> I did not say that, nor do I believe it, nor is it really related.
What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments against signing a CLA apply equally to contributing to non-GPLed software projects.
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.
It entirely depends on the CLA. But the CLAs I've seen referenced generally only do one thing: give the entity who issued the CLA the rights to do pretty much whatever they want with your code (one key right is often the ability to go closed source or otherwise re-license the work without the author's permission) while usually granting the author no additional rights or consideration. It is often as close as you can get to assigning copyright without actually assigning it (i.e. you're still the author but you've pretty much given up your rights to you contribution)
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.
> you've pretty much given up your rights to you contribution
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.
> the CLAs I've seen referenced generally only do one thing: give the entity who issued the CLA the rights to do pretty much whatever they want with your code (one key right is often the ability to go closed source or otherwise re-license the work without the author's permission) while usually granting the author no additional rights or consideration.
Indeed, but submitting a contribution under an MIT-style permissive license grants that entity a very similar set of rights.
The difference is that the author was aware of that grant at the time they contributed the code since it was implicit in the license. CLAs are often essentially a way to backdoor additional grants after the fact without the original author's permission.
How so? If anything the CLAs I've seen are much more explicit that your code may be distributed as part of a future closed-source version of the project than, say, the MIT license is.
With all of the well-known open source licenses, it's generally clear to the author up front what rights they are granting. With CLAs they are usually fuzzy by design: maybe the rights will be used to go closed source, maybe to sue anther entity, etc. (it generally depends on what's in the best interest of the entity who wrote the CLA) Sure, they're explicit in the sense that they say 'we can do pretty much anything we want down the road' because they have to... that's the point of the CLA: to grant the authoring entity the right to make decisions down the road without consulting those who contributed. Oracle is practically a textbook example of why this is usually a bad thing for developers/users.
> With all of the well-known open source licenses, it's generally clear to the author up front what rights they are granting. With CLAs they are usually fuzzy by design
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?
The GPL family of licenses certainly provides the strongest guarantees to the contributor. But let's consider a "weak" license like MIT. Here's the text to refresh your memory:
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.
> 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.
The majority contributor(s) (i.e. those that are making you sign the CLA) can relicence their contributions, and keep your tiny contributions MIT licenced.
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).
If i'm reading you right, the implication is that if you sign a CLA for an MIT license codebase, they could retroactively close-source your code contributions?
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?
By assigning copyright to them, you give them the right to distribute your work under a different license. Yes, you can't take back the original license from the older code. But they could start distributing the code without respect to the original license.
>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"
Yes, but those conditions start and end at requiring attribution.
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.
Sorry, that is what I meant by attribution (which is defined as the copyright and license in MIT).
>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.
What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself?
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.
IANAL but I think it is a grey area. Licenses are contracts, and contracts usually require "consideration", but there is also something called "Promissory Estoppel"
which may nullify that. I found out about it from someone on here a while back and went down a rabbit hole googling it.
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.
In addition to that, "consideration" doesn't have to mean "money" — in fact, consideration usually won't be monetary on at least one side of the contract (e.g. if I offer you $5 to mow my lawn, the lawnmowing is consideration). If your license requires people to give you attribution, that could reasonably be viewed as consideration.
(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.)
The consideration with open source licenses is often authorship credit / promotional. It's not terribly different than a band giving away MP3's of their music: maybe they want to share their music with the world, maybe they want you to buy a ticket to their concert, but they are getting something out of it and are free to give away something if they have the rights to do so.
That if you don't pay the license can be revoked at any time is probably indeed a myth. On the other hand, there is a chance big enough to worry about that many FOSS license could in fact be revoked by the copyright owners for other reasons, or if not revoked have distribution greatly hindered.
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.
> Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing.
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.
I was specifically thinking of attribution. If you make a significant contribution, you probably have your name, or your company in the copyright notice for that code. the BSD license requires that to be with all copies no matter the end user license.
IANAL, but this is a generalization and not true in all cases. I think they might be able to try to force you not to use your own code if, and only if, the CLA requires you to assign copyright to the project. I think it would still be on shaky ground, as you could reimplement what you did and be fine. You as copyright holder have the right to re-release code you solely hold the copyright to under any license. I will sign a CLA that requires me to affirm I have the right to contribute the code, but I will not sign one that requires me to assign copyright, unless I am getting paid (in which case it becomes a work for hire).
Each contributor may only re-license their contributions independently. If there's any of Linus's own work left in the kernel it would have to be rewritten should he decide that he was fed up with RMS and was going to take Linux closed source. ;)
This is not accurate, you can not retroactively re-license distributed code, only code you distribute going forward. No code would need to be rewritten.
What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments against signing a CLA apply equally to contributing to non-GPLed software projects.