26. Oktober 2026

Der Open-Source-Dschungel: Rechtliche Fragen im Rampenlicht – Teil IV

  • Artikel
  • Compliance
  • Legal
  • Daten / Technologie / IP

Teil 4 dieser Serie widmet sich ausgewählten Praxisproblemen, die bei der Entwicklung, Be-reitstellung und Übertragung von Software regelmässig auftreten.

  • Noëlle Glaus

    Legal Associate

  • Michael Kunz

    Legal Partner

  • Philipp Stadler

    Senior Legal Associate

 

1. Welchen Einfluss hat statisches oder dynamisches Linking auf die Lizenzpflichten?

Software wird häufig mit externen Bibliotheken verbunden. Beim statischen Linking wird deren Code beim Kompilieren in die ausführbare Datei eingebunden. Beim dynamischen Linking bleibt die Bibliothek separat und wird erst bei der Ausführung geladen.

Diese Unterscheidung kann lizenzrechtlich relevant sein, insbesondere bei Copyleft-Lizenzen. Dabei stellt sich die Frage, ob Bibliothek und Hauptprogramm durch das Linking so eng verbunden werden, dass Lizenzpflichten auch für das Hauptprogramm entstehen. Die Art des Linkings allein ist dafür jedoch nicht entscheidend.

Das zeigt der Vergleich von GNU General Public License (GPL) und GNU Lesser General Public License (LGPL): Bei der GPL führt nach Auffassung der Free Software Foundation sowohl statisches als auch dynamisches Linking dazu, dass das verbundene Programm den Copyleft-Pflichten der GPL unterliegt. Die LGPL erlaubt dagegen grundsätzlich auch das Linking mit proprietärer Software. Dynamisches Linking ist dabei meist einfacher, während bei statischem Linking zusätzliche Pflichten bestehen können, insbesondere um ein erneutes Linking mit einer modifizierten Version der LGPL-Bibliothek zu ermöglichen.

Entscheidend sind daher stets die konkrete Lizenz, ihre Version und die Art der technischen Einbindung der Bibliothek.

2. Was bewirkt die Classpath Exception?

Die Classpath Exception ist eine Ergänzung zur GPL. Sie schränkt die Copyleft-Wirkung der GPL beim Verlinken einer GPL-lizenzierten Bibliothek mit unabhängigen Softwaremodulen ein. Ohne die Ausnahme könnte die Verbindung dazu führen, dass die GPL auf das kombinierte Werk Anwendung findet. Die Classpath Exception verhindert diese Copyleft-Wirkung für unabhängige Module.

Konkret erlaubt sie, eine entsprechend lizenzierte Bibliothek mit einem unabhängigen Modul – z.B. einer proprietären Anwendung – zu verbinden, ohne dass dieses Modul allein aufgrund der Verbindung ebenfalls unter die GPL gestellt werden muss. Das daraus entstehende Programm kann grundsätzlich unter selbst gewählten Lizenzbedingungen weitergegeben werden. Die Lizenzbedingungen der eingebundenen Komponenten sind weiterhin einzuhalten.

Dabei spielt es grundsätzlich keine Rolle, ob die Bibliothek statisch oder dynamisch eingebunden wird. Entscheidend ist, dass das verbundene Modul tatsächlich unabhängig ist, also nicht von der GPL-lizenzierten Bibliothek abgeleitet ist oder auf ihr basiert.

3. Welche Folgen hat der Austausch von OSS-Bibliotheken durch Endnutzer?

Bestimmte Open-Source-Lizenzen, insbesondere die GNU Lesser General Public License (LGPL), sollen sicherstellen, dass Nutzer eine eingebundene OSS-Bibliothek verändern oder durch eine modifizierte Version ersetzen können. Wird eine solche Bibliothek (dynamisch oder statisch) mit proprietärer Software verbunden, darf die technische oder vertragliche Ausgestaltung diese Möglichkeit nicht unzulässig beschränken.

Für Softwareanbieter stellt sich damit auch die Frage, wer die Verantwortung trägt, wenn ein Endnutzer eine solche Änderung selbst vornimmt. Verändert oder ersetzt der Nutzer eine OSS-Bibliothek eigenständig und führt dies zu Fehlfunktionen, Inkompatibilitäten oder anderen Problemen, sollte der Anbieter hierfür grundsätzlich nicht dieselbe Verantwortung übernehmen wie für die von ihm ausgelieferte Software.

Gerade weil bestimmte Open-Source-Lizenzen dem Endnutzer solche Änderungs- oder Austauschmöglichkeiten einräumen, sollte dieses Risiko auch in den Vertragsbedingungen angemessen berücksichtigt werden. Gewährleistungs- und Haftungsregelungen sollten insbesondere klarstellen, dass der Anbieter für Folgen eigenständiger Änderungen oder eines Austauschs der betreffenden OSS-Komponenten durch den Endnutzer grundsätzlich nicht einsteht, soweit dies rechtlich zulässig ist. Gleichzeitig dürfen diese Regelungen die dem Endnutzer durch die anwendbare Open-Source-Lizenz eingeräumten Rechte nicht unzulässig beschränken.

