CLAs create different issues than making (small) open source contributions
utcc.utoronto.ca
utcc.utoronto.ca
For example, I have been asked to sign CLAs that granted rights to "recipients" or "organizations" that they hadn't named, having simply adopted a template CLA without filling it in. Some placed specific requirements on me, like "notifying the Project Manager", without information on how to do that or who they were. cla-assistant.io even has the unbelievable default of stating that it's a "CLA for multiple repositories or organizations" without naming them. How can you agree to a contract without knowing where it applies?
In my experience it is rarely possible to legally contribute to a project that uses a CLA. You can ignore the legal issue with the assumption that none of it will come up anyway, but that's a weird way to approach contracts.
1. e.g., <https://github.com/neovim/neovim/issues/3036>
I get it's usually just the lawyers protecting the company just in case a contributor tries something dodgy in the future. Out of principle however, I resent the broad assignment of copyright and granting them the right to relicense.
Of course I expect most of these projects would never exercise that right, but the mere fact that they _could_ take my Free work and make it non-Free is very disturbing.
So I'm simply not going to use it. I'm not going to get invested, then find a problem that I could theoretically submit a patch for. Rather than think of all the users who would benefit from my change, I'll just see it as free work for a megacorp.
That really depends on the CAA. It might allow way more. The text might be (legally) not applicable or have flaws, etc.
> Do you find this disturbing?
It is a barrier to contribute. I would not even bother trying to contribute.
Your statements here are already a bit conflicting to me. You partly might want to monetize the software. You partly might want to release it as MIT. I don't see how you'd still have a means to monetize if you'd release it as MIT. Feels like you want to keep all options open.
That all said, hey, you developed it, so cool if you'd listen to people with different opinions but I'd likely not need your software anyway I guess. Further, loads of non-CAA pure GPL software never receive any contributions. It takes quite a bit of effort to be noticed and get contributions.
FYI: If I reread above parts might come across as harsh but none is meant that way.
Most CLAs are a bot on the MR where you click sign, type your name, and it's done. If you don't really care about your code ownership then it's barely a speed bump compared to the rest of getting a PR merged.
Yeah, I've put 7 years and thousands of hours into it. I do want to keep my options open!
> loads of non-CAA pure GPL software never receive any contributions.
Yup, for several years before I had a CAA I received almost no contributions, except from people I had a direct personal relationship with. The CAA hasn't deterred people, in fact if you look at the timeline, I've gotten more contributors since I've put the CAA into place. (I'm sure it's not cause and effect, but still.)
> It is a barrier to contribute. I would not even bother trying to contribute.
I used to think that I would want any and all contributions to my project. But I've learned over time that, except for trivial changes, a PR from a new contributor is more effort than it's worth, by itself. I mean I can write code, and I do--lots of it. The real value in contributing is everything else: documentation, bugfixing, sincere attention on the problem. So I realized that I'm looking for repeat contributors, the ones who are going to invest in the project, and become active community members, maybe even maintainers. And the low-effort drive-by contributors who would be deterred by e.g. a CAA were never the contributors that were going to move the needle anyway.
In fact, and please correct me if I'm wrong, based on your general tone above, I'm guessing that you've never been an active contributor to any open source project, CLA/CAA or not. In which case, I consider the CAA to have been effective: you can feel self-righteous and I avoid the hassle.
I would hightlight that the dual licensing in particula introduces the issue of sharing any profits with other maintainers, if there are several. Personally if I'm submitting minor patches I would not bring this up, but it deter people from wanting to be more actively involved.
Depends on the size and scope of your project, I guess.
Even if the CLA somehow said you could only relicense to MIT, they could simply do that without releasing anything, and immediately take it and use it in proprietary things :)
https://github.com/saulpw/visidata/blob/develop/CONTRIBUTING...
Also take a look at GitHub's ToS, which explicitly states that "inbound=outbound" is the default. I don't think you can expect people to hunt down your little notice when there is a site-wide default. https://docs.github.com/en/site-policy/github-terms/github-t...
As someone who has been turned off by many CLAs before, I find yours [1] pretty clear and straightforward.
So maybe you're right but "99% of projects have a CLA in the form of not giving a fuck" is far more accurate.
I've lost many contributions over the insane FSF contributors license workflow. https://www.fsf.org/blogs/licensing/new-contributors-frequen...
I am a one-man shop. I struggle to read code written by others because I struggle to build theory of mind.
So I do not want your contributions. My CLA is supposed to drive you away from giving them to me.
But on the flip side, I also want to be able to give commercial licenses to customers instead of the current AGPL-like license I have. For that, I need a CLA.
I also want to relicense to more permissive ones in the future after I'm established. I also want to release my stuff into the public domain on my death. For that, I need a CLA.
So I apologize, but my CLA is meant to stop you from contributing, but it's also important for making things more permissive later.
On a related note, this is why proliferation of FLOSS licenses is bad - it prevents smooth code sharing between projects. Use MIT, BSD, GPL3, or LGPL and call it a day. I'm still not sure how "compatibility" actually works.
My take is that's still not possible because we dropped the CLA.
In the past it may have been unlikely because the original author offered the solver under paid terms for commercial use and LGPL would allow commercial use without paying. I'm not sure what my own contribution to that part is, but I'd sooner offer GPLv2 as an option over LGPL.
Why is it off the table? Email your contributors and ask if anyone objects. If they object or don't reply, you can probably rewrite the code they contributed, or argue it's too small/trivial to justify a copyright claim. To be blunt, it's extremely unlikely someone is going to sue or even raise a stink over a small contribution. It's more work than if you had a CLA, yeah, but it's not off the table.
> On a related note, this is why proliferation of FLOSS licenses is bad. Use MIT, BSD, GPL3, or LGPL and call it a day.
100% agree.
Part 1: https://jbkempf.com/blog/how-to-properly-relicense-a-large-o...
Part 2: https://jbkempf.com/blog/how-to-properly-relicense-a-large-o...
Part 3: https://jbkempf.com/blog/how-to-properly-relicense-a-large-o...
1) contributed enough code to genuinely have a copyright claim,
2) are still alive,
3) are not easily contactable, and
4) care enough about their contribution to file a legal claim over it.
IMO they could have stopped after the emails and a quick look through the remaining unaccounted-for code for any genuinely significant contributions. They didn't need to go hunt down one guy who changed two characters in a comment ("Quite a few people were surprised that I would mail them ('I only wrote one small commit', 'This was minor code').").
Oh it's not really. If either FreeCAD or Blender devs asked for a drop of the solver under their license I'd take a look to see who we'd need permission from and make some effort. It can't be more than 10 people.
Since we switched to Eigen for the matrix stuff, there would also be a decision on whether to use it prior to that change. It was completely stand alone until then.
Solvespace as a whole will remain GPLv3 though.
There is so little that you stand to gain by agreeing to the CLA (and so much downside for them if they reject it and keep the status quo) that the best thing would be to say no.
And I hope that if they do keep it as-is and then someone comes along later and makes the fix, you hound them about violating your IP and cite their comment "we do not have the rights" as prima facie evidence. Make CLA worshippers bite the bullet on their goofy beliefs.
Luckily, as I wrote, the change is not copyrightable and no one, including myself or my employer, can claim copyright ownership over it.
Right.
> no one, including myself or my employer, can claim copyright ownership over it
People can claim anything they want. Whether they're correct is the thing. I'm suggesting that, since they've articulated a belief that they can't use it without an explicit CLA, you go ahead and yes-and them and play it out both for comedy's sake and the greater good.
Different organisations have different goals when it comes to releasing code as Open Source.
Setting aside universities for the moment, companies (and especially startups) have (hopefully) a strategy which takes their product to commercialism and profitability.
Some projects go OSS purely for the marketing, attracting talent, unpaid labour and so on. But ultimately that means a pivot, and a CLA gives them more pivoting choices. They might cut out some contributers, but at the same time they serve the long game.
If you are wanting to contribute to a project, you, in turn, need to be clear what your goals are, and make sure they are aligned with the -long term- goals of the project owner.
But the same problems arise in most other organizations - it's hard enough to get a legal department to sign essential things needed to keep a business running, never mind signing some random CLA for a project they haven't heard of.
Finally, your view seems oriented to pseudo-open source projects where someone slapped an open source license on code written at a single company and wants to keep control of that code within the company, rather than open projects spanning multiple organizations, run by the developers and architects of the code.
At least that's in my experience. It's significantly easier to not contribute back than spend ages trying to involve legal. Sort of like a barrier to entry, though maybe called a barrier to contribute.
OSS covers a wide spectrum of projects, from the Linux Kernel at the one end, to Frank's recent half-assed attempt at a CSS editor. Clearly no statement is going to cover everything.
The set of projects that require a CLA, and the set of pseudo OSS projects has a high degree of overlap.
[1] https://www.gnu.org/licenses/why-assign.en.html
[2] https://www.fsf.org/bulletin/2022/fall/copyright-assignment-...
https://developercertificate.org
(We have a GitHub action that verifies this, based on another action, based on something by Probot. Ours has been modified to allow automatic DCO certification for people from the company.)
The CLAs I have seen basically boil down to the project maintainers maintaining ownership of the code, ability to adjust the license if desired, and protect them from people contributing code that the contributor doesn't have the rights for.
I have seen projects suffer from single contributors stubbornly refusing to budge on relicensing, even if the relicense would benefit the project.
If I contribute to an AGPL project and sign a CLA that assigns copyright to you, you might announce tomorrow that you are going to run off with my contribution and start only releasing new versions under a non-FOSS licence. This fear applies particularly if you are a for-profit company who might one day lose your desire to do FOSS.
This exact thing, in fact (other than the AGPL part anyway) happened recently with just about every Hashicorp project - so it is not just some hypothetical fear.
I would not contribute (unless I was being paid) to someone else's project unless there was no CLA (inbound = outbound licensing), or they were a not-for-profit with appropriate constitutional limitations on profit-seeking behaviour.
That is generally the point of a CLA. If that bothers you you're supposed to not contribute and not sign. The up side is that that revenue model might mean that they can pay people to do that work instead of relying upon drive by pull requests and maintainers dedicating their time for free.
Back in the early days of open source I saw a lot of people get mad at viral licensing because it did exactly what it was supposed to. There was some weird sort of entitlement complex going on where people felt entitled not only to use open source but that it was somehow unfair that they couldn't also violate the terms and conditions of using it.
I was similarly perplexed by the reaction back then too.
One way is not strictly better or worse than the other. But if a project that has a CLA also has a currently permissive license, then take the supposedly open source route and fork it.
(I am the author of the linked-to article.)
A normal CLA is just making things that are implicit when contributing code explicit. It is a clarifying statement and agreement on who maintains control. So if the complaint is that CLAs force you and your company or institution to be explicit when contributing code, then I'm not sure I understand the complaint.
Still, CLAs are a barrier on their own already. Standardizing them doesn't help. Plus as another commenter mentioned: sometimes a standard CLA is used but then various bits aren't filled in.
Code hosting websites, like GitHub, should provide a mechanism for registered users to electronically sign a CLA from their web interface. No hassle, no unfilled bits, and you've got a 3rd party (e.g. GitHub) notarizing the contract.