HN Reader

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

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

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.

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.

>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 emailed Stallman about the ethics of using AGPLv3 with a CLA to allow selling exceptions. Here's his reply:

https://news.ycombinator.com/item?id=42601846

  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.

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.

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?

[1] - https://jackson.dev/post/oss-licensing-sucks/

These days you just blindsight a project's community by instating a process heavy (you want the technical people to self-opt-out) 'board of governance', then put in place a draconian Orwellian regime in the name of 'safety', revoking project access from all that do not support the coup, or worse, still dare to speak out againt you.

> But a fork is not a simple matter; it is a lot of work, and will fail without people and resources behind it

Well yes. There is no free lunch. Open source only works if enough people are willing to give back. If your fork dies, that probably means the project had a lot of free riders.

The main issue i have with rug pulls is its essentially false advertising. They grew their customer base by promising open source and reneged when it was no longer convinent. This feels morally gross to me.

However i don't know that i actually am worried about the no longer making contributions aspect. Nobody is obliged to continue working on something forever. Its a totally normal thing for individuals to retire from a project, its fine for companies to stop too.

Why do we need to maximize profits? With current technology we shouldn't need to work 8 hours per day, maybe 2-3 hours max to maintain quality of living. Instead we should work to make everyone's life easier, including your own life of course.

This is causing management at the current company to run in circles a bit as well. The company has been fairly adamant about having support contracts for systems, and it has encountered a number of these stunts. Opscode with chef a long time ago, CentOS exit, VMWare, Broadcom has a number of more ugly things available in Tanzu.

And we were either paying these companies (looking at VMWare), or looked for quotes and intending to pay these companies. But suddenly, your configuration management is supposed to cost almost 6 digits per year. Very basic services should suddenly cost a mid-6-digit range per year for a basic suport contract. Sorry but what the fuck? And - again, looking at VMWare - even then we can't really rely on it?

I've been recommending to instead sponsor foundations, or straight up paying maintainers and developers of OSS we use regularly. The giggles when suggesting that have been getting quieter. But I'd rather hire a Proxmox/qemu dev than start paying the next VMWare.

> There is typically a spike in these clones after a relicensing event, suggesting that people are considering creating a hard fork of the project

That, or maybe people make a "snapshot" just in case. I don't believe many people seriously consider leading the effort of maintaining a fork...

I feel like the SSPL is almost a good open source license. I think there is a place for something a little stronger than the AGPL that is copyleft on necessary components even if they aren't directly linked. But it has a couple of major failings:

1. It's too vague about what is covered by it. This makes using such software risky in practice. Is the OS it runs on included? What about a log aggregator used to collect logs? Or a system backup system? The VM hypervisor and orchestration software for running the VMs that host it? I think it would be better if it was more clearly scoped to components that are specifically related to the service itself and not general purpose components of the hosting environment and/or things that could easily be substituted with other standard open source or off the shelf components.

2. It isn't compatible with AGPL or GPL. This is especially bad combined with 1. Does that mean you can't run the service on Linux? I don't think it could be compatible with AGPL code directly linked to it, but it could allow external components to be under most open source licenses.

IANAL, and don't know exactly how to word a license that fixed those issues, but I think there could be something better than the SSPL, and maybe such a license has a better chance of getting OSI approval.

Checks notes,

RIP VibeVoice Large 7B

https://arxiv.org/pdf/2508.19205

https://github.com/microsoft/VibeVoice

Nice to have forks & downloadable models now 'innit

I believe there should be a broader family of terms besides rug pull for when the intentions of vendors and developers change over time to become extractive and negative. No, enshittification is not the right word.

On a side note, if you had a quality OS like Linux with access to the source code but had to pay a small amount to get it, would you not pay?

Oh stop. When someone gives you free stuff and then changes the terms a little that isn’t a “rug pull” and it’s not “feudalism.” If you contributed a little and voluntarily signed a CLA this is also not a “rug pull.”

The whole reason for these “rug pulls” is abuse of the open source ethos by big companies using it as free labor for SaaS and giving nothing back.

SaaS is more like feudalism than any other software model, yet the open source community seems committed to making sure the SaaS industry can continue its free ride.

Part of why I’d hesitate to ever again make free (as in beer) software is this whole toxic shitty mentality. If I give you a ton of work for free, say thank you. If a bunch of investors fund that, say thank you. This entitlement mentality from a bunch of people with careers that mostly put them in or near the global 1% is gross. It’s not like you people need stuff for free. You ain’t poor.

A lot of words without any mention of copyleft, protective licenses, GPL. Difficult to take the article seriously.