There has been another one this month. A widely-used open-source project, the kind that sits three layers down in everybody's dependency tree, woke up one morning with a new licence and a blog post explaining why it was, in fact, good for the community. I will not name and shame, partly because by the time you read this there will be a fresher example, and partly because the specifics matter less than the pattern. The pattern is what I want to talk about.
The mechanics are always the same. A company stewards a popular project. The project is genuinely good, which is why it got popular, which is why a cloud provider started selling it as a managed service without sending so much as a thank-you card. The stewarding company looks at its revenue, looks at the hyperscaler's revenue, and decides that the only lever it has is the licence. So out goes the OSI-approved licence, in comes something with "Source Available" in the marketing and a clause that says you may do anything you like with this code except the one thing your competitor was doing with it.
I have a lot of sympathy for the people making these decisions. I really do. Watching a trillion-dollar company resell your work whilst you struggle to make payroll is not a hypothetical grievance, it is a real one, and "just monetise it better" is the kind of advice given by people who have never tried. The frustration is legitimate. I am not here to lecture maintainers about gratitude.
But I am here to say that the licence is not the asset they think it is, and changing it does not do what they hope.
what actually gets spent
The thing a project like this is built on is not the code. The code can be forked in an afternoon. What it is built on is trust: the quiet, accumulated confidence of thousands of engineers who chose to depend on it precisely because they believed it would still be theirs to use next year. That belief is the entire product. It is why someone put it into a production system that now cannot be ripped out without a quarter of work.
When you change the licence, you do not just adjust some terms. You retroactively rewrite the deal that every one of those engineers thought they had made. The code they shipped last year under one set of promises is now governed by another. Nothing they already deployed breaks, technically. What breaks is the assumption that let them deploy it without a lawyer in the room.
And here is the part the blog posts never reckon with. Trust does not come back at the price it left. You can revert a licence, and several projects have when the backlash got loud enough, but you cannot un-teach people the lesson they just learned. The lesson is: this can happen. Once an engineer has internalised that a dependency can be relicensed out from under them, they evaluate every future dependency through that lens. They reach for the boring Apache-2.0 thing instead of the exciting Source-Available thing. They build the abstraction layer they were too pragmatic to build before. The relicensing does not just cost you the goodwill of the people you annoyed today, it costs you the benefit of the doubt from everyone watching.
the fork is not the threat
The companies doing this tend to frame the fork as the worst case. A foundation picks up the last open commit, rallies the contributors, and ships a community version under the original terms. That has happened more than once now, and it is embarrassing, but it is not actually the deepest wound.
The deepest wound is the engineers who do not fork and do not stay. They just quietly stop choosing you. They were never going to file an angry issue or write a Hacker News comment. They were going to keep depending on your work for the next decade, and recommending it to colleagues, and contributing the odd fix. Now they are going to spend twenty minutes on the alternatives page and pick something with a licence they do not have to think about. You will never see them leave because they were never loud. The graph just bends, slowly, in the wrong direction.
I want to be careful not to turn this into a morality play where the maintainers are villains. They are usually exhausted people trying to keep something alive in an ecosystem that has no good answer to the free-rider problem. The licences they are reaching for, the various "Business Source" and "Server Side" and "Functional Source" variants, are honest attempts to solve a real and nasty incentive failure. I do not think anyone has cracked it. The hyperscaler problem is genuine, and "contribute back, you cowards" has never once worked as a strategy.
But I do think we keep mislabelling what is being spent. The conversation is always about revenue and competition and fairness, all of which are real. Nobody puts the actual line item on the invoice, which is: we are spending the thing that made us valuable in the first place. You can only do that once.
what I have started doing
Practically, on my own systems, this has changed how I evaluate a dependency. I no longer just check whether the licence is open today. I look at who controls it, whether there is a CLA that assigns copyright to a single company, and how that company makes money. A project with a permissive licence but a single corporate owner whose business model is in direct tension with that licence is, to me, a higher risk than a slightly worse project governed by a foundation. Not because the people are untrustworthy, but because the incentive points at the door.
That is a sad thing to have to do, and I resent slightly that it is now part of the job. The whole promise of open source was that I did not have to think about the politics, I could just read the licence and get on with it. The relicensing wave has made the politics load-bearing again.
So if you maintain one of these projects and you are staring down a hyperscaler, you have my genuine sympathy, and I do not have a clever answer for you. But please understand that the licence is not the lever you wish it were. The trust is the product. Spend it carefully, because the refund is terrible.