Buch lesen: «Praxishandbuch Open Source», Seite 7
a) Statische vs. dynamische Verlinkung
105
Zunächst betrachten wir einmal grundsätzlich die Verlinkung von Software-Bestandteilen. Bei einer Verlinkung handelt es sich um eine Verbindung zweier Software-Bestandteile, so dass diese – ggf. noch mit mehreren anderen Software-Komponenten – ein komplettes Programm bilden. Eine solche Verbindung ist auf verschiedene Weisen möglich, je nachdem wie eng die beiden Software-Bestandteile dabei miteinander verknüpft werden. In der Regel wird hier nach statischer und dynamischer Verlinkung unterschieden.
106
Unter einer statischen Verlinkung versteht man allgemein eine feste Verbindung von zwei Software-Komponenten. Hier wird bei der Erstellung des Programms durch Kompilieren die FOSS Komponente mittels des Linkers mit dem restlichen (proprietären) Code der Software zu einer einzigen Datei zusammengefügt.22 Im Anschluss an den Kompilierprozess existiert daher nur noch ein ausführbares Programm, in dem sowohl der eigene Programmcode als auch der Code der verwendeten FOSS – oder anderer Software-Komponenten – als eine Einheit enthalten sind. Auf diese Weise ist die FOSS Komponente untrennbar mit dem restlichen Code verbunden, so dass hier im Nachhinein die FOSS Komponente weder entfernt oder ausgetauscht werden kann.
107
Eine dynamische Verlinkung ist dagegen eine lose Verbindung zwischen zwei Software-Komponenten. Die beiden Software-Komponenten werden hierbei bei der Kompilierung nicht durch den Linker zu einem einzigen gemeinsamen Programm zusammengefügt, sondern bleiben weiterhin als einzelne Bestandteile bestehen. Die proprietäre Software greift hier erst zur Laufzeit – also im Zeitpunkt der Ausführung des Programms – auf die FOSS Komponenten und deren Funktionen zu.23 Dies ermöglicht es, die FOSS Komponente auch im fertigen Programm noch zu entfernen oder zu ersetzen.
108
Backup: Für den Anfang mag ein grundsätzliches Verständnis dafür genügen, was dynamische Verlinkung bedeutet. Nämlich eine Verbindung zweier Software-Komponenten, die es ermöglicht, eine der Komponenten auch später auszutauschen (z.B. gegen eine neuere Version der Komponente oder gegen eine an die eigenen Bedürfnisse angepasste Komponente).
Die konkreten technischen Anforderungen an eine dynamische Verlinkung – so wie sie beispielsweise auch von der LGPL-2.1 ausdrücklich vorausgesetzt werden – zu kennen, ist aber relevant, um den konkreten Einsatz einer Software auf Lizenzkonformität zu überprüfen und sicherzustellen, dass der Copyleft Effekt sich nicht auf eigene, proprietäre Bestandteile der Software auswirkt.
Im Folgenden werden daher im Überblick die konkreten technischen Anforderungen an eine dynamische Verlinkung dargestellt, so wie sie von der LGPL-2.1 vorausgesetzt wird. Dies sind auch die Kriterien, von denen wir ausgehen, wenn wir in diesem Buch auf eine dynamische Verlinkung Bezug nehmen:
– Die FOSS Komponente bleibt als eigenständiges File im File System identifizierbar,
– sie interagiert nur über Standardschnittstellen mit anderer (insbesondere proprietärer) Software
– und ist zumindest theoretisch, wenn auch mit einigem Aufwand, durch den Nutzer austauschbar.
109
Die Unterscheidung der dynamischen und statischen Verlinkung für die FOSS Compliance beruht hauptsächlich auf der LGPL, da diese Lizenz spezielle Ausnahmen für eine dynamische Einbindung von unter der LGPL stehenden Programmteilen (hauptsächlich Bibliotheken) enthält. Dabei enthält die LGPL jedoch an keiner Stelle den Begriff der dynamischen Verlinkung, sondern lediglich eine Beschreibung der Voraussetzungen für eine zulässige Einbindung (siehe Rn. 108). Die LGPL hat damit zwar die Voraussetzungen der dynamischen Verlinkung, nicht aber den konkreten Begriff geprägt. Dieser wurde vielmehr durch die Anwender geprägt.
b) So linken die verschiedenen Programmiersprachen
110
Als nächstes betrachten wir nun, wie diese Arten der Verlinkung sich in der Praxis in diversen gängigen Programmiersprachen manifestieren. Denn je nachdem, welche Programmiersprache vorliegt, sind verschiedene Arten der Verlinkung möglich.
111
Programmiersprachen sind formale Sprachen, mit denen Datenstrukturen und Algorithmen, also Rechenvorschriften, formuliert werden können, die dann von einem Computer ausgeführt werden können. Sie folgen dabei einem bestimmten Regelsystem, nach dem die unterschiedlichen Anweisungen an den Computer formuliert werden können.24 Es existieren zahlreiche Programmiersprachen, die alle ihre eigenen Anwendungsgebiete haben. Hier wollen wir einige der gängigsten Sprachen vorstellen und zeigen, wie sich in diesen die Verbindung von einzelnen Programmbestandteilen unterscheiden kann.
aa) C und C++
112
Programmiersprachen, die sowohl statische als auch dynamische Verlinkungen einzelner Programmteile zulassen, sind beispielsweise C sowie die darauf aufbauende Programmiersprache C++. Die Anwendungsbereiche dieser beiden Programmiersprachen sind groß, da sowohl C als auch C++ jeweils für System- und Anwenderprogrammierung verwendet werden können. Daher tauchen diese Programmiersprachen im Bereich der FOSS auch häufig auf. In C, C++ oder anderen Programmiersprachen dieser Art, können FOSS und andere Software-Komponenten entweder mittels des Linkers bei der Kompilierung statisch mit dem restlichen Programmcode verbunden werden. Es ist aber auch möglich, mittels einer entsprechenden Schnittstelle dafür zu sorgen, dass andere, separat kompilierte FOSS und Software-Komponenten erst während der Laufzeit durch das eigene Programm aufgerufen werden.25
bb) Python
113
Eine weitere Programmiersprache, die grundsätzlich sowohl statische als auch dynamische Verlinkungen zulässt, ist Python. Ähnlich wie bei C handelt es sich hier ebenfalls um eine Programmiersprache, die sehr vielseitig einsetzbar ist, da sie mehrere Paradigmen der Programmierung unterstütz. Die meisten Python Distributionen basieren auf dynamischen Verlinkungen. Es stehen viele eigenständige Libraries zur Verfügung, auf die im eigenen Code referenziert und deren Funktionalität dann während der Laufzeit aufgerufen werden kann. Diese Libraries werden von dem System bereitgestellt, auf dem Python läuft (dies kann z.B. das Linux Betriebssystem sein). Python ermöglicht es aber auch, entsprechend benötigte Libraries statisch einzubinden. Dabei steht der Code der verwendeten Library dann nicht mehr separat auf dem System zur Verfügung, sondern wird direkt zusammen mit dem übrigen Python Code mittels des Linkers zu einer einzigen Binärdatei zusammengefügt.26
cc) Java
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
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 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
c) System Call zum Aufruf selbstständiger Anwendungsprogramme – Process Call
124
Ein anderer Fall des System Call ist der Aufruf eines selbstständigen Anwendungsprogramms. Dabei wird ein separat auf dem System bereitgestelltes, unabhängiges Executable (also ein selbstständiges Programm) durch die – ebenfalls selbstständige – Anwendungssoftware aufgerufen und ausgeführt. Auf FOSS bezogen wird also eine eigenständige FOSS Komponente lediglich durch ein anderes proprietäres Programm aufgerufen und ausgeführt. Ein Beispiel hierfür könnte sein, dass ein proprietäres Programm die Funktion beinhalten soll, PDFs anzuzeigen. Um dies zu tun, ruft die Software bei Eingabe einer PDF-Datei nun einen ebenfalls auf dem System vorhandenen, eigenständigen PDF-Reader (z.B. ein FOSS Produkt) auf und führt ihn aus, um so das PDF über diesen Reader anzuzeigen.
125
Die beiden Software-Bestandteile bleiben dabei grundsätzlich getrennt und funktionieren auch unabhängig voneinander (entsprechend dem vorherigen Beispiel könnte der PDF-Reader jederzeit auch separat verwendet werden). Bei einer so eingesetzten FOSS Komponente würde es sich also um ein komplett eigenständiges Programm handeln und nicht etwa um eine (mit dem Betriebssystem ausgelieferte) Library oder einen anderen Programmteil, der im Sinne einer dynamischen Verlinkung eingebunden wird. Aufgrund dieser Selbstständigkeit und jederzeitigen Trennbarkeit der einzelnen Programme entsteht bei dieser Art des Systemaufrufs in der Regel kein derivative work im Sinne der FOSS Lizenzen. In der Regel wird daher auch kein Copyleft entsprechender strenger FOSS Lizenzen ausgelöst, das dazu führen würde, dass beide Software-Komponenten unter dieselbe FOSS Lizenz gestellt werden müssten. Allerdings ist auch hier immer eine entsprechende Beurteilung des konkreten Einzelfalls erforderlich, um festzustellen, welche Vorgaben die jeweiligen FOSS Lizenzen beinhalten und wie die technische Umsetzung des System Call erfolgt ist.
126
Da auf Grund des gegebenenfalls nicht ausgelösten Copyleft hier in einem FOSS Compliance-Prozess eine andere Bewertung des System Calls zum Aufruf eines selbstständigen Anwendungsprogramms erfolgen würde, kann es sinnvoll sein, für den eigenen Prozess entsprechend bezeichnende Begriffe für die unterschiedlichen Arten der System Calls einzuführen. So können diese bereits bei der Sachverhaltsermittlung unterschieden und der Prozess gegebenenfalls vereinfacht werden. Wir haben daher auch für dieses Buch unterschiedliche Begriffe gewählt, um die Unterscheidung der jeweils unterschiedlichen System Calls zu vereinfachen. Soweit wir im Folgenden auf den speziellen Unterfall des System Call Bezug nehmen, bei dem ein Anwendungsprogramm ein anderes selbstständiges Programm aufruft, ohne dass ein Copyleft ausgelöst wird, sprechen wir von einem Process Call. Dieser Begriff soll veranschaulichen, dass hier keine unselbstständige Systemfunktion, sondern ein eigener selbstständiger Prozess aufgerufen wird.
