Softwareentwicklern stehen heutzutage mächtige Bibliotheken und Frameworks zur Verfügung, die den Entwicklungsprozess signifikant beschleunigen (vgl. auch die zunehmende Verbreitung von Low-Code-Plattformen) und vermeiden, dass Softwareentwickler „das Rad neu erfinden“ müssen. Neben proprietären Bibliotheken wird auch Open Source Software eingesetzt, die bei der Softwareentwicklung nicht mehr wegzudenken ist.

Zur Klarstellung: Quelloffene Software (oder: Open Source Software) ist hierbei nicht identisch mit freier Software. Sind allerdings beide Kriterien erfüllt, spricht man von Free Open Source Software (FOSS). Um Ihnen eine Vorstellung von der Verfügbarkeit bzw. Verbreitung von Open-Source-Komponenten zu geben: Der Open Source Scanner-Anbieter WhiteSource (Erläuterung weiter unten) beziffert die Anzahl an verfügbaren OSS-Komponenten auf 155 million open source components (both source and binary) in languages such as Java, Ruby, and Python, and another 11 billion open source files in languages such as C/C++, Javascript, PHP, and ObjectiveC . Das ist beeindruckend.

Wenn Software ausschließlich für den Eigenbedarf entwickelt wird, dann kann die Nutzung von FOSS als unkritisch gelten. Doch bereits wenn Software innerhalb eines Konzerns verteilt wird oder wenn ein (Software)Produkt entwickelt wird, welches weiter vertrieben wird, dann ist auf eine Einhaltung der Lizenzbedingungen zwingend zu achten; nicht zuletzt kann dies das das Design der Softwarearchitektur beeinflussen. Andernfalls kann es beim Verstoß von Lizenzbedingungen zu Unterlassungsansprüchen oder Strafen kommen (Vgl. weiter unten).

Es sei der Vollständigkeit halber auch darauf hingewiesen, dass im Rahmen von M&A, IPO und Ähnlichem sogenannte Open Source Software Audits (OSS Audits) die Regel sind, in der im Rahmen der Due Diligence geprüft wird, ob die Lizenzbedingungen von genutzter Open Source Software eingehalten wird.

FOSS kann dabei sehr unterschiedlichen Lizenzbestimmungen unterliegen, und tatsächlich unterscheiden sich diese Lizenzen sehr stark untereinander. In nachfolgendem Artikel werden einige der wesentlichen Open-Source-Lizenzen vorgestellt sowie die lizenzrechtlichen Herausforderungen, die sich bei Nutzung von FOSS ergeben.

Lizenzbestimmungen von Open Source Software: Die Grundlagen

Open-Sourcen-Lizenzen lassen sich zunächst einmal danach kategorisieren, inwieweit diese eine sogenannte Copyleft-Klausel enthalten:

Lizenzen mit einer strengen Copyleft-Klausel: Diese verlangen, dass sämtliche Bearbeitungen bei ihrer Weitergabe der Ursprungslizenz zu unterstellen sind. Wird eigene entwickelte Software mit einer Open Source Software mit Copyleft-Effekt weitergegeben, besteht das Risiko, dass (im worst case) auch die eigenentwickelte Software den Lizenzbedingungen der Open Source Software unterstehen muss. Anders formuliert: Damit könnte die Pflicht entstehen, den Source Code eigenentwickelter Software offenlegen zu müssen!

Wikipedia erläutert den Grundgedanken zu Copyleft wie folgt: Copyleft kam ursprünglich bei Lizenzen für freie Software auf. Dort erzwingt es, dass Fortentwicklungen eines freien Ur-Programms wiederum frei sind und frei bleiben. Es verhindert so, dass Lizenznehmer das Programm durch proprietäre Erweiterungen in die proprietäre Domäne überführen.

Die am weitesten verbreitete Copyleft-Lizenz ist die GNU General Public License (hier: 3.0). Wer ein Blick in die Lizenzbestimmungen wirft, kann die Philosophie des Copyleft aus erster Hand nachvollziehen; die relevante Passage bezieht sich auf „modifizierte Versionen“ (also: Weiterentwicklungen):

