Praxishandbuch Open Source. Christian Galetzka

Praxishandbuch Open Source - Christian Galetzka


Скачать книгу
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.

       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

      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

      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


Скачать книгу