Open Source
Praxisprobleme der Open-Source-Lizenzierung
2.02.2010 | Open Source | von Carsten Gerlach
Wer eigene Software unter eine Open-Source Lizenz stelle möchte, hat angesichts der Vielzahl verschiedener Open-Source-Lizenzen die Qual der Wahl: allein die Open Source Initiative (OSI) hat über 50 verschiedene Lizenzen als echte Open-Source-Lizenzen zertifiziert (http://www.opensource.org/licenses). Der potentielle Lizenzgeber steht vor dem Problem, die zu seinen Zielvorgaben am besten passende Lizenz auszuwählen oder möglicherweise sogar eigene Lizenzbedingungen zu entwerfen. Dabei müssen neben wirtschaftlichen Zielvorgaben technische und lizenzrechtliche Probleme berücksichtigt werden, die nicht auf den ersten Blick offensichtlich sind.
Möchte der Lizenzgeber mit der Open-Source-Lizenzierung die Weiterentwicklung der Software durch eine Entwicklergemeinschaft fördern, sollte er sich für eine bekannte Lizenz entscheiden und nach Möglichkeit keine eigenen Lizenzbedingungen erstellen. Die Erstellung eigener Lizenzbedingungen oder die Wahl einer nicht verbreiteten Lizenz kann die Entwicklung und Adaption durch eine Community behindern. Softwareentwickler und Open-Source Aktivisten sind in der Regel keine Juristen und haben begreiflicherweise wenig Interesse, neue Lizenzklauseln verstehen zu müssen.
I. Lizenzprobleme bei der Integration von Drittkomponenten
Da i.d.R. bei der Softwareentwicklung auf existierende Standardkomponenten zurückgegriffen wird, kann es schon im Entwicklungsstadium begründete lizenzrechtliche Komplikationen geben.
Es stellt sich die Frage, ob die Lizenzbedingungen der Komponenten eine Lizenzierung des Endprodukts unter einer Open-Source-Lizenz überhaupt zulassen oder eine Festlegung auf bestimmte Lizenzen oder Lizenztypen erzwingen.
Wenn Komponenten verwendet werden, die unter einer proprietären Lizenz stehen, ist eine Lizenzierung des Endprodukts unter einer Open-Source-Lizenz i.d.R. nicht möglich. Open-Source-Lizenzen fordern Offenlegung und Weitergabe des Quelltextes sowie die Einräumung von Bearbeitungsrechten an die Allgemeinheit, was proprietäre Lizenzen naturgemäß nicht gestatten
Auch bei der Verwendung von Open-Source-Komponenten können lizenzrechtliche Schwierigkeiten entstehen. Die Lizenzbedingungen verschiedener Einzelkomponenten müssen eine Integration unter einheitlichen Lizenzbedingungen zulassen. Problematisch ist hierbei das sog. Copyleft-Prinzip. Copyleft-Lizenzen stellen besondere rechtliche Anforderungen an die Weiterverwendung von Komponenten und werfen das Problem der Lizenzkompatibilität auf.
1. Copyleft- und Permissive-Lizenzen
Es gibt grob zwei Kategorien von Open-Source Lizenzen:
- Lizenzen mit Copyleft-Klauseln
Copyleft-Klauseln verlangen, dass alle Bearbeitungen und abgeleiteten Werke einer Software unter den gleichen Lizenzbedingungen stehen wie das Ursprungswerk. Copyleftklauseln stellen also sicher, dass Weiterentwicklungen und Bearbeitungen einer Software nicht unter geänderten Lizenzbedingungen vertreiben werden. Prototyp ist die GNU General Public LIcense (GPL) oder die EuPL, eine von der Europäischen Kommission entwickelte Lizenz.
- Lizenzen ohne Copyleft-Klauseln
Diese permissive Lizenzen enthalten keine derartigen Beschränkungen. Bearbeitungen und Weiterentwicklungen einer permissive-lizenzierten Software können unter nahezu beliebigen Lizenzbedingungen verbreitet werden. Die bekannteste Permissive-Lizenz ist die BSD-Lizenz.
Neben den Copyleft und den Permissive Lizenzen existieren diverse Mischformen. Praktisch bedeutsam ist vor allem die LGPL, die den Copyleft-Effekt für bestimmte Verwendungsfälle einschränkt.
2. Lizenzkompatibilität
Wird Software unter Verwendung einer Copyleft-Lizenzierten Komponente entwickelt, erzwingt die Copyleft-Klausel die Lizenz des Endprodukts. Das Endprodukt muss unter der gleichen Lizenz stehen wie die benutzte Komponente. Man nennt dies auch den viralen Effekt der GPL, die auf das Endprodukt ausstrahlt. Das bedeutet, GPL-Komponenten können ein Softwareprojekt in lizenzrechtlicher Hinsicht "infizieren". Copyleft Lizenzen sind in der Regel nicht kompatibel zueinander. Die Verwendung einer Copyleft-Lizenzierten Komponente schließt somit die Verwendung anderer Komponenten aus, die unter anderen Copyleft-Lizenzbedingungen stehen. Dagegen ist die Verwendung von Permissive-lienzierten Komponenten unproblematisch, da das Endprodukt unter beliebigen Lizenzbedingungen vertrieben werden kann.
3. Lösungsmöglichkeiten
Zur Lösung lizenzrechtlicher Kompatibilitätsprobleme bieten sich mehrere Wege an. Neuere Lizenzen weichen das strenge Copyleft-Prinzip zugunsten einer größeren Kompatibilität auf. Für den praktisch wichtigen Fall der Verwendung von Bibliotheken ist in der LGPL-Lizenz eine Ausnahme vorgesehen. Auch die gleichzeitige Verwendung unterschiedlicher Lizenzbedingungen (dual licensing) ist ein möglicher Ausweg.
Entscheidend ist, dass potentielle lizenzrechtliche Schwierigkeiten frühzeitig erkannt und ggf. schon bei der Entwicklung der Software berücksichtigt werden.
a. Kompatibilitätsklauseln
Kompatibilitäts-Klauseln weichen das strenge Copyleft-Prinzip auf. Sie erlauben, dass Bearbeitungen oder abgeleitete Werke nicht nur unter den Bedingungen der Ausgangslizenz, sondern auch unter bestimmten anderen, "kompatiblen" bzw. zusätzlichen Lizenzbedingungen stehen dürfen (vgl. Ziff. 7 der GPL v. 3, Ziff. 5 und dem Appendix der EuPL v. 1.1). Die EuPL zählt in einer Anlage die kompatiblen Lizenzen auf. Die GPL-Lizenz v. 3 fehlt bislang in dieser Aufzählung, was allerdings daran liegt, dass die GPL v. 3 zum Zeitpunkt der Veröffentlichung der EuPL v 1.1 noch nicht eingeführt war.
Ausdrückliches Ziel der Kompatibilitätsklausel ist die Herstellung von Kompatibilität der EuPL mit der GPL. Die Intergration von EuPL und GPL Lizenzierten Komponenten ist dann möglich, da die Kompatibilitäts-Klausel der EuPL eine Lizenzierung des Endprodukts unter der GPL erlaubt.
b. Bibliotheken und LGPL
Für den praktisch äußerst bedeutsamen Fall der Verwendung von Bibliotheken (libraries) sieht die LGPL ausdrücklich eine Ausnahme vom strengen Copyleft-Prinzip der GPL vor. Die LGPL wurde eigens zur Vermeidung der angesprochenen Kompatibilitätsprobleme erstellt. Die LGPL regelt für den Fall der Nutzung einer LGPL-lizenzierten Bibliothek zwar gewisse Einschränkungen, im Ergebnis ist aber ein Vertrieb des Endprodukts unter beliebigen Open-Source-Lizenzen möglich. Wird das Endprodukt getrennt von der Bibliothek vertrieben, ist sogar ein Vertrieb unter proprietären Lizenzbedingungen möglich, da die LGPL den Fall der reinen Benutzung einer LGPL-lizenzierten Bibliothek nicht erfasst.
c. Dual Licensing
Ein Urheber kann seine Software parallel unter verschiedenen Lizenzbedingungen zur Verfügung stellen. So kann eine Software beispielsweise unter verschiedenen Open-Source-Lizenzen oder zugleich unter einer Open-Source-Lizenz und einer proprietären Lizenz verbreitet werden. Dieses Lizenzmodell wird als "Dual Licensing" bezeichnet.
Sind Kompatibilitätsprobleme absehbar, können die Autoren der verwendeten Komponenten gebeten werden, ihre Komponenten auch unter passenden Lizenzbedingungen im Wege des dual licensing zur Verfügung zu stellen. Aus praktischen Gründen funktionieren dual-licensing-Anfragen jedoch nur, wenn ein einziger oder nur wenige Urheber bzw. Rechteinhaber für die jeweilige Komponente vorhanden sind: jeder Miturheber muss dem dual licensing zustimmen.
Dual Licensing bietet für Lizenzgeber kreative Möglichkeiten im Umgang mit Open-Source-Lizenzen. So ist denkbar, dass ein Hersteller die jeweils aktuelle Version seiner Software unter einer proprietären Lizenz vertreibt, ältere Versionen aber unter einer Open-Source-Lizenz freigibt. So ist es möglich, die Vorteile einer Freigabe der Quellcodes mit der Möglichkeit zur Erhebung von Lizenzgebühren für die aktuelle Version zu kombinieren.
d. Trennung von Komponenten
Copyleft-Klauseln greifen ein, wenn eine Bearbeitung oder ein abgeleitetes Werk (sog. Derivative Work) einer Copyleft-lizenzierten Software erstellt wird. Es ist äußerst umstritten in welchen Fällen der Copyleft-Effekt der GPL eingreift, wenn eine Komponente nicht verändert wird, sonder nur unverändert in ein Endprodukt integriert wird.
- Formale Kriterien: Wenn Komponenten in einem einheitlichen ausführbaren Programm zusammengefasst werden, z.B. durch statisches Verlinken von Bibliotheken. Ein von einer Komponente "abgeleitetes Werk" entsteht also immer dann, wenn die Komponente formal Bestandteil eines einheitlichen Endprodukts wird.
- Inhaltliche Kriterien: Bilden die Komponenten eine funktionale und strukturelle Einheit mit dem Endprodukt, ist dieses unabhängig vom Vorliegen eines formal einheitlichen Werkes gleichfalls ein "abgeleitetes Werk" im Sinne der GPL. Auch die Verwendung dynamisch verlinkter Bibliotheken kann zur Entstehung eines "abgeleiteten Werkes" und damit zum Eingreifen des Copyleft-Effekts führen.
- Gestaltungsmöglichkeiten: Handelt es sich bei der Komponente und dem Endprodukt um formal getrennte Elemente, die lediglich miteinander kommunizieren, erfasst der Copyleft-Effekt das Endprodukt dagegen nicht. Hier bestehen allerdings angesichts der unklaren Rechtslage erhebliche Unsicherheiten und Risiken.
II. Kommerzielle Nutzung der Software durch Dritte
Bei der Wahl der Lizenz ist die Frage, in welchem Umfang eine kommerzielle Nutzung der Software durch Dritte gewünscht ist. Dabei ist nicht nur Nutzung, sondern auch Weiterentwicklung und Bearbeitung durch Dritte zu kommerziellen Zwecken zu berücksichtigen.
1. Benutzung der Software zu kommerziellen Zwecken
Open-Source-Lizenzen erlauben keine Einschränkung hinsichtlich der Art der Nutzung oder in Hinblick auf bestimmte Personen oder Nutzergruppen. Der Lizenzgeber hat bei Verwendung einer Open-Source-Lizenz keine Möglichkeit zu verhindern, dass seine Software von Dritten zu kommerziellen Zwecken genutzt wird.
Ist eine kommerzielle Benutzung der Software durch Dritte nicht erwünscht, hilft nur die Erstellung eigener Lizenzbedingungen. Es handelt sich dann aber nach allgemeinem Verständnis nicht mehr um eine Open-Source-Lizenz.
2. Kommerzialisierung durch Dritte
Der Lizenzgeber legt mit einer Open-Source-Lizenz den Quellcode der Software offen und räumt der Allgemeinheit Bearbeitungsrechte ein. Dritte können daher die Software weiterentwickeln und bearbeiten oder Teile davon in eigene Produkte integrieren, diese neuen Produkte aber unter proprietären Lizenzbedingungen vertreiben.
Eine solche kommerzielle Aneignung der Software durch Ditte lässt sich nur durch die Verwendung von Copyleft Lizenzen vermeiden. Nutzt ein Dritter Copyleft-lizenzierte Software als Basis für eigene Weiterentwicklungen, muss er diese Weiterentwicklungen unter den ursprünglichen (Open-Source-)Lizenzbedingungen vertreiben. Er kann seine Weiterentwicklungen nicht unter proprietäre Lizenzbedingungen stellen.
Dagegen erlauben permissive Lizenzen wie z.B. die BSD-Lizenz, dass Weiterentwicklungen unter beliebigen Lizenzbedingungen vertrieben werden können. So muss auch insbesondere der Quelltext von Weiterentwicklungen nicht offengelegt werden: auch eine Weiterverbreitung im Binärformat ohne Freigabe des Quelltextes ist möglich. Ein Dritter könnte also aufbauend auf der ursprünglichen Software ein weiterentwickeltes Produkt herstellen und dieses unter einer proprietären Lizenz vertreiben.
3. Integration und Interoperabilität
Die Integration der Software in kommerzielle Produkte Dritter kann auch ein wirtschaftlich gewünschtes Ergebnis sein. In diesen Fällen wäre die Verwendung einer Copyleft-Lizenz kontraproduktiv. Um Dritte zur Weiterentwicklung und Integration der Software zu ermutigen, sollen ihnen möglichst keine Beschränkungen in Hinblick auf die spätere Lizenzierung ihrer Produkte auferlegt werden. Zur Förderung der kommerziellen Nutzung und Integration des Quellcodes bietet sich daher die Verwendung von Permissive-Lizenzen an, die eine Lizenzierung abgeleiteter Werke unter beliebigen Bedingungen zu lassen. Die Gewährleistung von Interoperabilität durch Veröffentlichung von Schnittstellen- oder Formatdokumentation ist lizenzrechtlich unproblematisch. Die Entwicklung von Software unter Verwendung solcher Informationen unterliegt keinen lizenzrechtlichen Beschränkungen und hat auf die Lizenzwahl keinen Einfluss.
III. Anforderungen des nationalen Rechts
Die meisten Open-Source-Lizenzen liegen nur in englischer Sprache vor. Sofern Übersetzungen vorliegen, sind diese in der Regel inoffiziell, d.h. sie dienen nur zu Informationszwecken und werden nicht Vertragsgrundlage. Darüber hinaus enthalten die meisten Open-Source-Lizenzen weder Rechtswahl- noch Gerichtsstandsklauseln.
Es stellt sich an diesem Punkt die Frage, ob die Erstellung einer eigenen, an die Verhältnisse deutschen und europäischen Rechts angepassten Lizenz die Position des Lizenzgebers entscheidend verbessert.
1. Sprache
An der wirksamen AGB-rechtlichen Einbeziehung englischer Vertragsbedingungen bestehen zumindest gegenüber Verbrauchern Zweifel. Jedoch lässt sich der Nutzer im Regelfall ohnehin willentlich auf die englische Sprache ein, z.B. über den Download der Software von englischsprachigen Webites oder die faktische Inanspruchnahme der durch die Lizenz gewährten Nutzungsrechte, so dass von einer wirksamen Einbeziehung der englischsprachigen Lizenzbedingungen auszugehen ist. Ein wesentlicher Vorteil aus der Erstellung eigener, deutschsprachiger Lizenzbedingungen ergibt sich daher für den Lizenzgeber nicht. Ist eine mehrsprachige Vertragsbedingung dennoch von Bedeutung, kommt die EuPL in Frage, die auch in einer deutschen Übersetzung veröffentlicht ist.
2. Rechtswahl
Die anwendbare Rechtsordnung bestimmt sich nach allgemeinen kollisionsrechtlichen Grundsätzen, da die meisten Open-Source-Lizenzen keine Rechtswahlklausel enthalten.
Die dinglichen Regelungen der Lizenz unterfallen zwingend dem Urheberrechtsstatut, so dass das Schutzlandprinzip Anwendung findet. Eine abweichende Rechtswahl ist nicht möglich.
Für die schuldrechtlichen Regelungen der Lizenz gilt das Vertragsstatut und damit das Prinzip der freien Rechtswahl nach Art. 27 EGBGB das Recht des Staates Anwendung, mit dem der Vertrag die engste Verbindung aufweist. Dies ist im Zweifel das Recht des Lizenzgebers, da die Einräumung der Nutzungsrechte die charakteristische Leistung des Lizenzvertrags im Sinne der Art. 28 Abs. 2 EGBGB ist. Allerdings sind zugunsten von Verbrauchern gem. Art. 29 Abs. 1 EGBGB die zwingenden Verbraucherschutzregelungen des Staates anwendbar, in dem der Verbraucher seinen gewöhnlichen Aufenthaltsort hat. Diese Regelungen lassen sich auch durch eine Rechtswahlklausel nicht ausschließen.
Eine Rechtswahlklausel würde also nur in eingeschränktem Umfang praktische Wirkung entfalten. Denn zum Einen sind die zentralen urheberrechtlichen Regelungen einer Rechtswahl entzogen und zum Anderen finden zwingende ausländische Verbraucherschutzregelungen trotz abweichender Rechtswahl Anwendung.
3. Haftung und Gewährleistung
Die meisten Open-Source-Lizenzen enthalten einen pauschalen und vollständigen Ausschluss jeglicher Haftung und Gewährleistung. Ein solcher pauschaler Haftungs- und Gewährleistungsausschluss ist nach ganz herrschender Meinung gem. § 309 Nr. 8b aa) BGB, § 276 Abs. 3 BGB unwirksam.
Haftung und Gewährleistung richten sich daher nach den gesetzlichen Regelungen. Dabei ist das Schenkungsrecht in Bezug auf den Lizenzgeber unabhängig von Vertriebsmodell und Distributionsweg anwendbar. Die Unwirksamkeit des vollständigen Haftungs- und Gewährleistungsausschlusses in den gängigen Open-Source-Lizenzen hat damit keine praktische Bedeutung. Der Lizenzgeber haftet nach den gesetzlichen Vorschriften der §§ 521, 523, 524 BGB. Dieser gesetzliche Haftungs- und Gewährleistungsmaßstab ist für den Lizenzgeber wesentlich günstiger als marktübliche Haftungs- und Gewährleistungsklauseln in proprietären Lizenzverträgen.
IV. Praxishinweise
Bei der Entscheidung für eine Open-Source-Lizenz sind zu berücksichtigen:
- die wirtschaftlichen und technischen Vorgaben des konkreten Projekts und
- in welchem Umfang eine spätere kommerzielle Nutzung der Software durch Dritte erwünscht ist.
Die Erstellung eigener Lizenzbedingungen ist für den Lizenzgeber dagegen aus praktischen Gründen nur selten empfehlenswert.
