Praxishandbuch Open Source. Christian Galetzka
und widerlegt, dass die LGPL für Java nicht kompatibel sei. Laut der FSF ist die LGPL mit allen bekannten Programmiersprachen anwendbar.
Die Struktur von Java sieht vor, dass eine von einer Anwendung benötigte Bibliothek (die dann z.B. unter der LGPL lizenziert ist) als separate JAR-Datei vorliegt. Die Anwendung nutzt dann eine sog. Import-Funktion, um auf die Bibliothek zuzugreifen. Beim Kompilieren der Anwendung werden daher Funktionssignaturen gegen die Bibliothek überprüft und so eine Verknüpfung hergestellt. Die Bibliothek bleibt dabei aber grundsätzlich ein eigenständiger Bestandteil, auf dessen Funktionen zugegriffen wird, der aber nicht komplett in den Code der Anwendung übernommen wird.
Die Bibliothek erfüllt daher grundsätzlich alle Anforderungen, die die LGPL an eine dynamische Verlinkung stellt, da weiterhin gewährleistet bleibt, dass ein Nutzer die Bibliothek verändern oder austauschen kann.29
22 Indiana University, About linkers and dynamic and static linking, https://kb.iu.edu/d/akqn. 23 Indiana University, About linkers and dynamic and static linking, https://kb.iu.edu/d/akqn. 24 https://de.wikipedia.org/wiki/Programmiersprache. 25 https://de.wikipedia.org/wiki/C_(Programmiersprache). 26 https://wiki.python.org/moin/BeginnersGuide/Overview; http://openbookproject.net/thinkcs/python/english3e/way_of_the_program.html. 27 Ullenboom, http://openbook.rheinwerk-verlag.de/javainsel, Kap. 1.2. 28 https://developers.slashdot.org/story/03/07/17/2257224/lgpl-is-viral-for-java. 29 Turner, https://www.gnu.org/licenses/lgpl-java.en.html.
4. Diese Befehlsstrukturen müssen Juristen erst recht verstehen
116
– Bei anderen Arten von Befehlsstrukturen zur Interaktion von Software ist im Hinblick auf das Auslösen eines Copyleft immer eine genaue Betrachtung erforderlich, inwieweit die Programmteile dabei selbstständig und getrennt voneinander funktionsfähig bleiben.
– Selbst für sog. System Calls oder Systemaufrufe macht es daher Sinn zu unterschieden, ob mit diesen ein selbstständiges anderes Programm oder lediglich ein unselbstständiger Programmteil wie eine Bibliothek aufgerufen wird.
117
Neben den gerade beschriebenen Arten der Verlinkung gibt es auch noch andere Mechanismen und Befehlsstrukturen, die dafür sorgen, dass unterschiedliche Software-Bestandteile miteinander interagieren. Da einige von diesen Mechanismen sich ebenfalls auf die lizenzrechtliche Bewertung einer FOSS Komponente auswirken können, wollen wir auch hierzu einen kurzen Überblick geben, welche weiteren Arten der Interaktion bzw. Verbindung es hier gibt und wie sich diese ggf. auf eine rechtliche Bewertung auswirken können.
a) System Call
118
Ein Mechanismus, der im Zusammenhang mit FOSS häufig auftaucht, ist der System Call. Ein System Call oder auch Systemaufruf beschreibt eine Methode, die von Anwendungsprogrammen genutzt wird, um mit dem Systemkern zu kommunizieren und so die vom Betriebssystem bereitgestellten Funktionen auszuführen, wie z.B. das Lesen einer Datei. Die System Calls stellen also die Kommunikation zwischen Anwendungsprozess und Betriebssystem her. Bekannt ist der Begriff hauptsächlich aus dem Linux Umfeld, aber auch bei anderen Betriebssystemen wie Unix oder Windows funktioniert die Kommunikation zwischen Anwendungsprogramm und Kernel auf eine ähnliche Weise.30
Abbildung 2: Kernel Architektur und System Call© Jun Rechtsanwälte (CC BY-SA 4.0)
119
Allerdings wird der Begriff des System Call nicht ausschließlich für die Kommunikation zwischen Anwendungsprogrammen und Kernel verwendet. Häufig dient der Begriff auch dazu, das Zusammenspiel zweier unabhängiger Anwendungsprogramme zu beschreiben. Ein System Call kann also auch einen Fall beschreiben, bei dem ein separat auf dem System bereitgestelltes, unabhängiges Executable (also ein selbstständiges Programm) durch eine andere unabhängige Anwendungssoftware aufgerufen und ausgeführt wird.
120
Da der Begriff des System Call also nicht nur einen konkreten Fall abbildet, ist es sinnvoll, hier die unterschiedlichen Arten von System Calls voneinander abzugrenzen und sich ggf. eigene geeignete Begriffe zu schaffen, um bestimmte Arten von System Calls eindeutig bezeichnen zu können. Insbesondere da die unterschiedlichen Arten von System Calls im Rahmen eines FOSS Compliance-Prozesses durchaus zu einer unterschiedlichen Bewertung führen können. Insbesondere dann, wenn es darum geht, zu bewerten, ob möglicherweise ein Copyleft ausgelöst wird. Für dieses Buch unterschieden wir daher grundsätzlich nach zwei Arten von System Calls, die im Folgenden näher beschrieben werden.
b) System Call zum Aufruf unselbstständiger System- oder Programmfunktionen
121
Ein System Call zum Aufruf einer unselbstständigen System- oder Programmfunktion beschreibt den Umstand, dass eine separat auf dem System bereitgestellte Funktionalität (z.B. in Form einer Library) durch eine Anwendungssoftware aufgerufen und ausgeführt wird. Der proprietäre Programmcode ruft also beispielsweise die Funktionalität einer ebenfalls auf dem System befindlichen FOSS Komponente auf und integriert diese in den eigenen Ablauf. Ein gutes Beispiel für eine solche Art des System Call sind beispielsweise die System Calls bei Linux, auch Linux SysCalls genannt.31
122
Vergleicht man diese Art des System Call mit der weiter oben (Rn. 107f.) bereits beschriebenen dynamischen Verlinkung, so wirken diese beiden Arten der Interaktion von Software-Komponenten fast identisch. Bei einem solchen System Call ist es daher grundsätzlich möglich, dass durch seine Verwendung der Copyleft Effekt strenger FOSS Lizenzen ausgelöst werden kann. Da in diesem Fall die aufgerufene Komponente kein eigenständiges Executable darstellt, sondern es sich lediglich um einen unselbstständigen Programmteil bzw. einen Teil des Systemkerns handelt, kann ein derivative work im Sinne der FOSS Lizenzen entstehen. In diesen Fällen muss daher verstärkt auf die konkreten Vorgaben der jeweiligen FOSS Lizenzen sowie die technische Umsetzung des System Call geachtet werden. Gerade für Programmen, die auf einem Linux Betriebssystem laufen und daher entsprechende System Calls zum Kernel benötigen, um die dort bereitgestellten Funktionen nutzen zu können, ist das Problem bereits bekannt und wurde hier durch die Linux-syscall-exception-to-GPL gelöst. Diese stellt eine Ausnahme dar, nach der bei entsprechender Einbindung der Libraries in andere Anwendungsprogramme als System Calls über UAPI gerade kein derivatve work entsteht.
123
Backup: Linux-syscall-exception-to-GPL und Linux-syscall-note
Der Linux kernel steht grundsätzlich unter der GPL-2.0, sog. Syscall Note, enthält aber eine Ausnahme, die eine weitere Ausbreitung der GPL-2.0 auf verbundenen Code verhindert:
„Usage-Guide: This exception is used together with one of the above SPDX-Licenses to mark user space API (uapi) header files so they can be included into non GPL compliant user space application code. To use this exception add it with the keyword WITH to one of the identifiers in the SPDX-Licenses tag: <SPDX-License> WITH Linuxsyscall-note
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall