License change and relicensing: the complete guide.

License change and relicensing is the act of replacing the legal terms that govern a software project. The code may look the same the day after a relicense, but the rights you hold to use it can be very different. Over the past several years a wave of well known projects has done exactly this, moving from open source licenses to source available ones, and the result is a category of risk that sits quietly inside production estates across every industry. This guide is the buyer side view: plain, dated, and focused on what you can actually do.

As an independent firm we are paid only by the buyer. We sell no software and take no fee from any vendor, so this guide names the risk as it is. It is commercial and licensing risk advisory, not legal advice. For interpretation of any specific license and your compliance position, your own counsel is the right place to turn.

What relicensing actually changes

An open source license, in the sense the Open Source Initiative defines it, grants broad freedoms: to use the software for any purpose, to study and modify it, and to redistribute it. A source available license keeps the source readable but withdraws some of those freedoms. The two licenses at the center of the current wave are the Business Source License and the Server Side Public License. Neither is OSI approved open source. Both are source available, and both carry conditions that an open source license would not.

The Business Source License restricts production use that competes with the vendor and converts to an open license after a delay, commonly four years. The practical effect is that you can read and even run the code, but if your use looks competitive under the license, you may owe a commercial license today. The four year clock matters, because the version you run becomes openly licensed only once that delay has passed. We cover the mechanics in detail in the four year delay in the BSL explained.

The Server Side Public License goes further. It adds a copyleft style condition aimed at parties that offer the software as a service: if you do, you must release the source of the surrounding service stack under the same terms. For most enterprises the obligation does not bite, because they run the software internally rather than offering it to third parties. But the distinction between internal use and a managed service is exactly where the risk sits, and it is rarely as clean as it first looks.

The projects that moved, and when

The pattern is easiest to see through the projects that drove it. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023. IBM later acquired HashiCorp, which changed the commercial backdrop against which buyers now negotiate. The community responded with OpenTofu, an open license fork of Terraform that carries the tool forward for teams that want to stay on open terms. The HashiCorp story is covered in depth in the HashiCorp and Terraform pillar.

Redis moved to a dual model of the Redis Source Available License and the Server Side Public License as of March 2024, and later added an open license option. The fork here is Valkey, backed by a group of large operators who wanted an openly licensed path. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021, and Elastic later added an open license option as well. The fork there is OpenSearch, led by AWS. MongoDB was the early mover, adopting the Server Side Public License in 2018. The database side of the wave is covered in the Redis, Elastic, and database relicensing pillar.

The dates matter because this is a fast moving topic and licenses keep evolving. Several vendors that moved to source available licenses later added an open license option, which softened the position for some users. The only safe approach is to anchor every statement to a date and to re check the current terms before acting. The full timeline is set out in the 2023 to 2026 relicensing wave explained.

Why a relicense reaches software you already run

The common assumption is that a license change applies only to future adopters. It does not. A new license typically governs new versions and updates of the software. The version you deployed last year stays under its old license, but the moment you take a patch, a minor upgrade, or a security fix released under the new terms, your use is bound by them. This is the quiet mechanism by which a relicense reaches a production estate. Few teams notice the license line in a release note, and the dependency may sit several layers deep where no one is watching.

Freezing on an old version is not a free escape. The old license is preserved, but so is the old code, which means you stop receiving security patches. For a database or a secrets manager, that trade is rarely acceptable for long. The choice between an unpatched but openly licensed version and a patched but newly restricted one is the heart of many relicensing decisions, and it has to be made with the full dependency picture in view.

Transitive dependencies make this harder. A component you never chose directly can pull in a relicensed library, and a build tool you treat as plumbing can quietly fall under new terms. This is why a relicense is not a single event but a blast radius, and why mapping it well is the foundation of every sound response.

Who carries the exposure

Relicensing risk does not respect org charts. The CISO carries it because an unmanaged license change is an unmanaged risk in production. The general counsel carries it because the obligations are legal in nature and can surface in an audit or a dispute. Procurement carries it because a relicense can convert free usage into a commercial line item with little warning. Engineering leaders carry it because the remedy, whether a fork, a replacement, or a negotiated license, lands as work on their roadmap. The firms that handle relicensing best are the ones that put these four in the same room early.

Regulated industries feel it most sharply. A financial services firm running a relicensed component across dozens of teams, or a healthcare provider with the same component embedded in a clinical system, cannot treat a license change as a quiet technical detail. For the broader treatment of where this risk originates, see the open source license risk pillar.

How to respond when a relicense lands

The first thirty days set the tone. The instinct to either ignore the change or rip the component out immediately are both wrong. The right first move is to map where the affected component sits and how deep it goes, so the decision that follows rests on facts rather than headlines. From there, you size the exposure in plain terms: what does the change cost if you do nothing, and what does it cost to cure. Only then do you choose a path. Our step by step view of this window is set out in how to respond in the first 30 days of a relicense.

There are three broad doors. The first is a community fork: OpenTofu for Terraform, Valkey for Redis, OpenSearch for Elasticsearch. A fork is often the cleanest exit, but only after you confirm feature parity, support continuity, and a credible security patch path. The second is replacement, where a different component does the same job under terms you can live with. The third is a negotiated commercial license, which is the right answer when the incumbent is too deep to move and the price can be brought down to match real usage. None of the three is automatically best. The right door depends on your estate.

Mapping and quantifying the exposure

Every sound response starts from a map. You cannot contain what you cannot see, and a relicensed component that hides in a transitive layer is the one that turns into a finding. The work begins with a complete dependency tree, direct and transitive, with the current license state attached to each node. From there you trace the blast radius around each changed component and size the exposure in board language: the cost of the exposure if left, and the cost to cure. That pairing is what lets leadership make a real decision rather than a hopeful one.

This is the work of a relicensing exposure review, which builds on an open source license risk assessment. Where the review points to action, open source remediation services carry it through, and where a commercial license is the answer, commercial license negotiation brings the price down to match your leverage.

Preventing the next surprise

The relicensing wave is not over, and the cheapest relicense to handle is the one you see coming. Governance is what turns a license change from a fire drill into a tracked event. A current dependency map, a license allowlist that reflects your tolerance, and an intake gate that flags a component before it enters production together mean a future relicense is visible the day it happens. The same software bill of materials that satisfies a regulator is the one that finds a relicensed component before it becomes a problem. For the discipline behind this, see the open source governance and SBOM pillar.

Prevention is not free, but it is far cheaper than discovery in an audit. The aim is modest and durable: never again learn of a license change from a vendor letter or an auditor's question.

Explore the relicensing cluster

MORE IN THIS CLUSTER

Explore more from this guide.