REMEDIATION AND ALTERNATIVES

Keeping old versions: the risks and the limits.

Keeping old versions is the first move many teams reach for after a relicense. Pin to the last release under the open license and the immediate license pressure eases. The tactic is real, but it has a clock on it. This article sets out what it buys you and where it runs out.

Keeping old versions, meaning pinning your estate to the last release published under the open license, is the most tempting response to a relicense because it requires no migration and no purchase. For a moment, nothing changes. The version you already run was obtained under terms you accepted, and a relicense generally applies to new releases rather than reaching backward. So the license pressure recedes and the deadline appears to vanish. The trouble is that the deadline has not vanished. It has only changed shape, from a licensing problem into a security and support problem that grows with every month you stay put. Used well, the tactic is a bridge. Mistaken for a destination, it becomes a liability.

What keeping an old version actually buys

The value is time, and time has real worth. A pinned release lets you keep running without an unplanned purchase while you assess the blast radius, qualify alternatives, and sequence a proper move. It removes the pressure to make a rushed decision under a vendor's clock. As of August 2023 HashiCorp moved Terraform, Vault, Consul, Nomad and Packer to the Business Source License, as of March 2024 Redis moved to a Server Side Public License model, and Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. In each case the last open release still exists and can usually be run under the license it shipped with. That is the relief the tactic provides, and for a planning window it is genuinely useful.

Confirm the license boundary before you rely on it

The whole tactic rests on a premise that deserves checking. The assumption is that the version you hold remains under the prior open license even after the project relicenses future releases. That is generally the case, but the terms vary by project, and the exact boundary between the last open release and the first restricted one is a question of fact. Record the precise version you are pinning to, capture the license it shipped under, and put the boundary question to your own counsel rather than assuming it. The discipline costs little and prevents the worst outcome, which is discovering later that the version you relied on was not as clean as you thought.

The security limit is the one that bites

Once upstream moves on, the pinned version stops receiving fixes. New vulnerabilities will be found in code you are still running, and the patches for them will land on the new releases under the new license, not on your frozen one. You are then left to backport fixes yourself, to accept the exposure, or to move. For a component that processes untrusted input or faces the internet, this limit arrives quickly and matters enormously. A frozen version of an internet facing service is a growing security debt, and no amount of license relief offsets an unpatched critical vulnerability. This is why keeping old versions is safe in proportion to how isolated and low risk the component is.

Support and compatibility drift come next

Beyond security, the frozen version slowly falls out of step with everything around it. New operating systems, language runtimes, drivers, and adjacent services move forward, and a pinned dependency that cannot move with them becomes harder to keep running. Commercial support for an old release thins or ends. Documentation and community help drift toward current versions. None of this is fatal on day one, but it compounds. The longer you hold, the more the surrounding estate has to bend around the one component you have frozen, and the higher the eventual cost of catching up. The tactic that bought you time begins charging interest.

When the tactic is reasonable

Keeping an old version is a sound choice in two situations. The first is as a deliberate bridge while a real remediation is planned and executed, with a defined end date and a chosen destination. The second is for components that are genuinely isolated, low risk, not exposed to untrusted input, and unlikely to need security updates in the window you care about. For those, a frozen release can be a stable and inexpensive answer for a long time. What makes the tactic dangerous is using it by default for critical, exposed systems with no plan to leave, because that converts a temporary convenience into a standing risk that no one owns.

Treat it as one option among several

The honest way to use a pinned version is to place it beside the other routes and choose with eyes open. Staying frozen, moving to a community fork, removing the dependency, and negotiating a commercial license each carry a different cost and a different risk curve. Keeping old versions wins on near term cost and loses on long term risk, which is exactly why it works best as a bridge to one of the others. Set the destination while the bridge is still solid. For the full comparison, read open source remediation, your options explained, price the routes in the cost model of each remediation path, and fit the work to your shipping cadence with remediation and your release cycle. The wider context sits in the remediation and alternatives pillar.

The buyer side view

We help you use the pinned version for exactly what it is good for and not a day longer. We confirm the license boundary with your counsel, identify which components can safely sit on a frozen release and which cannot, and set the end date and destination so the bridge leads somewhere. We are paid only by you, so the timeline serves your risk tolerance rather than any vendor's renewal calendar.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Use the bridge, then cross it.

A confidential open source remediation advisory. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.