5 ms·
> 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
by palata 1y ago
> 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.
- goodpoint 1y ago> If you use a permissive licence, then a rug pull is part of the deal. True. Yet CLAs do not always give away all rights.
- charcircuit 1y agoThere is no such thing as a rug pull in regards to open source. A GPL copy of your code will exist forever.
- zozbot234 1y agoYes, it's a pretty weird notion. The only "rug pull" is wrt. ongoing maintenance of the project, but any maintainer may end up abandoning their own project for any reason or no reason at all. This is why essentially all FLOSS licenses have long provided for the right to fork the existing codebase under a new maintainership.
- Spooky23 1y agoUnless you can sustain a fork, it is a rug pull if you’ve incorporated the software in other projects. Imagine if a non-trivial critical project like OpenSSL had this happen. Shitty behavior like this is more common with software both OSS and commercial than in the past. Treat any meaningful software engagement like a celebrity marriage.
- sparkie 1y agoThe biggest issue is that companies which depend on something like OpenSSL do not do enough to sustain it, leaving its maintainers working often uncompensated, for the benefit of people making far more money. Would it be a rug pull if those maintainers simply burned out and decided "I'm moving onto something else," Leaving the project in limbo, with nobody maintaining it? Or maybe they really do enjoy working on the project, but it doesn't pay the bills, so they have to look for an alternative way to monetize it, and that way can continue working on it. My opinion is that unless you genuinely just enjoy working on something and sharing it, you are not obliged to do unpaid labour for the benefit of anyone else. Companies depending on FOSS software should be contributing financially to each and every one of them. This is the real shitty behavior - the expectation these companies have of getting bugfixes and improvements for free. In the Mongo/Elastic and Amazon cases for example, this is far smaller companies being taking advantage of by a giant. IMO they were right to "rug pull" by relicensing under SSPL. Amazon can easily afford to maintain forks for these projects - but it probably would've been cheaper for them to just contribute financially, and they wouldn't have needed to switch from AGPL. Anyone who works on OpenSearch without compensation is a fool - essentially doing unpaid labour for one of the wealthiest companies on the planet.
- Ekaros 1y agoI find it weird that companies do not have explicit plans for each dependency they pull in. In case of maintenance is dropped and there is critical vulnerability. Being able to fully support each and every dependency you use should be absolute minimum for any commercial project.
- thayne 1y ago
- account42 1y agoYou are ignoring the network and branding effects. The original maintainer removing themselves from the project leaves space for someone to take it over. The original maintainer taking the project proprietary means any replacement based on the last open source code needs to re-build the community from near zero.
- 01HNNWZ0MV43FF 1y agoThe pull is that a CLA allows someone to circumvent the GPL at some point in the future at their leisure It's open-washing
- jenadine 1y agoIn case of dual license, this is the stated goal so there is no "pull". (Unless they stop with the GPL version, but I'd say this is unlikely)
- hedora 1y agoThough note that redhat is doing this with all GPL software, but without a CLA. They retaliate against customers that share source code, and claim that this doesn’t fall under the “without further restrictions” clause in the redistribution of source code phrase in the GPL. Anyway, rug pulls are apparently possible, even with the GPL, at least until this is taken to court and IBM loses.
- paulryanrogers 1y agoHow does Rocky Linux continue to get timely updates from upstream? Do they have to use shells or other subterfuge?
- hedora 1y agoIt looks like they’re not RHEL compatible any more: https://www.zdnet.com/article/rocky-linux-9-arrives-with-everything-you-need-to-replicate-the-distro-on-your-own/ https://www.zdnet.com/article/rocky-linux-9-arrives-with-eve... That says they pull from CentOS Stream, which I think is upstream from RHEL.
- paulryanrogers 1y agoAccording to this other article [0] they still aim for 1:1 compatibility with RHEL, and not Stream. I also don't see any mention of Stream in the Rocky 9 release notes. EDIT: I wonder if Rocky is still following their original plans to leverage rented VMs [1]? [0] https://linuxiac.com/rocky-linux-confirmed-to-remain-fully-compatible-with-rhel/ https://linuxiac.com/rocky-linux-confirmed-to-remain-fully-c... [1] https://rockylinux.org/news/keeping-open-source-open https://rockylinux.org/news/keeping-open-source-open
- deleted 1y ago[deleted]
- kelnos 1y ago"Open source" is more than just GPL. MIT, for example, can be made proprietary. And yes, the last version of that MIT-licensed source will exist forever, but, in practice, forking and maintaining that fork can be a tireless, difficult, painful endeavor that most people will not have the time and energy for.
- goku12 1y ago> 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=individual https://canonical.com/legal/contributors/agreement?type=indi... [2] https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde...
- echelon 1y ago> commonly are subject to rug pulls This open source purism is toxic. Projects have to be sustainable. Hyperscalers have hoovered up the entire Internet and own the entire mobile device category. We're over here bickering about small developers writing source available / OSS-with-CLA. If the community cares so damned much, they can take the last open version and maintain it themselves. Please take all of this negative energy and fight for a breakup of big tech instead.
- dapperdrake 1y agoAnd this has always depended on hardware and never really software.
- DaSHacka 1y ago"The issue you care about is toxic. You should care about the issue I care about instead!"
- cycomanic 1y agoThat's misinterpreting what the previous poster is saying. They are saying that hyperscalers owning significant portions of the Internet (and using lots of projects without giving back) is a bigger threat to the sustainability of OSS. Now I would argue that the sustainability of OSS is more important at least in the context of an lwn article. That doesn't mean one can not argue that rug pulls are the bigger threat, but that's not what you accused the previous poster off.
- socalgal2 1y agowhich hyperscalers are we talking about specifically? Microsoft, Google, Apple, Facebook, all gives tons of open source support. I think Amazon does too but less familar. So who are these hyperscalers you're claiming don't give back?
- kelvinjps10 1y agoBut what about GNU their projects require signing a CLA and I don't think they will do a rug pull
- bayindirh 1y agoThere's also Eclipse Project's CLA and DCO. They are going for 20+ years.
- sokoloff 1y agoI think there are two differences there: FSF wants to be able to relicense as/if the legal landscape evolves, but in a way consistent with the original license aims. I fully support this (and I want to give them this flexibility), but admit that this is based on my trust in FSF more than anything else. FSF wants a contribution agreement to ensure that it doesn’t have to litigate with 1000s of companies who might claim some contribution that an employee of theirs made was corporate IP*. I also understand this, particularly given the incentive for a company to intentionally cause a “tainted” contribution to get into FSF products. My willingness to “go along” with an FSF CLA is much, much greater than for a random company who wants to trade on and benefit from the goodwill of the “we’re open-source!!” banner and yet be able to rug-pull later. * - I think I have exactly one tiny change into emacs from decades ago. It took me way longer to get corporate sign off on the CLA than it did to author the change.
- phkahler 1y ago>> My willingness to “go along” with an FSF CLA is much, much greater than for a random company who wants to trade on and benefit from the goodwill of the “we’re open-source!!” banner and yet be able to rug-pull later. FSF is the only organization that I would trust with a CLA. Everyone else has mixed motives. As this stuff keeps happening I think the GPL will regain popularity.
- wizzwizz4 1y agoConsider adding the Software Freedom Conservancy to that list: I'd even trust them more than the FSF.