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.
d) Mounten von Dateisystemen
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.
e) Pipes
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
131
Diese Art der Kommunikation zwischen zwei Prozessen wurde ursprünglich für das Betriebssystem UNIX erfunden und ist daher häufig im UNIX bzw. Linux Umfeld zu finden. Pipes existieren aber genauso für andre Betriebssysteme wie z.B. Windows oder das IBM Betriebssystem OS/2.
132
Die Pipe stellt einen Kanal zwischen zwei Programmen her. Allerdings bleiben die Programme dabei getrennt voneinander, so dass jedes der Programme grundsätzlich selbstständig ohne das andere Programm nutzbar ist. Die Pipe ermöglicht es lediglich, Informationen bzw. Ergebnisse, die von einem Programm erzeugt werden, mittels eines anderen Programms wieder aufzunehmen und weiter zu verarbeiten. Die an einer Pipe beteiligten Programme nehmen also Eingabedaten von ihrer Standardeingabe entgegen und stellen Ausgabedaten auf ihrer Standardausgabe bereit. Dabei müssen die beiden Programme nicht einmal wissen, von welchem anderen Programm die Eingabe kommt bzw. an welches Programm die Ausgabe weitergeliefert wird. Je nach Art der Pipe, müssen die Programme daher keinen gemeinsamen Ursprung aufweisen, sondern können die Pipe einfach zur Laufzeit des Programms zum Lesen oder Schreiben von Informationen öffnen.35
133
Aufgrund dieser sehr losen Verbindung zwischen den Programmen,