A medium-sized application can include hundreds of open source components, many of which arrive as indirect dependencies that nobody consciously chose. Each has a license, and each license has obligations. Keeping it all in your head is impossible: you need a method. In recent years a few standard tools have become established that turn compliance into a repeatable activity rather than a pre-release emergency. The most important one is SPDX.
What SPDX is
SPDX (Software Package Data Exchange) is an open standard that originated within the Linux Foundation and is recognised as the international standard ISO/IEC 5962:2021. It has two parts worth distinguishing:
- A list of license identifiers: short, unique names such as
MIT,Apache-2.0,GPL-2.0-only,GPL-3.0-or-later,BSD-3-Clause. - A format for describing software: a document listing packages, files, licenses, copyrights and relationships between components.
License expressions
Identifiers are combined with simple operators:
MIT OR Apache-2.0 # dual license, recipient's choice
GPL-2.0-or-later WITH Classpath-exception-2.0
LGPL-2.1-only AND MIT # parts with different licenses, all apply
ORmeans the recipient can choose;ANDmeans both apply;WITHadds a recognised exception to the license.
Identifiers in files
The most useful and cheapest practice is to put a comment at the top of every source file:
// SPDX-FileCopyrightText: 2026 Author Name
// SPDX-License-Identifier: Apache-2.0
Two lines instead of a twenty-line header. Automated tools read them reliably, and anyone copying a single file into another project carries the license information along with it.
The REUSE specification
The Free Software Foundation Europe has published the REUSE specification, which formalises these practices:
- every file has its license and copyright declared, in the file itself or in an accompanying file;
- full license texts live in a
LICENSES/folder; - a command-line tool checks whether the repository is compliant.
For files that cannot contain comments, such as images or binaries, a text file alongside or a central configuration file is used.
What an SBOM is
An SBOM (Software Bill of Materials) is the complete list of components that make up a product, with versions, origin and licenses. It is the equivalent of the ingredients list on a food product.
The two most common formats are:
| Format | Origin | Typical use |
|---|---|---|
| SPDX | Linux Foundation | licensing and compliance, also security |
| CycloneDX | OWASP | security and vulnerabilities, also licensing |
An SBOM serves two main purposes. For compliance, it tells you which license obligations must be met in the distributed product. For security, it lets you find out within minutes whether a product contains a vulnerable version of a library when a new vulnerability is published.
A practical five-step process
- Declare your own license with SPDX identifiers in every file of internal code.
- Generate the SBOM automatically at every build, from the package manager's lock files and, for container images, from image analysis.
- Define a license policy: which licenses are allowed without review (for example MIT, BSD, Apache 2.0), which need approval (for example LGPL, MPL), which are excluded for that product.
- Block the pipeline when a disallowed or unknown license appears, instead of finding out after release.
- Produce notices for recipients: from the SBOM you generate the file with license texts and copyrights to ship with the product.
Frequent pitfalls
- Wrong metadata: the license field in package registries is sometimes empty, generic or wrong. Doubtful cases must be checked in the project's files.
- Copied code: snippets pasted from other projects do not appear in any lock file. Code scanning tools help find them.
- "Custom" licenses: some libraries use their own or modified texts. The standard provides identifiers with the
LicenseRef-prefix to mark them without confusing them with official ones. - System components in container images: an image includes operating system packages with their own licenses, often forgotten.
In my work an SBOM is also an investigative tool: when you need to reconstruct which version of a component was running at a given moment, a bill of materials kept for every release saves many hours.
In short
- SPDX provides unique license identifiers and a standard format for describing software.
- Two SPDX header lines in every file replace long license notes and are machine-readable.
- The REUSE specification helps make a repository fully declared and verifiable.
- An SBOM lists every component of a product and is useful for both licensing and security.
- Automating generation, checks and blocking in the pipeline turns compliance into routine.
