Seriously, Don't Sign a CLA | Hacker News Reader

Seriously, Don't Sign a CLA

drewdevault.com

96 pointsTomte36 comments

I've come around to a new appreciation of why a CLA may not be bad.

I have a business. That business deals in copyleft software that I have sole copyright in (or comes from permissively-licensed code).

My customers, which will be businesses, will be required to sign a contract with a CLA so that if they make changes, I will be the copyright holder of those changes.

No, I won't have individuals sign a CLA. But I also won't accept contributions from individuals, like the SQLite authors, who need a guarantee that all of their code can be public domain.

In this way, I will be legally able to loosen the license over time if I so wish. Without CLA's for customers, I couldn't do that.

Lawyers at my job pointed out one particularly nasty aspect of CLAs: the lack of liability controls.

All open source licenses have some form of legal liability wording in them, e.g. from GPL v2:

> 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

No CLA I've seen so far does anything to maintain that protection from liability. Those responsible for the software could switch the license to one which leaves you, or your employer, legally liable for any damages incurred. That could very, very quickly, bankrupt you and/or them.

Sure, but in America, anybody can sue anybody for anything. Your lawyers are of course right that having a clause in a software license disclaiming all liability for its use could be helpful in your defense -- but it's not an ironclad guarantee that you will not be sued or even found liable for your contributions in the event that it causes some kind of catastrophe. If this is a major concern for you, you should probably avoid contributing to FOSS altogether.

However, if you don't own the software and don't distribute the software and don't have any other kind of relationship with the users of the software, it's likely going to require the plaintiff to demonstrate particularly egregious conduct on your part in order for a court to find that you have some liability for damages arising from the use of the software. But YMMV.

Well, of course.

But if I accept a contribution, I'm already accepting responsibility for it, so I will not accept it unless I understand it and test the snot out of it.

This is another reason I don't accept contributions from individuals.

It's not about you.

It's about the person/company that signs the CLA. They're the ones that end up in potential legal nightmares, unless the CLA specifically promises to continue to indemnity.

I think my CLA should do that. I'll make sure my lawyer adds that to the draft.

> In this way, I will be legally able to loosen the license over time if I so wish. Without CLA's for customers, I couldn't do that.

Or you can make it poprietary, which is the exact reason I would not want to sign a CLA with you, because I want a guarantee that my contribution remains foss.

True.

But again, I don't take contributions from individuals, so I wouldn't ask you to sign one anyway.

This means that if I take it proprietary, I will have ensured I do not steal from any contributors.

You will not have stolen in the same way that Google/FB don't "steal" your data. Instead, the end user is simply forced into the position to give away their IP to you, where you can adjust the licensing per your whims, even to sell it back to them. It's fine to consider your lack of contributors is related to the "no individual" contributors" choice that you have made, but it would be disingenuous to avoid recognition of how your choices probably result more in "no contributors".

Individual end users will not be contributors.

Businesses will be contributors. These businesses have more "power" than me because they'll be bigger than my one-man shop.

I'll do these CLA's to adjust that power balance.

How many real contributors you have? Is it mainly just you and perhaps some tiny bug fixes?

I have exactly one who fixed some typos in documentation and gave me permission to relicense under any FOSS license.