You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

Hierzu gibt es zwar eine Einschränkung zur Anwendung dieser Copyleft-Folgen – ABER: Es gibt Unwägbarkeiten bei der Auslegung und damit mindestens ein lizenzrechtliches (Rest)Risiko: A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

Aufgrund des aufgezeigten rechtlichen (Rest)Risikos werden Open-Source-Komponenten, die der GNU General Public License unterliegen, in nicht wenigen Softwarefirmen schlicht gar nicht mehr eingesetzt.

Lizenzen mit einer beschränkten Copyleft-Klausel: Lizenzen mit beschränktem Copyleft-Effekt haben ebenfalls einen Copyleft-Effekt, der aber Ausnahmen von der Lizenzierungspflicht von Bearbeitungen zulässt.

Lizenzen ohne Copyleft-Klausel (Non-Copyleft-Lizenzen): Non-Copyleft-Lizenzen gestatten die Lizenzierung von Weiterentwicklungen unter abweichenden Lizenzbedingungen. Allerdings können sie Mindestpflichten enthalten, die in jedem Falle einzuhalten sind.

Grundsätzlich gilt, dass bei Weitergabe von Open Source Software an Dritte mindestens folgende Voraussetzungen einzuhalten sind: (a) Der Dritte wird auf die Verwendung der Open Source Software unter Nennung des Rechteinhabers hingewiesen und (b) die Lizenzbedingungen werden mitgegeben (also: Offenlegungs- und Hinweispflichten). Für die GNU General Public License heißt es konkret: You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program..

Lizenzbestimmungen von Open Source Software: Lizenzkompatibilität

Eine spezifische Herausforderung bei der Nutzung von FOSS-Komponenten bzw. genauer: mehrerer FOSS-Komponenten ist die sogenannte Lizenzkompatibilität. Das heißt: Die Möglichkeit, FOSS-Komponenten unter abweichenden Lizenzbedingungen zu einem neuen Programm zu kombinieren, wobei alle Lizenzbedingungen widerspruchsfrei erfüllt werden. Der einfachste Fall besteht darin, dass FOSS-Komponenten kombiniert werden, die alle einer Non-Copyleft-Lizenz unterliegen. Hier sind schlimmstenfalls Mindestanforderungen bei der Lizenzvergabe zu erfüllen, was in der Regel unproblematisch ist. Daher können Software-Komponenten unter Non-Copyleft-Lizenzen untereinander beliebig kombiniert werden, natürlich auch mit proprietärer Software.

Copyleft-Software („streng“ oder „mit beschränkter Copyleft-Klausel“) wiederum kann zumeist nicht mit anderer Copyleft-Software zu einem neuen Programm verbunden werden, wenn nicht eine besondere Kompatibilitätsklausel dies erlaubt, weil diese neue Software dann nicht gleichzeitig unter abweichenden Lizenzen angeboten werden kann.

Wenn Copyleft-Software („streng“ oder „mit beschränkter Copyleft-Klausel“) mit Non-Copyleft-Software verbunden werden soll, ist in der Regel eine Einzelfallprüfung erforderlich. Wie so oft „kommt es darauf an …“. Betrachten wir einmal die Kompatibilität zwischen Non-Copyleft-Lizenzen und einer Lizenz mit beschränktem Copyleft für den konkreten Fall der Mozilla Public License 2.0 (MPL 2.0). Mozilla Public License 2.0 (MPL 2.0) ist hierbei eine Lizenz mit einem beschränkten Copyleft. Hier gilt: Nicht alle abgeleiteten Werke sind dieser Lizenz zu unterstellen, sondern nur diejenige Software, die als “Modification” im Sinne des Paragraphen 1.10 der Lizenzbedingungen anzusehen ist. Im Wortlaut heißt es:

1.10. “Modifications”
means any of the following:
(a) any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or
(b) any new file in Source Code Form that contains any Covered Software.

