Hacker News Reader

Comment by systems_glitch | Hacker News Reader

Been saying this privately for a long time. Agree on "GPL is the best choice," as well. My personal experience with devs who don't want to GPL their code or contribute to GPL projects is that they're under the impression that having a permissive license on their own project will get $corp to use it and, somehow, they'll profit from $corp using it. Haven't personally seen it yet, but I have seen a bunch of permissive licensed stuff get pulled into bigger projects and changes never contributed back.

View on HN

As an open source project 'owner' my personal experience is similar i.e. nearly nobody of the companies contributes back. Often times you are not even allowed to talk about their usage.

But still, I think the permissive license we picked was the better choice. Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)

IMO a permissive license is better and easier for the developer and the GPL is better for the end user.

But even the GPL does not grant you anything without a lawyer :) E.g. I tried to get the GPL source code from Waze (tried it multiple times!) and got a reply: "I've looked into your concern and determined that it needs some extra attention from our end." See also https://2jk.org/english/2014/03/27/israeli-waze-hit-with-gpl...

(btw: you can get the inofficial code from here https://github.com/maximuska/Freemap-waze)

> IMO a permissive license is better and easier for the developer and the GPL is better for the end user

No, as developers we use tons of software. We are users before being developers. As such, GPL protects developers as well.

> Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)

In this scenario, your company is the thing GPL is trying to protect your community devs from (i.e. the gpl is trying to stop a company from taking contributions donated on the condition they would be open-source, and selling them privately without compensation). You are basically saying the GPL makes it harder to do the thing the GPL was trying to stop.

The GP wants to donate some software to the community, on the condition that he gets to use any derivative community work on his product. Anybody contributing to the code is clearly informed of that, and decides to do it out willfully.

It's a perfectly reasonable arrangement that adds value to both the community and the GP, and that the GPL "protects against". So, yes, the GP's point stands in that there are uses for licenses other than the GPL. All of the complaints about they only being good for people creating proprietary software are true, they just completely miss the point.

To clarify, i dont think that GP is morally wrong or anything (as long as they are upfront about what they are doing, although it can get morally questionable fast if they aren't careful). I guess the point i was trying to make is its weird to describe that as a flaw of the GPL when its basically the primary use case .

Oh, the GP is in a context of people strongly implying that any permissive license shouldn't be used at all.

But if you take too long to reach it and forget the context, it does indeed sound like a weirdo complaining that the GPL is copyleft.

If someone published his code under GPL, but then use it in himeself product, is this moral?

I think yes, obviously.

The morally questionable situation is where you publish code under GPL, allow community contributions on the code on the condition that the community contributors sign a document transfering copyright to you (without payment or anything like that) and then also use those community contributions in a closed source product you sell.

thanks your reply, I did not find if this only work when they just want to offer some gifts.

> The GP wants to donate some software to the community, on the condition that he gets to use any derivative community work on his product.

wat

That's exactly backwards. Releasing your donation under a permissive license doesn't give you that. A permissive license gives others express permission to make derivative works that the original author company might not be able to use themselves—because there's no obligation for others to keep it open...

> IMO a permissive license is better and easier for the developer and the GPL is better for the end user.

A permissive license is only better and easier for developers of proprietary software. The GPL is better for developers of free software and for end users.

I agree, though I think there's an irony in the mutual incompatibility of many FOSS licenses. For instance, try making a GPL project that depends on a data file licensed under Creative Commons. One's best bet in such a situation is to ask the rights holder to release to you under a compatible license, but people (and institutions) are generally reluctant to do so.

Two permissive licenses, one headache for the FOSS dev.

> But still, I think the permissive license we picked was the better choice. Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)

Regardless of license, most software projects are either community projects, or corporate projects, but not both. Corporations rarely see fit to invest in the development of a project they're using because some other chump is giving it away for free. And volunteer programmers rarely want to deal with submitting commits to a project with corporate managers who are focused on the needs of the organization and see volunteer programmers as out-of-the-loop nuisances.

Whether you're a corporation open sourcing something to get free community labor, or a volunteer open sourcing something to get corporations to contribute, you'll probably be disappointed.

> IMO a permissive license is better and easier for the developer and the GPL is better for the end user.

users don't care, they aint taking the code for changing.

Arguably it also doesn't matter till you are corporation closing the code for profit. If all you do is OSS and are used by people that also release OSS, extra protection GPL gives are not useful. But of course real world is not that idealistic.

And for that of course BSD/MIT is better. No facility for anyone to get anything out of you so you can take and take without ever giving back aside from occasional bug report and outrage over someone having a bug they didn't fix in project they are not paid to develop in the first place

