Seite 2: OSS und Copyleft am Beispiel der GPLv3

Inhaltsverzeichnis

Die Funktionsweise und urheberrechtliche Bedeutung von Copyleft lässt sich anhand der bekannten GNU General Public License, seit 2007 in der Version 3 (GPLv3) veröffentlicht, anschaulich erläutern.

Den rechtlichen Ausgangspunkt für Lizenzen nach deutschem Recht markieren §§ 2 Abs. 1 Nr. 1; 69a ff. Urheberrechtsgesetz (UrhG): Wer eine Software entwickelt, erwirbt – auch ohne Eintragung – das Urheberrecht an der Software. Der Urheber kann im Rahmen des gesetzlichen Schutzumfangs frei entscheiden, was er oder andere mit der Software machen dürfen. Kern von OSS ist es nun, dass der oder die Urheber Dritten (Entwicklern und Nutzern) in einer Lizenzvereinbarung relativ weitgehende Nutzungsrechte nach § 31 Abs. 1, 2 UrhG einräumen.

Die GPL als eine der bekanntesten solcher Lizenzvereinbarungen wird von deutschen Gerichten auch als Lizenzvertrag anerkannt. Nicht unproblematisch ist in diesem Zusammenhang, dass die GPL nur in der englischen Originalversion rechtsverbindlich sein soll. Es existiert zwar eine deutschsprachige Übersetzung, dennoch soll der englischsprachige Text maßgeblich sein. Das stellt Verwender bei Rechtsstreitigkeiten in Deutschland vor verschiedene Herausforderungen, zum einen hinsichtlich der Auslegung einzelner Klauseln, zum anderen, weil der Lizenztext vor deutschen Gerichten übersetzt werden muss, da die Gerichtssprache nach § 184 S. 1 Gerichtsverfassungsgesetz (GVG) grundsätzlich Deutsch ist.

Die Grundzüge der GPLv3 sind jedoch relativ klar, daher lässt sich die Lizenz auch in Deutschland verwenden. Zu den Kernelementen beim Vertrieb von OSS nach GPLv3 gehören:

• das Anbringen von Urhebervermerken (Ziffer 4);
• die Übergabe (oder Verlinkung) des Lizenztexts (Ziffern 4, 5);
• ein Änderungsvermerk, soweit der Quelltext verändert wurde (Ziffer 5);
• die Zugänglichmachung des Quelltexts (Ziffer 6);
• die Wahrung des Copyleft-Prinzips (Ziffer 10);
• die Berücksichtigung des Lizenzgebührenverbots (Ziffer 10);
• eine Lizenzierung etwaiger eigener Patente an den Nutzer der Software (Ziffer 11) sowie
• ein Gewährleistungsausschluss (Ziffer 15).

Bei Nichtbeachtung der genannten Bedingungen können Rechteinhaber urheberrechtliche Beseitigungs- und Unterlassungsansprüche nach § 97 UrhG geltend machen – gegebenenfalls ist auch mit wettbewerbsrechtlichen Abmahnungen zu rechnen. Im schlimmsten Fall drohen darüber hinaus sogar strafrechtliche Sanktionen nach §§ 106; 108a UrhG für die unerlaubte Verwendung von OSS. Allerdings sind entsprechende Fälle nur selten strafrechtlich relevant, unter anderem, da es regelmäßig an dem erforderlichen vorsätzlichen Handeln fehlt.

Vergleichbare Bedingungen finden sich nicht nur in der GPLv3, sondern auch in vielen weiteren OSS-Lizenzen. Diese Bedingungen zu erfüllen, ist in der Praxis teilweise durchaus herausfordernd. Zur OSS-Compliance ist tatsächlich zunächst zu klären, welche Open-Source-Komponenten im Rahmen der unterschiedlichen Entwicklungen im Unternehmen zum Einsatz kommen. Nur so lässt sich identifizieren, welche OSS-Lizenzen (in welcher Version) Anwendung finden. Dies ist notwendig, um die einschlägigen Lizenztexte bei der Veröffentlichung übergeben zu können. Darüber hinaus ist genau zu dokumentieren, welche konkreten Änderungen an der OSS vorgenommen wurden, um aussagekräftige Änderungsvermerke anfügen zu können.

