Der Open-Source-Dschungel: Rechtliche Fragen im Rampenlicht
Artikel
Compliance
Legal
Daten / Technologie / IP
Teil 3: Was muss bei der Integration von OSS beachtet werden?
Noëlle Glaus
Legal Associate
Michael Kunz
Legal Partner
Philipp Stadler
Senior Legal Associate
Teil 3 dieser Serie konzentriert sich auf die Chancen und Risiken, die sich ergeben, wenn ein Softwarenutzer Open-Source Komponenten nutzt oder in seinen eigenen Code integriert.
Was ist «Weitergabe»?
Unter «Weitergabe» versteht man die Übertragung einer Kopie eines urheberrechtlich geschützten Werks, wie beispielsweise Software, von einer Rechtsperson auf eine andere. Das Prinzip der Weitergabe ist besonders wichtig für Unternehmen und Entwickler, die Open-Source-Software (OSS) einsetzen und in ihre eigenen Produkte integrieren, da viele Verpflichtungen aus OSS-Lizenzen erst bei einer Weitergabe an Dritte wirksam werden.
Entscheidend ist dabei nicht, wie die Software genutzt wird, sondern ob ein Dritter tatsächlich eine Kopie erhält. Solange eine Anwendung nur intern genutzt oder weiterentwickelt wird und keine externen Dritten eine Kopie erhalten, liegt keine Weitergabe vor. Damit werden die Pflichten aus OSS-Lizenzen in diesem Fall noch nicht ausgelöst. Eine Weitergabe liegt typischerweise vor, wenn (i) Software an Kunden ausgeliefert wird, (ii) Quellcode oder Binärdateien überlassen werden oder (iii) Software öffentlich zum Download bereitgestellt wird.
Was gilt bei Cloud- und SaaS-Lösungen?
Bei modernen Bereitstellungsformen wie Software-as-a-Service (SaaS) oder webbasierten Anwendungen ist der Begriff der Weitergabe nicht immer eindeutig. Die zentrale Frage lautet: Liegt eine Weitergabe bereits vor, wenn Nutzer über das Internet mit der Software interagieren, ohne eine Kopie herunterzuladen? Nach herrschender Lehre und Rechtsprechung ist die Antwort für die meisten Open-Source-Lizenzen: Nein. Nutzer erhalten nur Zugriff auf die Software, aber keine Kopie, sodass die Lizenzpflichten in der Regel nicht ausgelöst werden. So definiert beispielsweise die strenge GPLv3-Lizenz den Begriff «übermitteln» (to convey) wie folgt:
“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.”
Eine besondere Ausnahme bildet die Affero GPL (AGPL). Sie wurde entwickelt, um sicherzustellen, dass Lizenzpflichten auch dann gelten, wenn Software über ein Netzwerk bereitgestellt wird, ohne dass Kopien übermittelt werden. Bereits das Bereitstellen der Software über ein Netzwerk gilt hier als Weitergabe. In diesem Fall müssen die Lizenzbedingungen der AGPL eingehalten werden, etwa die Pflicht, den Quellcode allen Nutzern unter denselben Bedingungen zugänglich zu machen.
Welche Pflichten entstehen bei der Weitergabe?
Wird Open-Source-Software nicht nur intern genutzt, sondern an Dritte weitergegeben – zum Beispiel durch die Auslieferung oder das Zurverfügungstellen einer Anwendung mit entsprechenden OSS-Komponenten – greifen bestimmte Lizenzpflichten. Diese unterscheiden sich je nach Lizenztyp und betreffen unter anderem Transparenzanforderungen, die Pflicht, Änderungen kenntlich zu machen, sowie die für Copyleft-Lizenzen typische Verpflichtung, die Software unter denselben Lizenzbedingungen weiterzugeben (siehe unten, Ziffer 6).
Um diese Pflichten zu kennen, müssen Entwickler spätestens beim Produkt-Release genau wissen, welche Komponenten in der Anwendung enthalten sind und unter welchen Lizenzen sie stehen. Es empfiehlt sich die Erstellung einer Software „Bill of Materials“ (BoM), die alle eingesetzten Komponenten samt Lizenzinformationen dokumentiert (siehe auch unten, Ziffer 8). Fehlen diese Informationen oder sind sie unvollständig, kann dies schnell zu Lizenzverstössen führen und rechtliche Risiken nach sich ziehen. Nur wenn problematische Komponenten rechtzeitig erkannt werden, können sie vor dem Release ersetzt oder unter einer geeigneten Lizenz in die Anwendung aufgenommen werden.
Was steckt hinter der Notice-Pflicht?
Zahlreiche Open-Source-Lizenzen verlangen, dass bei der Weitergabe von Software auf die verwendeten OSS-Komponenten hingewiesen wird. Die sogenannte «Notice»-Pflicht bedeutet, dass Empfänger darüber informiert werden müssen, welche Teile der Software unter welcher Lizenz stehen. In der Praxis werden dazu meist die vollständigen Lizenztexte beigelegt, Urheber und Mitwirkende genannt und gegebenenfalls der zugehörige Quellcode bereitgestellt.
Es hat sich bewährt, den von der Lizenz abgedeckten Quellcode bereits vor der Weitergabe bereitzustellen, da die Lizenztexte in der Regel als Textdateien im Quellcodepaket enthalten sind. Allerdings ist umstritten, ob die reine Einbettung der Lizenztextdateien im Quellcodepaket ausreicht, um den (teilweise) strengen Transparenzanforderungen von Open Source Lizenzen gerecht zu werden. Aus diesem Grund empfiehlt es sich, dem Quellcodepaket oder dem entsprechenden Repository eine zusätzliche Textdatei beizulegen, die klar beschreibt, unter welcher Lizenz die gesamte Anwendung veröffentlicht bzw. weitergegeben wird und unter welcher Lizenz die einzelnen Komponenten stehen.
Lizenzverletzung oder keine Lizenz?
Im Umgang mit Open-Source-Software ist zwischen einer Nutzung ohne wirksame Lizenz und einer Verletzung bestehender Lizenzbedingungen zu unterscheiden.
Liegt keine wirksame Lizenz oder sonstige Nutzungserlaubnis vor, etwa weil fremder Code ohne Lizenzangabe übernommen wurde und keine anderweitige Einwilligung des Rechteinhabers besteht, handelt es sich um eine Urheberrechtsverletzung. In diesem Fall ist die Nutzung unzulässig; regelmässig kommen nur die nachträgliche Einholung einer Lizenz vom Rechteinhaber oder die vollständige Entfernung des betroffenen Codes in Betracht.
Besteht hingegen eine wirksame Lizenz, wurden deren Bedingungen jedoch nicht oder nicht vollständig eingehalten (z. B. fehlende Copyright-Hinweise oder unterlassene Offenlegungspflichten), liegt eine Lizenzverletzung vor. Je nach Lizenz kann ein solcher Verstoss zum automatischen Wegfall der Nutzungsberechtigung führen, sodass jede weitere Nutzung eine Urheberrechtsverletzung darstellt. Soweit die jeweilige Lizenz und das anwendbare Recht dies vorsehen, kann die Verletzung durch nachträgliche Erfüllung der Lizenzpflichten geheilt und die Lizenz für die Zukunft wiederhergestellt werden. Andernfalls ist die Beendigung der Nutzung durch Entfernung oder Ersetzung des betroffenen Codes erforderlich.
Was ist der «virale Effekt»?
Der sogenannte «virale Effekt» wird im Zusammenhang mit Copyleft-Lizenzen, insbesondere der GPL, häufig diskutiert. Er beschreibt die verbreitete Vorstellung, dass die Integration von Copyleft-Code in proprietäre Software automatisch dazu führen könnte, dass der eigene Code unter die Copyleft-Lizenz fällt und in der Folge der gesamte Code offengelegt werden muss – auch der eigene. Juristisch gesehen ist diese Vorstellung jedoch unzutreffend.
Copyleft-Lizenzen wie die GPL sehen vor, dass bei der Weiterverbreitung eines kombinierten Werks, das GPL-lizenzierten Code enthält und ein einheitliches «abgeleitetes Werk» bildet, der gesamte verbreitete Code unter den Bedingungen der GPL stehen muss. Wer gegen diese Bedingung verstösst, indem er das kombinierte Werk weitergibt, ohne den vollständigen Quellcode unter der GPL offenzulegen, verliert die Lizenzrechte am GPL-Code. Die weitere Verbreitung stellt dann eine Urheberrechtsverletzung dar, die Unterlassungs- und gegebenenfalls Schadensersatzansprüche nach sich ziehen kann.
Das Urheberrecht kennt jedoch keine Rechtsmittel, mit denen Entwickler gezwungen werden könnten, ihren proprietären Code aktiv unter die GPL zu stellen oder in die Public Domain zu überführen. Die Integration von GPL-Code „infiziert“ proprietären Code nicht automatisch und wandelt ihn nicht kraft Gesetzes in GPL-Code um. Der virale Effekt wirkt ausschliesslich als Bedingung für die rechtmässige Weiterverbreitung: Wer ein kombiniertes bzw. abgeleitetes Werk verbreiten möchte, muss sich entscheiden, entweder die GPL-Bedingungen einzuhalten oder auf die Verbreitung zu verzichten.
Was sind Lizenzkonflikte?
Lizenzkonflikte entstehen, wenn Codebasen unter unterschiedlichen Lizenzen in einem neuen Projekt zusammengeführt werden und die Bedingungen der Lizenzen miteinander unvereinbar sind. Beispielsweise ist die Kombination einer strengen Copyleft-Lizenz mit einer freizügigen (auch «permissiven» Lizenz) grundsätzlich problematisch, wenn beabsichtigt ist, das kombinierte (bzw. abgeleitete) Werk unter einer freizügigen Lizenz zu verbreiten. Lizenzkonflikte können auch entstehen, wenn bestimmte Nutzungsbedingungen einer Lizenz den Bedingungen einer anderen Lizenz widersprechen, etwa hinsichtlich der erlaubten Nutzung, Weitergabe oder Patentrechte.
Die jüngste Open Source Security and Risk Analysis‑Studie (OSSRA 2025) von Black Duck zeigt, dass Lizenzkonflikte nach wie vor weit verbreitet sind: In 56 % der untersuchten Anwendungen wurden Lizenzkonflikte festgestellt, und in 33 % der Fälle sind Komponenten ohne eindeutige Lizenz oder mit angepasster Lizenz enthalten, was rechtliche Unsicherheiten verschärft. Verantwortliche von Open-Source-Projekten, Nutzer entsprechender Software und Entwickler sollten daher die Lizenzbedingungen aller eingesetzten Komponenten sorgfältig prüfen und sicherstellen, dass diese miteinander kompatibel sind, bevor sie Code kombinieren oder weiterverbreiten.
Weshalb ist die Kompatibilität von OSS-Lizenzenwichtig?
In modernen Softwareprojekten werden häufig verschiedene Open-Source-Komponenten kombiniert, die jeweils eigenen Lizenzbedingungen unterliegen. Besonders relevant ist die Kompatibilität dieser Lizenzen im Hinblick auf Copyleft-Mechanismen wie die GPL, die vorschreiben, dass abgeleitete Werke unter derselben Lizenz weitergegeben werden müssen. Kompatibilitätsprobleme können die Nutzung oder Weitergabe von Software einschränken und lassen sich in der Praxis meist nur durch alternative Lizenzierung oder den Austausch einzelner Komponenten lösen.
Eine bewährte Methode zur Risikominimierung ist die Erstellung einer Software „Bill of Materials“ (BoM), die alle eingesetzten Komponenten samt Lizenzinformationen dokumentiert. Die BoM dient als Grundlage für interne Compliance-Audits und wird zunehmend von Kunden, Investoren oder Käufern verlangt, um die rechtliche Lage der Software nachvollziehen zu können. Die wirtschaftliche Bewertung und Veräusserbarkeit einer Softwarelösung hängen massgeblich davon ab, ob ihre Lizenzlage transparent und rechtlich belastbar ist. Fehlende Transparenz oder ungeklärte Lizenzkonflikte können den Wert der Software bzw. den Unternehmenswert mindern oder Transaktionen verzögern, insbesondere wenn entsprechende Risiken erst im Rahmen von Due-Diligence-Prüfungen offenkundig werden.
Was ist bei Patenten zu beachten?
Neben dem Urheberrecht kann Open-Source-Software auch Fragen zu Patenten aufwerfen. Einige Lizenzen, wie Apache 2.0 oder GPLv3, enthalten ausdrücklich eine Patentlizenz, welche die Nutzung geschützter Technologien innerhalb der Software erlaubt und verhindert, dass Rechteinhaber nach der Weitergabe des Codes Patentansprüche gegen Nutzer geltend machen. Andere Lizenzen, etwa BSD, MIT oder GPLv2, treffen hierzu keine klaren Aussagen. Gerichte vertreten teilweise die Auffassung, dass durch die Nutzung des OSS-Quellcodes eine implizite Patentlizenz eingeräumt wird, doch dies ist rechtlich nicht einheitlich geklärt. Grundsätzlich bleibt daher bei Lizenzen ohne ausdrückliche Patentklausel eine gewisse Unsicherheit hinsichtlich möglicher Patentansprüche des Rechteinhabers gegenüber den Nutzern.
Klicken Sie hier um mehr über unsere Expertisen zu erfahren:
