Читать книгу: «Praxishandbuch Open Source», страница 8

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

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.

 – Vertragstypologisch liegt ein Lizenzvertrag mit schenkungsrechtlichen Elementen vor.

 – Der Nutzer von FOSS leitet seine Befugnis ebenso wie jeder weitere Nutzer, Bearbeiter und Verbreiter vom (ersten) Rechtsinhaber ab; mit diesem kommt der Lizenzvertrag zustande („sternförmige“ Vertragsabschlüsse).

 – Die schriftliche Erwähnung einer Nutzungsart in FOSS Lizenzbedingungen als urheberrechtlichem Vertrag ist nur dann erforderlich, wenn diese Nutzungsart zum Zeitpunkt der Lizenzgewährung noch unbekannt war.

 – Die h.M. geht von der Wirksamkeit von FOSS Lizenzbedingungen aus, was zumindest für die strenge Copyleft Klausel kontrovers diskutiert werden kann. Die Wirksamkeit der Haftungsbeschränkungen wird allgemein verneint.

142

Im Rahmen der folgenden Ausführungen erscheint es sinnvoll, sich noch einmal vor Augen zu führen, dass die Fragen hinsichtlich des Vertragsschlusses, des Vertragsinhalts und der Wirksamkeit einzelner Klauseln nur unter bestimmten Umständen Bedeutung erlangen. Soweit ein Nutzer lediglich Software nutzt, in der FOSS enthalten ist, werden die FOSS Lizenzbedingungen und somit die Fragestellungen nicht relevant.1 Durch diese bloße Benutzung von FOSS werden gewöhnlich keine Verpflichtungen des Nutzers begründet.2 Dies folgt bereits aus § 69d Abs. 1 UrhG.

143

Soll FOSS bearbeitet und verbreitet werden, ist dafür die Einräumung von Nutzungsrechten nötig. Wir betrachten daher zuerst die vertragsrechtlichen Grundlagen in Bezug auf FOSS mit dem Ziel, aus diesen Rechtsfragen auch Argumente für die Praxis zu ziehen. Futter hierfür findet sich sowohl über die vertragsrechtliche Einordnung mit Schenkungselementen als auch über den AGB-Charakter der FOSS Lizenzbedingungen.

a) Wie FOSS Lizenzen einbezogen werden

144

FOSS Lizenzbedingungen sind für eine Vielzahl von Verträgen vorformulierte Bedingungen, die eine Vertragspartei der anderen stellt3 und die nicht individuell ausgehandelt wurden.4 Die Rechtsnatur des Vertrages und seine vertragstypologische Einordnung sind für die Einstufung der Lizenzbedingungen als Vertragsbedingungen im Sinne der §§ 305ff. BGB unerheblich.5 Bei den FOSS Lizenzbedingungen handelt es sich daher nach h.M. in Literatur6 und gefestigter Rechtsprechung7 um AGB i.S.d. § 305 Abs. 1 BGB.

aa) Wirksame Einbeziehung

145

Eine wirksame Einbeziehung der FOSS Lizenzbedingungen ist grundsätzlich zu bejahen. Der Vertragsschluss folgt den allgemeinen Regelungen,8 Angebot und Annahme gemäß §§ 145ff. BGB. Die FOSS Lizenzbedingungen enthalten dabei alle vertraglichen Hauptleistungspflichten für den Empfänger. Das Angebot ist auf Abschluss eines Lizenzvertrages ad incertas personas gerichtet und beinhaltet eine Einräumung einfacher Nutzungsrechte gemäß den Bedingungen des Lizenzvertrages.9 Vergleichbar dem Kauf gegen Höchstgebot bei eBay10 richtet sich das jeweilige Angebot nur an diejenigen potenziellen Vertragspartner, die die Lizenzbedingungen in vollem Umfang anerkennen.

146

Gemäß § 305 Abs. 2 BGB können AGB nur Vertragsbestandteil werden, wenn

 – der Rechtsinhaber den Empfänger ausdrücklich darauf hinweist,

 – der Rechtsinhaber dem Empfänger die Möglichkeit verschafft, in zumutbarer Weise von den Lizenzbedingungen Kenntnis zu nehmen,

 – und der Empfänger mit ihrer Geltung einverstanden ist.

147

Das ist bei FOSS Lizenzbedingungen aus mehreren Gründen gegeben: Man kann nämlich davon ausgehen, dass bei Abgabe des Angebots nach § 151 Satz 1 BGB auf den Zugang einer Annahmeerklärung bei dem Antragenden verzichtet wird.11 Handelt es sich bei den Lizenzbedingungen um die der GPL, bieten Ziff. 5 GPL-2.0 und Ziff. 9 GPL-3.0 hierfür entsprechende Anhaltspunkte.12 Für die Möglichkeit der Kenntnisnahme ist die Abrufbarkeit der FOSS Lizenzbedingungen im Internet als ausreichend anzusehen.13 Der Empfänger der FOSS erklärt durch seine Nutzungshandlung, für die er eine über § 69d Abs. 1 UrhG hinausgehende Befugnis benötigt, durch schlüssiges Verhalten die Annahme.14

148

Soweit im Schrifttum stets auf die englische Sprache, in der die Lizenzbedingungen abgefasst sind, verwiesen wird, um die Einbeziehung in Frage zu stellen,15 kann dies nicht überzeugen. Zum einen werden die Empfänger von FOSS regelmäßig unternehmerisch handeln,16 zum anderen ist Englisch die Sprache der Programmierer und somit in diesem Kontext schlicht üblich.17