Es gibt zwar mittlerweile leistungsfähige Tools, um OSS-Komponenten im eigenen Code aufzuspüren. Da es mitunter dennoch ausgesprochen mühselig ist, alle OSS-Komponenten im Nachhinein zu finden, empfiehlt es sich in der Regel, bereits vom Beginn der Entwicklung an ein umfassendes Verzeichnis über die OSS anzulegen und zu pflegen. In die fertige Distribution lassen sich dann auch einfacher die erforderlichen Urheberrechtsvermerke einfügen. Die GPLv3 verlangt „angemessene“ Urheberechtsvermerke und stellt dafür Muster zur Verfügung (Im Abschnitt "How to Apply These Terms to Your New Programs" der GPLv3, lässt jedoch durchaus Spielräume hinsichtlich der konkreten Gestaltung. In der Regel reicht es aus, im Quelltext oder in den Einstellungen des Programms eindeutige Vermerke mit Hilfe der GPLv3-Vorlagen zu hinterlegen.

Zudem ist der Quelltext unter den Bedingungen der GPLv3 zu veröffentlichen. Dabei ist grundsätzlich dasselbe Medium zu wählen, über das der Objekt-Code vertrieben wird. Bei physischen Medien muss der korrespondierende Quelltext auf demselben Medium gespeichert sein. Bei OSS, die zum Download bereit liegt, genügt es, den Quelltext ebenfalls online zur Verfügung zu stellen. Dem Grundgedanken freier Software folgend ist nach GPLv3 außerdem rechtlich wie tatsächlich sicherzustellen, dass die Nutzungsrechte, insbesondere das Recht zur Vervielfältigung, Verbreitung und Veränderung, nicht eingeschränkt sind. Darüber hinaus ist der beschriebene Copyleft-Effekt zu beachten, das heißt, jede Weiterentwicklung ist ebenfalls unter GPLv3-Bedingungen zu verbreiten.

Schließlich sieht die GPLv3 einen relativ weiten Gewährleistungsausschluss für die Qualität und Leistungsfähigkeit des Programms vor – "soweit dies gesetzlich zulässig ist". Solch ein Gewährleistungs- beziehungsweise Haftungsausschluss entstammt dem US-amerikanischen Recht, ist jedoch nach deutschem Recht in aller Regel unwirksam (Dies gilt jedenfalls, sofern die Lieferbedingungen als AGB einzustufen sind, was regelmäßig der Fall ist, vgl. Auer-Reinsdorff/Conrad-Kast, Handbuch IT- und Datenschutzrecht, 3. Aufl. 2019, Teil B § 9 Rn. 39 f.). Daher hat der Gewährleistungsausschluss zumindest gegenüber deutschen Anwendern regelmäßig keine Bedeutung.

Besondere Herausforderungen von Copyleft bei der Softwareentwicklung

Copyleft-Lizenzen sind ein wirkungsvolles Instrument, um den Open-Source-Gedanken über die Jahre, Versionen und Varianten einer Software aufrechtzuhalten. Copyleft bringt jedoch auch Nachteile mit sich. Vor allem besteht die ständige Gefahr, dass der Copyleft-Effekt auf eigenentwickelte, proprietäre Software übergeht, wenn man OSS-Komponenten verwendet.

Viele Softwareprojekte sind und werden weiterhin unter der Vorversion GPLv2 veröffentlicht. Nach dem Lizenztext der GPLv2 liegt jedoch nicht nur bei der Veränderung, sondern bereits bei der Verknüpfung und Verbindung von OSS mit kommerzieller Software eine abgeleitete („derivative“) Software vor. Dies hat zur Folge, dass der Copyleft-Effekt sich auch auf die proprietären Softwarekomponenten erstreckt und diese in die Public Domain fallen können. Dabei ist sowohl bei Entwicklern als auch bei Juristen hochumstritten, in welchen Fällen eine derivative Software vorliegt.

Die Problematik hat grundsätzlich auch die Free Software Foundation (FSF) erkannt und als Reaktion darauf einige Anpassungen in der GPLv3 vorgenommen. Wirklich überzeugend gelöst ist die Problematik jedoch nicht, sondern wird nur nicht mehr adressiert. Die GPLv3 enthält schlicht keine expliziten Äußerungen mehr dazu, inwiefern sich das Copyleft bei der Einbindung von OSS-Komponenten in Eigenentwicklungen fortpflanzt. Vom Copyleft-Effekt erfasst sind nach GPLv3 jedoch auf OSS-Komponenten „basierende“ Programme. Insofern ist eine wertende Betrachtung erforderlich, um festzustellen, ob Copyleft (über-)greift.

Die nach wie vor bestehenden Risiken eines ausufernden Copylefts lassen sich abmildern, wenn man einzelne Komponenten inhaltlich-funktional, aber auch technisch scharf abtrennt. Insofern bleiben jedoch Rechtsunsicherheiten, die sich letztlich nur ausräumen lassen, wenn man auf Software mit strengem Copyleft-Effekt verzichtet.