Seit dem Release der ersten OXID-Shopversion 4 stellt sich immer wieder
die spannende Frage nach der Einsetzbarkeit von Modulen innerhalb der
Community-Edition, im Folgenden kurz „CE“ genannt. Diese wurde
von der OXID eSales AG unter die populäre GPLv3 gestellt. War vorher
die Art der Lizenzierung von Modulen eher nebensächlich, wirft die GPL
nun die Frage auf:

Dürfen „kommerzielle“ OXID-Module rechtlich einwandfrei auch unter der CE genutzt werden?

Wem
die Definition der GPL unbekannt ist, sollte als erstes den zugehörigen
Wikipedia-Eintrag lesen, der die meisten grundlegenden Fragen klärt. [1]

Speziell der Abschnitt „GPL Version 3“ ist hierbei natürlich interessant, da er auf die Besonderheiten der GPLv3 genauer eingeht.

Die GPL wurde erstellt, um möglichst viele Bereiche in der
Softwareentwicklung abdecken zu können und dort entsprechende
Rechtssicherheit zu gewährleisten. Entsprechend komplex bzw. auch
teilweise allgemein und vage gefasst ist dieses Lizenzkonstrukt, so dass
es eine Beantwortung dieser Frage nicht einfach macht.
Da wir, die Fa. D3 Data Development Inh. Thomas Dartsch, als langjähriger
Premium-Partner der OXID eSales AG und Autor diverser sehr populärer
Module für den OXID eShop, auch direkt von dieser Problematik betroffen
sind, habe ich (Thomas Dartsch) mich dieses Sachverhalts einmal
angenommen. Basis dazu war das Buch „Die GPL kommentiert und erklärt“
aus dem bekannten O’Reilly-Verlag, von dem zahlreiche andere Bücher
rund um Software und Programmierung stammen. Nicht zuletzt wird von
O’Reilly auch das aktuell einzig existierende Buch zum OXID eShop
angeboten. [2]

Für die Interpretation der GPL, in Bezug auf das ziemlich spezielle Thema
der Module unter dem OXID eShop, diente mir vorallem Teil 2 „Die kommentierte GPL“
des genannten Buches. Hier wird auf die einzelnen Anwendungsfälle und
Besonderheiten genauer eingegangen. In vielen Beispielen konnte ich die
Beziehung zwischen einem Modul und dem OXID eShop wiedererkennen. Daher
beziehen sich auch folgende Zitate und meine anschließende Beurteilung
auf den Inhalt dieses Buches.

Bevor ich mich mit meiner Recherche beschäftigt hatte, ging ich wie wohl so ziemlich jeder andere halbwegs „GPL“
Interessierte davon aus, das es nur ein wichtiges Kriterium gibt: Darf
Programmcode, der unter der GPL steht, mit Code vermischt und genutzt
werden, der nicht per GPL lizenziert ist?
Für die Code-Vermischung gibt es innerhalb der GPL den treffenderen Begriff
»derivative work« (abgeleitete Werke), der jedoch gleichzeitig mehr
Konstellationen beinhaltet, als die reine technische Vermischung von
Programmcode. Dazu später mehr. Relativ schnell wurde klar, dass es
daneben mindestens noch zwei andere Kriterien gibt. Dies ist zum einen
die Art des Vertriebswegs und zweitens die Tatsache, ob ein Programmcode
nur mit einem GPL-Code zusammen arbeitet. Alle drei Punkte müssen
demnach für den vorliegenden Fall genau betrachtet werden, um in der
Summe festlegen zu können, ob der OXID eShop in seiner CE-Version mit
einem kommerziellen (nicht GPL-lizenzierten) Modul betrieben werden
kann. Für den Laien stellt sich hier schnell die Frage: Warum ist das so
kompliziert? Warum gibt es dazu keine klare Aussage? Die Antwort findet
sich in anderen Lizenzwerken. Denn wie jeder andere juristische Text
auch, läßt die GPL Spielraum für Interpretationen. Als Beispiel sei die „Microsoft EULA“
genannt, der jeder Nutzer eines Rechners mit Windows Betriebssystem bei
der Installation zustimmen muss. Da dies jedoch erst nach dem Kauf der
Software passiert, gibt es viele Juristen, die argumentieren, dass damit
die EULA in Deutschland (Europa?) ungültig sei, da die
Nutzungsbestimmungen dem Nutzer vor dem Kauf bekannt sein müssen.
Erwartungsgemäß sieht das Microsoft jedoch anders. Es gibt sicherlich
noch eine ganze Reihe anderer Beispiele für Lizenzbestimmungen, die je
nach Betrachtungsweise unterschiedliche Meinugnen hervorrufen. Bei
kommerziellen Lizenzen gibt es dazu jedoch meist bereits richterliche
oder gar höchstrichterliche Urteile, so dass man eine entsprechende
Rechtssicherheit hat. Solche Urteile fehlen jedoch in aller Regel bei
der GPL, da sie zumeist im non-profit Umfeld genutzt wird und damit
etwaige Verstöße aus Kostengründen viel seltener vor Gericht landen.
Daher handelt es sich im Folgenden um die Schlussfolgerungen eines
Nicht-Juristen, anhand der Interpretationen des oben genannten Buches.
Dabei werde ich die genannten drei Kriterien auf die Situation im OXID
eShop betrachten.

