How to respond in the first 30 days of a relicense.

How to respond in the first 30 days of a relicense is mostly a question of order. The change itself is rarely an emergency on day one, because the version you already run usually keeps its old license. What makes the next month matter is that routine activity, an upgrade here, a dependency bump there, can quietly pull the new terms into production before anyone has decided anything. The job of the first 30 days is to convert a vague worry into a clear, sized picture, contain the obvious risks, and reach a deliberate decision rather than a reactive one. Speed matters, but only after you can see what you are dealing with.

This playbook moves through four phases: confirm the facts, inventory the blast radius, contain and hold, then size and decide. For the wider framing of how a relicense works, the pillar on license change and relicensing gives the full context.

Week one: confirm the facts

Start by reading the change precisely rather than the headline about it. Identify exactly which products are affected, which versions carry the new terms, what the new license is, and when it takes effect. Announcements are often narrower or broader than the summary suggests, and getting this wrong sends the whole response in the wrong direction. Note whether the new terms are the Business Source License, the Server Side Public License, or a vendor specific source available license, because the obligations differ. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023, and Redis moved to a Redis Source Available License and Server Side Public License model as of March 2024, so the precise project and version you run determines which set of rules applies.

Pin down the dates in particular. Notice and effective dates govern when the new terms bind and which versions are clean, and they are the backbone of the whole response. We cover them in notice and effective dates in a relicense.

Week one to two: inventory the blast radius

You cannot respond to exposure you cannot see. The second task is to find every place the affected component runs, directly and transitively, including the build pipeline and any internal platform that depends on it. A relicensed component buried in a shared platform reaches every product built on that platform, so the inventory has to follow the dependency tree rather than stop at the named product. Record the versions in use against the effective dates, because the gap between the version you run and the version that carries new terms is exactly what determines whether you have an active exposure or merely a future one.

This is the same mapping discipline that underpins all relicensing work, and it is where most of the first month's effort belongs. The wider compliance picture that the inventory feeds is set out in relicensing and your compliance obligations.

Week two: contain and hold

With the map taking shape, put a short, deliberate hold on upgrades of the affected component. A routine update is the most common way new terms reach production, so a temporary freeze stops the exposure from growing while you decide. Make the freeze explicit and time bound, tell the teams that ship the component why it is in place, and pair it with a watch for any pending changes already in flight. This is a holding move, not a fix. Its only job is to prevent the situation from getting worse during the weeks you spend understanding it. Bring legal and procurement in now rather than later: legal reads the new terms against your actual use, and procurement prepares for a possible commercial conversation so you are never forced to start one cold.

A frozen component also stops receiving security patches, so the hold has a cost that grows over time. That tension is exactly why the freeze must be short and feed directly into a decision rather than become the default state.

Week three to four: size the exposure and decide

With facts and a map in hand, size the exposure in board language: what it costs to leave it and what it costs to cure. Then choose a path with eyes open. The main options are migrating to a community fork such as OpenTofu, Valkey, or OpenSearch, replacing the component outright, negotiating a commercial license that reflects your real usage and leverage, or, for a stable deployment, holding on a clean version while you plan. Each option carries an engineering cost and a license posture, and the right answer depends on where the component sits and how central it is. The fork path in particular is told in the OpenTofu and Valkey fork story.

Thirty days is enough to move from surprise to a sized, owned decision, provided you spend it in the right order. Confirm the facts, map the blast radius, contain the obvious risk, then decide with the numbers in front of you. The firms that handle a relicense well are simply the ones that resisted the urge to act before they could see. 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.