The Community Corrosive Effects of CLAs (2021) | Hacker News Reader

The Community Corrosive Effects of CLAs (2021)

blog.hansenpartnership.com

73 pointspabs346 comments

It would be helpful to explain what DCO (Developer Certificate of Origin, terrible name!) and CLA (contributor license agreement) stand for. I managed to get the idea from context and google though it would have been nice to be explicit in the post.

The point about the balance of power and power dynamics involved is interesting. I think it applies more broadly as well. Are these really “agreements” when individuals have no ability to negotiate them? They seem more like playground rules.

You can fork the project and ONLY publish your contribution with the public license (i.e. GPL) instead of agreeing to also cede rights to the company.

One problem is discoverability. GitHub lists forks in an un-sort-able manner.

>One problem is discoverability. GitHub lists forks in an un-sort-able manner.

This obviously doesn't solve the problem generally, but I recently found an extension called lovely-forks[1], that automatically shows the most starred fork for every github repository.

1:https://github.com/musically-ut/lovely-forks

You have no power over Netflix terms and conditions, still you _agree_ to them, so it's an agreement even if its not byproduct of a negotiation.

Contracts of adhesion, yay.... /s

Good argumentation from very faulty assumptions.

The Developer Certificate of Origin is not a contributor license agreement. (See https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA.) It has no part that clearly says the contributor grants a license for their contribution, or on what terms.

This is the main disadvantage of the DCO, especially in non-GPL projects. Not that it "encourages distributed ownership". A contributor license agreement doesn't change who owns any copyrights, either. That's a copyright assignment. FSF's copyright assignment paperwork isn't a contributor license agreement, either. Assignment != License.

License grants in CLAs are often in different, broader terms than open source licenses for several reasons. For one, many open source licenses are ancient, without clear and complete license grants by today's standards. Second, part of the point of a CLA in many cases is to enable project stewards to change or legally upgrade license terms in the future. CLAs give them all the rights we can think of to license on whatever terms, so they're not caught short.

There is no reason CLAs for a project can't be shared openly.

If temptation to abuse of power were inevitable, we would see a lot more individual contributors to open projects who retained ownership of their copyrights suing project users about meaningless license violations for monetary settlements.

Companies like Elastic have changed to new licenses for future development. None that I'm aware of has tried to change the license terms for previously released open work retroactively, and there are serious legal questions about whether this is even possible or practical. Bloggers and tweeters sow a lot of unfounded fear about "evil corporate relicensing" by using loose terms that can imply, for those ready to see it, that there are releases floating around out there with Apache 2.0 license notices that aren't actually Apache 2.0 licensed anymore. What actually changes is that ongoing development by those companies moves to new terms, and folks interested in continuing development under the old license terms either do or don't step up to "fork" from the last release under those terms.

Are there any community open source projects that use CLA by the way? I've always assumed DCO were for community open source and CLA were for corporate open source.

The FSF requires copyright assignment or a public domain dedication for contributions to many of their projects. I'd consider that as equivalent to a CLA. The article mentions the Apache Foundation as requiring a CLA as well.

Meshtastic requires a CLA.

I don't understand how the advantage of the DCO is that the receiving organization does not have to track it: it's a declaration of authenticity that can be used to pursue remedies in court in the even of fraud. Contributors would need to sign and submit and organizations would need to track it for each separate contribution. A DCO is a CLA as far as I can see except on a per-contribution basis instead of on a per-contributor basis.

CLAs for foundations deserve considerable security, but that's nothing on CLAs for companies; I cannot ever see a good reason to sign on for one of those.

Microsoft requires a CLA. I have contributed small fixes before and am working on a smallish but bigger impact fix, and I’ll have no problem signing again.

Why is it an issue? I’m using their free product, and I’m making it better by contributing and them accepting the contribution. The CLA absolves me and absolves them and let’s them keep power over the licensing. Code bases with all sorts of “rights holders” for various pieces of the codebase are probably a nightmare to deal with if the license needs to be adjusted for whatever reason.

I’ve contributed bug fixes and small features to a bunch of CLA projects, and every time I do the project eventually rug pulls the license and replaces it with something that works exactly against my particular interests. I don’t get massively salty about it, but it’s kinda shitty and really makes me think twice about contributing to any CLA these days. Every time I see a CLA now I just think it’s some jerks crowdsourcing R&D from a community that they know they’re eventually going to shaft with a new commercial license.

