The open source license risk assessment process.

Most enterprises discover their open source license exposure in the worst possible way: a vendor letter, an audit notice, or a question from the board that no one can answer. The open source license risk assessment process exists to replace that discovery with a method. It is a structured sequence that moves from an honest scope through a complete dependency map to a ranked, costed plan, so the exposure is known before it is asserted. This article sets out the process step by step, the same one we run for buyers from our side of the table.

Why a process beats a tool scan

A scanner can list components. It cannot tell you which of them matters, where the exposure concentrates, or what to do about it. The open source license risk assessment process is the judgment that turns a list into a decision. It reads current license state rather than the state recorded at adoption, it traces the blast radius of a relicensed component through everything built on it, and it ranks findings by real exposure rather than alphabetical order. The recent license changes make this distinction sharp. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023. Redis moved to a dual model including the Server Side Public License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. A scan that trusts the old license string will report all of these as the projects they used to be.

Step one: scope the assessment honestly

The process begins by deciding what is in scope, and the honest answer is usually the production estate and the build pipelines that feed it. Scoping too narrowly produces a clean report that means nothing; scoping the entire organization at once produces a project that never finishes. The right scope is the software whose license exposure could actually hurt you: the customer facing services, the revenue systems, and the infrastructure they depend on. We define that scope with you at the start, because an assessment is only as defensible as the boundary it draws, and a boundary drawn to flatter the result is worse than no assessment at all.

Step two: map the full dependency tree

With scope set, the process resolves the complete dependency tree for everything in it. Direct dependencies, the components you chose, are the easy part. The exposure usually hides in the transitive layer, the components you inherited through something else and never evaluated. We resolve dependencies from manifests, lockfiles, and built artifacts, then reconcile what is declared against what actually ships, because the two often differ. This mapping work is the foundation the rest of the assessment rests on, and it is the subject of our deeper guide on building an open source license inventory and our SBOM and dependency mapping service.

Step three: record current license state per node

Each node in the tree is then tagged with its license as it stands today, not as it stood when the component was adopted. This is the step that catches the relicensing exposure, because a component pulled in years ago under a permissive license may now carry the Business Source License or the Server Side Public License. Source available is not open source, and these licenses are not approved by the Open Source Initiative, so a node that looks familiar by name can carry a commercial use restriction it did not have before. The license state is dated, with an as of marker, because this is a fast moving topic and a finding without a date ages into a guess.

Step four: trace the blast radius

A single relicensed component is rarely the whole story. The process traces its blast radius: everything built on it, everything that ships it, and every service whose license posture changes because of it. A source available database deep in the tree can change the exposure of every product that depends on the service it backs. Mapping the blast radius is what turns a one line finding into an understanding of what is actually at stake, and it is what lets the next step rank exposure by consequence rather than by count. The phrase we use with buyers is simple: find the blast radius before the vendor does.

Step five: rank the exposure by risk

Not every finding deserves equal attention. The process ranks exposure by a combination of how restrictive the license is, how the component is deployed, and how much sits on top of it. A Business Source License component under a competitive production system ranks far above the same license on an internal tool used by three people. This ranking is what makes the assessment actionable, because it tells the organization where to spend its first and scarcest remediation effort. It is also what makes the assessment honest, because it resists the temptation to bury the one material finding in a list of a hundred trivial ones.

Step six: produce a costed containment plan

The assessment ends not with a problem but with a plan. For each material finding, the process lays out the routes to contain it, a fork, a migration, removing the dependency, or a negotiated commercial license, with the cost and the timeline of each. The aim is a containment plan the organization can act on and a board can approve, sequenced so exposure falls early. The options and the order are the subject of our remediation and alternatives pillar. A containment plan grounded in a credible alternative is also the leverage that disciplines a vendor's price, which is why the assessment and any later negotiation are part of the same arc.

What you hold at the end

When the process completes you hold four things: a dependency map with current license state per node, a blast radius analysis for the relicensed components, a risk ranked findings list, and a costed containment plan. Together they form a picture you can defend to a vendor, an auditor, or your board, and a basis to act rather than react. For the questions buyers raise most often about this work, see our open source license risk FAQ, and for the full frame, the open source license risk pillar. The assessment is not a document for the shelf. It is the start of a contained position.