Quantifying Open Source License Exposure

Most organizations can name their open source license risk in general terms. Far fewer can put a number on it. Quantifying open source license exposure is the discipline of closing that gap: taking a known risk, such as a dependency that moved to the Business Source License or the Server Side Public License, and expressing it as a measured exposure that a board can rank against every other call on its budget. Without a number, license risk stays an abstract concern that loses every fight for attention and funding. With one, it becomes a decision.

This article walks through the method we use, the same one behind our open source license risk assessment. It rests on three measures: the blast radius, the cost of exposure, and the cost to cure. Together they turn a license change into a funded plan rather than a recurring source of anxiety. For the wider framing, this article sits under the pillar on open source license risk.

Start with the blast radius

Blast radius is the full set of systems, products, and downstream dependencies affected when a single component relicenses. It is the first thing to measure because it determines everything that follows. A component that looks small on a dependency list can have a wide blast radius if dozens of services build on it, directly or transitively. The reverse is also true: a prominent tool used in one isolated place may have almost no reach.

Measuring blast radius means tracing both direct and transitive dependence. The direct uses are usually known. The transitive ones, where a component is pulled in by another library or embedded inside a product you ship, are where exposure hides. A complete software bill of materials is what makes this tractable, because it shows the full tree rather than the top layer. The goal is a precise count of what touches the relicensed component, ranked by how close each system sits to revenue or to a customer.

Put a cost on the exposure

Cost of exposure estimates what the unmanaged risk could cost if you do nothing. It has several components. There is the commercial license demand a vendor might make, sized to your actual usage. There is the remediation effort that would be forced on you under time pressure rather than chosen on your schedule. There is the business disruption if a critical system has to change suddenly. And there is the compliance exposure if a copyleft or distribution obligation reaches a product you ship. Each can be estimated as a range, and the ranges can be weighted by how likely each outcome is.

The point of a range rather than a single figure is honesty. License exposure is genuinely uncertain, and a false precision helps no one. A credible exposure estimate says, in effect, that the unmanaged risk sits somewhere between a floor and a ceiling, with the most likely outcome near a stated midpoint. That is enough for leadership to act, and it is far more useful than a red, amber, green label that hides the magnitude entirely.

Measure the cost to cure

Cost to cure is the price of removing the risk. It is the counterweight to cost of exposure, and comparing the two is what drives the decision. Curing an exposure usually means one of three things: migrating to a community fork such as OpenTofu, Valkey, or OpenSearch, replacing the component with a different option, or taking a negotiated commercial license. Each carries an engineering cost, a license posture, and a timeline, and the cure that looks cheapest on engineering is not always the one with the best license posture.

When cost to cure sits well below cost of exposure, the case to act is clear and easy to fund. When the two are close, the decision becomes a judgment about risk appetite, and the quantified figures let leadership make that judgment deliberately rather than by default. When cost to cure exceeds cost of exposure, the honest answer may be to accept and monitor the risk, which is itself a valid, documented decision rather than an oversight.

Translate the numbers for the board

The final step is translation. Engineering speaks in dependencies and versions. A board speaks in money, risk, and time. A quantified exposure bridges the two, because it expresses a technical risk in the language leadership already uses. The most effective output is short: the blast radius in plain counts, the cost of exposure as a weighted range, the cost to cure as a funded plan, and a clear recommendation to remediate, negotiate, or accept. That single page is what turns license risk from a standing item that never gets resolved into a decision that gets made and recorded.

Quantifying exposure also pays off the next time. Once you have a baseline, a new relicense is measured against an existing map rather than from scratch, and procurement carries a usage baseline into any negotiation. The discipline compounds. For the specific signals that should prompt this exercise, see open source license risk red flags to watch. If your business ships software to others, the exposure model changes, and open source license risk when you redistribute software covers that case. For the underlying concept of copyleft that often drives the cost of exposure, see the glossary entry on copyleft.

RELATED READING