OEM & supplier FOSS complianceCopy Anchor Link

How a compliance obligation that sits with the manufacturer is actually discharged by a supply chain that is four tiers deep. The OEM writes the policy and carries the regulatory duty; the Tier 1, Tier 2 and silicon vendors own the facts. Everything in a working programme follows from closing that gap.

Not legal advice. Licence obligations are contracts; type-approval, product-safety and cybersecurity duties are statutory. This page describes how programmes are structured in practice — confirm scope, dates and contract wording with counsel for your products and markets.

This page covers layers 3–5 of the compliance assurance framework in depth: control, supply-chain assurance and sustainment, seen from both sides of the OEM/supplier boundary.

The asymmetry that drives everythingCopy Anchor Link

FOSS compliance across a corporate boundary is not a legal-review problem. It is a data contract problem.

The OEM holds:

• The statutory duty — type approval, homologation, product safety, and the obligation to publish notices and source for what it ships.
• The commercial consequence — recall, stop-delivery, injunction, brand damage.
• The regulatory exposure — under UN R155 §5.1.1(a), a duty to collect and verify information through the supply chain.
• Almost none of the underlying facts.

The supplier holds:

• The actual bill of materials for the delivered image.
• The patches, build scripts, configuration and vendored code.
• The sub-supplier relationships — where the real risk usually sits.
• Almost none of the statutory duty.

The OEM's contract is with the Tier 1. The risk sits three or four levels down. The contract is the only instrument that reaches Tier 2 and Tier 3 — which is why flow-down is written as a clause with an evidence duty, never assumed.

The deliverable that crosses the boundaryCopy Anchor Link

Four artefacts, defined precisely enough to be accepted or rejected at a milestone gate. "An SBOM" is not a specification; a format plus a spec version plus a completeness assertion is.

Two properties matter more than the contents: the SBOM must be regenerated per build and kept under change control, and it must be attributable — who produced it, with which tool, when.

The four gatesCopy Anchor Link

Compliance fails when it is an end-of-project document exercise. It holds when it is four gates, each emitting an artefact the OEM can audit years later.

The last gate is the one most programmes miss. An over-the-air update is a distribution, not maintenance — under UN R156 each campaign re-triggers copyleft source obligations for the code in that image.

What the OEM has to put in placeCopy Anchor Link

1. A policy with the nine blocks. Scope (fonts, ML weights, datasets and forum snippets count; "no licence found" means "not approved"), named roles and a published external contact point, the licence matrix, an intake and approval path, build-and-release controls, supplier flow-down, security and maintenance, records retention, and training with consequences. See Automotive OEM FOSS.
2. A licence matrix that compiles into a build rule — not a PDF. Allow / conditional / deny has to be machine-checkable at merge time.
3. Qualification criteria at sourcing. OpenChain ISO/IEC 5230 (licence compliance) and ISO/IEC 18974 (security assurance), with the scope question asked explicitly: does conformance cover one project, one product, or the whole legal entity?
4. Acceptance criteria, written down. Reject anything missing the seven NTIA elements, with NOASSERTION or empty licence fields, without purls, or without a serial number tying it to a build.
5. Continuous verification. Run your own scan on the delivered image and reconcile it against the supplier's SBOM. The delta between the two is where vendored code, copied snippets and BSP patch directories hide.

What the supplier has to buildCopy Anchor Link

The mirror image, and it is a build-system problem more than a legal one:

1. Intake and approval. Declare component, version and intended use → automated scan → triage → board decision → decision recorded against the part number or repository.
2. SBOM generation in CI, per build, with the spec version pinned by the contract.
3. A licence-text and notice collector that produces the attribution set exactly as it will ship.
4. A source archive or written-offer generator for every copyleft component, valid for the support period.
5. Vulnerability monitoring with VEX, an upstream-abandonment trigger, and an internal patch SLA.
6. Flow-down to your own sub-suppliers — with evidence, on request — plus records that outlive the programme team.

