Christian Galetzka - Praxishandbuch Open Source

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, bei der grundsätzlich beide Programme unabhängig voneinander funktionsfähig sind, kann hier ebenfalls überwiegend davon ausgegangen werden, dass durch die Verbindung mittels einer Pipe kein derivative work im Sinne der FOSS Lizenzen entsteht und somit regelmäßig kein Copyleft ausgelöst wird. Die FSF hat sich in ihren FAQ sogar ausdrücklich dazu geäußert, dass Pipes zumindest für die GPL kein derivative work begründen.36

134

Eine weitere Möglichkeit zur Kommunikation bzw. zum Datenaustausch zwischen Programmen stellen die sog. Sockets dar. Sockets sind Kommunikationsendpunkte, die zum Austausch von Daten dienen und vom jeweiligen Betriebssystem bereitgestellt werden. Ein Programm verwendet Sockets, um Daten mit anderen Programmen auszutauschen. Dabei spielt es keine Rolle, ob sich die Programme innerhalb eines Rechnersystems befinden oder auf unterschiedlichen, über ein Netzwerk verbundenen Systemen. Im Vergleich zu Pipes sind Sockets bidirektional, über sie können Daten also sowohl empfangen als auch gesendet werden.37

135

Ursprünglich wurden Sockets ebenfalls zunächst für UNIX entwickelt, finden sich heute aber ebenfalls nicht ausschließlich im UNIX- bzw. Linux Bereich, sondern auch in anderen gängigen Betriebssystemen wie Windows oder OS/2.

136

Sockets bilden eine plattformunabhängige, standardisierte Schnittstelle zwischen der Netzwerkprotokoll-Implementierung des Betriebssystems und der eigentlichen Anwendungssoftware. Ein Computerprogramm fordert einen Socket vom Betriebssystem an und das Betriebssystem hat die Aufgabe, alle benutzten Sockets sowie die zugehörigen Verbindungsinformationen zu verwalten.38 Ähnlich wie bei den Pipes bleiben die Programme also grundsätzlich unabhängig voneinander und kommunizieren nur über standardisierte, vorgegebenen Schnittstellen miteinander. Die jeweilige Funktionsfähigkeit des einzelnen Programms wird durch den Socket nicht beeinträchtigt. Einige der FOSS Lizenzen mit Copyleft machen die Kommunikation mit anderer Software über Standardschnittstellen zur Voraussetzung für eine dynamische Verlinkung (siehe Rn. 107f.). Allerdings geht man bei der dynamischen Verlinkung in der Regel von Programmteilen aus, die unselbstständig sind. Bei der Kommunikation über Sockets kommunizieren jedoch selbstständige Programme miteinander, so dass hier in der Regel nicht von einem derivative work auszugehen ist. Zumindest für die GPL hat die FSF auch hier in ihren FAQs darauf hingewiesen, dass nach ihrer Ansicht Sockets kein derivative work erzeugen.39 Wie immer gilt es aber auch hier, sich die genauen Vorgaben der FOSS Lizenzen sowie die konkrete technische Umsetzung der Socket-Verbindung anzusehen und abzuwägen.

137

Die Kommandozeile oder Befehlszeile – im Englischen auch command line genannt – ist ein Teil eines Computerprogramms, der es ermöglicht, eine vom Nutzer eingegebene Textzeile entgegenzunehmen, im Kontext zu interpretieren und auszuführen. Kommandozeilen waren historisch die erste Methode zur Interaktion mit Betriebssystemen. Bei vielen Betriebssystemen wird die Kommandozeile von einer Shell bzw. einem Interpreter ausgewertet und dann die entsprechend eingegebene Funktion ausgeführt. Auch einige Anwendungsprogramme bieten Kommandozeilen, z.B. als Alternative zur grafischen Benutzeroberfläche, an.40 Im Umfeld des Betriebssystems können mit der Kommandozeile also andere Funktionen und Programme aufgerufen werden. Bei Anwendungsprogrammen dient die Kommandozeile zwar eher dazu, Funktionen innerhalb der Software auszuführen, sie kann aber auch dazu genutzt werden, andere Programme und Programmteile aufzurufen und auszuführen.

138

Ein Aufruf über die Kommandozeile stellt also eine weitere Möglichkeit der Kommunikation zwischen zwei Programmen dar. Auch hier stellt sich daher wieder die Frage, wie diese Art der Kommunikation zu bewerten ist, insbesondere hinsichtlich der Erzeugung eines derivative work.

139

Bei einem Aufruf über die Kommandozeile bleiben das aufrufende und das aufgerufene Programm grundsätzlich voneinander getrennt. Das aufgerufene Programm wird lediglich gestartet und ausgeführt und es wird keine dauerhafte Verbindung zwischen den beiden Programmen geschaffen. Sie sind weiterhin selbstständig funktionsfähig. Die Voraussetzungen für ein derivative work sind daher in der Regel nicht erfüllt. Dies bestätigt die FSF für die GPL auch zumindest für den Fall, dass der Aufruf über die Kommandozeile lediglich der Kommunikation zwischen zwei Programmen dient.41 Dies wäre z.B. der Fall, wenn – ähnlich wie bei den Pipes – Informationen oder Ergebnisse aus einem Programm in dem anderen Programm angezeigt oder weiterverwertet werden. Sollte die Kommunikation mit dem anderen Programm allerdings so tiefgehend sein, dass hierbei komplexe interne Datenstrukturen der Programme ausgetauscht werden – die Programme also deutlich enger miteinander verbunden werden, als dies bei einem reinen Austausch von Ergebnissen der Fall wäre – könnte dies laut der FSF wiederum für das Entstehen eines derivative work und damit auch für das Auslösen eines Copyleft sprechen.42 Wie immer müssen also auch im Fall des Aufrufs über eine Kommandozeile die konkreten Umstände überprüft und bewertet werden, insbesondere wie stark der Kommandozeilenaufruf die beiden Programme letztlich verbindet.

30https://de.wikipedia.org/wiki/Systemaufruf. 31The Definitive Guide To Linux System Calls, https://blog.packagecloud.io/eng/2016/04/05/the-definitive-guide-to-linux-system-calls/#what-is-a-system-call. 32https://www.kernel.org/doc/html/v4.18/process/license-rules.html. 33https://www.it-administrator.de/lexikon/mounten.html. 34https://whatis.techtarget.com/de/definition/Pipe. 35https://de.wikipedia.org/wiki/Pipe_(Informatik). 36FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation. 37https://www.itwissen.info/Socket-socket.html. 38FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation. 39https://www.itwissen.info/Socket-socket.html. 40https://de.wikipedia.org/wiki/Kommandozeile. 41FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation. 42FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation: „But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.“