4. Wie funktionieren Docker Images und Container?

Docker ist eine weit verbreitete Plattform, mit der Software in sogenannten Containern bereitgestellt und ausgeführt werden kann. Container schaffen eine weitgehend einheitliche und isolierte Umgebung, sodass eine Anwendung unabhängig vom jeweiligen System zuverlässig ausgeführt werden kann.

Grundlage dafür ist ein Docker Image. Es enthält die für die Ausführung benötigten Komponenten, beispielsweise die Anwendung selbst, Bibliotheken, Laufzeitumgebungen und Konfigurationsdateien. Ein Container ist eine laufende Instanz eines solchen Images. Aus demselben Image können mehrere voneinander getrennte Container gestartet werden.

Ein Dockerfile ist wiederum eine Textdatei mit Anweisungen zur Erstellung eines Docker Images. Vereinfacht gesagt ist das Dockerfile das „Rezept“, das Image das daraus erstellte Softwarepaket und der Container dessen laufende Instanz.

 

5. Welche OSS-Risiken entstehen durch Docker?

Docker Images enthalten neben der eigentlichen Anwendung häufig zahlreiche weitere Softwarekomponenten, etwa Betriebssystembestandteile, Bibliotheken und andere Abhängigkeiten. Wird ein Docker Image an Kunden oder andere Dritte weitergegeben, werden grundsätzlich auch diese Komponenten mitgeliefert – selbst wenn sie für die Anwendung gar nicht benötigt werden. Daher müssen auch deren Lizenzbedingungen beachtet werden.

Wichtig ist dabei die Unterscheidung zwischen Dockerfile und Docker Image: Die Lizenz des Dockerfiles sagt grundsätzlich nichts über die Lizenzen der im Docker Image enthaltenen Software aus. Ein Dockerfile unter der MIT License kann z.B. GPL-lizenzierte Software in das Docker Image einbinden. Je nach Lizenz der enthaltenen Komponenten müssen bei einer Weitergabe etwa Lizenztexte und Copyright-Hinweise mitgeliefert oder Quellcode zur Verfügung gestellt werden.

Ein Docker Image besteht zudem aus mehreren Layers. Für die Compliance ist grundsätzlich die Software relevant, die mit diesen Layers weitergegeben wird – nicht nur das, was im fertigen Docker Image sichtbar ist. Unternehmen sollten deshalb die enthaltenen Komponenten und deren Lizenzen kennen und vor einer Weitergabe prüfen. Dies gilt auch für Docker Images aus öffentlichen Repositories.

6. Welche OSS-Risiken entstehen durch Abhängigkeiten und Package Manager?

Moderne Software greift häufig auf zahlreiche externe Softwarepakete und Bibliotheken zurück, die über Package Manager wie npm, Maven oder pip eingebunden werden. Diese Pakete und Bibliotheken können ihrerseits von weiteren Komponenten abhängig sein. Solche sogenannten transitiven Abhängigkeiten werden oft automatisch installiert, ohne dass Entwickler jede einzelne Komponente bewusst auswählen.

Aus lizenzrechtlicher Sicht dürfen auch diese Abhängigkeiten nicht ausser Acht gelassen werden. Die verschiedenen Komponenten können unterschiedlichen Open-Source-Lizenzen unterliegen und je nach Art ihrer Einbindung und Nutzung beispielsweise Pflichten zur Mitlieferung von Lizenztexten und Copyright-Hinweisen oder – insbesondere bei Copyleft-Lizenzen – weitergehende Anforderungen auslösen. Problematisch kann es insbesondere werden, wenn einzelne Lizenzen nicht mit der vorgesehenen Nutzung oder mit anderen eingesetzten Lizenzen kompatibel sind.

Unternehmen sollten deshalb nicht nur die unmittelbar ausgewählten OSS-Komponenten, sondern den gesamten Dependency Tree kennen und dokumentieren. Software-Composition-Analysis-Tools (SCA) und eine aktuelle Software Bill of Materials (SBOM) helfen dabei, direkte und transitive Abhängigkeiten samt deren Lizenzinformationen automatisiert zu erfassen. Vor jeder Veröffentlichung oder Weitergabe der Software sollte deshalb geprüft werden, ob alle resultierenden Lizenzpflichten eingehalten werden.

7. Sind Algorithmen urheberrechtlich geschützt?

Das Urheberrecht schützt bei Computerprogrammen grundsätzlich die konkrete Umsetzung einer Idee, insbesondere den individuell gestalteten Quellcode. Die dahinterstehende Idee, eine mathematische Methode oder die blosse Funktion eines Programms ist dagegen grundsätzlich nicht urheberrechtlich geschützt.

