26.04.2016 – Auf dem 2016er Wordcamp in Nürnberg haben wir in einer Session vorgestellt, unter welchen Umständen ein Content-Management-System, das unter GPL lizenziert wurde, um Komponenten erweitert werden darf, die unter kommerzieller Lizenz stehen.
Die weit verbreiteten Content-Management-Systeme WordPress, Drupal, TYPO3 oder Joomla stehen wie Linux unter GPL-Lizenz. Das bedeutet, dass Änderungen am CMS und hiervon abgeleitete Werke auch unter einer kompatiblen Open Source Lizenz stehen müssen. Die Betreiber-Communities nehmen diese Verpflichtung sehr ernst und verstoßen Softwareanbieter, die beispielsweise mit Themes unter kommerziellen Lizenzen am Markt auftreten. WordPress verweist auf die Lizenz-FAQ von Drupal, die keinen Zweifel aufkommen lässt, dass jegliche Erweiterung des CMS auch unter GPL stehen muss. Wir sehen das aus juristischer Sicht anders. Es gibt Konstellationen, bei denen Erweiterungen auch unter kommerzieller Lizenz als Closed Source Software weitergegeben werden dürfen.
Es kommt auf die Frage an, wann derivative work vorliegt und ob die eigene Software getrennt vertrieben wird. Hier werden kontrovers unterschiedliche Meinungen vertreten. Am besten nähern wir uns der Fragestellung über die Allgemeinpole und deren Vertreter.
Nach einer extrem konservativen Ansicht soll immer dann derivative work vorliegen, wenn das angeblich abgeleitete Werk für seine Benutzung eine andere Software benötigt. Danach soll sogar jede Software, die für das Linux-Betriebssystem geschrieben wurde, auch unter Open Source Lizenz stehen müssen. Die Verfechter dieser Theorie sagen, wer bei der Softwareentwicklung schon an Linux gedacht habe, produziert ein abgeleitetes Werk, welches unter entsprechender Lizenz stehen muss.
Diese Position ist so realitätsfern, dass sie kaum ernst genommen werden kann. Linux wäre mit keiner kommerziell lizenzierten Software mehr kombinierbar. Gleichwohl wird diese Position vertreten und sogar von Gerichten mangels näherem technischen Sachverstand übernommen. Das Landgericht Berlin hatte in der Entscheidung AVM gegen Cybits angenommen, dass sich der Copyleft-Effekt des Linux-Kernels auf die gesamte eingebettete Software eines Routers erstreckt, wenn diese in einer zusammenhängenden Firmware verkörpert ist. Wenn etwas in einem Gehäuse steckt, muss es derivative work sein.
Betrachten wir den liberalen Gegenpol, entdecken wir einen anderen Extremismus. GPL-basierte Betriebssysteme werden in der Praxis geradezu schamlos mit kommerzieller Software verbunden. Hersteller von intelligenten Haushalts-Netzwerk-Geräten oder Telefonie-Geräten verbinden und ergänzen Open Source Software mit ihren eigenen Produkten und stellen das Gesamtgebilde unter kommerzieller Lizenz. Ein Vertreter dieser Fraktion, die Firma VMware, steht aktuell vor Gericht in Hamburg und muss erklären, warum Veränderungen am Kernel angeblich keinen Copyleft-Effekt auslösen. Wir glauben, dass es VMware schwer fallen wird, die Rechtmäßigkeit des eigenen Handelns nachzuweisen, sofern die technischen Angaben der Klägerseite zutreffen sollten.
Über diese Extrempole kommt man zu keiner brauchbaren juristischen Einschätzung. Bei einem Content-Management-System kann nicht alles was mit dem System verbunden ist unter Copyleft-Effekt fallen. Drupal-Entwickler versuchen die Linie dort zu ziehen, wo der Nutzer statt Programmcode Daten wie HTML-Seiten oder Bilder eingibt. Diese sollen nicht unter den Copyleft-Effekt fallen, weil es sich um Daten des Users handele. Diese Trennung ist zwar charmant, aber trotzdem unbrauchbar. Soll der Javaskript-Code auf der HTML-Seite unter ein Copyleft fallen? Soll ein grafisches Template nach intelligenten und unintelligenten Daten unterschieden werden?
Maßstab für die Frage, ob zwei Softwarekomponenten voneinander abgeleitete Werke darstellen, ist die Frage, ob das eine Werk in funktionaler Hinsicht eine Erweiterung des anderen Werkes darstellt oder ob zwei unabhängige Werke über die hierfür vorgesehenen Schnittstellen miteinander kommunizieren. Ein Betriebssystem ist dafür vorgesehen, Ressourcen für Anwendungsprogramme bereitzustellen. Das Anwendungsprogramm ist dabei keine Erweiterung des Betriebssystems, sondern die vorgesehene Funktion des Betriebssystems. Entsprechend ist ein Content-Management-System dafür da, Inhalte (Content) zu managen. Inhalte sind dabei all jene flexiblen Inhalte, die typischerweise vom Anwender konfiguriert und über das CMS verwaltet werden. Die Kombination aus HTML-Seiten, PHP-Seiten und Stylesheets ist zunächst einmal kein abgeleitetes Werk des CMS. Das ändert sich auch nicht in dem Moment, wenn ein solches Template oder Theme für eine Vielzahl von Websites angelegt und über das CMS verwaltet wird. Diese funktionale Einschätzung ändert sich auch nicht dadurch, dass im Template ausführbarer Code enthalten ist, gleichgültig ob dieser auf dem Server oder beim Client ausgeführt wird.
Wie sieht es mit anderen Erweiterungen aus, die im Backend des CMS eingebunden werden? Nach der oben genannten Formel liegt kein derivative work vor, wenn eine Softwarekomponente über dafür vorgesehene Schnittstellen eingebunden wird. Kann das auch dann gelten, wenn damit der Funktionsumfang des CMS erweitert wird? Dies hängt davon ab, ob das CMS nach seiner Funktion dafür vorgesehen ist, über Plugins und Module erweitert zu werden. Ergänzungen des CMS, die über ein Backend und ohne Veränderung des Source Codes des CMS eingebunden werden können, sind regelmäßig kein derivative work. Sie können also auch unter kommerzieller Lizenz vertrieben werden.
Lassen Sie uns jetzt die Schraube über den Anschlag hinaus drehen. Was ist, wenn ich ein CMS erweitere, indem ich die vorhandenen Dateien verändere und Source Code hinzufüge? Bei Content-Management-Systemen, die auf interpretierten Sprachen wie PHP basieren und keinen Compiler benötigen, ist eine solche Anpassung einfach und erfordert kein Reverse Engineering. Wenn ich Source Code-Dateien von WordPress verändere, ist die veränderte Datei selbstverständlich derivative work. Auch eine hinzugefügte Datei, die auf Source Code-Ebene eingebunden wird, löst derivative work aus. Grund: Es werden nicht die für die Einbindung von Erweiterungen vorgesehenen Schnittstellen verwendet.
Könnte man jetzt nicht einfach die Schnittstellen erweitern, diese Veränderungen unter Open Source stellen und dann über das neu geschaffene Einfallstor eigenen Code einbinden? Die Drupal-FAQ erwähnt diesen Fall ausdrücklich und hält ihn für unzulässig. Tatsächlich sind wir hier an der Grenze zwischen Zulässigkeit und Unzulässigkeit angekommen. Mit Sicherheit wird man es als rechtsmissbräuchlich ansehen, wenn eine Schnittstelle alleine zu dem Zweck geschaffen wird, um den Copyleft-Effekt auszuhebeln, aber auch hier wird es Gestaltungsmöglichkeiten geben.