Hacker News Reader

Comment by sneak | Hacker News Reader

A reminder:

Projects aren't able to do this (relicense a whole code base unilaterally) if you don't sign the CLA that assigns them your copyrights in the project.

Never sign a CLA to contribute to an open source project.

View on HN

Over a decade ago, I remember that we were debating the merits of CLAs that got all of OpenOffice.org owned by Oracle (cf. https://lwn.net/Articles/443989/ as a random starting point).

I really think this was the FSF's fault - they insisted on copyright assignment for any contributions to GNU, because if the FSF held the entire copyright, they'd be in a better place to pursue legal action against violators. But history has shown that this clearly hasn't been required: Linux doesn't have this policy, and no Linux enforcement case has ever failed because the Linux Foundation wasn't able to demonstrate clear standing. And the FSF basically legitimized everyone else asking for CLAs. Had they stood firm and said that giving up ownership of your code to a central entity is antithetical to the spirit of free software, and the license is all that people can rely on, I think we would have been in a much better place today.

Unlike MIT/Apache/BSD-style Open Source licenses, Free Software can't be relicensed by anyone but the copyright owner. It's a completely different situation.

The current problems stem from pretending that Open Source has any more of a relationship with Free Software than it does to proprietary software - an expectation that reifies (and honestly necessitates) things like "the Spirit of Open Source" in the minds of developers. The Spirit of Open Source is that you're working for massive companies who can ignore you.

The only relationship between Open Source and Free Software is the fact that Open Source code can be arbitrarily relicensed and therefore can be relicensed as Free Software as easily as it can be as proprietary software.

Please stop spreading incorrect information. Re-licensing is an exclusive right granted to the copyright holder; it has a specific meaning under copyright law. There is nothing in the Apache, BSD, or MIT license that grants re-licensing. Using source code that has been licensed under a permissive license in a larger work that is licensed differently (including more restrictions) isn't re-licensing.

Absolutely true. There's a consequence of this that people tend to ignore: You cannot remove the (e.g.) MIT license text from an MIT-licensed work if you redistribute it as GPL.

The MIT license gives you "Permission ... subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

You can abide by that condition by distributing your software under the GPL and retaining the MIT license text for portions. You cannot abide by that condition by "relicensing" the software and removing the MIT license: you are in violation of the license.

Fair distinction in MIT's case, and other attribution-ware.

> Using source code that has been licensed under a permissive license in a larger work that is licensed differently (including more restrictions) isn't re-licensing.

Whatever you want to call it is fine. I prefer to think that GPL'd software that incorporates Open Source takes a copy and makes it GPL (especially because if I modify the Open Source at all, my changes are not available under an Open Source license.) Other people who are using that piece of Open Source are not using my copy, which is GPL.

MIT, Apache, and BSD are "GPL-Compatible Free Software Licenses" according to the FSF: https://www.gnu.org/licenses/license-list.html#GPLCompatible...

I gather you have some meaning of Free Software that is different from what the FSF means by it, and also different from what groups like Debian and Fedora mean by it. Can you expand on what you mean by "Free Software" and what relationship it has with the "Free Software" movement as defined by the FSF, Debian, Fedora, etc.?

Do you think that the FSF, therefore, works within "the Spirit of Open Source", that contributors to glibc are working for the FSF, which can ignore them?

> "GPL-Compatible"

Of course they are. They can be placed into GPL software. They can be placed into any software.

> Do you think that [...] contributors to glibc are working for the FSF, which can ignore them?

Yes.

You're selectively quoting. The important part wasn't that the FSF claims that those licenses are "GPL-Compatible," which nobody disputes; the important part was that the FSF claims that those licenses are "Free Software Licenses." Do you dispute that?

Elsewhere in this thread you imply that you believe that the GPL is not an Open Source license. Can you clarify that, too? Because, again, it sounds like you're using terms that don't match what the Free Software and Open Source communities mean by those terms. (In particular, GNU would disagree with this claim - https://www.gnu.org/philosophy/free-open-overlap.en.html - as would the OSI, of course.) So you should define them.

I recently chose to sign a CLA for an MR I wanted to make to a commercial entity's SDK. The feature I added will enable me to build a product and potential revenue stream. I could have forked the project and maintained my own version, but I'd rather do the work for free and have someone else maintain the library going forward. I don't care about who owns or has access to the the work I did in this instance, so I was comfortable with signing it.

They can still do this if the old code base is under a permissive license, since permissive licenses like BSD, Apache and MIT are compatible with proprietary licenses.

Mostly true, but only up to an extent: without a CLA, they can't just update LICENSE.txt to replace the contents with the text of the new license and be on their merry way without any trace of the old one.

They can't hide the fact that it was once MIT/BSD/Apache licensed, and they still have to include copies of that original license (and any notices) even after the switch, as that is one of the conditions that contributors make their work available under, and failure to do so would mean the org is in violation if they haven't otherwise received approval.

Even if one has to include the original license and notices with the new version, the original license and notices apply to the portions which were present in the older versions. The new portions added to the software after the license change must be used only as per the new license. MIT, BSD and Apache licenses don't forbid you to use a new license to your own derivative work.

Everything you just wrote is true, but it's not clear why you felt the need to spell it out, especially right here. (No one has said otherwise. No one has said anything that could be mistaken to mean otherwise.)

I think you are confusing re-licensing with sub-licensing, which are not the same. Under copyright law, the copyright holder is granted certain exclusive rights over their work and re-licensing is one of the rights. If the license grants sub-licensing, a licensee can pass on some or all of the rights in the license to a third party. Of the three licenses you mentioned, only the MIT license allows sub-licensing.

The license terms for a sub-license must be consistent with the original license terms, although not necessarily the same. The sub-licensor can use different words as in the original license, but they cannot override the terms and conditions that are required by that license. The sub-licensor cannot sub-license more rights than have been granted by the original license.

Works released under the Apache, BSD, and MIT license can be included in a larger work with a more restrictive license or modifications can be put under such a restrictive license, but the original license must remain intact.

If you are getting your information on re-licensing from the Wikipedia page below, it is wrong.

https://en.wikipedia.org/wiki/Permissive_software_license

As long as the licence wasn’t copyleft, they can still incorporate your code in their closed project without a CLA.

I think they can effectively do the same thing if they own the copyright to a significant portion of the work.

Here's a thought experiment: Suppose that Mongo or Cockroach consists of 80% code for which they own the copyright (written by employees). And it's 20% written by contributors who have NOT signed the CLA.

Now can they relicence the whole codebase? No, but I think they can do something with thes same effect by relicensing their parts.

I think it's easier to see if they start a new project. Say Mongo starts a new project called "Dumbo".

Dumbo consists of 80% Mongo code relicensed. And they simply reuse the contributors' code under the existing open source license. So you distribute both licenses with the code.

But now it is still impossible (*) for Amazon or whoever to stand up a cloud service according to the license -- unless they want to rewrite 80% of the code.

I'm not a lawyer but that's my understanding of how it works. Interested in contrary (informed) opinions.

(*) edit: better to say that it's harder, not impossible. They can fork the old code under the old license. It really depends if the they "understand" the code.

If the initial license was GPL or the like, then it would prevent that, as long as they want to include any of the contributors' GPL code, they have to offer the whole package under GPL. MIT-style licenses would generally permit what you describe.

Also, they can't "unlicense" previously distributed code - if the system was previously distributed with an open source license, Amazon can use that version as the basis for a "Dumbo-compatible" cloud service without rewriting the 80% of the code as long as they're basing it on the last open release; they would only have to reimplement the new things that "Dumbo" added if they want; Amazon does not have to accept the new license if they don't need the new code and the old code with the old license fits their needs better.

And indeed, Amazon forked Elasticsearch from the last open-source version and is continuing independent development.

>Also, they can't "unlicense" previously distributed code

The United States allows authors (and heirs), except work-for-hires, to clawback copyright transfers and terminate licenses after 35 years on works made after 1977. This is an inalienable statutory right, which means it cannot be waived even with a contract.

That said, it may be difficult to terminate licenses in practice because open source licensing is done informally in most cases and courts haven't ruled whether this impacts the right of termination. However, copyright assignment and contributor license agreements are subject to termination.

Okay, the consequences of this paragraph (https://www.copyright.gov/title17/92chap2.html#203) are potentially devastating if triggered, but 35 years is quite a long time in the tech world. It would be very interesting on how such a fork could proceed once the 35 year term (measured from the grant of that licence, essentially the last day the original open source version was distributed) happens if the copyright owner issues the termination letters, but for all the recent licence switches this won't be an issue until 2050s, and in any case the users would have at least two years of warning to switch to something else or possibly make the product compliant by rewriting whatever of the original 35 year old parts are still needed.

Yes that matches my understanding.

And IMO it's fair for Amazon to continue the development based off an old version. Forking is an important right in open source. Nobody who releases code as open source should expect that their code isn't forked.

A CLA certainly makes things clearer. But, as is common with legal questions, the answer is some combination of it's not 100% clear and it depends on the particulars. For example, around the time of GPLv3, there was some discussion of whether Linux could be relicensed to GPLv3 if Linus wanted to. (He didn't.) Eben Moglen for one was of the opinion that it probably could be. [1]

[1] https://www.cnet.com/news/linux-to-gplv3-a-practical-matter-...

Reply on news.ycombinator.com