Open Source Software — Lizenzierung!?
OSS ist in der Regel frei zugänglich, doch dahinter können sich verschiedenste Kombinationen von Lizenzierungen befinden, welche in der Praxis oft missachtet werden.
Ein hervorragender Artikel in englischer Sprache wurde deshalb ins deutsche übersetzt, um einen Einblick zu geben, wie komplex Open Source Lizenzierung sein kann. Der Originaltitel lautet: Open Source License Compliance-Why and How? aus dem Computer Magazin in der Ausgabe August 2019 auf den Seiten 63–67.
Einhaltung der Open-Source-Lizenz — Warum und Wie?
Kurzfassung
Die Einhaltung der Lizenzanforderungen für Open-Source-Software (OSS) ist notwendig, wird aber oft übersehen. In diesem Artikel wird erläutert, wie sich die Einhaltung von OSS-Lizenzen von der Einhaltung kommerzieller Softwarelizenzen unterscheidet, warum sie notwendig ist, obwohl OSS im Allgemeinen kostenlos ist und welche Anforderungen an OSS gestellt werden müssen. Der Schwerpunkt liegt auch auf dem häufigsten Anwendungsfall: Dem Verkauf eines Produkts, das offenen Quellcode enthält.
Bei der Verbreitung von Open Source Software (OSS)-Komponenten als eigenständige Software oder im Rahmen eigener Softwareprojekte wird ein wesentlicher Schritt zur Einhaltung der jeweiligen Lizenzbestimmungen oft vernachlässigt und seine Komplexität oft unterschätzt.
Unterschiede zwischen kommerziellen Lizenzen und OSS-Lizenzen
Warum ist die Einhaltung von OSS-Lizenzen so komplex?
Die Schwierigkeiten werden deutlich, wenn man OSS-Lizenzen mit kommerziellen Lizenzen vergleicht. Bei den meisten kommerziellen Lizenzen besteht die Hauptverpflichtung des Lizenznehmers lediglich in einer Zahlung für das Recht, die Software zu nutzen oder zu verbreiten. Kommerzielle Lizenzen können mit spezifischen Einschränkungen bezüglich der Lizenz-Metriken in Form von Concurrent-User-Lizenzen oder speziellen Anforderungen für die indirekte Nutzung von Software oder deren Vertrieb einhergehen; die Hauptpflicht (auch in diesen soeben genannten Fällen) ist jedoch die Zahlung einer Vergütung für die Nutzung der Software.
Die meisten OSS-Lizenzen funktionieren anders als kommerzielle Lizenzen. Sie beinhalten keine Zahlungen. Viele verlangen jedoch die Bereitstellung von Lizenztexten oder anderen Informationen zusammen mit der Bereitstellung der Software. Einige Lizenzen verlangen die Bereitstellung oder das Angebot des Quellcodes der OSS-Komponente in Fällen, in denen die Software nur in binärer Form zur Verfügung gestellt wird.
Vom Original-Autor:
Willkommen zurück zu dieser Kolumne über Open-Source-Software und wie sie die Welt verändert! Im vorherigen Text wurden Open-Source-Lizenzen vorgestellt und erläutert: die Rechte, die sie Ihnen einräumen, die Pflichten, die Sie zu erfüllen haben, und die Verbote, die Sie zu beachten haben. Für Benutzer von Open-Source-Software können die Verpflichtungen besonders heikel sein. Sie müssen diese Verpflichtungen einhalten, damit die Ihnen gewährten Rechte wirksam werden können. Wenn Sie die Verpflichtungen missachten, können Sie vom Rechtsinhaber verklagt werden.
Neben rein kommerziellen und rein Open-Source-lizenzierten Projekten gibt es viele Zwischenformen. Fast jedes größere Stück Software enthält heutzutage OSS-Komponenten. Einige kommerzielle Anwendungen werden auch in einem dualen Lizenzmodell lizenziert, bei dem die gleiche Komponente unter einer OSS-Lizenz und unter einer kommerziellen Lizenz verfügbar ist, die den Empfänger von den Anforderungen der OSS-Lizenz befreit. Ein weiteres gängiges Lizenzmodell ist das offene Kernmodell, das die Basistechnologie unter einer OSS-Lizenz und zusätzliche Funktionalität oder Erweiterungen als proprietäre Software unter einer kommerziellen Lizenz anbietet.
Warum Compliance?
Warum ist die Einhaltung von Open-Source-Regeln so wichtig? Geht es nicht um freie Software? Wenn keine Unternehmen hinter solchen Lizenzen stehen, müssen Sie dann wirklich eine Durchsetzung im Falle der Nichteinhaltung befürchten?
Erstens kann, wie bereits erwähnt, OSS-lizenzierte Software Teil einer dualen Lizenzstrategie sein, hinter der ein Unternehmen und damit kommerzielle Ziele stehen.
Zweitens werden innerhalb der Gemeinschaft einige Anstrengungen unternommen, OSS-Lizenzen durchzusetzen, um das Bewusstsein für die Einhaltung von OSS-Lizenzen zu schärfen, was zu gerichtlichen Klagen führt.
Drittens haben einige Softwareentwickler ein Geschäftsmodell etabliert, indem sie Unternehmen in Fällen der Nichteinhaltung von OSS-Lizenzen angreifen. Einer von ihnen soll dadurch Millionen von Euro verdient haben.
Bei einigen OSS-Lizenzen, wie z.B. der GNU General Public License v2.0 (GPL-2.0), enden die Nutzungs- und Verbreitungsrechte bei Verletzung der Lizenzverpflichtungen. Infolgedessen kann ein Lizenzgeber von einem Softwarehersteller verlangen, von der zukünftigen Verbreitung seiner Komponenten abzusehen. Insbesondere nach deutschem Recht ist es in solchen Fällen recht einfach, von einem zuständigen Gericht eine Unterlassungsverfügung zu erwirken, was in der jüngeren Vergangenheit zu dem geführt hat, was als Open-Source-Trolling bezeichnet wurde.
Hauptverpflichtungen von OSS-Lizenzen
Die Hauptpflichten, die mit OSS-Lizenzen einhergehen, lassen sich in zwei Kategorien einteilen:
- organisatorische Anforderungen an den Umgang mit der OSS und
- Pflichten zur Information und Dokumentation.
Organisatorische Anforderungen
Copyleft-Effekt. Hinsichtlich des Umgangs mit OSS-Komponenten enthalten einige OSS-Lizenzen wie die GPL, die GNU Lesser GPL (LGPL) und die GNU Affero GPL (AGPL) einen so genannten Copyleft-Effekt: Abgeleitete Werke solcher OSS-Komponenten müssen unter derselben OSS-Lizenz lizenziert werden (siehe z.B. Abschnitt 2b der GPL-2.0). Dieser Effekt kann z.B. durch das statische Verlinken einer LGPL-lizenzierten Bibliothek mit proprietärem Code ausgelöst werden. Um den Copyleft-Effekt zu vermeiden, muss man im Falle der LGPL entweder dynamisch verlinken, oder, falls dies nicht ausreicht (wie bei GPL-lizenzierter Software, bei der jede Verlinkung den Effekt auslöst), auf die Verwendung der entsprechenden OSS-Komponente verzichten. Die Gewährleistung der Vermeidung eines solchen Copyleft-Effekts kann zu einem wesentlichen Element eines Open-Source-Compliance-Prozesses werden. Die Beurteilung, ob der Copyleft-Effekt zutrifft, ist in der Praxis nicht einfach, da sie nicht nur von technischen Anforderungen abhängt, die automatisch ausgewertet werden können. Noch komplizierter wird es, wenn Komponenten von Drittanbietern ins Spiel kommen, die nicht vom Vertreiber der endgültigen Software zusammengebaut wurden. In diesem Fall stehen dem Vertreiber die zur Beantwortung der Copyleft-Frage erforderlichen Kenntnisse nicht zur Verfügung, was die Beantwortung dieser Frage praktisch unmöglich macht.
Modifikation von OSS. Weitere organisatorische Anforderungen betreffen die Modifikation von OSS. In Distributionen von modifizierten Versionen verlangen einige Lizenzen, dass solche Änderungen zusammen mit begleitenden Informationen über das Datum und den Umfang der Änderungen formal hervorgehoben werden, oder sie verlangen, dass modifizierte Komponenten umbenannt werden, um Verwechslungen mit der Originalversion zu vermeiden (siehe z.B. Abschnitt 2a der GPL-2.0).
Geschützte Umgebung für die Verwaltung digitaler Rechte. Einige Lizenzen verlangen, dass der Benutzer modifizierte Versionen der OSS-Komponenten auf einem Gerät installieren kann (siehe z.B. Abschnitt 6, Absatz 5 der GPL-3.0). In der Praxis verbietet dies die Verwendung solcher Software in einer durch digitale Rechteverwaltung geschützten Umgebung. Folglich kann Software, die unter solchen Lizenzen vertrieben wird, auf keinem Gerät verwendet werden, das kryptografischen Schutz verwendet und nur entsprechend signierte Binärdateien ausführt. (Dies verbietet z.B. die Verwendung von GPL-3.0-lizenzierter Software auf einem iPhone).
Informations- und Dokumentationsanforderungen
Neben den organisatorischen Anforderungen enthalten die meisten Open-Source-Lizenzen spezifische Informations- und Dokumentationspflichten. In vielen Fällen verlangen die Lizenzen, dass der jeweilige Lizenztext bei der Verteilung der Software zusammen mit der Software geliefert wird.
Lassen Sie uns einen Blick auf die Verpflichtungen der GPL-2.0 werfen, einer der am weitesten verbreiteten Open-Source-Lizenzen in diesem Bereich. Gemäß Abschnitt 1 der GPL-2.0 muss mit jeder Programmkopie eine Kopie der Lizenzbedingungen mitgeliefert werden. Dies kann in physischer Form als Ausdruck oder nicht-physisch durch Hinzufügen einer entsprechenden Textdatei erfolgen. Nach der deutschen Rechtsprechung ist die bloße Bereitstellung eines Links zum Lizenztext nicht ausreichend.
In der Praxis werden die anwendbaren Lizenzen für OSS-Komponenten, die in proprietärer Software enthalten sind, oft einfach als eine große Textdatei zusammenkopiert, ohne anzugeben, auf welche Komponente die jeweiligen Lizenzen anwendbar sind. Dies entspricht wahrscheinlich nicht den Anforderungen der Lizenzen. Vielmehr müssen die jeweiligen Texte den entsprechenden lizenzierten Softwarepaketen zugeordnet werden, so dass jeder einzelnen Komponente die richtigen Lizenztexte zugeordnet werden.
Fehlende Lizenztexte sind ein klassischer Fall von Lizenzverletzungen, der bei einigen Lizenzen zum Verlust aller Nutzungsrechte führen kann (siehe Abschnitt 4 der GPL-2.0), und der in der Praxis manchmal Durchsetzungsmaßnahmen wie eine einstweilige Verfügung nach sich zieht.
Und neben dem Lizenztext ist in vielen Fällen auch ein Copyright-Vermerk mit Angabe des Namens des Autors erforderlich. Abschnitt 1 der GPL-2.0 verlangt vom Vertreiber, “auffällig und angemessen auf jeder Kopie einen entsprechenden Urheberrechtsvermerk zu veröffentlichen”.
Die Copyright-Hinweise finden sich normalerweise an mehreren Stellen innerhalb der Software. Einige von ihnen sind in der Datei mit den Lizenztexten enthalten. Darüber hinaus können die Quelldateien auch Urheberrechtsvermerke enthalten, die oft über Hunderte oder Tausende von Dateien verteilt sind. Die Hinweise werden jedoch nicht im Binärcode der Software zu finden sein, da ein Compiler sie nur als Kommentare betrachtet, die beim Kompilieren der Quelldateien entfernt werden.
Im Falle der GPL-2.0 ist umstritten, ob es ausreicht, die Copyright-Hinweise einfach aus den Lizenztexten zu entnehmen, oder ob es notwendig ist, für die Verbreitung der Binärdateien zusätzlich die Copyright-Hinweise aus den einzelnen Quelldateien zu extrahieren, was bei größeren Komponenten mit erheblichem Aufwand verbunden ist. Der Wortlaut von Abschnitt 1 der GPL-2.0 lässt eine Auslegung in der Weise zu, dass eine Extraktion der Urheberrechtshinweise erforderlich ist:
T. Jaeger and A. Metzger, Open Source Software, 4th ed. (in German), Munich: C. H. Beck, 2017, marginal 37.
A. Hemel and S. Coughlan, Practical GPL Compliance. San Francisco: Linux Foundation, 2017, p. 39.
Einige Lizenzen erfordern besondere Hinweise oder Hinweise in einer besonderen Form, wie z.B. die Berkeley Source Distribution (BSD)-4. Klausel, die verlangt, dass in der Werbung ein Hinweis auf Funktionen oder die Nutzung der lizenzierten Software angezeigt wird. In diesem Fall können sich die OSS-Lizenzen auf Marketingmaterialien oder andere Elemente auswirken, die normalerweise im Umgang mit OSS nicht berücksichtigt werden.
Die wahrscheinlich beste Möglichkeit, die oben genannten Informations- und Dokumentationsanforderungen zu erfüllen, ist die Erstellung und Pflege einer Stückliste als ein zentrales Dokument, in dem alle notwendigen Texte, Notizen und Informationen strukturiert enthalten sind.
Diese Stückliste sollte zusammen mit der Software geliefert und zusätzlich zum Bestandteil des mit dem Empfänger der Software abgeschlossenen Vertrages gemacht werden (der in der Regel vor Abschluss eines solchen Vertrages Informationen benötigt). Letzteres kann dadurch erreicht werden, dass die Stückliste im Internet zur Verfügung gestellt wird und in den Geschäftsbedingungen auf die Verwendung von Komponenten Dritter und auf eine Landing Page verwiesen wird, über die der Benutzer auf die für die Komponenten zutreffenden Dokumente zugreifen kann. Man sollte jedoch bedenken, dass dies im Hinblick auf die Verpflichtungen vieler Lizenzen nicht ausreichend ist.
Bereitstellung des Quellcodes
Einige OSS-Lizenzen verlangen die Bereitstellung des Quellcodes in Fällen, in denen das Softwarepaket nur in binärer Form bereitgestellt wird. In einigen Fällen ist ein schriftliches Angebot, den Quellcode auf Anfrage zur Verfügung zu stellen, ausreichend (siehe Abschnitt 3b der GPL-2.0). In anderen Fällen ist ein solches Angebot nicht ausreichend, und der Quellcode muss in einer bestimmten Form zur Verfügung gestellt werden, z.B. als Download von einem Server, wenn die Binärdatei auf die gleiche Weise zur Verfügung gestellt wird (siehe Abschnitt 6d der GPL-3.0).
In den vorhergehenden Beispielen muss der bereitgestellte Quellcode exakt derselbe Quellcode sein, der den jeweiligen Binärdateien zugrunde liegt. Es reicht nicht aus, auf die Webseite des offiziellen Projekts oder auf ein Online-Repository für die unmodifizierten Quelldateien der offiziellen Zweigstelle zu verweisen. Dies würde nur in den Fällen ausreichen, in denen das OSS unverändert verwendet wird; auch in solchen Fällen bleibt der Vertreiber für die Verfügbarkeit der Website oder des Repositories verantwortlich.
Im Falle von Aktualisierungen der Software muss auch dieser Quellcode zur Verfügung gestellt werden. Folglich muss der Benutzer eines eingebetteten Systems oder eines Desktop-Softwarepakets in der Lage sein, festzustellen, welche Version der Software verwendet wird. Zusätzlich muss der Hersteller ein Repository unterhalten, das alle älteren Versionen der Software, die vertrieben wurden, archiviert. Wenn ein schriftliches Angebot ausreicht, wird empfohlen, sicherzustellen, dass es rechtlich den Lizenzbestimmungen entspricht.
Wann gelten die Lizenzverpflichtungen?
Im Gegensatz zu vielen kommerziellen Softwareprodukten schränken die meisten OSS-Lizenzen die interne Handhabung der Software nicht ein, z.B. durch die Begrenzung der Anzahl der gleichzeitigen Benutzer oder Kerne oder durch vergleichbare Lizenzmetriken. Sie erfordern jedoch die Verteilung der Software, um die Lizenzverpflichtungen auszulösen. Die meisten Lizenzverpflichtungen werden auch nicht ausgelöst, wenn der Zugriff auf die Software als Dienstleistung angeboten wird. Eine Handvoll OSS-Lizenzen erlegen jedoch auch in diesem Fall spezifische Verpflichtungen auf, wie z.B. die AGPL oder die Server Side Public License.
In der Praxis empfiehlt es sich, die OSS-Lizenzanforderungen ohnehin zu erfüllen. Selbst wenn nur Software als Dienstleistung angeboten wird, kann ein Kunde eine Vor-Ort-Lösung benötigen. In diesem Fall würde eine Verteilung von Software herausgegeben, und die entsprechenden Verpflichtungen der OSS-Lizenz würden ausgelöst.
Häufig wird vergessen, dass die Bereitstellung unmodifizierter Software als Teil eines Bündels von Softwarekomponenten auch die Verpflichtungen der zugrunde liegenden OSS-Lizenzen auslöst, beispielsweise bei der Bereitstellung einer Linux-Distribution als Basis für ein eingebettetes System. Vielen OSS-Komponenten fehlen jedoch noch immer die Informationen, die bei der Verteilung zur Verfügung gestellt werden müssen.
Häufig gemachte Fehler
Auch wenn sich viele Unternehmen beim Umgang mit Softwarekomponenten von Drittanbietern um Compliance bemühen, scheitern einige von ihnen in der Praxis. Es kann helfen, Fehler, die häufig gemacht werden, genauer zu betrachten.
Vernachlässigung der formalen Anforderungen
Viele Unternehmen konzentrieren ihre Bemühungen auf die Frage, ob und in welchem Umfang der Copyleft-Effekt gilt. In der Praxis handelt es sich bei den durchgesetzten Lizenzverpflichtungen jedoch meist um formale Verstöße wie fehlende Lizenztexte oder ein fehlendes schriftliches Angebot des Quellcodes.
Die Vermeidung des Copyleft-Effekts kann wesentlich sein. Genauso wichtig ist es jedoch, die Einhaltung der formalen Anforderungen sicherzustellen. Diese mögen auf den ersten Blick weniger kritisch erscheinen, aber da sich die Durchsetzung auf diese formalen Anforderungen konzentriert, sollten sie ein wesentlicher Bestandteil eines Einhaltungsprozesses sein.
Keine rekursive Abtastung
Ein weiterer Fehler besteht darin, sich nur auf die Hauptkomponenten der Software von Drittanbietern zu konzentrieren und die darin enthaltenen Unterkomponenten zu ignorieren. Ein Entwickler ist im Allgemeinen nur an der Hauptkomponente interessiert und kümmert sich nicht um mögliche Unterkomponenten. Unter dem Gesichtspunkt der Compliance ist es jedoch unerheblich, ob der Distributor eine Komponente eines Drittanbieters direkt eingebunden hat oder ob sich die Komponente eines Drittanbieters als Unterkomponente in das Softwarepaket eingeschlichen hat. Jedes Stück Software muss ordnungsgemäß verteilt werden.
In der Praxis handelt es sich bei den durchgesetzten Lizenzverpflichtungen jedoch meist um formale Verstöße wie fehlende Lizenztexte oder ein fehlendes schriftliches Angebot des Quellcodes.
Ein gutes Beispiel ist der Linux-Kernel. Es ist allgemein bekannt, dass der Linux-Kernel unter der GPL-2.0 lizenziert ist. In der Praxis besteht der Kernel jedoch aus Hunderten von Unterkomponenten. Ein Scan des Quellcodes ergibt etwa 90 verschiedene Lizenzen. Auch wenn es unter ihnen Duplikate geben mag, zeigt dies, dass der Linux-Kernel weit davon entfernt ist, ein zusammenhängendes Stück Software zu sein, das nur unter einer Lizenz lizenziert ist. Obwohl dies den Aufwand für die OSS-Konformität drastisch erhöht, wird dringend empfohlen, alle Komponenten von Drittanbietern rekursiv zu durchsuchen, um sicherzustellen, dass keine Unterkomponente übersehen wird.
OSS-Lizenzen sind nur Vorlagen, keine Gesetze
Schließlich ist es ein weiteres gemeinsames Verständnis, dass Lizenzen im Zweifelsfall von ihren Urhebern interpretiert werden, z.B. von der Free Software Foundation im Falle der GPL. Obwohl dies sicherlich der beste Ansatz ist, wenn keine andere Interpretation zur Verfügung steht, ist dies vielleicht nicht der richtige Weg, wenn Urheberrechtsinhaber und Lizenzgeber von Softwarekomponenten ihr eigenes Verständnis solcher Lizenzen zum Ausdruck gebracht haben.
OSS-Lizenzen basieren in der Regel auf Vorlagendokumenten. Die Grundlage ist jedoch nur ein Vorlagedokument und kein Gesetz. Wann immer solche Lizenzen interpretiert werden müssen, muss man einen Blick auf den jeweiligen Willen und das Verständnis der beteiligten Parteien werfen. Und wenn solche Parteien ihr Verständnis in einer Weise ausdrücken, die von der anderen Partei berücksichtigt werden muss, gibt es sehr gute Argumente dafür, dass dieses Verständnis Teil des Lizenzvertrags wird, auch wenn es dem offiziellen Verständnis der Urheber solcher Lizenzen widerspricht.
In der Praxis kann dies zu unterschiedlichen Ergebnissen führen. Nehmen Sie zum Beispiel den Copyleft-Effekt. Bei identischer Handhabung von zwei Softwarekomponenten, die beide unter der GPL-2.0 lizenziert sind, kann das Copyleft in einem Fall ausgelöst werden, während es im anderen Fall nur deshalb nicht ausgelöst wird, weil ein Lizenzgeber das Verständnis geäußert hat, dass der Copyleft-Effekt gegeben ist, während der andere Lizenzgeber dieselbe Lizenz unterschiedlich interpretiert. Folglich wird dringend empfohlen, im Zweifelsfall die Website eines Projekts, die Liste der häufig gestellten Fragen und andere verfügbare Dokumentation zusammen mit der Software in Betracht zu ziehen.
Die Einhaltung von OSS kann schwierig sein. Insbesondere die Informations- und Dokumentationsanforderungen sind schwieriger zu erfüllen, als sie scheinen. Da jedoch die Fälle der Durchsetzung von OSS-Lizenzen in der jüngsten Vergangenheit zugenommen haben, können die Anforderungen an OSS-Lizenzen nicht länger vernachlässigt werden. Es ist unerlässlich, die notwendigen Prozesse einzurichten, um die Lizenzkonformität im Umgang mit OSS zu gewährleisten. Ein wesentliches Element einer solchen Einhaltung ist die Aufstellung einer maßgeschneiderten OSS-Politik. Sobald es einmal verfasst ist, muss seine Einhaltung sichergestellt werden. Sofern die Anzahl der OSS-Komponenten und Software-Updates nicht begrenzt ist, sind Werkzeuge zum Scannen und Verwalten der notwendigen Informationen unumgänglich. Da die Aufgabe der OSS-Konformität jedoch nicht vollständig automatisiert werden kann, muss ein Open-Source-Gremium, das mit Vertretern mit ausreichenden technischen und rechtlichen Kenntnissen besetzt ist, die Ergebnisse der Tools überprüfen und bewerten.
Ein äußerst hilfreiches Werkzeug beim Auffinden von diversen Lizenzen in Softwareprogrammen ist: