Rug pulls, forks, and open-source feudalism

> 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.

> 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.

There is no such thing as a rug pull in regards to open source. A GPL copy of your code will exist forever.

Yes, 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.

> 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...

The pull is that a CLA allows someone to circumvent the GPL at some point in the future at their leisure

It's open-washing

> 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.

Unless 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.

And this has always depended on hardware and never really software.

But what about GNU their projects require signing a CLA and I don't think they will do a rug pull

There's also Eclipse Project's CLA and DCO. They are going for 20+ years.

The 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.

Though 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.

How does Rocky Linux continue to get timely updates from upstream?

Do they have to use shells or other subterfuge?

I 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.

That depends on what's written on the CLA.

"The issue you care about is toxic. You should care about the issue I care about instead!"

>> 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.

The text includes this specification: "The Foundation promises that all distribution of the Work, or of any work "based on the Work," that takes place under the control of the Foundation or its assignees, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms". So you're right, in principle the FSF could apply the AGPL to every software they have copyright assigned for, but they also have to be careful not to breach the terms of their own contract.

As to the SSPL and similar license, the FSF hasn't publicly commented on it but they also don't include it in their list of approved free software licenses, so we know that the FSF doesn't really think the line could/should be drawn far from the GPLv3 and AGPL.

Neither you nor the parent comment are using rug pull in the sense of the article.

Consider adding the Software Freedom Conservancy to that list: I'd even trust them more than the FSF.

While I generally don't sign CLA's, I will occasionally consider one if the CLA is to a nonprofit foundation which has strong governance in place to prevent restrictive re-licensing. However, sense these cases have to be very carefully evaluated on a case by case basis, it is very rare that I would even consider it.

For a long while I was using MIT a lot, these days I have started switching to GPL especially for anything significant.

All because of the nonsense and all the rugpulls.

It looks like they’re not RHEL compatible any more:

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.

I 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.

In my experience, the usefulness of any particular license is only as good as your ability to enforce it in court.

That'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.

In 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)

If you're not paying or contributing, who are you to complain if the maintainer(s) stop working for free? The level of entitlement is amazing.

Using a license that contributors trust your project to abide by is far more useful than any potential litigation that may or may not happen.

It's also a risk for the other side. Big companies wouldn't take the risk to go in court, they'd rather not use your project.

> 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.

That has not been my experience... instead, they realize that struggling individual developers cannot and do not want to fight for their rights, so they openly abuse them knowing nothing will happen.

Unless you are the size of Google, it just isn't feasible. Most companies don't have the resources to fully support every piece of their tech stack. It would be more practical if the cost of continued maintenance was spread among all companies that depended on the dependency, but I'm not sure how best to accomplish that.

> 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.

You could say that about anything though. A bakery has dependenices on fruit suppliers, flour suppliers, paper and wrapping suppliers, the baker(s), the cashier(s), etc. All of which could disappear and they'll have to find new ones

which 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?

There are also plenty of massive, popular open source projects which don’t require much if any ongoing maintenance. OpenSSL-ish things are the exception, not the rule.

Of the rest, it’s fine to keep using old versions of things…however, things with ecosystems that move on or contributors/users that fetishize “actively maintained” as a use-this-not-that indicator can complicate that decision.

Yep. They have to pool resources and effort to make it make sense. That requires some mechanism of coordination that pulls in enough participation to keep it representative. I'm all over this. PrizeForge's Elastic Funding was designed expressly to create meaningful cooperation between businesses, prosumers, and regular users of all shapes and sizes.

"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.

Can you explain why anyone would trust the SFC over the FSF? The FSF are effectively zealots with a specialized interest. I can understand saying that donations might be better spent with the SFC, but I am not sure that translates to more trust.

GPL pretty much guarantees Google won't use you code.

Although in this post "Do no evil" world that may no longer be true.

And even if it is, Google don't need to use your code. They have enough resources to clean-room re-engineer pretty much any useful piece of code ever written - perhaps short of Linux, MacOS, and Windows.

If Google decide they need to use your GPL Open Source project, they'll just assign a team to fully document it while meticulously not using any copyrightable text from your project in their version of the documentation, then assign a different team to write software that matches their own internal documentation - most likely in a different language - probably Golang.

Or more likely, they'll make sure there are enough subpoena-able internal internal comms to make it look like they did that, then just get some external-jurisdiction non-english-speaking intern to use Gemini to copyright whitewash the Golang rewrite directly from your open source code.

(I just sat here for 5 minutes trying to work out how to end this post on a positive note - but I've got nothing...)

The positive note, I think, is that Google won't use your software and you won't have to deal with Google problems as a result :-)

I disagree, we remember the cases where companies egregiously breach the license, we don't remember the cases where they just comply.

GPL is at least setting your expectations. With MIT can you even call it a rug pull? The entire point is to let companies do that sort of thing.

