12 ms·

Don’t sign a CLA

455 points by chmaynard 8y ago

_jal 8y ago
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.
madisp 8y ago
But can't you take any MIT or Apache (or similarly permissively licensed) project closed source anyway?
- floatboth 8y ago
  You can make the next version proprietary or whatever, but you obviously can't retroactively revoke the license from released code :)
Legogris 8y ago
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".
- rqs 8y ago
  > the title and the tone implies that you as a contributor should be a FOSS maximalist. 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.
  - Legogris 8y ago
    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.
    - Sir_Cmpwn 8y ago
      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.
      - toast0 8y ago
        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)
      - chipotle_coyote 8y ago
        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.
jcadam 8y ago
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. Ah well.
- nraynaud 8y ago
  I feel you, red tape to report a bug, red tape to send a patch, and then the owner sends you to hell because they don’t owe you anything.
RobertSmith 8y ago
CLA intimidates people to contribute. It discourages contributions
- radarsat1 8y ago
  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?
  - pastage 8y ago
    Coding is fun, signing a document is not. It would take many hours of coding to offset the time it takes to sign a CLA.
  - jasonlotito 8y ago
    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.
  - toast0 8y ago
    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.
linkmotif 8y ago
> 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.
- vorpalhex 8y ago
  "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) https://en.wikipedia.org/wiki/Good_faith_(law)
mcherm 8y ago
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.
- zamalek 8y ago
  Some even protect the contributors: > [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. [1] Khan Academy CLA: https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KXyIj5nKlZzNkOnQG-4A1R7X_BWGTShQ/viewform https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KX...
monocasa 8y ago
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.
- Legogris 8y ago
  Correct me if I'm wrong, but my understanding is that copyright transfer is not even legally applicable in many jurisdictions.
  - monocasa 8y ago
    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.
    - guitarbill 8y ago
      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.
- kevin_b_er 8y ago
  And as a result, ZeroMQ has a bizarre LGPLv3 license with supposed exceptions and claims it doesn't need commercial licensing as a result.
Timshel 8y ago
If you see it from the other side, I completely understand why anyone with a project might not want a random contributor to become an equal. It opens the door for fun things like : https://lwn.net/Articles/694890/ https://lwn.net/Articles/694890/
natch 8y ago
“I never signed anything though... I just clicked submit on an agreement and there might have been a checkbox checked, or not.” The article should make it more clear that the same warning also should apply to digital signatures and agreements in their various forms.
hyperpape 8y ago
An interesting contrast among FOSS maximalists is that the FSF requires a CLA for a subset of its projects: https://www.gnu.org/licenses/why-assign.html https://www.gnu.org/licenses/why-assign.html
- Sir_Cmpwn 8y ago
  I think the FSF gets a pass here, given that the GPL has explicit protections against the negative behaviors warned about in the article.
  - akerl_ 8y ago
    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.
    - Sir_Cmpwn 8y ago
      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.
  - hyperpape 8y ago
    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.
jpablo 8y ago
Wait, Free Software Foundation requires a CLA itself! https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html
- sevensor 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - scrollaway 8y ago
    In other words, "do as I say, not as I do".
    - sevensor 8y ago
      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.
    - yarrel 8y ago
      Anyone can assign their copyrights to the FSF. So no. ;-)
    - deleted 8y ago
      [deleted]
- 8y ago
evmar 8y ago
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.
vorpalhex 8y ago
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.
codetrotter 8y ago
> 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.
trulyrandom 8y ago
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.
rlpb 8y ago
"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.
deleted 8y ago
[deleted]
DannyBee 8y ago
"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 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. [1] 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/ https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
kradroy 8y ago
My father told me long ago: "After you've done the work the only thing you should sign is a check you're about to deposit."
- JdeBP 8y ago
  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. * http://www.legislation.gov.uk/ukpga/1992/32/section/1 http://www.legislation.gov.uk/ukpga/1992/32/section/1 * http://www.legislation.gov.uk/ukpga/Vict/45-46/61/section/34 http://www.legislation.gov.uk/ukpga/Vict/45-46/61/section/34 * http://www.legislation.gov.uk/ukpga/Vict/45-46/61/part/II/crossheading/negotiation-of-bills http://www.legislation.gov.uk/ukpga/Vict/45-46/61/part/II/cr...
