f) Sockets
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.
g) Aufruf über Kommandozeile
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.
30 https://de.wikipedia.org/wiki/Systemaufruf. 31 The 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. 32 https://www.kernel.org/doc/html/v4.18/process/license-rules.html. 33 https://www.it-administrator.de/lexikon/mounten.html. 34 https://whatis.techtarget.com/de/definition/Pipe. 35 https://de.wikipedia.org/wiki/Pipe_(Informatik). 36 FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation. 37 https://www.itwissen.info/Socket-socket.html. 38 FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation. 39 https://www.itwissen.info/Socket-socket.html. 40 https://de.wikipedia.org/wiki/Kommandozeile. 41 FSF, FAQ about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation. 42 FSF, 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.“
Kapitel III Rechtliche Grundlagen: insbesondere Lizenzvorgaben und Copyleft
140
Mit diesem Kapitel wollen wir weder mit detaillierter Darstellung von juristischen Meinungsstreitigkeiten langweilen, noch uns an die Stelle derjenigen Fachautoren setzen, die den Einsatz von FOSS mit einem ganzheitlichen dogmatischen Ansatz aller juristisch-relevanten Fragestellungen behandeln wollen. Dennoch ist das Verständnis des „rechtlichen Grundvokabulars“ im Zusammenhang mit FOSS essenziell für die Einordnung des konkreten Anwendungsfalls und vor allem auch für die Lösung von rechtlichen Problemen im Bereich FOSS durch rechtliche Argumentation (hierzu ausführlich (Rn. 723ff.).
1. FOSS Lizenzen sind AGB – es gilt Schenkungsrecht
141
– FOSS Lizenzbedingungen sind AGB und nach h.M. wirksam einbezogen.
–