Automotive OEM FOSS policy & requirementsCopy Anchor Link

A car is the least convenient artefact in the world to ship open source in: locked-down hardware, a fifteen-year support tail, a supply chain four tiers deep, and a safety and type-approval regime that treats every software change as a regulated event. This is how OEMs write the policy, and what they push down to suppliers.

Not legal advice. Licence obligations are contracts, and type-approval, product-safety and cybersecurity duties are statutory. This page describes how the two interact and what a workable programme looks like — confirm scope, dates and wording with counsel for your products and markets.

Why vehicles are the hard caseCopy Anchor Link

Almost everything that makes consumer-electronics FOSS compliance routine is absent in a vehicle:

• Distribution never ends. A handset is distributed once. A car is distributed at sale and then again at every over-the-air update — for a decade or more. Every update is a fresh triggering of copyleft source obligations for the code in that image.
• The chain is deep and uneven. A head unit contains a Tier 1's integration layer, a Tier 2's middleware, three silicon vendors' BSPs, an OS distribution and a few thousand upstream packages. The OEM's contract is with the Tier 1; the risk sits four levels down.
• The hardware is deliberately sealed. Secure boot, signed images and locked debuggers are what regulators and safety cases demand — and exactly what GPLv3's anti-tivoization terms and "Installation Information" requirement bite on.
• Safety cases assume a known artefact. ISO 26262 wants you to know what each software element is, where it came from and how it was validated. Unidentified copyleft code in a QM or ASIL partition is an audit finding, not just a legal one.
• The remedy hurts more. In consumer electronics the worst realistic outcome is an injunction on a product line. In automotive, licence termination touches a type-approved product in the field, with recall and stop-delivery exposure.
• Copyleft reaches the crown jewels. The differentiating code — ADAS stacks, perception models, infotainment UX — lives in the same image as GPL-licensed components. Linking mistakes there disclose proprietary algorithms, not just build scripts.

The rulebook an OEM policy has to satisfyCopy Anchor Link

None of the vehicle regulations say "open source". All of them require you to know what is in the car, which is why FOSS compliance in this sector is a cybersecurity and homologation topic as much as a licensing one.

Timeline:

Anatomy of an OEM FOSS policyCopy Anchor Link

Published OEM policies differ in length, but the ones that survive audit contain the same nine blocks. If you are writing one, these are the headings:

1. Scope and definitions. What counts as open source for this policy: not only libraries, but build scripts, kernel and BSP patches, fonts, icon sets, ML models and weights, datasets, and code pasted from forums. Say explicitly that "no licence found" means "not approved".
2. Governance and named roles. An OSPO or FOSS compliance office, a review board with authority to say no, a named contact per programme, and — required by both OpenChain standards — a published external contact point for licence and security enquiries. Escalation path to legal and to the safety organisation when OSS appears in an ASIL partition.
3. Licence policy. The allow / conditional / deny matrix below, plus the isolation rules that make copyleft acceptable (separate process, dynamic linking only, no static linking into proprietary modules, no modification of copyleft components without a source-return plan).
4. Intake and approval. A request path developers can actually follow: declare the component, version and intended use → automated scan → triage → board decision → decision recorded against the part number or repository. Approval attaches to a use, not to a package.
5. Build and release controls. SBOM generated per build, licence texts and notices collected, source archive and written offer produced for copyleft components, and a release gate that fails the build when an unapproved licence appears.
6. Supplier requirements and flow-down. See the next section. The contract is the only instrument that reaches Tier 2 and Tier 3.
7. Security and maintenance. Continuous vulnerability monitoring, VEX publication, an upstream-abandonment trigger (no maintainer response, no release in N months, repo archived), an internal patch SLA, and a duty to feed fixes upstream.
8. Records and retention. Keep the inventory, approvals, notices and source archives for the support period plus the statutory tail — for vehicles, plan in decades. Auditors under R155 will ask for historical evidence, not just the current build.
9. Training and consequence management. Role-based training for developers, architects and purchasers; documented consequences for bypassing the gate; periodic internal audit and, ideally, external conformance assessment.

Policy length is not the variable that matters. A two-page policy that is enforced in CI beats a thirty-page policy nobody reads. The test an auditor applies is: can you produce, for any shipped build, the list of components, their licences, the approvals, and the source you owe?

Licence decision matrixCopy Anchor Link