Schwieriger wird die Abgrenzung, wenn sich eine Idee technisch nur auf wenige Arten umsetzen lässt. Dann liegen Idee und konkrete Umsetzung sehr nahe beieinander. Nach der im US-amerikanischen Recht entwickelten «Merger Doctrine» kann eine Software, deren Ausdrucksform mit der Idee «verschmilzt» nicht urheberrechtlich geschützt werden. Der Urheberrechtsschutz soll in solchen Fällen nicht dazu führen, dass über den Schutz des Quellcodes faktisch auch die zugrunde liegende Idee oder Methode monopolisiert wird.

In der Schweiz ist die Merger Doctrine zwar kein eigenständiger Rechtsgrundsatz. Das Schweizer Urheberrecht kann jedoch zu einem ähnlichen Ergebnis führen: Geschützt ist die individuell gestaltete Ausdrucksform, nicht die dahinterstehende Idee. Je stärker ein Quellcode durch technische Vorgaben, Standards oder die gewünschte Funktion vorgegeben ist, desto enger kann daher sein urheberrechtlicher Schutz sein.

Ein Algorithmus kann jedoch auf andere Weise geschützt werden, etwa durch Geheimhaltung, vertragliche Regelungen oder – sofern die entsprechenden Voraussetzungen erfüllt sind – durch ein Patent.

8. Wird ein öffentliches Repository durch die Umstellung auf «private» wieder proprietär?

Wird ein öffentliches Repository auf «private» gestellt, ist der Quellcode für neue Nutzer nicht mehr frei zugänglich. Bereits eingeräumte Rechte aus einer gültigen OSS-Lizenz werden dadurch jedoch grundsätzlich nicht rückwirkend entzogen.

Wer den Quellcode zuvor rechtmässig unter einer OSS-Lizenz bezogen hat, darf ihn weiterhin nach den Bedingungen dieser Lizenz nutzen, bearbeiten und – soweit erlaubt – weitergeben. Auch bestehende Forks werden durch die Umstellung des ursprünglichen Repositories nicht automatisch unzulässig. Allein das Entfernen des Repositories oder des Lizenztexts ändert daran grundsätzlich nichts.

In der Praxis kann allerdings der Nachweis entscheidend sein: Welche Version wurde wann und unter welcher Lizenz bezogen? Entwickler und Unternehmen sollten deshalb Versionen und die dazugehörigen Lizenzinformationen sorgfältig dokumentieren.

Wichtig ist zudem, dass die blosse Veröffentlichung von Quellcode in einem öffentlichen Repository diesen noch nicht zu Open Source macht. Dafür muss der Rechteinhaber entsprechende Nutzungsrechte einräumen, typischerweise durch eine ausdrücklich angegebene OSS-Lizenz.

9. Was geschieht mit OSS-Lizenzen bei einem Eigentümerwechsel?

Werden die Urheberrechte an einer Software übertragen, etwa im Rahmen eines Asset Deals, bleiben bereits wirksam erteilte OSS-Lizenzen nach der hier vertretenen Auffassung bestehen. Auch wenn die dogmatische Einordnung nicht abschliessend geklärt ist, sprechen insbesondere praktische Erwägungen dafür. Das Open-Source-Modell setzt voraus, dass sich Nutzer und Entwickler auf bereits eingeräumte Rechte verlassen können. Könnten diese durch einen Rechteübergang entfallen, würde dies die kooperative Weiterentwicklung gefährden und dem Grundgedanken von Open Source widersprechen.

Nach dieser Auffassung übernimmt der neue Rechteinhaber die Software mit ihrer bestehenden Lizenzhistorie. Der Wechsel des Rechteinhabers lässt die bereits eingeräumten OSS-Nutzungsrechte an den veröffentlichten Versionen unberührt. Dies gilt allerdings vorbehaltlich zwingender Vorgaben der jeweils anwendbaren Rechtsordnung. Der neue Rechteinhaber kann jedoch künftige Versionen unter einer anderen Lizenz veröffentlichen, sofern er über die dafür erforderlichen Rechte am gesamten betroffenen Quellcode verfügt. Wenn externe Contributors eigene Rechte am Quellcode besitzen oder externe Komponenten in den Quellcode integriert wurden, setzt ein Lizenzwechsel unter Umständen die Zustimmung der jeweiligen Rechteinhaber voraus, sofern sich die erforderlichen Befugnisse nicht bereits aus den anwendbaren Lizenzen oder einem Contributor License Agreement (CLA) ergeben.

Bei Unternehmenstransaktionen sollte deshalb geprüft werden, wem die Rechte am Quellcode tatsächlich zustehen und welche OSS-Verpflichtungen bestehen. Relevant sind insbesondere Lizenzinformationen, CLAs, Arbeits- und Entwicklungsverträge sowie die Herkunft des Quellcodes. Eine unklare Rechte- oder Lizenzlage kann den Wert und die Veräusserbarkeit der Software erheblich beeinflussen.

Klicken Sie hier um mehr über unsere Expertisen zu erfahren:
Zurück

Ihr Team