Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t sign a CLA

drewdevault.com

Post reply on HN
Print view View original

71–80 of 196 posts

Re: Don’t sign a CLA

#71

Post by Sir_Cmpwn »

Klathmon wrote: post #66
Sir_Cmpwn wrote: post #56

Earlier quoted context omitted.

The GPL family of licenses certainly provides the strongest guarantees to the contributor. But let's consider a "weak" license like MIT. Here's the text to refresh your memory: https://opensource.org/licenses/MIT If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. The GPL differs in that the new work must also be licen…

If i'm reading you right, the implication is that if you sign a CLA for an MIT license codebase, they could retroactively close-source your code contributions? My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override…

By assigning copyright to them, you give them the right to distribute your work under a different license. Yes, you can't take back the original license from the older code. But they could start distributing the code without respect to the original license.

>The "without limitation" part of the MIT license guards against this doesn't it?

Ah, but it reads "without limitation [...] subject to the following conditions"

Re: Don’t sign a CLA

#72

Post by dec0dedab0de »

Sir_Cmpwn wrote: post #57
dec0dedab0de wrote: post #48

Earlier quoted context omitted.

What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing. Also, technically if you don't pay for code the copyright holder can revoke the lice…

>Also, technically if you don't pay for code the copyright holder can revoke the license at any time I'm pretty sure this is a myth.

IANAL but I think it is a grey area. Licenses are contracts, and contracts usually require "consideration", but there is also something called "Promissory Estoppel" which may nullify that. I found out about it from someone on here a while back and went down a rabbit hole googling it.

Re: Don’t sign a CLA

#73

Post by tomp »

dec0dedab0de wrote: post #48
lmm wrote: post #44

Earlier quoted context omitted.

> I did not say that, nor do I believe it, nor is it really related. What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments ag…

What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing. Also, technically if you don't pay for code the copyright holder can revoke the lice…

> technically if you don't pay for code the copyright holder can revoke the license at any time

So Linus can all of a sudden say that Linux is no longer GPL?!

Re: Don’t sign a CLA

#74

Post by sevensor »

jpablo wrote: post #20

Wait, Free Software Foundation requires a CLA itself! https://www.gnu.org/licenses/why-assign.en.html

They do, and I believe it's because it gives them a better platform from which to pursue GPL violation claims. I think that's basically sensible and an exception to OP's general statement -- if you're contributing to an FSF project, you need to understand that what you're doing is political as well as technical. You're giving FSF more ammunition with which to enforce copyleft. FSF is an exception to the concern that the asignee of your copyright is going to do a proprietary relicensing.

Re: Don’t sign a CLA

#75

Post by tomp »

Sir_Cmpwn wrote: post #56
lmm wrote: post #44

Earlier quoted context omitted.

> I did not say that, nor do I believe it, nor is it really related. What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments ag…

The GPL family of licenses certainly provides the strongest guarantees to the contributor. But let's consider a "weak" license like MIT. Here's the text to refresh your memory: https://opensource.org/licenses/MIT If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. The GPL differs in that the new work must also be licen…

The majority contributor(s) (i.e. those that are making you sign the CLA) can relicence their contributions, and keep your tiny contributions MIT licenced.

Hopefully they can't relicence retroactivelly, so the previous version of the software stays available, but any following versions can be entirely closed source (but they keep your MIT licence notice).

Re: Don’t sign a CLA

#76

Post by rurban »

hyperpape wrote: post #17

An interesting contrast among FOSS maximalists is that the FSF requires a CLA for a subset of its projects: https://www.gnu.org/licenses/why-assign.html

It limits a lot of contributions, yes. It's certainly "unfree". But I still signed it happily, even if I agree with a lot of op's points.

In my case I need the FSF to defend any evil actions which did happen before with these type of packages (libredwg), and will happen again. I certainly don't want to be at the end of such a lawsuit or infringement claim (like illegally using a trademark), and I'm happy that the FSF will defend us. Even if the external contributions are 10x lower than with a non-gnu project and it's a pain.

Re: Don’t sign a CLA

#77

Post by whatshisface »

tomp wrote: post #73
dec0dedab0de wrote: post #48

Earlier quoted context omitted.

What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing. Also, technically if you don't pay for code the copyright holder can revoke the lice…

> technically if you don't pay for code the copyright holder can revoke the license at any time So Linus can all of a sudden say that Linux is no longer GPL?!

Each contributor may only re-license their contributions independently. If there's any of Linus's own work left in the kernel it would have to be rewritten should he decide that he was fed up with RMS and was going to take Linux closed source. ;)

Re: Don’t sign a CLA

#78

Post by Legogris »

craigsmansion wrote: post #28
Legogris wrote: post #4

It's a great point to be aware of, but the title and the tone implies that you as a contributor should be a FOSS maximalist. As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications. When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged…

> to go full Stallman and say that everything but GPL is evil. Can you provide a quote where he says or implies such a thing?

I wasn't necessarily referring to the author here, it is more of a straw-man really. Could have worded that better.

Re: Don’t sign a CLA

#79

Post by chipotle_coyote »

Sir_Cmpwn wrote: post #22
Legogris wrote: post #18

Earlier quoted context omitted.

No, but I would be just as upset if I wouldn't have done that contribution. There is no way they can change the past - my contribution is still open source and so is the project up until the version where they introduced the license change. The version I made my contribution to is still BSD but the current upstream master might not be.

Yes, but now that version is quickly becoming stale, growing CVEs and perhaps becoming incompatible with the new upstream, with a community left in disarray that more often than not fails to support a fork.

I don't see how a CLA materially affects this possibility, though. If my company sponsors a BSD-licensed open source project without enforcing a CLA and then decides that starting with the next major version, we're taking it closed source, the exact same thing you describe is just as likely to happen as with a CLA -- the deciding factor seems to me to be whether most of the development activity happening on the codebase is community-driven or driven by paid developers at the company. Conversely, if the community is active and doing a lot of major work already, and there are enough non-company developers with the time, interest, and skill to start and sustain a fork, they're going to do that with or without a CLA.

Re: Don’t sign a CLA

#80

Post by Klathmon »

Sir_Cmpwn wrote: post #71
Klathmon wrote: post #66

Earlier quoted context omitted.

If i'm reading you right, the implication is that if you sign a CLA for an MIT license codebase, they could retroactively close-source your code contributions? My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override…

By assigning copyright to them, you give them the right to distribute your work under a different license. Yes, you can't take back the original license from the older code. But they could start distributing the code without respect to the original license. >The "without limitation" part of the MIT license guards against this doesn't it? Ah, but it reads "without limitation [...] subject to the following conditions"

Yes, but those conditions start and end at requiring attribution.

MIT already allows sublicensing, so a CLA for an MIT project (assuming nothing else shady is going on) really only buys them the ability to change future licenses to something incompatible with MIT (would that be called superlicensing?), and possibly remove your attribution in future versions.

That to me is philosophically what I want out of a permissive license, so I personally am fine with CLAs in those cases, however I can understand why some would be against that.

Post reply on HN