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".
>As they say, not all open source is FOSS
This isn't true - you mean "not all open source is copyleft".
>> 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
This is also not true. You should review the open source definition:
>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.
The point is the adjective is commonly used imprecisely, despite a minority’s desire for it to be only used to describe a precise circumstance.
Genie, meet bottle.
‡ 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.
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.
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.
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".
It's like "those people told me that they are free, but I cannot sell them, so in reality they are non-free".
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.
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.
"Customer" implies a much looser relationship, but you should still make sure appropriate contracts defining ownership are in place.
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.
It's not. Let's not muddy the waters that this term was already introduced to further.
I've never seen anyone advocate the term as open-but-not-free beyond those stating it to defend a point.
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?
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.
Digital Ocean explains the difference between free and open-source software: https://www.digitalocean.com/community/tutorials/Free-vs-Ope....
Eliah Kagan answers the question on AskUbuntu with some explanation of the history and plenty of links: https://askubuntu.com/questions/78958/is-there-a-difference-....
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.
Sometimes, CLAs are bad. Oracle loves CLAs. Sun Microsystems loved CLAs. Pretty sure you have to sign one to contribute to OpenJDK now...
Open source licenses can be just awful too. AGPL, for example. CLAs are not an immediate "no," but they should make you ask "Why am I signing this?" If you can't come up with a good reason, fine, don't sign it. But don't for a second think you'll get code into a project run by Oracle without signing one.
There's nothing wrong with this if it's what you want to do especially say if it's for work. But depending on your priorities, it may not be in your best interests.
That's not true. With most CLAs, you retain all rights to your submission. You just give the maintainer a very generous license. I haven't seen a CLA that requires you to give up any rights to your own contribution.
If the maintainer decides to switch to a closed source license, you are free to fork and maintain an open source version with your changes.
This is the difference to copyright assignment. If you produce something as contractor or employee, usually whoever pays for your work owns it, and you can't go and publish your work under an open source license.
Indeed, but submitting a contribution under an MIT-style permissive license grants that entity a very similar set of rights.
Not my experience at all.
> Oracle is practically a textbook example of why this is usually a bad thing for developers/users.
What would have happened differently there if people had contributed under an MIT license instead of signing a CLA?
If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. The GPL differs in that the new work must also be licensed as GPL.
That's pretty meaningless given that there is no obligation to distribute the source code to the new version, or to provide any way that "substantial portions" that are used in the new version can be extracted and used separately from the new-license work.
Meanwhile if you contribute to a currently-MIT-licensed project under a CLA, you have a copy of the current version under the MIT license and can continue to redistribute that indefinitely.
So what practical difference does it make?
Hopefully they can't relicence retroactivelly, so the previous version of the software stays available, but any following versions can be entirely closed source (but they keep your MIT licence notice).
My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override the MIT license in that way either.
The "without limitation" part of the MIT license guards against this doesn't it?
>The "without limitation" part of the MIT license guards against this doesn't it?
Ah, but it reads "without limitation [...] subject to the following conditions"
MIT already allows sublicensing, so a CLA for an MIT project (assuming nothing else shady is going on) really only buys them the ability to change future licenses to something incompatible with MIT (would that be called superlicensing?), and possibly remove your attribution in future versions.
That to me is philosophically what I want out of a permissive license, so I personally am fine with CLAs in those cases, however I can understand why some would be against that.
>copyright notice and this permission notice
>MIT already allows sublicensing
IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.
>IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.
Yeah, so a CLA allows that to move to a "superlicense" kind of thing (still not sure if that word makes sense there), so they could rollback those grants or restrictions of the MIT license in the future, but they cannot do so for the past.
Which, I'm okay with in a lot of cases, as that is what I philosophically want from a permissive license. However I can see how many would not be.
Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing.
Also, technically if you don't pay for code the copyright holder can revoke the license at any time. So if you sign a CLA the project can retroactively stop you from using your own code. Unfortunately, this is a major argument for projects to require a CLA in the first place.
I'm pretty sure this is a myth.
The license does have consideration.
You provide some code. The other entity (the project) provides attribution and other things depending on the specific license.
Promissory Estoppel only comes in to play if one side doesn't provide anything of value, and so the bar of consideration isn't met. But to my knowledge, licenses already meet the bar of consideration, so promissory estoppel doesn't matter.
Money isn't the only thing of value. The exchange of one good or service for another good or service is still consideration, no matter what. And "attribution" and "the promise to hold harmless" are of value.
(IANAL and obviously this comes with the usual truck full of caveats that all legal issues do, but this is my understanding of the general state of US law at least.)
There are two issues (at least).
The first is that some such licenses may be "bare licenses". A bare license is a license to use someone else's property that is not coupled with an equitable interest in that property. Bare licenses can be revoked at will unless they state they are irrevocable.
Of course, you could have a bare license, and separate from that a contract with the copyright owner in which the copyright owner agrees not to revoke the bare license, so a license being a bare license is not necessarily a big deal except when it stands alone. I think that such an associated contract is reasonably likely to be found in most cases.
The second, and more serious issue is where does your license come from when you use FOSS software? This, as far as I know, is largely unexplored in the courts.
Let's say I've released Foo under a FOSS license. The license says it is irrevocable. You get a copy of Foo from me. You've got a license to Foo, from me, and it is yours forever.
Now you give a copy of Foo to Bob. Where does Bob's license come from?
There are two possibilities. (1) It comes from me. Whenever you, or anyone else, no matter how many steps removed from me distributes Foo the recipient automatically receives a license from me. (2) The Foo license allows sublicensing, and you use your sublicensing right to create a license for Bob.
The big question is what happens if it some point I announce that I am no longer issuing new licenses.
The sublicensing case is the most clear. Everyone who already has Foo retains they license (remember, I made the Foo license irrevocable). Their licenses allow sublicensing, so they can continue to distribute, giving their distributees a license (which includes the sublicensing right).
Unfortunately only a couple major FOSS licenses, I believe, allow sublicensing (Apache and MIT). Most of the rest either are silent on it or explicitly say it is not allowed (GPL).
So lets assume non-sublicensable Foo...Bob gets a copy of Foo from you after I have purportedly stopped issuing licenses. I sue Bob for copyright infringement. What is Bob's defense?
Note that I am not attempting to revoke the irrevocable Foo license with anyone--I'm just trying to stop create new* Foo licenses with anyone else.
Bob can't really argue that you gave him a Foo license, because the Foo license does not allow sublicensing.
I think Bob is going to have to argue that there is a contract between me and you, and part of that contract is that I will issue new Foo licenses to anyone you give the software to, and by not issuing Bob a license I'm in breach of my contract with you, and that Bob is a third party beneficiary of my contract with you, and has standing to counter sue to enforce my contract with you to issue him a license. But third party beneficiaries only have standing when they are an intended beneficiary, not when they are incidental beneficiaries.
It would be a big, very unclear, mess.
There's not much in the way of substantial requirements that can be effectively included in a non-copyleft license, because to grant rights to end users in ways that will ensure that they can actually exercise them you have to put significant restrictions on the distributor. E.g. the LGPL managed to be "copyleft enough" to be incompatible with app stores, and still offers the end user very little that they wouldn't get from an MIT-like permissive license.
So Linus can all of a sudden say that Linux is no longer GPL?!
> I did not say that, nor do I believe it, nor is it really related.
Not even Stallman believes this . He has even explicitly endorsed the use of a "lax license" when pragmatic concerns justify it .
Sorry for putting words in your mouth, but that's kind of how it came across as I read it.
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?
I think the idea was: I have my code contributed under BSD, so you cannot re-license my code without clearance from me.
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.
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.
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.
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.
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.
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)
In such event, you can still distribute the existing source code, or fork the project in order for it to remain BSD-only.
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.
> 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?
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.
Does FSF copyright assignment count? They do that on many of their projects (including Emacs).
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.
This is not how anyone I have ever talked to thinks about it. You are probably confusing Free Software with open source software. 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
> 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.
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:
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.
Perhaps you missed the "qua FOSS"? This is latin for "because it is", in this context "contributing to FOSS because it is FOSS".
the osd guarantees the relevant right for an individual to change the software. if you apreciate this right, then you should work to preserve it.
Can you provide a quote where he says or implies such a thing?
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.
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.
It's exactly the opposite: All Free Software is open source, but not vice versa .
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.
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.
> : 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.
 Khan Academy CLA: https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KX...
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.
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).
If you need legal advice for your specific project and situation, speak to a lawyer.
> 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.
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's unlike CLAs as described in the article.
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.
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.
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.
It's the FSF's commitment (mentioned upthread) to not do that which arguably makes it safe to sign a CLA with the FSF.
We can generally trust the FSF not to, but copyright gives you that right.
Edit: thought I was on a different thread. You're right on this one.
Term 2 of the CLA just defines inbound=outbound for Term 2 of the License (https://www.apache.org/licenses/LICENSE-2.0).
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
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.
It opens the door for fun things like : https://lwn.net/Articles/694890/
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.
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.
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.
Therefore the fact that one of the most extreme software freedom organizations out there argues for copyright assignments is very telling.
Or, to echo Drew DeVault somewhat: Don't sign cheques made out to you as the payee.
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.
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 politely told them I don't do CLAs. I checked a few weeks later and the passwords were still posted.
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.
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.
Actually, it serves two main purposes :
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.
(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.
 bradley kuhn wrote a much better article than this one (no offense to the author here!), though i disagree with bradley's view :P - https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
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...
As far as I can see DCO is more lightweight but doesn't allow relicensing like CLA.
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.
> 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 think the fundamental legal mechanism of cross-licensing is correct, but the quorum-vote-like solicitation mechanism needs more thought and feedback.
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 article should make it more clear that the same warning also should apply to digital signatures and agreements in their various forms.
No. Random fringe anonymous emails from non-contributors claimed (incorrectly) that developers could do so.
See https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocabil... and https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x... for details (incorporating actual legal analysis).
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.
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." - https://en.wikipedia.org/wiki/Good_faith_(law)
So the question is, are they acting in bad faith if they attempt to use a CLA to subvert the open source license?
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.