How to map your open source blast radius.

A blast radius is a borrowed term, and a useful one. In open source license risk it means the full set of systems, products, and obligations touched when a single component changes its terms. The component itself is only the center. The damage, if there is any, spreads outward through everything that depends on it. Mapping that spread is the difference between a vague worry and a plan.

What is an open source blast radius?

Your open source blast radius is everything affected when one component relicenses. That includes the component, every service and product that depends on it directly, every component that depends on it transitively, and the commercial and compliance exposure that flows from the new terms. A relicense at a low layer of your stack can surface in a dozen products you would not connect to it at first glance. The blast radius is the honest accounting of that reach.

The reason the metaphor fits is that exposure is rarely contained to the obvious place. A database library three levels deep in a build, pulled in by a framework no one thinks about, can carry a license change straight into a flagship product. Mapping the blast radius means following those paths to their ends rather than stopping at the components you remember choosing.

Why mapping the blast radius matters now

The relicensing wave made this exercise urgent. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1, which restricts competitive production use. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License, with Valkey forming as the open fork. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, with OpenSearch as the fork. MongoDB moved to the Server Side Public License in 2018. Source available is not open source, and none of these source available licenses are approved by the Open Source Initiative.

Each change can apply to software already running in production. The blast radius is how you find out whether it applies to yours, and how widely. Here are the five steps we use.

Step one: build a complete inventory

Everything starts with knowing what you run. Use software composition analysis to produce a software bill of materials that lists every component, direct and transitive, with its name, version, and declared license. A partial inventory produces a partial blast radius, which is worse than none because it offers false comfort. The inventory must reach the transitive layers, because that is where most relicensing exposure hides. If you do not yet hold a current inventory, building one is the first deliverable, not a prerequisite you are assumed to have.

Step two: identify the relicensed components

With the inventory in hand, flag the components whose terms have changed. The declared license in a package manifest is often the license at publish time, not the license in force today, so this step requires checking current project state rather than trusting the manifest. Pay particular attention to the projects in the relicensing wave and to any component that moved to a source available or strong copyleft license such as the GNU AGPL. This is where the center of each blast radius sits.

Step three: trace the dependency tree outward

For each relicensed component, follow the edges. Which services import it directly. Which products ship those services. Which other components pull it in transitively. The goal is a map that runs from a single changed license out to every product and system it touches. This is the literal blast radius, and it is usually wider than the team expects, because a component low in the stack fans out as you climb.

Step four: classify exposure by how you use it

Not every touch point carries the same risk. A license such as the Business Source License restricts specific uses, commonly offering a competing product or service. The Server Side Public License attaches conditions when you offer the software as a service. So each node on your map needs a use classification: internal only, customer facing, or part of an offering that the license might restrict. The exposure concentrates in the nodes where your use intersects what the license actually limits. The rest of the map matters for completeness but rarely drives the decision.

Step five: size and rank the exposure

Finally, put numbers on it. For each material node, estimate the cost of exposure if the risk lands and the cost to cure it, whether that means migration, a negotiated license, or removal. Rank the nodes so the work follows the money. A board does not want a flat list of two hundred components; it wants the five that matter, with a cost attached and a recommended path. That ranked, sized picture is the finished blast radius map, and it is what turns the analysis into a decision.

Common mistakes to avoid

Three mistakes recur. The first is stopping at direct dependencies, which leaves the transitive exposure invisible. The second is trusting the manifest license rather than checking current project state, which misses the relicense entirely. The third is treating every flagged component as equally urgent, which buries the few that matter under the many that do not. A good map avoids all three by being complete, current, and ranked.

Mapping the blast radius is the foundation of our open source license risk assessment service. For the wider frame, read our pillar on open source license risk. To connect the map to your inventory discipline, see open source license risk and your SBOM, and to understand how others find the same exposure, read how auditors and vendors find your exposure. For the license mechanics behind it all, compare the Business Source License, the Server Side Public License, and the GNU AGPL.