GPL gives one guarantee - that the code you give will not be closed down for money and used to save some corporation some dev-hours. Some devs don't like it because it is making their life difficult (and I'd also argue anything higher than LGPL for stuff like libraries is kinda pointless), but that's kinda the point.

> GPL gives one guarantee

GPL explicitly allows commercial usage. E.g. I take take your GPL code and create a SaaS around it and make a lot of money or I can create a consultancy service around your GPL code.

My single biggest incentive when I'm writing open source code is that I want to NEVER have to solve the same problem again, for the rest of my career, no matter who I am working for in the future.

That's why I chose the license that seems least likely to prevent me from being able to use the code I've written (currently Apache 2).

> That's why I chose the license that seems least likely to prevent me from being able to use the code I've written (currently Apache 2).

That's incorrect. As the upstream author you have every right to use your own code any way you want.

> As the upstream author you have every right to use your own code any way you want.

Well, that depends on if the project accepts pull requests, and whether they have something like a contributor licensing agreement in place.

I wrote "your own code". Obviously if you accept contributions from others it's different.

I think the parent is alluding to a situation where their employer has copyright for the code written on the job. If you take your own previously-written code and just "submit" it to the codebase, you've created a legal snafu for yourself if you ever want to use that same code again elsewhere.

Of course you can take your code and license it to said employer in whatever way you both agree on. But this is going to be much easier if the code is already publicly available to everyone, with a known license: the employer doesn't need to even care really who the author is, just the license.

> If you take your own previously-written code and just "submit" it to the codebase, you've created a legal snafu for yourself

Not at all. The code you are going to submit already has a license file attached. Just update it with an accepted FOSS license before the submission.

You don't have to provide any special license or make it public.

As I said

> Of course you can take your code and license it to said employer in whatever way you both agree on.

but that's likely to be a manual step with a lot of raised eyebrows, frowns, and questions involved.

Not if I was writing it for someone else's closed source project at the time.

for the same reason in one job i was able to change my employment contract to include a guarantee that all code i write on that job will be released under the GPL

i thought that way i would always be able to use the code in my own FOSS projects but i would also not be able to sell out and make my work proprietary (since it would contain GPL code owned by my employer)

this may seem less beneficial than an apache license but it was aligned with the company goals as far as my work was concerned, so i essentially had them put a verbal promise into writing, and i thought it was a neat way to commit myself to FOSS

Makes sense. There are two broad classes of code, actual standalone projects, and handy code you don't want to rewrite at each job. The latter really fits BSD or Apache - you're trying to break down as many barriers to use as possible and you aren't concerned about receiving contributions.

I don't think that's necessary, though. As the original creator, you're the "owner", not a licensee.

As the owner you reserve the right to re-license it to anybody you'd like, under any license you'd like, as long as you don't give that right away.

At a job, or on a contract, the employment agreement or the contract will almost always says you're giving that right to them in exchange for compensation.

...unless you accept contributions from other people, who then own those contributions.

But then it's no longer about "using code you've written". It becomes "using code you and other people have written".

> My single biggest incentive when I'm writing open source code is that I want to NEVER have to solve the same problem again, for the rest of my career, no matter who I am working for in the future.

You can tell your company to either buy a proprietary license from yourself or reimplement the whole thing.

> I chose the license that seems least likely to prevent me from being able to use the code I've written (currently Apache 2)

You won't be able to use it if the future project is under a GPLv2 (or GPLv2+) requirement, since Apache 2.0 and GPLv2 are not compatible.

GPL is still a questionable choice for anything that can be turned into a SAAS app. Remember if you dont distribute the binary, you dont have to distribute sources.

This is a good point and I'd like to suggest (without being certain) that the AGPL is a good solution.

> The GNU Affero General Public License is designed specifically to ensure that ... the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

Imho if you're ok with the GPL v3, the AGPL v3 is almost always the better choice. The spirit of the GPL is "if you change it for anything other than internal use, you have to distribute the changes", and the AGPL just logically extends the enforcement of this to services provided over the internet.

The AGPL v3 and GPL v3 also contain provisions to make them compatible with each other (resulting in AGPL terms for the combined work, but the GPL parts remain GPL).

The FSF goes a bit more into detail on this: https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t...

FWIW, i dont like the ambiguity of what is "configuration" and what is "code". I feel its a bit unclear.

I also think its a bit problematic taken in the absolute, sometimes you have security patches you want to deploy and test out for a week before making the issue public, or perhaps emergency patches for sudden (downtime causing) issues.

