OSS License Compliance

What Is OSS License Compliance?

OSS license compliance is the practice of meeting the legal obligations that attach to every open-source component an organisation ships. Those obligations come from each component's licence, not from its security posture. They are triggered by distribution, which makes them a property of the artifact you hand over rather than the environment you built it in.

Every open-source licence grants permission to use code in exchange for conditions. Permissive terms ask for little beyond preserving copyright and licence notices. Copyleft terms ask for more, typically that source is made available to whoever receives the binary.

A licence review therefore answers a different question from a vulnerability scan. The scan asks whether a component is dangerous. The review asks what you owe because you shipped it.

How OSS License Compliance Works

Licences are commonly grouped into families that differ in what they ask of the distributor:

• Permissive terms — MIT, BSD and Apache-style licences. Carry the copyright notice and licence text with the distribution.
• Weak copyleft — LGPL and MPL-style licences. Modifications to the component must be made available; the surrounding application is generally left alone.
• Strong copyleft — GPL-style licences. Source availability can extend to the larger work, depending on how the two are combined.
• Network copyleft — AGPL-style licences. Offering the software over a network can trigger a source obligation that internal hosting would not.

These families are a way to reason about risk, not a legal taxonomy. What a licence requires depends on its exact text, on how the component is linked or modified, and on how the result is delivered. Interpretation belongs to counsel, and nothing here is legal advice.

Obligations also stack. One component can carry several licences at once — a dual-licensed library, a differently licensed test directory — so the unit of review is the file.

Why a Container Image Is the Hard Case

A container image is a distribution unit. It carries an operating-system layer, language runtimes, the application and every library the build resolved — routinely hundreds of components, most arriving as a transitive dependency.

Four properties make an image harder to review than its repository:

• Scale — the component count in a finished image dwarfs any manifest's dependency list.
• Several licences per component — declared metadata often disagrees with the licence headers in the files shipped.
• Build is not distribution — compilers, linters and test fixtures stay behind; what survives into the final layers is what you hand over.
• Delivery model — hosted software keeps the binary on your own infrastructure; an on-premises installation or an appliance hands it over, which is the act most obligations key on.

An SBOM is the inventory that review runs on. SPDX was designed with licence identification as a first-class field, so one document serves both the vulnerability workflow and the licence workflow: security and legal review share an artifact.

The inventory does not settle the obligation. It records what is present and what each component declares; it cannot say whether a condition applies.

How to Manage Licence Obligations in Production Environments

Treat licence review as a build output, not a pre-release scramble.

• Generate an SBOM during the build and keep it with the artifact, so the inventory matches what shipped.
• Review the final image, not the build context, since only what ships carries an obligation.
• Record decisions per component and reuse them, so the same library is not re-examined every release.
• Produce the notice file mechanically from the SBOM, and treat a missing or ambiguous declaration as a blocking defect.
• Escalate anything unclear — dual licences, modified copyleft code, undeclared files — to counsel.

How Hardened Container Images Support Licence Review

Hardened minimal images shrink the problem before review begins. Removing shells, package managers and build tooling removes components, and a component never shipped is one less licence to account for.

Provenance matters as much as size. Echo images are built in controlled build infrastructure, signed and attested, and delivered with SBOM, provenance and VEX (echo.ai/product), so the inventory a reviewer needs arrives with the image rather than being reconstructed later.

That supplies evidence, not a determination. The legal reading stays with counsel, where it belongs.

FAQs

Is licence compliance the same as vulnerability management?

No. They run on the same inventory but answer different questions. Vulnerability management asks whether a component is exploitable and whether a fix exists. Licence review asks what conditions attach to distributing it. A component can be entirely free of known flaws and still create an obligation you have not met.

Does shipping hosted software avoid open-source obligations?

Not entirely. Most conditions are triggered by distributing a binary, which hosted software does not do, so permissive and ordinary copyleft terms often stay quiet. Network copyleft licences are written specifically to cover that case. What hosting changes is which obligations apply to you, not whether any of them apply at all.

What is a notice file?

It is the document shipped alongside software that reproduces the copyright statements and licence texts of the components inside it. Permissive licences generally require little more than this. Generating it from an SBOM keeps it aligned with what actually shipped, rather than with a dependency list someone maintained by hand two releases ago.

Can an SBOM prove compliance?

No. An SBOM is evidence, not a conclusion. It records which components are present and what each one declares, which is the input a review needs. Whether a condition has been triggered, and whether your response satisfies it, is a legal judgement the document cannot make for you. It narrows the work rather than replacing it.

Who should make licence decisions?

Counsel. Engineering supplies the inventory, the delivery model and an accurate account of how components are combined; legal decides what those facts require. Teams get into trouble when an engineering view of a licence family substitutes for a reading of the text against the way the software actually ships. Ask early, while the architecture is movable.