Don’t sign a CLA

It's a great point to be aware of, but the title and the tone implies that you as a contributor should be a FOSS maximalist.

As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications.

When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.

> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.

This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. I will save that for the parts of my life where it makes sense - I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil. If I believed that, I wouldn't be working on a closed-source project in the first place and then this piece would be fully relevant.

A much better title would be "Why I don't sign CLAs" or "The dangers of signing CLAs".

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

A blog post of mine arguing for CLAs:

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.

Hi, I run an open source project and it has a CLA. I chose a fairly permissive one (contributors retain ownership/copyright), however it does allow relicensing. One of the main reasons I chose to do this is:

1. I have a put a lot of time into the project. More than anybody. Years of work. At some point, I'd like to be able to make money off of it, and relicensing will give me that option (enterprise installations and all that).

2. iOS. The GPL, from a lot of what I've read, is incompatible with the Apple store. If you want to release a GPL-licensed app on iOS, you need to be able to relicense it. Please prove me wrong here, but I think this is a big deal.

Here's my take. If I ever want to make the project completely closed, the last GPLed version is still available and able to be forked or continued. I can't erase the project from the face of the earth, which is kind of what the author seems to be suggesting.

Secondly, if I was starting a project that blossomed with the help of hundreds of contributors, I'd be much more likely to not want a CLA. That said, this is my project. Sure, anyone can fork it and do what they want with it, but I am the one creating it. And at some point, I want that to pay off. My choice of GPL is not to protect contributors, it's to protect the users. The CLA lets me have a restrictive license while giving me the freedom to relicense as needed.

If that keeps you from contributing, no hard feelings. But having a CLA lets me navigate a lot of issues that would otherwise keep me up at night (or make me not want to maintain the project at all).

Pieter Hintjens makes a similar argument in Social Architecture, describing ZeroMQ's community guidelines:

> All patches are owned by their authors. There SHALL NOT be any copyright assignment process.

> Here we come to the key reason people trust their investments in ZeroMQ: it's logistically impossible to buy the copyrights to create a closed source competitor to ZeroMQ. iMatix can't do this either. And the more people that send patches, the harder it becomes. ZeroMQ isn't just free and open today--this specific rule means it will remain so forever. Note that it's not the case in all MPLv2/GPL projects, many of which still ask for copyright transfer back to the maintainers.

Wait, Free Software Foundation requires a CLA itself!

https://www.gnu.org/licenses/why-assign.en.html

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

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

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

The Apache CLA is pretty benign (for projects that are distributed under the Apache license; sometimes it is used for projects distributed under different licenses and then it gets murky), but the overhead to contributors and maintainers is significant and it is less precise than a Developer's Certificate of Origin. The "Inbound=Outbound Is All You Need" section of this post is on-point. http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html

> Open source is a commitment to your community. Once you make it, you cannot take it back. You don’t get the benefits associated with being an open source project if you have an exit hatch. You may argue that it’s your right to do what you want with your project, but making it open source is explicitly waiving that right.

I open source things I write, and I love open source but I think this stance is disingenuous.

Yes you should maintain your project in the future so that you don’t leave your users hanging to dry, but sometimes life happens and you can’t continue your open source project in its current form.

With a CLA, the creators of a project that would otherwise be unable to continue the project due to lack of funds can develop a proprietary version that they can earn money from licensing to people. And hopefully they will continue to maintain an open source version that receives bug fixes and some features while certain other features are only developed for the proprietary version.

Demanding that those who make open source software do so under strict conditions will only serve to deter people from making open source software in the first place, IMO.

Certainly it can be frustrating to be a user of a software and have them close the source, but what would the alternative be? Probably that it just died, so for you the outcome would be the same.

Open source is great. It saves time and money by letting people and companies make use of the work done by others to save themselves from having to duplicate the effort. But it is never going to be the case that we can demand that someone else continues maintaining a product for us for free.

When a product goes closed source, from your point of view it should not be much different from had it shut down completely. The last open source version of the product is still available so if someone was goinging to step up and maintain it into the future they still can, and if they weren’t going to, well then it makes no big difference what the original authors decide to do anyway.

Personally the main reason I don’t use CLAs for my projects is that I am using a very permissive license for most of my projects already, the ISC license, and I don’t foresee any situation where I would want to switch to another license for my projects.

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/

As a counterpoint, read 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.

Not all CLAs are designed to let the project relicense itself. In particular, some CLAs are there to make the contributors promise that they are not submitting patent-encumbered code which they intend to later assert some rights on. Those CLAs seem like they are fixing up a fundamental unclearness in how patents are licensed in open source software.

> used their CLA to pull along any external contributions for the ride. As thanks for the generous time

