Open Source Licence Compliance Guide: Obligations, SBOMs and Policy

Most software an organisation ships or runs is built largely from open source components, and every one of them arrives with licence obligations that someone has to know about and meet. Missing an attribution notice, shipping a copyleft library inside a proprietary product or running modified AGPL code as a service can force a product recall, a source code release or a negotiated settlement. Licence compliance is also a supply chain discipline: the same component inventory that answers "are we exposed to this CVE?" answers "what are we obliged to do for this licence?". This guide covers licence categories and their obligations, SPDX identifiers and expressions, licence data in SBOMs, the OpenChain ISO/IEC 5230 programme standard, policy and tooling, and how to roll a programme out. It is written for application security, platform engineering and open source programme office (OSPO) practitioners who need a working process, and it is not legal advice: decisions on specific licences belong with counsel.

Key takeaways

• Obligations depend on what you do with the code, not only on the licence: distribution, modification, linking and network use each trigger different duties.
• Use SPDX identifiers and expressions everywhere (policy, scanners, SBOMs) so that "GPL-2.0-only OR MIT" means the same thing to every tool and person.
• Separate declared from concluded licences: what a package says about itself is evidence, not a decision, and scanners regularly find files under other licences.
• ISO/IEC 5230 (OpenChain) defines the programme, not the licence answers: roles, policy, competence, review and artefacts that let customers trust your compliance.
• Licence data now belongs in the SBOM: CISA's 2025 draft minimum elements add licence as a field, so one inventory should serve security and legal review.

Licence families and what they require

The Open Source Initiative's Open Source Definition sets ten criteria a licence must meet to be called open source, including free redistribution, access to source code, permission for derived works, and no discrimination against persons, groups or fields of endeavour. Within that space, licences fall into families whose obligations differ sharply.

Two compatibility facts catch teams regularly. The Apache Software Foundation explains that Apache-2.0 code can be included in GPLv3 projects but not the other way round, and that the Free Software Foundation has never considered Apache-2.0 compatible with GPLv2 because of its patent termination and indemnification terms. The ASF's own third-party policy is a useful model of a tiered list: Category A (Apache-like: Apache-2.0, BSD-3-Clause, MIT, ISC, zlib, BSL-1.0) may be included, Category B (EPL-2.0, MPL-2.0, CDDL-1.1) may be included in binary form only with prominent labelling, and Category X (GPL, AGPL, LGPL, SSPL-1.0, BUSL-1.1, BSD-4-Clause) may not be included because they place restrictions on larger works.

Licence terms also change between versions of the same project. HashiCorp moved future releases of its products from MPL 2.0 to the Business Source License 1.1 in August 2023, keeping most libraries and SDKs on MPL 2.0 and restricting use that provides a competitive offering. A routine version bump can therefore change your obligations, which is why licence review must run on every dependency update, not only on first adoption.

How obligations are triggered

• Internal use only: running unmodified open source internally triggers few obligations under most licences. The exception is network copyleft: an internally hosted but externally reachable service built on modified AGPL code is in scope.
• Distribution: shipping software to customers in any form (installers, mobile apps, firmware, container images, virtual appliances, SDKs) is the main trigger. A public container image counts: the image layers carry every package's obligations.
• Modification: weak copyleft licences focus on modified files or libraries; track patches you carry on top of upstream so you can publish them when required.
• Linking and combination: static versus dynamic linking matters for LGPL; vendoring copied source files into your repository makes their licence part of your code base and is easily lost.
• Snippets: code copied from forums, documentation or AI coding assistants may carry a licence or none. Snippet matching tools exist for this, and AI-generated code needs the same provenance question asked of it. See the AI-Generated Code Review Guide.
• AI models and datasets: model weights and training data often use licences outside the classic software families (custom model licences, Creative Commons for data). The OSI's Open Source AI Definition 1.0 requires that users can use, study, modify and share the system, and that the preferred form for modification includes data information, the complete training and running code, and the parameters. Treat a model labelled "open" as unverified until its licence is reviewed. See the AI-BOM Guide.

SPDX identifiers, expressions and licence evidence

