Open Source Compliance

Open source compliance: why it matters

Open source compliance means meeting the conditions of the licences under which open-source software is used, and managing the security and supply-chain risks that come with it. Almost every software product, connected device and enterprise system contains open-source components. They are free of charge but not free of obligations: licences require attribution, distribution of licence texts and, for copyleft licences, the release of source code for derivative works.

Under German copyright law, using software beyond the licence is copyright infringement, and courts have enforced open-source licence conditions for many years. Since the EU Cyber Resilience Act, open source compliance also has a cybersecurity dimension: manufacturers must exercise due diligence when integrating open-source components into products with digital elements.

For companies, failures surface at bad moments: a customer audit, a due diligence review before an exit, a warning letter from a rightholder or an exploited vulnerability in an outdated library. A structured compliance process is far cheaper than remediation under pressure. It also builds trust with customers, many of whom now ask for SBOMs and compliance statements as part of procurement, and it shortens due diligence when the company raises capital or is sold.

Licence types and their obligations

Open-source licences fall broadly into two families:

• Permissive licences (for example MIT, BSD, Apache 2.0) allow use, modification and distribution, including in proprietary products, subject mainly to attribution, inclusion of the licence text and, for some, notices of changes and patent provisions.
• Copyleft licences (for example the GPL family, LGPL, MPL, AGPL) require that derivative works distributed to others are licensed under the same terms, with source code made available. The scope of "derivative work" and the conditions triggering obligations differ: the GPL is triggered by distribution, the AGPL also by making software available over a network, and the LGPL and MPL apply a weaker, file- or library-based copyleft.

Consequences of non-compliance under German law

Under German copyright law, rights of use can be granted subject to conditions (§ 31 UrhG), and the author's exclusive rights in computer programs cover reproduction, modification and distribution (§ 69c UrhG). Many open-source licences provide that rights terminate automatically if their conditions are breached, and German courts have accepted that a user who breaches such conditions loses the licence and infringes copyright. Rightholders can then claim injunctions, information, removal and, where fault exists, damages.

Because developers retain copyright, individual contributors to open-source projects have standing to sue, and some have enforced GPL conditions in German courts. Warning letters demanding a cease-and-desist declaration and compliance are a typical first step.

Beyond copyright, open-source issues affect commercial contracts throughout the supply chain: customers increasingly require warranties that software complies with open-source licences and contains no copyleft components that would affect their own code. Breach of such warranties can lead to claims, termination and reputational damage. Public-sector buyers and large industrial customers often go further and require compliance with recognised programme standards and delivery of SBOMs in agreed formats with each release.

The Cyber Resilience Act and open source

The Cyber Resilience Act (Regulation (EU) 2024/2847, CRA) sets cybersecurity requirements for products with digital elements placed on the EU market. Its treatment of open source distinguishes between roles:

• Manufacturers that integrate open-source components into their commercial products remain fully responsible for the product's compliance. They must exercise due diligence when integrating third-party components, including free and open-source software not made available in the course of a commercial activity, so that these components do not compromise the product's cybersecurity (Article 13(5) CRA). When they identify a vulnerability in an integrated component, they must report it to the person maintaining the component and remediate it (Article 13(6)).
• Open-source software stewards — legal persons, such as foundations, that systematically support the development of free and open-source software intended for commercial activities — are subject to a light-touch regime: a documented cybersecurity policy, cooperation with market surveillance authorities and certain reporting duties (Article 24). Administrative fines do not apply to stewards.
• Non-commercial open-source development is generally outside the scope, as the CRA applies to products made available on the market in the course of a commercial activity.

The CRA's reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and the Regulation applies in full from 11 December 2027 (Article 71). Manufacturers must also draw up a software bill of materials (SBOM) as part of the technical documentation. See our insight on Cyber Resilience Act obligations.

Building an open source compliance programme

An effective programme combines policy, process and tools:

1. Policy: define approved and restricted licences, approval workflows for new components and rules for contributions to external projects.
2. Inventory: maintain an SBOM for each product and release, generated automatically through software composition analysis tools.
3. Review: check licence obligations and licence compatibility before every release, with legal review of copyleft components and unusual licences.
4. Fulfilment: deliver licence texts, attributions and source code where required, for example via a written offer or a source code portal.
5. Security: monitor vulnerabilities in components continuously, patch promptly and report in line with CRA duties.
6. Supply chain: require SBOMs, source code packages and open-source compliance warranties from suppliers and subcontractors, and verify them before release.
7. Training: train developers, product managers and procurement staff on licence basics, the approval process and escalation routes.