The matrix is the part suppliers actually read. It converts a legal judgement into a build-time rule. Shapes vary by OEM; the pattern below is typical.

What OEMs require from suppliersCopy Anchor Link

The OEM writes policy; the Tier 1 and Tier 2 deliver evidence. Modern sourcing documents treat open source governance as a qualification criterion — Taylor Wessing's 2026 read on the sector is blunt: non-compliance leads to exclusion from tenders, contractual penalties and, in due diligence, price reductions or indemnities.

For the other side of the table — what a supplier has to build in order to answer these — see OEM & supplier playbook.

At quotationCopy Anchor Link

• State your open source governance: policy, tooling, roles, and whether you hold OpenChain ISO/IEC 5230 conformance (licence compliance) and/or ISO/IEC 18974 (security assurance).
• Name a contact point for licence and vulnerability matters, reachable for the life of the product.
• Declare any copyleft component you intend to use, and your isolation approach.

At each delivery milestoneCopy Anchor Link

• OSS inventory / SBOM for the delivered software, in a named format and spec version — e.g. CycloneDX 1.7 or SPDX 3.0.1 — with supplier name, component name, version, other unique identifiers (purl), dependency relationships, author and timestamp. See the NTIA element mapping.
• Licence texts for every component, in full, plus any NOTICE content and attribution strings as they will appear in the product.
• Source package for every copyleft component: the exact sources used, build scripts, configuration and any modifications — or a written offer valid for the support period.
• Changes since the last delivery: added, removed and version-bumped components, not just a fresh full dump.
• Security status: known vulnerabilities affecting the delivered versions, with a VEX statement distinguishing "contains a vulnerable library" from "is exploitable". See CycloneDX VEX.

Standing obligationsCopy Anchor Link

• No open source component outside the approved list without prior written approval — request, justification, decision, record.
• No AGPL, no SSPL/BUSL-style source-available licences, no unlicensed code; GPLv3 only where the installation-information question has been resolved.
• Flow the same obligations down to your own sub-suppliers, and evidence it on request.
• Maintain and patch for the agreed support period; notify the OEM when upstream goes unmaintained.
• Audit rights: the OEM (or its assessor) may audit the compliance programme, typically annually and on reasonable notice.
• Indemnity and remedy for licence breaches, including the cost of remediation in the field; records retained for the statutory tail.

Illustrative clause — not a template:

# 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 ensure recipients can obtain all licence texts, copyright notices
   and attribution required by the applicable licences, in the form specified by OEM.

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

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

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

OpenChain and the SBOM plumbingCopy Anchor Link

Automotive was one of the first industries to converge on a single answer to "how do I know my supplier's programme is real?" — the OpenChain Project standards, both ISO/IEC standards maintained by a Linux Foundation project:

• Licence compliance: ISO/IEC 5230:2020
• Security assurance: ISO/IEC 18974:2023
• Automotive Work Group: chaired by Toyota
• Adoption: 1,000+ companies in the wider OpenChain community

ISO/IEC 5230:2020 specifies what a quality open source licence compliance programme must contain: defined processes, assigned responsibilities, and sustainability — including a published external contact point. ISO/IEC 18974:2023 (OpenChain Security Assurance Specification 1.1) does the same for security: knowing what you ship, tracking vulnerabilities, and responding. Neither mandates a tool; both are self-certified against a free checklist, which is why scope matters — ask whether conformance covers one project, one product or the whole legal entity.

The OpenChain Automotive Work Group, chaired by Masato Endo of Toyota, is where OEMs and Tier 1s compare practice; it held a face-to-face workshop at Bosch in Stuttgart on 10 September 2024. Toyota announced adoption of ISO/IEC 5230 in December 2020. Companies that have publicly declared ISO/IEC 5230 conformance include Toyota, Woven by Toyota, Honda, Hyundai, KIA, Hyundai Mobis, Hyundai AutoEver, Volvo Cars, Scania, Mercedes-Benz R&D India, Bosch, ZF, Aptiv, Visteon, Panasonic Automotive Systems, HARMAN, Elektrobit, dSpace, AVL, IAV, Hella Aglaia, Telechips, NXP, Qualcomm, BlackBerry, TomTom, 42dot, ECARX, SAIC Z-One, LG Electronics and Samsung Electronics; Honda and LG also appear on the ISO/IEC 18974 list. Absence from the list means silence, not non-compliance — many programmes are simply never announced.