2ion 8y ago
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.
lacker 8y ago
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.
kemitchell 8y ago
A blog post of mine arguing for CLAs: https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sham.html https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sha... My post responds to a different blog post. Some of the arguments here are different. Here, I can't help pointing out two minor vocabulary issues. A "Contributor License Agreement" does not usually transfer ownership of copyright. We call documents that do "copyright assignments", and they require special formalities. There are some strange hybrids, like CLAs that assign joint ownership of copyright, but they're the exception. Most CLAs that I see are merely additional license grants from contributor to project steward or BDFL. "Relicense" gets misused and misunderstood all the time. It's very rare to see anyone try to change license terms for code already released under an open source license, and distributed to others. There are legal questions about whether this is possible or practical. And as I recall, Redis Labs didn't try to do that, but only changed the terms that will apply to new work on select Redis add-ons, going forward. In other words, they changed the terms they'll use for future work. We sometimes say "relicensing" when we mean "dual licensing" or "offering the same code on different terms", rather than changing the one-and-only set of terms that apply to software. The former describes what companies do when they steward a project under a common open source license, often GPL or AGPL, but also sign business deals that include traditional, proprietary-style license terms. Often, such licenses omit requirements to preserve copyright notices from developers, and also copyleft requirements. At the same time, business-to-business licenses are often more restrictive in other ways, like limiting to internal business use, prohibiting reselling, seat-limiting, and so on. CLAs often give corporate stewards the more permissive licenses they need to sign those kinds of terms with customers. In that sense, CLAs make possible the business model that supports the company stewarding the project.
hodgesrm 8y ago
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?
jedbrown 8y ago
> 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. Term 2 of the CLA just defines inbound=outbound for Term 2 of the License (https://www.apache.org/licenses/LICENSE-2.0 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 http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html
gant 8y ago
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.
btilly 8y ago
As a counterpoint, read https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html where the GNU project explains why they require copyright assignments. 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.
- JdeBP 8y ago
  Or read https://news.ycombinator.com/item?id=18149011 https://news.ycombinator.com/item?id=18149011 here where it is argued out that a copyright assignment is not the same thing as a contributor licence agreement.
  - btilly 8y ago
    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.
kodablah 8y ago
> 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.
simplecomplex 8y ago
Has any CLA ever been used in court and held up? What are real world examples of CLA’s being enforced in court?
quest88 8y ago
I don't mind contributing to paid software. 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.
lucb1e 8y ago
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.
jpfr 8y ago
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. https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52 https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
kemitchell 8y ago
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: https://writing.kemitchell.com/2018/09/30/Contributor-Councils.html https://writing.kemitchell.com/2018/09/30/Contributor-Counci... I think the fundamental legal mechanism of cross-licensing is correct, but the quorum-vote-like solicitation mechanism needs more thought and feedback.
sytse 8y ago
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-license/ 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.
evrydayhustling 8y ago
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.
IAmLiterallyAB 8y ago
Have we forgotten the Linux Code of Conduct controversy? Contributors threatened to remove their code from the kernel. A CLA would completely prevent that.
- JoshTriplett 8y ago
  > Contributors threatened to remove their code from the kernel. No. Random fringe anonymous emails from non-contributors claimed (incorrectly) that developers could do so. See https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/ https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocabil... and https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4 https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x... for details (incorporating actual legal analysis).
- deleted 8y ago
  [deleted]
tlrobinson 8y ago
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.
orthecreedence 8y ago
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).
- kemitchell 8y ago
  re iOS store, have a look at: https://github.com/signalapp/libsignal-protocol-c#license https://github.com/signalapp/libsignal-protocol-c#license If you need legal advice for your specific project and situation, speak to a lawyer.
tristor 8y ago
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.
nikisweeting 8y ago
I hate both CLAs and DCOs. CMV: it's an unnecessary barrier to contributing for new users that provides no additional guarantees over GPG signing.
pron 8y ago
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.
carapace 8y ago
An obscure but interesting point, by DJB: > 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. https://cr.yp.to/softwarelaw.html https://cr.yp.to/softwarelaw.html
vsl 8y ago
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.