I don't think the nitty gritty details of the AGPLv3 matter much in practice. Those details matter most to the sort of organizations that fear lawsuits and consult with lawyers, and such organizations will likely not use AGPLv3 licensed code at all.

AGPLv3 is thus a de facto 'hobbyists only' license, and hobbyists by in large don't go around suing each other; generally they just make good faith efforts to respect each others licenses and maybe use social ostracism when somebody steps over the line. Since hobbyists don't take their community disputes to court, the technical legal minutia of the license doesn't matter to most of them.

I still think details matter because it helps determine what is good faith following the license. Ambiguity also helps spread fud, which makes it harder for big companies to contribute and reuse such software.

Many people find the AGPL to be a nonfree license, myself included.

What isn't free about it?

As a corporation, I might not want to use it in conjunction with my code, but that's the point. You are free to do what you want, but you in turn must share your code.

Or you engage with the owner to make a financial arrangement for a separate license.

In short: It prohibits you from not sharing your code based on whether or not the ethernet cable is or is not plugged in to your machine.

This is like nonfree usage restrictions on otherwise free software, like the famous (if unenforceable) “can not be used for evil” license clause.

that's not right. in my understanding the intention of the AGPL is to share code with users of a program, even if the users didn't get a copy of the program.

therefore the AGPL shouldn't force you to share code if the program runs on a server. but it should force you to share code if the program can be accessed by a user.

this may even apply to running something like a kiosk device where users interact with a program on a device they don't own.

Right but which freedom does that restrict that's not in the spirit of the gpl?

I.e. the gpl prohibits you not sharing code if you distribute the binary. What is the philosophical underpinning of "sharing binary" not being a restriction but "ethernet" being a restriction.

The evil thing is not similar because you are discriminating against a field of endevour (similar to licenses that say educational use only, non-commercial only or non-military only). It seems to be a very different type of restriction.

> whether or not the ethernet cable is or is not plugged in to your machine

That's not even remotely near what it is.

>> As a corporation, I might not want to use it in conjunction with my code, but that's the point.

I've worked for several large corporations and were in the throes of a major project. Using an Open Source tool would've cut a lot of our dev times by many hours. Three out of three times, all three team leads and managers said "no" to using open source. We had to build several large components from scratch, which did lead to extended development timelines, a ton of working late at night and several "crunch" weekends.

Their rationale? They didn't want to have to maintain a piece of software that was open source. The resounding opinion was it was "dangerous" and not safe - because someone could check in a malicious piece of code and that could end up in our very large, enterprise application when we needed to update it. Nobody wanted to be on the hook if that ever happened.

In the end, it seemed like it was more about upper management types playing CYA instead of trying to put out a solid product.

I don't think there is any computer currently in use with 0 open source on it.

Am I mistaken in believing the only additional requirement of the AGPL is, in layman's terms, that if you operate the software as a paid service you must also release the source code of any changes that you apply to it?

If that is the case, I don't see how the AGPL qualitatively infringes on any "freedoms" that the GPL doesn't already restrict: you must keep derivatives free. Of course one may argue that the GPL is nonfree when compared to BSD/MIT style licences, in which case fair enough.

The justification usually given for AGPL is to prevent other companies from running paid SaaS without sharing their modifications. The actual terms is that any user who interacts with the software over the network must be able to download the sources. It doesn't say anything about whether the service is paid or free.

I think the argument of FOSS people who don't like it would be something like, as a user, just running the software on my machine can potentially create a legal obligation to set up source distribution, if, like, I forgot to block a port.

Ah, I was unaware that it applied regardless of it being a paid service or not. I imagine that would be somewhat analogous to distributing binaries of modified GPL software for free without providing the sources.

In any case, does the AGPL requirement to provide sources apply even if you are running an unmodified version? In other words, would merely pointing to the original repository not be enough?

Regarding the risk of accidental legal obligations, I suppose it depends on the details and technical wording of the licence.

If the requirement broadly covers any use of the software on the machine (e.g. some backend service that happens to help your public webserver to stay online) I can see the discomfort, especially if one must explicitly provide or link to unmodified sources too.

On the other hand though, if the requirement is limited to actual provision of the software's functionality to 3rd parties, I would argue that if someone accidentally provides it due to forgetting to block a port then they have much bigger problems than the AGPL.

It doesn't matter whether the service is paid or not.

You can read the terms yourself, the network part is section 13, it's not long.

https://www.gnu.org/licenses/agpl-3.0.en.html

