License Compliance

License obligations in dependency trees

License obligations enter a codebase every time a developer adds a dependency. Most violations trace back to transitive dependencies that no one explicitly selected. A direct dependency with a permissive license may pull in dozens of transitive dependencies, some carrying disclosure or attribution obligations incompatible with the organisation's distribution model. These conflicts surface during audits or customer due diligence, long after the dependency shipped.

Without systematic license visibility, compliance teams discover problems reactively. A customer's legal review flags an incompatible license in a shipped product. An internal audit reveals components with no license data at all. A supplier changes license terms between versions, and no one notices until the next procurement review. Each discovery forces component replacement or isolation under time pressure.

SBOMs provide the per-component license data that makes proactive compliance management possible.

License visibility through SBOMs

SBOM generation tools extract license metadata from package manifests and LICENSE files. Each component entry includes an SPDX license identifier or expression. For identifier syntax, expression operators (AND, OR, WITH), and format requirements, see Licenses.

License coverage, the percentage of components with valid license data, is the primary quality metric. Components marked NOASSERTION (license unknown) or NONE (explicitly unlicensed) represent gaps requiring follow-up. The framework does not prescribe a specific threshold; treat coverage as an organisational policy decision.

At L1, SBOMs contain basic license identification for declared components. License data may be incomplete for transitive dependencies, and enrichment is manual.

At L2, automated generation achieves high license coverage across the full dependency tree. License expressions accurately represent multi-license and exception scenarios. SCA (Software Composition Analysis) tools validate coverage as part of the generation pipeline.

Dual-licensed and multi-licensed components require attention. An OR expression means the consumer selects which license applies; an AND expression means all listed licenses must be satisfied. Producers should document which license they selected from multi-license offerings so downstream consumers and auditors have a clear record.

Producer: policy enforcement in CI/CD

Organisations define license policies that categorise licenses into allowed, requires-review, and prohibited tiers. The categories reflect the organisation's business model, distribution method, and regulatory obligations. Policy content varies: what a SaaS provider prohibits may differ from what an on-premise vendor restricts. The framework does not prescribe which licenses belong in which tier.

SCA tools evaluate SBOM license data against the organisation's policy at CI/CD checkpoints. A build that introduces a prohibited license fails the gate or raises a flag for review. Integration points include pull request checks and build pipelines. Earlier gates reduce remediation cost.

At L1, license checks may run manually or at release milestones. At L2, automated policy evaluation runs on every build, integrated into the same pipeline that generates and validates the SBOM.

Producer: obligation tracking and compliance artifacts

Licenses carry obligations beyond the right to use. Attribution requirements and source disclosure conditions vary by license. SBOM license data makes these obligations visible per component, per release, replacing ad-hoc auditing with a repeatable check.

Attribution and NOTICE files can be generated directly from SBOM license data. Automating this generation ensures attribution stays current as dependencies change between releases. Manual attribution files drift out of sync within a few release cycles.

Dependencies can change license terms between versions. A major version upgrade may introduce obligations incompatible with the organisation's policy. Comparing SBOM license data across dependency versions before upgrading catches these changes before they reach production.

For commercial or proprietary components, the SBOM should contain copyright attribution and signal that commercial terms exist external to the SBOM. Use a license.name field referencing the agreement rather than an SPDX id. This tells consumers the component is not open-source licensed and that separate contractual terms apply.

Consumer: license assessment of vendor software

When vendors provide SBOMs, procurement leads and third-party risk managers evaluate the license data against the organisation's own policies before signing contracts. A vendor SBOM revealing incompatible license obligations is a procurement risk. Identifying it before contract signature avoids post-deployment remediation.

Monitoring does not end at procurement. When vendors ship updated SBOMs with new software versions, consumers compare license data against the previous version. A dependency that changed from a permissive to a restrictive license between versions requires reassessment, even if the vendor's own compliance posture is unchanged.

Components with NOASSERTION or missing license data in vendor SBOMs represent unresolved risk. Consumers should flag these gaps as supplier quality issues and request clarification. This assessment integrates with broader Supplier Transparency practices.

Common pitfalls

Treating low license coverage as acceptable. Components without license data are not "probably fine." They represent unknown obligations. Target high coverage and treat gaps as action items, not noise.

No automated enforcement. A license policy that exists only in a document and relies on developer awareness will be violated. Integrate policy checks into CI/CD where violations are caught before they ship.

Ignoring NOASSERTION entries. NOASSERTION entries require investigation, not dismissal. Contact the upstream maintainer or evaluate alternatives.

Skipping license checks on dependency upgrades. A dependency that was compliant at version 2.x may carry different terms at version 3.x. Re-evaluate license data with every major dependency change.

One-time compliance instead of continuous. License compliance is not a checkbox at release time. Dependencies change, vendors relicense, and new transitive dependencies appear. Automated SBOM generation and policy evaluation on every build catches these changes before they require emergency remediation.

Related concepts

• Licenses for SPDX identifier syntax, license expressions, and field-level format requirements
• Generate SBOMs for the generation pipeline that produces the license data this page relies on
• Supplier Transparency for the broader vendor assessment workflow