Open source software is embedded in virtually every enterprise product, yet few understand the associated license risks. From the GPL copyleft effect and SBOM obligations under the EU Cyber Resilience Act to M&A due diligence, we explain what matters in OSS compliance.
The Invisible Dependency
Over 90 per cent of all modern software products contain open source components. What appears at first glance to be a cost-effective and innovative solution carries significant legal risks. Open source software (OSS) is by no means "free" in the sense of "without conditions". Every OSS component is governed by a licence that defines precise obligations -- and breaching those obligations can have severe consequences.
For companies that develop, integrate or distribute software, knowledge of and compliance with open source licences is not an optional best practice but a mandatory legal necessity. The risks range from injunctive relief claims and damages to the loss of proprietary intellectual property rights.
The Licence Landscape: From Permissive to Copyleft
Open source licences can broadly be divided into two categories, and understanding the distinction is critical for risk assessment.
Permissive Licences
Licences such as the MIT Licence or the Apache Licence 2.0 are comparatively straightforward. They permit the free use, modification and redistribution of the software -- including in proprietary products. The key obligations are limited to retaining the copyright notice and the licence text. The Apache Licence 2.0 additionally includes an express patent licence that provides users with protection against patent claims by the licensor.
Copyleft Licences: The "Viral" Effect
Copyleft licences are significantly more complex, foremost among them the GNU General Public Licence (GPL). The central feature of the GPL is the so-called copyleft effect: anyone who integrates GPL-licensed code into their own programme and distributes it must release the entire resulting work under the GPL as well -- including the complete source code.
This obligation is frequently described as a "viral effect" because the licence effectively spreads to all connected parts of the code. For companies whose business model is based on proprietary software, this can be existentially threatening: the unintentional integration of a GPL component may require the disclosure of the entire proprietary source code.
The LGPL (Lesser General Public Licence) mitigates this effect. It permits the inclusion of LGPL libraries in proprietary software, provided the library is dynamically linked and the user is able to replace it. However, pitfalls remain with static linking or modifications to the library itself.
Hellwig v. VMware: A Wake-Up Call for Industry
The importance of GPL compliance was vividly illustrated by the Hellwig v. VMware case. Christoph Hellwig, one of the most prolific Linux kernel developers, sued VMware in 2015 before the Hamburg Regional Court for violation of GPLv2.
The allegation was that VMware had integrated Linux kernel code into its ESXi hypervisor without disclosing the source code of the entire derivative work under the GPL. Although the claim was ultimately dismissed on evidentiary grounds -- Hellwig was unable to sufficiently demonstrate which specific lines of code originated from him -- the case sent shockwaves through the industry.
The central legal question, which remains unresolved to this day, concerns the concept of a derivative work under the GPL: at what point does the combination of proprietary and GPL-licensed code become a unified work that is subject to the GPL in its entirety? This uncertainty forces companies to exercise particular caution in the architecture of their software.
The EU Cyber Resilience Act and the SBOM Obligation
With Regulation (EU) 2024/2847 -- the Cyber Resilience Act (CRA), the European legislator has created a new dimension of transparency obligations. The CRA, which entered into force on 10 December 2024 and will be fully applicable from 11 December 2027, requires manufacturers of products with digital elements to create and maintain a Software Bill of Materials (SBOM).
What Is an SBOM?
An SBOM is a machine-readable inventory of all software components in a product -- comparable to an ingredients list for food products. It documents all libraries, frameworks and modules used, including their versions and licences.
NTIA defined minimum requirements for SBOMs as early as 2021, which have since been updated by CISA in a revised version from 2025.
CRA Requirements for the SBOM
The CRA requires the SBOM to:
- be created in a common, machine-readable format
- list at least the top-level dependencies of the product
- be retained as part of the technical documentation
- be made available to market surveillance authorities upon request
While the SBOM does not need to be publicly accessible, the obligation to create and maintain it enforces a systematic recording of all OSS components -- and thereby their licences.
Common Licence Types and Their Implications
A clear understanding of the most common licence types is essential for business practice:
MIT Licence
- Obligations: Retain copyright notice and licence text
- Risk: Low
- Practice: Can be used in proprietary software without problems
Apache Licence 2.0
- Obligations: Retain copyright notice, licence text and NOTICE file; express patent licence
- Risk: Low to medium
- Distinctive feature: Patent retaliation clause (loss of patent licence if patent proceedings are brought against the licensor)
GPL v2 / v3
- Obligations: Place the entire derivative work under the GPL; disclose source code
- Risk: High
- Practice: Only usable in clearly separated, independently distributed modules or as a pure back-end tool
LGPL
- Obligations: Disclose modifications to the library itself under the LGPL; dynamic linking required
- Risk: Medium
- Practice: Can be used in proprietary software if the linking requirements are met
AGPL (Affero GPL)
- Obligations: As for the GPL, but the disclosure obligation is triggered merely by making the software available over a network (SaaS)
- Risk: Very high
- Practice: Particularly critical for commercial SaaS applications
M&A Due Diligence for Open Source Software
In corporate transactions, OSS compliance is increasingly becoming a deal-breaker. Buyers must ensure that the target company is not committing licence violations that could lead to liability risks after the transaction closes.
Key Audit Areas
OSS due diligence should cover at least the following aspects:
- Inventory: Complete identification of all OSS components used and their licences
- Licence compatibility: Verification that the combination of different licences is permissible
- Copyleft contamination: Identification of GPL or AGPL components in proprietary products
- Compliance with licence terms: Are copyright notices, licence texts and, where applicable, source code correctly provided?
- Organisational compliance: Do internal processes and responsibilities for OSS management exist?
Impact on Valuation
Identified OSS risks can have a significant impact on the transaction price. In severe cases -- for example, where a core product is GPL-contaminated -- this can mean the termination of the transaction. Contractual safeguards in the form of representations, warranties and indemnities are therefore essential.
Organisational Compliance Programmes
An effective OSS compliance programme is built on several pillars:
Governance Structure
- Appointment of an Open Source Program Office (OSPO) or at least a dedicated compliance officer
- Clear policies for the use of OSS (allowlist/denylist for licence types)
- Defined approval processes before integrating new OSS components
Technical Tooling
Modern tools enable automated detection and management of OSS components:
- FOSSA: Automated licence detection, SBOM generation and policy enforcement
- Snyk Open Source: Combined security and licence compliance scanning
- Black Duck (Synopsys): Comprehensive software composition analysis with deep binary inspection
ISO/IEC 5230 -- The OpenChain Standard
The OpenChain Standard of the Linux Foundation, an international standard as ISO/IEC 5230 since 2020, defines core requirements for high-quality open source compliance programmes. OpenChain certification builds trust in the supply chain and reduces the audit burden with business partners and in due diligence processes.
Practical Recommendations
For Managing Directors and Board Members
- Raise awareness: Place OSS risks on the management agenda
- Allocate budget: Compliance tools and personnel are an investment, not an expense
- Define responsibilities: Establish clear accountability for OSS compliance
For Development Teams
- Check before integrating: Verify licence compatibility of every new OSS component before inclusion
- Document dependencies: Continuously maintain and update SBOMs
- Integrate into the build pipeline: Embed automated licence scans into the CI/CD pipeline
For Legal Departments
- Create a licence policy: Clear guidelines on which licences are acceptable under which conditions
- Contractual protection: Include licence representations in developer and supplier contracts
- Conduct training: Regularly raise awareness among all stakeholders on OSS legal issues
Conclusion
Open source software is an indispensable part of modern software development -- and rightly so. However, the associated licence risks require professional management. The EU Cyber Resilience Act with its SBOM obligation further increases the pressure to act. Companies that neglect their OSS compliance risk not only legal sanctions but also significant economic damage -- from failed M&A transactions to the forced disclosure of proprietary source code.
At compleneo, we support you with the legal assessment of your open source usage, the implementation of compliance programmes and OSS due diligence in corporate transactions. Get in touch with us.