The SPDX License List (version 3.29.0 at the time of writing) gives each licence and exception a short identifier, full name, canonical text and permanent URL, and flags whether it is OSI approved and FSF free/libre. Using these identifiers in policy and tooling removes the ambiguity of strings such as "BSD" or "GPL".

Expression syntax

Precedence runs from + to WITH to AND to OR, so LGPL-2.1-only OR BSD-3-Clause AND MIT means LGPL-2.1-only OR (BSD-3-Clause AND MIT). Policy engines that split strings on spaces get this wrong; use a proper expression parser.

Declared versus concluded

• Declared licence (SPDX 2.3 field 7.15, PackageLicenseDeclared): what the package authors state inside the package, such as a COPYING file. Registry metadata from outside the package does not belong here.
• Licence information from files (7.14): every licence a scanner finds in the package's files, with no statement of how they combine.
• Concluded licence (7.13, PackageLicenseConcluded): the licence the SBOM author concludes governs the package after weighing declared data, file evidence and scanner output.
• NONE versus NOASSERTION: NONE is a positive statement that no licence or copyright exists; NOASSERTION means no determination was made. A NOASSERTION concluded licence on a shipped component is an open finding, not a pass.

For code you publish, an SPDX-License-Identifier: comment at the top of each source file makes your own licensing machine-readable for downstream consumers and their scanners.

Licence data in the SBOM

An SBOM is the natural home for licence evidence because it already lists every component, version and relationship. The 2021 NTIA minimum elements did not include licence. CISA's draft 2025 Minimum Elements for a Software Bill of Materials, published for public comment until 3 October 2025, proposes four additional fields: component hash, licence, tool name and generation context. Check the CISA site for the status of the final version before citing it in contracts.

• SPDX: package-level declared and concluded licences, per-file licence information and copyright text, all expressed with SPDX expressions.
• CycloneDX: licences attach to each component (components[].licenses[]), and the format supports declared, observed and concluded licences as well as commercial licence tracking for software asset management.
• Scope: generate the SBOM from the built artefact (container image, package, firmware) as well as from source, because build steps pull in base image packages and transitive dependencies that the source manifest never shows.
• Attribution output: generate the third-party notices file shipped with the product from the same SBOM, so notices cannot drift from what is actually inside.

For SBOM formats, generation and exchange in depth, see the SBOM Guide.

Programme design with ISO/IEC 5230

ISO/IEC 5230:2020 is the OpenChain Specification 2.1 transposed into an international standard in December 2020; ISO lists it as confirmed and current in 2026. It specifies the key requirements of a quality open source licence compliance programme: where compliance processes belong, who holds which role, and how the programme stays sustainable. Organisations can self-certify against the OpenChain checklist, use an independent assessment, or obtain third-party certification, and conformant organisations can list themselves publicly. Its sibling ISO/IEC 18974 applies the same programme structure to open source security assurance (known vulnerability handling), so one OSPO process can cover both.

Choosing a policy model and tooling

• Use-case based policy over a single list: AGPL-3.0-only may be acceptable for an unmodified internal tool and unacceptable inside a hosted product. Key decisions on licence plus use case plus modification.
• Small organisations: start with a short allow list of permissive licences, deny strong and network copyleft in distributed products, and send everything else to one reviewer. An SBOM tool plus a policy check in CI is enough.
• Large or regulated organisations: run an OSPO, adopt ISO/IEC 5230, require supplier SBOMs with licence data in procurement, and keep per-release compliance archives for the support life of each product.
• Scanner types: manifest-based software composition analysis is fast but trusts declared metadata; file-level licence and copyright scanning finds embedded licences and headers; snippet matching finds copied code. Most programmes need the first two; add snippet matching where code copying or AI generation is common.
• Remediation choices: replace the component, elect a permissive option in an OR expression, isolate it behind a process or network boundary after legal review, obtain a commercial licence, or comply by publishing source. Record the choice with the component version it applies to.

Vendor tooling for composition analysis usually covers licence and vulnerability data together; see the Software Supply Chain Security Buyer's Guide for evaluation criteria.

Implementation roadmap

