It's a great point to be aware of, but the title and the tone implies that you as a contributor should be a FOSS maximalist.
As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications.
When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.
> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. I will save that for the parts of my life where it makes sense - I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil. If I believed that, I wouldn't be working on a closed-source project in the first place and then this piece would be fully relevant.
A much better title would be "Why I don't sign CLAs" or "The dangers of signing CLAs".
>I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil
I did not say that, nor do I believe it, nor is it really related.
>When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.
This is definitely a valid position to hold, and I have signed CLAs on behalf of my employer before for this very reason. I suppose my article is targeted more at people contributing in their spare time, and to discourage maintainers from adopting a CLA in the first place.
> This isn't true - you mean "not all open source is copyleft".
Yes it is, and I'm not sure the commenter does. Software may be free but not open-source, and it may be open-source but not free. The term "free and open-source" signifies both.
> This is also not true. You should review the open source definition:
That is not the definition of open-source (or even "open source"), a common term for software the source code of which is available; it is the Open Source Definition, a copyrighted work published by The Open Source Initiative.
Contrary to the confusing rhetoric of the Open Source Initiative, they have no claim on how anyone uses common words in the English language like open and source. Putting the two together is trivial. Open-source is an adjective referring to the fact that that source code is available. It need not refer to some particular organization's ideology.
Reality admits shades between Humpty Dumpty being right‡ and the Prescriptivist utopia where some ivory tower decides how language works.
‡ In "Through the Looking Glass" Humpty Dumpty asserts that "When I use a word, it means just what I choose it to mean—neither more nor less".
So it matters whether it's, say, one pundit who thinks "Source code available to certain parties under license" (e.g. Microsoft Windows has been handled this way in the past) counts as Open Source, or so common that you can find dozens of erroneous examples in every major software publication of the last five years.
People writing "free reign" when they mean "free rein" might be unsalvageable at this point, whereas people saying "backslash" when they mean a forward slash - probably we can still say those people are just wrong and need to sort it out.
> despite a minority’s desire for it to be only used to describe a precise circumstance.
The vast majority of the software industry uses "open source" correctly. A small minority of people and companies with a vested interest in sowing confusion to promote their "source available" business models misuses the term and creates FUD.
This wasn't really my experience... I went to school for CS, which involved using a bunch of open and closed source tools of different kinds. I wasn't aware of the distinctions between different kinds of open source, some of which fell within the OSI definition and some of which did not, I just knew that closed source stuff where I couldn't read the source was more annoying when things went wrong. I remember the moment much later when I realized that there was this whole (weird, to me) turf war over the definition. It still seems to me that the most straightforward definition of "open source" is just any software for which the source code is available (such that it is open, like a book).
This confusion/imprecision is only common among non-technical people. When a software project describes themselves as open source, in the overwhelming majority of cases they actually mean this https://opensource.org/osd-annotated
> Software may be free but not open-source, and it may be open-source but not free.
Free and Open source software are basically mean to be synonyms, the latter being put forth by people to eliminate the ambiguity in English about the use of the word Free.
The "free" in "free software" means libre software, not gratis software.
The fact that "free" in this context means libre is precisely why "free" and "open-source" are distinct concepts, and why you can have something that's "open-source but not free", and even "free but not open-source" (which in this case would basically mean you have a binary rather than source, but you're free to do whatever you want with it; you don't have the source so it's a lot harder to modify, but not impossible, and if you did modify it you'd be perfectly free to distribute that or relicense it or whatever else you want). I know the GNU defines "free" as requiring access to the source code, but that's just their opinion.
Tangential rant: "Copyleft" licenses aren't actually free. The GNU claims they are, that the restrictions that copyleft licenses add don't conflict with the "central freedoms" but simply protects them. But they do restrict my freedom. If a piece of source was truly free, I should be allowed to make significant modifications and sell the resulting software (without giving out the source). Copyleft expressly prohibits this. I get that the GNU is dreaming of a utopia in which all software is open source and "free" and nobody ever makes closed-source software or charges for software. But we don't live in that utopia, and we probably never will; the closest we'll come is when we hit a post-scarcity society and do away with money, so no more keeping software closed-source in order to sell it, but there will still be reasons to keep software closed-source other than wanting to charge money for it. But I digress. The point is, Copyleft licenses rather significantly restrict my freedom as a developer. I'm not trying to debate as to whether or not that restriction is a good thing, just taking issue with calling the result "freedom".
But Copyleft license significantly increases my freedom as a developer. I can develop software for customer#1, then use same software with customer#2, and so on. It's free.
It's like "those people told me that they are free, but I cannot sell them, so in reality they are non-free".
You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too. The question isn't "does the license enforce that the source must be distributed", it's "will the customer allow me to release the work as open source to begin with". About the only way Copyleft applies here is if you can make a strong case that the work customer#1 wants you to do necessitates (or would be much more expensive without) using a piece of copyleft-licensed source, and therefore the whole work must be covered under a copyleft license. But as a developer with a long work history I've never hit that case, or personally know anyone who has.
Really about the only scenario I can think of where I'd reasonably expect to hit this case is if I were tasked with building the software stack for some kind of appliance that would be greatly simplified by throwing Linux on there. And even then, the custom software running as a process on the box would presumably not have to be Copyleft-licensed, just any changes to the Kernel or any other bundled GPL'd software would have to be made available (if in fact there are any changes), and if GPLv3 is involved then the box would have to have some way for the user to replace the software (but the Linux Kernel is GPLv2 so that may not be an issue).
Barring that scenario, if your idea is "I'll develop something for customer#1 and slap the GPL license on it, then customer#1 has no choice but to release the source and I can reuse it for customer#2", unfortunately that's incorrect. Work done for hire is owned by the employer, not the employee, so you can't slap the GPL license on work you do for customer#1 unless customer#1 authorizes it. And in fact if the entire work is built in-house (rather than pulling in GPL'd libraries), then it doesn't even matter if you claim that it's GPL'd because the customer would be the sole copyright owner and would be able to relicense it. The only reason they couldn't relicense it is if it pulls in third-party GPL'd code or libraries, but if I were customer#1 and I hired a developer who pulled in GPL'd libraries without permission in order to try and force the entire work to be released as open source, you can bet I'd be firing that developer on the spot.
> You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too.
No, I cannot. Work done for hire is owned by the employer, not the employee. But, if employer chose GPL-covered software, e.g. Linux kernel, then he is forced to release code under GPL, so I can develop my code, e.g. kernel module for customer #1 and then use it with customer#2, because GPL protects my freedom. I don't need to reinvent the wheel, like with proprietary code.
If the employer chooses any open-source license whatsoever then you can use the code with the next customer (assuming the next customer is ok with the license). There's nothing special about Copyleft licenses there. Well, except for the fact that a Copyleft license is far more likely to have customer#2 say "no you can't use that, it's GPL, are you crazy?"
It does seem though that the majority of uses of "open source" describes Free Software. This is in line with the origins of the phrase as well - it was created to remove the confusion stemming from the adjective "free":
>That is not the definition of open-source (or even "open source"), a common term for software the source code of which is available; it is the Open Source Definition, a copyrighted work published by The Open Source Initiative.
This is blatantly false. You will find it very difficult to find any respected authority whose definition of open source differs from the OSI's definition.
I agree. Regardless of what GP's feelings on the matter are, Open Source is a proper and well-defined term that was originally used as a way to sell open software business models to high-level execs.
I've never seen anyone advocate the term as open-but-not-free beyond those stating it to defend a point.
> Software may be free but not open-source, and it may be open-source but not free.
Other than version 1 of the Apple Public Source license, which is considered open source but not free (and also now entirely unused), what cases are you thinking of?
There are specific controversies; take GNU vs OSI. GNU elaborates the differences on their site: https://www.gnu.org/philosophy/free-software-for-freedom.en..... I couldn't find OSI's take on their website, other than a general lack of reference to GNU/FSF's idea of Free Software.
Then there are disagreements on specific licenses. OSI approves licenses GNU does not classify as Free, and GNU classifies licenses as Free that OSI does not approve.
Then there's GitHub, which publishes a site to help you "choose an open source license," which includes a license not approved by OSI (the Unlicense), and only makes a reference to OSI as an "additional resource". Likewise, GitHub lists FSF as an "additional resource," while consistently using the term open source, not free, and not free and open.
In the past I've run into projects where the source was on GitHub where you could compile yourself, but binaries needed to be purchased. Lemme see if I can find it
It's shared source, behind a register wall. You can clone the git tree and privately hack to your heart's content, but commercial usage and sharing of the source are under (fairly reasonable) particular rules.
They did not. Simon Phipps, President of OSI, not only admits as much but provides a link in his blog that proves the point: https://opensource.org/blog/18418.
> 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.
To have contributed under BSD means that you have contributed under a license that permits relicensing. To contribute under the "BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license.
If you want to contribute under your secret license, what it means is that you don't want to spend any time in the first place contributed to the BSD-licensed project. Make your changes and use them, but don't contribute them back. The BSD license permits this fully, including your ability to distribute and sell the resulting software, subject to the advertising clause as appropriate. So it's not like there's anything onerous about this idea.
"BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license.
I understand what you're saying, but even if you do release BSD software along with code under a different license, you are still bound by the (very minimal) requirements of the BSD license.
That’s a bizarre idea. If you don’t want people doing things the license allows, don’t contribute under that license. If you don’t want people relicensing your code without your specific permission, then the BSD license is not the one you want, and you shouldn’t contribute to projects that use it.
Actually, it is you that have the bizarre idea. BSD licences do not permit people relicensing code without permission of the copyright holder. Copyright licences cannot do so. No copyright licence could do this.
To do this, the actual copyright ownership has to be transferred. A copyright licence is a grant of permission by a copyright owner who retains that ownership. It is not a transfer of ownership.
You don't need ownership to relicense. You just need a license which permits relicensing, which BSD does (as long as the new license is compatible, and they usually are).
It does not permit relicensing. You may use it in an aggregate work with other pieces that have a different license, including proprietary or GPL, but that does not mean your code is relicensed.
1. Its a good idea, if you are going to use licensed code that you have an understanding of the law and what it actually means when you use other people's code.
2. As the code is not relicensed you have to follow the terms. Generally for example even BSD licensed code (other than BSD0) requires that you include attribution both in source code and binaries or documentation, so you need to keep a full list of licenses and authors and list them out in the docs.
You can't take the code as-is and turn it into proprietary code. You need to build a derivative work that contains the permissive code plus some other proprietary stuff.
No, but I would be just as upset if I wouldn't have done that contribution.
There is no way they can change the past - my contribution is still open source and so is the project up until the version where they introduced the license change. The version I made my contribution to is still BSD but the current upstream master might not be.
Yes, but now that version is quickly becoming stale, growing CVEs and perhaps becoming incompatible with the new upstream, with a community left in disarray that more often than not fails to support a fork.
Software goes stale all the time for many reasons. If you're not prepared to fix it or replace it yourself, you really shouldn't be using it.
In my experience, a lot of the projects with large numbers of CVEs also have a rather sprawling project with lots of things that can (and should) be disabled if they don't apply to your environment; most of the CVEs will happen in parts you don't use. (That's clearly not the case for all projects, openssl is a joy to have as a critical dependency, but there are some options now)
I don't see how a CLA materially affects this possibility, though. If my company sponsors a BSD-licensed open source project without enforcing a CLA and then decides that starting with the next major version, we're taking it closed source, the exact same thing you describe is just as likely to happen as with a CLA -- the deciding factor seems to me to be whether most of the development activity happening on the codebase is community-driven or driven by paid developers at the company. Conversely, if the community is active and doing a lot of major work already, and there are enough non-company developers with the time, interest, and skill to start and sustain a fork, they're going to do that with or without a CLA.
>But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then?
If you signed a CLA then presumably you're either happy about it or you've just signed a contract you had literally zero understanding of.
If you're more concerned about getting your fix in upstream or the kudos that comes with being a committer to "x project" then yeah, you probably wouldn't mind.
I personally view Microsoft's use of CLAs as a trap that highlights just how disingenuous their "turning over a new open source leaf" was but I don't really have a problem with open source projects using them in general. The maximalist approach to open source would mean a lot of really great open source would never get written. Authors have gotta eat.
>> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
> This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade.
Indeed, I've contributed to one open source project with a CLA, it had an Apache v2 license... So It didn't really seem to make any practical difference to that license. The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to - which seems a little overly defensive but fair enough as Apache doesn't explicitly protect against that.
That said, I don't like the barrier CLAs impose on open source projects. Has anyone seen GPL+CLA in the wild?
> The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to
This is often times called a "DCO" — Developer Certificate of Origin. I think that is a better name for these, as the term "CLA" is very much associated with the controversial copyright reassignment/relicensing clauses.
Mono used to have a CLA to Novell. There were GPL and LGPL parts. It turned out to be beneficial because it enabled Xamarin (made up of mono developers) to acquire licensing rights to redistribute and relicense it after Novell dropped support for the project.
Come on. It's a personal blog. It's understood to be a personal opinion. The title and message is quite fine as-is.
He even concludes: "if you are contributing to open source and you want it to stay that way, you should not sign a CLA."
if, if, if.
I generally agree with you (!), BTW, but the author does a great job justifying the when and why of his own opinion, and I find it sound.
IOW, if I want to contribute back because I don't want to maintain a private fork or spearhead a public fork, I just want to be done with it, totally fine, even by the author's opinion, which is fully qualified with the statement "and you want it to stay that way". This is reasonable and not at all forceful like Stallman.
You are reacting to something that isn't written nor implied.
>This is not the case of all open source licenses.
false. open source is literally just a friendlier name and otherwise rebranding of free software. all open source is free software and all free software is open source. if you are contributing to FOSS qua FOSS, then you want it to remain FOSS. FOSS refers to that software which guarantees your right to change it, so if you are making changes, you clearly benefit from it remaining FOSS.
note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs.
Not all open source is free software. I'm certain there exists code to which you can legally gain access (thus the source is "open"), that is not "free software" (in other words, under a license that has clauses incompatible with "free software").
> false. open source is literally just a friendlier name and otherwise rebranding of free software.
This is not how anyone I have ever talked to thinks about it. You are probably confusing Free Software[0] with open source software[1]. If you still hold your point we are arguing semantics and stating that your interpretation (a minority interpretation) is right and that most of the software industry and open source community is wrong.
> if you are contributing to FOSS qua FOSS, then you want it to remain FOSS
Not necessarily.
> note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs.
You're completely right. Important factor to be aware of as a contributor for sure.
"Literally just a friendlier name" is more-or-less the OSI's spin on the split; those remaining with the FSF were concerned about a shift of focus away from principles. (With the obvious caveat that these are generalizations about a lot of individuals.)
But in practical terms, "free software" and "open source software" as used by the FSF and the OSI describe the same set of software. Consider their respective license lists:
Your sources contradict your premise. The core tenants of the two are the same; many of those who prefer the term "Free Software" do so because the term "Open Source" implies that providing the source code is all that's necessary, but at least "Open Source" as used by the OSD is synonymous.
OSI #5-10 are kind of a spelled out form of Freedom 0
OSI #2 maps pretty much directly onto Freedom 1 (The title of OSI #2 just says source code, but the body text specifies more)
OSI #1 is Freedom 2
OSI #3 maps to Freedom 3, with #4 being a clarification of what is allowed.
I interpreted the comment above as speaking of Stallman's positions, not the author's. I still suspect that's the case, although I now see that there's ambiguity I missed on first read.
I did refer to rms with "he", as I found it hard to believe rms would refer to non-GPL Free Software licenses as "evil", but the OP already admitted it was a straw-man either way.
> When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.
And this, regardless of how you weigh the post's other objections to a CLA, is a very good reason to sign one for many contributions.
> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
This is not the case of all open source licenses...
Wrong. FOSS = Free Open Source Software, which is really redundant, because all Open Source Software is Free Software. Open Source is essentially the marketing branch of Free Software. The Open Source Definition, and the Four Freedoms are basically the same thing. The only difference is that Open Source cares more about being practical, and Free Software is trying to save the world.
EDIT: I am always surprised by the number of people on HN who seem to not understand this. I know there has been a push the last 10 years or so against copyleft, and specifically the GPL. I didn't think it extended to forgetting what these words in our industry actually mean.
I never heard of the “Open Watcom” license before. But if it really does not allow modified copies to run locally then it is violating criteria 1, and 3 of the Open Source Definition. I am surprised the OSI approved it.
As you can see, it says the opposite. Per §2 you must publish your modified source if you deploy it per §1 in ways including "any and all internal use or distribution of Covered Code within Your business or organization except for R&D use and/or Personal Use".
Richard Stallman dislikes the idea of being forced to publish source code when the modified application is being published internally within a business. Ironically, and rather confusingly, being required to publish source in such additional circumstances he deems "too restrictive", right after calling open source licensing "looser" than free software. (Pick one direction for the metaphor and stick with it, M. Stallman. (-:)
This oddity comes about because freedom is also the freedom to not give one's software source code to other people. Whereas the Sybase licence makes it mandatory to publish modified source even when the compiled modified software is not being given to the public at large.
It's not hard, furthermore, to see why terms that require giving people the source code in more circumstances remain compatible with the principles of open source.
I guess it really comes down to Criteria 1 of the open source definition being worded as "...shall not restrict any party from selling or giving away..."
But this is surely an oddity. It's almost like someone went out of their way to come up with a license to prove they're different.
I think it depends entirely on the purpose of the CLA. Different licenses say different things. Some merely assert that the signer is contributing under the license under which the project is distributed. (Although you may consider it obvious, I am not aware of any existing case law in the US that asserts that submitting a patch necessarily comes with a grant of license to the copyright. And I can guarantee that there isn't case law in every jurisdiction around the world.) Other CLA purposes that seem reasonable to me include a guarantee that IF the contributor has a patent on the submitted code then a license to use that patent is granted to all users of the software.
Even if the CLA does contain text granting some organization which manages the code the right to re-distribute under some other license, I may well be comfortable with that. Sometimes projects choose to move to a new license (GPL v3 wouldn't exist without this). Sometimes a company chooses to offer commercial licenses in addition to free ones. My willingness to contribute under these conditions comes down to the degree to which I trust the organization (realizing that the organization may change, but that almost no human endeavor can be achieved without some level of trust).
On the other hand, if YOU wish to refuse to sign CLAs, you are certainly welcome to do that. But do not be surprised if some organizations reject your offers to contribute patches.
> [1]: You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
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.
Hi, I run an open source project and it has a CLA. I chose a fairly permissive one (contributors retain ownership/copyright), however it does allow relicensing. One of the main reasons I chose to do this is:
1. I have a put a lot of time into the project. More than anybody. Years of work. At some point, I'd like to be able to make money off of it, and relicensing will give me that option (enterprise installations and all that).
2. iOS. The GPL, from a lot of what I've read, is incompatible with the Apple store. If you want to release a GPL-licensed app on iOS, you need to be able to relicense it. Please prove me wrong here, but I think this is a big deal.
Here's my take. If I ever want to make the project completely closed, the last GPLed version is still available and able to be forked or continued. I can't erase the project from the face of the earth, which is kind of what the author seems to be suggesting.
Secondly, if I was starting a project that blossomed with the help of hundreds of contributors, I'd be much more likely to not want a CLA. That said, this is my project. Sure, anyone can fork it and do what they want with it, but I am the one creating it. And at some point, I want that to pay off. My choice of GPL is not to protect contributors, it's to protect the users. The CLA lets me have a restrictive license while giving me the freedom to relicense as needed.
If that keeps you from contributing, no hard feelings. But having a CLA lets me navigate a lot of issues that would otherwise keep me up at night (or make me not want to maintain the project at all).
Pieter Hintjens makes a similar argument in Social Architecture, describing ZeroMQ's community guidelines:
> All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
> Here we come to the key reason people trust their investments in ZeroMQ: it's logistically impossible to buy the copyrights to create a closed source competitor to ZeroMQ. iMatix can't do this either. And the more people that send patches, the harder it becomes. ZeroMQ isn't just free and open today--this specific rule means it will remain so forever. Note that it's not the case in all MPLv2/GPL projects, many of which still ask for copyright transfer back to the maintainers.
As far as I understand, not as such, but you can transfer all rights to another. That's how copyright from employee to employer works in Germany AFAIK. So practically it ends up being the same in nearly all cases.
Pretty much. Pedantically speaking, you can't transfer all rights. Urheberrecht always stays with the author. But Urheberrecht isn't copyright. (Over)simplified, it codifies who owns the copyright of a work initially, and that owner can transfer the copyright.
They do, and I believe it's because it gives them a better platform from which to pursue GPL violation claims. I think that's basically sensible and an exception to OP's general statement -- if you're contributing to an FSF project, you need to understand that what you're doing is political as well as technical. You're giving FSF more ammunition with which to enforce copyleft. FSF is an exception to the concern that the asignee of your copyright is going to do a proprietary relicensing.
That's an odd conclusion to draw from my post. Are you under the impression that OP represents the FSF? He does not. Neither do I. My point is that the general rule that one should be wary of CLAs because they can be used to take away your software freedoms probably doesn't apply to the FSF. A different consideration applies to the FSF -- if you don't like their political goals, don't support them by contributing to their projects.
It figures - the FSF are believers in releasing under "GPLv3 or later", which almost no-one does, as the FSF are of course empowered to do whatever they want with future GPL versions.
"What the CLA is actually used for is to give the project maintainers the ability to relicense your work under a more restrictive software license, up to and including making it entirely closed source."
This goes both ways. It also gives the project maintainers the ability to relicense your work under a less restrictive licence, up to and including making it even more open (eg. from GPL to MIT).
Note that what you contribute will be open source forever regardless of a CLA: as soon as it is released (the open source version your patch is based on, and your open source contribution), the open source -ness cannot be revoked by anyone. A "community fork" from the most recent open source release is always possible, as has been seen multiple times with multiple projects, including those with CLAs.
What the author is really saying is that by signing a CLA you're revoking your claim to what the project maintainers do with the project _in the future_, after they have worked on it some more.
There is, after all, a huge asymmetry here. In a project managed by a major sponsor requiring a CLA, your contribution is probably tiny compared to the work done by project sponsors. In this case, it doesn't seem unreasonable to me for the sponsors to be wanting not to encumber their project with the removal of their ability to take _future work_ on their project closed source (because they were originally the sole copyright holders), just for the sake of a tiny contribution.
Do those tiny contributions add up? I can only think of a few projects when they do, and that's where the ecosystem consists of multiple corporate sponsors (Linux and Postgres come to mind). In most cases where there is a CLA, there is a single corporate sponsor who employs full time developers, and no other developers are contributing full time so the majority of ongoing work is done by the single sponsor. If you want to argue that the CLA is enforcing this condition, then go ahead and fork the project to prove me wrong!
If you're contributing a major component, then sure, you might want to think about it, though even then you're going to get somebody else to maintain that component for you indefinitely if you contribute it.
If you're contributing a minor bugfix, then you're probably hurting yourself (by making yourself maintain that fix forever, or forcing yourself to maintain an entire fork) more than achieving out of principle.
>The Foundation promises that all distribution of the Work, or of any work "based on the Work," that takes place under the control of the Foundation or its assignees, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms.
It goes on like that for a bit, to essentially promise that your software will always stay free (as in freedom).
It also gives you (but not the FSF) the right to use your own code in proprietary software, with 30 days notice.
It limits a lot of contributions, yes. It's certainly "unfree". But I still signed it happily, even if I agree with a lot of op's points.
In my case I need the FSF to defend any evil actions which did happen before with these type of packages (libredwg), and will happen again. I certainly don't want to be at the end of such a lawsuit or infringement claim (like illegally using a trademark), and I'm happy that the FSF will defend us. Even if the external contributions are 10x lower than with a non-gnu project and it's a pain.
Wouldn't your article then more accurately be "Don't sign a CLA without reading it and making sure you agree with what it says", which reduces pretty cleanly to "Don't sign things unless you've read them and agree with them"?
Your overall point seems to be one I agree with, which is "CLAs can be (and often are) used to enable maintainers to make decisions that contributors wouldn't want to be made, and contributors should thus be careful in what they agree to", but in making it an imperative headline it's lost the nuance.
Well, I could make a CLA which asks you to remember to drink your Ovaltine, which would be pretty harmless. But the average CLA is far from harmless, so it deserves special mention to call out these CLAs as harmful.
Some CLAs are worse than others, though, and as people send me examples of supposedly benine CLAs I've been writing up addendums to add to the bottom of the article. There is indeed some nuance here, which I hope to address in that manner.
I can see your point of view, though one nitpick: the GPL doesn't prevent shenanigans any more than an MIT license. With a CLA, the owners can relicense the code as a non-open source license. With both MIT or GPL, you retain the rights to develop the previously released code.
It's the FSF's commitment (mentioned upthread) to not do that which arguably makes it safe to sign a CLA with the FSF.
> What about the Apache Foundation CLA? This CLA is one of the better ones, because it doesn’t transfer copyright over your work to the Apache Foundation. I have no beef with clauses 1 and 3-8. However, term 2 is too broad and I would not sign this CLA.
The Apache CLA is pretty benign (for projects that are distributed under the Apache license; sometimes it is used for projects distributed under different licenses and then it gets murky), but the overhead to contributors and maintainers is significant and it is less precise than a Developer's Certificate of Origin. The "Inbound=Outbound Is All You Need" section of this post is on-point. http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html
> Open source is a commitment to your community. Once you make it, you cannot take it back. You don’t get the benefits associated with being an open source project if you have an exit hatch. You may argue that it’s your right to do what you want with your project, but making it open source is explicitly waiving that right.
I open source things I write, and I love open source but I think this stance is disingenuous.
Yes you should maintain your project in the future so that you don’t leave your users hanging to dry, but sometimes life happens and you can’t continue your open source project in its current form.
With a CLA, the creators of a project that would otherwise be unable to continue the project due to lack of funds can develop a proprietary version that they can earn money from licensing to people. And hopefully they will continue to maintain an open source version that receives bug fixes and some features while certain other features are only developed for the proprietary version.
Demanding that those who make open source software do so under strict conditions will only serve to deter people from making open source software in the first place, IMO.
Certainly it can be frustrating to be a user of a software and have them close the source, but what would the alternative be? Probably that it just died, so for you the outcome would be the same.
Open source is great. It saves time and money by letting people and companies make use of the work done by others to save themselves from having to duplicate the effort. But it is never going to be the case that we can demand that someone else continues maintaining a product for us for free.
When a product goes closed source, from your point of view it should not be much different from had it shut down completely. The last open source version of the product is still available so if someone was goinging to step up and maintain it into the future they still can, and if they weren’t going to, well then it makes no big difference what the original authors decide to do anyway.
Personally the main reason I don’t use CLAs for my projects is that I am using a very permissive license for most of my projects already, the ISC license, and I don’t foresee any situation where I would want to switch to another license for my projects.
And their stated issues are not trivial. I have personally run into a few cases where people thought that they owned their work, but actually it was owned by their employer. I don't have to look very far - it happened to me personally when I lived in New York. (Not entirely coincidentally, I now live in California where it is much easier to retain ownership of any side project that I might happen to do.)
Yes, it is handing them extra power that is abusable. However it is also power that they may have legitimate reasons to want. As with all legal agreements, the real question is what you are afraid of.
No, a copyright assignment is not the same thing as a contributor license agreement. Copyright assignment is in all respects that this article cares about even worse.
Therefore the fact that one of the most extreme software freedom organizations out there argues for copyright assignments is very telling.
Not all CLAs are designed to let the project relicense itself. In particular, some CLAs are there to make the contributors promise that they are not submitting patent-encumbered code which they intend to later assert some rights on. Those CLAs seem like they are fixing up a fundamental unclearness in how patents are licensed in open source software.
> used their CLA to pull along any external contributions for the ride. As thanks for the generous time
Am I the only one that doesn't over-value their own contributions? So many copy-left proponents always bemoan giving your work away. While that may hold some water on some large efforts, in general, who cares if you give away bits of your work? Who cares if you sign it away? Don't get hung up on your personal pride like your contribution is the greatest thing ever, feel free to share and share alike even on projects with caveats to your sharing, even if that means you are guilted by the forced-freedom side of the community. Or don't...but no need to pretend like others are bad for doing so.
I do not agree with the sentiment that all CLA are evil.
Yes, CLA that transfer all ownership to the project are bad. But many CLA are in place to protect the project from bad actors. For example companies suing the project because an employee has submitted code that he wasn't allowed to make public.
I use a CLA in an open source project. But it does not transfer ownership. It just states that the contributor is allowed to make the contributions and accepts the license.
Your father's advice does not scale. Not all legal systems work the same way, and in some having the payee sign one is an indorsement by the payee that makes it payable to third parties (which will be whoever the bearer happens to be for a simple signature, an indorsement in blank). Whereas having the payee not sign checks, and having checks crossed as "A/C payee", are considered the better practices.
Or, to echo Drew DeVault somewhat: Don't sign cheques made out to you as the payee.
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.
Why would people contribute to a project they don't agree to the license of? Isn't it good to discourage contributions from people who don't agree in the first place, avoiding future conflict?
As someone who works at a fairly enlightened big company, it's not too hard to get approval to contribute to an open source project (lawyers confirm the license is ok, and that the project doesn't touch any things that are currently sensitive to touch publicly) and it usually only takes a couple business days, getting approval to agree to a CLA is a fairly big additional delay, especially when they want it signed by the company rather than the individual.
They can agree with the license and disagree with the CLA.
In fact, by requiring a CLA, as a user of the product, you know that they organization behind the code is discouraging contributors. This is not a good thing.
I'm not entirely sure I understand why so many people are against CLAs. I've been active in the open source community since 1996, and am currently employed at a company which is 100% based upon service around open source software, which includes our stewardship of several projects which have significantly advanced the community cause. My employer requires a CLA. It is not written in esoteric legalese, but is rather simple to understand before you sign it. It is designed to protect both you, as the contributor, and my employer.
A CLA is a good thing when it's written well, is not overly onerous, and is being used to further contributions. Here is some basic reasons why a company like my employer may want contributors to sign a CLA:
1. It prevents your heirs from terminating your copyright grants in the future if you pass away or any number of other weird quirks of US copyright law that could potentially result in legal fuckery that you do not intend.
2. It prevents enforcement of patents surrounding code you have contributed against my employer.
3. It indemnifies you as the contributor against expectations of support, guarantee, or warranty for your contribution.
4. It commits my employer to maintenance of your contribution once its accepted as long as it is needed in the code-base.
5. It protects my employer from getting in trouble for contributions where the contributor did not have legal license to offer the contribution, because you are asserting that you have such license before offering that contribution.
Yes, it allows for re-licensing, but in practice what this means is that some or all of the code may be dual-licensed at some point in the future to assist in integration with other open source software projects.
To assert you should never sign a CLA seems short-sighted and unreasonable. I can't speak for every project, but my employer has been a good steward of software in the community and the community itself since the day it was founded and has committed to continuing to do so.
While I can certainly understand that you may not wish to sign a CLA with an organization you do not trust, I don't think refusal to sign should be a default position. Instead, like any contract, you should read before you sign and not enter into agreements with entities you do not trust. Simple as that.
I won't contribute to any open source project with a CLA - which has been a shame for a few open source projects. I caught a serious security vulnerability in one project including them openly posting admin secrets - and privately contacted and let them know, appropriately - only to get back a response of "Can you sign our CLA and help us fix this?".
I politely told them I don't do CLAs. I checked a few weeks later and the passwords were still posted.
I'm sitting on a few custom forks of open source tools (in which I've either fixed a bug or added a feature I needed) which I've more or less kept to myself because the process to contribute back to those projects is just enough of a PITA (due to CLAs and the like) that I can't overcome my apathy/laziness enough to spend the time/effort required to submit my changes and get them accepted.
What about the maintainer's right to not have their hands tied as they evolve a project by one person issuing a custom license on their PR? I agree with your final suggestion of forking off (hah) if you have a problem with the CLA... But it's unwarranted to say a maintainer protecting himself from a huge additional coordination burden is a kick in anyone else's groin.
I've always been under the impression that CLA's are meant to ensure that contributors can not retract their contributions once they've made them. I'd be fine with signing such an agreement. Relicensing other people's work, on the other hand, does seem like a dramatic overreach indeed.
Even if you don't sign a CLA, can't someone take an Apache/BSD/MIT-licensed work and make a closed source form of it? The license effectively just requires them to mention where the code came from. Whether you signed a CLA or not seems pretty irrelevant.
Apache says for example: "You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole [...]".
I think the OP's concern only applies to GPL software, which in my experience is pretty rare at this point.
I agree with the author that a CLA is one sided since contributors are at the mercy of the organization they sign their rights over to. For the open source code a Developer Certificate of Origin (DCO) is more appropriate. I learned this when Debian brought it up https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l...
For our proprietary source available code we do use a CLA since it is a custom license and we want the option to make changes to it in the future.
"What the CLA is actually used for is to give the project maintainers the ability to relicense your work under a more restrictive software license, up to and including making it entirely closed source."
Actually, it serves two main purposes[1] :
1. Protect the project from people who don't actually have the necessary rights to be contributing or wish to retract contributions later.
This is the most common case, and it happens all the time (though essentially all of it is resolved privately due to CLA's).
The law is full of interesting dragons. As a random example: Most open source is also too young, but in ~10-15 years, you will start to see copyright right terminations in the US (https://www.law.cornell.edu/uscode/text/17/203) for projects that have no CLA's.
It's inevitable.
(as is having to deal with the rights of people who are dead, which already happens)
Projects often need to do something to protect themselves over time (regardless of whether it's a CLA or copyright assignment or ...)
2. Protect the projects from patents in #1 when the license does not do so.
(this is also resolved privately)
It also resolves an issue that only has popped up recently, copyright trolling by folks like Patrick McHardy.
Relicensing is a very secondary concern, and mostly comes into play over time because the project screws up or grows larger than it expected.
The boogeyman of "corporation takes away my rights" is a nice boogeyman, but the infinitely more common case is "project screws up because they didn't think about licensing when they started". The number of "corporate relicensings" is vastly dwarfed by non-corporate ones.
One of the more interesting things to me is that the largest mass relicensing i'm aware of was the FSF force-relicensing projects to GPLv3 (sometimes quite against majority-contributor wishes), with no comment or discussion or allowance for dissent. So it wasn't a corporation doing it for whatever, it was a foundation doing it for ideological reasons.
The fact the article tries to make it seem like it's happening all the time is disingenuous at best, and honestly only serves to make the argument weaker (because it's unsupported by data).
I'd also point out a CLA or equivalent is also necessary to move a project from gpl-v2 only to gpl-v3 (IE not "restrictive software licenses") if the project later chose. Otherwise it is stuck in limbo forever.
The answer you usually get from anti-CLA folks is "they shouldn't do that in the first place" which is nice but doesn't actually fit with the fact that most people basically don't pay any attention to license choices in a meaningful way when they start projects. Or make mistakes. You know, one of the reasons we have version control in the first place - so we can change things we got wrong over time.
Even if you could cause them to not make mistakes, or never change viewpoints, you'd still have millions of legacy projects to deal with.
All this article tells me is that the person hasn't run a large enough open source project to have to deal with these in a meaningful way. That's okay.
But i've never found someone who did who has not run into the issues above and eventually moved to CLA's or an equivalent.
I've also spent a lot of time in my life fixing smaller projects that never had one, and then became larger, and then had to clean up the mess. It usually costs foundations/etc a lot of money and time to track down contributors or pull code.
I'd actually love to live in a world where CLA's aren't necessary (and copyright was sane). But pretending we do won't get us there.
Wow, regarding #1 - am I understanding this correctly? Linus's widow or children can revoke his GPL license of his kernel contributions after he dies unless he covers this scenario explicitly in his will?
Edited to add: Seems there's a 5-year window from year 35-40 after the initial license or grant where the license or grant can be terminated, either by the original author or their heirs, but honestly I have no idea if I'm reading this correctly. This whole statutory terminations thing goes way over my head. I cannot parse this document: https://akbllp.com/introduction-and-copyright-overview/statu...
Is it a settled argument that the US statutory termination right applies to copyrights granted by the common open source licenses? Could you maybe point to a good legal discussion of this issue?
In my spare time / hobby projects, I'm ready to don my FOSS advocate hat, but as a businessman and employee, I'm practically ignoring all issues with the lack of F in OSS. Many thanks to those who can afford to live by their ideals even when it comes to earning a living, though, and much respect for being willing to deal with this kind of stuff all the time.
It's not so much signing away your rights as getting something in exchange for something. As you say, you can always fork the project, but very often large projects (that tend to be the ones with CLAs) are also used by companies that rely on them. What you get in exchange for the CLA is your code (written to scratch your itch) becoming part of the mainline, and saving you the trouble of merging with every update. If scratching your own itch is the goal, and if your contribution is small relative to the total project (and it often is for projects with CLAs), then granting the project leaders a joint ownership over copyright is a very small price to pay in exchange for having the leaders take your contribution into the mainline. If, on the other hand, your goal is to shape the project, this usually entails a large number of significant contributions, and if you do that, becoming a part of the leadership or getting a part of the project ownership can be negotiated.
I would rather be able to fix a bug or provide a feature to software my company paid for rather than hoping they'll fix/implement it sometime soon, or building some hack around it, if it makes my life easier.
This seems to be an argument against non-viral licenses than CLAs:
> We’ve seen this happen before. Consider the Redis Labs debacle, where they adopted the nonfree1 Anti-Commons Clause2, and used their CLA to pull along any external contributions for the ride. As thanks for the generous time invested by their community into their software, they yank it out from underneath it and repurpose it to make money with an obscenely nonfree product.
People can already repurpose software with permissive licenses such as MIT, BSD, or Apache 2.0. That's actually the point of those licenses, isn't it?
> In the United States, once you own a copy of a program, you can back it up, compile it, run it, and even modify it as necessary, without permission from the copyright holder.
...
> Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use. ... As long as you're not distributing the software, you have nothing to worry about.
I recently blogged about an alternative to contributor license agreements without any single foundation or BDFL, that cover relicensing of past code to respond to license issues:
I think the fundamental legal mechanism of cross-licensing is correct, but the quorum-vote-like solicitation mechanism needs more thought and feedback.
The point is somewhat ruined by getting major facts about licensing and Redis wrong:
1. It was about proprietary addons, not community version at all.
2. The license of Redis would allow such relicensing of externally contributed code without CLA. Read the damn BSD license, that permissiveness is its whole point.
20 years ago, OSS developers understood their licenses. These days, it seems common that people slam a random license on their code or contribute somewhere with absolutely no functional understanding of the legal aspects.
The reality is some companies simply wouldn't contribute open source projects if they didn't have the flexibility afforded by requiring contributors sign a CLA. Maybe you would consider that preferable, but I don't. They have a right to require a CLA, just as I have a right to not contribute if I don't want to sign a CLA.
Good general advice. I can't say I have a categoric aversion, but the onus is on upstream to honestly and clearly explain the specific circumstances and reasoning for why the license by itself is insufficient for their special needs.
TL;DR: Some (all?) CLAs allow the maintainers to change the license of the code that you contributed, even if that is a proprietary license. The article mentions exactly one example of where a maintainer did that and does not point out what clauses to look for, how many CLAs actually do this, etc.
Have we forgotten the Linux Code of Conduct controversy? Contributors threatened to remove their code from the kernel. A CLA would completely prevent that.
> A CLA is a kick in the groin to a contributor’s good-faith contribution to the project.
I wouldn’t invest in a company that conducts business “on good faith.” That’s well and good in the domain of interpersonal interaction, but is irresponsible behavior from a company, which must do all it can to safeguard its assets and revenues.
And I don’t think I’m being soulless here. A company like Facebook is entrusted with and responsible for many people’s very livelihoods. As a corporation it must not behave casually. There’s no “in good faith” when you have millions of employees and investors.
"Good faith" and by extension "bad faith" are quasi-legal terms. To do business in good faith is to act by the letter and spirit of terms without an intention of attempting to defraud.
As I understand it, someone who acts in Good faith usually has more leniency then someone who acts in bad faith. For instance, I had a friend who upon leaving an apartment building was charged several hundred dollars for maintenance having to replace lightbulbs - she disputed the debt, but the apartment complex attempted to charge her interest on it during the dispute. Because the apartment complex acted in bad faith, not only was the debt canceled, but the apartment complex had to pay out additional damages to her.
A business should act on good faith. That doesn't mean not having legal agreements or being naive, it means following the letter and spirit of laws. You might be able to technically trick someone into letting you steal their open source contributions and sell them, but that would be bad faith.
Wikipedia explains it this way: "In contract law, the implied covenant of good faith and fair dealing is a general presumption that the parties to a contract will deal with each other honestly, fairly, and in good faith, so as to not destroy the right of the other party or parties to receive the benefits of the contract. It is implied in every contract in order to reinforce the express covenants or promises of the contract. A lawsuit (or a cause of action) based upon the breach of the covenant may arise when one party to the contract attempts to claim the benefit of a technical excuse for breaching the contract, or when he or she uses specific contractual terms in isolation in order to refuse to perform his or her contractual obligations, despite the general circumstances and understandings between the parties. When a court or triar or fact interprets a contract, there is always an "implied covenant of good faith and fair dealing" in every written agreement.[1]" - https://en.wikipedia.org/wiki/Good_faith_(law)
I think the point is to assume good faith on the contributer's side, i.e. that they will follow in the letter and spirit of the OS license, so a CLA is unnecessary. Conversely, by putting a CLA in place, the subtext is "I think you're probably a scumbag (=person acting in bad faith) and don't trust the OS licenses used for billions of lines of code, so I'm going to hit you with a CLA preemptively".
As an interesting bit of context, the European legal system skews more towards the spirit of the law, allowing for shorter legal documents/contracts. Whereas the US legal system skews towards the letter of the law, meaning contracts end up being several hundred pages, littered by garbage like "including but not limited to", and things like that.
As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications.
When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.
> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. I will save that for the parts of my life where it makes sense - I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil. If I believed that, I wouldn't be working on a closed-source project in the first place and then this piece would be fully relevant.
A much better title would be "Why I don't sign CLAs" or "The dangers of signing CLAs".