Approval attaches to a use, not to a package. The same library is fine in a test tool and unacceptable statically linked into an ASIL-B module. Record the use.

Where the deliverables liveCopy Anchor Link

Put them in the Cybersecurity Interface Agreement (CIA) required by ISO/SAE 21434 for distributed development. That document already governs who does what across the boundary; adding inventory, licence list, vulnerability contact and patch ownership to it is cheaper than maintaining a parallel annex nobody reads. Keep the detailed schedule — formats, windows, retention — as a contractual annex referenced from the CIA.

The licence matrix, supplier-facingCopy Anchor Link

The full matrix is on the automotive page. Condensed to what a supplier has to do:

How the OEM verifies what it is givenCopy Anchor Link

Acceptance is a checklist, applied mechanically:

• Seven NTIA elements present and non-empty for every component, not just the top-level one.
• Explicit spec version in the document header.
• purl or equivalent unique identifier per component.
• Dependency relationships present, so transitive risk is visible.
• Serial number and timestamp tying the SBOM to one shipped artefact.
• A completeness assertion naming what is deliberately out of scope.
• A delta against the previous delivery, reviewed rather than filed.
• An independent rescan of the delivered image, reconciled against the delivered SBOM.
• A signature or attestation if the SBOM leaves the organisation, plus a TLP marking.

The test that decides whether any of it worksCopy Anchor Link

An auditor under R155 will ask one question:

For any shipped build, can you produce the list of components, their licences, the approvals, and the source you owe?

If the answer depends on someone still being employed, the programme fails. Everything above is scaffolding for that one sentence.

Failure modes at the interfaceCopy Anchor Link

• SBOM the week before SOP. A document, not a control. Generate per build and gate on it.
• Scanners missing vendored code and BSP patch directories — exactly where copyleft enters firmware.
• Flow-down assumed, not contracted. Ask for the sub-supplier's inventory.
• Approval recorded against a package, not a use.
• No upstream-abandonment trigger. An unmaintained library in a fifteen-year support tail is a scheduled incident.
• Licensing and security in two disconnected tools. R155 expects one supply-chain story.
• OTA treated as maintenance. Notices and source have to ship with the update.
• Records deleted when the project closes. Audit evidence has to outlive the programme team.

Contract schedule — illustrativeCopy Anchor Link

# Schedule — Open Source Software (illustrative)

1. Supplier shall maintain a complete and accurate inventory of all Open Source
   Software ("OSS") incorporated in, linked to, or distributed with the Deliverables,
   and shall deliver that inventory as an SBOM in [CycloneDX 1.7 / SPDX 3.0.1]
   at each milestone and at each release, including transitive dependencies.

2. Supplier shall not incorporate OSS licensed other than under a licence listed in
   Annex A without the OEM's prior written approval. AGPL-3.0, SSPL, BUSL and any
   licence not approved by the Open Source Initiative are prohibited.

3. For each copyleft component, Supplier shall deliver complete corresponding source
   code, build scripts, configuration and all modifications, or a written offer valid
   for [15] years, in a form usable by a recipient of the vehicle.

4. Supplier shall deliver, at each milestone, a delta of components added, removed or
   version-bumped since the previous delivery.

5. Supplier shall ensure recipients can obtain all licence texts, copyright notices
   and attribution required by the applicable licences, in the form specified by OEM,
   including with every over-the-air update.

6. Supplier shall flow down requirements 1–5 to its sub-suppliers and shall evidence
   such flow-down on request.

7. Supplier shall monitor for vulnerabilities in delivered components and provide a
   VEX statement and remediation within [N] days of a critical disclosure.

8. Supplier shall maintain an open source compliance programme conformant with
   ISO/IEC 5230 and shall permit OEM or its assessor to audit it annually.

Companion to Automotive OEM FOSS. Compiled September 2026 from UNECE R155/R156 texts, ISO/SAE 21434, the OpenChain Project standards and published OEM sourcing practice. Regulatory facts are dated — verify before relying on them. Nothing here is legal advice.