455 points by chmaynard 8y ago

_jal 8y ago

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.

madisp 8y ago

But can't you take any MIT or Apache (or similarly permissively licensed) project closed source anyway?

floatboth 8y ago
You can make the next version proprietary or whatever, but you obviously can't retroactively revoke the license from released code :)

Legogris 8y ago

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

rqs 8y ago
> the title and the tone implies that you as a contributor should be a FOSS maximalist. 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.
- Legogris 8y ago
  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.
  - Sir_Cmpwn 8y ago
    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.
    - toast0 8y ago
      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)
    - chipotle_coyote 8y ago
      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.

jcadam 8y ago

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

nraynaud 8y ago
I feel you, red tape to report a bug, red tape to send a patch, and then the owner sends you to hell because they don’t owe you anything.

RobertSmith 8y ago

CLA intimidates people to contribute. It discourages contributions

radarsat1 8y ago
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?
- pastage 8y ago
  Coding is fun, signing a document is not. It would take many hours of coding to offset the time it takes to sign a CLA.
- jasonlotito 8y ago
  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.
- toast0 8y ago
  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.

linkmotif 8y ago

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

vorpalhex 8y ago
"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) https://en.wikipedia.org/wiki/Good_faith_(law)

mcherm 8y ago

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.

zamalek 8y ago
Some even protect the contributors: > [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. [1] Khan Academy CLA: https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KXyIj5nKlZzNkOnQG-4A1R7X_BWGTShQ/viewform https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KX...

monocasa 8y ago

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.

Legogris 8y ago
Correct me if I'm wrong, but my understanding is that copyright transfer is not even legally applicable in many jurisdictions.
- monocasa 8y ago
  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.
  - guitarbill 8y ago
    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.
kevin_b_er 8y ago
And as a result, ZeroMQ has a bizarre LGPLv3 license with supposed exceptions and claims it doesn't need commercial licensing as a result.

Timshel 8y ago

If you see it from the other side, I completely understand why anyone with a project might not want a random contributor to become an equal. It opens the door for fun things like : https://lwn.net/Articles/694890/ https://lwn.net/Articles/694890/

natch 8y ago

“I never signed anything though... I just clicked submit on an agreement and there might have been a checkbox checked, or not.” The article should make it more clear that the same warning also should apply to digital signatures and agreements in their various forms.

hyperpape 8y ago

An interesting contrast among FOSS maximalists is that the FSF requires a CLA for a subset of its projects: https://www.gnu.org/licenses/why-assign.html https://www.gnu.org/licenses/why-assign.html

Sir_Cmpwn 8y ago
I think the FSF gets a pass here, given that the GPL has explicit protections against the negative behaviors warned about in the article.
- akerl_ 8y ago
  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.
  - Sir_Cmpwn 8y ago
    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.
- hyperpape 8y ago
  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.

jpablo 8y ago

Wait, Free Software Foundation requires a CLA itself! https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html

sevensor 8y ago
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.
- deleted 8y ago
  [deleted]
- scrollaway 8y ago
  In other words, "do as I say, not as I do".
  - sevensor 8y ago
    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.
  - yarrel 8y ago
    Anyone can assign their copyrights to the FSF. So no. ;-)
  - deleted 8y ago
    [deleted]
8y ago

evmar 8y ago

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.

vorpalhex 8y ago

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.

codetrotter 8y ago

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

trulyrandom 8y ago

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.

rlpb 8y ago

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

deleted 8y ago

[deleted]

DannyBee 8y ago

"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 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. [1] 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/ https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

kradroy 8y ago

My father told me long ago: "After you've done the work the only thing you should sign is a check you're about to deposit."

JdeBP 8y ago
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. * http://www.legislation.gov.uk/ukpga/1992/32/section/1 http://www.legislation.gov.uk/ukpga/1992/32/section/1 * http://www.legislation.gov.uk/ukpga/Vict/45-46/61/section/34 http://www.legislation.gov.uk/ukpga/Vict/45-46/61/section/34 * http://www.legislation.gov.uk/ukpga/Vict/45-46/61/part/II/crossheading/negotiation-of-bills http://www.legislation.gov.uk/ukpga/Vict/45-46/61/part/II/cr...