Welche Situation haben wir jedoch genau vorliegen?

Der OXID eShop in der CE-Version liegt wie beschrieben unter der GPLv3
Lizenz. Er kann also frei verändert, angepasst und verbreitet werden,
solange das resultierende Werk ebenfalls unter der GPLv3 steht. Das ist
der einfachste Fall und nicht weiter erklärungswürdig. Interessant wird
es, wenn ein Nutzer (Shopinhaber) ein kommerzielles Modul erwirbt – das
nicht unter der GPLv3 steht- und es in seinem OXID eShop CE nutzen
möchte. Wichtig ist hierbei zu erwähnen, dass durch das spezielle
Modulsystem des Shops in aller Regel keine vorhandenen Programmdateien
des Shops mit neuem Code abgeändert werden müssen.

Damit kommen wir zum 1. Betrachtungspunkt, des »derivative work« (abgeleitetes Werk)

„[…] muss eigener Code eindeutig der GPL unterstellt werden, wenn das
vorbestehende GPL-Programm in seiner bestehenden Form geändert wird.
Erweiterungen, Kürzungen und Abänderungen des Codes führen stets dazu,
dass das so geänderte Programm der GPL unterstellt werden muss […]“ [3]

Module für den OXID eShop werden – wie oben beschrieben – als eigenständige Dateien ausgeliefert. Eine sog. Metadata-Datei (seit OXID eShop Version 4.6.0) ist für die Integration aller Moduldateien in den Shop
verantwortlich. Die OXID eSales AG liefert hier also selbst ein
Werkzeug, um keine Codevermischung, also das direkte ändern von
Shopdateien, nötig zu machen. Es gibt daher nur sehr wenige
Anwendungsfälle, bei denen eine Codevermischung stattfindet. Dies könnte
z.B. der Fall sein, wenn ein Modul eine Shopfunktion in der Form
erweitern muss, indem die vorhandene Funktion dupliziert und mit
eigenem Code erweitert wird. Der zweite Fall könnten meiner Meinung nach
die Templates sein, die für die Optik im Shopfrontend und -backend
verantwortlich sind. In aller Regel wird in diese Dateien zusätzlicher
Code eingefügt, um eine gewisse Funktion anzeigen zu lassen, und mit
dem Modul ausgeliefert. Für beide Ausnahmefälle würde es sich anbieten,
die Teile des Moduls per Lizenz auszulagern und expliziet unter die GPL
zu stellen. Das ist besonders bei den Templates unproblematisch, da der
eingefügte Code nur sehr marginal ist, un kaum über wenige einfache
Programmzeilen hinaus geht.

Hinzu kommt die eindeutige Abgrenzung zwischen GPL- und Nicht-GPL-Programmcode:

„[..]Es soll vermieden werden, dass GPL-Software mit selbständigen
Softwaremodulen in einer Form verbunden wird, die es dem Nutzer
unmöglich macht, die GPL-Bestandteile ohne weiteres als eigenständige
Teile zu erkennen und zu nutzen.[..]“ [4]

Auch dieser Punkt der „Code-Vermischung“
ist bei OXID-Modulen durch das klare Modulsystem des OXID eShop nicht
gegeben. Alle Modulbestandteile sind eindeutig als solche
identifizierbar, was sich seit der 4.6.0 des Shops und deren
umfangreicheren Möglichkeiten innerhalb des Modulverzeichnisses weiter
vereinfacht hat.

Ein gutes Fazit zu diesem Punkt bildet die folgene Auflistung:

„[..] ergibt sich folgende Abstufung für Software, die zusammen mit einem GPL-Programm verbreitet werden soll:

1.
Programme oder Softwarebestandteile, die (inhaltlich) nicht voneinander
abgeleitet sind, können unter unterschiedlichen Lizenzen verbreitet
werden, wenn sie auch formal getrennt vorliegen;
2.
Programme oder Softwarebestandteile, die (inhaltlich) nicht voneinander
abgeleitet sind, müssen aber dann insgesamt unter der GPL verbreitet
werden, wenn sie ein »Ganzes« bilden, weil keine formale Trennung
besteht;
3. Programme oder Softwarebestandteile, die (inhaltlich) voneinander abgeleitet sind, dürfen stets nur unter der GPL gemeinsam verbreitet werden.“ [5]

Kommen wir zum 2. Punkt, dem Vertriebsweg

„Unabhängig von der Frage, wann ein »derivative work« im Einzelfall vorliegt, ist der Vertrieb von eigener Software alleine immer dann unter einer
beliebigen Lizenz zulässig, wenn sie keinen GPL-Code enthält. Selbst
wenn die »Verbindung« der eigenen Software mit dem GPL-Programm ein
»abgeleitetes Werk« ergeben würde, wäre der alleinige Vertrieb
gestattet. Das liegt daran, dass in diesem Fall nicht das bearbeitete
Programm vertrieben wird, sondern nur eigener Code. [..]“ [6]