We implemented a Contributor License Agreement (CLA) on our project, [Monica](https://monicahq.com), to protect ourselves from potential legal action by contributors.

Without a Contributor License Agreement (CLA), even if the repository is licensed under the MIT license, I'm not sure I'm protected against disgruntled contributors, regardless of the complaint.

what legal actions from contributors are you fearing, and how does your CLA protect against that? (btw: i can't find any mention of the CLA on the website or on github)

> (btw: i can't find any mention of the CLA on the website or on github)

We've found contributors are more likely to sign a CLA if kept ignorant of it until the time comes to merge the reviewed fruits of their labor. /s

My employer requires that all open source projects have a CLA, but there's really no benefit ever to be gained from closing any of its projects.

My understanding is that the CLA is there for two main reasons: First, as a legal CYA, since large companies are lawsuit magnets, and more importantly to me: for flexibility in changing the OSS license we use. Our individual OSS projects have moved between teams, and best practices enough that we have them under a number of permissive licenses (BSD-3-clause, MIT, Apache 2.0). It's been useful sometimes when combining projects, or to reduce the number of license headers to (sparingly) re-license under a common license. Without a CLA this would basically be impossible.

The CLA does require trust that we won't relicense under a restrictive license or gain undeserved benefit by making commercial licenses that rely on the copyright (as opposed to say I support license). That has turned some potential contributors off. At least that's a choice everyone can make.

> The CLA does require trust that we won't relicense under a restrictive license

This is why I would never sign a CLA. I may trust the entity asking for one, but owners change over time, and I can't trust that the project or business won't be transferred to someone else in the future who may not be trustworthy on these issues.

Sure, but also the “collective ownership” of the Linux kernel is the reason it can never leave GPLv2 for GPLv3. If companies like Red Hat start finding fun loopholes in GPLv2, Linux will be powerless to seal them up.

Linus has explicitly stated he doesn't like GPLv3, and neither do many others - corporate and otherwise - so all a copyright assignment would do is potentially remove their rights to use code they wrote.

Either by making it GPL3 and have them lose access to it in their use case, have the code made proprietary so they can't use it at all, or switch to another license entirely (BSD, MIT, or public domain which are all "worse" than GPL per the GPL3 folk).

I don't understand people who would assign copyright for OSS code they wrote to someone else, because that's just a giant F U to the entire concept, and has literally no up side for anyone other than the new owner.

IANAL...

A CLA should specify that the copyright assigned will always be under a license approved by the FSF and OSI.

The "and" is important, as it's probably possible for one of those organizations to go off the rails, but not both.

If the contribution is into an open source project on, e.g. github, the contribution is already covered by an open source license the contributor is aware of. If the copyright owner takes it private, they cannot revoke the existing GPL license on the existing code base - only changes from that point forward.

At that point, the contributor could take the existing codebase and fork it to keep it open source. Of course, they can only do that under the existing license so they have no power to change the license themselves.

What CLAs do allow (that IMHO is beneficial) is the copyright owner developing other licensing options for specific customers. This can provide a better income source than just “support” for a project.

Redhat hasn't found a bona fide loophole in the GPL. Rather they're trying to create a drag that will cause market inefficiency to accrue to them. It can only work as long as their changes stay relatively minor. The more valuable those changes are, the more incentive there is for people to break their agreement and widely publish the GPL code, perhaps even anonymously so that Redhat can't actually discontinue their access.

Sveasoft tried the same thing with WRT54G firmware back in the day, and failed so hard that apparently nobody really remembers.

Its not a loop hole, the GPL only ever required you to give the source to users, it never required the source to be public.

Sure, but the terms of the GPL imply other not-explicitly-specified results due to straightforward emergent behavior. Like the terms themselves don't prohibit (and even encourage) charging for GPL software, but in the presence of FSF's Freedom #2 (redistribution), the price ends up tied to the work of distribution rather than the utility of the software. That overall resulting state of affairs is what people are taking for granted and reacting against possibly changing.

Since sourcegraph was Apache2, it doesn't matter whether or not contributors signed a CLA. Apache2 only requires them to provide attribution. At any point a permissively licensed project can go closed-source. When they distribute it, they'd provide attribution, and would provide a link off to code from the last open source version.

A CLA primarily provides legal coverage for the legal entity primarily responsible for the project, as they can claim copyright on all the changes.

From a project maintainer perspective, I prefer DCO over CLA, as it provides a similar style of protection, but in general lawyers at companies default to a CLA.

If you want access to future changes, you need to limit yourself to contributing to copyleft licenses.

> It is not ethical to demand copyright assignment in addition to the free labor of the open source community.

Unless you're a GNU project under the FSF?

I don't think Drew would disagree with your point, given he has been vocally critical of the GNU project due to the continued involvement of Stallman and those who support Stallman.

However, it's important to note that practically it's not clear that GNU actually need a CLA if they wanted to pull such a movie. Contributions to GNU projects are GPL-x-or-later licensed, and GNU are the authority to declare something as GPL 4, even if it contained language that allowed the project owner to close the project.

You are wrong on many details here. First of all, GNU isn't even a legal entity. The only legal entity is the FSF. Second, only some GNU packages have a copyright assignment to the FSF, not all. Some packages use a DCO, and some have way more creative solutions (see https://www.gnunet.org/static/pdf/copyright.pdf for example). Finally, not all GNU packages are necessarily GPL-x-or-later. Yes, that's generally a good default (and sometimes AGPL-or-later or LGPL-or-later are good, too), but not a strict rule.

Many people oppose the FSF's policy of copyright/IP/ownership theft.

Pharo's CLA doesn't seem that bad [0]. You retain copyright, and agree to license your contribution using the MIT License. OTOH, you also agree that your contribution is "only a small component". IANAL and I wonder what is the implication of such a clause.

[0] http://files.pharo.org/media/PharoSoftwareDistributionAgreem...

There's also the FLA[0], which guarantees the contributor that the project will only be relicensed to (certain) free software licenses.

0: https://fsfe.org/activities/fla/fla.html

No doubt a naive question, but without a CLA, how does the project obtain the IP rights from the contributors necessary to make all the code releasable under an open source license (or a future open source license)?

I suppose if every contribution from the very beginning was made predicated on a license that was irrevocably open source and permitted the project maintainers to re-license the project under a future compatible license, then CLAs perhaps wouldn’t be necessary (though doesn’t there still need to be an assignment of the contributor’s inherent copyright rights?), but how often is this the case in practice?

It requires those contributors to license their contributions under the same license, which as a valid open source license will allow distributing all the contributions under a larger work under that license (or compatible licenses). You're right this makes _changing_ license a lot harder, but to an extent, that's the point, as if you could easily jump from LGPL to Apache or something, there's very few ways you could make that allowance without making it easy to go to full proprietary.

The DCO is basically the legal CYA your lawyers might require from contributors saying "I wrote this code any any future contributions I will submit and am happy to license it under X". Notably unlike CLA, it doesn't assign ownership to the recipient or give them permission to arbitrarily relicense.

Thank you for the explanation - very much appreciated.

IANAL. Can a CLA be considered a "contract without consideration" and not legally enforceable?

i don't think so.

the contributor is giving the company/project something. and not making a promise that they don't keep.

if i understand it correctly, consideration is only relevant for a contract that has not yet been executed.

once the contribution is made, there is no enforcement necessary, because the contract is already completed. the project must now be able to assume that it can use the contribution under the terms that were agreed upon.

if that was not the case, no project could ever accept any contributions from anyone.

all the CLA is doing is requiring the contribution to be made under specific conditions.

if the project only accepts contributions under the GPL then there is an implicit CLA that all contributions be released under the GPL. once the contribution is released the license for it can't be changed either.

Reply on news.ycombinator.com