RELICENSING

Relicensing and Your Existing Contracts

By OpenSource Risk Experts · June 6, 2026

Relicensing and your existing contracts is where a licensing event stops being abstract and starts touching agreements you have already signed. A component you depend on changes terms, and the change does not stay contained in your codebase. It travels into the customer contracts that promise functionality, the vendor agreements that assumed an open dependency, and the support deals tied to a particular version. The contract language never changed. Your ability to satisfy it may have. This article maps where the exposure sits and what to review first.

We write from the buyer side, as an independent advisory paid only by the buyer. This is not legal advice. For interpretation of any license or contract, we point you to your own counsel. What we offer is the commercial map that tells your counsel where to look.

How relicensing reaches contracts you already signed

A contract is a promise made under a set of assumptions. When you signed an agreement to deliver a product or service, you assumed the components inside it would remain usable on the terms in force at the time. Relicensing breaks that assumption quietly. The promise still stands, but a dependency that was free to deploy may now carry a competitive use restriction or a commercial license demand that sits between you and the promise. The exposure is not in the new license alone. It is in the gap between what you committed to and what the new license now permits.

The events that create this gap are now common. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023. Redis moved to the RSALv2 and the Server Side Public License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021. If any of these sit inside a product you sell or host under contract, the agreement deserves a fresh read against the current terms.

Three contract types that carry the exposure

The first is the customer agreement. If you ship or host software to customers and a relicensed component is load bearing in that delivery, a new restriction may put the commitment at risk. The harder cases are agreements that promise specific functionality, uptime, or a roadmap that depends on continuing to use the affected component on its old terms. The second is the vendor or reseller agreement, where you may have warranted the license posture of what you distribute. The third is the support or maintenance deal, often tied to a version, where staying on the prior openly licensed release to avoid the new terms can collide with a commitment to keep current.

These are also the agreements most likely to contain warranties and indemnities about open source compliance. A relicensing event can turn a routine warranty into an active question. The work is to find every contract where the affected component is material, then map the dependency to the specific obligation. This is closely related to the broader duties covered in relicensing and your compliance obligations.

CUSTOMER AGREEMENTS

Promises of functionality or roadmap that depend on a relicensed component remaining freely deployable.

VENDOR AND RESELLER

Warranties about the license posture of what you distribute downstream may now be in question.

SUPPORT AND MAINTENANCE

Version tied deals collide with the choice to stay on the prior openly licensed release.

The old version question and what it does not solve

A common first instinct is to freeze on the last version released under the old open license. In most cases that version stays under its prior terms, so the immediate license pressure eases. But the freeze is a tradeoff, not a cure. You stop receiving security fixes, new features, and compatibility updates under those terms, which can itself breach a support commitment or a security warranty in a customer contract. The choice to stay on the old version should be a documented decision with an owner, not a default that no one revisited. The mechanics of what survives a change are covered in what happens to old versions after a relicense.

Timing matters as well. The effective date of a relicense and any notice the vendor gives shape how much room you have before a contract obligation comes due. Understanding the calendar is part of the response, and we treat it in notice and effective dates in a relicense.

Where procurement and counsel come in

Once the affected contracts are mapped, the response splits. Your counsel interprets the obligations and tells you whether a given clause is actually at risk. Procurement handles any commercial license that becomes the chosen path, negotiating from the buyer side rather than accepting a list price. Both depend on a clear picture of where the component sits and how it is used, which is the work we do. The interaction with approval workflows is covered in relicensing and procurement approval processes.

For the full landscape of how a license change creates exposure, see the relicensing exposure pillar. When you want every affected agreement found and mapped to the dependency that drives it, our relicensing exposure review produces the map your counsel and procurement teams work from.

Questions buyers ask.

How does relicensing affect your existing contracts?

A license change on an upstream component can ripple into agreements you have already signed. Customer contracts that promise certain functionality, vendor agreements that assume an open dependency, and support deals tied to a specific version can all carry exposure if the underlying license now restricts your use. The contract terms did not change, but your ability to meet them may have.

Does a relicense break my customer commitments?

Not automatically, but it can put them at risk. If you ship or host software built on a component that relicensed, and your customer contract assumes you can continue to do so freely, a new competitive use restriction or commercial license demand may sit between you and that commitment. Review the dependency against the obligations you have promised.

Can I keep using the old version under the old license?

Usually the version released under the prior open license remains under that license, but you stop receiving updates, security fixes, and new features under those terms. Staying on the old version is a contractual and security tradeoff, not a permanent fix, and should be documented rather than assumed.

What should I review first after a relicense?

Start with the contracts where the relicensed component is load bearing. Customer agreements that depend on the affected feature, vendor and reseller agreements, and any support or maintenance deals tied to a version. Map the dependency to the obligation, then route interpretation to your counsel.

Is this legal advice?

No. We provide commercial and licensing risk advisory, not legal advice. For interpretation of license terms and contract obligations, we recommend your own counsel.