The strategic relevance of open source in the digital value chain
The integration of open source software (OSS) is no longer an optional scenario in modern software and product development. From operating systems to cloud infrastructures and frameworks for artificial intelligence to specialised libraries, OSS is the engine of digital transformation, enabling companies to shorten development cycles and reduce innovation costs in many ways.
However, the use of OSS is by no means a legal vacuum. Open source licences are legally binding conditions. Failure to comply with these terms not only poses a legal risk, but can also jeopardise the economic integrity of entire product lines and a company's IP strategy in the long term.
Copyright classification and regulatory differentiation
Open source licences are legally classified as licence agreements through which the rights holder grants the user certain rights of use under clearly defined conditions.
Courts have repeatedly ruled that violations of these licences can lead to the termination of the rights of use, which makes any further use of the software a copyright infringement.
The various open source licences differ considerably in the scope of their conditions. In consulting practice, the common licence models can be divided into three main categories:
Permissive licences (e.g. MIT, BSD, Apache 2.0)
These licences are characterised by a high degree of flexibility. They allow the use, modification and distribution of the software in proprietary products with minimal restrictions. The main obligation is usually to retain the original copyright notices and licence text and make them available to the end user.
Strong copyleft licences (e.g. GPLv2, GPLv3)
Licences that implement the copyleft principle aim to permanently secure the continued use of all future modifications to the software. The core of the regulation is that when modifications to the software are distributed, they must be published under the same licence.
This is where the risk of what is often referred to as contamination of one's own code lies: if one's own (proprietary) code is linked to copyleft code, this can result in the entire software package falling under the copyleft licence and thus the source code having to be disclosed to third parties. For companies whose business model is based on the protection of proprietary algorithms, this can threaten their very existence.
Other (weaker) copyleft licences (e.g. LGPL, MPL)
These licences, which are often used for libraries, for example, represent a compromise. They generally limit the copyleft effect to the respective library/file itself.
Linking with proprietary modules is possible in compliance with certain technical specifications without the entire application being subject to the copyleft effect, although the boundaries between ‘linking’ and ‘editing’ can become blurred.
Risk profiles and liability scenarios in the event of non-compliance
Failure to comply with open source licence terms is not a purely academic problem, but results in concrete, measurable legal and economic risks. Essentially, four critical risk factors can be identified:
Consequences under intellectual property law
Since licences usually grant rights of use to OSS on condition that the licence obligations are complied with, violations can lead to the automatic revocation of the licence.
In case of non-compliance, rights holders can assert claims to cease and desist from further use of the software, which in the past has already resulted in the suspension of sales or the recall of hardware products that had already been delivered (e.g. IoT devices with embedded software).
Economic implications and IP integrity
The aforementioned risk of contamination of proprietary code by copyleft effects can undermine the core value of a software company. If a company is required to disclose the source code of its proprietary algorithms due to a licence violation, this can have a significant impact on its competitive position and the exclusivity of its intellectual property.
Transaction security in M&A processes
Open source compliance checks are becoming increasingly important in due diligence for mergers and acquisitions as well as in financing rounds. Unresolved licence issues regularly lead to significant purchase price reductions, indemnities or, in the worst case, the termination of the transaction, as the acquirer cannot calculate the risk of an infected code base.
Supply chain governance
In industries with a high degree of division of labour (automotive; mechanical and plant engineering), open source compliance has evolved from a purely internal risk assessment to a central quality assurance metric within the supply chain. Large OEMs and system integrators are now increasingly demanding from their suppliers comprehensive proof of legally compliant software governance.
Within this framework, suppliers must document in detail how they identify and license OSS and generate the corresponding compliance artefacts. Failure to meet these requirements can lead directly to exclusion from tendering procedures or to severe contractual penalties. Open source compliance is thus becoming an essential prerequisite for marketability as a qualified supplier.
Open source corporate governance
The complexity of modern software ecosystems makes it clear that selective legal reviews or ad hoc decisions by individual development teams are no longer sufficient to ensure the integrity of corporate assets. What is needed instead is holistic open source corporate governance that views the management of third-party software as an integral part of the compliance organisation.
The open source policy
The foundation of any governance is a binding internal guideline (open source policy). This serves not only as a set of prohibitions, but as a strategic guide. It defines clear decision-making criteria for the use of OSS and creates legal certainty for the actors involved.
Interdisciplinary responsibility
Since open source compliance is an interface task, legal, software development (engineering), procurement and sales must work together in a coordinated process. The goal is a ‘compliance by design’ approach, in which legal requirements are already taken into account in the software architecture process and in the development and marketing processes.
Processual safeguarding and inventory
An essential aspect of governance is the creation of transparency across the entire software supply chain. The automated creation of a Software Bill of Materials (SBOM) plays a central role here. his enables the company to be able to provide accurate information to customers, regulatory authorities or potential investors at any time.
Conclusion and strategic recommendations for action
Open source compliance is not purely a technical or legal task, but an integral part of risk management. Our recommendations for action are therefore as follows:
- Conduct an audit of your critical software products (baseline check).
- Establish an interdisciplinary governance structure (legal & tech).
- Implement SBOM processes.
- Raise awareness and train your development teams regularly.
Taylor Wessing supports clients at this interface with combined expertise in IT law, IP strategy and technical understanding to make innovations legally compliant and sustainable.