Industry standards for open-source compliance programmes and SBOM formats help structure these processes and make them auditable for customers and acquirers. Automating the inventory in the build pipeline ensures that the SBOM reflects what is actually shipped, rather than what developers remember.

Embedded devices, automotive and industrial products

Open source compliance is particularly demanding for products that ship software inside hardware — vehicles, machines, routers, medical devices, consumer electronics. Firmware often combines a Linux kernel and other GPL components with proprietary drivers and applications. Every shipped device is a distribution, so licence texts and source code offers must accompany the product or be accessible, for the lifetime of the obligation. Supply chains add complexity: tier-one suppliers deliver software stacks containing hundreds of components from sub-suppliers. Manufacturers should contractually require complete SBOMs, compliance warranties and source code packages from suppliers, and verify them before release. Industry initiatives in automotive and electronics have developed shared standards for this purpose.

AI models and open-source licences

AI adds new licence questions. Models are released under a variety of licences — classic open-source licences, open-weight licences with use restrictions or acceptable use policies, and licences that limit commercial use above certain user numbers. Not all models labelled "open" meet the open-source definition. Companies using or fine-tuning such models must review the licence terms for permitted uses, attribution and downstream obligations, and consider the separate questions of training data rights and AI Act obligations for general-purpose AI models released under free and open-source licences. See our insight on general-purpose AI provider duties.

Responding to a licence claim

When a rightholder alleges non-compliance — often with a warning letter demanding a cease-and-desist declaration — companies should first establish the facts: which component, which version, which products and which obligations were not met. In many cases, compliance can be restored quickly by providing licence texts, attributions or source code. The cease-and-desist declaration should be limited to the actual infringement and drafted carefully, because contractual penalties apply to future breaches. Cooperative resolution is common; community enforcement often aims at compliance rather than damages, but commercial enforcement does occur.

Contributions and outbound open source

Companies also release software as open source or contribute to external projects. They should decide which licence to use, check that they own or have the rights to all contributed code, clarify contributor licence agreements, and consider effects on patents — some licences grant patent licences to users. Employees contributing on company time act for the employer; policies should address this to avoid disputes about ownership. See our insight on technology transfer and patent licensing.

Common misconceptions

Several assumptions regularly lead companies astray. "Open source means no rules" is wrong: licences are binding conditions. "Internal use is always safe" is mostly right for the GPL, which is triggered by distribution, but not for the AGPL, and distribution to affiliates or customers' devices counts. "Dynamic linking avoids copyleft" is an oversimplification: the effect depends on the licence and the technical integration. "Our supplier is responsible" is only true contractually; towards rightholders and, under the CRA, towards authorities, the company placing the product on the market is responsible. Finally, "we can fix it later" underestimates how difficult it is to remediate deeply embedded components once products are shipped.

Governance and responsibilities

Open source compliance needs an owner. Many companies set up an Open Source Program Office or designate a cross-functional team from engineering, legal, security and procurement. Its tasks include maintaining the policy and approved-licence list, operating the scanning and SBOM tooling, deciding on exceptions, coordinating outbound contributions and reporting to management. Management should receive regular reports on compliance status and on vulnerabilities in components, because both licence breaches and security incidents can create significant liabilities and, under the CRA, regulatory exposure.

Open source in transactions

Open source compliance is a standard topic in IP due diligence. Buyers ask for SBOMs, scan results and evidence of a compliance process, and look for copyleft components in distributed products, AGPL use in SaaS offerings and outdated components with known vulnerabilities. Findings lead to remediation covenants, specific indemnities or price adjustments. See our insight on IP due diligence in transactions.

How TRW & Co helps with open source compliance

We help software companies, manufacturers of connected products and users of open-source software set up and audit open source compliance programmes: drafting policies, reviewing licence obligations and compatibility, advising on copyleft and AGPL questions, preparing for CRA obligations, negotiating open-source warranties in customer and supplier contracts, and defending against or enforcing licence claims. We work with technical partners on scanning and SBOM generation. See our pages on cybersecurity and NIS2 and IP and patents, or contact us.