OpenSource Risk Experts
Map your blast radius

REMEDIATION AND ALTERNATIVES

Open source remediation FAQ.

This open source remediation FAQ answers the questions buyers ask after a relicense lands: whether to fork, migrate, or pay, how long the work takes, what it costs, and how to contain the risk without breaking what already runs. Plain answers, on the buyer's side.

This open source remediation FAQ collects the questions we are asked most once a project such as Terraform, Redis, or Elasticsearch has changed its license and the exposure has been mapped. Remediation is the part where you do something about it. The answers below are written plainly and apply to the common cases, though the right move always depends on your specific estate. None of this is legal advice, and whether a given use breaches a license is a question for your own counsel.

What is open source remediation?

Open source remediation is the work of containing the risk that appears when a component you depend on changes its license. The Business Source License restricts competitive production use. The Server Side Public License carries a strong condition aimed at offering software as a service. When a component moves to terms like these, continuing as before can create exposure. Remediation is your response: fork to a community alternative, migrate to a different technology, buy a commercial license, or remove the dependency. Each option is weighed on the exposure it removes, the engineering cost, and the timeline, so the path you choose holds up and does not simply relocate the problem.

Should we fork, migrate, or pay?

This is the central question, and the honest answer is that it depends on the component, your usage, and your leverage. A wire compatible community fork is often the lowest cost path: OpenTofu for Terraform, Valkey for Redis, and OpenSearch for Elasticsearch all exist precisely because enterprises wanted an open licensed continuation. Paying for a commercial license makes sense when no credible fork exists, or when you need vendor features and support that the free editions do not provide. Removing the dependency suits cases where the component adds little you cannot rebuild more cheaply than you can license it. The structured way through this choice is set out in fork, migrate, or pay: the remediation decision.

How long does remediation take?

It ranges widely. A wire compatible fork swap can be a matter of weeks once you have tested compatibility and run it through your release process. A migration that changes interfaces or requires moving data runs longer, often a quarter or more. A full re architecture that removes a deeply embedded dependency can take several quarters. A well run programme does not wait for the slowest item before starting; it front loads the quick, high risk changes, contains the hardest items on a documented stopgap, and runs the long migrations in parallel. The realistic comparison of cost and time across these paths sits in the cost model of each remediation path.

Is forking safe for an enterprise?

A well governed fork can be a sound enterprise choice, but the word safe hides real diligence. OpenTofu sits under the Linux Foundation and Valkey under the same umbrella as of 2024, which gives them neutral governance and a credible release cadence. Even so, you should check the fork's security patching, its long term compatibility with what you run, the breadth of its contributor base, and whether it is keeping pace with the original. A fork removes the license exposure only for as long as it remains a viable, maintained alternative. Where several forks compete, the choice itself needs care, which is the subject of building an open source remediation roadmap.

Can we keep the old version under the old license?

Often yes, as a stopgap rather than a destination. Versions released before a license change generally keep their original terms, so a release shipped under the old open license usually remains usable on those terms. The cost is that you freeze on a version that stops receiving security patches and new features. For a short bridge while you remediate, that can be acceptable if the security trade off is owned explicitly. As a long term answer it accumulates its own risk. This is a deliberate, documented decision, not a default to drift into.

What does remediation cost?

The largest cost in most remediation is engineering time, not license fees, and buyers routinely underestimate it. A fork swap that looks free still consumes testing, validation, and release effort. A migration consumes far more. The point of costing every path on the same basis is to compare a real number against a real number: the engineering cost of forking or migrating against the commercial license fee of paying. Only then can you see which path is genuinely cheaper over the period that matters, rather than which one looks cheaper today. A low headline fork is not a saving if it needs a rewrite next year.

The buyer side view

We answer these questions for your specific estate, not in the abstract. We confirm the exposure with your counsel, weigh forking, migrating, and paying on a single cost model, and hand you a sequenced plan you can defend. We are independent and paid only by you, never by a vendor or reseller, so the recommendation serves your budget and your risk. The full set of options sits in the open source remediation and alternatives pillar, and we run the hands on work through our open source remediation advisory engagement.

COMMON QUESTIONS

Questions buyers ask.

What is open source remediation?

Open source remediation is the work of containing the risk created when a component you run changes its license. It covers forking to a community alternative, migrating to a different technology, buying a commercial license, or removing the dependency, each chosen on the exposure, the engineering cost, and the timeline.

Should we fork, migrate, or pay?

It depends on the component, your usage, and your leverage. A wire compatible fork such as OpenTofu, Valkey, or OpenSearch is often the lowest cost path. Paying makes sense when no credible fork exists and you need vendor features or support. Removing the dependency suits cases where the component adds little you cannot rebuild.

How long does open source remediation take?

A wire compatible fork swap can be a matter of weeks once tested. A migration that changes interfaces or moves data runs longer, and a full re architecture can take quarters. A typical programme front loads the quick, high risk items and runs the hard migrations in parallel on a documented stopgap.

Is forking safe for an enterprise?

A well governed fork such as OpenTofu under the Linux Foundation or Valkey can be a sound choice, but it carries its own diligence: governance, release cadence, security patching, and long term compatibility all need checking. The fork removes the license exposure only if it remains a viable, maintained alternative.

Can we just keep the old version under the old license?

Sometimes, as a stopgap. Versions released before the change usually keep their original license, but you freeze on a release that stops getting security patches and new features. It buys time, not a destination, and the security trade off needs to be owned explicitly.

Is this article legal advice?

No. It is commercial and licensing risk analysis, not legal advice. For interpretation of license terms and compliance, engage your own counsel.

CONTAINMENT

Turn the remediation questions into a plan.

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

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

Talk to an advisor