Relicensing and your compliance obligations.

Compliance is easy to picture as a fixed checklist. A relicense breaks that picture. The same component that carried light obligations under an open license can, in a newer release, carry restrictions and conditions that did not exist when you adopted it. The work is to notice the change, understand which obligations now apply to your use, and prove you are meeting them. None of that happens automatically, which is why a relicense should prompt a deliberate review rather than a shrug.

How relicensing changes your compliance obligations

When a project relicenses, the duties attached to using it change for the releases that carry the new terms. The direction of the change depends on the license. A move to the Business Source License introduces a restriction on competitive production use, so compliance becomes a question of staying inside the additional use grant. A move to the Server Side Public License attaches conditions when you offer the software as a service. A move to a strong copyleft license such as the GNU AGPL can require you to make corresponding source available under certain conditions. The software did not change. The obligations did, and your compliance posture has to follow.

The relicensing wave gives the concrete anchors. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, and MongoDB moved to the Server Side Public License in 2018. Each of these can place new obligations on releases published under the new terms.

Do the new obligations reach software already in production?

They can, for the releases that carry the new license. This is the point that catches teams off guard. Compliance is not frozen at the moment you adopted a component. If you upgrade to a release published under the new terms, the obligations in that license apply to your use of that version. Older releases generally keep their original license, so a system pinned to a pre change version may carry the old obligations. The version you run decides which set applies. That makes your inventory a compliance document, not just an engineering one, and it makes routine upgrades a moment where obligations can quietly change.

The duties that can attach after a relicense

Several kinds of obligation can appear. There are use restrictions, where a license forbids a class of production use such as offering a competing service. There are service conditions, where offering the software to others as a service triggers requirements. There are source disclosure duties under strong copyleft, where distributing or, in some cases, providing network access to the software requires making corresponding source available. There are attribution and notice requirements that survive any license change. And there are the obligations in any commercial license you take to resolve the situation, which carry their own audit and reporting terms. Which of these apply to you depends on the exact license text and how you use the component, and that interpretation belongs with your own counsel.

Why a relicense raises your audit exposure

A relicense gives the project owner both new restrictions to enforce and a commercial reason to enforce them. That combination raises the chance that someone will ask how you use the software. The defense is not to hope the question never comes. It is to be ready to answer it with evidence. An organization that can show which version runs where, under which license, for which use, and since when, turns an open ended audit into a bounded question. An organization that cannot is negotiating from the back foot against the owner's assumptions.

How to stay defensible after a relicense

Build the record before you need it. Keep a current inventory through software composition analysis that reaches transitive dependencies. Record the license state and version of each component, not the license declared at adoption. Classify how you use each one: internal only, customer facing, or part of an offering a license might restrict. Keep evidence of all three so you can demonstrate, not just assert, that you are meeting the obligations that apply. That record is the difference between a compliance question you answer in a meeting and one that turns into a project. The discipline is ordinary. The payoff arrives the day someone asks.

From obligations to a defensible position

Mapping your obligations after a relicense is part of our relicensing exposure review. For the full picture, read our pillar on open source relicensing. To understand the licenses behind these duties, read the Business Source License explained. To get the version boundaries right, read notice and effective dates in a relicense, and to see how a corporate event can start it all, read relicensing triggered by acquisition.