You probably shouldn’t add a CLA to your open source project (2018) | Hacker News Reader

You probably shouldn’t add a CLA to your open source project (2018)

ben.balter.com

38 pointsAmorymeltzer41 comments

If I have an OS project and someone submitted a Pull Request with something they cannot really publish. Like a piece of proprietary code from their work. Without a CLA, I have full responsibility if I accept it, so their lawyer can easily sue me for that piece of code.

I mean, that actually happened to me a few years ago, and their lawyers forced me to completely delete the whole project, just over a few lines of someone's code. So as for me, CLA gives at least some additional protection against lawyers trying to shut down some competing OS project.

As someone that has a huge bet on DCO - for you, as a contributor, is DCO better?

That's an option too. Though as for me it's the same efforts for a contributor.

Unless you require the CLA physically signed on paper. Otherwise there are GitHub addons that do CLA just with one click once after making a first Pull Request.

I'm thinking more `git commit --amend -s ...`

Forgive my ignorance, but why couldn't you work to replace it, or at least revert the commit?

If it was completely open source, they would have to prove that you accepted code maliciously, ie: knowing that the code was proprietary and for unfair advantage, etc.

Do you feel like they were bluffing? Because I definitely do.

Lawyers will always ask for the most favorable outcome for their client, which in this case was the GP deleting the project. Had the GP gotten their own lawyer (or even "call their bluff" by letting them either take it to court or GTFO), I'm guessing they could have kept the project. (Of course, if GP knew before merging the code that it was someone else's code, then things are likely different, and going to court might not be favorable)

They could argue that the git commit history being immutable means that they have to delete the entire repository to remedy the existence of the proprietary code being available for download. The best way to continue would be to either rewrite history (eg. with BFG) or fix it, destroy the git history, then start from scratch.

I think it was not about those lines, and they didn't want to listen. I believe the court would rule to just "revert it" but I didn't have money to go to court anyway.

I'm not sure that I would spend money on lawyers if I had a CLA, but at least it would give me a leverage in conversation.

Curious. How would the CLA protect you?

Couldn't the same situation occur even if the contributor had signed a CLA.

That is answered in the article:

"CLAs shift the legal risk for copyright infringement, patent infringement or other bad acts, intentional or otherwise, from the project (the entity best positioned to defend a legal claim, and often the one most directly benefiting financially), to the contributor"

Okay. But still if a person contributes code that is not their code, even if they sign a CLA, and it ends up in the project the project can't say "not our problem they signed a CLA". The project would still need to remove the offending code.

It would give me a leverage and that would be a totally different conversation.

Though I understand that if lawyers want to destroy something they can do it regardless the CLA or anything. It's just the game of who spend more money in court.

Yes, but with a CLA you will never actually get to merge most pull requests. No random dev that thinks "well I can upstream this patch" is going to read through, understand and sign a random document for you.

I require CLA now and had never experienced a single developer refusing to sign it

Maybe this is "survivors bias" and you only know the ones who accepted. Maybe the ones who refused never even bothered to tell you.

How would you experience people you never meet?

CLA == Contributor License Agreement

"You can think of a CLA as somewhat of a “reverse open source license”. Whereas open source licenses are a copyright grant for users to use the project, a contributor license agreement, at its core, is the right for the project to incorporate a contributor’s code."

CLAs are bad because:

* "CLAs create a contribution-hostile developer experience"

* "CLAs require significant administrative overhead"

* "CLAs shifts legal blame to the party least equipped to defend against it"

You're welcome :)

> * "CLAs shifts legal blame to the party least equipped to defend against it"

I don't really get this one. The argument in the post is that the contributor does not the money/knowledge to make the legal decision required to sign the CLA. But typically the CLA requires the contributor to confirm that the contributed code is theirs to give away. The contributor should be able to make that determination!

The contributor could fully believe that they have the rights to the code, because they wrote it using their own computer resources, on their own time (on vacation, etc). However a number of organizations claim ownership over all IP created by any employee at any time. And a contributor may not realize that because it is often a 2 line paragraph buried in an inch-thick stack of new-hire forms that you don't get to see until after you've left your previous job and started the new one.

Sure it might be hard for the contributor to be sure, but it’s even harder for the repository owner.

I get it's a meme but are you lot really signing contracts without reading them?

Honestly this post+comments has tipped me over to add a CLA haha. I'm not legally vouching for someone who doesn't even know their employment contract D:

On the first day of showing up at a dream job (compared to what I had before, and after terminating my employment with the previous job), you sit for the whole first day going through new hire orientation. Along with a big stack of paperwork. And it isn't that you don't read the document, but there is a difference between reading and understanding the full implication of it, depending on how they word the one phrase out of a 10 page document that looks like it contains mostly common sense items that you are agreeing to.

Each to their own. I wouldn't sign something I don't understand

Most of the arguments against the use of a CLA in this essay feel like legitimate but generic laments of the complexity surrounding software licensing and employment contracts, not actually relevant to whether or not most projects should adopt CLAs.

CLAs can be written to be confusing (like anything), but in my experience they are no more confusing than open source licenses themselves. Suggesting using Apache License to avoid the confusion of a CLA is particularly weird to me since that is a long and complicated license compared to the most common OSS licenses.

Bad process can also make CLAs hard, but that’s not any fundamental problem with the concept of a CLA. As someone who also worked on improving the CLA process for a non-profit OSS foundation, I can say with confidence that the administrative burdens are insignificant when your process isn’t broken. It feels to me like saying “you probably shouldn’t use code linters” as a blanket rule because some projects use some uncommon coding style.