It just says interact remotely through a network. Interpreting what this means precisely is left as an exercise for the reader / the reader's lawyer.

  forgot to block the right port

I'm not against AGPL myself so don't take that as like, the strongest argument against it. It was meant a bit tongue-in-cheek.

thats's just silly.

if you get notified of a security breach caused by your own incopetence, you secure it. which would effectively be the highest harm apgl can inflict on you already: stop hosting the service. which was your point all along.

i think pointing to an upstream repo is probably enough in most cases provided you can link to the right version. but what do you do if the upstream repo disappears?

for a popular program that's not very likely, but lost source code is the bane of software development, so hacing your own version available would be better, at least as a backup

> but what do you do if the upstream repo disappears?

distributions keep archives. Just use a distribution and you're fine.

> just running the software on my machine can potentially create a legal obligation

Not true: only if you made local modifications.

> I forgot to block a port

Also not true. You have plenty of time to close that port.

"""your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice."""

If you expose services on the Internet by mistake you are going to have 1000x bigger problems than the risk of being sued successfully for a honest mistake.

Personally, I am much more wary of the definition of "interaction" than of unwillingly distribute the software. The later one is a fault of the person accessing my computer against my will, not mine. But I have no idea how far "interaction" can be stretched-up, is using your software equivalent to signing some NDA? Hell if I know.

That said, FOSS authors normally aren't the kind of people that pushes to those crazy maximalist interpretations of documents. So if any risk exists, it's not large.

I would say GPL constrains some freedoms of the code users to provide some freedoms to the end users.

It's not entirely clear what counts as derivative work with regards to GPL. There is a lot of corner cases and workarounds in the real world. It becomes even less clear when you widen the definition of distribution.

Do you mean you believe it doesn't comply with the Free Software Definition and/or Open Source Definition, or that you believe it does but that it's nonfree anyway (or in other words, that you disagree with those definitions)?

> Many people find the AGPL to be a nonfree license, myself included.

I don't understand this stance.

From the point of view of the user, the AGPL offers the same freedoms as the regular GPL. If you use the program, you have the right to see and edit its source code, regardless if the program runs on your own computer or on another computer.

How can anybody call this feature "nonfree" is beyond me.

AGPL basically says you can't use the program to provide an online service unless you $(sacrifice your first-born.)

Granted, the license only asks you to publicize your modifications, but in software that's basically your "first-born".

Not really, the vast majority of users of these kinds of software run it unmodified, the valuable stuff is around it. (If that weren't the case, MongoDB hadn't come up with their own "give us everything!" license because AGPL was too "weak")

One of the important definitions of Free (capital F) software is the freedom to modify it without restrictions.

If you're just talking about the freedom to run things unmodified, basically every software you can download online without paying is "free", and obviously AGPL fits that bill for the uncapitalized "free" software. But that's not what we're talking about here, right?

If the freedoms is your angle: And a large point of the GPL family of licenses is to make you publish your changes so your users can run and further modify it, and AGPL is a logical extension to that for a world in which users rely on software they don't personally run. So that their important freedom of being able to run and modify software they rely on is preserved. If you get to keep your changes, your users are deprived.

The situation is funny that AGPL is widely derided as both being to weak and being to strong.

Many people believe all sorts of absurd things with no evidence.

Do you have evidence?

To add on to this:

There's also the path that--even if you have a permissively licensed project--$corp will see your thing, like it, and decide to just copy it, to overall avoid having to deal with dependencies they do not own. In other words, a lot of places are unwilling to play in anyone else's backyard. They "support" open-source, but only when it's on their terms.

They might even call you, under the pretext of a job interview, and of course they want to discuss in detail the most significant project you've worked on! But you find out there are all kinds of awkward conditions on the job offer, like a cross-country move, or much lower pay than you were expecting, or no actual commitment that you'd be working on your project but just a vague, verbal statement that you could continue "during 10% time". You'll have to interview three more times with 15 more teammates. Everything gets dragged out for months and then you see them announce their own project in opposition to yours.

That is, if anyone pays attention to your project. Most open-source developers are categorically averse to anything resembling advertising. Try building a thing and then posting about it on a topic-appropriate sub-Reddit. So many of them will delete your post or ban your account from the sub for "spam".

The vast majority of the market--including other open-source developers--want open-source developers to write code, shut up, and go away. The minute you start talking about maybe wanting some remuneration for your efforts, you're suddenly "ungrateful" or "shilling" or "spamming" or "selling-out". (EDIT: It's happening in this very thread, further down the page)