Is that a bad thing?

I don't write code specificly so google can use it. If they find it useful and are willing to abide by the license, then by all means great, but if they don't want it, that is their business.

As far as white room reimplementations go - why would i care about that at all? Its no longer my code at that point. Copyright is not a patent, all that is their right to do. Just like i have the right to do the same thing to them. (How do you think our nice linux computers manage to interact with proprietary protocols?)

But how can we be sure that the same "nothing" wouldn't have happened with any other (or no) license in most cases?

Did the lock I put on my door actually prevent anyone from breaking in if nobody ever tried?

In my mind, regardless of your license, you still have to be able to defend your rights, or you don't really have any.

SFC are the same as FSF effectively, or even better. Their GPL lawsuit against Vizio for example is brilliant, they are suing as a third-party beneficiary of the GPL, rather than as a copyright holder. If they win then it means any recipient of GPLed binaries can sue for compliance.

https://sfconservancy.org/copyleft-compliance/vizio.html

They are also the only folks doing GPL compliance work for the Linux kernel and hardware vendors.

Indeed, see for example Vizio (or Tesla) or many other examples.

https://sfconservancy.org/copyleft-compliance/vizio.html

> SFC seeks to confirm in the courts that purchasers of devices running Linux and other software with reciprocal licenses like GPLv2 have a legal right to ask for, and receive, the source code for those devices, so they can adapt the software to their needs, and make practical use of those adaptations by being able to install those changes back onto the devices they purchased.

Specifically the last part of that sentence, unfortunately I'm not very hopeful that it will happen, since v2 does not have the same anti-tivoization clause that v3 does, and Linus has personally said that he wants people to be able to lock down their products.

My own personal experience with SFC, EFF and FSF is also that they will only agree to take on a case for you if they happen to want to do it, and if you sign over all copyright ownership to them, which I think a lot of people are not willing to do.

I don’t think there so much conspiracy.

The big companies could just be a huge collection of disconnected small teams of 2nd rate developers who have little understanding of software licensing and are just trying to ship a product.

Not an excuse though.

Of course, it doesn’t help that annual training focuses on trade compliance and ethics with no mention of licensing.

Hell, I’ve never seen a policy on the use of commercial clip art…

GPLv2 has the same requirements as GPLv3 around installation of modifications. The GPLv3 also doesn't prevent what TiVo did; breaking the proprietary software when run on modified GPLed software. TiVo didn't prevent installation of modified GPLed software, and didn't think it was legal to do that.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

Linus doesn't want people to enforce the GPL in general, not just the lockdown case, he has been arguing against that for a long time.

IIRC SFC has a contract option to enforce your copyrights without being the owner of them, I've seen that contract on paper at conferences. They also have limited resources, so can't take on every case.

> GPLv2 has the same requirements as GPLv3 around installation of modifications

I disagree:

> Stallman found this practice (using crypto lock-down to force the proprietary software to fail) illegitimate. He noted publicly that GPLv2 didn't prevent this behavior, and wanted (and wrote, as explained below) a GPLv3 draft that prohibited that behavior.

I think the author is sometimes (but not always) conflating software installation instructions with the ability to actually usefully install different versions of the software.

At one point he specifically claims that GPLv2 required "a functional installation method", but gives no citations of this in any actual clause of the GPLv2, nor cites any court cases where this was argued either way, and even admits that many lawyers believe that a working installation method is not required (and gives no evidence otherwise because saying he personally disagrees).

> there was a clear installation requirement in GPLv2 — the word “install” appears prominently

Except the only time the word "install" actually appears is in this part:

> scripts used to control compilation and installation of the executable

And I would argue that it's going to be entirely up to every individual judge's 50/50 interpretation as to whether "scripts used to control installation" actually implies a working method of installation as well.

Not only that, but TiVo's "forcing the proprietary software to fail" practice is IMO a completely different legal issue from not even having a method of installing different software on a locked-down device in the first place.

TiVo happened to have a method to do that already, but many devices since then (which use Linux kernels) do not have a way to actually modify any software, and for good reason IMO (e.g. safety/regulation such as in aerospace/defense/medical/automotive industries). And they are not getting sued or called out by anyone to my knowledge... but please prove me wrong.

If the judge has read the GPL preamble, they would understand the intent of the license, and I would guess that would make it a 90/10 chance of requiring a working install method.

That’s basically what RedHat is (was?) for

There's several ways to do it:

- incorporate

- foundation (a subtype of incorporating)

- government

- cooperatives

The trouble with corporations is that they do have interests that are very independent of their customers and they are not good agents (principle-agent problem). RedHat, partly because they could not figure out better ways to monetize, has increasingly fought gadgets with gadgets, creating service contracts for support interfaces for open-core products and so on. This does not maximize the value delivery of open solutions.

