The Open Source Jungle: Legal Issues in the Spotlight
Articles
Compliance
Legal
Data / Technology / IP
Part 3: What needs to be considered when integrating OSS?
Noëlle Glaus
Legal Associate
Michael Kunz
Legal Partner
Philipp Stadler
Senior Legal Associate
Part 3 of this series focuses on the opportunities and risks that arise when a software user utilizes open source components or integrates them into their own code.
What is “distribution”?
“Distribution” refers to the transfer of a copy of a copyrighted work, such as software, from one legal entity to another. The principle of distribution is particularly important for companies and developers who use open source software (OSS) and integrate it into their own products, as many obligations under OSS licenses only take effect when the software is distributed to third parties.
The decisive factor here is not how the software is used, but whether a third party actually receives a copy. As long as an application is only used or further developed internally and no external third parties receive a copy, there is no distribution. In this case, the obligations arising from OSS licenses are not yet triggered. Transfer typically occurs when (i) software is delivered to customers, (ii) source code or binary files are provided, or (iii) software is made publicly available for download.
What applies to cloud and SaaS solutions?
With modern forms of delivery such as Software-as-a-Service (SaaS) or web-based applications, the concept of transfer is not always clear. The key question is: Does a transfer already occur when users interact with the software via the Internet without downloading a copy? According to prevailing doctrine and case law, the answer for most open source licenses is no. Users only receive access to the software, but not a copy, so the license obligations are not usually triggered. For example, the strict GPLv3 license defines the term “convey” as follows:
“To ‘convey’ a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.”
The Affero GPL (AGPL) is a special exception. It was developed to ensure that license obligations also apply when software is provided via a network without copies being transferred. Simply providing the software via a network is considered distribution in this case. In this case, the license terms of the AGPL must be complied with, such as the obligation to make the source code available to all users under the same conditions.
What obligations arise when the software is distributed?
If open source software is not only used internally but also distributed to third parties – for example, by delivering or making available an application with corresponding OSS components – certain license obligations apply. These vary depending on the type of license and include transparency requirements, the obligation to indicate changes, and the obligation typical of copyleft licenses to distribute the software under the same license terms (see below, section 6).
In order to be aware of these obligations, developers must know exactly which components are included in the application and under which licenses they are covered by the time the product is released at the latest. It is advisable to create a software “bill of materials” (BoM) that documents all components used, including license information (see also below, section 8). If this information is missing or incomplete, this can quickly lead to license violations and entail legal risks. Only if problematic components are identified in good time can they be replaced before release or included in the application under a suitable license.
What is behind the notice requirement?
Numerous open source licenses require that the OSS components used be indicated when software is distributed. The so-called “notice” requirement means that recipients must be informed about which parts of the software are covered by which license. In practice, this usually involves including the complete license texts, naming the authors and contributors, and, if necessary, providing the associated source code.
It has proven useful to provide the source code covered by the license before distribution, as the license texts are usually included as text files in the source code package. However, it is controversial whether simply embedding the license text files in the source code package is sufficient to meet the (sometimes) strict transparency requirements of open source licenses. For this reason, it is advisable to include an additional text file with the source code package or the corresponding repository that clearly describes under which license the entire application is published or distributed and under which license the individual components are licensed.
License violation or no license?
When dealing with open source software, a distinction must be made between use without a valid license and a violation of existing license terms.
If there is no valid license or other permission to use the software, for example because third-party code has been adopted without license information and no other consent has been obtained from the copyright holder, this constitutes a copyright infringement. In this case, use is not permitted; the only options are to obtain a license from the copyright holder retrospectively or to remove the code in question completely.
If, on the other hand, there is a valid license but its terms have not been complied with or have not been complied with in full (e.g., missing copyright notices or failure to disclose information), this constitutes a license violation. Depending on the license, such a violation may result in the automatic loss of the right of use, meaning that any further use constitutes a copyright infringement. If the respective license and applicable law so provide, the infringement can be remedied by subsequent fulfillment of the license obligations and the license can be restored for the future. Otherwise, termination of use by removing or replacing the affected code is necessary.
What is the “viral effect”?
The so-called “viral effect” is often discussed in connection with copyleft licenses, especially the GPL. It describes the widespread notion that the integration of copyleft code into proprietary software could automatically result in one's own code falling under the copyleft license and, as a consequence, the entire code having to be disclosed – including one's own. From a legal perspective, however, this notion is incorrect.
Copyleft licenses such as the GPL stipulate that when a combined work containing GPL-licensed code is redistributed and forms a uniform “derivative work,” the entire distributed code must be subject to the terms of the GPL. Anyone who violates this condition by distributing the combined work without disclosing the complete source code under the GPL loses the license rights to the GPL code. Further distribution then constitutes a copyright infringement, which may result in injunctive relief and, if applicable, claims for damages.
However, copyright law does not provide any legal remedies that could force developers to actively place their proprietary code under the GPL or transfer it to the public domain. The integration of GPL code does not automatically “infect” proprietary code and does not convert it into GPL code by operation of law. The viral effect acts exclusively as a condition for lawful redistribution: Anyone who wishes to distribute a combined or derivative work must decide either to comply with the GPL conditions or to refrain from distribution.
What are license conflicts?
License conflicts arise when code bases under different licenses are merged into a new project and the terms of the licenses are incompatible with each other. For example, combining a strict copyleft license with a permissive license is fundamentally problematic if the intention is to distribute the combined (or derivative) work under a permissive license. License conflicts can also arise when certain terms of use of one license contradict the terms of another license, for example with regard to permitted use, distribution, or patent rights.
The latest Open Source Security and Risk Analysis (OSSRA 2025) study by Black Duck shows that license conflicts are still widespread: license conflicts were found in 56% of the applications examined, and in 33% of cases, components without a clear license or with an adapted license are included, which exacerbates legal uncertainties. Those responsible for open source projects, users of such software, and developers should therefore carefully review the license terms of all components used and ensure that they are compatible with each other before combining or redistributing code.
Why is the compatibility of OSS licenses important?
Modern software projects often combine different open-source components, each of which is subject to its own license terms. The compatibility of these licenses is particularly relevant with regard to copyleft mechanisms such as the GPL, which stipulate that derivative works must be distributed under the same license. Compatibility issues can restrict the use or distribution of software and, in practice, can usually only be resolved through alternative licensing or the replacement of individual components.
A proven method of minimizing risk is to create a software “bill of materials” (BoM) that documents all components used, including license information. The BoM serves as the basis for internal compliance audits and is increasingly required by customers, investors, or buyers in order to understand the legal status of the software. The economic valuation and saleability of a software solution depend largely on whether its licensing situation is transparent and legally sound. A lack of transparency or unresolved license conflicts can reduce the value of the software or the company, or delay transactions, especially if the relevant risks only become apparent during due diligence reviews.
What needs to be considered with regard to patents?
In addition to copyright, open source software can also raise questions about patents. Some licenses, such as Apache 2.0 or GPLv3, explicitly include a patent license that allows the use of protected technologies within the software and prevents rights holders from asserting patent claims against users after the code has been distributed. Other licenses, such as BSD, MIT, or GPLv2, do not make any clear statements on this issue. Some courts take the view that the use of OSS source code grants an implicit patent license, but this has not been clarified uniformly in law. In principle, therefore, licenses without an explicit patent clause leave a certain degree of uncertainty regarding possible patent claims by the rights holder against users.