I think this often cuts both ways and license changes are a last resort by project owners trying to find a sustainable path forward. Sentry being an example of this. Some (most?) OS projects have some company/organization behind them that is doing most of the work, I have no problem signing a CLA if that helps them continuing to exist by relicensing my contribution in some way. At least not if my contributions are pretty small scale, which I think most outside contributions are.

The Microsoft CLA is a key part of their classic embrace/extend/extinguish playbook.

For example?

They'll sunset the free-software project, and use your contributions for their proprietary spyware.

I appreciate that, but that’s not an example. It’s also not a description of embrace/extend/extinguish.

"Embrace" is indeed not in this example, but would depend on whether the project originally adhered to some community standard.

The "extend" part might map to maintaining or getting free labor for a project, maybe to eventually modify it in an incompatible way once sufficient usage share is attracted, if you can get other devs to do it.

"Extinguish" would then be breaking the public version completely while possibly still using the working code in proprietary software.

The "extinguish" part needs a CLA to be legal, or with, say, the GPL, they'd be required to publish the source of the derivative work.

s/security/scrutiny ?

How about because your changes won't be merged if you don't?

I guess you could go one level back and not make changes if there's going to be a CLA for them.

Merging a bug fix upstream relieves you of burden of maintaining it. It is good for both party, not just for upstream. I think signing corporate CLA, if required to merge, is quite reasonable in this case.

> It is good for both party, not just for upstream.

Indeed. Maybe, then, it's the corporations who should have a think about requiring a CLA?

Their business model may rely on dual licensing, whereas fixes coming from you are "nice to have"

That's me! At least, I read the CLA and when it contains things like "please sign away rights that the law specifically made unwaivable like moral rights to your work", that's me not contributing.

Sometimes that works for the CLA holder, sometimes it doesn't. As the FSF discovered when they tried to force the issue for gcc.

Define acronyms the first time they appear.

Agreed! The term CLA wasn't even defined in the article. I had to look it up.

PSA: CLA is Contributor License Agreement

Ok but WTF is PSA?

Sorry I don't understand the undefined acronym "WTF".

OK. But what is OK short for?

It's a misspelling of 0K, or 'zero Kelvin', meaning that there's no energy left to argue, so just 0K, whatever, let's go with what you're saying,

I thought OK meant "zero kills", as in "none of our soldiers are dead"

TL;DR

The old old joke is “all correct”. I want to say it was about Andrew Jackson’s horrible spelling.

> Define TLAs the first time they appear.

FTFY

(2021)

Added. Thanks!

Really weird to have rms as an example.

There is little chance of FSF changing the GPL as long as RMS continues to run it, given his monomaniacal, pathological obsession with software freedom at the expense of literally everything else, including basic human decency.

But he's not going to live forever (thank god) and his successors might try to use GPL4 as a political wedge within the FOSS community. Put in restrictions on project governance and codes of conduct, make a violation unrelated to the software itself terminate the license, something like that. "Ethical source" didn't get anywhere but something backed with the heft of FSF might. (Given how RMS has stacked FSF with loyalists, it's probably more likely that they'd do something to punish "ethical source" than enshrine it. Both are equally corrosive in my view.)

Or it might make FSF even less relevant. We'll see.

Stallman was right, continues to be right and will be right. Sadly.

I hope they don't invent a GPLv4 where nobody is allowed to use any code, period, then promptly switch all code under CLAs to it.

Even if something so absurd would happen, the version of the code from just before the change to a new license would still be available under the GPLv3. So everyone who wouldn't agree with this change (which would presumably be everyone), could simply fork the code from that point and continue under the GPLv3.

The more realistic risk of a CLA on GPL'ed code is that the person in control would switch it to a more permissive license without the copyleft restrictions of the GPL. That would actually have a negative impact that others can't mitigate by forking (although with a fork you could of course again make any new code added to the project the original license again).

I was attempting humor. The FSF's mission is definitely not to make code unavailable, but to permit tinkering.

But in seriousness, you are completely correct, and I agree with you.

There’s a CLA that places specific restrictions on how the contribution can be re-licensed: http://www.harmonyagreements.org/docs/ha-cla-i.html

I think it’s fair to demand that clarity. Keep in mind though that if a project is already using a permissive license it’s always going to be easy to make the project open core or for someone to make a proprietary work with your contribution.

Contrary to this article’s statements CLAs are actually easier for everyone involved at least on the second contribution due to the tools that exist. It’s just a checkbox on a PR.

Reply on news.ycombinator.com