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.

There's nothing wrong with this if it's what you want to do especially say if it's for work. But depending on your priorities, it may not be in your best interests.

That's not true. With most CLAs, you retain all rights to your submission. You just give the maintainer a very generous license. I haven't seen a CLA that requires you to give up any rights to your own contribution.

If the maintainer decides to switch to a closed source license, you are free to fork and maintain an open source version with your changes.

This is the difference to copyright assignment. If you produce something as contractor or employee, usually whoever pays for your work owns it, and you can't go and publish your work under an open source license.

Indeed, but submitting a contribution under an MIT-style permissive license grants that entity a very similar set of rights.

Not my experience at all.

> Oracle is practically a textbook example of why this is usually a bad thing for developers/users.

What would have happened differently there if people had contributed under an MIT license instead of signing a CLA?

https://opensource.org/licenses/MIT

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. The GPL differs in that the new work must also be licensed as GPL.

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?

Hopefully they can't relicence retroactivelly, so the previous version of the software stays available, but any following versions can be entirely closed source (but they keep your MIT licence notice).

My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override the MIT license in that way either.

The "without limitation" part of the MIT license guards against this doesn't it?

>The "without limitation" part of the MIT license guards against this doesn't it?

Ah, but it reads "without limitation [...] subject to the following conditions"

MIT already allows sublicensing, so a CLA for an MIT project (assuming nothing else shady is going on) really only buys them the ability to change future licenses to something incompatible with MIT (would that be called superlicensing?), and possibly remove your attribution in future versions.

That to me is philosophically what I want out of a permissive license, so I personally am fine with CLAs in those cases, however I can understand why some would be against that.

Read carefully:

>copyright notice and this permission notice

>MIT already allows sublicensing

IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.

>IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.

Yeah, so a CLA allows that to move to a "superlicense" kind of thing (still not sure if that word makes sense there), so they could rollback those grants or restrictions of the MIT license in the future, but they cannot do so for the past.

Which, I'm okay with in a lot of cases, as that is what I philosophically want from a permissive license. However I can see how many would not be.

Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing.

Also, technically if you don't pay for code the copyright holder can revoke the license at any time. So if you sign a CLA the project can retroactively stop you from using your own code. Unfortunately, this is a major argument for projects to require a CLA in the first place.

I'm pretty sure this is a myth.

The license does have consideration.

You provide some code. The other entity (the project) provides attribution and other things depending on the specific license.

Promissory Estoppel only comes in to play if one side doesn't provide anything of value, and so the bar of consideration isn't met. But to my knowledge, licenses already meet the bar of consideration, so promissory estoppel doesn't matter.

Money isn't the only thing of value. The exchange of one good or service for another good or service is still consideration, no matter what. And "attribution" and "the promise to hold harmless" are of value.

(IANAL and obviously this comes with the usual truck full of caveats that all legal issues do, but this is my understanding of the general state of US law at least.)

There are two issues (at least).

The first is that some such licenses may be "bare licenses". A bare license is a license to use someone else's property that is not coupled with an equitable interest in that property. Bare licenses can be revoked at will unless they state they are irrevocable.

Of course, you could have a bare license, and separate from that a contract with the copyright owner in which the copyright owner agrees not to revoke the bare license, so a license being a bare license is not necessarily a big deal except when it stands alone. I think that such an associated contract is reasonably likely to be found in most cases.

The second, and more serious issue is where does your license come from when you use FOSS software? This, as far as I know, is largely unexplored in the courts.

Let's say I've released Foo under a FOSS license. The license says it is irrevocable. You get a copy of Foo from me. You've got a license to Foo, from me, and it is yours forever.

Now you give a copy of Foo to Bob. Where does Bob's license come from?

There are two possibilities. (1) It comes from me. Whenever you, or anyone else, no matter how many steps removed from me distributes Foo the recipient automatically receives a license from me. (2) The Foo license allows sublicensing, and you use your sublicensing right to create a license for Bob.

The big question is what happens if it some point I announce that I am no longer issuing new licenses.

The sublicensing case is the most clear. Everyone who already has Foo retains they license (remember, I made the Foo license irrevocable). Their licenses allow sublicensing, so they can continue to distribute, giving their distributees a license (which includes the sublicensing right).

Unfortunately only a couple major FOSS licenses, I believe, allow sublicensing (Apache and MIT). Most of the rest either are silent on it or explicitly say it is not allowed (GPL).

So lets assume non-sublicensable Foo...Bob gets a copy of Foo from you after I have purportedly stopped issuing licenses. I sue Bob for copyright infringement. What is Bob's defense?

Note that I am not attempting to revoke the irrevocable Foo license with anyone--I'm just trying to stop create new* Foo licenses with anyone else.

Bob can't really argue that you gave him a Foo license, because the Foo license does not allow sublicensing.

I think Bob is going to have to argue that there is a contract between me and you, and part of that contract is that I will issue new Foo licenses to anyone you give the software to, and by not issuing Bob a license I'm in breach of my contract with you, and that Bob is a third party beneficiary of my contract with you, and has standing to counter sue to enforce my contract with you to issue him a license. But third party beneficiaries only have standing when they are an intended beneficiary, not when they are incidental beneficiaries.

It would be a big, very unclear, mess.

There's not much in the way of substantial requirements that can be effectively included in a non-copyleft license, because to grant rights to end users in ways that will ensure that they can actually exercise them you have to put significant restrictions on the distributor. E.g. the LGPL managed to be "copyleft enough" to be incompatible with app stores, and still offers the end user very little that they wouldn't get from an MIT-like permissive license.

So Linus can all of a sudden say that Linux is no longer GPL?!