> My personal experience with devs who don't want to GPL their code or contribute to GPL projects is that they're under the impression that having a permissive license on their own project will get $corp to use it and, somehow, they'll profit from $corp using it.

A lot of big corporations will not allow GPL dependencies to be used in their codebases, and not having a GPL license will definitely make software more usable by those corporations.

How the developer expects to profit by giving something away for free is definitely a mystery, but there is also some truth to the idea that a GPL license does scare companies away.

I choose BSD over GPL because I want myself and others to have the maximum utility of my work. demanding downstream users coordinate that work with me doesn't really support that goal for either of us.

The GPL solves very few problems nowadays, because most software isn't distributed anymore. The AGPL solves a specific issue: a company is running an undistributed, modified version of the code, which is accessed by end-users, that gives them a business advantage.

Elasticsearch is a good example of a problem that isn't solved by a different license. Amazon is running essentially unmodified versions of elasticsearch, which competes against the business model of the company building elasticsearch. Even with an AGPL license, elasticsearch (the company) is not going to be making any money.

If a company isn't interested in upstreaming changes, it probably won't help that they're using an AGPL license. If the code isn't user-facing, the license won't force them to make their changes available. Even if it is, often changes a company doesn't want to upstream are very specific to them and aren't useful to others. Even if it's business valuable, and the company makes the changes available, they won't be making it easy to integrate.

The AGPL, more than anything, places a burden on users and developers, and reduces the community size. Most companies don't allow the use of AGPL software, and in the cases they do, they often only allow its use in an unmodified way, or only allow modifications if it isn't user-facing.

That was our main reason for scrutinizing AGPL libraries at $previous_job. IIRC our biggest concern was over iText (Java PDF library) and other libraries that depended on iText. In our case, we ended up not having to modify anything and were fine, but if we did have to modify, it'd have been to include trade secret features, which are a non-starter for distribution!

It's a nasty, complicated situation with bad actors on both sides.

> because most software isn't distributed anymore

You're probably thinking of SaaS, but, still, what?

I'd argue we distribute software much more than say 20 years ago. Almost every web site you view is distributing non-trivial software (javascript, from maybe a dozen npm packages). App stores are making software distribution much easier for the average user. Programmers are increasingly using dependency managers to download libraries. Even every SaaS service is getting their software from somewhere, and the tech stack is increasingly complex these days, which means even more software being distributed and used.

Perhaps what you mean is "software isn't sold anymore", so the money is all in the services. Which is probably true, and this is probably where GPL is becoming irrelevant.

But then, it can be argued that the services model was in part the industry's response to the prevalence of GPL, which pushed businesses to find workarounds. People need to make money, and if software sales isn't generating enough dollars because GPL software pushes down the prices people are willing to pay, then they'd just invent reasons for users to buy services instead. -- which, if true, could be interpreted as a success story for the GPL.

You have to truly hate people to license a library using anything but a permissive license, especially in the javascript ecosystem. Nothing ruins your day quicker than finding a transitive dependency with a copyleft license.

Maybe I should have been clearer. Most actual products based on OSS aren't distributed anymore. They're SaaS. The majority of the most popular app store apps are clients to a SaaS product.

The only problem I have with GPL is that I don't want to use "or later version" (as I don't trust all future FSF leaders), but it's illegal to link GPL V2 and V3 code, and I would expect the same problem will arise with a future V4.

The case of Linux vs *BSD is probably the largest-scale test of efficiency of GPL vs permissive licenses on stuff contributed back. It also looks pretty decisive, too.

I think it is dangerous to look at this too much, there are other reasons that Linux got off to a better start not directly related to the license. Such as some rather serious lawsuits against FreeBSD in the past, that hurt adoption in the time Linux was getting up and going.

But yeah it is true that Linux is much more efficient at getting stuff upstreamed, I think Sony has sent more patches to Linux than FreeBSD and the PlayStation runs on it.

I don't think i've ever heard someone saying this. Does anyone really believe this? Some concrete examples would be illuminating.

For me the logic roughly worked out like this. I managed to get successive employers to "sponsor" (i.e. pay me my normal salary but let me use my work time to work on my open source project) my open source project, because we were using that project at work and it was missing features my employer was interested in.

Some of those employers had policies outright prohibiting GPL use...

if it was lgpl licensed they'd have no choice but to do that

No. They would have simply never adopted the library and most likely not hired me either.

as it goes for 99.99999999999% people who release under MIT.

And linux (GPL) does have paid developers, and so does webkit (LGPL).

Your data is rather meaningless… but I'm happy your statistic that excludes all the data points you dislike proves your theory :)

Reply on news.ycombinator.com