Inhaltsverzeichnis (verbergen)
Urheberrecht
Für einen integrierten eLearning-Campus von besonderer Relevanz ist die Frage, wie die Einbindung von Plugins in das verwendete Lernmanagementsystem erfolgen kann.
Einbindung von Plugins
In Bezug auf die sog. Plugins stellt sich abermals die oben bereits angesprochene Frage, ob es sich hierbei um ein abgeleitetes Werk handelt, welches dann ebenfalls unter der GPL vertrieben werden müsste. Wären sie hingegen nicht als derived work anzusehen, könnten sie unter einer beliebigen Lizenz weitergegeben werden, ohne gegen die Lizenzbestimmungen der GPL zu verstoßen.
Der Begriff Plugin bezeichnet dabei ein Computerprogramm, das in ein anderes Softwareprodukt gleichsam eingeklinkt wird. Es ergänzt dabei die Software, stellt jedoch anders als ein Add-on eine eigenständige Software dar. Wie die GPL selbst klarstellt, soll durch den oben beschriebenen Copy-Left-Vermerk nicht erreicht werden, dass Rechte für Werke in Anspruch genommen oder beschnitten werden, die komplett auf eigenen Ideen beruhen:
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
Da es sich bei einem Plugin um eigenständige Software handelt, ist insoweit nicht von einem abgeleiteten Werk im Sinne der GPL auszugehen, sodass auch eine Weiterverbreitung nicht zwingend unter der GPL zu erfolgen hat. Zumindest bei der eigenständigen Weiterverbreitung können eigene Plugins somit unter einer durch den Urheber frei wählbaren Lizenz weiterverbreitet werden.
Problematisch ist allerdings die Weiterverbreitung des Plugins gemeinsam mit Stud.IP. In diesem Fall könnte von einem Ganzen im Sinne von § 2b GPLv2 ausgegangen werden. Diese Fallgestaltung ist derjenigen der Verbindung eines Programms mit einem Kernelmodul bzw. mit einer Programmbibliothek vergleichbar. Für Kernelmodule wird deren Eigenständigkeit angenommen, wenn das Modul mit dem Kernel über eine Schnittstelle kommuniziert und das Modul nicht integraler Bestandteil des Kernels werden soll. Daneben spielt auch der Zeitpunkt der Entwicklung des Moduls eine entscheidende Rolle. Ist das Modul vor dem Kernel geschaffen worden, ist von dessen funktionaler Eigenständigkeit auszugehen. Im Hinblick auf Programmbibliotheken wird eine erste Unterscheidung aufgrund der statischen oder dynamischen Verknüpfung des zugreifenden Programms mit der Bibliothek getroffen. Neben dieses durch die Programmiertechnik zu beeinflussende Kriterium müssen jedoch inhaltliche Kriterien treten, um die Qualifizierung endgültig vornehmen zu können. So gilt es hier zu beachten, ob die Bibliothek allein für das maßgebliche Programm entwickelt wurde oder ob sie auch mit anderen Programmen verwendbar ist. Handelt es sich um eine GPL-Bibliothek, auf die andere Programme zugreifen, so ist zu fragen, ob das zugreifende Programm auch mit anderen Bibliotheken lauffähig wäre. Die bezeichneten Kriterien werden auch im Hinblick auf Plugins relevant. So gilt es auch hier zu klären, ob das bezeichnete Plugin allein für das unter der GPL lizenzierte Programm verwendbar ist oder auch mit anderen Programmen verwendet werden kann. In die Abwägung einzubeziehen ist dabei auch die Programmiertechnik, also die Art und Weise der Verknüpfung. Diese spielt beispielsweise dann eine Rolle, wenn das entsprechende Plugin nicht mehr von der übrigen Software unterschieden werden kann. Daher kann bereits die Verarbeitung der beiden Bestandteile in eigenen Dateien maßgeblich für deren Eigenständigkeit sein.
Insbesondere: Einbindung fremder Plugins
In Bezug auf die Einbindung fremder Plugins ergibt sich an dieser Stelle eine Besonderheit. Für die Einbindung und Weiterverbreitung maßgeblich ist insoweit nicht die GPL, also die Lizenz der Software, in die das Plugin eingebunden werden soll, sondern die Lizenz, unter der das Plugin vertrieben wird. Sie entscheidet darüber, für welche Zwecke ein solches Plugin weiterverarbeitet werden kann.
Probleme ergeben sich hier insbesondere in Bezug auf die gemeinsame Verbreitung von Stud.IP in Verbindung mit den genannten Plug-Ins. Wie oben bereits ausgeführt , ist nach § 2 der GPL eine Unterstellung unter die Lizenzbedingungen der GPL auch dann erforderlich, wenn die beiden Werke als Ganzes gemeinsam vertrieben werden sollen.
Auf den ersten Blick scheint hier die Sachlage einfach: Die gemeinsam vertriebene Software wird nach Maßgabe der GPL verbreitet. Allerdings können sich hier insoweit Lizenzkonflikte ergeben, als dass die Lizenz, unter der das Plugin erworben wurde, möglicherweise ebenfalls vorsehen kann, dass ein Weitervertrieb nur unter der Erwerbslizenz möglich ist.
Jedenfalls möglich ist in diesen Fällen jedoch eine Verbreitungsform, bei der das Lernmanagementsystem und das Plugin nicht als einheitliches Ganzes anzusehen sind. Wie oben ausgeführt ist von einem einheitlichen Ganzen immer dann auszugehen, wenn es dem Nutzer nicht möglich ist, die GPL-Bestandteile ohne weiteres als eigenständige Teile zu erkennen und zu nutzen. Ausreichend ist damit nicht eine technische Verknüpfung zweier Softwarebestandteile, vielmehr müssen die beiden Teile auch inhaltlich-funktional miteinander in Zusammenhang stehen. Von einem eigenständigen Programm ist jedenfalls dann auszugehen, wenn die erfüllten Funktionen nach der Verkehrsanschauung als typische Funktionen eines eigenständigen Programms betrachtet werden.