1. Inventory (weeks 1 to 4): generate SBOMs for the top revenue products and every externally distributed artefact, including container images. Record declared and file-level licences.
2. Policy draft (weeks 2 to 6): with counsel, write tiered policy keyed to SPDX identifiers and use case; encode it as policy-as-code.
3. Audit mode in CI (weeks 6 to 10): run the policy check on pull requests and builds in report-only mode; measure findings, false positives and unknown licences without blocking.
4. Triage the backlog: resolve denied licences in shipped products first, then NOASSERTION and LicenseRef- components, then missing notices.
5. Enforce in rings: block new denied licences on a pilot set of repositories, then on all repositories that produce distributed artefacts. Keep an exception workflow with expiry dates; rollback is switching the gate back to report-only for a repository, not deleting the policy.
6. Release artefacts: generate notices files and source archives automatically per release and attach them to the release record.
7. Formalise: self-certify against ISO/IEC 5230, publish an enquiry contact, and add licence evidence requirements to supplier contracts.

Detection and measurement

• Monitor: new dependencies and version changes on every merge, licence changes between versions of an existing component, LicenseRef- and NOASSERTION results, and SBOM diffs between releases.
• Metric: licence coverage percentage of components in distributed products with a concluded licence that is not NOASSERTION (target above 98 percent).
• Metric: policy violations in released artefacts (target zero), tracked separately from violations caught before merge.
• Metric: review turnaround median days from conditional-licence request to decision.
• Metric: release evidence completeness share of releases with SBOM, notices file and, where needed, source archive stored.
• Metric: exception age count of licence exceptions past their expiry date.

Framework mapping

For the security side of the same inventory see the Open Source Security Guide, and for product obligations in the EU see the EU Cyber Resilience Act Guide.

Common failure patterns

• Trusting registry metadata: the package manifest says MIT, but a bundled subdirectory is GPL. Only file-level scanning finds it, which is why concluded licence must be a separate decision.
• Scanning source, shipping images: the repository passes, but the container base image adds hundreds of OS packages whose notices and source offers were never produced.
• "We are SaaS, so copyleft does not apply": true for most GPL code, false for modified AGPL code exposed to users over a network.
• Licence drift on upgrade: an automated dependency bump moves a component to a source-available licence, and nobody re-reviews because the component was approved years ago.
• Orphaned decisions: approvals recorded in chat or email with no component version, so nobody can show which release they cover.
• Snippets and AI output outside the process: copied code never appears in a manifest and is invisible to composition analysis.

Practitioner checklist

• Adopt SPDX identifiers and expressions as the only licence vocabulary in policy, tooling and SBOMs.
• Write a licence policy keyed on licence, use case (internal, hosted, distributed) and modification, agreed with counsel.
• Generate SBOMs with licence data from built artefacts, not only from source manifests.
• Record declared and concluded licences separately and treat NOASSERTION in shipped components as an open finding.
• Run the policy check in CI in report-only mode first, then enforce in rings with an expiring exception workflow.
• Re-review licences on every version change, and alert on licence changes between versions.
• Produce notices files and copyleft source archives automatically for each release and retain them.
• Name an owner, train developers who add dependencies, and self-assess against ISO/IEC 5230.
• Require licence data in supplier SBOMs and contracts.
• Review AI models, datasets and AI-generated code for licence and provenance like any other component.

Standards and references

• ISO: ISO/IEC 5230:2020 Information technology, OpenChain Specification
• OpenChain Project: ISO/IEC 5230 Licence Compliance
• SPDX: SPDX License List
• SPDX: SPDX License Expressions (Specification 3.0.1 Annex)
• CISA: Draft 2025 Minimum Elements for a Software Bill of Materials
• Open Source Initiative: The Open Source Definition
• Apache Software Foundation: Third-Party License Policy
• Open Source Initiative: Open Source AI Definition 1.0

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · SBOM Guide · Open Source Security Guide · EU Cyber Resilience Act Guide · NIST SP 800-161 Cyber Supply Chain Risk Management Guide. This guide summarises open source licence obligations and standards and is not legal advice.