Open Source und Copyleft

Open Source Software hat sich in der Softwarebranche mehr als etabliert und begegnet uns im Alltag in vielen Facetten. Schätzungen zufolge besteht proprietäre Standard- und Individualsoftware aus bis zu 98 % Fremdkomponenten. Beim Einsatz der Fremdkomponenten spielt der Einsatz von Open Source Software eine entscheidende Rolle. Nach Erhebungen des Scantool-Anbieters Synopsys basiert durchschnittlich über 57 % einer Codebasis auf Open Source Software. Die wirtschaftliche und rechtliche Bedeutung von Open Source Software ist daher hoch.

Doch was hat es mit dem Copyleft-Effekt auf sich. Mehr dazu in diesem Artikel:

Open Source: Definition des Copyleft-Effekts

Der Copyleft-Effekt ist nicht einheitlich definiert. Die nachstehende Formulierung beschreibt den Copyleft-Effekt jedoch meines Erachtens am deutlichsten:

„Der Copyleft-Effekt ist eine Klausel, die sicherstellt, dass Weiterentwicklungen der Software unter denselben Bedingungen der Lizenz wieder freigegeben werden“.

Die Intention solcher Copyleft-Klauseln liegt darin, die freie Nutzbarkeit der Software auch für weiterentwickelte Versionen sicherzustellen.

Open Source: Risiko: Copyleft

Damit birgt der Copyleft-Effekt ein erhebliches Risiko für die (eigene) proprietäre Software. Der Copyleft-Effekt ist insofern problematisch, weil regelmäßig der Quellcode der von Open Source Software abgeleiteten Softwareelemente offengelegt werden muss. Die Open Source Lizenzbedingungen springen gleichsam auf die proprietäre Software über. Man spricht in diesem Zusammenhang anschaulich auch vom „viralen Effekt“. Die Open Source Software „infiziert“ also die proprietäre Software. Die vormals proprietäre Software ist ab nun als Open Source Software zu behandeln. Das “Heiligtum” eines jeden Softwareunternehmens, der Quellcode, muss damit offengelegt werden. Für Entwickler von proprietärer Software besteht diese Gefahr insbesondere dann, wenn Bibliothek-Dateien (Plugins) auf Basis von Open Source Lizenzen in die proprietäre Software integriert werden – was enorm häufig der Fall ist.

Open Source: Copyleft ist nicht gleich Copyleft

Je nachdem, wie „aggressiv“ der Copyleft-Effekt in den einzelnen Lizenzbestimmungen formuliert wird, wird differenziert zwischen einem „starken Copyleft“, einem (normalen) „Copyleft“ und „Permissive Lizenzen“. Dazu zwei Beispiele zur besseren Veranschaulichung:

Die aktuell am weitest verbreitete Lizenz ist die GNU General Public License, Version 2 (bzw Version 3). Diese formuliert den Coypleft-Effekt (Punkt 2 lit b)) wie folgt sehr streng:

„You must cause any work…that in whole or in part contains or is derived from the (Open Source) Program…to be licensed as a whole…under the terms of this License“.

Hingegen sehen die Lizenzen BSD Copyright License und MIT License gar keine diesbezüglichen Verpflichtungen vor (womit sie als Permissive Lizenzen zu qualifizieren sind). Dies macht die Nutzung lizenzrechtlich deutlich unkomplizierter als bei Copyleft-Software. Wenn man nun in Erinnerung ruft, dass 57 % des weltweit programmierten Codes auf Open Source Lizenzen beruht und die GNU General Public License, Version 2, die am häufigsten eingesetzte Open Source Lizenz ist, wird deutlich, welche „Gefahr“ Open Source Software für proprietäre Software begründet.

Open Source: Derived or not derived, dass ist hier die Frage

Die springende Frage in diesem Zusammenhang ist, wann liegt eine (von Open Source Software) abgeleitete Software „derived work“ vor? Auch wenn Vertreter der Free Software Foundation und mit ihr das LG Berlin davon ausgehen, dass fast jede Art der Verknüpfung von proprietärer Software mit Copyleft-Open Source Software einen viralen Effekt auslösen soll, erscheint eine differenzierende Betrachtung geboten. Diese Frage zu beantworten ist wahrlich kein leichtes Unterfangen und lässt sich nur auf Basis einer interdisziplinären Zusammenarbeit zwischen Softwareentwickler und Juristen lösen. Folgende Prüfungsschritte sind in diesem Zusammenhang zu empfehlen:

• Prüfung anhand formeller Kriterien: Hier lautet die Prüfungsfrage: Sind die eigenen Entwicklungen von den Open Source Code-Elementen separat abgrenzbar? Wird dies bejaht, spricht dies gegen ein abgeleitetes Werk und somit gegen den Copyleft-Effekt.  

• Prüfung anhand kommerzieller Kriterien: Hier steht die Frage im Zentrum: Wie wird die Software nach außen auf dem Markt vertrieben? Eine „einheitliche“ Vermarktung spricht eher für ein „derived work“ und somit für den Copyleft-Effekt. Die Eigenständigkeit liegt gerade dann nicht vor, wenn die proprietäre Software mit der Open Source Software als „Teil eines Ganzen“ verbreitet wird.[4]

• Prüfung anhand funktioneller Kriterien: Hier lautet die Prüfungsfrage: Sind die einzelnen Elemente (gemeint Open Source Elemente einerseits und proprietäre Software andererseits) jeweils für sich eigenständig nutzbar. Wenn also die proprietäre Software ohne die Open Source Elemente nicht genutzt werden kann, spricht dies für ein abgeleitetes Werk und somit für den Copyleft-Effekt.  
  
  

Handlungsempfehlung:

Zur Vermeidung des viralen Effekts ist es erforderlich, dass die proprietäre Software unabhängig und formal von der Open Source Software abgegrenzt werden kann und sowohl Open Source Software als auch die proprietäre Software keine strukturelle Einheit bilden. Auf diese Abgrenzung ist sowohl während der Entwicklung als auch im Vertrieb der Software zu achten. Vertraglich sollte darauf geachtet werden, dass das Softwareunternehmen hinsichtlich der Open Source Bibliotheken nicht der direkte Vertragspartner des Kundens wird. In diesem Fall würde das Softwareunternehmen für einen Mangel in den Open Source Elementen haften.

‍