←back to thread

275 points pabs3 | 6 comments | | HN request time: 0s | source | bottom
Show context
palata ◴[] No.45148071[source]
> Projects with CLAs more commonly are subject to rug pulls; projects using a developers certificate of origin do not have the same power imbalance and are less likely to be rug pulled.

Would be worth explaining why: my understanding is that if you sign a CLA, you typically give a right to relicence to the beneficiary of the CLA. So you say "it is a GPL project, my contribution is GPL, but I allow you to relicence my contribution as you see fit".

If the project uses a permissive licence already, honestly I don't really see a big impact with signing a CLA: anyone can just take the codebase and go proprietary with it. However, if it is a copyleft licence, then signing a CLA means that the beneficiary of the CLA doesn't play by the same rules and can go proprietary with the contributions!

If you don't want a rug pull, you should use a copyleft licence and not sign a CLA: nobody can make Linux proprietary because the copyright is shared between so many people.

If you use a permissive licence, then a rug pull is part of the deal.

replies(5): >>45148427 #>>45148502 #>>45148634 #>>45148648 #>>45148948 #
1. goku12 ◴[] No.45148634[source]
> my understanding is that if you sign a CLA, you typically give a right to relicence to the beneficiary of the CLA.

Just to clarify, this depends upon the exact CLA you sign. Canonical's CLA (CCLA) [1] for example, contains this clause in Section 2.3 Outbound license:

> We may license the Contribution under any licence, including copyleft, permissive, commercial, or proprietary licences. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the licence or licences which We are using for the Material on the Submission Date.

This means that they promise to release your contribution under the original license as well. Or in other words, they won't relicense the old contributions retroactively. There may be other CLAs that don't make this promise. It's generally a good idea to read and understand what you are signing up for. (Applicable for any agreements, not just CLAs, since your argument is to avoid them.)

Almost all CLAs let the contributor retain the copyright. (If I understand correctly, copyright transfers are involved only in CAAs.) So that option is also available for you to do whatever you want to do with your contributions. In any case, the actual problem is the breach of an unwritten trust you place in the project owners. Since you generously contributed your work to them and everyone else, you'd expect the same favor in return for the contributions by others in the future. But CLAs leave that open and under the sole control of the project owners, primed for a rug-pull. The only way you'll ever get the benefit of those contributions after a rug-pull is if you collaborate directly with the other contributors - a fork in essence.

> If you don't want a rug pull, you should use a copyleft licence and not sign a CLA

There is an odd and particularly hideous combination of those two - AGPL + CLA. I'm generally a proponent of AGPL. However, I believe that this combination is worse than a permissive license + CLA. Copyleft licenses require you to supply the source code (including your custom modifications) upon request to anyone you distributed the application to. In AGPL, the use of an online service also falls under the definition of 'distribution of application'. So you have to distribute the modifications of the server-side code to anyone who uses your service. I see this as a good thing - because someone else with a lot of resources can't just improve and host your service, denying you the benefit of those improvements. However with a CLA, the project owner (perhaps a company) can host a relicensed version with undisclosed improvements, while you will be forced to reveal your improvements if you try to do the same (since you're using AGPLed code). You wouldn't have the same problem if the source was under a permissive license + CLA.

But here is where it gets particularly egregious. The above problem can also affect software under just a permissive license and no CLA. This is what happened to Incus and LXD. LXD was initially under the Apache license and the linux containers community, in collaboration with Canonical. One fine morning, Canonical just decided to take control of the project, prompting the linux containers community to fork it as Incus. For a while after that, both projects used to borrow code from each other since they had the same license. But then Canonical decided to relicense LXD under AGPLv3 + CLA. This means that it was no longer possible for Incus to borrow code from LXD due to license incompatibility, while Canonical continued to do so under a slightly odd arrangement. You can read about it in detail here: [2]

[1] https://canonical.com/legal/contributors/agreement?type=indi...

[2] https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde...

replies(2): >>45153165 #>>45167386 #
2. palata ◴[] No.45153165[source]
> This means that they promise to release your contribution under the original license as well.

To me it sounds like they reserve the right to use my contribution in their proprietary code as they see fit... My point was that by using a copyleft licence and not signing a CLA, I prevent them from using my contribution in a proprietary fork.

replies(2): >>45153696 #>>45156744 #
3. socalgal2 ◴[] No.45153696[source]
> I prevent them from using my contribution in a proprietary fork.

You effectively prevent your contribution from being merged back into the original project. This generally means your contribution isn't likely to be used. It will sit in its own repo for others to find.

replies(1): >>45159917 #
4. goku12 ◴[] No.45156744[source]
You're right on both counts. My reply is supplemental to your comment and not its correction. I was just adding information about some pesky corner cases for anyone who's interested in it.
5. palata ◴[] No.45159917{3}[source]
Well, in practice if they require that I sign a CLA, I just don't bother contributing :-).

Of course they don't care because someone else will work for them for free, but that won't be me.

6. account42 ◴[] No.45167386[source]
> But here is where it gets particularly egregious. The above problem can also affect software under just a permissive license and no CLA. This is what happened to Incus and LXD. LXD was initially under the Apache license and the linux containers community, in collaboration with Canonical. One fine morning, Canonical just decided to take control of the project, prompting the linux containers community to fork it as Incus. For a while after that, both projects used to borrow code from each other since they had the same license. But then Canonical decided to relicense LXD under AGPLv3 + CLA. This means that it was no longer possible for Incus to borrow code from LXD due to license incompatibility, while Canonical continued to do so under a slightly odd arrangement. You can read about it in detail here: [2]

Well yeah, that's what you sign up for with a permissive license. Canonical could have just as well kept their changes closed source - here Incus (or others interested in Canonical's changes) at least had the option to also adopt the AGPLv3.