Building an open source license inventory.

Building an open source license inventory is the first practical step toward controlling relicensing exposure. Most enterprises know roughly what they run, but few hold a single record that names every component, direct and transitive, alongside the license that governs it and the date that state was last confirmed. Without that record, a license change passes unnoticed until a vendor letter or an audit forces the question. With it, the same change is a line item you can see, price, and act on. The inventory is not a one off document. It is a living asset that earns its keep every time a project moves from an open license to a source available one, which has happened repeatedly since 2023.

This article sets out a buyer side method for building and maintaining the inventory. It sits within the wider discipline covered on the pillar for open source license risk, and pairs closely with the work of mapping your open source blast radius.

Why an inventory beats a guess

The case for building an open source license inventory rests on a simple fact: licenses are not static. A component adopted under a permissive or copyleft license can move to the Business Source License or the Server Side Public License at the vendor's discretion. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023. Redis moved to a dual Redis Source Available License and Server Side Public License model as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. Each of those changes applied to software already running in production somewhere, and each created exposure that the operator had not chosen. An inventory is what lets you find the affected component on day one rather than after the cost has compounded.

The inventory also answers questions you will eventually be asked. A regulator may want a software bill of materials. A vendor may assert that your use breaches a new term. An acquirer may probe your dependency tree in diligence. In each case the inventory turns an open ended inquiry into a bounded, answerable one. The difference between a defensible record and a scramble is built long before the question arrives.

Step one: define the scope

Decide what the inventory covers before you start collecting. Most enterprises scope it to all software they build, deploy, or distribute, which means production services, internal tooling, build pipelines, and anything shipped to a customer. The boundary matters because license obligations differ sharply by use. Software you only run internally carries different exposure than software you redistribute, a distinction explored in open source license risk when you redistribute software. Capture the use context for each component, not just its name, because the same library can be low risk in one place and high risk in another.

Scope also means depth. A shallow inventory that lists only the dependencies you declared misses the larger population of transitive ones pulled in beneath them. The license that creates the problem is often three or four levels down, which is why depth is not optional.

Step two: generate the dependency tree

With scope set, generate a software bill of materials from each build using your package managers and a software composition analysis step in the pipeline. This produces the full tree, direct and transitive, in a standard format such as SPDX or CycloneDX. The tree is the raw material of the inventory. It is worth generating it from the build itself rather than from a manifest, because manifests describe intent while builds describe reality, and the two diverge more often than teams expect. The transitive layer is where most surprises hide, a point made in detail in transitive dependencies and hidden license risk.

The same software bill of materials that anchors the inventory also satisfies regulatory and customer demands, so the work serves more than one master. The relationship between the two is covered in open source license risk and your SBOM.

Step three: resolve and date every license

For each node in the tree, record the license that governs it and the date you confirmed that state. The date is the part teams forget and the part that matters most. A license is a moving target, and a record that says a component is openly licensed without saying when that was true is worth little once the project relicenses. By dating each confirmation, you create the ability to detect change: when a later scan returns a different license for the same component, you know a relicense has occurred and roughly when. Note also whether the license is open source in the recognized sense or merely source available, since the two are not the same and source available licenses such as the Business Source License and the Server Side Public License are not approved as open source.

Where the resolved license is ambiguous or dual, capture both the options and the basis for your reading, and flag it for review. Interpretation of a specific license against your use is a question for your own counsel, and the inventory should make those questions easy to find rather than pretend to answer them.

Step four: keep it current

An inventory built once and shelved decays quickly, because new dependencies arrive with every release and licenses change without notice. Wire the inventory into the build so it refreshes continuously, and set a monitor that flags when a component's license state differs from the last confirmed value. This turns the inventory from a snapshot into a sensor, one that alerts you the moment a project moves. The practice of watching license state over time is the subject of open source license risk monitoring over time. Maintained this way, building an open source license inventory pays back its cost on the first relicense it catches early.

Treat the inventory as evidence as well as a working tool. A dated, continuously refreshed record of what you run and under which terms is exactly what an auditor, a vendor, or a board wants to see. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license and your compliance position, your own counsel is the right place to turn.