ARTICLE / GOVERNANCE AND SBOM
Open source governance and SBOM FAQ.
This open source governance and SBOM FAQ gives plain answers to the questions buyers ask most: what governance is, what a software bill of materials does, how the two catch a relicense before an audit, and who should own the work. Read it as a quick orientation, then follow the links into the detail.
Open source governance and the software bill of materials are two halves of the same control. Governance sets the rules for how open source enters and stays in your software. The SBOM records what is actually there. This open source governance and SBOM FAQ answers the questions that come up when an engineering or risk leader first sizes the work, with each answer pointing to where the detail lives. The thread running through all of them is the same: most relicensing risk lands on software you already run, so the goal is a system that sees the change early rather than one that learns about it from an auditor.
What is open source governance and what does it cover
Open source governance is the standing system of rules, gates, and ownership that controls open source across its life in your software. It covers a license policy with an allowlist and a denylist, an approval gate at intake, monitoring of components already in use, and a named owner accountable for keeping it current. Governance is not a document. It is a control wired into how teams ship, so the common case moves fast and the risky case surfaces for review. The components to include are set out in what to include in an open source policy, and the gates that enforce it are covered in approval workflows for developers. How mature a program is can be assessed against the open source governance maturity model.
What an SBOM does and how it catches a relicense
A software bill of materials is a complete and current list of the open source and third party components in your software, direct and transitive, with the license state of each. It is the foundation for everything else, because you cannot govern or monitor what you cannot see. When a project moves to a source available license, an accurate SBOM tells you at once whether you run it and where. That is the difference between a one line query and a multi week investigation. The work of keeping it true is covered in maintaining an accurate SBOM, and the ongoing watch that turns a change into an alert is the subject of continuous open source license monitoring. The wave that made this urgent included HashiCorp moving Terraform and others to the Business Source License as of August 2023, Elastic moving to the Server Side Public License in 2021, and Redis moving to a source available model as of March 2024.
Who owns the work and how often it runs
Governance needs an owner or it ages into a document no one follows. Larger engineering organizations often centralize the work in an open source program office, covered in building an open source program office. Smaller teams can assign the same accountabilities to a governance lead or a cross functional committee, with legal consulted on interpretation. On cadence, the answer is continuous rather than periodic. Dependencies change with every build and a relicense can land at any time, so a quarterly snapshot is stale within weeks. The practical aim is to regenerate the inventory in the build pipeline and watch the license state of recorded components on an ongoing basis. Source available is not open source, and the restrictions these licenses add are exactly what a standing control is built to catch. The full frame sits in our pillar on open source governance and SBOM. Interpretation of any specific license belongs with your own counsel.
COMMON QUESTIONS
Questions buyers ask.
What is open source governance?
Open source governance is the set of rules, gates, and ownership that controls how open source enters and stays in your software. It covers a license policy, approval at intake, monitoring of components already in use, and a named owner accountable for keeping the system current. Strong governance catches a relicense at intake rather than in an audit, and it depends on an accurate inventory of what you run.
What is an SBOM and why does it matter?
An SBOM, or software bill of materials, is a complete list of the open source and third party components in your software, direct and transitive, with the license state of each. It matters because you cannot govern or monitor what you cannot see. When a project relicenses, an accurate SBOM tells you immediately whether you run it and where, which turns a relicense into a query rather than an investigation.
How do governance and an SBOM catch a relicense?
An SBOM records what you run and its current license state. Governance adds a rule that monitors those components for changes, not only checks them at adoption. When a component moves to a source available license such as the Business Source License or the Server Side Public License, the change registers against your inventory and triggers a review. Without the inventory, the relicense is invisible until a vendor inquiry or an audit forces the question.
Do we need an open source program office?
Not every organization needs a formal open source program office, but every organization needs an owner for open source governance. A program office centralizes policy, approvals, and monitoring, which scales well for larger engineering organizations. Smaller teams can assign the same accountabilities to a governance lead or a cross functional committee. What matters is that the policy has an owner and the inventory stays current, not the name of the function.
How often should an SBOM be updated?
An SBOM should be continuous rather than periodic. Dependencies change with every build, and a relicense can land at any time, so a snapshot taken once a quarter is stale within weeks. The practical aim is to regenerate the inventory as part of the build pipeline and to monitor the license state of recorded components on an ongoing basis, so a change is detected close to when it happens.
Is open source governance advice legal advice?
No. This is commercial and licensing risk advisory, not legal advice. We help you design the policy, the gates, the inventory, and the monitoring that keep open source risk visible and controlled. The interpretation of whether a specific license restricts your use is a question for your own counsel.
GOVERNANCE
Turn the FAQ into a working control.
Our governance and policy advisory builds the policy, inventory, and monitoring that keep open source risk visible. Independent, buyer side, paid only by you.
Not ready to talk? Read the free open source license risk guides first.