Open source governance and SBOM: the complete guide.

What open source governance and SBOM mean

Open source governance and SBOM are two halves of the same discipline. Governance is the set of rules, owners, and gates that decide which open source enters your software and on what terms. A software bill of materials, or SBOM, is the inventory that records what actually got in. One sets policy. The other proves what the policy produced. Neither is much use alone. A policy with no inventory cannot be enforced, and an inventory with no policy is just a list.

For an enterprise, the purpose is plain. You run software you did not write, layered many levels deep, and the license terms on that software can change without your involvement. Governance and SBOM give you a way to answer three questions at any moment: what do we run, under which license, and since when. When those answers are current and defensible, a relicense becomes a flag you handle on your own schedule rather than a finding an auditor hands you.

Why open source governance and SBOM matter now

For years, governance was treated as a tidy back office task. The license on a popular component was permissive, it stayed permissive, and the inventory rarely earned a second look. That assumption no longer holds. A wave of widely used projects has changed terms, and the change reaches code already in production.

As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer from an open source license to the Business Source License 1.1, which restricts competitive production use and converts to an open license after a delay. IBM later acquired HashiCorp, and the community created OpenTofu as an open fork of Terraform. As of March 2024, Redis moved to a dual model under the Redis Source Available License and the Server Side Public License, prompting the Valkey fork. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, prompting the OpenSearch fork. MongoDB moved to the Server Side Public License in 2018.

Two facts make these changes a governance problem rather than a footnote. Source available is not open source, and the Business Source License and the Server Side Public License are not approved by the Open Source Initiative. A component you adopted under permissive terms may now sit under terms a vendor reads as requiring a commercial agreement. If your inventory is stale, you will not know until someone asks. The point of governance and SBOM is to make sure you know first.

What goes into a software bill of materials

A useful SBOM lists every component in a piece of software, both the direct dependencies your teams chose and the transitive ones those dependencies pulled in. For each component it records the name, the version, the supplier, a unique identifier, and the declared license. The good ones also record where the component runs and how it reached you, so a finding can be traced from a license back to a deployment.

Depth is what separates a real SBOM from a checkbox. Most relicensing exposure hides in the transitive layers, in the dependency of a dependency that no engineer consciously selected. An SBOM that stops at the top level will miss exactly the components most likely to surprise you. Currency matters just as much. A bill of materials is a snapshot, and a snapshot from last quarter cannot tell you what relicensed last month. The inventory has to refresh on a cadence that matches how fast your software and its licenses change.

SPDX and CycloneDX: which SBOM format to use

Two formats dominate. 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 application security community and carries vulnerability and dependency relationship data well, which makes it the common choice in security tooling. The formats are not rivals so much as lenses. Many enterprises produce both, because a regulator, a customer, and a security scanner each prefer a different one.

The format matters less than the discipline of generating it automatically and keeping it current. An SBOM that a person assembles by hand once a year is already wrong by the time it is finished. The same map that satisfies a customer contract clause should be the map your team queries to find a relicensed component, which means it must be machine generated and continuously refreshed.

What open source governance includes

Governance has four working parts. The first is policy: a written statement of which licenses are allowed, which are allowed with conditions, and which are blocked. A good policy names the families plainly, from permissive licenses such as Apache License 2.0 and MIT, through weak copyleft, to strong copyleft such as the GNU AGPL, and on to source available terms such as the Business Source License and the Server Side Public License.

The second is approval gates: the points in the development flow where a new component is checked against policy before it can be used. The third is intake controls: the automation that enforces the gate, so a blocked license cannot quietly enter a build. The fourth is ownership: a named team accountable for the policy, the gates, and the inventory. Without an owner, governance erodes the moment the first deadline pressures a team to skip the gate.

The aim is to set the rules before the next change lands, not after. A future relicense should be caught at intake, where it is cheap to handle, rather than in an audit, where it is not. Read more on building developer friendly checks in our guide to open source approval workflows for developers.

The role of an open source program office

An open source program office, or OSPO, is the team that owns open source strategy, policy, and compliance across an organization. It is the natural home for governance. The OSPO sets the license policy, runs the approval gates, owns the inventory that the SBOM produces, and acts as the single point of contact when a vendor or auditor asks a licensing question. In smaller organizations the role may sit with a single architect or a security lead, but the function is the same: someone owns the rules and the record.

A program office also closes the loop between governance and the business. It translates a license change into a decision the board can read, and it carries the institutional memory of why a given component was approved and on what terms. For a fuller definition, see our glossary entry on the open source program office.

How software composition analysis fits in

Software composition analysis, often shortened to SCA, is the tooling that scans your code and builds to identify open source components and their licenses. It is the engine behind a current SBOM. SCA tools detect components, resolve transitive dependencies, and flag known vulnerabilities and license concerns. They are necessary but not sufficient. A scanner can tell you that a component carries the Business Source License; it cannot tell you whether your particular use of that component crosses the line the license draws. That judgment is where governance and advisory work begin.

Used well, SCA feeds the inventory automatically, the inventory feeds the policy engine, and the policy engine feeds the gate. The chain runs without a human until a finding needs a decision. For practical patterns on wiring this up, see our article on open source inventory automation.

How governance catches the next relicense

Catching a relicense is a sequence, not a single control. Continuous monitoring watches the inventory against the current declared license of each component. When a project changes terms, the monitoring flags the affected component at the next refresh. The policy then classifies the new license: permissive, copyleft, source available, or blocked. If the new state is restricted, the intake gate prevents any new use of the component while the existing exposure is assessed. The program office decides what to do next, whether that is remediation, a negotiated license, or a documented decision to accept the risk.

The difference this makes is timing. An organization without governance learns about a relicense when a vendor sends a letter or a renewal arrives with new terms. An organization with governance learns about it at the next inventory refresh, on its own schedule, with the affected deployments already mapped. The exposure is the same. The position is entirely different.

A maturity path for governance and SBOM

Most enterprises do not arrive at full governance in one step. A workable path starts with visibility: stand up software composition analysis and produce a first SBOM, even an imperfect one, so you can see what you run. The second step is policy: write down which licenses are allowed and which are not, and classify what the inventory found. The third is enforcement: wire the policy into approval gates and intake controls so the rules hold at build time. The fourth is monitoring: refresh the inventory continuously and watch for license changes. The fifth is ownership: stand up an open source program office, or assign the function clearly, so the discipline survives turnover and deadline pressure.

Each step delivers value on its own, so the program is worth starting even if you cannot reach the end this year. The first SBOM alone will usually surface a relicensed component or two that no one had flagged. That finding, handled early, often pays for the whole effort. This work is advisory, not legal advice; for interpretation of any license term, engage your own counsel.

Related reading across the cluster

This pillar anchors our governance and SBOM cluster and connects to the wider practice. For the developer facing controls, read open source approval workflows for developers. For the tooling and automation behind a current inventory, read open source inventory automation. To define the team that owns it all, see the glossary on the open source program office.

For the broader frame, see our pillar on open source license risk, which covers how exposure forms and spreads, and our pillar on relicensing, which explains the license mechanics that governance is built to catch. When you are ready to put rules in place, our open source governance and policy service builds the policy, gates, and inventory to your risk tolerance.

MORE IN THIS CLUSTER

Explore more from this guide.