bb) Wirksamkeit

149

Als AGB unterliegen die Klauseln der FOSS Lizenzen der Wirksamkeitskontrolle. Das kann sich bei verschiedenen Klauseln auswirken und zu Argumenten für die Verwendung in den Vertragskonstellationen führen (siehe hierzu den Praxisfall im Anhang 839ff.). Alle Juristen stürzen sich im Zusammenhang mit AGB-Kontrolle für FOSS Lizenzbedingungen auf den offenkundigen Verstoß: die Haftungsklauseln, die in der Regel zwar mit amerikanischem Recht vereinbar sein mögen, mit deutschem Recht jedoch nicht. Es besteht allgemein Einigkeit, dass die Haftungsklauseln in FOSS Lizenzen so gut wie immer gegen §§ 309 Nr. 8 b) aa), 309 Nr. 7, 307 Abs. 1 Satz 1, Abs. 2 Nr. 2 BGB verstoßen.18

150

Weniger eindeutig und deutlich weniger beleuchtet wird ein anderer Aspekt, der im Rahmen der Wirksamkeitskontrolle diskutiert werden kann, nämlich die Frage nach der Wirksamkeit der Copyleft Klauseln, aber vor allem der Rechterückfallklausel. So eine Klausel sieht beispielsweise die GPL-2.0 vor; hält sich der Lizenznehmer nicht an die Lizenzbedingungen, erfolgt ein automatischer Rechterückfall (siehe bereits Rn. 32). Hier kommt § 307 BGB in Betracht, wenn solche Klauseln den Empfänger der FOSS unangemessen benachteiligen.

151

Das LG München I19 hat durch ökonomisch effiziente Prüfung die Lizenzbedingungen der GPL-2.0 betrachtet, konkret die Ziff. 2, 3 und 4 GPL-2.0. Es kommt zum Ergebnis, dass aufgrund der gesamten Vertragskonstruktion der Vertragspartner des Verwenders nicht unangemessen benachteiligt wird.20 Das LG München I nimmt mit der h.M. eine auflösend bedingte Einigung an und entscheidet, dass Ziff. 4 GPL-2.0 keine Beschränkung des Nutzungsrechts darstellt, die im Übrigen über § 31 Abs. 1 Satz 2 UrhG gestattet wäre.

152

Es hat dennoch ausgeführt, dass man vermutlich zu einer Teilunwirksamkeit der Klausel käme, wenn man von einer Unwirksamkeit von Ziff. 4 Satz 2 und 3 GPL-2.0 ausginge. Dann bliebe Ziff. 4 Satz 1 GPL-2.0 stehen und ein Verstoß gegen diesen hätte nur schuldrechtliche Auswirkungen, sprich könnte zu Kündigungen oder Schadensersatz führen. Die Annahme einer Unwirksamkeit der gesamten Klausel ist unwahrscheinlich, da inhaltlich und sprachlich ein zulässiger Regelungsteil abspaltbar ist, der eine eigenständige, sinnvolle Regelung enthält.21

153

Die Regelung der Ziff. 4 GPL-2.0 begegnet auch aus anderen Gründen erheblichen Bedenken. Ein Verstoß gegen das Transparenzgebot wird zwar abzulehnen sein.22 Aber ein Verstoß gegen § 307 BGB könnte wegen eines Widerspruches zu § 314 BGB gegeben sein.23 Gemäß § 314 BGB ist für die außerordentliche fristlose Beendigung eines Dauerschuldverhältnisses ein wichtiger Grund erforderlich. Nach der GPL genügt bereits die geringste Pflichtverletzung, einen „Rückfall“ der Rechte auszulösen.24 Dies ist wegen der grundsätzlich gegebenen Erforderlichkeit einer vorherigen Abmahnung problematisch.25 Man könnte über § 139 BGB oder § 306 BGB zu dem Ergebnis gelangen, dass vor einem Rechterückfall der Empfänger erst abgemahnt werden müsste, den vertragsgemäß geschuldeten Zustand herzustellen.26 Ein deutsches Gericht könnte mit diesem Argument – wenn und soweit es einmal mit dieser Frage ernsthaft befasst sein wird – zu der Erkenntnis gelangen, dass die in Ziff. 4 GPL-2.0 vorgesehene Rechtsfolge unangemessen ist.27 Der Abgemahnte könnte dann durch entsprechende Herstellung des lizenzkonformen Zustandes den Verstoß heilen, was vermutlich am ehesten dem Sinn und Zweck der FOSS Lizenzen entspräche.

154

Dieser Argumentation für eine Abmahnung vor Rechtsfortfall könnte entgegengehalten werden, dass das Urheberrecht grundsätzlich beim Erwerb von Nutzungsrechten streng ist. Ein gutgläubiger Erwerb ist nicht möglich. Zudem wird in dieser speziellen Konstruktion die FOSS unentgeltlich überlassen und lediglich über die FOSS Lizenzbedingungen das Nutzungsrecht mit den Vorgaben verknüpft. Damit scheint es wiederum gerechtfertigt, auch den strengen Rechterückfall hinzunehmen. In jedem Fall kann hier kontrovers diskutiert werden.