OPEN SOURCE LICENSE RISK
How a license change creates enterprise exposure.
A license change rarely announces itself. It arrives in a release note, lands in a transitive layer, and reaches production through a routine upgrade. This article explains how a license change creates enterprise exposure, and what leaders need to map before it becomes a finding.
Published May 28, 2026. Commercial and licensing risk advisory, not legal advice.
A license change creates enterprise exposure because the software does not move, the terms do. The binary you run, the library three layers down, the build tool that has never failed you: none of them change the day a project relicenses. What changes is the set of rights you hold to use them. That gap, between code that looks identical and terms that no longer match your usage, is where the exposure lives. It is quiet, it is easy to miss, and it can sit in production for months before anyone asks the question that surfaces it.
Understanding the mechanics is the first defense. This article walks through how a license change reaches your estate, why old versions are not a clean escape, what the blast radius looks like, and where the real cost lands. For the wider treatment of the topic, the pillar on open source license risk sets the full context.
The mechanism: new terms govern new versions
When a project relicenses, the new license usually applies to new versions and updates rather than retroactively to the version you already deployed. On the surface that sounds reassuring. In practice it is the mechanism of exposure. Software does not sit still. Teams take security patches, minor upgrades, and dependency bumps as a matter of routine, and many of those updates are released under the new license. The moment you pull one in, your use of that component is bound by the new terms. No one signs anything. No procurement gate fires. The license simply changes underneath you on the next ordinary upgrade.
The licenses driving current exposure are the Business Source License and the Server Side Public License, neither of which is OSI approved open source. 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 Server Side Public License adds a copyleft style condition aimed at parties that offer the software as a managed service. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023. Redis moved to a Redis Source Available License and Server Side Public License model as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021, and MongoDB moved to the Server Side Public License in 2018. Each is a candidate to be sitting in your estate right now.
Why staying on an old version is not a free escape
The obvious response is to pin the component to the last version released under the old license. The license is preserved, and on paper the exposure is gone. But the code is frozen too, which means you stop receiving security patches and bug fixes. For a secrets manager, a database, or anything on the network edge, 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 real decision a license change forces, and it cannot be made well without seeing the whole picture. Pinning is a holding move, not a strategy.
This is also where time works against you. The longer a pinned component sits unpatched, the larger the security exposure grows, while the licensing exposure waits for the next time someone upgrades without checking. Two risks accumulate in parallel, and neither resolves itself.
The blast radius is wider than the named product
The named product is the part everyone can see. The exposure usually extends much further. A relicensed library can be pulled in transitively by a component you did chose, so it enters the estate without any direct decision. A build tool that teams treat as plumbing can fall under new terms while continuing to work exactly as before. Internal platforms compound the reach: when a single relicensed component sits inside a shared platform used across many teams, the blast radius is every product built on that platform. Tracing this reach is not optional. It is the difference between a sized, bounded exposure and an open question that an auditor gets to define for you.
Build and continuous integration tooling deserves particular attention, because it is the layer most often assumed to be safe and least often inventoried. We cover that specific risk in license risk in your CI CD and build tooling.
Where the cost actually lands
Exposure becomes cost in a few predictable ways. The first is a commercial license demand: usage you ran for free now falls inside terms that require payment, and the vendor sets the opening price. The second is remediation effort: moving to a fork such as OpenTofu, Valkey, or OpenSearch, or replacing the component, lands as real engineering work on a roadmap that was already full. The third is the cost of discovery in the wrong setting, where an audit or a vendor inquiry finds the exposure before you do, and you negotiate from the back foot with no map of your own. The first two are manageable. The third is the one to avoid.
The way to keep cost bounded is to see the exposure first and size it in board language: what does it cost to leave it, and what does it cost to cure. That pairing turns a vague worry into a decision leadership can actually make.
What to do about it
Start with a map. A complete dependency tree, direct and transitive, with the current license state on every node, is the foundation that every later decision rests on. From there you can trace the blast radius around each changed component, size the exposure, and choose a path with the facts in hand. Then keep the map current, because a license change you see on the day it happens is a tracked event, while one you find in an audit is a crisis. The discipline of watching for change over time is covered in open source license risk monitoring over time, and the broader response playbook lives in the pillar on license change and relicensing.
A license change creates enterprise exposure quietly and reaches further than it first appears, but it is mappable, sizeable, and containable. The firms that handle it well are simply the ones that looked first. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license and your compliance position, your own counsel is the right place to turn.
COMMON QUESTIONS
Questions buyers ask.
How does a license change create enterprise exposure?
A license change creates enterprise exposure when a project you already run swaps an open source license for a source available one. New terms typically govern new versions, so the next patch or upgrade binds your existing use, and competitive use or distribution conditions can apply to software already in production.
Does a license change affect old versions we already run?
The version you deployed keeps its old license, but the moment you take an update released under the new terms your use is bound by them. Staying on an old version preserves the license while freezing security fixes, which is its own form of exposure.
What is the blast radius of a license change?
The blast radius is everything that depends on the relicensed component, directly or transitively, plus the products and platforms built on top of it. A change to one library can reach far beyond the named product, which is why mapping is the first step.
Which license changes matter most?
The moves to the Business Source License and the Server Side Public License drive most current exposure. HashiCorp moved Terraform and others to the Business Source License as of August 2023, Redis moved as of March 2024, and Elastic moved as of 2021.
Is this legal advice?
No. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license and your compliance position, we recommend your own counsel.
SEE YOUR EXPOSURE
Map the exposure before an audit does.
A confidential open source license risk assessment. Independent, buyer side, paid only by you.
Not ready to talk? Read the free open source license risk guides first.