Open Source Remediation: Your Options Explained

Open source remediation is the work that follows the discovery of a relicensed dependency. The assessment told you what changed and how far it reaches. Remediation is the decision about what to do, and the execution that returns the affected software to license terms you can accept. There are four broad paths open to a buyer, and the temptation is to reach for the one that sounds simplest or that worked for someone else. The better approach is to understand all four, then choose the one that fits your specific footprint. This article explains the options and the questions that decide between them.

We write from the buyer side as an independent advisory paid only by the buyer. This is not legal advice. For interpretation of whether a given path satisfies a license, we point you to your own counsel.

What open source remediation actually means

Open source remediation is the containment phase of license risk work. When a project moves from an open source license to a source available one, the exposure is the gap between what your deployment now requires under the new terms and what you are prepared to accept. Remediation closes that gap. It does not mean panic or wholesale replacement. In many cases the right remediation is to confirm that your use still falls inside what the new license permits and to document that position. Where the use does fall inside a restriction, remediation means choosing a path that moves the software back to acceptable terms at a cost you can justify.

The error to avoid is treating remediation as a single technical task. It is a decision with commercial, engineering, and license dimensions, and the cheapest looking option on one axis can be the most expensive on another. A fork that avoids a license fee can carry a large migration and maintenance cost. A commercial license that looks expensive can be cheaper in total than the engineering effort to remove the dependency. The work is to see all of that at once.

Option one: move to a community fork

The first option is to move to a community fork that continues the project under an open source license. The relicensing wave produced several such forks. OpenTofu forked from Terraform, Valkey forked from Redis, and OpenSearch forked from Elasticsearch, each created so that organizations could keep using a compatible engine on open terms. When a fork is broadly compatible, this can be the cleanest path, because it restores a permissive or open posture while preserving most of the technology and the skills your teams already have. The cost lives in the migration effort and in the longer term risk that the fork and the original diverge, which can add maintenance work over time. The fork is strongest when compatibility is high and the component is widely deployed, so a single migration pays back across many teams.

Option two: migrate to an alternative

The second option is to migrate to a different product entirely, rather than a fork of the same one. This is the right path when a credible alternative exists with a license posture you prefer and a feature set that meets your needs, or when the relicensed project has limitations you were already prepared to leave behind. Migration to an alternative carries the highest compatibility risk of the four options, because you are moving to genuinely different software, not a compatible fork. The payoff is that you can choose the destination on its own merits, including its license, its roadmap, and its fit, rather than being tied to the lineage of the component that relicensed. This path suits situations where the dependency was already a candidate for replacement and the relicensing event simply brought the decision forward.

Option three: buy a commercial license

The third option is to accept that the software is the right one and buy a commercial license from the vendor. This is often the correct answer when the component is deeply embedded, when migration would be costly and risky, and when your usage is narrow enough that the license fee is reasonable. The key to this path is to negotiate from your side of the table, with a measured usage baseline rather than the inflated footprint a list price assumes. A commercial license that reflects your actual usage and leverage can be the cheapest total option, even when the headline number looks large, because it avoids an expensive and disruptive migration. We cover the negotiation discipline in the commercial license negotiation service, and the way to size each path against the others in fork, migrate, or pay, the remediation decision.

Option four: remove the dependency

The fourth option is to remove the dependency altogether. This is viable when the component is shallow, used in a limited way, or replaceable with capability you already have or can build cheaply. Removal eliminates the license question entirely rather than substituting one set of terms for another, which makes it attractive when the dependency was marginal to begin with. It is rarely the right path for a deeply embedded engine, where removal means rebuilding a great deal, but for a peripheral library or a tool used by one team it can be the simplest and most durable answer. The decision rests on how deeply the component is woven into your systems, which is exactly what the blast radius map tells you.

How a buyer chooses the right path

The choice between the four paths comes down to three variables sized for your specific deployment: engineering cost, license posture, and timeline. A component that is shallow and isolated points toward removal or a quick migration. A component that is deep, widely used, and has a compatible fork points toward the fork. A component that is deep with no good fork or alternative points toward a negotiated commercial license. The mistake is to pick a path by reputation rather than by fit, since the same relicensing event can warrant a fork for one organization and a commercial license for another, depending entirely on how each one deploys. We model the numbers behind the choice in the cost model of each remediation path.

All four paths depend on an accurate map of where the component runs and how deeply it is embedded. Without that, every option is a guess. Producing the map and sizing each path is the work of our open source remediation advisory. For the full set of approaches, see the remediation and alternatives pillar.