This is one of the reasons open-source-but-not-open-contribution is becoming more common. If you don't accept code contributions you don't have to worry at all about where that code ultimately came from, which could be an expensive legal problem further down the line.
Not-open-contribution is what I'll be going with if any of my nascent projects get to the point of having something I'm prepared to release for public consumption. I know I'm potentially losing out on help, but I'll be keeping as full control as possible of my stuff⁰. Found a bug: document it to me, and I'll fix it. Desperately want to fix it yourself because I'm not fast enough, or you just _really_ want to? Fork. Want to implement a new feature that I'm not planning or that I'm being too slow on for your needs? Fork¹, and if you are nice about it² I'll forward on anyone else wanting that feature to your project.
--
[0] useful should I decide to alter the license(s) it is available under etc.
[1] or, if you don't want to be constrained by my licensing terms for my code, which are most likely AGPLv3, that get included in your project, clean-room reimplement (or release as patches initially, slowly replacing my code completely, and then relicense once all my stuff is replaced, similar to what LAME did for patent reasons)
[2] trying to nag me to change my mind before you do so is not being nice about it: if I say “no” or “maybe later” then continuing to beg/nag/cajole is wasting my time
Selectively it is, rejecting low quality updates and so forth, but some take exception to projects that reject all or ask for them not to be sent in the first place.
Is this a "generation gap" or something? This has been the case for decades for many (and probably most) of the relevant open source products where a commercial enterprise is behind the project, and projects who have the unfortunate experience of discovering that attorneys really exist.
Christ. Talk about impassioned language. “Demanding”? Not “asking for”? That’s fine, it’s perhaps a bit ambiguous. Not “requiring”? But, “demanding”?
If you’re contributing to big open source projects with any regularity, you surely know what a CLA is already. This is hardly new. Just off the top of my head, Django has a CLA: https://www.djangoproject.com/foundation/cla/. This just feels like drive-by outrage.
It’s completely in line with societal expectations that the maintaining entity of an open-source project can set the terms by which contributions are accepted. Its presentation as a “legal agreement” is just an agreement that actually stands a chance if it went to court.
It’s their project, and since you haven’t contributed to it, it’s by absolutely no definition “yours”. You’re free to not contribute. You’re presumably free to fork it.
If you see an open source project that’s badged as…say…MIT but that has a CLA, take that that into consideration when deciding whether or not to contribute? Is this really worth a thread?
The usual Open Source / Free Software puritans will have the usual puritan arguments about this. I really don’t care that much. I put these arguments in the same bucket as arguments from people that claim that something isn’t “Agile” or “Scrum”. There’s more than enough room for different people and organisations to choose different terms for licensing their software. It’s not weird or creepy or deceptive.
"The Django software foundation is asking all past and future contributors to sign a contributor license agreement. Every contributor of non-trivial amounts of code (more than just a line or two) to Django should sign such a document. If somebody is unable to sign the document, their contribution (whether it be code, or documentation or string translations) may need to be removed from Django. "
If they were operating under a model of open contribution ... and then pull the carpet out from under them (as they are asking for retroactive compliance). They should be prepared to have the contributions pulled out from under them with legal action.
Besides why does the creep Chaim Kirby (President of the Django foundation) want to know where you live, keep it accessible within their org just to "receive your contribution".
The corporate behemoth is publishing something that I get to use for free. It has a bug, that I just happen to trip over constantly. It's important to me to fix it since it requires effort to work around it. It's just not high enough in their priority list that I can expect that to happen soon. The fix is simple and I have a good idea how to approach it.
What do I do? Fork, carry the patchset until they fix it? Or contribute the fix, taking all the burden of maintaining it.
I can now freely decide to accept their terms on how to contribute a change that benefits me to a project they own.
Usually this means the corporate behemoth takes on the burden of maintenance for your PR, relieving you of the costs of maintaining your own fork. It's often a worthwhile trade-off. Your fixes will also get wider distribution if you upstream them, benefitting the community as a whole.
Because you want something. That might be a feature that you then don't have to maintain yourself, publicity/goodwill, or even entertainment. Or to improve something you like so that you like it even more.
But my code is owned by the FSF not the Linux Foundation, and I'm pretty sure they won't allow to hand over their projects over to someone who dislikes their preferred license, GPLv3.
>> From the comments I don't get what is HN's stance for it? Could someone please ELI5 the arguments for and against this?
HN doesn't have one stance. The pros are that "the project" or those running it have full control of all contributions. In regular open source this allows doing things like changing the license. It can be beneficial to change the license from say GPLv2 to GPLv3, or maybe to MIT if that's what turns out to be important. The cons include things like taking the code private and changing to only commercial licenses. This one also seems to suggest they might have commercial licensing in addition to open. In the end, a contributor can always take the code and fork it if something bad happens, but in practice it's best for a project to have a single central development effort.
One project that comes to mind is Q-CAD. It's developer maintains a commercial/paid version that has things the open source one does not. Therefore a CLA is required to contribute to it. I suspect enough people decided "hey, I don't want to contribute to your commercial product even if the OSS version also gets my contribution" that very few contribute, and years ago an earlier version was forked to create LibreCAD. Sadly Q-CAD has since made major improvements - to toolkit and others - but the open version can't take those changes. So we have an open source version that is kind of old and a newer version not getting contributions.
Q-CAD seems to be GPLv3, so the open source version could take the changes as long as they comply with the license. They cannot take features from the commercial version. A CLA doesn’t change that either way. LibreCAD can’t contribute back unless they accept the CLA.
Or is the issue that the fork diverged and the work from the commercially supported version is progressing faster than the LibreCAD fork?
You should not enter into a legal agreement for free. You are bound by it weather you understand it or not. Also, what you submit, and what the agreement says you give, are not the same thing. The agreement will stay in effect, even if you stop contributing.
Are you responding to the wrong comment or something? None of this seems relevant. If your advice is to not enter an agreement for free, then don’t contribute to projects that require a CLA. If you’re right about the public’s lack of appetite for them, then nobody else will contribute. What do you want?
Absolutely my feelings as well. They want to have their cake, eat it too, charge you for your own contributions after the re-license, and try to take you to court later over the perceived misrepresentation.
It's a commercial product intended for Disney to make money. I don't see why you wouldn't expect some kind of paperwork from a worldwide media conglomerate. This is Disney we're talking about, the company that claims to have bought the legal rights but not the obligation to pay royalties of popular works.
As always, forking and maintaining your own version is an option. They don't have an obligation to accept your help, nor do you have an obligation to agree to their terms.
Demanding is a bit strong, it's a reasonable request! If you're not happy with it, you're welcome to not contribute, or to fork and share contributions there instead.
I do think this example is a bit long and hard to read though. Most I've seen for projects tend to be much simpler: "I promise that this is really my work, that I have legal rights to share it, and I give the project this code to use as they see fit with no warranty etc". For example: https://github.com/TryGhost/Ghost/blob/main/.github/CONTRIBU.... And CLA Assistant is great for this if you're using Github, it's super quick & easy.
Of course it doesn't matter if you're building a small library yourself, but as soon as there's a real business associated anywhere, it's helpful to have contributions clearly documented, and to have clear control over the licensing of code within your projects.
Not-open-contribution is what I'll be going with if any of my nascent projects get to the point of having something I'm prepared to release for public consumption. I know I'm potentially losing out on help, but I'll be keeping as full control as possible of my stuff⁰. Found a bug: document it to me, and I'll fix it. Desperately want to fix it yourself because I'm not fast enough, or you just _really_ want to? Fork. Want to implement a new feature that I'm not planning or that I'm being too slow on for your needs? Fork¹, and if you are nice about it² I'll forward on anyone else wanting that feature to your project.
--
[0] useful should I decide to alter the license(s) it is available under etc.
[1] or, if you don't want to be constrained by my licensing terms for my code, which are most likely AGPLv3, that get included in your project, clean-room reimplement (or release as patches initially, slowly replacing my code completely, and then relicense once all my stuff is replaced, similar to what LAME did for patent reasons)
[2] trying to nag me to change my mind before you do so is not being nice about it: if I say “no” or “maybe later” then continuing to beg/nag/cajole is wasting my time