FOSS Compliance Vocabulary

An SBOM is a structured inventory of all software components in a product — analogous to a food ingredients label. For FOSS compliance, it answers: "what licenses are in my product?"

SBOM formats (machine-readable standards):
• SPDX (Software Package Data Exchange) — Linux Foundation standard; ISO/IEC 5962
• CycloneDX — OWASP standard, common in security tooling
• SWID (Software Identification Tags) — ISO/IEC 19770-2, common in enterprise software

What an SBOM contains:
• Package name, version, supplier
• SPDX license identifier(s)
• Copyright notices
• Download location / VCS URL
• Checksum / hash
• Dependency relationships

Regulatory context (why SBOMs matter now):
• US Executive Order 14028 (2021): requires SBOMs for software sold to the US federal government
• EU Cyber Resilience Act: SBOM requirements for products sold in the EU
• Many enterprises now require SBOMs in vendor contracts

Generating SBOMs:
• Tools: Syft, Trivy, SPDX tools, CycloneDX libraries
• Typically generated from lock files (package-lock.json, poetry.lock, go.sum, Cargo.lock)

Key vocabulary:
• SBOM (Software Bill of Materials) — a structured inventory of all software components and their licenses
• Transitive dependencies — packages that your direct dependencies depend on (often where compliance issues hide)
• SPDX license identifier — a standardised short code for a license (e.g., MIT, Apache-2.0, GPL-3.0-or-later)
• License scanning — automated analysis of dependencies to identify licenses and potential compliance issues

Distributing GPL-licensed code in a binary triggers the source disclosure obligation — the recipient must be able to obtain and build the Corresponding Source.

GPL v3 distribution obligations (§6):
1. License text: include a copy of GPL v3 with every distribution
2. Corresponding Source: provide all source needed to generate, install, run, and modify the covered work
3. Delivery options:
a. Include source alongside binary in the distribution
b. Written offer (valid ≥ 3 years) to provide source upon request for cost of media
c. For internet distribution: include source at same publicly accessible location

What "Corresponding Source" includes:
• Source code for the GPL component itself
• Build scripts, configuration files, makefiles
• Source for any scripts to control installation
• NOT: the compiler, kernel, standard libraries (these are "system libraries")

The coupling question:
• If the GPL component is the entire product or tightly coupled → entire distribution may need to be GPL
• If isolated via a separate process/API → copyleft may not propagate to the rest

Common non-compliance mistakes:
• Shipping binaries without any license text
• Making a written offer but not actually fulfilling source requests
• Providing incomplete source (missing build scripts)

Key vocabulary:
• Corresponding Source — all source code needed to build, install, and run the GPL-covered work
• Written offer — an alternative to including source: a promise to provide it for 3 years
• System library exception — GPL §1 exempts standard compilers and OS components from the source requirement
• Binary distribution — distributing compiled software to customers without source code

"Unknown license" in a scanner output means the tool couldn't match the text to a known license — it does NOT mean no license exists. It requires human review.

Common causes of "unknown license" results:
• Custom license text (not in scanner database)
• Non-standard formatting of a known license (e.g., MIT with modifications)
• License in a language other than English
• Scan of a copyright notice, not a license (scanner false positive)
• Proprietary commercial license

How to resolve unknown license flags:
1. Find the original package on npm, PyPI, GitHub, etc.
2. Read the LICENSE, COPYING, or NOTICE file in full
3. Check the package.json/pyproject.toml/setup.py for license metadata
4. Search the SPDX license list for the closest match
5. If truly novel or restrictive → escalate to legal team

License scanner tools used in practice:
• FOSSA — enterprise license compliance, integrates with CI
• Black Duck (Synopsys) — comprehensive SBOM + license risk
• REUSE tool (FSFE) — checks files for SPDX headers
• scancode-toolkit — open source, generates the LicenseRef-scancode-* identifiers
• Trivy — security-focused, also scans licenses

Key vocabulary:
• License scanner — a tool that analyses code repositories to identify licenses of all components
• LicenseRef- — SPDX prefix for licenses not in the main SPDX list; requires custom definition
• License risk — the legal and compliance risk associated with using a particular license in a product
• FOSS compliance toolchain — the set of tools used to automate license identification and compliance reporting

Apache 2.0 attribution has three requirements: copyright notice, license text, and NOTICE file contents — the license text can be shared, but copyright notices and NOTICE file contents are per-component.

Apache 2.0 §4 — Redistribution conditions (what you must include):
• §4(a): Reproduce the Apache 2.0 license text in your distribution (one copy suffices for all Apache 2.0 deps)
• §4(b): Retain all copyright, patent, trademark, and attribution notices from the Source
• §4(c): Include a copy of the NOTICE file from the original work (if the original had one)
• §4(d): Your NOTICE file can add your own attribution statements

Typical FOSS compliance notice document structure:
THIRD-PARTY SOFTWARE NOTICES
This product includes software from the following sources:
--- [Library Name] ---
Copyright (c) 2023 Author Name. All rights reserved.
Licensed under Apache License, Version 2.0.
NOTICE: [contents from the library's NOTICE file]
At the end, one full copy of the Apache 2.0 license text.

Where to surface attribution notices:
• Mobile apps: Settings → "Open Source Licenses" screen
• Desktop apps: Help → "About" → "License" screen
• Server software: LICENSE or NOTICE directory in the distribution
• Firmware: device setup/admin UI

Key vocabulary:
• Attribution notice — a copyright notice and license reference that must be included with distributions
• NOTICE file — an Apache 2.0-specific file containing attribution statements that must be reproduced
• Third-party notices — collected attribution information for all open source dependencies in a product
• FOSS compliance audit — a review to confirm all open source obligations are met before distribution

REUSE is a per-file compliance specification — it makes every file in a repository self-describing for copyright and license information, enabling complete automated compliance.

The problem REUSE solves:
• A single top-level LICENSE file says "this project is MIT" — but what about vendored files? Configuration files? Auto-generated code? Files copied from other projects?
• Without per-file notices, scanners and humans must guess what applies to each file
• REUSE makes the answer unambiguous for every file

REUSE requirements:
1. Every file must have a copyright notice: SPDX-FileCopyrightText: 2023 Name
2. Every file must have a license identifier: SPDX-License-Identifier: MIT
3. Either in the file itself (source files) or in a companion filename.ext.license file
4. All referenced licenses must appear as full text in a LICENSES/ directory

Tool: reuse lint — checks compliance; CI integration available.

Who uses REUSE:
• Many Linux Foundation and FSFE projects
• KDE, Inkscape
• Increasingly adopted in embedded/automotive (AUTOSAR, OpenChain)

OpenChain — adjacent standard:
• ISO/IEC 5230 — a standard for FOSS compliance programs
• Specifies what a mature compliance process should include
• REUSE compliance + SBOM generation are typical OpenChain-aligned practices

Key vocabulary:
• REUSE specification — an FSFE standard requiring per-file copyright and SPDX license identifiers
• SPDX-FileCopyrightText — the REUSE-specified header field for copyright notices
• SPDX-License-Identifier — the REUSE-specified header field for license information
• OpenChain (ISO/IEC 5230) — a standard defining requirements for a quality FOSS compliance program