Christian Galetzka - Praxishandbuch Open Source

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: 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

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.

127

Eine weitere Möglichkeit, Zugriff auf bestimmte Dateien und Funktionen herzustellen, ist das sog. Mounten oder Einhängen. Dabei wird – insbesondere bei Unix, aber auch anderen Betriebssystemen – ein (Teil-)Dateisystem an einer bestimmten Stelle, nämlich dem Einhängepunkt oder Mountpoint, innerhalb eines anderen Dateisystems verfügbar gemacht, so dass der Benutzer auf die dort vorhandenen Dateien und Funktionen zugreifen kann. Das so gemountete Teildateisystem erscheint für den Benutzer dabei als Bestandteil des Gesamtdateisystems.33

128

Diese Art der Einbindung wird häufig genutzt, um Festplatten in ein bereits bestehendes Betriebssystem einzugliedern und diese damit für das Betriebssystem nutzbar zu machen und so entweder auf die bereits auf der gemounteten Festplatte gespeicherten Informationen zugreifen zu können oder es dem Betriebssystem zu ermöglichen, eigene Informationen dort abzulegen.

129

Auch hier könnte man darüber nachdenken, ob durch das Zusammenführen der Dateisysteme nicht ein derivative work entsteht und sich auf einem der Dateisysteme vorhandene FOSS Komponenten mit Copyleft auf das gesamte System auswirken. Da hier zwar das eine Dateisystem auf das andere zugreift und dessen Informationen verwertet, die Dateisysteme aber grundsätzlich – häufig sogar auf unterschiedlichen Hardware-Komponenten – voneinander getrennt sind und eigenständig voneinander funktionieren würden, entsteht durch das Mounten in der Regel kein derivative work. Die einzelnen auf den Dateisystemen vorhandenen FOSS Komponenten sind hier eher als eine Zusammenstellung diverser einzelner Programme auf einem gemeinsamen Datenträger zu sehen. Diese Art der Aggregation wird z.B. von der GPL ausdrücklich nicht als derivative work betrachtet. Auch hier kommt es aber immer auf eine genaue Betrachtung der jeweiligen Umstände des konkreten Einzelfalles an.

130

Pipes oder Pipelines stellen ebenfalls eine Möglichkeit der Interaktion bzw. Kommunikation zwischen zwei Programmen oder Programmteilen dar. Die Pipe stellt dabei einen Datenstrom zwischen zwei Prozessen dar, durch den Informationen von einem Programmprozess zu einem anderen übertragen werden. Vereinfacht gesagt erzeugt ein Computerprogramm ein Ergebnis als Output. Dieser Output wird dann über die Pipe an ein anderes Programm übertragen, das diesen Output des ersten Programms als Input wieder aufnimmt. Die Informationen werden dabei vom System temporär zwischengespeichert, bis das empfangende Programm die Informationen aufnehmen und auslesen kann. Eine Pipe funktioniert dabei immer nur in eine bestimmte vorgegebene Richtung. Daten können von einem Programm damit also entweder weitergegeben oder empfangen werden.34