„Open Source“-Software in proprietären Produkten

Bei der Entwicklung von eigener, proprietärer Software wird häufig auf Open-Source-Software zurückgegriffen, um „das Rad nicht neu zu erfinden“. Es wird z. B. eine freie JPG-Bibliothek in die eigene Software eingebunden oder der Linux-Kernel in eine Embedded Software oder Firmware einbezogen. Die betreffende Open-Source-Software steht dabei unter eigenen Open-Source-Lizenzbedingungen, die einzuhalten sind. Im Falle von Lizenzverstößen können Dritte u. a. Unterlassung und Schadensersatz verlangen. Im Open-Source-Bereich kann jedoch noch eine gravierendere Folge eintreten: Es kann die gesamte eigene Software kostenlos im Quellcode zu veröffentlichen sein. Dies ist der sog. Copyleft-Effekt oder die „Infizierung“ der eigenen Software durch die Open-Source-Lizenz.

Was ist Open-Source-Software?

Open-Source-Software oder „Freie und Open-Source-Software” (FOSS) ist — im einfachsten Sinne — Software, deren Quellcode allgemein zugänglich ist und kostenlos verwendet werden darf. Für Open-Source-Software wird häufig eine der folgenden Lizenzen verwendet:
  • GPL (GNU General Public License)
  • LGPL (GNU Lesser General Public License)
  • CDDL (Common Development and Distribution License)
  • MPL (Mozilla Public License)
  • EPL (Eclipse License)
  • BSD (Berkeley Software Distribution)
  • APL / ASL (Apache License)
  • MIT / X11
  • AFL-2.1 (Academic Free License)

Copyleft-Effekt / „Infizierung”

Einige Open-Source-Lizenzen sehen einen Copyleft-Effekt vor. Dies bedeutet – mit Unterschieden im Detail –, dass die Open-Source-Software zwar kostenlos bearbeitet und in der eigenen, proprietären Software verwendet und so ein „abgeleitetes Werk“ erstellt werden darf. Manche Open-Source-Lizenzen verlangen im Gegenzug zur kostenlosen Verwendung jedoch, dass auch die eigene Software insgesamt oder teilweise nicht unter eigene Lizenzbedingungen gestellt wird, sondern unter eine Open-Source-Lizenz. Dies kann bedeuten, dass die gesamte eigene, proprietäre Software mit sämtlichem darin befindlichen Know-how kostenlos im Quellcode veröffentlicht werden muss. Dies wird als „Infizierung“ der eigenen Software oder Copyleft-Effekt bezeichnet. Copyleft ist dabei das Antonym zu Copyright. Hinsichtlich der GPL in der Version 2 findet sich die betreffende Regelung in § 2 GPLv2:

„Sie müssen dafür sorgen, daß jede von Ihnen verbreitete oder veröffentlichte Arbeit, die ganz oder teilweise von dem Programm oder Teilen davon abgeleitet ist, Dritten gegenüber als Ganzes unter den Bedingungen dieser Lizenz ohne Lizenzgebühren zur Verfügung gestellt wird.“

Abhängig von den genauen Regelungen der Open-Source-Lizenz werden Lizenzen mit einem starken Copyleft-Effekt, Lizenzen mit einem schwachen Copyleft-Effekt und Lizenzen ohne Copyleft-Effekt unterschieden, z. B.:

starkes Copyleftschwaches Copyleftkein Copyleft
GPLLGPLMIT / X11

Zu beachten ist dabei, dass ein „abgeleitetes Werk“ sehr schnell vorliegen kann. Unter der GPL führt z. B. neben einer statischen Einbindung einer Bibliothek nach überwiegender Meinung auch eine bloße dynamische Verlinkung / Einbindung einer Bibliothek zum Eintritt des Copyleft-Effekts. Auch eine sonstige zu enge Abhängigkeit der eigenen Software von einer — im Beispiel — GPL-Software kann zum Vorliegen eines abgeleiteten Werkes und damit zum Eintritt des Copyleft-Effekts führen.

Um ungewünschte Effekte zu vermeiden, enthält einige Open-Source-Software Zusätze und Ausnahmen zu den eigentlichen Open-Source-Lizenzbedingungen. Hinsichtlich der Compiler-Software GCC ist etwa die „GPL linking exception“ vorgesehen. Speziell hinsichtlich von Java-Anwendungen wird häufig die „GNU Classpath Exception“ aufgenommen. Selbst der Linux-Kernel, der unter der Lizenz GPL steht, enthält eine Ausnahme, damit Anwendungsprogramme keine abgeleiteten Werke darstellen und daher nicht jedes Linux-Anwenderprogramm automatisch durch die GPL „infiziert“ wird.

Lizenzhinweispflichten

