Open-source license compliance starts with your SBOM
Most teams adopt SBOMs for security reasons — vulnerabilities, supply-chain risk, regulatory pressure. But the same inventory that powers vulnerability management quietly solves another problem that has been lurking in every codebase for years: open-source license compliance. If you are producing SBOMs and not using them for license governance, you are leaving value on the table.
The problem nobody schedules time for
Every open-source component you use carries a license — a legal agreement governing how you may use, modify, and distribute it. Most are permissive and harmless. Some carry obligations: attribution requirements, source-disclosure requirements (copyleft), or terms simply incompatible with how you ship your product.
The trouble is that licenses, like the dependencies that carry them, arrive transitively and invisibly. You did not read the license of the library three levels deep in your dependency tree. You may not know it is there. And license risk, unlike a vulnerability, does not announce itself with a CVE — it surfaces during due diligence for an acquisition, a funding round, or a major enterprise deal, usually at the worst possible moment.
Why the SBOM is the right foundation
License compliance and SBOMs are a natural fit because they need the same underlying data: a complete, accurate inventory of every component you ship, including transitive dependencies. Once you have that inventory, license information is just another attribute attached to each component.
In fact, SPDX — one of the two major SBOM formats — began life as a licensing standard before it became a general SBOM format. License data is not bolted onto SBOMs; for one of the formats, it was the original purpose.
What good license governance looks like
With a current SBOM per product, license compliance becomes a set of answerable questions:
- What licenses are present across all our components, including transitive ones?
- Are any incompatible with how we distribute our product — for example, a strong copyleft license in a proprietary application we ship to customers?
- What attribution do we owe? Many permissive licenses require you to reproduce copyright notices; an SBOM lets you generate that attribution automatically.
- What changed between this release and the last? A new transitive dependency can introduce a new license obligation silently.
The categories that matter
You do not need to be a lawyer to grasp the basic risk tiers:
- Permissive (MIT, Apache 2.0, BSD): minimal obligations, usually just attribution. Low risk.
- Weak copyleft (LGPL, MPL): obligations typically scoped to the component itself. Moderate, manageable.
- Strong copyleft (GPL, AGPL): can impose source-disclosure obligations on software that links to them. High risk for proprietary products, and AGPL in particular can reach network-delivered services.
- No license / unknown: a component with no clear license is a genuine liability — you have no granted rights to use it at all.
That last category deserves emphasis. An unlicensed dependency is not a free one; it is one you have no legal right to use. A good SBOM flags these "unknown license" components explicitly rather than letting them hide.
Make it continuous, not a fire drill
The failure mode is treating license review as a one-time event — a frantic audit before a deal closes. The fix is the same as for vulnerabilities: make it continuous. If your SBOM is regenerated every release and your tooling flags new or risky licenses as they appear, license compliance becomes a steady background process instead of an emergency. The inventory you built to manage vulnerabilities already contains everything you need.