> 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.
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.
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.
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.
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.
"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.
> 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]
> 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.
> 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.
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.
> Contributors and maintainers often have less power than even the smaller companies, and users have less power yet.
If contributors/maintainers are not happy with what the small company does, they can fork the project (assuming a liberal license) and continue in their own way. Valkey is a good example (with an interesting twist of license dynamics where Redis can use Valkey code now, but not the other way around).
> We have built a world where it is often easiest to just use whatever a cloud provider offers
And, IMHO, this is the major problem in the dev community these days - we've become lazy and focused on nonsense ("pretty"/unusable UIs, web gymnastics, llm, "productivity" etc.). We didn't have problems in the past to fork or reimplement OSes (various BSD instances), compilers (gcc versions), databases (MariaDB), and so on. There are tons of geniuses around hacking on cool stuff, but, sadly, the loudness of various hipsters and evangelists limits their visibility.
> Those providers may not contribute back to the projects they turn into services, though, upsetting the smaller companies that are,
The significant contribution that these providers (AWS, et al.) make to these projects is often overlooked - free advertisement. If I can remember correctly, ElasticSearch got popular when AWS started to offer it as a service. Additionally, cloud providers usually contribute (by employing core developers, shipping patches or testing) to the kernel, gcc or jdk, from which these small companies benefit significantly. In contrast, they themselves could do none of this.
But it is easier to blame "big scary clouds" than to rethink your business model. Be honest, start closed; no one will touch that and no one will be standing in your way.
Building the software you rely on from source by default is one way to reduce the impact these events have on you and shift the power dynamic. If you're installing binaries/images from a vendor (free or otherwise), transitioning to a fork may be an undertaking and a sweaty risk-assessment.
Switching your existing build-infra to sync sources from a new remote should be a snap.
Also no major need to hound maintainers to ship a release or merge that neglected bugfix or feature you desperately need - just cherry-pick it.
This is one of the reasons I like Guix so much: its packaging system treats source builds as the normal case, with binary packages available via caching. So if you go to install a package and there's no cached binary, Guix will happily build it for you on the spot, with bitwise reproducibility if it can. You still get the benefits of prebuilt packages, but you always have that escape hatch.
This also means that it's trivial to install a patched version of a package through the same package manager as everything else. No dedicated build infra required (though of course if you're deploying to a large fleet you may want to set up some build servers to avoid the need for rebuilds on most machines).
Debian has been like this in practice for at least 25 years (when I first switched to it).
The builds weren’t reproducible back then, but never mattered in practice for me personally. Now, the vast majority of the packages have reproducible builds, which is good enough for me. (Though these days I’m using devuan because I’ve never seen a stable systemd desktop/laptop that uses .debs)
Depends on the actual software licence, many commercial vendors do provide source code, however the licence doesn't allow you to do whatever you feel like with code, even if technically it is possible to do so.
This happens a lot in commercial products where scripting languages are used, for example.
Or enterprise consulting as another example, where the code is delivered as part of the project, but it is bound to the agency for compiling purposes, unless the customer pays extra for that right.
IMO if you're a technical decision maker, you should ignore fair source/business source stuff with extreme prejudice. These are fundamentally incompatible with the goal of having autonomy for your systems.
Only pick these if they're non-critical, have a significantly higher RoI, or a high commodity item.
This whole discussion is about FLOSS projects where the right to "do whatever you feel like with code" is well established - even literally so, in the case of purely private/internal changes that are not distributed to or publicly performed for any third party.
It's not possible to rug pull an open-source project by just switching new work to a different license. The real issue with open-source is that we don't live in a utopia where you can publish all of your work for free and still live a quality of life comparable to working at an average developer job, and yet so many non-maintainers somehow feel they are owed future labor. Maintainers come and go. Without sponsorship, the half life on maintainers is going to be relatively short, and more developers are going to be pushed to publishing less permissively.
I'm reminded of the infamous Mojang/Microsoft fiasco with the Bukkit community. They gave no support to a project, after "secretly" acquiring it when they hired some of the developers, letting a volunteer work hard for years maintaining it.
He was rightfully outraged when he discovered he had basically done years of free labor for Microsoft, and ended up leveraging a DMCA notice to shutter the project, due to the lack of a CLA and the inherent nature of Bukkit being ultimately glued onto the Mojang server jar to be useful.
I agree. Its an incentives issue if I am being honest.
If I ever generate software, I would also prefer to open source it but there are mechanisms where either cloud providers or anybody can take my changes and earn over them without me getting anything in return...
I mean, it is technically what it means to have a foss license but I just can't shake the feeling that we as a society are feeling so entitled that people are advocating against sspl licenses or etc. when I do think that if you are a dev and you wish to work on foss full time then something like sspl might be good in that regards.
Open source Contributors just don't get paid for the work they are doing. They are sadly doing free labour. I feel like I personally might start coding stuff in sspl or maybe just source available licenses if they get more favourable. The whole terminology behind source available licenses is kinda weird in the sense that basically a single clause which is meant to stop big cloud providers from selling your service that you built can make something like agpl foss and sspl not foss/source available.
You've touched on some interesting points here. I have also felt the entitlement, but while contemplating why it exists I came to the conclusion that it is due to a misplaced belief that open-source primarily benefits the individual and as such is a righteous crusade. While individuals may become beneficiaries in particular use-cases, I would argue that it is actually corporations that benefit the most, and not by a small margin. Just think of all that labor they get away with not having to pay for and all that specialized knowledge they don't have hire for. Then they also benefit from publishing libraries to end users so that their platforms may be more deeply integrated in customer's tech stacks. Meanwhile the guy maintaining the various open-source libraries that underpin those commercial services doesn't get anything at all. One might even be able to claim that open-source is predominantly an upwards transfer of wealth from engineers to executives.
AGPLv3 doesn't block folks from selling services based on your software, they just have to ensure their users can get a copy of the code. Also AGPL is FOSS.
>Elasticsearch contributors were Elastic employees; that, unsurprisingly, did not change afterward. OpenSearch started with no strong contributor base, so had to build its community from scratch. As a result, the project has been dominated by Amazon contributors ever since
So in a way the "rug pull" achieved what it wanted, amazon is now contributing to development.
I think discussing these "rug pulls" without discussing the destructive habit of many large companies to only profit without giving back misses the mark. Any community where there is a large imbalance between the ones doing the work and the ones profiting will over the long run become unstable.
> I think discussing these "rug pulls" without discussing the destructive habit of many large companies to only profit without giving back misses the mark
There's nothing destructive about using software in accordance to it's license, no one's puppy is being kicked.
The problem is too many developers and startups decide to be "paid" in exposure and use permissive licenses as a growth hack while chasing deployment counts and GitHub stars. They are perfectly fine with widespread, unpaid adoption until a hyperscaler with superior infra is involved, then suddenly the license becomes a liability. You can't have your cake and eat it.
> There's nothing destructive about using software in accordance to it's license
Doesn't this exact same argument work in the opposite direction too? In other words, the "rug puller" is just exercising their rights (explicit in a CLA, or implicit in a permissive license) to use a different license moving forwards. There's nothing destructive because the previous FOSS releases continue to exist and can be forked and maintained by the community if they wish.
> You can't have your cake and eat it.
So what's the alternative? Let's say you independently create an innovative backend/infrastructure software project in 2025, but one that doesn't lend itself well to a SaaS-only model. You require income from it to continue developing it. Realistically, what license do you pick on day one that doesn't doom you to failure?
It didn't achieve what Elastic wanted. It didn't lead to more people paying for Elastic licenses, it lead to users switching from Elasticsearch to a fork. And they eventually backpedaled and relicensed again under the AGPL.
Now, it might be better for the Open/elasticsearch ecosystem, because AWS is contributing more, and possibly the competition drives both Opensearch and Elasticsearch to be better. But on the other hand, there is now a split between two incompatible products, and Elastic has certainly lost some trust.
Elastic might be fine in the long run. But everyone I know(sample size <20 orgs) migrated to OpenSearch and never looked back. They were never interested in running Elastic in a separate cloud or running it themselves, and that's what a lot of these DbaaS providers have to overcome.
It's already annoying to create your first terraform module for a new AWS managed service, but they then want the users to have the extra complexity of VPC peering/privatelink/vpn and then manage that lifecycle as well.
AGPL/GPL require people to contribute forward to users, not back to maintainers. They also don't require any monetary compensation, which is what companies like Elastic are mainly after, not code contributions.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair, but I think it
is also more harmful.
On balance, using the AGPL is better.
What I understand from RMS's answer is that he recognizes that the solution of using the AGPL + a CLA for allowing to sell exceptions creates an imbalance/unfair situation where only one entity can engage in the activity of selling exceptions, but ultimately he cares more about user freedom, and finds the solution of using the GPL to avoid the imbalance worse because anynody could modify the SaaS code without redistributing it, which means that the users freedoms are not respected. Basically, the GPL doesn't protect much the SaaS code and is somewhat similar to a permissive license in this setting. The AGPL protects the code better.
RMS doesn't like the GPL for SaaS software for exactly the same reason they created the AGPL in the first place, and developer inconvenience is less of a concern than potential user freedom breach.
The entity to which the exception is sold could itself close the software for its own users. But so could it if the code was released under a permissive licenses and this is, critically, why RMS finds this acceptable: he doesn't want to consider releasing software under permissive licenses unethical. This is a limit he doesn't want to cross. After all, one can't be blamed for all the sins in the world and it's the company closing the code that would be doing non-free software, not the original authors.
AGPL+CLA doesn't enable more cases of users losing freedom than a permissive license, so this is okay for RMS.
Now, it is a view strictly focused in terms of user freedom outcome and that's probably how anything RMS says should be interpreted by default. Nothing prevents you from considering that there are other aspects to consider and that the imbalance AGPL+CLA creates is unacceptable.
On a side note, it makes me think of the Qt business model.
I understand why users get annoyed at "rugpulls", but if a company that is doing the vast majority of the work to develop and maintain a project is not financially sustainable they don't have that many options. An article like this really needs to include info about the financials.
I'm honestly curious since I've been considering how I license my large OSS projects lately [1], and I really do want to understand what would be "acceptable" here. Start more funding campaigns for the project? Work on it less? Sell merch? Openly communicate that they'll need to re-license without additional funding?
The hate comes from the company offering it under an OSS license and then taking it away. If they had started with a non-OSS license users wouldn't feel betrayed. Of course then they may not have had as many users, which is why they tried to be OSS to start with.
AFAIK, Mongo, Elastic, Redis, and Hashicorp were all doing fairly well financially when they did their "rug pulls". They maybe weren't doing as well as they wanted to, but they weren't on the verge of collapse either. In the case of Hashicorp, it was probably a strategy to sweeten the acquisition by IBM.
For nearly all open source projects, we are free riders. We use them and don’t contribute anything back. Open source is not about fair exchange; it’s about gift-giving and copying other people’s homework.
If you choose to give gifts to the world, that’s great, but you should go into it with your eyes open and not expect anything back. The world includes a lot of terrible people and you’re giving them gifts too. It’s okay to change your mind.
Calling it a “rug pull” when a software vendor relicenses seems like biased language. We still have all the gifts they gave us. It’s unfortunate that they changed direction, but nothing lasts forever.
This is not, strictly speaking, true. The example projects saw contribution in terms of code, testing, documentation, and - most importantly - marketing and evangelism.
These projects are not things put up on GitHub as a convenience that people just happened to adopt: the companies in question spent great sums of money encouraging adoption, usually with developer evangelists on staff who’d preach the technical advantages and talk about benefits of the licensing to convince people to use them.
It’s naive at best to position that as simple “gift culture” and claim it’s biased to call it what it really is: a rug pull.
In the case of Redis the company promised explicitly it would always keep the license for Redis core: until it didn’t. That’s a rug pull, plain and simple.
Accepting code and other contributions, encouraging other FOSS projects to rely on a project and then relicensing? Rug pull.
Show me a project that was not aggressively marketed for adoption using open source as a selling point and I’ll agree that’s not a rug pull. If Acme Corp just happened to have a GitHub repo for something under a FOSS license and people organically found and adopted it, okay. I’m not aware of any such examples, though.
"We didn't contribute anything" is mostly true for most of us. For people who do work on open source projects, it's still true for all the projects you don't work on, which far outnumber the ones where you do.
I think it's fair to recognize that giving gifts, especially repeatedly over a long time, can create an obligation as people become dependent on those gifts and alternatives they might have relied on otherwise disappear or never materialize in the first place.
And that's before going into the effort of other people that goes into making an open source project successful but who don't have any legal ownership over the source code and thus no legal say in the future of it.
It doesn't have to be that way though, companies and folks with money can give back and help projects they depend on to become sustainable. Start an Open Source Program Office, audit all the software you run, including dependencies, and make sure that they are all viable, by contributing back with dev hours and funding, and advocate that other related companies do the same.
Readit News
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.
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.
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.
It's open-washing
Deleted Comment
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...
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.
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.
True. Yet CLAs do not always give away all rights.
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.
If contributors/maintainers are not happy with what the small company does, they can fork the project (assuming a liberal license) and continue in their own way. Valkey is a good example (with an interesting twist of license dynamics where Redis can use Valkey code now, but not the other way around).
> We have built a world where it is often easiest to just use whatever a cloud provider offers
And, IMHO, this is the major problem in the dev community these days - we've become lazy and focused on nonsense ("pretty"/unusable UIs, web gymnastics, llm, "productivity" etc.). We didn't have problems in the past to fork or reimplement OSes (various BSD instances), compilers (gcc versions), databases (MariaDB), and so on. There are tons of geniuses around hacking on cool stuff, but, sadly, the loudness of various hipsters and evangelists limits their visibility.
> Those providers may not contribute back to the projects they turn into services, though, upsetting the smaller companies that are,
The significant contribution that these providers (AWS, et al.) make to these projects is often overlooked - free advertisement. If I can remember correctly, ElasticSearch got popular when AWS started to offer it as a service. Additionally, cloud providers usually contribute (by employing core developers, shipping patches or testing) to the kernel, gcc or jdk, from which these small companies benefit significantly. In contrast, they themselves could do none of this.
But it is easier to blame "big scary clouds" than to rethink your business model. Be honest, start closed; no one will touch that and no one will be standing in your way.
Switching your existing build-infra to sync sources from a new remote should be a snap.
Also no major need to hound maintainers to ship a release or merge that neglected bugfix or feature you desperately need - just cherry-pick it.
This also means that it's trivial to install a patched version of a package through the same package manager as everything else. No dedicated build infra required (though of course if you're deploying to a large fleet you may want to set up some build servers to avoid the need for rebuilds on most machines).
The builds weren’t reproducible back then, but never mattered in practice for me personally. Now, the vast majority of the packages have reproducible builds, which is good enough for me. (Though these days I’m using devuan because I’ve never seen a stable systemd desktop/laptop that uses .debs)
This happens a lot in commercial products where scripting languages are used, for example.
Or enterprise consulting as another example, where the code is delivered as part of the project, but it is bound to the agency for compiling purposes, unless the customer pays extra for that right.
Only pick these if they're non-critical, have a significantly higher RoI, or a high commodity item.
Guessing unrelated to the comment itself, prolly got a minor downvote army on my back after a different recent comment on Gaza matters.
Downvotes are just a noisy signal in general and I wouldn't read that much into a few here and there, it comes with the territory.
Oh and yeah, this meta makes for tedious threads so site guidelines and all that.
He was rightfully outraged when he discovered he had basically done years of free labor for Microsoft, and ended up leveraging a DMCA notice to shutter the project, due to the lack of a CLA and the inherent nature of Bukkit being ultimately glued onto the Mojang server jar to be useful.
https://blog.jwf.io/2020/04/open-source-minecraft-bukkit-gpl...
I mean, it is technically what it means to have a foss license but I just can't shake the feeling that we as a society are feeling so entitled that people are advocating against sspl licenses or etc. when I do think that if you are a dev and you wish to work on foss full time then something like sspl might be good in that regards.
Open source Contributors just don't get paid for the work they are doing. They are sadly doing free labour. I feel like I personally might start coding stuff in sspl or maybe just source available licenses if they get more favourable. The whole terminology behind source available licenses is kinda weird in the sense that basically a single clause which is meant to stop big cloud providers from selling your service that you built can make something like agpl foss and sspl not foss/source available.
https://github.com/fossjobs/fossjobs/wiki/resources
So in a way the "rug pull" achieved what it wanted, amazon is now contributing to development.
I think discussing these "rug pulls" without discussing the destructive habit of many large companies to only profit without giving back misses the mark. Any community where there is a large imbalance between the ones doing the work and the ones profiting will over the long run become unstable.
There's nothing destructive about using software in accordance to it's license, no one's puppy is being kicked.
The problem is too many developers and startups decide to be "paid" in exposure and use permissive licenses as a growth hack while chasing deployment counts and GitHub stars. They are perfectly fine with widespread, unpaid adoption until a hyperscaler with superior infra is involved, then suddenly the license becomes a liability. You can't have your cake and eat it.
Doesn't this exact same argument work in the opposite direction too? In other words, the "rug puller" is just exercising their rights (explicit in a CLA, or implicit in a permissive license) to use a different license moving forwards. There's nothing destructive because the previous FOSS releases continue to exist and can be forked and maintained by the community if they wish.
> You can't have your cake and eat it.
So what's the alternative? Let's say you independently create an innovative backend/infrastructure software project in 2025, but one that doesn't lend itself well to a SaaS-only model. You require income from it to continue developing it. Realistically, what license do you pick on day one that doesn't doom you to failure?
Now, it might be better for the Open/elasticsearch ecosystem, because AWS is contributing more, and possibly the competition drives both Opensearch and Elasticsearch to be better. But on the other hand, there is now a split between two incompatible products, and Elastic has certainly lost some trust.
It's already annoying to create your first terraform module for a new AWS managed service, but they then want the users to have the extra complexity of VPC peering/privatelink/vpn and then manage that lifecycle as well.
https://news.ycombinator.com/item?id=42601846
RMS doesn't like the GPL for SaaS software for exactly the same reason they created the AGPL in the first place, and developer inconvenience is less of a concern than potential user freedom breach.
The entity to which the exception is sold could itself close the software for its own users. But so could it if the code was released under a permissive licenses and this is, critically, why RMS finds this acceptable: he doesn't want to consider releasing software under permissive licenses unethical. This is a limit he doesn't want to cross. After all, one can't be blamed for all the sins in the world and it's the company closing the code that would be doing non-free software, not the original authors.
AGPL+CLA doesn't enable more cases of users losing freedom than a permissive license, so this is okay for RMS.
Now, it is a view strictly focused in terms of user freedom outcome and that's probably how anything RMS says should be interpreted by default. Nothing prevents you from considering that there are other aspects to consider and that the imbalance AGPL+CLA creates is unacceptable.
On a side note, it makes me think of the Qt business model.
I'm honestly curious since I've been considering how I license my large OSS projects lately [1], and I really do want to understand what would be "acceptable" here. Start more funding campaigns for the project? Work on it less? Sell merch? Openly communicate that they'll need to re-license without additional funding?
[1] - https://jackson.dev/post/oss-licensing-sucks/
If you choose to give gifts to the world, that’s great, but you should go into it with your eyes open and not expect anything back. The world includes a lot of terrible people and you’re giving them gifts too. It’s okay to change your mind.
Calling it a “rug pull” when a software vendor relicenses seems like biased language. We still have all the gifts they gave us. It’s unfortunate that they changed direction, but nothing lasts forever.
This is not, strictly speaking, true. The example projects saw contribution in terms of code, testing, documentation, and - most importantly - marketing and evangelism.
These projects are not things put up on GitHub as a convenience that people just happened to adopt: the companies in question spent great sums of money encouraging adoption, usually with developer evangelists on staff who’d preach the technical advantages and talk about benefits of the licensing to convince people to use them.
It’s naive at best to position that as simple “gift culture” and claim it’s biased to call it what it really is: a rug pull.
In the case of Redis the company promised explicitly it would always keep the license for Redis core: until it didn’t. That’s a rug pull, plain and simple.
Accepting code and other contributions, encouraging other FOSS projects to rely on a project and then relicensing? Rug pull.
Show me a project that was not aggressively marketed for adoption using open source as a selling point and I’ll agree that’s not a rug pull. If Acme Corp just happened to have a GitHub repo for something under a FOSS license and people organically found and adopted it, okay. I’m not aware of any such examples, though.
And that's before going into the effort of other people that goes into making an open source project successful but who don't have any legal ownership over the source code and thus no legal say in the future of it.