2023-08-19
CLAs create different issues than making (small) open source contributions
I've seen a view expressed that Contributor License Agreements are only a small extra piece of formality over contributing bugfixes and other open source changes. I think this is wrong. Often, the decisions that are made over whether or not to contribute changes to open source projects are significantly different than the decisions that must be made over CLAs, such that my university and similar institutions have little to lose from the former and a great deal to lose from the latter.
When I make a bugfix or some other small change to an open source project's source code as part of my work, my university has only two real options for what to with it; we can either keep the change private or publish it under the original open source license used by the project. Since universities are nominally not in competition with each other in the way that companies are and are instead into sharing things with the world, this is an easy and uncontroversial call for everyone to make. There is pretty much no reason not to share such small things.
(In a company, sharing your bugfixes for an open source project may help your competitors who also use the project, so you have some reason to keep them private. For large changes, the code I write might in theory reveal intellectual property that the university would like to keep private in order to patent or otherwise license, and in general might give the university some leverage to negotiate license changes or other things with the project. We have no leverage for small bugfixes or changes.)
A Contributor License Agreement is a legal document and a legal agreement. No institution enters into legal agreements without care, and I am specifically not authorized to enter into such agreements on behalf of my institution; very few people are, and they are all busy and senior. As with any legal document, signing a CLA requires the institution's lawyers to scrutinize the terms to see if there's anything dangerous we're accepting in the process, because a CLA may contain all sorts of surprising clauses and grants that the institution specifically agrees that it's giving the other party. This makes CLAs not anywhere near as simple as 'do we publish this change under the project's open source license or keep it private'. Signing a CLA is not at all the same as publishing a change under the open source license its project requires, especially if the project uses a standard, widely known open source license or a very close variation of it.
(And releasing something under what is fundamentally a copyright grant is quite different from executing a signed agreement with a specific counterparty, who may acquire new legal rights or causes of action against you due to clauses in the agreement.)
It's not at all odd or unusual that it's much easier to do one than the other at my institution. Probably this is the case at any number of organizations. This is a big factor in why CLAs impede modest contributions, even if and when the organization is fully in favour of publishing and sharing such things. One corollary is that it's extremely unwise to assume that someone's failure be able to execute a CLA means that they can't actually publish or share their change.
Requiring a CLA is a strong move by the owner of the project. It says that they would rather have fewer legitimate, fully allowed changes because they wish that all of the changes they do accept to be fully covered by their chosen license agreement (whatever the terms of it are, and sometimes these will include 'we can later relicense your code on any terms we chose, including commercial licenses only').
PS: This doesn't make CLAs intrinsically bad. I accept that there are some organizations that are sufficiently large lawsuit targets that they feel they need to take strong defensive measures, and CLAs are one of those measures. I do feel unhappy when such organizations react to bug reports with 'please write the small patch for us, and by the way you need to sign a CLA'.