Читать книгу Praxishandbuch Open Source - Christian Galetzka - Страница 43

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 under the heading of ‚derived work‘. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. – Also note that the only valid version of the GPL as far as the kernel is concerned is _this_particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. – Linus Torvalds“.

Diese Dokumentationsdatei enthält also eine Beschreibung, wie Source Code Dateien zu kommentieren sind, um ihre Lizenz klar und deutlich hervorzuheben und ein mögliches Copyleft für kommerziellen Code zu vermeiden.

Die User-Space-API (UAPI) Header Dateien stellen dabei die Schnittstelle von User-Space-Programmen zum Kernel her. Gemäß dem Hinweis in der in Linux enthaltenen Kernel COPYING Datei ist die syscall-Schnittstelle eine klare Grenze, die dafür sorgt, dass die GPL-Anforderungen nicht auf jede (kommerzielle) Software ausgeweitet werden, die diese Schnittstelle zur Kommunikation mit dem Kernel verwendet. Um die Schnittstelle für kommerzielle Software nutzen zu können, ohne ein derivative work zu erzeugen und das Copyleft der GPL-2.0 auszulösen, müssen die UAPI Header in alle Quelldateien eingebunden werden, die eine ausführbare Datei erzeugen, die auf dem Linux kernel läuft bzw. auf diesen zugreift.32