Cracking the Code: Legal Issues in Open Source – Part IV
Articles
Compliance
Legal
Data / Technology / IP
Part 4 of this series focuses on selected practical issues that arise in the development, de-ployment, and transfer of software.
Noëlle Glaus
Legal Associate
Michael Kunz
Legal Partner
Philipp Stadler
Senior Legal Associate
1. How does static or dynamic linking affect licensing obligations?
Software is often linked to external libraries. With static linking, the library’s code is incorporated into the executable file during compilation. With dynamic linking, the library remains separate and is loaded only at runtime.
This distinction can be relevant from a licensing perspective, particularly in the case of copyleft licenses. It raises the question of whether the library and the main program are so closely linked that the licensing obligations also extend to the main program. However, the type of linking alone is not decisive.
This is illustrated by a comparison of the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL). According to the Free Software Foundation, both static and dynamic linking under the GPL result in the linked program being subject to the GPL’s copyleft obligations. By contrast, the LGPL generally also permits linking with proprietary software. Dynamic linking is usually simpler in this context, whereas static linking may entail additional obligations, particularly the obligation to enable relinking with a modified version of the LGPL library.
Accordingly, the specific license, its version, and the manner in which the library is technically integrated are always decisive.
2. What is the effect of the Classpath Exception?
The Classpath Exception supplements the GPL. It limits the GPL’s copyleft effect when a GPL-licensed library is linked with independent software modules. Without this exception, the linking could result in the GPL applying to the combined work. The Classpath Exception prevents this copyleft effect with respect to independent modules.
Specifically, it allows a library licensed under the GPL with the Classpath Exception to be linked with an independent module, such as a proprietary application, without requiring that module to be licensed under the GPL solely because of the linking. The resulting program may generally be distributed under terms chosen by the distributor. The license terms applicable to the linked components must nevertheless be complied with.
It generally does not matter whether the library is linked statically or dynamically. What matters is that the linked module is genuinely independent, meaning that it is not derived from or based on the GPL-licensed library.
3. What are the consequences of end users replacing OSS libraries?
Certain open-source licenses, particularly the GNU Lesser General Public License (LGPL), are intended to ensure that users can modify an integrated OSS library or replace it with a modified version. If such a library is linked, whether dynamically or statically, to proprietary software, neither the technical arrangements nor the contractual terms may impermissibly restrict this possibility.
For software providers, this also raises the question of who bears responsibility if an end user makes such a modification independently. If the user independently modifies or replaces an OSS library and this results in malfunctions, incompatibilities, or other problems, the provider should generally not bear the same level of responsibility as it does for the software it supplies.
Precisely because certain open-source licenses grant end users such modification or replacement rights, the associated risk should be appropriately addressed in the contractual terms. In particular, the warranty and liability provisions should clarify that, to the extent permitted by law, the provider is generally not liable for the consequences of the end user’s independent modification or replacement of the relevant OSS components. At the same time, these provisions must not impermissibly restrict the rights granted to the end user under the applicable open-source license.
4. How do Docker images and containers work?
Docker is a widely used platform that enables software to be deployed and run in so-called containers. Containers create a largely uniform and isolated environment, allowing an application to run reliably regardless of the underlying system.
A Docker image forms the basis for this. It contains the components required to run the software, such as the application itself, libraries, runtime environments, and configuration files. A container is a running instance of such an image. Multiple separate containers can be launched from the same image.
A Dockerfile, in turn, is a text file containing instructions for creating a Docker image. Put simply, the Dockerfile is the “recipe”, the image is the software package created from it, and the container is the running instance of that package.
5. What OSS risks does Docker pose?
In addition to the application itself, Docker images often contain numerous other software components, such as operating system components, libraries, and other dependencies. If a Docker image is shared with customers or other third parties, these components are generally included as well, even if they are not actually required for the application. Their license terms must therefore also be observed.
It is important to distinguish between a Dockerfile and a Docker image. The license applicable to the Dockerfile generally says nothing about the licenses applicable to the software contained in the Docker image. For example, a Dockerfile licensed under the MIT License may include GPL-licensed software in the Docker image. Depending on the licenses of the included components, license texts and copyright notices may have to be provided, or source code made available, when the image is distributed.
A Docker image also consists of multiple layers. For compliance purposes, the software distributed within these layers is generally relevant, not merely what is visible in the final Docker image. Companies should therefore identify the included components and their licenses and review them before distributing the image. This also applies to Docker images obtained from public repositories.
6. What OSS risks arise from dependencies and package managers?
Modern software often relies on numerous external software packages and libraries integrated through package managers such as npm, Maven, or pip. These packages and libraries may, in turn, depend on other components. Such transitive dependencies are often installed automatically, without developers consciously selecting each individual component.
From a licensing perspective, these dependencies must not be overlooked. The various components may be subject to different open-source licenses and, depending on how they are integrated and used, may trigger obligations such as requirements to include license texts and copyright notices or, particularly in the case of copyleft licenses, more extensive obligations. Problems may arise, in particular, if individual licenses are incompatible with the intended use or with other applicable licenses.
Companies should therefore identify and document not only the OSS components they have directly selected, but also the entire dependency tree. Software Composition Analysis (SCA) tools and an up-to-date Software Bill of Materials (SBOM) can help automatically identify direct and transitive dependencies and the corresponding license information. Before any release or distribution of the software, companies should verify that all resulting license obligations are being met.
7. Are algorithms protected by copyright?
For computer programs, copyright law generally protects the specific expression of an idea, particularly the corresponding source code. By contrast, the underlying idea, a mathematical method, or the mere functionality of a program is generally not protected by copyright.
The distinction becomes more difficult when an idea can technically be implemented in only a limited number of ways. In such cases, the idea and its specific expression are closely intertwined. Under the “Merger Doctrine” developed in U.S. law, software is not protected by copyright where its form of expression “merges” with the underlying idea. In such cases, copyright protection should not result in the underlying idea or method being effectively monopolized through protection of the source code.
In Switzerland, the Merger Doctrine is not recognized as a standalone legal principle. However, Swiss copyright law may lead to a similar result: protection extends to the original expression, not to the underlying idea. The more source code is dictated by technical specifications, standards, or the intended functionality, the more limited the scope of copyright protection may be.
An algorithm may, however, be protected in other ways, for example through confidentiality, contractual provisions, or, if the relevant requirements are met, a patent.
8. Does switching a public repository to “private” make it proprietary again?
If a public repository is changed to “private”, the source code is no longer freely accessible to new users. However, rights already granted under a valid OSS license are generally not retroactively revoked as a result.
Anyone who previously lawfully obtained the source code under an OSS license may continue to use, modify, and, to the extent permitted, distribute it in accordance with the terms of that license. Existing forks also do not automatically become unlawful when the status of the original repository changes. In principle, simply removing the repository or the license text does not alter this.
In practice, however, evidence may be crucial: Which version was obtained, when was it obtained, and under which license? Developers and companies should therefore carefully document the relevant versions and associated license information.
It is also important to note that merely publishing source code in a public repository does not automatically make it open source. For this to occur, the rights holder must grant the relevant rights of use, typically through an explicitly specified OSS license.
9. What happens to OSS licenses in the event of a change in ownership?
If the copyright in software is transferred, for example as part of an asset deal, OSS licenses that have already been validly granted remain in effect according to the view taken here. Although the doctrinal basis is not conclusively settled, practical considerations in particular support this position. The open-source model depends on users and developers being able to rely on rights already granted. If those rights could cease to exist as a result of a transfer of copyright, this would jeopardize collaborative development and contradict the fundamental principles of open source.
According to this view, the new rights holder acquires the software together with its existing licensing history. The change in rights holder leaves previously granted OSS rights to the published versions unaffected, subject to mandatory provisions of the applicable law. The new rights holder may nevertheless release future versions under a different license, provided that it holds the necessary rights to the entire source code concerned. If external contributors hold rights in portions of the source code or third-party components have been integrated into it, a change of license may require the consent of the respective rights holders, unless the necessary permissions have already been granted under the applicable licenses or a Contributor License Agreement (CLA).
In corporate transactions, it is therefore important to verify who actually holds the rights to the source code and which OSS obligations apply. License information, CLAs, employment and development agreements, and the origin of the source code are particularly relevant. An unclear rights or licensing position can significantly affect the value of the software and the ability to sell it.
