Open source remediation and alternatives: the complete guide.

A license change does not break your software. The build still passes, the service still runs, and for a while nothing seems different. What changes is the basis on which you are permitted to use what you already run. Open source remediation and alternatives is the discipline of responding to that change deliberately, with the cost and the risk of each route laid out, rather than reacting to a vendor letter or an audit notice under pressure. This guide is the hub for that work. It sets out the routes, the order to take them in, and the trade offs that decide which one fits your situation.

Why remediation became a board level question

For two decades, enterprises treated open source as settled infrastructure. A component adopted under a permissive license stayed permissive, and the only real questions were security and support. That assumption no longer holds. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023, with the community fork OpenTofu emerging in response. Redis moved to a dual model of the Redis Source Available License and the Server Side Public License as of March 2024, with the fork Valkey. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, with the AWS led fork OpenSearch. MongoDB moved to the Server Side Public License in 2018. Each of these is widely deployed, and each change can reach software already in production.

The reason this rises to the board is that the exposure is commercial, not just technical. Source available is not open source. The Business Source License and the Server Side Public License are not approved by the Open Source Initiative, and their restrictions on competitive use and their distribution obligations can translate directly into a commercial license demand. A component you adopted for free can become a line item with a price set by someone else. Remediation is how that price is contested or avoided.

The four routes to containment

Every remediation decision resolves to one of four routes, or a blend of them across components. Understanding each one on its own terms is the foundation for choosing well.

Route one: move to a fork

When a project relicenses, the community often responds with a fork that continues under an open license. OpenTofu followed the Terraform change, Valkey followed Redis, and OpenSearch followed Elasticsearch. For many buyers the fork is the lowest friction route, because it is built to preserve compatibility with what you already run. The migration effort can be modest, and the license fee disappears. The questions to weigh are the fork's governance, the durability of its community, and the gap that can open between the fork and the upstream project over time. A fork backed by a foundation and major contributors carries a different risk profile from one maintained by a handful of volunteers.

Route two: migrate to a different project

Sometimes the cleaner answer is not a fork of the same project but a different project entirely, one that solves the same problem under a license posture you are comfortable with. This route carries more engineering effort because the replacement is not drop in compatible, but it can resolve the exposure decisively and sometimes improves the architecture in the process. Migration suits components where the fork's future is uncertain, or where the relicense exposed a dependency you would rather not have carried in the first place. The cost is real and must be counted honestly, which is why migration is weighed against the alternatives rather than chosen on principle.

Route three: remove the dependency

The most underused route is removal. Many relicensed components are used lightly, for a single feature or a convenience that standard library functionality or a small amount of in house code could replace. Where that is true, removing the dependency eliminates the exposure entirely rather than relocating it to a fork or a different vendor. Removal is the only route that reduces your dependency surface rather than merely changing its license. It is not always available, but it is always worth checking first, because the cheapest component to remediate is the one you no longer need.

Route four: negotiate a commercial license

Staying on the relicensed project under a negotiated commercial license is a legitimate outcome when the software is deeply embedded, the alternatives are costly, and the price is acceptable. The mistake is accepting the list price as the price. A buyer side negotiation, grounded in your actual usage and the credible alternatives you have mapped, is what turns a vendor's opening number into a fair one. Negotiation is strongest when the other three routes have been costed, because the willingness to walk to a fork or a migration is the leverage that disciplines the price. See our commercial licensing guide for how those terms are structured.

Prioritizing by risk and effort

A remediation program that tries to fix everything at once fixes nothing well. The discipline is to sequence the work by risk and effort. Plot each affected component on two axes: how much exposure it carries, and how hard it is to remediate. The components that are high exposure and low effort move first, because they retire the most risk for the least work and bend the risk curve down early. High exposure and high effort components come next, planned carefully with rollback paths. Low exposure components can often wait, or be held under a short term license while the higher priorities are cleared. This is the subject of our deeper guide on remediation prioritisation by risk and effort.

Sequencing also matters for credibility. A program that shows the board a falling exposure curve in its first quarter earns the runway to finish the harder work. One that opens with the most entangled component and stalls loses that confidence. The order is a strategic choice, not just an engineering one.

Choosing between the routes

No single route is right for an estate. Most programs blend all four: a fork for the components where compatibility matters most, a migration for the dependency whose future looks shaky, removal for the lightly used pieces, and a negotiated license for the one system too embedded to move on the current timeline. The choice for each component turns on three questions. What does the route cost in engineering effort and elapsed time. What license posture does it leave you in, and is that posture durable. And how does it fit the sequence, given everything else competing for the same teams. A route that is cheapest in isolation can be the wrong choice if it blocks a more urgent piece of work.

Getting the internal organization aligned is as important as the technical choice. Engineering, legal, finance, and procurement each see a different part of the picture, and a remediation plan only holds if they agree on the priorities and the trade offs. Our guide on remediation and internal stakeholder alignment covers how to build that agreement before the work starts rather than after it stalls.

Where remediation starts: the map

None of the four routes can be chosen without first knowing what you run. Remediation begins with an accurate dependency map that records the license state of every component, direct and transitive, and flags the ones that have relicensed since adoption. Without that map, a program risks remediating components that were never exposed while missing the one that was. The mapping work is covered in our SBOM and dependency mapping service and the broader open source license risk pillar. The map is not a preliminary; it is the foundation the entire remediation plan rests on.

Why the buyer side matters

Remediation advice is only as good as the interests behind it. We are an independent advisory, buyer side, with no vendor relationship and no reseller arrangement, paid only by you. That independence is what lets the recommendation be honest across all four routes. A vendor will steer you toward the commercial license. A tool company will steer you toward its platform. A systems integrator may favor the route with the most billable migration work. The buyer side advisor has a stake only in the lowest total exposure for your situation, and will tell you when that means removing a dependency, walking to a fork, or, yes, paying a fee that turns out to be fair. The leverage that independence creates frequently pays for the engagement on its own.

Explore the remediation cluster

This guide is the hub for our remediation work. The articles below go deeper on the practical questions that come up once a program is underway:

• Remediation prioritisation by risk and effort, how to sequence the work so exposure falls fastest.
• Remediation and internal stakeholder alignment, getting engineering, legal, and finance to agree before the work begins.
• Open source remediation FAQ, the questions buyers ask most often, answered plainly.

For the wider context, the relicensing exposure pillar explains how a license change behaves in production, and the open source license risk pillar covers how the whole picture is mapped and contained. To see remediation play out in practice, browse our case studies, including an enterprise that chose a fork over a license fee and contained the cost.

From map to contained exposure

The arc of a remediation engagement is consistent. Map the estate and the license state of every component. Identify the relicensed and copyleft exposure and rank it by risk and effort. Choose a route for each affected component, blending forks, migration, removal, and negotiation. Sequence the work so the exposure curve falls early and visibly. Then close the loop with governance, so the next relicense is caught at intake rather than in an audit. Our open source remediation advisory service runs that arc with you, from the first map to the last contained component, on your side of the table throughout.

MORE IN THIS CLUSTER

Explore more from this guide.