Open source license risk and your SBOM.

You cannot manage what you cannot see. Open source license risk and your SBOM meet at exactly that point. A software bill of materials is the inventory of every component you run, and the license state of those components is where the risk lives. When a project relicenses, the only reliable way to know whether it affects you is to check it against a current, complete bill of materials. Without one, the first sign of exposure is usually a vendor letter.

Why the SBOM is the foundation of license risk

Open source license risk is the chance that a component you depend on carries terms that restrict your use, demand a commercial license, or impose obligations you have not met. Sizing that risk requires three facts for every component: what it is, which license governs it, and where it runs. A software bill of materials is the only artifact that holds all three in one place. Every later step, from mapping a blast radius to defending an audit, draws on the SBOM. If the inventory is wrong, everything built on it is wrong too.

This matters more now than it did a few years ago. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License, with Valkey 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 these source available licenses are not approved by the Open Source Initiative. The SBOM is how you find out which of these, if any, are in your estate.

How an SBOM surfaces relicensing exposure

A license aware SBOM does more than list components. When it records the current license state of each one and refreshes on a regular cadence, it becomes a detector. A relicense shows up as a change in the license field of a component you already track. Compared against the prior snapshot, the change is obvious, and the affected component is already linked to the services and products that depend on it. The exposure that would otherwise stay hidden until an audit becomes a line item you can act on.

The same map also supports the reverse query. When a vendor asks how you use a particular component, the SBOM answers immediately: here is every place it runs, in which version, since when. That turns a stressful open ended inquiry into a bounded one, which is the entire point of keeping the inventory current.

What a license aware SBOM must capture

A bill of materials built for security alone often falls short for license risk. To serve license risk, the SBOM must capture transitive dependencies, not just the direct ones, because most relicensing exposure hides in the deeper layers. It must record the current license rather than the license declared at publish time, since those frequently differ after a relicense. And it should link each component to where it runs, so a flagged license can be traced to a deployment and a use. An SBOM that records only top level components and trusts the manifest license will miss the very exposure you are trying to find.

Which SBOM format suits license tracking

SPDX and CycloneDX are the two leading formats. SPDX is an ISO standard with deep support for license expressions, which makes it strong for the license tracking that relicensing risk demands. CycloneDX grew out of the security community and carries vulnerability and dependency data well. For license risk specifically, SPDX license expressions are valuable, but many enterprises generate both formats because a customer, a regulator, and a scanner each prefer a different one. The format matters less than generating it automatically and keeping it current.

Keeping the SBOM current

A snapshot ages quickly. License changes arrive on the vendor schedule, not yours, so an inventory refreshed once a year can carry a relicense undetected for months. The SBOM should regenerate on every build, or at least on a cadence that matches how fast your software and its licenses move. Automation is the only way to sustain this. A bill of materials assembled by hand is already out of date by the time it is finished, and it cannot scale to an estate of any real size.

From SBOM to action

The SBOM is the start, not the finish. Once it flags a relicensed component, the work moves to classification and decision: is the use restricted, what does the exposure cost, and what is the path to contain it. The SBOM scopes that work precisely, so the decision rests on facts rather than estimates. It also has limits worth naming. An SBOM can tell you a component carries the Business Source License; it cannot tell you whether your particular use crosses the line the license draws. That judgment is advisory work, and the legal interpretation belongs to your own counsel.

A license aware SBOM underpins our open source license risk assessment service. For the wider frame, read our pillar on open source license risk. To put the inventory to work, see how to map your open source blast radius and how auditors and vendors find your exposure. For the governance discipline around it, read our pillar on open source governance and SBOM.