Chancen und Risiken: Copyleft in der Softwareentwicklung

Inhaltsverzeichnis

Lizenzmodelle regeln nicht nur bei proprietärer Software (Closed Source) deren Kommerzialisierung, sondern dienen auch Anbietern freier und Open-Source-Software (OSS) zur gezielten Steuerung der wirtschaftlichen Nutzbarmachung. Die wesentlichen Chancen und Risiken urheberrechtlicher Lizenzmodelle mit Copyleft-Klausel und die daraus resultierenden Auswirkungen auf die Softwareentwicklung lassen sich auf Basis der grundlegenden Funktionsweise Freier Software und Open Source am Beispiel der GNU General Public License (GPLv3) anschaulich darstellen.

Grundlagen von Freier Software und Open Source

Freie Software beschreibt Software, die Entwicklerinnen und Entwicklern sowie Anwenderinnen und Anwendern größtmögliche Freiheit einräumt, sie auszuführen, zu kopieren, zu verbreiten, zu untersuchen, zu ändern und zu verbessern. Als Abspaltung der Freie-Software-Bewegung gründete sich in den 1990er-Jahren die Open Source Initiative (OSI) . Auch Open Source zielt im Kern auf offene Quellcodes, kollaborative Entwicklung und weitgehend unbeschränkte Nutzung ab. Im Unterschied zur Freien Software ist Open Source üblicherweise jedoch als etwas restriktiver in Bezug auf die Freiheit der Anwender zu verstehen, denn sie soll die wirtschaftliche Nutzbarmachung von quelloffener Software erleichtern. Für die nachfolgenden rechtlichen Überlegungen spielt die begrifflich-historische Unterscheidung jedoch keine entscheidende Rolle. Vereinfachend dient daher OSS als Sammelbegriff für Freie und Open-Source-Software.

Die Bandbreite an OSS ist ausgesprochen groß. Betriebssysteme wie Linux oder Android, Webbrowser wie Firefox oder Chromium, Office-Pakete wie LibreOffice (bzw. OpenOffice.org), das Grafikprogramm GIMP, der VLC Media Player, das Datenbanksystem MySQL, Content-Management-Systeme wie Joomla oder Drupal, der Apache HTTP Server oder das Blockchain-System Ethereum sind nur wenige prominente Beispiele. Neben der stetig wachsenden Anzahl an Open-Source-Anwendungen existiert ein breites Spektrum teils sehr unterschiedlicher OSS-Lizenzen. Die genannten Beispiele zeigen, dass OSS zwar dem Grunde nach quell- und nutzungsoffen ist, jedoch – entgegen häufig anderslautender Annahmen – sich durchaus kommerziell nutzen lässt. Auf den ersten Blick erscheint das paradox, ist aber in vielen OSS-Lizenzmodellen explizit so angelegt: Die GPLv3 zum Beispiel untersagt zwar, Lizenzgebühren, also Gebühren für die Nutzung der Software, zu verlangen, erlaubt jedoch explizit Gebühren für die Verbreitung, den Support oder Garantieversprechen.

Bedeutung von Copyleft

Copyleft ist typisches Merkmal vieler OSS-Lizenzen und ein Wortspiel mit dem Begriff Copyright (Urheberrecht). Während das Urheberecht beziehungsweise klassische Lizenzmodelle es Softwareentwicklern erlauben, die Verbreitung, das Kopieren, das Ändern und andere Nutzungsarten durch Anwender und andere Entwickler einzuschränken, zielt Copyleft darauf ab, die Nutzungsarten über die gesamte Lizenzkette hinweg offenzuhalten. Als Copyleft bezeichnet man daher eine Klausel in urheberrechtlichen Lizenzverträgen, die festschreibt, dass Weiterentwicklungen immer unter den identischen oder wesentlich gleichen Bedingungen zur ursprünglichen Lizenz zu verbreiten sind (vgl. LG Köln, Urt. v. 17.07.2014 – Az. 14 O 463/13).

Copyleft ist damit vergleichbar mit „share alike“ bei Creative-Commons-Lizenzen. Typischerweise ist zwischen Lizenzen mit strengen Copyleft-Klauseln und solchen mit schwachen oder ganz ohne Copyleft-Klauseln zu unterscheiden. Bei schwachem Copyleft (GNU Lesser General Public License oder Mozilla Public License) ist es, insbesondere bei der Kombination mit eigenen Softwarekomponenten, unter engen Voraussetzungen und in begrenztem Umfang zulässig, eigene oder abweichende Lizenzbestimmungen zu verwenden (vgl. Mozilla Public License 1.1, Ziffer 6.3. Derivative Works). OSS-Lizenzen ohne Copyleft (MIT-, Apache-2.0- oder BSD-Lizenz) erlauben es, OSS in proprietärer Software zu verwenden – wobei Entwicklerinnen und Entwickler die weiteren Nutzungsrechte grundsätzlich beliebig einschränken können.

OSS und Copyleft am Beispiel der GPLv3

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.

Fazit: Bedarfsgerecht abwägen

OSS ist aus moderner, agiler Softwareentwicklung nicht mehr wegzudenken, fördert kollaborative Zusammenarbeit und hat viele bahnbrechende Anwendungen hervorgebracht. Copyleft sorgt ergänzend dafür, dass der Freie-Software-Gedanke erhalten bleibt und OSS dauerhaft nicht zweckentfremdend wird. Für Softwareunternehmen und Entwickler ist es gleichwohl erforderlich, sich im Detail mit den zahlreichen Lizenzenzmodellen auseinanderzusetzen und bei der modularen Einbindung von OSS-Komponenten mit Bedacht zu agieren. Sonst besteht die Gefahr, die Softwareentwicklung auszubremsen. Im schlimmsten Fall kann Copyleft innovativen Neuentwicklung im Weg stehen. Daher sollten Entwicklerinnen und Entwickler je nach Einzelfall auch OSS-Lizenzen mit schwachem oder ohne Copyleft ins Auge fassen.

Ilan Leonard Selz
ist Rechtsanwalt LL.M. (UMN) der Technologiekanzlei SCHÜRMANN ROSENTHAL DREYER Rechtsanwälte mit Fokus auf Datenschutzrecht, IT-Recht und gewerblichem Rechtschutz. Er betreut Mandate in den Bereichen Technologie, E-Commerce und Bankwesen – ein besonderer Schwerpunkt liegt in der Adtech-Branche. Zudem ist Herr Selz als externer Datenschutzbeauftragter tätig.

(map)