Don’t sign a CLA

A blog post of mine arguing for CLAs:

https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sha...

My post responds to a different blog post. Some of the arguments here are different.

Here, I can't help pointing out two minor vocabulary issues.

A "Contributor License Agreement" does not usually transfer ownership of copyright. We call documents that do "copyright assignments", and they require special formalities. There are some strange hybrids, like CLAs that assign joint ownership of copyright, but they're the exception. Most CLAs that I see are merely additional license grants from contributor to project steward or BDFL.

"Relicense" gets misused and misunderstood all the time. It's very rare to see anyone try to change license terms for code already released under an open source license, and distributed to others. There are legal questions about whether this is possible or practical. And as I recall, Redis Labs didn't try to do that, but only changed the terms that will apply to new work on select Redis add-ons, going forward. In other words, they changed the terms they'll use for future work.

We sometimes say "relicensing" when we mean "dual licensing" or "offering the same code on different terms", rather than changing the one-and-only set of terms that apply to software. The former describes what companies do when they steward a project under a common open source license, often GPL or AGPL, but also sign business deals that include traditional, proprietary-style license terms. Often, such licenses omit requirements to preserve copyright notices from developers, and also copyleft requirements. At the same time, business-to-business licenses are often more restrictive in other ways, like limiting to internal business use, prohibiting reselling, seat-limiting, and so on.

CLAs often give corporate stewards the more permissive licenses they need to sign those kinds of terms with customers. In that sense, CLAs make possible the business model that supports the company stewarding the project.

CLA's basically do one thing: Protect the company using them from being sued by a contributor, or from being sued if a contributor copy pastes copyrighted code into the project. They're there to protect corporations that have outside contributors to projects they build and sell, typically. Sometimes, they're fine, like if you signed one to work on some obscure Linux driver for an obscure hardware item: the hardware company might want an outsider to write it, but still need legal protections since the person basically wandered in off the street from their legal departments view.

Sometimes, CLAs are bad. Oracle loves CLAs. Sun Microsystems loved CLAs. Pretty sure you have to sign one to contribute to OpenJDK now...

Open source licenses can be just awful too. AGPL, for example. CLAs are not an immediate "no," but they should make you ask "Why am I signing this?" If you can't come up with a good reason, fine, don't sign it. But don't for a second think you'll get code into a project run by Oracle without signing one.

> 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.

That's pretty meaningless given that there is no obligation to distribute the source code to the new version, or to provide any way that "substantial portions" that are used in the new version can be extracted and used separately from the new-license work.

Meanwhile if you contribute to a currently-MIT-licensed project under a CLA, you have a copy of the current version under the MIT license and can continue to redistribute that indefinitely.

So what practical difference does it make?

This goes both ways. Don't remember specifics, but contributors trying to "revoke" their license to destroy a FOSS project is about as common as a company trying to use your contributions in a only non-free version.