2ion 8y ago

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.

lacker 8y ago

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.

kemitchell 8y ago

A blog post of mine arguing for CLAs: https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sham.html https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sha... My post responds to a different blog post. Some of the arguments here are different. Here, I can't help pointing out two minor vocabulary issues. A "Contributor License Agreement" does not usually transfer ownership of copyright. We call documents that do "copyright assignments", and they require special formalities. There are some strange hybrids, like CLAs that assign joint ownership of copyright, but they're the exception. Most CLAs that I see are merely additional license grants from contributor to project steward or BDFL. "Relicense" gets misused and misunderstood all the time. It's very rare to see anyone try to change license terms for code already released under an open source license, and distributed to others. There are legal questions about whether this is possible or practical. And as I recall, Redis Labs didn't try to do that, but only changed the terms that will apply to new work on select Redis add-ons, going forward. In other words, they changed the terms they'll use for future work. We sometimes say "relicensing" when we mean "dual licensing" or "offering the same code on different terms", rather than changing the one-and-only set of terms that apply to software. The former describes what companies do when they steward a project under a common open source license, often GPL or AGPL, but also sign business deals that include traditional, proprietary-style license terms. Often, such licenses omit requirements to preserve copyright notices from developers, and also copyleft requirements. At the same time, business-to-business licenses are often more restrictive in other ways, like limiting to internal business use, prohibiting reselling, seat-limiting, and so on. CLAs often give corporate stewards the more permissive licenses they need to sign those kinds of terms with customers. In that sense, CLAs make possible the business model that supports the company stewarding the project.

hodgesrm 8y ago

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?

jedbrown 8y ago

> 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. Term 2 of the CLA just defines inbound=outbound for Term 2 of the License (https://www.apache.org/licenses/LICENSE-2.0 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 http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html

gant 8y ago

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.

btilly 8y ago

As a counterpoint, read https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html where the GNU project explains why they require copyright assignments. 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.

JdeBP 8y ago
Or read https://news.ycombinator.com/item?id=18149011 https://news.ycombinator.com/item?id=18149011 here where it is argued out that a copyright assignment is not the same thing as a contributor licence agreement.
- btilly 8y ago
  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.

kodablah 8y ago

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

simplecomplex 8y ago

Has any CLA ever been used in court and held up? What are real world examples of CLA’s being enforced in court?

quest88 8y ago

I don't mind contributing to paid software. 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.

lucb1e 8y ago

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.

jpfr 8y ago

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. https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52 https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

kemitchell 8y ago

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: https://writing.kemitchell.com/2018/09/30/Contributor-Councils.html https://writing.kemitchell.com/2018/09/30/Contributor-Counci... I think the fundamental legal mechanism of cross-licensing is correct, but the quorum-vote-like solicitation mechanism needs more thought and feedback.

sytse 8y ago

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

evrydayhustling 8y ago

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.

IAmLiterallyAB 8y ago

Have we forgotten the Linux Code of Conduct controversy? Contributors threatened to remove their code from the kernel. A CLA would completely prevent that.

JoshTriplett 8y ago
> Contributors threatened to remove their code from the kernel. No. Random fringe anonymous emails from non-contributors claimed (incorrectly) that developers could do so. See https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/ https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocabil... and https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4 https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x... for details (incorporating actual legal analysis).
deleted 8y ago
[deleted]

tlrobinson 8y ago

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.

orthecreedence 8y ago

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

kemitchell 8y ago
re iOS store, have a look at: https://github.com/signalapp/libsignal-protocol-c#license https://github.com/signalapp/libsignal-protocol-c#license If you need legal advice for your specific project and situation, speak to a lawyer.

tristor 8y ago

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.

nikisweeting 8y ago

I hate both CLAs and DCOs. CMV: it's an unnecessary barrier to contributing for new users that provides no additional guarantees over GPG signing.

pron 8y ago

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.

carapace 8y ago

An obscure but interesting point, by DJB: > 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. https://cr.yp.to/softwarelaw.html https://cr.yp.to/softwarelaw.html

vsl 8y ago

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.