Underneath the process sits the SBOM. Automotive programmes typically standardise on one format and pin the spec version in the contract: CycloneDX 1.7 (ECMA-424 2nd edition) is common where VEX and CBOM matter; SPDX 3.0.1 where licence expressiveness does. Generate it in CI, per build, and keep it under change control — see Tooling for the pipeline and Compliance for what regulators ask for.

Enforcement realityCopy Anchor Link

Three datapoints explain why automotive compliance budgets exist:

• Tesla. The Software Freedom Conservancy has documented repeated gaps: an incomplete "complete corresponding source" publication in 2018, and, in a December 2023 review of the Roadster service material, Linux kernel binaries with no source and no written offer at all. Tesla does publish some GPL code, but the pattern shows how easy it is to regress.
• GPLv3 and locked hardware. In Software Freedom Conservancy v. Vizio, a California court held on 23 December 2025 that GPLv2 and LGPLv2.1 do not require a distributor to enable reinstallation of modified code on the device — only to provide source. The court expressly contrasted GPLv3 and LGPLv3, which do require "Installation Information" for User Products. The separate question — whether an end customer can enforce the licence as a third-party beneficiary — was still unresolved when the case was listed for trial in January 2026. For an OEM the lesson is narrow but sharp: GPLv2 gives you an out on sealed hardware, GPLv3 does not.
• Copyleft as disclosure risk. The most expensive automotive failure is not a lawsuit; it is a linking decision that obliges you to publish a perception or ADAS stack, or a licence termination that removes your right to ship an ECU already in production. Rights holders can seek injunctive relief — in the limit, stop-delivery or recall.

On the positive side, publishing is now normal: Volvo Cars, for example, publishes open source licence lists per vehicle model and exposes the infotainment component list in the car's own settings menu. Attribution pages and in-vehicle notice screens are the visible half of a working programme.

Shared platforms you will meetCopy Anchor Link

Much automotive open source is consumed through a collective project rather than fetched directly from upstream:

• Automotive Grade Linux (Linux Foundation) — IVI-focused stack built on Linux and the Yocto ecosystem; Japanese OEMs are prominent members. Its current push is AGL SoDeV, a reference platform for software-defined vehicles showcased through 2026.
• Eclipse SDV & S-CORE (Eclipse Foundation) — S-CORE, the Safety Open Vehicle Core, was announced in June 2025 with BMW, Mercedes-Benz, Bosch, ETAS, QNX, Qorix and Accenture, targeting non-differentiating vehicle middleware.
• VDA open source initiative — eleven European OEMs and suppliers signed a Memorandum of Understanding on 24 June 2025 to build a certifiable open stack under the Eclipse umbrella: full stack in 2026, series vehicle by 2030.
• COVESA, Android Automotive, AUTOSAR — each arrives with its own licence mix and contribution rules.

The compliance insight is that joining one of these moves the work upstream: the project handles inbound licensing and publishes its own notices, but your obligations — copyleft source, notices in the product, vulnerability response — start where the project's end.

Failure modes worth designing againstCopy Anchor Link

• Inventory at design time, not release time. An SBOM produced the week before SOP is a document, not a control. Generate per build and gate on it.
• Snippets and patches ignored. Scanners miss vendored code, copied functions and BSP patch directories — exactly where copyleft enters ECU firmware.
• Approval without use-context. The same library is fine in a test tool and unacceptable statically linked into an ASIL-B module. Record the use, not just the package.
• OTA treated as maintenance. An update is a distribution. Licence notices and source offers have to ship with it, and RXSWIN-tracked software has to match what was approved.
• Tier 2 assumed to be covered. Flow-down is a clause, not a belief. Ask for the sub-supplier's inventory.
• No abandonment trigger. An unmaintained library in a product with a fifteen-year support tail is a scheduled incident.
• Security and licensing run separately. R155 expects one supply-chain story; two disconnected tools produce two answers to the same question.
• Records deleted with the project. Audit evidence has to outlive the programme team by years.

Compiled September 2026 from the OpenChain Project, UNECE R155/R156 texts, Regulation (EU) 2019/2144 and 2024/2847, Eclipse Foundation announcements, Software Freedom Conservancy publications and OEM-published materials. Regulatory and litigation facts are dated — verify before relying on them. Nothing here is legal advice.