Die Open-Source-Lizenzen enthalten zahlreiche weitere Verpflichtungen, die eingehalten werden müssen, um einen Lizenzverstoß zu vermeiden. Viele Open-Source-Lizenzen, wie z. B. die GPL, sehen sogar vor, dass die eigene Lizenz insgesamt entfällt, sobald ein Lizenzverstoß begangen wird.

Eine in fast sämtlichen Open-Source-Lizenzen enthaltene Regelung sind Lizenzhinweispflichten. Damit wird der Verwender verpflichtet, bei jeder Verbreitung der Open-Source-Software bestimmte Hinweise oder Informationen zu erteilen. In zahlreichen Anwendungen sind daher im „About“-Bereich längliche Dokumente verankert, in denen diese Hinweise und Informationen erteilt werden, so z. B. im Betriebssystem Android.

Die Zusammenstellung der Hinweise und Informationen ist häufig mit einem erheblichen Aufwand verbunden, da in der Regel nicht nur eine einzelne Open-Source-Software eingebunden wird. Darüber hinaus sind die meisten Open-Source-Komponenten von anderen Open-Source-Komponenten abhängig und daher auch die Informationen und Hinweise zu diesen Komponenten zu beachten.

Lizenzhinweise als AGB

Die Wiedergabe der Lizenzhinweise beinhaltet häufig die Verpflichtung, auch Haftungsausschlüsse abzudrucken oder anzuzeigen. In aller Regel handelt es sich dabei jedoch um Haftungsausschlüsse, die nach der Maßgabe einer anderen Rechtsordnung formuliert wurden und nach dem deutschen Recht fast durchgängig unwirksam sind. Erfolgt die Wiedergabe der Lizenzhinweise daher derart, dass der Haftungsausschluss als eigene Regelung verstanden wird, würde eine unwirksame AGB-Haftungsregelung verwendet werden. Neben der Folge der Unwirksamkeit drohen damit auch kostenpflichtige Abmahnungen durch Dritte mit Unterlassungs- und Vertragsstrafenverlangen.

Lizenzkompatibilität

In einer Software sollen häufig verschiedene Open-Source-Komponenten miteinander kombiniert werden. Dies ist im Grundsatz zwar möglich. Allerdings sind verschiedene Open-Source-Lizenzen untereinander inkompatibel. Inkompatibel sind z. B. die Lizenzen LGPL und die GPL. Eine Übersicht mit einer — rechtlich unverbindlichen — jeweiligen Einschätzung findet sich auf der Seite gnu.org.

Public Domain License

Die „Public Domain“-Lizenz stellt einen Sonderfall dar. Es handelt sich dabei nicht um eine Lizenz im eigentlichen Sinne, sondern um die nach dem US-Recht mögliche „Entlassung“ einer Software in die „Public Domain“, sodass die Software allgemeinfrei wird. Der Urheber verzichtet gewissermaßen auf seine Urheberrechte. Dies ist nach dem deutschen Urheberrecht allerdings nicht möglich. Obwohl der Urheber daher an sich zum Ausdruck bringt, keine Rechte geltend machen zu wollen, ist der Einsatz von „Public Domain“-Software im deutschen Rechtsraum damit allein noch nicht rechtssicher gelöst.

Duale Lizenzierungen

Einige Open-Source-Software-Hersteller überlassen dem Nutzer die Wahl unter zwei oder mehreren möglichen Open-Source-Lizenzen. Der Verwender kann dann z. B. wählen, ob eine bestimmte Open-Source-Software unter der GPL lizenziert werden soll oder unter der CDDL. Da die Lizenzwahl erhebliche Auswirkungen auf die eigenen Pflichten hat, sollte die Lizenzwahl sorgfältig überlegt und dokumentiert werden.

Entwicklungsumgebung und Entwicklungswerkzeuge

Die eigene, proprietäre Software wird häufig unter Zuhilfenahme von Entwicklungsumgebungen und Entwicklungswerkzeugen aus dem Open-Source-Bereich entwickelt. Damit stellt sich die Frage, ob sich allein die Open-Source-Lizenz der Entwicklungsumgebung oder des Entwicklungswerkzeugs auch auf die eigene Software auswirkt. Diese Frage ist letztlich danach zu beantworten, unter welcher Lizenz die Entwicklungsumgebung oder das Entwicklungswerkzeug genau steht. Als Grundregel dürfte jedoch gelten, dass dann, wenn die Entwicklungsumgebung oder das Entwicklungswerkzeug eigenen Code in das Endprodukt einbindet, auch die Lizenz der Entwicklungsumgebung oder des Entwicklungswerkzeugs zu beachten ist. Häufig erfolgt eine Einbindung von derartigem Code, ohne dass dies den Verantwortlichen bewusst ist. Eine genaue technische Prüfung sollte daher erfolgen.