Die GNU General Public License (GPL) ist die am weitest verbreitete Open-Source-Softwarelizenz. Das Linux-Betriebssystem Ubuntu, die Blogsoftware WordPress, die Office-Suite LibreOffice oder das Bildbearbeitungs-Tool GIMP sind nur einige populäre Beispiele. Viele dieser GPL-lizenzierten Programme bieten eine Schnittstelle, die es ermöglicht, Plugins einzubinden und so den Funktionsumfang der ursprünglichen Software erheblich zu erweitern.

Doch wie sieht es mit der Lizenzierung dieser Plugins aus? Müssen Plugins für GPL-Programme ebenfalls unter der GPL verbreitet werden oder ist auch eine unfreie Verbreitung (und damit eine Kommerzialisierung) dieser Plugins möglich? Diese Fragen sollen im folgenden Beitrag anhand eines kleinen Beispiels beleuchtet werden:

Softwareentwickler S entwickelt für die Blogsoftware WordPress ein Plugin, welches die beliebte Plattform um eine Fotogalerie erweitert. Da er viel Zeit und Energie in die Entwicklung des Plugins gesteckt hat, möchte er es gerne verkaufen und nicht zum freien Download zur Verfügung stellen.

Das Copyleft-Prinzip

WordPress wird unter der GNU GPL 2.0 (oder später) verbreitet. Charakteristisch für die GPL ist das sogenannte Copyleft-Prinzip. Danach dürfen Änderungen oder Ableitungen (= Derivate) von GPL-lizenzierten Werken nur unter den gleichen Lizenzbedingungen vertrieben werden. Wörtlich heißt es hierzu in der GPL unter Ziffer 2 b):

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Sie müssen dafür sorgen, dass 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.

(Quelle: Originaltext der GPL 2.0 in Englisch und Deutsch)

Das Copyleft-Prinzip stellt somit sicher, dass freie Software immer frei bleibt und nicht zu proprietärer Software „umgewandelt“ werden kann. Durch die Pflicht, auch Derivate immer unter der GPL zu lizenzieren, wird eine Kommerzialisierung der Software wirksam verhindert.

Plugins als Derivate

Doch unterfallen Plugins für GPL-Software überhaupt dem Begriff der „Derivate“ in der GPL? Aufschluss hierüber gibt wiederum die GPL in Ziffer 2 Abs. 2:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Wenn identifizierbare Teile des Werkes nicht von dem Programm abgeleitet sind und vernünftigerweise als unabhängige und eigenständige Werke für sich selbst zu betrachten sind, dann gelten diese Lizenz und ihre Bedingungen nicht für die betroffenen Teile, wenn Sie diese als eigenständige Werke weitergeben. Wenn Sie jedoch dieselben Abschnitte als Teil eines Ganzen weitergeben, das ein auf dem Programm basierendes Werk darstellt, dann muß die Weitergabe des Ganzen nach den Bedingungen dieser Lizenz erfolgen, deren Bedingungen für weitere Lizenznehmer somit auf das gesamte Ganze ausgedehnt werden – und somit auf jeden einzelnen Teil, unabhängig vom jeweiligen Autor.

(Quelle: Originaltext der GPL 2.0 in Englisch und Deutsch)

Auf unseren Beispielsfall bezogen stellen sich damit zwei Fragen: Was ist nach der GPL ein Derivat (= abgeleitetes Werk) und erfüllt das Galerie-Plugin diese Definition?

Was ist ein Derivat im Sinne der GPL?

Der Begriff des Derivats ist nicht klar definiert. Eindeutig den Derivaten zuzuordnen sind folgende Fallgruppen:

• Erweiterungen, Kürzungen und Änderungen des Originalcodes (in der Regel Bugfixes und Patches)
• Weiterentwicklung durch Codeergänzung, unabhängig davon, ob die Änderungen in einer neuen Datei oder in bestehenden Dateien implementiert werden.

Probleme tauchen hingegen immer dann auf, wenn keine klassische Weiterentwicklung stattfindet, sondern die GPL-Software mit anderen Programmbestandteilen verbunden wird – so wie dies bei Plugins in der Regel der Fall ist. Hierzu schweigt sich die GPL geflissentlich aus und auch vor Gericht wurde dieser Fall noch nicht entschieden. Allein die juristische Literatur hat bereits Kriterien zur Abgrenzung herausgearbeitet auf welche im Zweifelsfall auch die Rechtsprechung zurückgreifen wird. (Gerlach, CR 2006, S. 649 ff. und Funk/Zeifang, CR 2007, 617 ff.)

Die (wenigen) vorhandenen Abhandlungen stellen dabei überwiegend auf formale Kriterien ab.