„Wie
auch immer die technische Verbindung zwischen zwei
Softwarebestandteilen gestaltet ist – man wird verlangen müssen, dass
die Softwaredateien in deutlich abgegrenzter Form (etwa in voneinander
getrennten Dateien) verbreitet werden, so dass auch technisch- formal
eigenständige Softwarebestandteile vorliegen, sei es im Source-Code, sei
es im Objekt-Code.“ [7]

Es
handelt sich hier eher um einen Unterpunkt von 1), dem »derivative
work«. Jedoch geht es im speziellen um die Art und Weise der Verbreitung
des Programmcodes, also des Moduls. Im Gegensatz zu vielen anderen
Programmiersprachen müssen Module beim OXID eShop nicht als sog. „Executables“ ausgeliefert werden. Für Laien sind die „EXE“-Dateien
unter Windows genannt, die dann sowohl den originalen, wie auch den
Erweiterungscode enthalten. Eine exakte räumliche Trennung ist also –
wie auch schon unter 1) ausgeführt – bei OXID-Modulen gegeben.
Ich
kenne keinen Fall, in dem Module als festes Bundle zusammen mit dem
OXID eShop vertrieben werden, was einen Verstoß der GPL für diesen
Aspekt bedeuten würde. Der Verkauf der Module erfolgt in aller Regel
separat und klar getrennt (zip-Paket).

Zum Schluss nun der 3. Punkt, die „Programmselbständigkeit“

„Ein starkes Indiz für eine inhaltliche Abhängigkeit ist sicherlich der
Umstand, dass ein Softwarebestandteil speziell für das GPL-Programm
entwickelt wurde und nur mit diesem ablauffähig ist. Ist hingegen ein
Programm nicht nur mit dem GPL-Programm ablauffähig, sondern auch mit
anderer Software, […] so ist dies ein überzeugendes Argument für eine inhaltliche Selbstständigkeit, auch wenn für die jeweilige Portierung kleine
Anpassungen (zum Beispiel für Schnittstellen) erforderlich sind.“ [7]

Die
Selbständigkeit eines Programms definiert sich damit also nicht allein
durch die Tatsache, ob es für sich genommen lauffähig ist. Dies würde
bei einem OXID-Modul natürlich sofort verneint werden müssen, da es
immer auch die Shopsoftware als Basis benötigt. Wichtig ist daher ferner
die Tatsache, ob das Modul auch unter anderen Umgebungen lauffähig ist.
Hier kommen nun für mich die anderen Shopeditionen der OXID eSales AG
ins Spiel. Beide werden mit einer kommerziellen Lizenz ausgeliefert und
definieren sich daher für die GPL als „andere Software“.
Auch wenn es zwischen den Editionen, besonders gegenüber der
Professional-Edition (PE), eine extrem große gemeinsame Codebasis gibt.
Diese gemeinsame Codebasis ist auch der Grund, warum technisch gesehen
ein OXID-Modul, das in einer PE läuft, auch immer in einer CE
funktionieren wird. Das Modul läuft somit nicht nur exklusiv mit dem
GPL-Programm, sondern auch mit „anderer“ Software, was eine inhaltliche Abhängigkeit zum GPL-Programm ausschliesst.

Wir
fassen zusammen: Für die Bewertung, ob ein Nicht-GPL-Programmcode, der
innerhalb von GPL-Code genutzt wird, im Rahmen der GPLv3-Lizenz zulässig
ist, müssen mehrere Dinge betrachtet werden.

1) Handelt es sich um ein abgeleitetes Werk?
2) Gibt es einen gemeinsamen, nicht trennbaren Vertriebsweg?
3) Arbeitet der Nicht-GPL-Code ausschliesslich mit dem GPL-Code zusammen?

Für
alle 3 Punkte gibt es schlüssige und starke Argumente für eine
gemeinsame und GPLv3-konforme Nutzung zwischen einem OXID eShop CE und
nicht-GPL-Modulen, die für das OXID-Umfeld programmiert wurden. Eine
Verletzung der Lizenzbestimmungen der GPLv3 sehe ich daher nicht.

Quellenangabe:
[1] Wikipedia: http://de.wikipedia.org/wiki/GPL
[2] O’Reilly Verlag:  https://examples.oreilly.de/german_examples/onlineshopsoxidger/
[3] „Teil 2: Die kommentierte GPL“, Seite 66, Abschnitt 19
[4] „Teil 2: Die kommentierte GPL“, Seite 68, Abschnitt 24
[5] „Teil 2: Die kommentierte GPL“, Seite 69, Abschnitt 28
[6] „Teil 2: Die kommentierte GPL“, Seite 66, Abschnitt 18
[7] „Teil 2: Die kommentierte GPL“, Seite 69, Abschnitt 27