Diese MPL 2.0-Lizenz stellt also auf das rein formale Element ab, ob die Software in getrennten oder in einheitlichen Dateien vorliegt, so dass Hinzufügungen und andere Komponenten nicht der Ursprungslizenz unterstellt werden müssen, wenn sie in eigenen Dateien vertrieben werden. Die Mozilla Public License 2.0 (oder auch: Mozilla Public License 1.1) ist daher grundsätzlich mit Non-Copyleft-Lizenzen kompatibel, wenn die Bedingung erfüllt ist, dass der Code nicht in dieselben Dateien integriert wird (z.B. dynamische Verlinkung).

Betrachten wir einen weiteren Fall zur Kategorie Kompatibilität zwischen Non-Copyleft-Lizenzen und einer Lizenz mit beschränktem Copyleft, nämlich die GNU Lesser General Public License 3.0 („LGPL-3.0″). Auch hierbei handelt es sich um eine Lizenz mit beschränktem Copyleft. Anders als die MPL 2.0 ist das Copyleft aber nicht formal auf Dateibasis ausgestaltet, sondern nimmt konkret darauf Bezug, ob die Software als Bibliothek verwendet wird. LGPL-3.0 gestattet die Vervielfältigung und Verbreitung der Programmbibliotheken, die unter der LGPL-3.0 lizenziert sind, ohne dass das auf die Bibliotheken zugreifende Programm selbst der Ursprungslizenz unterstellt werden muss. Nur Änderungen an der Bibliothek selbst müssen wieder der LGPL unterstellt werden.

Tipps für das Lizenz- und Compliance Management bei Open Source Software

Für Unternehmen, die Open Source Software für eigene Softwareprodukte häufig einsetzen, empfiehlt sich die Einrichtung eines Managers, der das Lizenz- und Compliance Management beim Einsatz von Open Source Software verantwortet.

Der erste Schritt im Rahmen eines solchen Lizenz- und Compliance Managements besteht ja darin, eine Bestandsaufnahme der genutzten FOSS zu machen und zu bestimmen, welchen Lizenzbedingungen die genutzten FOSS-Komponenten unterliegen. Im Rahmen von OSS Audits werden hierfür auch sogenannte OSS Scanner eingesetzt, etwa OSS Discovery Project (Open Source Tool unter der Affero GNU Public License), Black Duck (ein Pionier im Bereich OSS Scanner, kommerzielles Tool) oder Flexera (vormals: Palamida, kommerzielles Tool). Diese Tools identifizieren nicht nur eingesetzte Open Source, sondern ermitteln auch (mögliche) Lizenzinkompatibilitäten. Der Anbieter WhiteSource geht einen Schritt weiter und integriert seine Lösung direkt in den Software Development Lifecylce (SDLC).

Zu rechtlichen Risiken

Wer gegen Lizenzbedingungen verstößt, riskiert eine Klage. Ein Beispiel für eine erfolgreiche Klage aufgrund Verletzung von Lizenzbestimmungen / GNU General Public License, Version 2 wurde vor dem Landgericht Hamburg (Juni 2013) verhandelt. Hier wurde der Beklagte verurteilt zu einer Vertragsstrafe in Höhe von 5.000 EUR zuzüglich vorgerichtlichen Rechtsverfolgungskosten in Höhe von ca. 2.000 EUR. Weitere Fälle von Gerichtsverfahren im Zusammenhang mit dem Urheberrecht von Open Source Software finden sich hier: Urteile zu Urheberrecht, Open-Source.

Das Risiko weitergehender Schadensersatzansprüche ist indes eher gering, vergleiche dazu die anwaltliche Kommentierung zu einer Entscheidung des Oberlandesgerichts Hamm in einem Rechtsstreit wegen Urheberrechtsverletzung: Schadensersatz bei Verletzung einer Open Source Lizenz: Das Gericht lehnte hier den Anspruch auf Schadensersatz ab, da der Klägerin kein Schaden entstanden sei; die Lizenzierung der Software unter der GNU General Public License müsse dahingehend ausgelegt werden, dass die Klägerin auf die monetäre Verwertung ihres ausschließlichen Nutzungsrechts vollständig verzichtet habe.

Sebastian Zang
Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.