Christian Galetzka - Praxishandbuch Open Source

114

Bei der Programmiersprache Java, die für die Programmierung von Anwendungen wie Desktop-Programmen, Webanwendungen oder Apps verwendet wird, sieht dies ein wenig anders aus. Hierbei handelt es sich um eine objektorientierte Programmiersprache, bei der die einzelnen Bestandteile und Funktionen in sog. JARs bereitgestellt werden. Die JARs entsprechen dabei grundsätzlich dem, was in den meisten anderen Programmiersprachen als Library bezeichnet wird. Werden zwei oder mehr JARs miteinander verbunden, geschieht dies in Java ausschließlich über Schnittstellen, über die die JARs dann mit anderen JARs kommunizieren und so ein ganzes Programm bilden. Die Verlinkung zwischen zwei in Java programmierten Software-Bestandteilen ist daher immer als eine dynamische Verlinkung einzuordnen. Eine statische Verlinkung, bei der mehrere einzelne Bestandteile fest miteinander zu einem einzigen Programm verbunden werden, ist in dieser Programmiersprache nicht vorgesehen.27

115

Backup: Sind unter LGPL stehende Programme in Java nutzbar?

Die LGPL enthält Ausnahmen vom Copyleft für solche Programmteile, die mittels einer dynamischen Verlinkung mit dem restlichen Programmcode verbunden sind. Aufgrund der Struktur von Java, die ohnehin immer eine dynamische Verlinkung zwischen einzelnen Programmteilen und Bibliotheken vorsieht, sollte der Einsatz LGPL lizenzierter Software daher unproblematisch sein. Dennoch findet man gerade in Entwicklerforen häufig Verwirrung darüber, ob die LGPL für eine in Java programmierte Anwendung überhaupt bestimmungsgemäß eingesetzt werden kann.28

Die FSF – die Urheber und Herausgeber der LGPL – hat sich zu diesen Äußerungen klar positioniert 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

22Indiana University, About linkers and dynamic and static linking, https://kb.iu.edu/d/akqn. 23Indiana University, About linkers and dynamic and static linking, https://kb.iu.edu/d/akqn. 24https://de.wikipedia.org/wiki/Programmiersprache. 25https://de.wikipedia.org/wiki/C_(Programmiersprache). 26https://wiki.python.org/moin/BeginnersGuide/Overview; http://openbookproject.net/thinkcs/python/english3e/way_of_the_program.html. 27Ullenboom, http://openbook.rheinwerk-verlag.de/javainsel, Kap. 1.2. 28https://developers.slashdot.org/story/03/07/17/2257224/lgpl-is-viral-for-java. 29Turner, https://www.gnu.org/licenses/lgpl-java.en.html.

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.

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.

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.