Am I the only one that doesn't over-value their own contributions? So many copy-left proponents always bemoan giving your work away. While that may hold some water on some large efforts, in general, who cares if you give away bits of your work? Who cares if you sign it away? Don't get hung up on your personal pride like your contribution is the greatest thing ever, feel free to share and share alike even on projects with caveats to your sharing, even if that means you are guilted by the forced-freedom side of the community. Or don't...but no need to pretend like others are bad for doing so.

I do not agree with the sentiment that all CLA are evil.

Yes, CLA that transfer all ownership to the project are bad. But many CLA are in place to protect the project from bad actors. For example companies suing the project because an employee has submitted code that he wasn't allowed to make public.

I use a CLA in an open source project. But it does not transfer ownership. It just states that the contributor is allowed to make the contributions and accepts the license.

https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52

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

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.

CLA intimidates people to contribute. It discourages contributions

I'm not entirely sure I understand why so many people are against CLAs. I've been active in the open source community since 1996, and am currently employed at a company which is 100% based upon service around open source software, which includes our stewardship of several projects which have significantly advanced the community cause. My employer requires a CLA. It is not written in esoteric legalese, but is rather simple to understand before you sign it. It is designed to protect both you, as the contributor, and my employer.

A CLA is a good thing when it's written well, is not overly onerous, and is being used to further contributions. Here is some basic reasons why a company like my employer may want contributors to sign a CLA:

1. It prevents your heirs from terminating your copyright grants in the future if you pass away or any number of other weird quirks of US copyright law that could potentially result in legal fuckery that you do not intend. 2. It prevents enforcement of patents surrounding code you have contributed against my employer. 3. It indemnifies you as the contributor against expectations of support, guarantee, or warranty for your contribution. 4. It commits my employer to maintenance of your contribution once its accepted as long as it is needed in the code-base. 5. It protects my employer from getting in trouble for contributions where the contributor did not have legal license to offer the contribution, because you are asserting that you have such license before offering that contribution.

Yes, it allows for re-licensing, but in practice what this means is that some or all of the code may be dual-licensed at some point in the future to assist in integration with other open source software projects.

To assert you should never sign a CLA seems short-sighted and unreasonable. I can't speak for every project, but my employer has been a good steward of software in the community and the community itself since the day it was founded and has committed to continuing to do so.

While I can certainly understand that you may not wish to sign a CLA with an organization you do not trust, I don't think refusal to sign should be a default position. Instead, like any contract, you should read before you sign and not enter into agreements with entities you do not trust. Simple as that.

I won't contribute to any open source project with a CLA - which has been a shame for a few open source projects. I caught a serious security vulnerability in one project including them openly posting admin secrets - and privately contacted and let them know, appropriately - only to get back a response of "Can you sign our CLA and help us fix this?".

I politely told them I don't do CLAs. I checked a few weeks later and the passwords were still posted.

I'm sitting on a few custom forks of open source tools (in which I've either fixed a bug or added a feature I needed) which I've more or less kept to myself because the process to contribute back to those projects is just enough of a PITA (due to CLAs and the like) that I can't overcome my apathy/laziness enough to spend the time/effort required to submit my changes and get them accepted.

Ah well.

What about the maintainer's right to not have their hands tied as they evolve a project by one person issuing a custom license on their PR? I agree with your final suggestion of forking off (hah) if you have a problem with the CLA... But it's unwarranted to say a maintainer protecting himself from a huge additional coordination burden is a kick in anyone else's groin.

I've always been under the impression that CLA's are meant to ensure that contributors can not retract their contributions once they've made them. I'd be fine with signing such an agreement. Relicensing other people's work, on the other hand, does seem like a dramatic overreach indeed.

Even if you don't sign a CLA, can't someone take an Apache/BSD/MIT-licensed work and make a closed source form of it? The license effectively just requires them to mention where the code came from. Whether you signed a CLA or not seems pretty irrelevant.

Apache says for example: "You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole [...]".

I think the OP's concern only applies to GPL software, which in my experience is pretty rare at this point.

I agree with the author that a CLA is one sided since contributors are at the mercy of the organization they sign their rights over to. For the open source code a Developer Certificate of Origin (DCO) is more appropriate. I learned this when Debian brought it up https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l...

For our proprietary source available code we do use a CLA since it is a custom license and we want the option to make changes to it in the future.

"What the CLA is actually used for is to give the project maintainers the ability to relicense your work under a more restrictive software license, up to and including making it entirely closed source."

Actually, it serves two main purposes[1] :

1. Protect the project from people who don't actually have the necessary rights to be contributing or wish to retract contributions later.