Government is not known for speed or efficiency. Good luck getting the average Joe to understand why your little git repo needs to come out of his payroll. Even if you get something passed, now all Joe hears on the radio is about how you're stealing his paycheck. Less learned: narrow interests are easy political targets. Okay so let's do a foundation!

So how about foundations? Every single git repo needs a foundation? That's a lot of overhead. Foundations have a scope. They can also suffer from principle agent problems. Foundations are a good solution, but they themselves have not really adapted to the information age. Rigid, self-serving governance can easily become entrenched by insiders who beat the drum while cashing checks.

PrizeForge solve a lot of these problems just by being very broad in scope and very neutral as far as interests. More payment is better. If the market wins, we win. We don't really have to care who or why but we should try to protect customer value by making money smarter and creating the means of coordination so that nobody moves alone.

PrizeForge is not good yet. But it will be. Our solution for the principle-agent problems will completely change how we do social. To start, we've started operating our fund-matching systems. Those will help us bootstrap faster. We can serve some of the communities we know well while building up the rest of our features. (Log in after a few hours, I'm currently doing maintenance).

If we are going to use this metaphor, its not about putting a lock on the door but having a door at all.

You need locks to protect yourself from malicious people, you need a door just to indicate that people shouldn't randomly come in. MIT is like not even having a door. There is no point in buying a top of the end lock if you leave your door open and hang a sign saying free cookies.

I would also disagree that hard power is the only possible way to defend one self. Soft power has its place too and can often offer you much more bang for your buck.

Second source is not too hard concept. You should have second supplier ready to go for your business critical supplies. Or be ready to produce those yourself in case of software.

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.

I've never worked at Google, but I'd be shocked if they won't use GPL code.

AGPL, sure, as lots of companies won't touch AGPL code (so, if you don't want companies to use your code, license it under AGPL).

But GPL is so commonly used and pretty well understood how to use it productively and safely and still run a profitable company. Avoiding it entirely seems extremely wasteful, at a scale that even Google probably won't be able to choose to.

Any Googlers/x-Googlers care to summarize the open-source usage policy?

IANAL, but my understand is that legally, the preamble is not part of the terms of the copyright license itself and if the preamble can be construed to provide something, but the actual license does not contain it, then it's not part of the license terms.

I'm willing to bet a pretty large amount that any judge with such a case before them will read the preamble in the course of the proceedings.

> If they win then it means any recipient of GPLed binaries can sue for compliance.

I hope they win the case (meaning, I think it's both morally and legally correct), but I hope that the conclusion of the case is not what this sentence says.

I don't want "company uses GPL software and takes pains to not distribute it [they run it only internally]; disgruntled employee finds a way to smuggle a copy of the binaries out, gives that copy to someone else; now that someone else can now demand enforcement of the GPL terms" to be legally supported.

To me, that's entirely different from "I use GPL software to make a TV and I sell that TV to anyone who will buy it." In that case, any buyer of the TV should be entitled to use the terms in clause 3 & 6 of the license and receive the source code that's covered by GPLv2.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html (clause numbers above refer to this license)

The GPL also says:

> Activities other than copying, distribution and modification are not covered by this License

I am interpreting this to mean that "installation" does not count as any of those things. It even says "The act of running the Program is not restricted", and to me that means I am free to restrict how/if the program can run in the first place, which I believe is what TiVo did.

Linus even admits "Tivo never did anything wrong", and honestly from a license perspective I'd rather be on the good side of whoever wrote the thing I'm using, as opposed to an outsider who thinks I might be using the license wrong, and is no party to any case I might be involved in.

Either way this Brad guy seems to go on a lot about how he thinks everyone else is wrong, while also never showing any evidence that his interpretations have ever played out successfully in court... so I think it's at least safe to say that for now, "we don't know" if installation is covered or not, until it's actually tested in court.

And even then, one judge may interpret it differently than the next one, so maybe there can't be a universal answer unless the license is modified to be more clear.

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.

That's not what "recipient" means: it's a term of art. If I want the source code to your private fork of my GPL'd software, and I see your old laptop on Craig's List, I can't buy the laptop, recover the undeleted binaries from the hard drive, then sue you for the source; this ruling wouldn't affect that.

Thank you! That's what I was looking for.

The FSF is also the one organization that effectively already has a CLA via the "version n or later" clause commonly used with GPL licenses. The question then is of course why they'd need a real CLA on top of that.

According 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-c...

[1] https://rockylinux.org/news/keeping-open-source-open

> 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.

You 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.

> Good luck getting the average Joe to understand why your little git repo needs to come out of his payroll.

That specific problem could be solved by funding it from taxes that only tech companies have to pay. Maybe something like how FDIC works, where if you want to sell SaaS, you need to pay for some kind of security insurance from the government, and the funds from that are used to support open source projects.

Of course, there are other problems with having the government do it, but I think the taxes issue is solveable. And personally, I'd rather see my taxes spent on helping open source software than military and weapons.