Open-source projects are demanding legal agreements to create PRs
cla-assistant.io
cla-assistant.io
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
http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
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".
I captured the full document:
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.
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.
Or is the issue that the fork diverged and the work from the commercially supported version is progressing faster than the LibreCAD fork?
We're an open source software community. You didn't get linux because Linus wanted to become Bill Gates.
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.
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.