This is the most common case, and it happens all the time (though essentially all of it is resolved privately due to CLA's).

The law is full of interesting dragons. As a random example: Most open source is also too young, but in ~10-15 years, you will start to see copyright right terminations in the US (https://www.law.cornell.edu/uscode/text/17/203) for projects that have no CLA's.

It's inevitable. (as is having to deal with the rights of people who are dead, which already happens)

Projects often need to do something to protect themselves over time (regardless of whether it's a CLA or copyright assignment or ...)

2. Protect the projects from patents in #1 when the license does not do so.

(this is also resolved privately)

It also resolves an issue that only has popped up recently, copyright trolling by folks like Patrick McHardy.

Relicensing is a very secondary concern, and mostly comes into play over time because the project screws up or grows larger than it expected.

The boogeyman of "corporation takes away my rights" is a nice boogeyman, but the infinitely more common case is "project screws up because they didn't think about licensing when they started". The number of "corporate relicensings" is vastly dwarfed by non-corporate ones.

One of the more interesting things to me is that the largest mass relicensing i'm aware of was the FSF force-relicensing projects to GPLv3 (sometimes quite against majority-contributor wishes), with no comment or discussion or allowance for dissent. So it wasn't a corporation doing it for whatever, it was a foundation doing it for ideological reasons.

The fact the article tries to make it seem like it's happening all the time is disingenuous at best, and honestly only serves to make the argument weaker (because it's unsupported by data).

I'd also point out a CLA or equivalent is also necessary to move a project from gpl-v2 only to gpl-v3 (IE not "restrictive software licenses") if the project later chose. Otherwise it is stuck in limbo forever.

The answer you usually get from anti-CLA folks is "they shouldn't do that in the first place" which is nice but doesn't actually fit with the fact that most people basically don't pay any attention to license choices in a meaningful way when they start projects. Or make mistakes. You know, one of the reasons we have version control in the first place - so we can change things we got wrong over time.

Even if you could cause them to not make mistakes, or never change viewpoints, you'd still have millions of legacy projects to deal with.

All this article tells me is that the person hasn't run a large enough open source project to have to deal with these in a meaningful way. That's okay. But i've never found someone who did who has not run into the issues above and eventually moved to CLA's or an equivalent.

I've also spent a lot of time in my life fixing smaller projects that never had one, and then became larger, and then had to clean up the mess. It usually costs foundations/etc a lot of money and time to track down contributors or pull code.

I'd actually love to live in a world where CLA's aren't necessary (and copyright was sane). But pretending we do won't get us there.

[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/

In my spare time / hobby projects, I'm ready to don my FOSS advocate hat, but as a businessman and employee, I'm practically ignoring all issues with the lack of F in OSS. Many thanks to those who can afford to live by their ideals even when it comes to earning a living, though, and much respect for being willing to deal with this kind of stuff all the time.

It's not so much signing away your rights as getting something in exchange for something. As you say, you can always fork the project, but very often large projects (that tend to be the ones with CLAs) are also used by companies that rely on them. What you get in exchange for the CLA is your code (written to scratch your itch) becoming part of the mainline, and saving you the trouble of merging with every update. If scratching your own itch is the goal, and if your contribution is small relative to the total project (and it often is for projects with CLAs), then granting the project leaders a joint ownership over copyright is a very small price to pay in exchange for having the leaders take your contribution into the mainline. If, on the other hand, your goal is to shape the project, this usually entails a large number of significant contributions, and if you do that, becoming a part of the leadership or getting a part of the project ownership can be negotiated.

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

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?

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

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

I think the fundamental legal mechanism of cross-licensing is correct, but the quorum-vote-like solicitation mechanism needs more thought and feedback.

The point is somewhat ruined by getting major facts about licensing and Redis wrong:

1. It was about proprietary addons, not community version at all. 2. The license of Redis would allow such relicensing of externally contributed code without CLA. Read the damn BSD license, that permissiveness is its whole point.

20 years ago, OSS developers understood their licenses. These days, it seems common that people slam a random license on their code or contribute somewhere with absolutely no functional understanding of the legal aspects.

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.

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.

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

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

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

Good general advice. I can't say I have a categoric aversion, but the onus is on upstream to honestly and clearly explain the specific circumstances and reasoning for why the license by itself is insufficient for their special needs.

TL;DR: Some (all?) CLAs allow the maintainers to change the license of the code that you contributed, even if that is a proprietary license. The article mentions exactly one example of where a maintainer did that and does not point out what clauses to look for, how many CLAs actually do this, etc.

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

> A CLA is a kick in the groin to a contributor’s good-faith contribution to the project.

I wouldn’t invest in a company that conducts business “on good faith.” That’s well and good in the domain of interpersonal interaction, but is irresponsible behavior from a company, which must do all it can to safeguard its assets and revenues.

And I don’t think I’m being soulless here. A company like Facebook is entrusted with and responsible for many people’s very livelihoods. As a corporation it must not behave casually. There’s no “in good faith” when you have millions of employees and investors.