← Journal
7 September 20263 min read

Your open source dependency has a governance model, whether you checked or not

Redis relicensed three times. HashiCorp moved five products to BSL. The licence you built on is a property of who controls the copyright, and that is knowable in advance.

Choosing a dependency is usually framed as a technical decision — does it work, is it maintained, is the API sane. There is a second question that gets asked far less often and has been considerably more expensive lately: who can change the terms, and what stops them?

The recent record is not reassuring. Elastic relicensed Elasticsearch under SSPL in 2021, and AWS forked it as OpenSearch. HashiCorp moved Terraform, Vault, Consul, Nomad and Packer to the Business Source License in August 2023, which produced OpenTofu and, eventually, IBM's lawyers pointed at it. Redis went through three licence changes.

None of those companies did anything unusual. They owned the copyright, the economics were difficult, and they changed the terms. That is what owning the copyright means.

The predictor is structural, not moral

The useful finding is that this is forecastable, and the signal is governance rather than intent.

When a project is stewarded by a neutral foundation rather than a single vendor, no one company controls the copyright or the roadmap, and a unilateral licence change becomes very hard to make. Foundation-hosted projects rarely relicense — not because the people are more virtuous, but because the mechanism that makes relicensing possible is absent.

Single-vendor open source, by contrast, has a structural pressure toward relicensing that has nothing to do with the founders' sincerity. The company must eventually monetise. The most common lever is restricting the terms under which competitors — usually hyperscalers — can offer it as a service. When that pressure arrives, the copyright assignment you agreed to in the contributor licence agreement is what makes the change legally straightforward.

So "will this project rug-pull" is largely answered by "does a single company own the copyright, and do they have an unsolved business model".

What the fork actually costs you

The reassuring story is that the community forks, the fork finds a foundation, and everyone carries on. That is broadly what happens — OpenSearch and OpenTofu both exist and are healthy, and forks that emerge under a foundation tend to have more organisational diversity than the original.

The cost is not that the software disappears. It is the migration nobody budgeted.

You now have two projects with diverging APIs, a decision to make under time pressure without good information about which will be maintained in three years, managed-service providers picking sides, and a period where documentation, tutorials and Stack Overflow answers refer ambiguously to both. For a small team, that is weeks of unplanned work triggered by an announcement you had no input into.

How to price this before you adopt

None of this argues against using single-vendor open source. Much of it is excellent, and refusing to touch anything not foundation-governed would rule out a great deal of good software.

It argues for pricing the risk when you choose, rather than discovering it later.

Check who holds the copyright. A contributor licence agreement assigning copyright to a company is the mechanism that enables relicensing. Its presence is public and takes two minutes to establish.

Check the licence, not the word "open". BSL, SSPL and various source-available licences are not open source under the OSI definition, and several have restrictions that matter if you host software for clients. "Source available" and "open source" are used interchangeably in marketing and mean different things in a contract.

Notice how deep the coupling goes. A library behind an interface you control is a manageable exposure. An orchestration tool your entire deployment pipeline is written against is not. Depth of coupling, not licence risk alone, determines what a relicensing event costs you.

Ask what happens if this doubles in price. That is the commercial form of the same question, and it is the one a client will eventually ask you about your own stack.

The part that is easy to forget

If you build software for clients, you are also answering for your dependencies. When a licence changes underneath a system you delivered two years ago, it becomes your phone call — regardless of who made the decision.

That is a good reason to know, for each significant dependency, who owns the copyright and what their business model is. It takes an afternoon for a typical stack, it is a document you write once, and it is a considerably better position than finding out from a blog post.

open sourcelicensingriskprocurement

Building something like this?

We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.