Von einem Derivat ist danach beispielsweise dann auszugehen, wenn der GPL-Code der ursprünglichen Software in den Code der neuen Software unmittelbar integriert wird. Mit anderen Worten: Ein Derivat liegt vor, wenn die Komponenten so miteinander verbunden sind, dass der GPL-Code nicht unabhängig vom neuen Code geladen werden kann, da die Software nur reibungslos funktioniert, wenn beide Komponenten zusammenwirken. (Gerlach, CR 2006, S. 649 (652))

Auch muss man dann von einem Derivat ausgehen, wenn der GPL-Code und der Code des neuen Programms Teil eines einheitlichen Anwendungsprogramms sind und in einem Adressraum ausgeführt werden.

Ebenfalls ein starkes Indiz für ein Derivat stellt nach der Literatur eine statische Verlinkung auf eine der unter GPL-lizenzierte Programmbibliotheken dar. (Funk/Zeifang, CR 2007, 617 (619))

Gegen das Vorliegen eines Derivats spricht dagegen, wenn die Kommunikation zwischen den Programmen lediglich über Mechanismen abläuft (z.B. Pipes, Queues, Sockets oder Kommandozeilen). Auch gewöhnliche Systemzugriffe auf das GPL-Programm lösen noch keinen Copyleft-Effekt aus. (Funk/Zeifang, CR 2007, 617 (620))

Sind Plugins Derivate?

Gerade im Bereich der Plugins herrscht in der juristischen Literatur und der Open-Source-Community eine lebhafte Diskussion, ob diese unter den Begriff der Derivate fallen.

Die Open-Source-Community bejaht diese Frage zumeist. Auf WordPress.org heißt es beispielsweise:

Part of this license outlines requirements for derivative works, such as plugins or themes. Derivatives of WordPress code inherit the GPL license. Drupal, which has the same GPL license as WordPress, has an excellent page on licensing as it applies to themes and modules (their word for plugins).

There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license. If you disagree, you might want to consider a non-GPL platform such as Serendipity (BSD license) or Habari (Apache license) instead.