Even after reading this I don’t really understand why the author seems to think that CLAs mostly exist to shift liability toward third parties. It’s not as though the project still gets to use the IP-infringing code just because the person who put it there signed a CLA, and it’s not as though the absence of a CLA keeps all parties from being sued. The legal entity that owns the project would probably be able to avoid any claim of wilful infringement, but I can’t think of any other way that a CLA shifts legal blame. (However, IANAL.)

On the other hand, I’ve been involved in OSS projects where a contributor didn’t sign a CLA, contributed code, then became acrimonious after some of their other ideas were rejected and threatened to sue the project if their code wasn’t removed. While it would’ve been extremely difficult for them to do so, it created a lot of problems that simply wouldn’t have existed if there were a signed CLA to point to.

The fact of the matter is that the long tail of OSS projects are not owned by big megacorps with endless pockets for lawyers; most are either part of 501(c)(6) non-profits like the Linux Foundation or just solo developers, and for those projects having a CLA is probably even more valuable.

A CLA is much like a CoC: It is an indication that the maintainer(s) of the repository are not busy with writing good software, but busy covering themselves because of all the hostile people they see around them. It tells you to not participate in the community, because to them your contribution isn't nice and welcome. It is a potential threat that must be mitigated.

> "CLAs shifts legal blame to the party least equipped to defend against it"

Ah, I forgot about the hundreds of thousands of dollars of retainer every open source maintainer has dedicated to defending against copyright lawsuits. Silly me.

As an author of a project I chose to license under the GPL, I now require a CLA in case I want to relicense my project under something more permissive, e.g. MIT (which would be prevented by other people submitting their pieces of code under the GPL).

They can also be used in the other direction, allowing a corporation with an initially open-source license to re-license all contributed work, including closing it off.

It's my understanding that relicensing only applies to future releases, so the original contributed work would still be available under the original open-source license, and the project could be forked from that point.

This is the exact reason I am against CLAs. Relicensing. You give me your work under the conditions of the GPL, then I as a contributor want to do the same. If relicensing is allowed you could just close up your source code and even though I contributed GPL code I could do nithing against it.

A CLA is a way for legal to minimize the risk of open-core development. However, at a high level, the company gets free use of the code and the right to commercialize the open source version, but doesn't want any responsibility for accepting the code. Even worse, the contributor way even be agreeing to be liable.

Those same companies will agree to taking on millions in indemnification, on behalf of their customers. They'll take on the risk to make a sale, but won't take on risk to get free work...ugh.

Depends on how the CLA is worded. It's possible for the CLA to have the contributor retain all copyright over their contributions (thus preventing the maintainer from pulling a 180 and suddenly licensing the contributed code commercially) while still forcing the contributor to assert that what they made is not stolen code.

It’s kinda weird to write an entire article talking about CLAs but not actually say why they’re being adopted (instead saying they’re being adopted because maintainers don’t consider the costs, which is the opposite of a reason). Namely, to prevent contributors from withdrawing the project’s license to their code after the fact, like what happened with Mojang’s Forge.

I don't get the point of CLAs. Will they prevent you from being sued, or help your case if you are? Will they allow you to avoid removing copyrighted code that was contributed under false pretenses? Has any of this been tested in an actual court?

Google has written up a detailed explanation of what they think the point is: https://google.github.io/opencasebook/cla-policy/

I've only signed a CLA to contribute to emacs, even as a big supporter of the GPL and understand why they want a CLA, its a pretty huge pain in the hole to contribute with fairly little end user or even contributor benefit. It just slows down development so much, at least for new developers I guess.

The thing that the FSF makes contributors sign isn't a CLA; it's a copyright assignment agreement. It goes much further than what's described in this article; rather than merely shifting the legal risk around, it makes it so that the FSF, not you, is the owner of the code that you wrote.

Obviously, something like this carries substantial potential for abuse, and so would generally be treated as sketchy and an indicator of bad faith if done by anyone else in the FOSS community. The FSF gets away with it because they have a long track record and everyone knows there's no way they're going to pivot to a proprietary-software business model.

The reason the FSF requires copyright assignment is because they want to be able to proactively sue GPL violators (because doing so is a way of furthering their core mission), and U.S. copyright law makes it difficult for anyone other than the copyright holder to do that. Most other organizations' priorities are such that this would be a waste of time for them.

> U.S. copyright law makes it difficult for anyone other than the copyright holder to do that.

Or, rather, the FSF originally believed this to be true. This HN post from today[0] is an instance of someone other than the copyright holder suing for GPL compliance. They are not claiming any kind of copyright ownership over the GPL code that they're suing over. We know now in hindsight that the FSF was overly cautious about this.

An interesting tidbit is that the GCC project (under the FSF banner) recently stopped requiring copyright assignment to the FSF[1]. Mostly because they want to distance themselves from the FSF, but partially because it didn't turn out to matter after all. A developer certificate of origin (DCO) suffices for their purposes.

[0] https://sfconservancy.org/copyleft-compliance/vizio.html

[1] https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html

We don't yet know that the SFC's new approach is going to work. The court could still reject it.

While true, the old approach (having a single contributor / partial owner, not necessarily an FSF-style copyright owner who owns the entire work) still doesn't require FSF copyright assignment. As an example, the Linux kernel never did copyright assignment, and the SFC has been suing over GPL violations for Linux.

I think I actually prefer CLAs most of the time. If I’m submitting a patch to some piece of source available code it’s usually because I encountered a bug or missing behavior that is getting in the way of my work and I want it to be fixed. I just want to give away my code; the last thing I really care about is getting an email from some lawyer years down the line.

Now if I’m signing up to be a core contributor/maintainer of a project and you ask me for a CLA then I take issue.

Reply on news.ycombinator.com