(Quelle: http://wordpress.org/about/license/)

Auffallend ist allerdings, dass die Autoren hier nur von einem Gefühl („we feel“) und einer rechtlichen Grauzone sprechen. Ein belastbares juristisches Argument ist dies jedenfalls nicht.

Die Free Software Foundation (FSF), welche die GPL entwickelt hat, trifft eine etwas klarere Aussage in Bezug auf Plugins:

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

(Quelle: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins)

Die Free Software Foundation stellt in ihren FAQ darauf ab, wie die GPL-Software das Plugin aufruft. Sofern dies mittels „fork“ und „exec“ geschieht, ist das Plugin laut FSF ein eigenständiges Programm und kein Derivat der GPL-Software.

Sofern die GPL-Software hingegen ein Plugin dynamisch verlinkt und sowohl die GPL-Software als auch das Plugin gegenseitige „function calls“  durchführen, glaubt („believe“) die FSF, dass es sich bei dem Plugin um ein Derivat der GPL-Software handelt. Sollte die GPL-Software das Plugin dynamisch verlinken, sich die Kommunikation allerdings nur darauf beschränken, die Hauptfunktion des Plugins aufzurufen und auf eine Antwort des Plugins zu warten, so bezeichnet die FSF dies als Grenzfall („borderline case“).

Leider hantiert die FSF hier ebenfalls mit weichen Argumenten, so dass auch deren Aussagen letztlich unbrauchbar sind.

Die deutsche juristische Fachliteratur und Rechtsprechung haben der Frage nach der rechtlichen Einordnung von Plugins für GPL-Software bislang wenig Beachtung geschenkt. Die einzige nennenswerte Quelle ist das Buch „Die GPL kommentiert und erklärt“ des Instituts für Rechtsfragen der Freien und Open Source Softeware (ifrOSS), welches auf der Website des ifrOSS kostenfrei heruntergeladen werden kann. Die Autoren dieses Buches setzen Plugins mit Programmbibliotheken gleich, da beide als „shared library“ zu einem Programm hinzugebunden werden.

Nach Ansicht der Autoren ist bei der Beurteilung der Frage, ob eine Programmbibliothek ein Derivat einer GPL-Software darstellt, auf den Zeitpunkt der Distribution der Software abzustellen. Grund hierfür sei, dass die GPL selbst auf den Vertriebsvorgang bezug nimmt („when you distribute them as separate works“).

Folgt man dieser Ansicht, stellen statische Programmbibliotheken Derivate dar, da sie mit dem zugreifenden (GPL-)Programm ein einheitliches Executable (= ausführbare Datei) bilden. Dynamische Programmbibliotheken hingegen können auch in einer getrennten Datei selbständig vorliegen.

Allerdings reicht dieser programmiertechnische Aspekt der dynamischen Verlinkung nach Ansicht der Autoren nicht aus, eine Programmbibliothek (bzw. ein Plugin) klar als selbständiges Werk betrachten zu können. Vielmehr müsse darüber hinaus auch der inhaltliche Aspekt beachtet werden. Sofern ein Plugin gerade für ein konkretes GPL-Programm entwickelt worden und für andere Programme nicht verwertbar ist, liege auch bei einer dynamischen Verlinkung ein Derivat vor. Nur wenn das Plugin mit nur leichten Anpassungen hinsichtlich der Schnittstelle auch für andere Programme verwendbar ist, soll nach Ansicht der Autoren weiterhin ein eigenständiges Programm vorliegen.

Auch die US-amerikanische Literatur schweigt sich zum Thema „Plugins für GPL-Software“ größtenteils aus. Die School of Law der University of Washington hat eine der wenigen wissenschaftlichen Betrachtungen des Themas veröffentlicht. Dort wird mittels eines Gedankenexperiments kritisiert, dass die FSF in ihren FAQ auf einen rein programmiertechnischen Aspekt abstellt und auch im Falle einer dynamischen Verlinkung von GPL-Software (grundsätzlich) ein Derivat annimmt:

The following thought experiment demonstrates the absurdity of the GPL approach. Imagine taking the Firefox source code and modifying it in such a way that it is encapsulated in a plugin, called Fireplug. Common sense and the law tell us that Fireplug is a derivative work of Firefox, based simply on the fact that Fireplug incorporates all or most of the Firefox codebase. Now, when we plug Fireplug into Firefox, we essentially have a Firefox browser running within a Firefox browser. And depending on the Firefox plugin architecture, the GPL drives us to incompatible results. If plugins are dynamically linked, Fireplug is a derivative work. This is the right result, but the reasoning is exactly wrong. Fireplug is a derivative work because it incorporates and is substantially similar to Firefox, not because of a decision made by the designer of the Firefox plugin architecture. On the other hand, if plugins are launched as separate programs, then Fireplug suddenly is not a derivative work, even though this result is counter the common sense result above. Clearly, the mechanism of a given plugin architecture are analytically unhelpful and misleading in answering the derivative work question.

(Quelle: http://www.law.washington.edu/lta/swp/law/derivative.html)

Leider präsentieren die Autoren der Abhandlung keine eigenen Lösungsansätze für das kritisierte Problem.

Fazit

Nimmt man die oben dargestellten vertretenen Rechtsmeinungen zusammen, lässt sich feststellen, dass derzeit keine Klarheit hinsichtlich der rechtlichen Bewertung von Plugins für GPL-Software besteht. Während die Open-Source-Community auf einen rein programmiertechnischen Aspekt abstellt und bei einer Ausführung des Plugins über „fork“ und „exec“ kein Derivat annimmt, gehen die Literaturmeinungen etwas weiter. Sie bejahen eine Selbständigkeit des Plugins auch dann, wenn eine dynamische Verlinkung vorliegt und das Plugin nicht speziell für eine GPL-Software entwickelt wurde.

Für unseren Plugin-Entwickler S aus dem eingangs skizzierten Beispiel bedeutet diese Unklarheit eine Rechtsunsicherheit beim kommerziellen Vertrieb seines Plugins unter einer unfreien Lizenz. Je nachdem, welcher Ansicht man folgt, ergeben sich für ihn unterschiedliche Lösungsansätze:

• Wenn S sein Plugin so entwickelt, dass es sich über „fork“ und „exec“ ansprechen lässt, unterfällt es nach der strengen Auffassung der FSF nicht mehr dem Begriff des Derivats und kann problemlos unter einer unfreien Lizenz vertrieben werden.
• Aber auch bei einer dynamischen Verlinkung des Plugins mit WordPress könnte er eine Eigenständigkeit erreichen, wenn das Plugin auch mit anderen Programmen verwendbar, also nicht speziell auf WordPress zugeschnitten wäre. Freilich beinhaltet letztgenannter Ansatz wegen der fehlenden Rechtsprechung auf diesem Gebiet ein gewisses Restrisiko. Da aber gute Argumente für diese Ansicht sprechen, ist das Risiko derzeit als eher gering einzustufen.

Lizenzen
Text: CC-BY 4.0 / Rechtsanwalt Jakob Wahlers
Foto: CC-BY 2.0 via flickr / Tim Lucas (bearbeitet durch Zuschnitt)