Kitabı oku: «Praxishandbuch Open Source»

1. Wie naiver Einsatz kostenloser Software Ihr Unternehmen bedrohen kann

5

 – Die FOSS Idealisten wollten die Software-Entwicklung von den Beschränkungen des Urheberrechts befreien, knüpften die Freiheit aber an Bedingungen.

 – Alternativlosigkeit von FOSS wird schnell behauptet, sollte aber kritisch hinterfragt werden.

 – Vor- und Nachteile sollten bei einem Einsatz von FOSS gut abgewogen werden, insbesondere wenn es kommerziell lizenzierte Alternativen gibt.

 – Neben Rufschäden drohen auch gerichtliche Verfahren bei FOSS Lizenzverletzungen.

6

Welche Motivation steckt hinter dem FOSS Konzept? Die urheber- und patentrechtlichen Beschränkungen von kommerzieller Software stellen sich als Hinderungsgrund für die kreative Entfaltung dar. Hätten nicht alle mehr davon, wenn jeder auf die bestehende Software aufsetzen könnte und dann seine eigenen Ergebnisse ebenfalls wieder im Source Code bereitstellt? Die Grundidee war einfach und altruistisch. Der Idealismus stößt jedoch an Grenzen, wenn sich zwar alle bedienen wollen, wichtige Fortentwicklungen dann jedoch unter kommerziellen Lizenzen verwertet wurden. So wurde die gegenseitige Freizügigkeit zur einklagbaren Bedingung.

a) Am Anfang stand die Idee: Freiheit von Copyrightzwängen

7

Der Entwickler Richard Stallman war einer der ersten, der die Idee von FOSS prägte. Zur Erläuterung verwies er darauf, dass das Konzept „frei“ i.S.v. Freiheiten, nicht i.S.v. nur kostenfrei bedeuten soll.

„To understand the concept, you should think of ‚free‘ as in ‚free speech‘, not as in ‚free beer‘.“

ist das wesentliche, von Stallman entwickelte Leitmotiv der FOSS Community.5 Mit verfügbarem Source Code könnten alle Entwickler an der Lösung aller Probleme und für alle benötigten Funktionen weltweit zusammenarbeiten, ohne dass jemand Wissen für sich behält.

aa) Wie sich FOSS verbreitet hat

8

Von diesem Ideal ist die heutige Realität jedoch deutlich entfernt. Der Gedanke, Geld für Software-Entwicklung auszugeben und die Ergebnisse dann an die Konkurrenz zu verschenken, erscheint in vielen Branchen noch immer einigermaßen abwegig. Hinzu kommt die Sorge vor der Aufdeckung von Sicherheitslücken, wenn Code offengelegt wird. Zwar wird viel FOSS eingesetzt, häufig aber eingebettet in kommerziellen Code.

9

Zur Jahrtausendwende war FOSS Software schon weit verbreitet, für manche seriösen Anwender aber gleichwohl anrüchig. Software-Anwender wollten einen Lizenzgeber haben, den sie in Haftung nehmen können, wenn etwas an der Software nicht funktioniert. Nur Freaks, die sich von Pizza und Cola ernährten, betrieben Linux Server zuhause, während seriöse Unternehmen mit viel Mühe Windows NT-Server am Laufen hielten. Die Entscheidung für FOSS Anwendungen war nicht alternativlos, erfolgte häufig aus einer bewussten Entscheidung zugunsten der Quelloffenheit und im Konsens mit dem Grundprinzip, dass man im Gegenzug zur kostenlosen Zurverfügungstellung der Software auch seine Bearbeitungen an die Community zurückspielen werde. In den folgenden Dekaden entstanden eine Kommerzialisierung von FOSS und eine Entkopplung von diesem altruistischen Grundverständnis.

10

Heutige Software-Entwickler beginnen ihren Beruf mit der Überzeugung, dass die Mehrheit aller Entwicklungsaufgaben unter Einbindung einer FOSS Komponente gelöst werden könne. Der Gedanke, auf FOSS zu verzichten und stattdessen alles von Hand zu programmieren, erscheint so absurd wie der Vorschlag an den Bäcker, sein eigenes Mehl zu mahlen. Während die Open Source Communities zwar gewachsen sind, wuchs aber auch der Anteil der kommerziellen Anwender, die unter keinen Umständen ihre eigenen Software-Quellen offen bereitstellen würden. Diese unterschiedlichen Einstellungen spielen eine Rolle bei der Auslegung der Lizenzen, wenn der Wortlaut nicht ausreicht und auf den mutmaßlichen Willen des Lizenzgebers abgestellt werden soll. Hier wird in beide Richtungen leidenschaftlich argumentiert, dass die FOSS Lizenz entweder jegliche kommerzielle Nutzung ohne unüberwindbare Hindernisse zulassen wollte oder anderseits der vollständige Support für einen Austausch gewährleistet sein muss.

bb) Wo FOSS verzichtbar ist und wo nicht

11

Software-Entwickler haben gelegentlich Mühe, ihren Inhouse-Juristen zu erklären, dass ein kompletter Verzicht von FOSS genauso wenig denkbar ist wie der Vorschlag, auf sämtliche Copyleft Lizenzen zu verzichten. Wer sich auf ein Linux Ökosystem eingelassen hat, kann den Einsatz von GPL nicht kategorisch ausschließen. Das einfache Modell, Lizenzen in Gut und Böse einzuteilen, hält dem Realitätscheck nicht lange stand. Wohl dem, der bei Entwicklung seiner Lizenzrichtlinien rechtzeitig mit seinen Entwicklern gesprochen hat.

12

Basic: Copyleft (siehe Rn. 225ff.)

Das ist das zentrale Prinzip des FOSS Ideals. Hat die Lizenz ein Copyleft, so muss ein von der FOSS Komponente „abgeleitetes Werk“ ebenfalls unter den Bedingungen der FOSS Lizenz verfügbar gemacht werden. Es gibt Lizenzen mit strengem Copyleft, die dieses Prinzip voll umsetzen, andere mit beschränktem Copyleft, die teils Ausnahmen vorsehen, sowie Lizenzen ohne Copyleft, die nur die Einhaltung anderer Bedingungen vorsehen. In der Regel wollen Unternehmen Copyleft vermeiden, um eigenen bzw. proprietären Code nicht im Source Code unter einer FOSS Lizenz freigeben zu müssen, damit sie die Lizenzvorgaben einhalten.

13

Auf der anderen Seite wird das Argument der technischen Notwendigkeit und Alternativlosigkeit viel zu häufig hingenommen. Wer sich dann im nächsten Schritt auch sagen lässt, dass die Einhaltung der theoretischen Bedingungen praktisch oder wirtschaftlich unmöglich ist, findet sich im Dilemma, zwischen Lizenzverstoß und Lästigkeit entscheiden zu müssen. Man solle doch pragmatisch sein, statt Probleme zu schaffen, wettert der CTO gegenüber der Rechtsabteilung und diese antwortet dann mit einer Strafbarkeitswarnung an den CEO. Diese Eskalation ist am Ende peinlich, wenn sich später herausstellt, dass eine legale Lösung nur aus Unfähigkeit übersehen wurde.

14

Zugegeben, an FOSS kommt man kaum vorbei, sobald ein Stromverbraucher mehr macht, als einen Wolfram-Draht zu erwärmen. Früher konnte man die typischen Einsatzfelder von FOSS noch mit Linux Servern beschreiben, während eingebettete Software häufiger individuell programmierte Software enthielt. Mit dem Internet der Dinge ist kaum noch eine Anwendung zu primitiv, um nicht mit FOSS umgesetzt zu werden. Eine Glühbirne kommt heute mit WLAN-Empfang auf FOSS Basis und synchronisiert das Programm mit Heizung, Kamera und Lautsprecher, ebenso das ferngesteuerte Sexspielzeug. Was kommuniziert, enthält vermutlich auch FOSS.

15

Kommerzielle Betriebssysteme wie iOS oder Windows enthalten bereits selbst FOSS und die dafür geschriebenen Anwendungsprogramme erst recht. Selbst die Steuerung einer Sieben-Segment-Anzeige wird gelegentlich mit FOSS realisiert. Wenn man FOSS freie Systeme sucht, müsste man daher schon auf die analoge Ebene des Operationsverstärkers zurückgehen – der enthält garantiert keine FOSS.

16

Es gibt jedoch auch leistungsfähige Realtime Betriebssysteme, die ohne Copyleft Lizenzen auskommen, dafür aber Lizenzgebühren kosten. Teilweise geben Rechtsinhaber die gleiche Anwendung unter FOSS Lizenz oder unter kommerzieller Lizenz heraus, so dass der Verzicht auf Copyleft Effekt gegen Gebühr gekauft werden kann. Bei vielen Libraries gibt es alternative Komponenten unter liberalen Lizenzen, was manchmal erst spät im Entwicklungsprozess bemerkt wird. Juristen sind daher gut beraten, bei behaupteter Alternativlosigkeit genauer hinzuschauen.

17

Basic: Begriffsklärung Software/Komponente/Produkt/Projekt/Library/File

Im Bereich FOSS werden viele Begriffe unterschiedlich eingesetzt. Wir verwenden als zentrale Bezeichnung FOSS Komponente für das einzelne urheberrechtlich geschützte Werk, das abgrenzbar für die Software-Entwicklung eingesetzt wird. Parallel werden auch die Begriffe FOSS, Produkt oder Projekt verwendet. Gerade die Internetauftritte von FOSS Komponenten werden häufig als Projekthomepages bezeichnet und bei entsprechender Community die Gemeinschaft/Komponente oft als Projekt. Ist die Komponente unselbstständig, wird sie häufig als Library bezeichnet (typisches Format ist eine .dll-Datei).

Eine FOSS Komponente besteht aus einer Vielzahl einzelner Files, die Zeilen von Header Informationen und Code beinhalten. Sie enthält ggf. weitere Komponenten oder Komponentenbestandteile, sogenannte Abhängigkeiten oder Dependencies. Teils sind diese nicht direkt in den Code einbezogen, sondern werden erst beim Kompilierungsvorgang, also der Umwandlung des Source Code in ein Kompilat, hinzugezogen.

Wir setzen den Begriff Produkt nicht für die einzelne Komponente ein, sondern wenn wir das Ergebnis der Zusammenstellung der Komponenten ggf. auch mit proprietärem Code bezeichnen wollen. Also ist damit quasi das Endergebnis der Programmiervorgänge gemeint. Alternativ wird das auch als Projekt bezeichnet. Projekt nutzen wir jedoch als Referenz für den gesamten Entwicklungsvorgang, insbesondere mit Bezug auf die Zeitschienen.

b) In welchen Fällen kostenlose Software teuer werden kann

18

FOSS gewinnt nicht nur Territorium in Wegwerf-Hardware, sondern auch in hochspezialisierten und hochpreisigen Steuergeräten für Maschinen oder Fahrzeuge. Ein Entscheidungsträger, der für die nächste Gerätegeneration einen Wechsel von vorwiegend proprietär lizenzierten Systemen zu FOSS beschließt, kennt die technischen Vorzüge und die ersparten Lizenzkosten sehr genau. Die rechtlichen Kosten treffen einige Hersteller aber trotzdem unvorbereitet und verdienen eine frühere Betrachtung.

19

Viele FOSS Entwickler verkennen zum Zeitpunkt der Systementscheidungen den Entwicklungsaufwand, der für eine lizenzkonforme Umsetzung erforderlich ist. Gerade bei der tiefen Einbindung von Copyleft Komponenten ist die Freigabe von eigenem Source Code manchmal nicht zu verhindern. Wer diese Software nicht freigeben will oder kann, weil sie ihm gar nicht selbst gehört, findet sich in einer Sackgasse und nimmt entweder Rechtsverletzungen in Kauf oder revidiert seine Software-Auswahl.

20

Wenn die gleiche Software unter Dual License gegen Lizenzgebühr oder unter Copyleft Lizenz angeboten wird, entfällt einerseits das Argument der Alternativlosigkeit, andererseits erhöht sich das Risiko der Rechtsverfolgung, da der Rechtsinhaber eher geneigt ist, Verletzungen der FOSS Variante zu verfolgen und Schadensersatz auf Grundlage der Lizenzanalogie einzufordern.

21

Auf der Seite der Schadenspotenziale sollte kalkuliert werden, welche Auswirkungen ein erfolgreich geltend gemachter Unterlassungsanspruch hätte. Ein solcher Anspruch sorgt bis zum Austausch der Software mindestens zu einem Auslieferungsstopp, u.U. auch zu einem Produktrückruf. Eine solche Rückrufpflicht ergibt sich für bereits veräußerte Gegenstände nicht automatisch aus dem Unterlassungsanspruch, mittelbar jedoch aus den Gewährleistungsansprüchen, wenn das nunmehr illegale Werk vom Käufer nicht mehr weitergegeben werden kann. Der Importeur einer Webcam mag dieses Risiko niedriger einschätzen als ein Automobilhersteller, dem die Stilllegung seiner Flotte droht. Im Business-to-Business-Bereich wiederum können Nachbesserungsaufwände im Rahmen von Wartungsverträgen zu verschmerzen sein.

22

Bei Umsetzung der künftig vorgeschriebenen Over-the-Air-Updates ergeben sich leichtere Korrekturmöglichkeiten für heilbare Lizenzverletzungen wie beispielsweise fehlende Pflichtangaben. Soweit jedoch die Lizenzkonformität nur durch Freigabe von eigenem Source Code erreicht werden kann, kann dies schon alleine daran scheitern, dass der Lizenzverletzer gar nicht über die notwendigen Rechte verfügt, um den entsprechenden Code unter einer FOSS Lizenz freizugeben.

23

Basic: Pflichtangaben und Source Code Freigabe (siehe Rn. 765ff.)

Die FOSS Lizenzen unterscheiden sich teils deutlich im Regelungsgehalt und Umfang der Regelungen, insbesondere bzgl. des Copyleft. So gut wie alle FOSS Lizenzen fordern jedoch für Verwertungshandlungen eine Auflistung von bestimmten Angaben, wir nennen sie Pflichtangaben. Es handelt sich meist um Copyright Hinweise, Lizenztexte und teils weitere Angaben wie z.B. Informationen zur Veränderung.

Copyleft Lizenzen fordern in der Regel die Mitlieferung oder dasAngebot der Mitlieferung des Source Code der FOSS Komponente unter der entsprechenden Lizenz, auch wenn das Copyleft für verbundene oder veränderte Software nicht greift. Greift Copyleft, muss entsprechend auch der veränderte oder verbundene Code bereitgestellt werden.

24

Wer selbst innerhalb einer Zulieferkette FOSS einsetzt, muss in seiner Kalkulation berücksichtigen, dass er für die Schäden seines Kunden haftet, soweit es ihm nicht gelingt, diese Haftungen vertraglich zuverlässig auszuschließen, worauf wir in diesem Buch noch eingehen werden. Natürlich sind die Zeiten vorbei, in denen Rechtsabteilungen apodiktisch jeglichen Einsatz von FOSS verboten haben. Andererseits verbietet sich der kritiklose ungeprüfte Einsatz.

c) Was schlimmstenfalls passieren kann

25

Die Rechtsabteilungen haben selbstverständlich im Blick, wie wahrscheinlich und groß die drohenden Schadensszenarien sind. Eines ist meist eindeutig klar: Eigener proprietärer Code soll nicht in großem Umfang unter einer FOSS Lizenz freigegeben werden. Die Vorgabe, Copyrightvermerke zusammen mit der jeweiligen Lizenz bei Weitergabe beizufügen, nehmen die Verwender meist schon deutlich weniger ernst. In der Praxis kommt häufig die Frage, ob das denn überhaupt jemand merkt und dann tatsächlich auch noch verfolgt.

aa) Häufiger Irrtum: Copyleft führt automatisch zur Freigabe als FOSS

26

Die Geschichte ist so dramatisch, dass sie in fast jedem FOSS Vortrag vorkommt. Sie ist trotzdem falsch. Es wird behauptet, dass die Auslösung des Copyleft Effekts dazu führt, dass die eigene Software – infiziert von einer winzigen Dosis Copyleft – auch zum Copyleft Zombie wird. Auf dieser Grundlage wird dann die Freigabe des kompletten kommerziellen Produkts gefordert, das entsprechend infiziert ist. Richtig ist, dass Werke, die von Copyleft lizenzierten Werken abgeleitet werden, ebenfalls unter Copyleft Lizenz gestellt werden müssen, um die Lizenzbedingung zu erfüllen (siehe hierzu Rn. 225ff.). Es gibt jedoch keinen Automatismus.

27

Der Rechtsinhaber hat die Wahl, die Copyleft Lizenz dadurch zu erfüllen, dass er seine eigene Software auch unter gleiche Lizenz stellt oder auf die Vorzüge der FOSS Lizenz, insbesondere auf das gewährte Nutzungsrecht zu verzichten. Das mag sich nach einem Dilemma anhören, da die Verletzung der Lizenz Rechtsnachteile bedeuten kann; es ist aber gleichwohl die Entscheidung des Rechtsinhabers, ob er die Freigabe seines Code und der FOSS Lizenz vornehmen will oder nicht. Dass kein Automatismus bestehen kann, ergibt sich schon alleine aus dem Umstand, dass der Verwerter möglicherweise gar nicht in der Lage ist, eine Lizenzierung unter einer FOSS Lizenz vorzunehmen. Wäre es anders, könnte man eine fremde kommerzielle Software mal eben mit GPL infizieren, so dass sie dann für jedermann frei nutzbar wäre.

28

Der Gedanke hält sich gleichwohl hartnäckig und liegt sogar der Entscheidung des LG Berlin im Fall AVM ./. Cybits (Surfsitter)6 zugrunde. Das an mehreren Stellen angreifbare Urteil (siehe ausführlich Rn. 605ff.) geht davon aus, dass der Hersteller der Fritzbox keine Unterlassungsansprüche gegen Cybits geltend machen darf, wenn das linux-basierte FritzOS verändert wird. Die Richter statuierten, dass mit Copyleft Effekt infizierte Software quasi „vogelfrei“ wird und der Rechtsinhaber seine Ansprüche aus dem Urheberrecht verlieren soll. Anders ausgedrückt sollen Sammelwerke, die aus FOSS bestehen, als Ganzes den Bedingungen der FOSS mit Copyleft Effekt unterliegen. Spätere Rechtsprechung hat diesen Fehler erkannt und auch unter dem Gesichtspunkt der Verwirkung und dem Unclean-Hands-Einwand Einwendungen gegen das Verwertungsrecht zurückgewiesen.7

29

Die Möglichkeiten für Lizenznehmer, wegen FOSS Verstößen Kostenfreiheit zu erlangen, sind etwas kleiner als angenommen. FOSS Lizenzen können nur die Instrumente des Urheberrechts einsetzen. Das Sanktionsarsenal beschränkt sich daher darauf, das kostenlos gewährte Nutzungsrecht an der FOSS entfallen zu lassen. Die Lizenz kann keine zusätzlichen Nutzungsrechte für jedermann an proprietärer Software erzeugen.

bb) Ungenutztes Schädigungspotenzial der Rechtsinhaber

30

Die „offene“ Verbreitung von FOSS bietet Vorteile, aber zugleich nicht zu unterschätzende Risiken, weniger für den Anwender als vielmehr für denjenigen, der FOSS für die eigene Entwicklung einsetzen und auch an Endkunden vertreiben will.

(1) Rechtlicher Fokus

31

Die Lizenzbedingungen der jeweiligen FOSS legen die urheberrechtlichen Rahmenbedingungen fest, unter denen der Entwickler der Software bzw. deren Rechtsinhaber anderen Nutzungsrechte an der FOSS einräumen will. Da die FOSS Lizenzbedingungen auf diese Weise die Ausübung des Urheberrechts konkretisieren, stellt jede Verletzung der Lizenzbedingungen eine Urheberrechtsverletzung dar, die urheberrechtliche Ansprüche der §§ 69f, 69a Abs. 4 i.V.m. §§ 97ff. UrhG auslöst, sofern die jeweiligen Anspruchsvoraussetzungen gegeben sind (siehe auch Rn. 499ff.).8

32

Automatischer Rechtsfortfall oder inhaltliche Beschränkung?

Die Geltendmachung von urheberrechtlichen Ansprüchen durch den Urheber wegen lizenzwidriger FOSS Nutzung hängt im Wesentlichen davon ab, ob das lizenzwidrige Verhalten zu einem Wegfall der durch die FOSS Lizenz eingeräumten Nutzungsrechte führt ober ob eine bloße Verletzung vertraglicher Pflichten vorliegt, was den Rechtsinhaber auf die bloße Durchsetzung von schuldrechtrechtlichen Ansprüchen gegen den Verletzer beschränken würde. Beispielsweise regelt die GPL-2.0 in Ziff. 4 einen automatischen Rechtsfortfall bei lizenzwidriger Nutzung, stellt aber lediglich eine vertragliche Regelung dar. Daher wird in der Literatur diskutiert, welche rechtlichen Folgen sich aus dieser Klausel ergeben.

Während einige Autoren von einer inhaltlichen Beschränkung der Nutzungsrechte i.S.d. § 31 Abs. 1 Satz 2 UrhG ausgehen,9 nimmt die h.M. eine auflösend bedingte Rechtseinräumung nach § 158 Abs. 2 BGB an.10 Im Ergebnis kann der GPL-2.0 nicht nur eine schuldrechtliche Verpflichtung zur Einhaltung der Lizenzbedingungen entnommen werden, so dass die h.M. zutreffend davon ausgeht, dass dem Lizenznehmer die Nutzungsrechte unter der auflösenden Bedingungen eingeräumt werden, dass dieser sich an die Lizenzbedingungen hält (siehe Rn. 152f.). Wird gegen die Pflichten verstoßen, fallen die Nutzungsrechte automatisch ex nunc weg und der Lizenznehmer begeht eine Urheberrechtsverletzung, wenn er die Software entgegen den Lizenzbedingungen vertreibt.11

(2) Realitätsfokus

33

Eine „Massenabmahnwelle“ der FOSS Entwickler ist bisher nicht losgebrochen, aber in Anbetracht des doch weitreichenden FOSS Einsatzes in Produkten aller Art künftig nicht per se ausgeschlossen. Die Konsequenzen aus der auch gerichtlichen Verfolgung der bei lizenzwidrigem FOSS Einsatz entstehenden Ansprüche können recht weitreichend sein. So ist u.U. der Rückruf ganzer Produktserien, in denen FOSS Komponenten ohne Einhaltung der Lizenzbedingungen implementiert sind, nicht undenkbar. Dies kann nicht zuletzt immense wirtschaftliche Schäden und Reputationsverluste für die in Anspruch genommenen Unternehmen nach sich ziehen.

34

Die entstehenden rechtlichen Risiken sind abhängig von der Strenge der jeweiligen FOSS Lizenz und von dem Pflichtenprogramm, das von den Lizenzbedingungen vorgeschriebenen ist und durch eine Weitergabe der jeweiligen FOSS z.B. in einem Endprodukt ausgelöst wird. Dies betrifft v.a. den Vertrieb der FOSS an Endkunden. Das rechtliche Risiko wird zusätzlich erhöht, wenn FOSS Komponenten mit proprietären Programmkomponenten z.B. verbunden im Rahmen von sogenannten Value added Produkten12 vertrieben werden. Handelt es sich bei der verbundenen oder auch nur bei Installation und Ausführung interagierenden FOSS um eine solche mit angeordnetem strengem Copyleft (wie z.B. bei der GPL-2.0 oder GPL-3.0 der Fall), so ist u.U. der Vertrieb nur gestattet, wenn alle Programme, die von der GPL Software abgeleitet sind, ebenfalls unter die GPL gestellt werden (siehe weiterführend Rn. 234ff.).

35

Die deutsche Rechtsprechung hat noch immer keinen gemeinsamen Nenner gefunden; v.a. zur Reichweite des Copyleft Effekts der GPL fehlen Entscheidungen, soweit ersichtlich, bisher völlig.13 Jedoch ist ein Großteil der Entscheidungen der letzten Jahre (siehe Rn. 36ff. und ausführlich Anhang Rn. 837.)14 zugunsten der Rechtsinhaber von FOSS ergangen, die von den jeweiligen Prozess-Kontrahenten ohne Beachtung der jeweiligen FOSS Lizenzbedingungen und damit urheberrechtswidrig eingesetzt worden ist. Die bisherigen FOSS Urteile schärfen daher den Fokus hinsichtlich der sich tatsächlich auch in der Praxis realisierenden Rechtsrisiken und fördern immer mehr das Bedürfnis von Unternehmen unterschiedlichster Wirtschaftszweige nach FOSS Compliance. Diese verfolgt das Ziel, einen kontrollierten Einsatz von FOSS und deren rechtskonformen Vertrieb v.a. in Verbindung mit Value added Produkten oder in eingebetteten Systemen zu ermöglichen.

d) Was bisher geschah...

36

In den letzten Jahren sind einige Vertreter aus der Open Source Community (siehe auch Rn. 48ff.) aufgetreten, die das Bild ergangener Gerichtsentscheidungen bzgl. der Verfolgung von Rechtsverstößen im FOSS Bereich geprägt haben. Außerdem wurden einige interessante Verfahren in Übersee im FOSS Bereich ausgetragen.

aa) Harald Welte: Pionier der deutschen FOSS Rechtsprechung

37

Allen voran und gleichsam als Initiator einiger richtungsweisender FOSS Urteile in Deutschland zu nennen ist Harald Welte, der Miturheber und -entwickler des Linux kernel. Welte betreibt unter der URL gpl-violations.org eine zentrale Informations- und Community-Webseite zu FOSS und katalogisiert dort zahlreiche Fälle, in denen die GPL (insbesondere die GPL-2.0) in der Praxis verletzt wurde. Ein Überblick der von ihm auch gerichtlich verfolgten FOSS Verletzungsfälle und weitere FOSS News findet sich ebenfalls auf der genannten Community-Webseite.15

38

Die Klärung von einigen wesentlichen Grundsatzfragen im FOSS Bereich für das deutsche (Urheber-)Recht vor den deutschen Gerichten geht auf von Welte angestrengte gerichtliche Verfahren zurück.

39

Die wesentlichen Grundsatzfragen:

 – FOSS Lizenzbedingungen als AGB (siehe Rn. 141ff.);

 – Wirksamkeit von FOSS Lizenzbedingungen in Deutschland (siehe Rn. 149ff.);

 – Rechtsfortfallklausel gem. Ziff. 4 GPL-2.0 als auflösend bedingte Rechtseinräumung (siehe Rn. 150ff.);

 – Verstoß gegen FOSS Lizenzbedingungen als Urheberrechtsverstoß, der Ansprüche nach den §§ 97ff. UrhG auslöst.

bb) Patrick McHardy: Kommerzialisierung der Rechtsverfolgung

40

Jedenfalls von der Open Source Community eher kritisch betrachtet wird die Rechtsverfolgung von Patrick McHardy, der u.a. auch Verfahren vor den deutschen Gerichten mit gleichwohl bisher mäßigem Erfolg angestrengt hat.16

41

Bereits seit 2013 geht McHardy im größeren Stil zunächst außergerichtlich gegen angebliche Urheberrechtsverletzungen der GPL-2.0 mit der Behauptung vor, er sei Miturheber bzw. Bearbeiterurheber des Linux kernel, und Unternehmen, die Linux beispielsweise im Zusammenhang mit von ihnen vertriebener Hardware nutzen, hätten die FOSS Lizenzbedingungen bzgl. der von McHardy zumindest mitentwickelten Linux Komponenten urheberrechtswidrig nicht eingehalten. Im Wege anwaltlicher Abmahnungen werden vor allem urheberrechtliche Ansprüche auf Unterlassung und Erstattung von Abmahnkosten geltend gemacht.

42

In den Fällen, die wir bisher gesehen haben, wirkte McHardy darauf hin, auf Abmahnungen möglichst weit gefasste Unterlassungserklärungen zu erhalten, und beobachtete sodann die weitere Betätigung der abgemahnten mittelständischen Unternehmen am Markt. In einem nächsten Schritt wurde ein Verstoß gegen abgegebene Unterlassungserklärungen und damit eine Vertragsstrafe geltend gemacht. Ähnliche Berichte gibt es von weiteren Fällen, wobei viele Auseinandersetzungen nicht in gerichtlichen Klageverfahren mündeten, sondern in außergerichtlichen Vergleichen endeten, deren Vergleichssummen McHardy zuflossen.17

43

Das Vorgehen von McHardy gerade im größeren Stil18 ist zumindest in Deutschland ein Novum im FOSS Bereich und rief erhebliche Kritik in der Open Source Community hervor. Der im Grunde nicht Community konforme Alleingang McHardys führte daher bereits im Sommer 2016 zu dessen Ausschluss aus dem sog. Core Team des Linux kernel für den Bereich Netfilter.19

cc) Schlaglichter FOSS relevanter Verfahren im Ausland

44

Auch ein kurzer Blick auf FOSS Verfahren im Ausland soll an dieser Stelle nicht fehlen. Zu den relevanten Auseinandersetzungen in den USA20 gehören die von der Software Freedom Conservancy21 angestoßenen Gerichtsverfahren insbesondere im Zusammenhang mit der Rechtsverfolgung von Verstößen gegen die GPL Lizenzbedingungen rund um BusyBox (siehe auch Rn. 62). Bei dem Verfahren BusyBox v. Westinghouse ging es im Jahr 2010 um die erste Rechtsdurchsetzung der GPL-2.0 in einem gerichtlichen Verfahren vor dem United States District Court, Southern District of New York, das zu einer Verurteilung der Beklagten zu Schadensersatz nach dem U. S. Copyright Act wegen Nichteinhaltung der Lizenzbestimmungen führte.22 Weitere Verfahren mit FOSS Bezug wurden vor U.S.-Gerichten u.a. in den Rechtssachen Jacobsen v. Katzer23, XimpleWare v. Versata24 sowie Artifex v. Hancom25 geführt. In allen Verfahren ging es thematisch um die Verletzung von FOSS Lizenzen durch Bestandteile der in den Verfahren streitgegenständlichen Software-Produkte. Das Verfahren Jacobsen v. Katzer ist insofern hervorzuheben, als es sich um das erste Verfahren handelte, in dem ein U. S.-Gericht zur Wirksamkeit von FOSS Lizenzbedingungen (im Verfahren: Artistic-1.026) entscheiden musste und deren Wirksamkeit bestätigte.27

45

Ein weiteres Verfahren mit insbes. vertragsrechtlichen Bezügen zu FOSS wurde vor dem französischem Cour d’appel de Paris in der Rechtssache AFPA/Edu4 ausgetragen.28 Neben der Bestätigung der Wirksamkeit der GPL-2.0 im Verhältnis zwischen Unternehmen hat die französische Entscheidung insofern Gewicht, als sie einen direkten Anspruch auf Herausgabe des Source Code und weiterer Informationen ausurteilte. Der Anspruch wurde dem Erwerber einer unter GPL lizenzierten Software gegen den Distributor der Software zugesprochen (siehe hierzu auch Rn. 162),29 dieser basierte aber, soweit aus den Gründen des Urteils ersichtlich, auf Ansprüchen aus dem zwischen AFPA und Edu4 bestehenden Vertragsverhältnissen, nicht aus unmittelbarer Anwendbarkeit der GPL-2.0.

46

Streng genommen keine FOSS Verfahren, aber dennoch besondere Schlaglichter von Software-Prozessen in den USA sind die vor U. S.-Gerichten ausgetragenen Verfahren zwischen Oracle und Google.30 Zentraler Vorwurf von Oracle an Google war die Verletzung von Patenten und Urheberrechten wegen der Verwendung der Programmiersprache Java in Googles Betriebssystem Android. Die gerichtlichen Bemühungen von Oracle reichen bis in das Jahr 2010 zurück und mündeten in mehreren Gerichtsverfahren ganz unterschiedlichen Ausgangs. Zuletzt wurde Google die Verwendung der Programmiersprache Java in seinem Betriebssystem unter dem Gesichtspunkt des Fair Use abgesprochen, was in die Geltendmachung von Schadensersatzforderungen in Milliardenhöhe durch Oracle mündete.31

47

FOSS in Java und Android

Interessanter Randaspekt ist, dass das von Oracle vertriebene Open-JDK als wesentlicher Teil des Oracle Programmpakets Java unter GPL-2.0 mit Classpath Exception32 lizenziert ist33 und insofern FOSS Relevanz hat. Außerdem ist das Google Betriebssystem Android vollständig quelloffen, was die notwendigen Recherchen für die patent- und urheberrechtliche Inanspruchnahme von Google durch Oracle sicherlich erleichtert haben dürfte. Software-Komponenten des Android Open Source Project (AOSP) sind überwiegend unter Apache-2.0 lizenziert; der ebenfalls im Projekt enthaltene Linux kernel bekanntlich unter GPL-2.0 mit teilweisen Exceptions.34 Die FOSS Komponenten von Java und von Android waren (soweit ersichtlich) in den U. S.-Verfahren allerdings nicht streitgegenständlich.

e) Das Who’s Who der Open Source Community

48

Hört oder liest man von FOSS, ist immer wieder die Rede von einer Community. Diese Community entwickelt gemeinschaftlich Software, nimmt dankbar Änderungen entgegen, entscheidet über Lizenzverstöße und Rechtsverfolgungen. Man könnte sich diese Community als supranationale, allwissende und übermächtige Instanz vorstellen, die zentral in der Blockchain lebt und am Ende von einer künstlichen Intelligenz gesteuert wird. Grund genug, dass wir diese ominöse FOSS Community genauer betrachten, wenigstens dort, wo sie durch Organisationen zutage tritt.

49

Da es eine Vielzahl von Organisationen mit sehr unterschiedlichen Ausrichtungen gibt, macht es Sinn, ihre Motive zu erforschen, um ihre Position besser einordnen zu können. Einfach wäre es natürlich, man könnte die Organisationen antagonistisch in Rechtsinhaber und potenzielle Rechtsverletzer aufteilen, allerdings kommen wir damit nicht weit, da jeder Software-Entwickler und Produkthersteller sowohl Täter als auch Verletzter einer Lizenzverletzung sein kann. Entsprechend sind die Organisationen inzwischen oft mit unterschiedlichen Interessenvertretern unterwandert. Einfacher ist die Zuordnung bei reinen Industrieverbänden, die sich beispielsweise zusammengeschlossen haben, um die Verwertung von FOSS in ihren häufig proprietären Projekten und Produkten zu vereinfachen.

aa) Free Software Foundation (FSF)

50

Zu den älteren, man könnte schon fast sagen traditionellen, Organisationen gehören jene, die schon im letzten Jahrtausend Lizenzen und Software herausgegeben haben, wie etwa die Free Software Foundation (FSF)35 als Urheber und Herausgeber der GNU GPL Lizenzfamilie. Die Aktivisten der FSF haben mit dem Copyleft Effekt in der GPL die vorherige Gratiskultur eingeschränkt. Das originelle Wortspiel Copyleft als Ergänzung oder Widerspruch zum Copyright wird dem FSF-Gründer Richard Stallman zugeschrieben. Aus seiner Tastatur sollen auch Äußerungen zur Reichweite der GPL Verpflichtungen stammen, wonach GPL betriebene Geräte ohne Display den Lizenztext vorlesen sollen und dass der Copyleft Effekt schon dann eintrete, wenn man an Linux beim Programmieren gedacht habe.

51

Die Position zur Interpretation der GPL von der FSF sollte man ernst nehmen, allerdings steht sie gelegentlich auch in Widerspruch zu nationalem Recht. Gerade wenn es um Lizenzkompatibilität und Copyleft Effekt geht, vertritt die FSF häufig die strengste anzunehmende, also panische Auslegungsart (siehe Rn. 490) Man könnte aber konstruktiv konzedieren, dass derjenige, der sich an die Vorgaben der FSF hält, und seine Software-Architektur entsprechend einschränkt, weitgehend auf rechtlich sicherer Seite operiert. Man muss dann aber auch in Konsequenz hinnehmen, dass man die beliebte OpenSSL Library mangels Lizenzkompatibilität nicht mehr auf GPL-2.0 Linux Systemen einsetzen kann.

52

Interessant sind die Äußerungen der FSF dort, wo Widersprüche im eigenen Lizenzwerk angesprochen werden, etwa bei der Wirkungsweise der GPL Exceptions, die nach ihrem Wortlaut geeignet sind, Zweck und Inhalt der Grundlizenz komplett auszuhebeln. Hier verweisen Organisationen und sogar Lizenztexte auf den INAL Disclaimer (I’m not a Laywer). Die Antwort auf die Frage ist natürlich wenig befriedigend, wenn man selbst Anwalt auf Suche nach Erleuchtung ist.

bb) Open Source Initiative (OSI)

53

Die Open Source Initiative (OSI)36 leistet einen wichtigen Dienst, indem sie FOSS Lizenzen nach einer allgemein anerkannten Definition zertifiziert. OSI zertifizierte Lizenzen sind damit etwa nur jene FOSS Lizenzen, die beispielsweise keine Einschränkung hinsichtlich des Verwendungszwecks vorsehen. Eine Lizenz, die kommerzielle oder auch nur militärische Nutzung ausschließt, kann nicht das OSI-Gütesiegel erhalten. Andererseits kann es im kommerziellen Umfeld eine gute Mindestanforderung darstellen, wenn man einzig FOSS Lizenzen zulässt, die von der OSI zertifiziert wurden.

cc) Apache Software Foundation (ASF)

54

Die Apache Software Foundation (ASF)37 ist Namensgeber für einen weit verbreiteten http Server und die Apache Lizenzen (siehe zu den Lizenzen Rn. 306ff.). Die aktuelle Apache-2.0 Lizenz ist in ihrer Wirkung scheinbar liberal und müsste sich daher in Copyleft Projekte einbinden lassen; die ASF wehrt sich jedoch gegen die Rechtsfolge, dass ihre eigene Software danach auch unter GPL stehen soll, und erwartet, dass die FSF ihre Rechtsauffassung bei der Lizenzinterpretation ändert.38

dd) Eclipse Foundation

55

Auch die Eclipse Foundation39 hat eine eigene Software und eine eigene Lizenz entwickelt. Diese hat für den Copyleft Effekt einzigartige Kriterien herausgearbeitet, die im Prüfungsprozess dann Fragen notwendig machen nach Separate Modules und Plug-in Struktur (siehe hierzu und zu den allgemeinen Lizenzvorgaben der EPL-1.0 und EPL-2.0 Rn. 295ff.). Antworten zu diesen Fragen lassen sich regelmäßig nicht aus dem Source Code entnehmen und erfordern lange Recherchearbeit, bis der Zulieferer des Zulieferers des Zulieferers ausfindig gemacht wurde, der dann idealerweise erklärt, dass die Komponente doch gar nicht eingesetzt werde und nur versehentlich mitgescannt wurde.

56

Die Eclipse Foundation macht mehr als die Betreuung eines Entwicklungstools und einer kopfzerbrechenden Lizenz. Man kann der Eclipse Foundation FOSS Projekte anvertrauen, damit diese die Koordination von Software-Entwicklung gegen Beitragsleistung zu übernehmen. Entsprechende Arbeitsgruppen sind mögliche Alternativen zu Joint Ventures, vor allem wenn es nicht darum geht, mit dem gemeinsamen Unternehmen Geld zu verdienen, sondern lediglich die Software Entwicklung in einem gemeinsamen Projekt mehrerer Unternehmen zu bündeln. Solche Betreuungsleistungen werden auch von anderen Organisationen angeboten.

ee) Linux Foundation

57

Eine besondere Produktnähe hat natürlich die Linux Foundation40, wobei sie nicht als Herausgeber oder Rechtsinhaber für den Linux kernel angesehen werden kann. Das bereitet manchmal Schwierigkeiten, wenn man eine Lizenzzuordnung einer einzelnen Komponente oder Datei überprüft. Weder die Linux Foundation noch die Linux Community haben formal das Recht, Lizenzen am Kernel zu vergeben oder gar zu verändern. Trotzdem kommt es gelegentlich zu Lizenzanpassungen, wenn beispielsweise Libraries neu unter den Wirkungsbereich der System Call Exception gestellt werden. Hier kann man sich fragen, ob der tatsächlich berechtigte Rechtsinhaber der Veränderung ausdrücklich oder stillschweigend zugestimmt hat; man kann sich die Frage aber auch sparen, um Bösgläubigkeit zu verhindern. Guter Glaube führt zwar noch nicht zu einem Rechtserwerb, kann jedoch beim Verschulden helfen.

ff) Sonstige

58

Auf Produktebene lassen sich beliebig viele Organisationen und Micro Communities aufzählen, die in der Regel von dem Motiv geprägt sind, der eigenen Software zu großer Verbreitung und Weiterentwicklung zu verhelfen. Fragt man in den Communities der Content Management Systeme unter GPL-2.0 (z.B. WordPress, Joomla oder Drupal) nach der Geltung der GPL-2.0 für kommerzielle Themes oder Module, erhält man typischerweise strengere Antworten als beim Unternehmensverband.

59

Die Open Source Automation Development Lab (OSADL)41 spielt mit praktischen bis mutigen Handlungsempfehlungen für ihre Mitglieder auf, wenn es um die Vermeidung von Copyleft Effekten geht. Vom OSADL stammt beispielsweise die kreative Idee, dass der Erschöpfungsgrundsatz dann für Serverbereitstellung genutzt werden kann, wenn für jede heruntergeladene Kopie eine lokale Kopie gelöscht wird, die idealerweise zuvor auf rechtmäßige Weise verbreitet wurde.

60

Communities bilden sich auch rund um webbasierte Plattformen wie GitHub42, SourceForge43 oder Stackoverflow44. Für viele Software-Entwickler besteht das persönliche Bedürfnis, in diesen Communities als Contributor oder Experte anerkannt zu werden. Daher drängen manche Entwickler ihr Management, eigene Software in der Community bereitzustellen. Der persönliche Prestigegewinn lässt sich dabei auch auf das Unternehmen übertragen. Altruistische Aktivität zugunsten der Community mag vor Gericht nicht als Rechtfertigung für Lizenzverletzungen taugen. Eigenes Engagement kann jedoch verhindern, dass ein Unternehmen als notorischer GPL Verletzer wahrgenommen wird, wie dies in der Vergangenheit häufig der Fall war für einige Chiphersteller, die ihre Treiber nicht quelloffen bereitgestellt haben. Auch ein Hersteller von Elektroautos konnte den Ärger der Community zumindest teilweise besänftigen, indem mit der Öffnung eines GitHub Accounts zumindest Teile der Lizenzverpflichtungen erfüllt wurden.45

61

Einige Organisationen haben sich darauf spezialisiert, Rechtsverletzungen zu verfolgen. Kernel Entwickler Harald Welte (siehe bereits Rn. 37ff.) betrieb mit gpl-violations.org eine inzwischen eingeschlafene Kampagne zur Rechtsverfolgung gegen GPL Verletzungen. Generierung von Schadensersatzansprüchen war dabei offenbar kein treibendes Motiv für die Vielzahl von Abmahnungen und Klagen. Welte verdanken wir die Klärung einiger GPL Grundsatzfragen in der deutschen Rechtsprechung, aber auch den Irrläufer zur Berliner AVM vs. Cybits Rechtsprechung (siehe ausführlich Rn. 605ff.). Fairerweise sollte man jedoch anmerken, dass die technischen Fehlverständnisse des Gerichts nicht so von Welte vertreten wurden.

62

In Amerika hat sich die Software Freedom Conservancy46 auf Rechtsverletzungen im Bedienungsumfeld spezialisiert und die GPL-2.0 lizenzierte Komponente BusyBox war dabei häufiger Streitgegenstand.47 Software Freedom Conservancy stand ebenfalls Pate für das Verfahren Hellwig ./. VMWare vor dem LG Hamburg48 und zweitinstanzlich OLG Hamburg49, das erfolglos blieb und damit einen vorläufigen Schlussstrich unter die organisierte Verfolgung von GPL Verletzungen vor deutschen Gerichten setzte.

5 Zu den wesentlichen Grundprinzipien Freier Software Stallman, https://www.gnu.org/philosophy/free-sw.html.en. 6 LG Berlin, 8.11.2011 – 16 O 255/10, ZUM-RD 2012, 153. 7 OLG Karlsruhe, 27.1.2021 – 6 U 60/20, K&R 2021, 271ff.; LG Mannheim, 24.1.2020 – 7 O 71/19 (abrufbar unter: https://shop.ruw.de/download-FOSS). Hierzu ausführlich Rn. 612ff. 8 Kurzüberblick bei Van den Brande/Coughlan/Jaeger, S. 137f.; weiterführend Jaeger/Metzger, Open Source Software, Rn. 209ff. m.w.N. 9 Siehe Nachweise bei Grützmacher, in: Wandtke/Bullinger, UrhG, § 69c Rn. 116. 10 Weiterführend Teupen, S. 207ff.; Jaeger, in: ifrOSS, Die GPL kommentiert und erklärt, Ziff. 4 Rn. 11ff.; Jaeger/Metzger, Open Source Software, Rn. 209; Grützmacher, in: Wandtke/Bullinger, UrhG, § 69c Rn. 116, jeweils mit m.w.N. 11 Jaeger/Metzger, Open Source Software, Rn. 211; Metzger/Jaeger, GRUR Int. 1999, 839 843. 12 Zum Begriff Jaeger/Metzger, Open Source Software, Rn. 22 sowie Rn. 51; Wiebe, in: Spindler/Schuster, § 69c UrhG Rn. 55. 13 Das OLG Hamburg reißt in dem Rechtsstreit Hellwig ./. VMWare (OLG Hamburg, 28.2.2019 – 5 U 146/16, MMR 2019, 452 Rn. 76 m. Anm. Galetzka/Hackel) die Problematik zumindest an, ohne dass sie sich jedoch entscheidungserheblich auswirkt. Mit der gleichen Feststellung die Vorinstanz (LG Hamburg, MMR 2016, 740, Rn. 95f. m. Anm. Galetzka/Otto). Auch LG Mannheim, 24.1.2020 – 7 O 71/19 (abrufbar unter: https://shop.ruw.de/download-FOSS) und OLG Karlsruhe, 27.1.2021 – 6 U 60/20, K&R 2021, 271ff. mussten die Problematik nicht entscheiden, siehe hierzu. Rn. 612ff. 14 Instruktiver Überblick bei Van den Brande/Coughlan/Jaeger, S. 142ff. 15 https://gpl-violations.org/news/. 16 Instruktiv und kritisch zu den von McHardy angestrengten Verfahren vor den Kölner Gerichten Czychowski, GRUR-RR 2018, 1ff. Siehe auch v. Welser, GRUR-Prax 2018, 164f. Siebers, MMR 2018, 415 mit Hinweis auf weitere angeblich erfolglose Verfahren von McHardy: LG Mannheim, 31.3.2015 – 2 O 216/14, bestätigt durch OLG Karlsruhe, 6.7.2015 – 6 U 91/15 (beide unveröffentlicht). 17 Vertiefend zum weiteren Hintergrund Czychowski, GRUR-RR 2018, 1f.; Siebers, MMR 2018, 415; Baader, https://www.pro-linux.de/news/1/25090/patrick-mchardy-gpl-durchsetzung-zur-persoenlichen-bereicherung.html; Thoma, https://www.golem.de/news/betriebssysteme-linux-4-14-ruestet-sich-gegen-copyright-trolle-1711-131108.html; Steinlechner, https://www.golem.de/news/lizenzbestimmungen-linux-abmahnungen-verunsichern-elektronikbranche-1803-133139.html. 18 Siebers, MMR 2018, 415 spricht bezüglich der von McHardy verfolgten gerichtlichen Verfahren von dem „Bestandteil eines Geschäftsmodells“. 19 https://marc.info/?l=netfilter-devel&m=146887464512702. 20 Siehe im Zusammenhang mit der Darstellung von rechtsvergleichenden Aspekten bei der Anwendbarkeit und Durchsetzung von FOSS Lizenzbedingungen die Hinweise auf weitere Gerichtsverfahren in den USA, Frankreich und den Niederlanden bei Jaeger/Metzger, Open Source Software, Rn. 460ff. und deren Rechtsprechungsübersicht in Anhang A, S. 313f. m.w.N. 21 https://sfconservancy.org/. 22 Jaeger/Metzger, Open Source Software, Rn. 460 mit Hinweis auf https://sfconservancy.org/docs/2010-07-27_dj-opinion.pdf (Fn. 1652). 23 U.S. Court of Appeals for the Federal Circuit, 13.8.2008 – 535 F.3d 1373 (2008), https://www.leagle.com/decision/infco20080813083. Zusammenfassend hierzu Fitzner, MMR-Nachrichtenarchiv 12/2008, S. XV, https://rsw.beck.de/cms/?toc=MMR.ARC.200812&docid=272027; Jaeger/Metzger, Open Source Software, Rn. 460. Zu den insgesamt und wechselseitig zwischen den Kontrahenten Jacobsen und Katzer ausgetragenen Verfahren, die u.a. auch patent claims und DMCA claims betrafen, https://en.wikipedia.org/wiki/Jacobsen_v._Katzer m.w.N. 24 U. S. Disctrict Court for the Northern District of California, 16.5.2014 – 5:13-cv-05161-PSG, https://casetext.com/case/ximpleware-inc-v-versata-software-1. Siehe auch http://ia803003.us.archive.org/22/items/gov.uscourts.cand.271648/gov.uscourts.cand.271648.18.0.pdf. 25 U. S. Disctrict Court for the Northern District of California, 25.4.2017 – 6-cv-06982-JSC, https://www.leagle.com/decision/infdco20170426a82. 26 https://spdx.org/licenses/Artistic-1.0.html. 27 Jaeger/Metzger, Open Source Software, Rn. 460 m.w.N. 28 Cour d’appel de Paris, 16.9.2009 – 04/24298, https://www.doctrine.fr/d/CA/Paris/2009/SK0D850C9610BFF617983A. 29 Hierzu Jaeger/Metzger, Open Source Software, Rn. 42, 463, die auf die Besonderheit dieses, soweit ersichtlich, bisher nur in Frankreich zugesprochenen Direktanspruchs sowie auf die dogmatische Anschlussfrage der Einordnung der GPL-2.0 als echter Vertrag zugunsten Dritter i.S.d. § 328 BGB hinweisen. 30 Siehe bspw. U. S. District Court for the Northern District of California, 31.5.2012 – C 10-035361 WHA, BeckRS 2012, 11940; U.S. Court of Appeals for the Federal Circuit, 9.5.2014, GRUR Int. 2014, 711 – Oracle America, Inc. v. Google Inc. Siehe auch den zusammenfassenden Überblick über die verschiedenen gerichtlichen Verfahren von Oracle gegen Google bei Beckendorf, MMR-Aktuell 2018, 405405. 31 U.S. Court of Appeals for the Federal Circuit, 27.3.2018 – 2017-1118, 2017-1202, http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF – Oracle America, Inc. v. Google LLC. 32 http://openjdk.java.net/legal/gplv2+ce.html. 33 FAQ von Oracle zu Java, Frage „What does the licensing change mean to me?“, https://www.oracle.com/de/java/technologies/javase/jdk-faqs.html. 34 https://source.android.com/setup/start/licenses. 35 https://www.fsf.org/. 36 https://opensource.org/. 37 https://www.apache.org/. 38 Zum Streit mit der FSF führt die unterschiedliche Rechtsauffassung zur Kompatibilität zwischen Apache 2.0 und GPL, siehe Rn. 675ff. 39 https://www.eclipse.org/. 40 https://www.linuxfoundation.org/. 41 https://www.osadl.org/. 42 https://GitHub.com/. 43 https://sourceforge.net/. 44 https://stackoverflow.com/. 45 Siehe Grüner, https://www.golem.de/news/linux-tesla-beginnt-versuch-der-gpleinhaltung-1805-134501.html. 46 https://sfconservancy.org/. 47 https://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/. 48 LG Hamburg, 8.7.2016 – 310 O 89/15, MMR 2016, 740 m. Anm. Galetzka/Otto. 49 OLG Hamburg, 28.2.2019 – 5 U 146/16, MMR 2019, 452 m. Anm. Galetzka/Hackel.

2. Was FOSS eigentlich ist

63

 – Das Verständnis von wesentlichen Begrifflichkeiten ist für die Prüfung von FOSS Anwendungsfällen und die Einordnung in den Praxiskontext essenziell.

 – FOSS kann als neutraler Begriff verwendet werden, der sowohl Freie Software als auch Open Source Software, die sich hauptsächlich in den dahinterstehenden Idealen unterscheiden, umfasst.

 – Die wesentlichen Merkmale von FOSS sind, dass die Software von jedermann frei und ohne Zahlung von Lizenzgebühren verwendet werden kann, der Source Code der Software zugänglich ist und der Nutzer die Software selbst verändern und an Dritte weitergeben darf.

 – Freeware, Shareware und auch Public Domain Software sind keine FOSS im klassischen Sinne; letztere kann jedoch nach denselben Maßstäben beurteilt werden.

64

Im Bereich der Free and Open Source Software gibt es diverse Begriffe und Definitionen, die häufig denselben oder zumindest einen ähnlich gelagerten Sachverhalt – nämlich quelloffene und für jedermann ohne Lizenzgebühr frei verwendbare Software – beschreiben sollen. So gibt es zum einen den Begriff der Freien Software und zum anderen den der Open Source Software. Obwohl die Begriffe häufig synonym verwendet werden, gibt es Unterschiede. Diese liegen jedoch eher in den hinter den Begriffen liegenden politischen Überzeugungen der einzelnen Organisationen, durch die diese Begriffe letztlich geprägt wurden, sowie den damit verbundenen Assoziationen. Gerade die Free Software Foundation (FSF) legt z.B. großen Wert auf die Verwendung der korrekten Begrifflichkeit.

65

Da sich die Definitionen von Freier Software und Open Source Software inhaltlich weitgehend entsprechen und aus lizenzrechtlicher Sicht in der Praxis eine Unterscheidung in den seltensten Fällen erforderlich ist, haben wir uns dazu entschieden, in diesem Buch den Überbegriff Free and Open Source Software – kurz FOSS – zu verwenden. Dieser Begriff wird allgemein verwendet, um sich neutral zwischen Freier Software und Open Source Software zu verhalten.50 Für ein besseres Verständnis von FOSS finden Sie im Folgenden aber dennoch die gängigen Definitionen sowie die möglichen Unterscheidungskriterien zwischen Freier und Open Source Software. Ebenso erläutern wir Ihnen kurz, wie Public Domain, Free- und Shareware in diesen Kontext einzuordnen sind.

a) FOSS = Free Software + Open Source Software

66

Der Begriff der Freien Software – oder Free Software – wurde von der FSF bzw. deren Gründer, dem Programmierer Richard Stallman, Mitte der 1980er eingeführt und definiert. Stallman macht dabei deutlich, dass sich der Begriff „frei“ nicht auf den Preis der Software bezieht, sondern vielmehr auf die Freiheit des Benutzers im Umgang mit der Software. Ein Benutzer soll durch entsprechende Lizenzierung die Möglichkeit haben, die Software entsprechend seiner eigenen Bedürfnisse anzupassen und die Software sowohl in der ursprünglichen als auch in einer veränderten Form an andere Nutzer weiterzugeben. In der Free Software Definition – erstmals 1986 durch die FSF veröffentlicht – werden diese Freiheiten mit dem folgenden Satz knapp zusammengefasst: „Free software is a matter of the users’freedom to run, copy, distribute, study, change and improve the software.“51 Die Grundvoraussetzung Freier Software ist also eine umfassende Einräumung von Nutzungsrechten, die es jedem Nutzer ermöglichen, die Software frei zu kopieren, zu bearbeiten, zu untersuchen und zu verbreiten. Durch eine entsprechende Lizenzierung sollen also vielfältige Nutzungsmöglichkeiten geschaffen werden, ohne das eine Lizenzgebühr dafür erhoben wird.

67

Da durch die Bezeichnung „frei“ häufig falsche Assoziationen ausgelöst wurden und das Konzept Freier Software missverstanden wurde, gründete sich Ende der 1990er die Open Source Initiative (OSI) und führte den Begriff der Open Source Software ein. Mit diesem Begriff sollte das Kriterium des offenen und für jedermann verfügbaren Source Code stärker in den Vordergrund gerückt werden. Man wollte dem Missverständnis entgegenwirken, dass eine kommerzielle Verwertung Freier Software nicht möglich sei. Die OSI entwickelte dazu ebenfalls eine Definition des Begriffs Open Source Software und legte in ihrer Open Source Definition fest, welche Kriterien eine Lizenz erfüllen muss, um als Open Source Lizenz zu gelten. Darunter fällt vor allem, dass die Software von jedem Nutzer genutzt, bearbeitet und weitergegeben werden darf, ebenfalls sowohl in der ursprünglichen als auch in einer durch den Nutzer bearbeiteten Version, ohne dass hierfür Lizenzgebühren anfallen. Darüber hinaus sollen aus der Software abgeleitete Werke Dritten unter denselben Lizenzbedingungen zur Verfügung gestellt werden können. Änderungen an der Ursprungssoftware sollen kenntlich gemacht und es soll dem Nutzer ermöglicht werden, Zugriff auf den Source Code zu erhalten, insbesondere wenn er die Software nur als ausführbare Datei erhalten hat.52

68

Wie oben bereits erwähnt, wird, nach Betrachtung der für die beiden Begriffe Freie Software und Open Source Software definierten Voraussetzungen, deutlich, dass diese sich sehr stark ähneln und daher – zumindest aus der lizenzrechtlichen Sicht – in der Regel keiner strikten Trennung bedürfen. Auch wenn sich die hinter den Begrifflichkeiten stehenden Ideale und Philosophien (siehe Rn. 7ff.) unterscheiden und die FOSS Gemeinde teilweise sogar in zwei Lager spalten, sind diese für einen praxisrelevanten Einsatz von FOSS nicht relevant. Es geht vielmehr darum festzustellen, ob es sich bei der eingesetzten Software überhaupt um FOSS handelt und ob die entsprechenden Lizenzbedingungen eingehalten werden können. Deutlich wird dies auch dadurch, dass die meisten der gängigen Open Source Lizenzen sowohl von der FSF als auch von der OSI als Open Source Lizenzen anerkannt werden.

69

Backup: Wenn es sich bei Freier Software und Open Source Software doch (zumindest annähernd) um dieselbe Software handelt, spielt eine Unterscheidung dann überhaupt eine Rolle und wenn ja, wann?

Der Begriff Open Source steht für Kriterien, die von dem Begriff Freie Software mit umfasst werden, an einigen Stellen jedoch auch weniger restriktiv sind. Der freigegebene Source Code Freier Software erfüllt in der Regel auch immer die Anforderungen an Open Source. Umgekehrt erfüllt Open Source zwar in den überwiegenden Fällen die Anforderungen, die an Freie Software zu stellen sind, aber eben nicht immer.

Die FSF hält z.B. einige der Open Source Lizenzen für zu restriktiv, wenn diese es nicht gestatten, veränderte Versionen der Software zu erstellen oder zu vertreiben. Ebenso hat die Freie Software-Bewegung ein Problem damit, wenn Source Code unter schwachen Lizenzen ohne Copyleft lizenziert wird und die daraus erstellten, ausführbaren Dateien dann zusätzlich unfreie Bedingungen enthalten. Auch der Einsatz von Prüfsignaturen, die verhindern, dass der Nutzer abweichende Versionen der Software installiert und ausführt – sog. Tivoisierung (siehe ausführlich Rn. 628ff.) – widerspricht dem Gedanken Freier Software.

Um der Verwendung Freier Software unter solchen Rahmenbedingungen entgegenzuwirken, hat die FSF die GNU General Public License Version 3 (GPL-3.0) entwickelt.53 Während der Begriff Open Source und die Open Source-Bewegung eher auf praktischen Erwägungen gründen, stell der Begriff der Freien Software die Prinzipien von Freiheit und Gerechtigkeit in den Vordergrund. Stallman betont in seinen Veröffentlichungen aber immer wieder, dass die beiden Bewegungen zwar unterschiedlicher Meinung über die Grundsätze sind, in den praktischen Empfehlungen aber mehr oder weniger übereinstimmen. Eine Zusammenarbeit sowie eine Vermischung von Freier und Open Source Software sind also durchaus möglich.54

b) FOSS ≠ Closed Source Software

70

Zwar haben wir anhand der oben angeführten Definitionen nun eine bessere Idee davon, was FOSS eigentlich bedeutet. Wie so häufig wird das Ganze aber erst in Abgrenzung zu anderen Formen von Lizenzmodellen interessant. Denn neben FOSS stößt man auch noch auf weitere Konzepte „kostenloser“ oder „frei verwendbarer“ Software. Diese sind nicht immer trennscharf abzugrenzen und führen daher gelegentlich zu Verwechslungen.

aa) Kommerzielle Software

71

Kommerzielle Software oder auch proprietäre Software wird in der Regel als Gegenbegriff zur FOSS verwendet und bezieht sich auf herkömmlich lizenzierte Software. Dabei ist der Begriff „proprietär“ genau genommen kein solides Abgrenzungskriterium, denn der Begriff bezieht sich auf die Rechtsinhaberschaft, die grundsätzlich auch bei FOSS gegeben ist. Bei FOSS haben die Rechtsinhaber lediglich darauf verzichtet, Lizenzgebühren für die Einräumung von Nutzungsrechten zu erheben. Teilwiese wird auch der Begriff Closed Source Software verwendet. Aber auch dieser ist nur bedingt für eine Abgrenzung geeignet. Denn der offen zugängliche Source Code stellt eben auch nur ein Kriterium für die Einordnung als FOSS dar und nicht das einzige. Auf jeden Fall stellt die kommerzielle Software die stärkste Abgrenzung gegenüber FOSS dar, da hier in der Regel sowohl Lizenzgebühren für die Nutzung verlangt werden als auch strenge Beschränkungen bzgl. der Bearbeitung und Veränderung vorliegen oder diese überhaupt nicht gestattet sind.

bb) Freeware

72

Auch bei sogenannter Freeware, die vom Namen her zunächst den Eindruck Freier Software vermitteln mag, handelt sich es sich dem Grunde nach um kommerzielle Software. Einzige Voraussetzung zur Einordnung einer Software als Freeware ist die kostenfreie Überlassung der Software an den Nutzer. In diesem Punkt ähneln sich Freeware und FOSS. Daher kommt es hier aufgrund der Ähnlichkeit der Begriffe gelegentlich zu Verwechslungen. Damit enden die Gemeinsamkeiten aber auch. Denn anders als bei FOSS erhält der Nutzer bei Freeware in der Regel nur sehr eingeschränkte Nutzungsrechte. Häufig wird die Nutzung auf eine nicht-kommerzielle Verwendung beschränkt und eine Weiterverbreitung der Software sowie eine Bearbeitung und Veränderungen untersagt. Auch der Source Code wird bei Freeware regelmäßig nicht offengelegt. Die Einräumung der Nutzungsrechte für Freeware erfolgt über sogenannte End User License Agreements – kurz EULA – und nicht über FOSS Lizenzen. Freeware ist also dem Bereich kommerzieller Software zuzuordnen. Die in diesem Buch erläuterten Rahmenbedingungen zum Umgang mit FOSS finden daher keine Anwendung auf Freeware.

cc) Shareware

73

Ein weiterer Unterfall kommerzieller Software ist Shareware. Auch hierbei handelt es sich um reguläre kommerzielle Software, die dem Nutzer lediglich für einen gewissen Zeitraum kostenlos zur Verfügung gestellt wird. Nach Ablauf einer zeitlich begrenzten Testphase wird die Nutzung der Software häufig technisch behindert oder zumindest stark eingeschränkt, sofern der Nutzer keine weitergehende Lizenz zur Nutzung erwirbt. Aufgrund der kommerziellen Natur der Shareware fällt auch diese nicht in den Anwendungsbereich der FOSS.

dd) Was ist mit Public Domain?

74

Bei Public Domain Software handelt es sich um ein Phänomen, das auf die Besonderheiten des amerikanischen Rechts zurückzuführen ist. Danach ist es möglich, gänzlich auf sein Urheberrecht zu verzichten und ein Werk gemeinfrei zu stellen.55 Dies gilt prinzipiell für den gesamten angloamerikanischen Rechtsraum, in dem wegen der grundsätzlichen Übertragbarkeit des Urheberrechts z.B. auch eine juristische Person das Urheberrecht sowohl originär erwerben als auch das Recht von einer natürlichen Person übertragen bekommen kann.56

75

Ein solcher Verzicht auf das Urheberrecht ist unter Geltung der deutschen Urheberrechtsordnung sowie in vielen anderen europäischen Staaten jedoch nicht möglich (siehe z.B. § 29 Abs. 1 UrhG). Das Urheberrecht ist zum einen unveräußerlich; das Werk kann also nicht etwa in die Gemeinfreiheit entlassen werden. Zum anderen belässt das Schöpferprinzip dem Urheber zumindest den Kern der Urheberpersönlichkeitsrechte, die wegen ihres höchstpersönlichen Charakters ebenfalls unveräußerlich und unverzichtbar sind.57 Eine echte Gemeinfreiheit tritt hier daher nicht ein, so dass die Public Domain Software nach anderen Maßstäben zu beurteilen ist.

76

Die Public Domain wird hier daher als die Einräumung einer Lizenz an jedermann gewertet, die eine unbeschränkte Verwertung der Software gestattet.58 Da Public Domain Software regelmäßig im Source Code veröffentlicht wird und dem Nutzer, durch die Gemeinfreiheit bzw. die Lizenz zur unbeschränkten Verwertung, die typischen Freiheiten der FOSS gewährt, kann Public Domain auch mit unter den FOSS Begriff gefasst werden. Zumindest die in diesem Buch dargestellten Rahmenbedingungen sind auch auf Public Domain Software anwendbar.

50 Stallman, https://www.gnu.org/philosophy/open-source-misses-the-point.de.html. 51 Stallman, https://www.gnu.org/philosophy/free-sw.html.en. 52 OSI, The Open Source Definition, https://opensource.org/osd. 53 Stallman, https://www.gnu.org/philosophy/open-source-misses-the-point.de.html. 54 Stallman, https://www.gnu.org/philosophy/free-sw.html.en. 55 Zum rechtlichen Rahmen von Public Domain und den Besonderheiten auch ausländischer Rechtsordnungen Jaeger/Metzger, Open Source Software, Rn. 8 m.w.N. 56 Statt vieler Hoeren, in: Hoeren/Sieber/Holznagel, Hdb. MultimediaR, Teil 7.8 Rn. 25. 57 Statt vieler Bullinger, in: Wandtke/Bullinger, UrhG, Vor §§ 12 Rn. 5 m.w.N. 58 Jaeger/Metzger, Open Source Software, Rn. 8; Spindler, in: Spindler, Rechtsfragen bei open source, Kap. B. Rn. 13; Spindler, in: Schricker/Loewenheim, Vor §§ 69a ff. Rn. 19f. m.w.N.

Kapitel II Technische Grundlagen: Coding und Kompilierung

77

Bei der Bewertung des Einsatzes von FOSS genügt es häufig nicht, einfach nur festzustellen, dass FOSS eingesetzt wird und welche Lizenzen für die jeweils eingesetzten FOSS Komponenten zu beachten sind. Um ermitteln zu können, ob ein lizenzkonformer Einsatz der FOSS im konkreten Projekt möglich ist, muss oft auch die technische Ausgestaltung des Einsatzes der jeweiligen FOSS Komponenten ermittelt und berücksichtigt werden. Denn unterschiedliche technische Ausgestaltungen können – je nach Lizenz – zu einer anderen rechtlichen Bewertung führen. Während einige Lizenzen nur danach unterscheiden, ob die Software im Source Code oder lediglich als ausführbare Datei im Binärcode an den Nutzer weitergegeben wird, enthalten andere Lizenzen auch unterschiedliche Verpflichtungen, je nachdem in welcher Form die FOSS Komponenten mit eigenem, proprietärem Code interagiert.

78

Um die unterschiedlichen Anforderungen der FOSS Lizenzen, die sich konkret auf verschiedene technische Ausgestaltungen hinsichtlich der Nutzung der FOSS Komponenten beziehen, richtig einordnen und die Risiken des FOSS Einsatzes sachlich bewerten zu können, ist es hilfreich, sich einige technischen Grundlagen in Bezug auf Software-Erstellung und -Architektur anzueignen. In diesem Kapitel wollen wir daher einen kurzen Überblick über diejenigen technischen Grundlagen geben, auf die in FOSS Lizenzen regelmäßig Bezug genommen wird. Dies soll Ihnen einerseits dabei helfen, die Anforderungen der FOSS Lizenzen besser zu verstehen, und andererseits, bei auftretenden Problemen nicht nur juristische, sondern auch technische Lösungsansätze für Ihre eigenen Projekte zu finden.

1. Welche Arten von Code gibt es?

79

 – FOSS Lizenzen enthalten teilweise unterschiedliche Anforderungen, je nachdem in welcher Form die Software an den Nutzer weitergegeben wird.

 – Zumindest muss zwischen menschenlesbarem Code (Source Code) und maschinenlesbarem Code (Object Code, Binaries, Executables) unterschieden werden.

 – Durch den Kompiliervorgang wird der Source Code zu Object Code/Binärcode/Executables umgewandelt.

80

Verschiedene FOSS Lizenzen machen unterschiedliche Vorgabe zur Nutzung der Software bzw. knüpfen andere Verpflichtungen an den Einsatz der Software, je nachdem, in welcher Form die Software an den Nutzer weitergegeben wird. Daher ist es wichtig, die unterschiedlichen Formen zu kennen, in denen der Code einer Software vorliegen kann und wie diese unterschiedlichen Formen von Code jeweils erzeugt werden können.

a) Source Code bzw. Quellcode

81

Source Code – häufig auch Quellcode oder Quelltext genannt – ist der für den Menschen lesbare, in einer der diversen Programmiersprachen verfasste Text eines Computerprogramms. Er beschreibt sowohl die jeweiligen Funktionen der Software als auch deren Aussehen bzw. die Darstellung des Programms bei der Ausführung. Bevor ein im Source Code vorliegendes Programm von einem Computer ausgeführt werden kann, muss der Source Code zunächst in eine für den Computer verständliche Form übersetzt werden. Dies geschieht z.B. mittels eines Compilers oder Interpreters, der entweder vorab den kompletten Source Code in Maschinensprache übersetzt oder dies erst zur Laufzeit des Programms tut.1 Im Source Code liegen neben den reinen Informationen, die für die Ausführung des Programms notwendig sind, in der Regel auch noch andere nützliche Informationen vor, wie beispielsweise Dokumentationen und Hinweise zur Anpassung des Code oder zur Fehlerbehebung. Die für die FOSS Bewertung relevantesten Informationen sind aber die häufig in den Headern der Dateien enthaltenen Angaben zur Lizenzierung der Software. Oft werden hier der jeweilige Text der FOSS Lizenz oder zumindest ein Verweis auf die Lizenz und auf den Ort, wo der Lizenztext zu finden ist, sowie Hinweise zum jeweiligen Rechtsinhaber der Software angegeben.

b) Object Code

82

Die nächste Stufe zwischen dem Source Code und der Maschinensprache ist der sog. Object Code oder auch Objektcode. Der Object Code ist ein Zwischenergebnis, das bei der Übersetzung des menschenlesbaren Code mittels eines Compilers entsteht. Er besteht bereits hauptsächlich aus Maschinencode und enthält neben dem bereits vorübersetzten Code des Programms andere verwendete Programmbibliotheken, die ebenfalls in das Programm eingefügt und mit diesem zum fertigen Programm verlinkt werden sollen. Das Format des Object Code hängt sowohl von der Programmiersprache, dem verwendeten Compiler als auch der Maschine ab, auf der das Programm ablaufen soll.2 Wichtig für die FOSS Beurteilung ist, dass der Object Code in der Regel keine verwertbaren bzw. für den Menschen lesbaren Informationen zur FOSS Lizenzierung mehr enthält. Die meisten FOSS Lizenzen stellen den Object Code daher mit dem Binärcode gleich und stellen in der Regel identische Anforderungen an die Weitergabe im Object oder im Binärcode.

c) Binärcode

83

Die Maschinensprache, oder auch der Binärcode bzw. Maschinencode, stellt die Code Form dar, die ein Computer benötigt, um ein Programm verarbeiten und ausführen zu können. In dieser Form des Code werden Informationen durch Sequenzen zweier unterschiedlicher Symbole dargestellt. Im Falle eines Computerprogramms besteht der Code nur noch aus Einsen und Nullen bzw. der Information wahr/falsch. Die kleinste Informationseinheit wird dabei als Bit bezeichnet und enthält genau diese eine Information: 1 oder 0 bzw. wahr oder falsch. Durch eine logische Verknüpfung solcher Bits lassen sich dann auch komplexe Informationen abbilden.3 Für den Menschen sind diese Bitfolgen kaum noch nachzuvollziehen. Bei reiner Betrachtung von Code in Binärform können dem Code also ohne weitere Zwischenschritte keine Informationen zu FOSS Lizenzierung und Rechtsinhabern mehr entnommen werden – sofern diese Informationen überhaupt noch im jeweiligen Code enthalten sind. Daher stellen einige FOSS Lizenzen besondere Anforderungen an die Mitlieferung von Lizenz- und Copyright Informationen für den Fall, dass die FOSS Komponente im Binärcode weitergegeben wird.

d) Executables

84

Eng mit dem Binärcode hängen die ausführbaren Dateien oder Executables zusammen. Dabei handelt es sich um Dateien, die als Computerprogramm ausgeführt werden können. Sie enthalten also den oben beschriebenen maschinenlesbaren Programmcode, der direkt oder durch eine Laufzeitumgebung – ein sog. runtime environment – ausgeführt werden kann. In einigen Fällen werden auch Dateien, die Bytecode oder Scripting Anweisungen enthalten, als ausführbare Dateien bezeichnet.4 Für dieses Buch sollen sich die Begriffe ausführbare Datei bzw. Executable einfach auf ausführbare Computerprogramme beziehen, die aufgrund ihrer Maschinenlesbarkeit keine für den menschlichen Betrachter verarbeitbaren Informationen zu FOSS Lizenzierung und Rechtsinhabern enthalten.

85

Backup: Erkennen von Code Formen anhand der Dateiendung

Anhand von Dateiendungen lässt sich bereits auf den ersten Blick erkennen, um welche Art von Code es sich bei einer Datei handelt. Mit dem Blick auf die Dateiendung kann man also direkt feststellen, ob es sich um Source Code oder um ausführbare Dateien handelt. Damit sehen Sie auch auf den ersten Blick, ob sich aus der jeweiligen Datei ggf. noch weitere Informationen für die FOSS Bewertung ziehen lassen (wie Angaben zu Copyrights und Lizenzierung in den Datei-Headern von Source Code Dateien) oder ob für die vorliegende Datei ggf. andere und/oder strengere Lizenzbedingungen gelten (für den Fall, dass die Lizenz unterschiedliche Vorgaben für die Weitergabe als ausführbare Datei macht).

Dateiendungen, die darauf hinweisen, dass es sich um Source Code handelt, sind beispielsweise .c, .h, .src oder .java. Hierbei handelt es sich jeweils um Textdateien, die Source Code oder Deklarationen zum Source Code enthalten. Auch bei Dateien, die auf .txt enden, handelt es sich um Textdateien. Solche im Code enthaltenen .txt Dateien enthalten häufig Informationen zur Lizenzierung, den Rechtsinhabern oder weitere hilfreiche Informationen zur Software (z.B. als LICENSE.txt, COPYING.txt oder README.txt).

Bei Dateiendungen wie .html oder .js handelt es sich zwar um Dateien, die von der Maschine direkt ausgeführt werden können, bei denen aber dennoch der Source Code direkt vorliegt und – z.B. mittels eines Texteditors – betrachtet werden kann. Da hier alle Informationen für den Betrachter lesbar vorhanden sind, können diese wie Source Code behandelt werden.

Hinsichtlich der ausführbaren Dateien und somit des Binärcodes dürfte die Dateiendung .exe wohl die bekannteste sein. Allerdings gibt es auch noch zahlreiche andere Dateiendungen, die auf Binärcode hindeuten, wie beispielsweise .dll oder .so, die auf Programmbibliotheken hindeuten, aber z.B. auch .msi, .bin oder .dat.

Bei der Endung .jar ist die Einordnung nicht immer auf den ersten Blick möglich. Denn hierbei kann es sich entweder um eine Java-Anwendungsdatei handeln, die durch Anklicken ausgeführt werden kann, oder aber um ein Java Archiv, das mehrere Java Dateien und auch andere Dateien enthalten kann. Diese Archive können dann mittels eines Packprogramm (wie WinZip, 7-Zip, o.ä.) geöffnet werden, um zu ermitteln, welche Art von Dateien sich darin befinden.

1 https://de.wikipedia.org/wiki/Quelltext. 2 https://en.wikipedia.org/wiki/Object_code. 3 https://de.wikipedia.org/wiki/Binärcode. 4 https://de.wikipedia.org/wiki/Ausführbare_Datei.

2. Von welchen Tools die Entwickler sprechen

86

 – Entwicklung und Build sind unterschiedliche Bereiche; Entwicklung betrifft die Erstellung von Code, Build den Kompilierprozess, also die Erzeugung der Executables.

 – Entwicklungsumgebungen, SDKs und Package Manager unterstützen bei der Verwaltung und Erzeugung von Code.

 – Der Compiler erzeugt aus Source Code zusammen mit einem Linker ein ausführbares Programm, das nur noch in maschinenlesbarer Form vorliegt.

87

Zur Erstellung von Code bzw. Software werden unterschiedliche Werkzeuge – sogenannte Programmierwerkzeuge oder Entwicklungstools – benötigt. Dabei handelt es sich um Computerprogramme, die es ermöglichen, Code zu erzeugen und diesen anschließend weiter zu be- und verarbeiten. Um besser zu verstehen, wie Software entsteht und bei welchen Entwicklungsschritten z.B. welche Formen von Code entstehen, wollen wir hier einen kurzen Überblick über die gängigen Werkzeuge zur Erstellung und Bearbeitung von Code geben, insbesondere dort, wo diese auch im Zusammenhang mit der Bewertung von FOSS relevant sein können.

88

Es gibt grundsätzlich unterschiedliche Herangehensweisen bei der Erstellung und Bearbeitung von Code. So können entweder einzelne Programmiertools verwendet werden, die sich der Entwickler nach Bedarf selbst zusammenstellt, oder es wird auf sogenannte Entwicklungsumgebungen zurückgegriffen, die bereits alle notwendigen Hilfsprogramme mitbringen.

Abbildung 1: Software-Entwicklung/Build-Prozess© Jun Rechtsanwälte (CC BY-SA 4.0)

a) Entwicklungsumgebungen und Build-Tools

89

Bei dem Begriff „Entwicklungsumgebung“ handelt es sich um einen Oberbegriff für unterschiedliche Arten von Hilfsmitteln zur Erzeugung und Bearbeitung von Code. So fallen unter diesen Begriff beispielsweise IT-Plattformen bzw. Systemumgebungen, auf denen Software entwickelt wird, oder Sammlungen von Computerprogrammen zur Software-Entwicklung, z.B. die sogenannten integrierten Entwicklungsumgebungen oder Software Development Kits. Der Begriff „Build-Umgebung“ bezieht sich dagegen nicht auf die Erstellung von Code, sondern den darauf folgenden Schritt, nämlich das Erzeugen von Executables. Build-Tools sind also die Programme, die beim Kompilieren eingesetzt werden.

90

Bei der Systemumgebung handelt es sich einfach um eine Plattform, mit der ein informationstechnisches System betrieben wird. Ein solches System hat dabei häufig einen dreistufigen Aufbau, der aus einer Entwicklungsumgebung besteht, auf der der Entwickler neue Software entwickelt, einer Testumgebung, auf der die neu erstellte Software getestet werden kann, und einer Produktivumgebung, auf der die Software letztendlich betrieben und zu Geschäftszwecken genutzt wird. Die Entwicklungsumgebung der Systemumgebung beschreibt dabei kein eigentliches Entwicklungswerkzeug, sondern lediglich den Ort, an dem neue Software entwickelt wird.5

91

Eine integrierte Entwicklungsumgebung oder auch IDE (kurz für Integrated Development Environment), stellt eine Sammlung verschiedener aufeinander abgestimmter Computerprogramme dar, die der Entwicklung von Software dienen. Solche IDEs gibt es für nahezu alle Programmiersprachen und Plattformen, wobei eine IDE in der Regel jeweils nur eine Programmiersprache unterstützt. Statt eine IDE zu verwenden, kann ein Entwickler sich die zur Software-Entwicklung benötigten Einzelwerkzeuge wie Texteditor, Compiler, Linker, etc. (mehr dazu siehe Rn. 97ff.) auch einzeln besorgen und zusammenstellen. Der Vorteil der IDE besteht jedoch darin, dass die einzelnen Werkzeuge bereits gut aufeinander abgestimmt sind und Software-Entwicklung in der Regel ohne Medienbrüche stattfinden kann.6 Beispiele für solche IDEs sind u.a. Eclipse oder die NetBeans IDE.

92

Neben den IDEs gibt es auch noch die Software Development Kits (kurz: SDKs). Diese stellen ebenfalls eine Sammlung von verschiedenen Werkzeugen und Hilfsmitteln zur Erstellung von Software dar und beziehen sich meist auf ein konkretes Produkt, wie z.B. Android, oder eine Programmiersprache und stellen dafür dann neben den Entwicklungstools auch entsprechende Schnittstellen und Dokumentationen, diverse Bibliotheken und manchmal auch Testprojekte zur Verfügung. Viele SDKs beinhalten bereits eine entsprechende IDE, mit der die anderen vom SDK bereitgestellten Komponenten genutzt werden können. Jedoch ist es auch möglich, die durch ein SDK bereitgestellten Funktionen in einer selbstgewählten IDE zu nutzen.7 Beispiele für SDKs wären das Android SDK oder das Java Development Kit (JDK).

93

Weitere wichtige Werkzeuge sind die Build-Tools. Hierbei handelt es sich ebenfalls wieder um Computerprogramme. Diese dienen aber nicht der grundsätzlichen Erstellung von Code, sondern vielmehr dazu, den bereits geschriebenen Source Code in ausführbaren Code umzuwandeln. Zwar sind auch IDEs mit ihren integrierten Compilern in der Lage dazu, aus dem dort geschriebenen Source Code ein ausführbares Programm zu erzeugen. Allerdings muss dies hier händisch durch den Entwickler angestoßen werden. Die Build-Tools bieten die Möglichkeit, den Build-Prozess – also die Kompilierung des Source Code in ein ausführbares Programm (siehe ausführlich Rn. 97ff.) – zu automatisieren und so z.B. zu ermöglichen, den Build immer zu einem festgelegten Zeitpunkt mit dem bis dahin neu hinzugefügten Code automatisch durchzuführen.8 Bekannte Build-Tools sind z.B. Maven, Gradle oder Ant.

94

Gelegentlich stößt man auch auf den Begriff Toolchain. Auch diese bezeichnet eine systematische Sammlung von verschiedenen Werkzeugen zur Erstellung und Bearbeitung von Code und beschreibt damit im Grunde etwas Ähnliches wie die bereits oben erwähnten Entwicklungsumgebungen. Der Begriff der Toolchain stammt daher, dass die unterschiedlichen Werkzeuge nacheinander in Form einer Kette eingesetzt werden. Hier sind regelmäßig ebenfalls Texteditoren zur Erstellung des Code sowie Compiler und Linker zur Umwandlung in ein ausführbares Programm enthalten.9 Ein bekanntes Beispiel für eine Toolchain ist die GNU Toolchain, die alle vom GNU Projekt entwickelten Programmierwerkzeuge enthält.

95

Ein ebenfalls wesentlicher Teil bei der Erstellung und Verwaltung von Code sind die sog. Paketverwaltungen oder Package Manager. Diese stellen ebenfalls eine Sammlung von Werkzeugen dar, die diesmal aber nicht zur Erstellung, sondern lediglich zur Verwaltung von Code dienen. Die Hauptfunktionen der Package Manager sind die Installation, Aktualisierung und Deinstallation von Software. Wichtigster Bestandteil ist die Paketdatenbank, die alle Informationen über installierte bzw. zur Verfügung stehende Software-Pakete beinhaltet. Grundsätzlich stammt diese Art der Software-Verwaltung aus dem Umfeld von Betriebssystemen und ermöglicht die einfache Verwaltung der auf und mit dem Betriebssystem betriebenen Software.10

96

Der Begriff des Package Manager wird aber auch für Plattformen verwendet, auf denen Entwickler Software-Pakete zur Lösung diverser Problemstellungen finden und die zudem die Möglichkeit bieten, die entsprechenden Pakete zu verwalten oder diese direkt in eigene Software oder eigene Software-Paketen zu integrieren. Ein Beispiel für eine solche Plattform ist der Node Package Manager oder kurz npm. npm ist ein Package Manager für node.js, die Laufzeitumgebung von JavaScript. Er bietet eine große Datenbank an bereits fertigen Paketen, die Möglichkeit, diese Pakete zu bearbeiten und an eigene Bedürfnisse anzupassen sowie die Pakete zu verwalten und mit anderen zu teilen.11 Auch wenn die Package Manager eher als Werkzeuge zur Verwaltung gedacht sind, kann damit, durch Einbeziehung diverser bereitgestellter Pakete in die eigene Software, natürlich auch Software bearbeitet werden.

b) Werkzeugkoffer zum Coden – Compiler, Parser, Linker und Interpreter

97

Wie bereits erwähnt, bedarf es spezieller Programme und Zwischenschritte, um zwischen den unterschiedlichen Formen des Code zu wechseln. Code, der in einer der gängigen Programmiersprachen geschrieben wurde, liegt zunächst im menschenlesbaren Source Code vor. Soll dieser Code dann zu einer ausführbaren Datei werden, muss er in eine maschinenlesbare Form übersetzt werden. Dazu werden spezielle Programme verwendet, die Compiler genannt werden. Compiler wandeln also Source Code in Maschinensprache um und übersetzen dabei das gesamte Programm und erzeugen dadurch zusammen mit einem Linker ein Executable, das auch separat – also ohne den Source Code – weitergegeben werden kann.

98

Backup: Kurze Übersicht zu gängigen Compilern

Es existieren zahlreiche Compiler und Linker für jede Programmiersprache. Nicht jeder Compiler und/oder Linker ist dabei gleich gut für jedes Vorhaben geeignet, da die unterschiedlichen Programme unterschiedliche Stärken und Schwächen aufweisen. Allerdings haben sich einige gängige Programme durchgesetzt, zu denen wir hier einen kurzen Überblick geben wollen.

Compiler für C und C++:

GNU GCC Compiler, Clang, Intel C++ Compiler, Microsoft Visual C++, Oracle C Compiler, Wind River (Diab) Compiler

Compiler für Java:

GNU Compiler for Java, javac, Eclipse Compiler for Java (JDT Core), Iodine

Compiler für Python:

Psyco, Cython, PyPy, Shed Skin

Viele der gängigen und oben genannten Compiler stehen unter FOSS Lizenzen und können daher in der Praxis Probleme mit sich bringen. Während einige Compiler, wie z.B. PyPy, unter liberalen Lizenzen stehen, stehen viele der gängigen Compiler, wie z.B. der GCC Compiler, der Java Compiler von Eclipse oder auch Shed Skin, unter strengen FOSS Lizenzen mit Copyleft. Gerade der GCC Compiler unter der GPL ist ein gutes Beispiel für Probleme, die mit FOSS Compilern auftreten können. Denn der GCC Compiler fügt während des Kompilierprozesses Teile seines eigenen (unter der GPL lizenzierten) Code – insbesondere einige GCC Header Dateien oder Runtime Libraries – in das kompilierte Programm ein.12 Diese GPL lizenzierten Code Bestandteile können dann ein Copyleft auslösen und so die kompilierte Software infizieren. Da die FSF dieses Problem aber erkannt hat und nicht grundsätzlich verhindern will, dass auch kommerzielle Programme mit dem GCC Compiler erstellt werden können, wurde hier eine Ausnahme, die sog. GCC Runtime Library Exception, geschaffen. Diese besagt, dass das Ergebnis eines Kompilierprozesses mit dem GCC Compiler nicht zwingend unter der GPL lizenziert werden muss, auch wenn in dem Ergebnis Code Bestandteile unter der GPL enthalten sind.

Bei dem Einsatz von FOSS Compilern sollte also immer darauf geachtet werden, ob der Compiler FOSS lizenzierten Code in das kompilierte Programm einfügt und ob bei Copyleft Lizenzen ggf. entsprechende Ausnahmen existieren, die in solchen Fällen von einem Copyleft befreien. Um diese Probleme zu umgehen, können ansonsten auch einfach kommerzielle Compiler wie beispielsweise die von Microsoft oder Wind River Systems verwendet werden.

99

Häufig gibt es bei dieser Übersetzung einen Zwischenschritt, bei dem der Source Code zunächst in eine Art Zwischencode – den oben erwähnten Object Code (siehe Rn. 82) – umgewandelt wird. Dieser Zwischencode hat den Vorteil, dass er häufig auf verschiedenen Plattformen läuft und auch von Interpretern verwendet werden kann. Diesen so entstandenen Object Code übersetzt der Compiler dann weiter in den Maschinencode, der vom jeweiligen Zielsystem verstanden werden kann. Der Linker – ebenfalls ein gesondertes Computerprogramm – setzt dann die kompilierten Programmbestandteile und -module, die mittels des Compilers erzeugt wurden, zu einer ausführbaren Datei zusammen, um auf diese Weise das fertige Programm zu erhalten. Bei dieser Zusammensetzung der Programmteile gibt es unterschiedliche Arten, die als statische und dynamische Verlinkung bezeichnet werden (siehe Rn. 106f.).

100

Neben den Compilern, die direkt Binärcode erzeugen, gibt es auch noch sog. Interpreter. Dabei handelt es sich um Programme, die Source Code direkt zur Laufzeit verarbeiten. Die Anweisung im Source Code wird dabei eingelesen, analysiert und dann ausgeführt. Anders als beim Compiler wird dadurch keine Datei erzeugt, die mehrmals ausgeführt werden kann, und es entsteht auch keine dauerhafte Übersetzung des Source Code. Der Interpreter stellt eher eine Zwischenschicht zwischen Programmiersprache und Maschine dar, die die Anweisungen des Source Code analysiert und dann die gewünschte Aktion im Zielsystem aufruft und ausführt. Man erhält durch den Einsatz eines Interpreters also kein unabhängiges Executable, sondern benötigt weiterhin den Source Code des auszuführenden Programms.13

101

Eine weitere Form von Hilfsprogrammen, mit denen man bei der Umwandlung von Code häufig zu tun hat, sind Parser. Mit einem Parser kann der Quelltext entsprechend aufbereitet werden, indem dieses Programm die Zeichenketten analysiert und in eine Repräsentation umwandelt, mit der ein anderes Programm arbeiten kann. Die meisten Programmiersprachen sind so gestaltet, dass sie für den Entwickler übersichtlich und komfortabel sind. Die oben bereits erwähnten Compiler können aber mit zusätzlich im Source Code enthaltenen Informationen, wie z.B. Kommentaren der Entwickler, nichts anfangen und diese nicht sinnvoll in Maschinensprache übersetzen. Hier hilft der Parser dabei, den Quelltext zu analysieren und zu bereinigen, so dass der Compiler im Anschluss den überarbeiteten Code verwenden und umwandeln kann.14 Ein weiteres Beispiel für ein solches Programm wäre der in einem Webbrowser enthaltene Parser, der den rein als Text vorliegenden HTML Code so aufbereitet, dass damit die entsprechende Webseite angezeigt werden kann.

102

Backup: Gängige FOSS Parser

Auch bei den Parsern gibt es zahlreiche Programme unter FOSS Lizenzen. Einige gängige FOSS Parser sind z.B. GNU Bison15, ANTLR16, JavaCC17, OpenL18, runcc19 oder SJPT20.

Wie bei den Compilern sollte auch bei den Parsern auf die Lizenzierung geachtet werden. Zwar stehen einige der Programme unter liberalen Lizenzen, für viele sind aber ebenfalls strenge Copyleft Lizenzen einschlägig. Parser dienen zwar eher zur Analyse und Aufbereitung des Code als zu dessen eigentlicher Erstellung; es ist jedoch trotzdem möglich, dass Teile des Parsers in den damit analysierten und bearbeiteten Programmcode eingefügt werden. Auch hier ist das Programm der FSF, der GNU Bison Parser, wieder ein gutes Beispiel. Um es Entwickler zu ermöglichen, auch mit einem unter der GPL lizenzierten Parser kommerzielle Programme zu erstellen, hat die FSF hier wiederum eine Ausnahme zur GPL speziell für ihren Bison Parser geschaffen. Diese sog. Bison Exception ermöglicht es, das Ergebnis aus dem Parser trotz ggf. enthaltenem GPL Code unter eine eigene Lizenz zu stellen.21

5 https://de.wikipedia.org/wiki/Systemumgebung. 6 https://de.wikipedia.org/wiki/Integrierte_Entwicklungsumgebung. 7 Augsten, https://www.dev-insider.de/was-ist-ein-sdk-a-730921/. 8 https://www.it-talents.de/blog/it-talents/alles-ueber-den-build-prozess#-ides-und-build-tools. 9 https://de.wikipedia.org/wiki/Toolchain. 10 Augsten, https://www.dev-insider.de/was-ist-eine-software-paketverwaltung-a-847919/. 11 https://www.onlinesolutionsgroup.de/blog/glossar/n/npm-node-package-manager/. 12 FSF, Using the GNU Compiler Collection (GCC), Ziff. 6.59, https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc.pdf. 13 Augsten, https://www.dev-insider.de/der-unterschied-von-compiler-und-interpreter-a-742282/. 14 Augsten, https://www.dev-insider.de/was-ist-ein-parser-a-756662/. 15 https://www.gnu.org/software/bison/manual/. 16 https://www.antlr.org/. 17 https://cs.lmu.edu/~ray/notes/javacc/. 18 http://openl.org/. 19 https://java-source.net/open-source/parser-generators/runcc. 20 http://sjpt.sourceforge.net/. 21 https://www.gnu.org/software/bison/.

3. Juristen müssen diese Verlinkung verstehen

103

 – Für das Auslösen eines Copyleft kommt es auf die Verbindungen des FOSS Code mit eigenen Programmbestandteilen an.

 – Daher sollte die konkrete Art der Verlinkung (statisch, dynamisch oder andere Formen der Interaktion von Code) ermittelt und korrekt anhand der Lizenzvorgaben eingeordnet werden.

 – Die Art der Verlinkung von FOSS mit eigenen Programmbestandteilen ist abhängig von der verwendeten Programmiersprache, da nicht alle Programmiersprachen alle Arten der Verlinkung zulassen.

104

Zahlreiche FOSS Lizenzen – insbesondere solche mit einem beschränkten Copyleft – knüpfen unterschiedliche Anforderungen und Konsequenzen an den Einsatz der jeweiligen FOSS Komponente, je nachdem wie diese mit dem übrigen, meist proprietären Code der Software interagiert. Es kommt dabei in der Regel darauf an, wie stark die FOSS Komponente in die eigene Software eingebunden wird. Wir sprechen hier von statischer oder dynamischer Verlinkung, um zu beschreiben, wie eng die FOSS Komponente mit proprietärem Code verbunden ist. Um diese Differenzierung besser nachvollziehen zu können, möchten wir an dieser Stelle zum einen erklären, wie wir die Begriffe der statischen und dynamischen Verlinkung grundsätzlich verstehen und in diesem Buch Bezug darauf nehmen. Zum anderen soll kurz dargestellt werden, wie sich die unterschiedlichen Arten der Verlinkung in diversen Programmiersprachen manifestieren können. Denn je nachdem, in welcher Programmiersprache die jeweilige Software geschrieben wurde, kommen bereits nur bestimmte Arten der Verlinkung überhaupt in Frage bzw. wird der Begriff der Verlinkung möglicherweise anders genutzt und kann so zu Missverständnissen führen.

a) Statische vs. dynamische Verlinkung

105

Zunächst betrachten wir einmal grundsätzlich die Verlinkung von Software-Bestandteilen. Bei einer Verlinkung handelt es sich um eine Verbindung zweier Software-Bestandteile, so dass diese – ggf. noch mit mehreren anderen Software-Komponenten – ein komplettes Programm bilden. Eine solche Verbindung ist auf verschiedene Weisen möglich, je nachdem wie eng die beiden Software-Bestandteile dabei miteinander verknüpft werden. In der Regel wird hier nach statischer und dynamischer Verlinkung unterschieden.

106

Unter einer statischen Verlinkung versteht man allgemein eine feste Verbindung von zwei Software-Komponenten. Hier wird bei der Erstellung des Programms durch Kompilieren die FOSS Komponente mittels des Linkers mit dem restlichen (proprietären) Code der Software zu einer einzigen Datei zusammengefügt.22 Im Anschluss an den Kompilierprozess existiert daher nur noch ein ausführbares Programm, in dem sowohl der eigene Programmcode als auch der Code der verwendeten FOSS – oder anderer Software-Komponenten – als eine Einheit enthalten sind. Auf diese Weise ist die FOSS Komponente untrennbar mit dem restlichen Code verbunden, so dass hier im Nachhinein die FOSS Komponente weder entfernt oder ausgetauscht werden kann.

107

Eine dynamische Verlinkung ist dagegen eine lose Verbindung zwischen zwei Software-Komponenten. Die beiden Software-Komponenten werden hierbei bei der Kompilierung nicht durch den Linker zu einem einzigen gemeinsamen Programm zusammengefügt, sondern bleiben weiterhin als einzelne Bestandteile bestehen. Die proprietäre Software greift hier erst zur Laufzeit – also im Zeitpunkt der Ausführung des Programms – auf die FOSS Komponenten und deren Funktionen zu.23 Dies ermöglicht es, die FOSS Komponente auch im fertigen Programm noch zu entfernen oder zu ersetzen.

108

Backup: Für den Anfang mag ein grundsätzliches Verständnis dafür genügen, was dynamische Verlinkung bedeutet. Nämlich eine Verbindung zweier Software-Komponenten, die es ermöglicht, eine der Komponenten auch später auszutauschen (z.B. gegen eine neuere Version der Komponente oder gegen eine an die eigenen Bedürfnisse angepasste Komponente).

Die konkreten technischen Anforderungen an eine dynamische Verlinkung – so wie sie beispielsweise auch von der LGPL-2.1 ausdrücklich vorausgesetzt werden – zu kennen, ist aber relevant, um den konkreten Einsatz einer Software auf Lizenzkonformität zu überprüfen und sicherzustellen, dass der Copyleft Effekt sich nicht auf eigene, proprietäre Bestandteile der Software auswirkt.

Im Folgenden werden daher im Überblick die konkreten technischen Anforderungen an eine dynamische Verlinkung dargestellt, so wie sie von der LGPL-2.1 vorausgesetzt wird. Dies sind auch die Kriterien, von denen wir ausgehen, wenn wir in diesem Buch auf eine dynamische Verlinkung Bezug nehmen:

 – Die FOSS Komponente bleibt als eigenständiges File im File System identifizierbar,

 – sie interagiert nur über Standardschnittstellen mit anderer (insbesondere proprietärer) Software

 – und ist zumindest theoretisch, wenn auch mit einigem Aufwand, durch den Nutzer austauschbar.

109

Die Unterscheidung der dynamischen und statischen Verlinkung für die FOSS Compliance beruht hauptsächlich auf der LGPL, da diese Lizenz spezielle Ausnahmen für eine dynamische Einbindung von unter der LGPL stehenden Programmteilen (hauptsächlich Bibliotheken) enthält. Dabei enthält die LGPL jedoch an keiner Stelle den Begriff der dynamischen Verlinkung, sondern lediglich eine Beschreibung der Voraussetzungen für eine zulässige Einbindung (siehe Rn. 108). Die LGPL hat damit zwar die Voraussetzungen der dynamischen Verlinkung, nicht aber den konkreten Begriff geprägt. Dieser wurde vielmehr durch die Anwender geprägt.

b) So linken die verschiedenen Programmiersprachen

110

Als nächstes betrachten wir nun, wie diese Arten der Verlinkung sich in der Praxis in diversen gängigen Programmiersprachen manifestieren. Denn je nachdem, welche Programmiersprache vorliegt, sind verschiedene Arten der Verlinkung möglich.

111

Programmiersprachen sind formale Sprachen, mit denen Datenstrukturen und Algorithmen, also Rechenvorschriften, formuliert werden können, die dann von einem Computer ausgeführt werden können. Sie folgen dabei einem bestimmten Regelsystem, nach dem die unterschiedlichen Anweisungen an den Computer formuliert werden können.24 Es existieren zahlreiche Programmiersprachen, die alle ihre eigenen Anwendungsgebiete haben. Hier wollen wir einige der gängigsten Sprachen vorstellen und zeigen, wie sich in diesen die Verbindung von einzelnen Programmbestandteilen unterscheiden kann.

aa) C und C++

112

Programmiersprachen, die sowohl statische als auch dynamische Verlinkungen einzelner Programmteile zulassen, sind beispielsweise C sowie die darauf aufbauende Programmiersprache C++. Die Anwendungsbereiche dieser beiden Programmiersprachen sind groß, da sowohl C als auch C++ jeweils für System- und Anwenderprogrammierung verwendet werden können. Daher tauchen diese Programmiersprachen im Bereich der FOSS auch häufig auf. In C, C++ oder anderen Programmiersprachen dieser Art, können FOSS und andere Software-Komponenten entweder mittels des Linkers bei der Kompilierung statisch mit dem restlichen Programmcode verbunden werden. Es ist aber auch möglich, mittels einer entsprechenden Schnittstelle dafür zu sorgen, dass andere, separat kompilierte FOSS und Software-Komponenten erst während der Laufzeit durch das eigene Programm aufgerufen werden.25

bb) Python

113

Eine weitere Programmiersprache, die grundsätzlich sowohl statische als auch dynamische Verlinkungen zulässt, ist Python. Ähnlich wie bei C handelt es sich hier ebenfalls um eine Programmiersprache, die sehr vielseitig einsetzbar ist, da sie mehrere Paradigmen der Programmierung unterstütz. Die meisten Python Distributionen basieren auf dynamischen Verlinkungen. Es stehen viele eigenständige Libraries zur Verfügung, auf die im eigenen Code referenziert und deren Funktionalität dann während der Laufzeit aufgerufen werden kann. Diese Libraries werden von dem System bereitgestellt, auf dem Python läuft (dies kann z.B. das Linux Betriebssystem sein). Python ermöglicht es aber auch, entsprechend benötigte Libraries statisch einzubinden. Dabei steht der Code der verwendeten Library dann nicht mehr separat auf dem System zur Verfügung, sondern wird direkt zusammen mit dem übrigen Python Code mittels des Linkers zu einer einzigen Binärdatei zusammengefügt.26

cc) Java

114

Bei der Programmiersprache Java, die für die Programmierung von Anwendungen wie Desktop-Programmen, Webanwendungen oder Apps verwendet wird, sieht dies ein wenig anders aus. Hierbei handelt es sich um eine objektorientierte Programmiersprache, bei der die einzelnen Bestandteile und Funktionen in sog. JARs bereitgestellt werden. Die JARs entsprechen dabei grundsätzlich dem, was in den meisten anderen Programmiersprachen als Library bezeichnet wird. Werden zwei oder mehr JARs miteinander verbunden, geschieht dies in Java ausschließlich über Schnittstellen, über die die JARs dann mit anderen JARs kommunizieren und so ein ganzes Programm bilden. Die Verlinkung zwischen zwei in Java programmierten Software-Bestandteilen ist daher immer als eine dynamische Verlinkung einzuordnen. Eine statische Verlinkung, bei der mehrere einzelne Bestandteile fest miteinander zu einem einzigen Programm verbunden werden, ist in dieser Programmiersprache nicht vorgesehen.27

115

Backup: Sind unter LGPL stehende Programme in Java nutzbar?

Die LGPL enthält Ausnahmen vom Copyleft für solche Programmteile, die mittels einer dynamischen Verlinkung mit dem restlichen Programmcode verbunden sind. Aufgrund der Struktur von Java, die ohnehin immer eine dynamische Verlinkung zwischen einzelnen Programmteilen und Bibliotheken vorsieht, sollte der Einsatz LGPL lizenzierter Software daher unproblematisch sein. Dennoch findet man gerade in Entwicklerforen häufig Verwirrung darüber, ob die LGPL für eine in Java programmierte Anwendung überhaupt bestimmungsgemäß eingesetzt werden kann.28

Die FSF – die Urheber und Herausgeber der LGPL – hat sich zu diesen Äußerungen klar positioniert und widerlegt, dass die LGPL für Java nicht kompatibel sei. Laut der FSF ist die LGPL mit allen bekannten Programmiersprachen anwendbar.

Die Struktur von Java sieht vor, dass eine von einer Anwendung benötigte Bibliothek (die dann z.B. unter der LGPL lizenziert ist) als separate JAR-Datei vorliegt. Die Anwendung nutzt dann eine sog. Import-Funktion, um auf die Bibliothek zuzugreifen. Beim Kompilieren der Anwendung werden daher Funktionssignaturen gegen die Bibliothek überprüft und so eine Verknüpfung hergestellt. Die Bibliothek bleibt dabei aber grundsätzlich ein eigenständiger Bestandteil, auf dessen Funktionen zugegriffen wird, der aber nicht komplett in den Code der Anwendung übernommen wird.

Die Bibliothek erfüllt daher grundsätzlich alle Anforderungen, die die LGPL an eine dynamische Verlinkung stellt, da weiterhin gewährleistet bleibt, dass ein Nutzer die Bibliothek verändern oder austauschen kann.29

22 Indiana University, About linkers and dynamic and static linking, https://kb.iu.edu/d/akqn. 23 Indiana University, About linkers and dynamic and static linking, https://kb.iu.edu/d/akqn. 24 https://de.wikipedia.org/wiki/Programmiersprache. 25 https://de.wikipedia.org/wiki/C_(Programmiersprache). 26 https://wiki.python.org/moin/BeginnersGuide/Overview; http://openbookproject.net/thinkcs/python/english3e/way_of_the_program.html. 27 Ullenboom, http://openbook.rheinwerk-verlag.de/javainsel, Kap. 1.2. 28 https://developers.slashdot.org/story/03/07/17/2257224/lgpl-is-viral-for-java. 29 Turner, https://www.gnu.org/licenses/lgpl-java.en.html.

4. Diese Befehlsstrukturen müssen Juristen erst recht verstehen

116

 – Bei anderen Arten von Befehlsstrukturen zur Interaktion von Software ist im Hinblick auf das Auslösen eines Copyleft immer eine genaue Betrachtung erforderlich, inwieweit die Programmteile dabei selbstständig und getrennt voneinander funktionsfähig bleiben.

 – Selbst für sog. System Calls oder Systemaufrufe macht es daher Sinn zu unterschieden, ob mit diesen ein selbstständiges anderes Programm oder lediglich ein unselbstständiger Programmteil wie eine Bibliothek aufgerufen wird.

117

Neben den gerade beschriebenen Arten der Verlinkung gibt es auch noch andere Mechanismen und Befehlsstrukturen, die dafür sorgen, dass unterschiedliche Software-Bestandteile miteinander interagieren. Da einige von diesen Mechanismen sich ebenfalls auf die lizenzrechtliche Bewertung einer FOSS Komponente auswirken können, wollen wir auch hierzu einen kurzen Überblick geben, welche weiteren Arten der Interaktion bzw. Verbindung es hier gibt und wie sich diese ggf. auf eine rechtliche Bewertung auswirken können.

a) System Call

118

Ein Mechanismus, der im Zusammenhang mit FOSS häufig auftaucht, ist der System Call. Ein System Call oder auch Systemaufruf beschreibt eine Methode, die von Anwendungsprogrammen genutzt wird, um mit dem Systemkern zu kommunizieren und so die vom Betriebssystem bereitgestellten Funktionen auszuführen, wie z.B. das Lesen einer Datei. Die System Calls stellen also die Kommunikation zwischen Anwendungsprozess und Betriebssystem her. Bekannt ist der Begriff hauptsächlich aus dem Linux Umfeld, aber auch bei anderen Betriebssystemen wie Unix oder Windows funktioniert die Kommunikation zwischen Anwendungsprogramm und Kernel auf eine ähnliche Weise.30

Abbildung 2: Kernel Architektur und System Call© Jun Rechtsanwälte (CC BY-SA 4.0)

119

Allerdings wird der Begriff des System Call nicht ausschließlich für die Kommunikation zwischen Anwendungsprogrammen und Kernel verwendet. Häufig dient der Begriff auch dazu, das Zusammenspiel zweier unabhängiger Anwendungsprogramme zu beschreiben. Ein System Call kann also auch einen Fall beschreiben, bei dem ein separat auf dem System bereitgestelltes, unabhängiges Executable (also ein selbstständiges Programm) durch eine andere unabhängige Anwendungssoftware aufgerufen und ausgeführt wird.

120

Da der Begriff des System Call also nicht nur einen konkreten Fall abbildet, ist es sinnvoll, hier die unterschiedlichen Arten von System Calls voneinander abzugrenzen und sich ggf. eigene geeignete Begriffe zu schaffen, um bestimmte Arten von System Calls eindeutig bezeichnen zu können. Insbesondere da die unterschiedlichen Arten von System Calls im Rahmen eines FOSS Compliance-Prozesses durchaus zu einer unterschiedlichen Bewertung führen können. Insbesondere dann, wenn es darum geht, zu bewerten, ob möglicherweise ein Copyleft ausgelöst wird. Für dieses Buch unterschieden wir daher grundsätzlich nach zwei Arten von System Calls, die im Folgenden näher beschrieben werden.

b) System Call zum Aufruf unselbstständiger System- oder Programmfunktionen

121

Ein System Call zum Aufruf einer unselbstständigen System- oder Programmfunktion beschreibt den Umstand, dass eine separat auf dem System bereitgestellte Funktionalität (z.B. in Form einer Library) durch eine Anwendungssoftware aufgerufen und ausgeführt wird. Der proprietäre Programmcode ruft also beispielsweise die Funktionalität einer ebenfalls auf dem System befindlichen FOSS Komponente auf und integriert diese in den eigenen Ablauf. Ein gutes Beispiel für eine solche Art des System Call sind beispielsweise die System Calls bei Linux, auch Linux SysCalls genannt.31

122

Vergleicht man diese Art des System Call mit der weiter oben (Rn. 107f.) bereits beschriebenen dynamischen Verlinkung, so wirken diese beiden Arten der Interaktion von Software-Komponenten fast identisch. Bei einem solchen System Call ist es daher grundsätzlich möglich, dass durch seine Verwendung der Copyleft Effekt strenger FOSS Lizenzen ausgelöst werden kann. Da in diesem Fall die aufgerufene Komponente kein eigenständiges Executable darstellt, sondern es sich lediglich um einen unselbstständigen Programmteil bzw. einen Teil des Systemkerns handelt, kann ein derivative work im Sinne der FOSS Lizenzen entstehen. In diesen Fällen muss daher verstärkt auf die konkreten Vorgaben der jeweiligen FOSS Lizenzen sowie die technische Umsetzung des System Call geachtet werden. Gerade für Programmen, die auf einem Linux Betriebssystem laufen und daher entsprechende System Calls zum Kernel benötigen, um die dort bereitgestellten Funktionen nutzen zu können, ist das Problem bereits bekannt und wurde hier durch die Linux-syscall-exception-to-GPL gelöst. Diese stellt eine Ausnahme dar, nach der bei entsprechender Einbindung der Libraries in andere Anwendungsprogramme als System Calls über UAPI gerade kein derivatve work entsteht.

123

Backup: Linux-syscall-exception-to-GPL und Linux-syscall-note

Der Linux kernel steht grundsätzlich unter der GPL-2.0, sog. Syscall Note, enthält aber eine Ausnahme, die eine weitere Ausbreitung der GPL-2.0 auf verbundenen Code verhindert:

„Usage-Guide: This exception is used together with one of the above SPDX-Licenses to mark user space API (uapi) header files so they can be included into non GPL compliant user space application code. To use this exception add it with the keyword WITH to one of the identifiers in the SPDX-Licenses tag: <SPDX-License> WITH Linuxsyscall-note

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall under the heading of ‚derived work‘. Also note that the GPL below is copyrighted by the Free Software Foundation, 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.

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

b) Wie Vertragsgrundlagen bei Ansprüchen helfen können

155

Für eine Beurteilung des Vertrages stellt sich die Frage, wie die einbezogenen FOSS Lizenzbedingungen vertragstypologisch einzuordnen sind. Es gibt keinen eigenen Vertragstyp für urheberrechtliche Lizenzverträge, die Einordnung erfolgt nach den bekannten Vertragstypen des BGB. Der Lizenzvertrag – egal wie knapp er gehalten ist – ist im deutschen Urheberrecht die Grundlage für die Bestimmung, welche Nutzungsrechte eingeräumt wurden. Ist eine Nutzungsart nicht genannt, muss nach der Zweckübertragungslehre geprüft werden, ob sie umfasst ist. Gutgläubig können Nutzungsrechte nicht erworben werden. Das ist in der Praxis z.B. dann wichtig, wenn die FOSS Lizenz keine Aussagen zu einer Modifikation der Software macht. Im Zweifel ist es dann nicht erlaubt, die Software zu verändern. Derjenige, der Software kostenlos bereitstellt, räumt somit nur die Rechte ein, die er mit seiner FOSS Lizenz einräumen möchte. Zudem kann er sich, insbesondere wenn er nur Contributions bereitstellt, auf Haftungsprivilegien aus Schenkungsrecht berufen.

aa) Lizenzvertrag mit schenkungsvertragsrechtlichen Elementen

156

Nach ganz h.M. handelt es sich bei der Einräumung von FOSS Lizenzen um einen Lizenzvertrag mit schenkungsvertragsrechtlichen Elementen.28 Die Rechtseinräumung bzgl. der FOSS erfolgt unentgeltlich als vermögensmindernde Zuwendung des Lizenzgebers, durch die er den Erwerber bereichert.

157

Ein wichtiges Thema ist die Haftung. Haftungsausschlüsse in AGB sind regelmäßig nach AGB-Kontrolle im deutschen Recht unwirksam (siehe Rn. 149). Daher gelten die gesetzlichen Regelungen, sofern nicht anderweitig vertraglich die Haftung geregelt wurde. Bei Anwendung der schenkungsvertragsrechtlichen Regelungen kommt meist direkt in den Sinn, dass sich derjenige, der schenkt, auf die Haftungsprivilegierung des § 521 BGB berufen kann.29 Danach hat der Schenker nur Vorsatz und grobe Fahrlässigkeit zu vertreten. Nach der Rechtsprechung gilt der gemilderte Haftungsmaßstab des § 521 BGB nicht nur für die Verletzung von Leistungspflichten, sondern auch für die Verletzung von Schutzpflichten (insbesondere Aufklärungs- und Hinweispflichten), soweit diese in einem Zusammenhang zu dem Schenkungsgegenstand stehen.30 Verletzt der Schenker somit leicht fahrlässig eine Aufklärungspflicht in Bezug auf die von ihm überlassene FOSS, haftet er dem Empfänger nicht für den daraus resultierenden Schaden.

158

Für Mangelschäden, also Schäden an der Software selbst, verdrängen die Sondervorschriften der §§ 523, 524 BGB jedoch § 521 BGB.31 Demnach haftet der Schenker nur für arglistig verschwiegene Mängel. Das Vorstehende gilt jedoch nicht ohne weiteres für Mangelfolgeschäden.32 Diese betreffen mittelbare, indirekte Vermögensfolgeschäden, denkbar an anderen Rechten und Rechtsgütern oder als Haftung gegenüber Dritten (Haftungsschäden).33 Für Mangelfolgeschäden ist seit der Schuldrechtsreform noch nicht höchstrichterlich geklärt, ob

 – die Spezialparagraphen auch in diesem Fall § 521 BGB verdrängen und somit nur für Arglist eine Haftung bestünde;34

 – oder § 521 BGB direkt gelten soll, was für Mangelfolgeschäden eine erweiterte Haftung auf grobe Fahrlässigkeit bedeuten würde;

 – oder §§ 280, 276, 241 Abs. 2 BGB gelten sollen, über die sogar eine Haftung für leichte Fahrlässigkeit bestünde. Ein Empfänger von FOSS sollte somit im Zweifel mit der letzten Linie argumentieren.

Abbildung 3: Haftungsfragen bei Schenkung© Jun Rechtsanwälte (CC BY-SA 4.0)

159

Für den Lizenzgeber oder Bereitsteller von Contributions mögen die vorstehend geschilderten Privilegierungen aus schenkungsrechtlichen Regelungen vorteilhaft sein, für den Empfänger der FOSS dagegen ist das ein Nachteil. Dieser muss im Zweifel mit der bisher nicht sicher entschiedenen Linie argumentieren, dass für Mangelfolgeschäden keine Privilegierungen gelten. Der Empfänger von FOSS sollte daher im Rahmen der Vertragsgestaltung mit einer FOSS Klausel den von ihm gewünschten Haftungsmaßstab regeln und dem Lieferanten konkrete Vorgaben zur Einhaltung der FOSS Lizenzbedingungen machen (zur Kautelargestaltung von FOSS Klauseln siehe Anhang Rn. 825ff.).

bb) Vertragsabschluss

160

Wir wollen hier auf die einzelnen Konstellationen von möglichen Vertragsbeziehungen zwischen Rechtsinhabern und Lizenznehmern, die bloß nutzen oder weiterentwickeln oder sogar weitergeben, nicht im Detail eingehen.35 Entscheidend ist grundlegend das Verhältnis desjenigen, der FOSS empfängt und weitergibt, zu dem Rechtsinhaber einerseits und zu einem möglichen Abnehmer (Zweitempfänger) andererseits.

Abbildung 4: Rechtsbeziehungen beim Vertrieb von FOSS© Jun Rechtsanwälte (CC BY-SA 4.0)

161

Jeder jeweilige Empfänger von FOSS steht zu dem Rechtsinhaber in einem Rechtsverhältnis,36 bei dem es sich um einen Lizenzvertrag mit schenkungsrechtlichem Charakter handelt. Vertragspartner des Empfängers werden die jeweiligen Rechtsinhaber der FOSS Komponente, und zwar entweder Miturheber oder die jeweiligen sukzessiven Urheber.37 Das bedeutet, das jeder Empfänger eine eigene Lizenz von dem/den Rechtsinhaber/n erhält und auf dieser Grundlage die FOSS nutzen kann, selbst wenn derjenige, der sie ihm überlassen hat, eine Rechtverletzung begangen hat, die dessen Nutzungsrecht ggf. sogar hat entfallen lassen. Der Empfänger von FOSS, die nicht lizenzgerecht vertrieben wurde, kann somit erst selbst in Anspruch genommen werden, wenn er die FOSS seinerseits weitergibt, ohne die Lizenzverletzung abzustellen.

162

Hat der Empfänger von FOSS einen eigenen Anspruch auf Herstellung eines lizenzgerechten Zustands?

Erhält jemand FOSS nicht lizenzgerecht, also beispielsweise ohne dass die entsprechend den Lizenzen notwendigen Copyright- und Lizenzvermerke beigefügt sind, so kann er selbst zwar die Software entsprechend der FOSS Lizenz nutzen. Er begeht jedoch selbst wiederum eine Rechtsverletzung, wenn er die FOSS seinerseits weitergibt und ebenfalls die erforderlichen Angaben nicht beifügt. Gerade wenn der Empfänger die FOSS jedoch im Binärcode erhalten hat, kann er die Copyright- und Lizenzvermerke in der Regel gar nicht selbst vollständig ermitteln und so die Rechtsverletzung nicht vermeiden.

Hat er jedoch keine vertraglichen Regelungen mit dem Bereitsteller der FOSS vereinbart oder sehen diese keine Regelung in Bezug auf die Einhaltung der FOSS Lizenzbedingungen oder die Bereitstellung der Copyright- und Lizenzvermerke vor, besteht zunächst ein Problem. Denn über die FOSS Lizenz, die entsprechende Bereitstellungsvorgaben macht, hat er kein direktes Rechtsverhältnis zu demjenigen, der ihm die FOSS bereitgestellt hat, außer dieser wäre gleichzeitig Rechtsinhaber. Er hat jedoch trotzdem ein eigenes Forderungsrecht aus den Lizenzen.

FOSS Lizenzbedingungen sehen gerade für den Fall der Weitergabe meist vor, dass die Copyright- und Lizenzvermerke weitergegeben werden. Sie verpflichten damit denjenigen, der FOSS weitergibt, zugunsten des jeweiligen Empfängers die entsprechenden Pflichtangaben weiterzugeben. Diese Verpflichtung (gleich ob sie als nachhängende Pflicht38 verstanden wird oder als konditional oder kausal zur Überlassung der FOSS verknüpfte Pflicht) kann nicht anders verstanden werden als eine Begründung der Rechte des jeweiligen Empfängers von FOSS.39 Will man diese auflösend bedingte Rechtseinräumung nicht als Begründung eines Forderungsrechts verstehen, muss der Rechtsgedanke des echten Vertrags zugunsten Dritter nach § 328 Abs. 1, Abs. 2 BGB herangezogen werden, um dem Empfänger ein eigenes Forderungsrecht zu gewähren.40 Nur ein solches Verständnis wird Sinn und Zweck der FOSS gerecht.41 Dies scheint jedoch, soweit ersichtlich, bisher nur in Frankreich gerichtlich anerkannt zu sein (siehe Rn. 45).

163

Zu der FOSS Lizenz können im Verhältnis eines Zulieferers zu einem Hersteller kaufvertragsrechtliche Elemente treten (insbesondere, wenn neben der FOSS zugleich proprietäre Software vertrieben wird). Die Rechtseinräumung bzgl. der FOSS erfolgt aber unentgeltlich. Die jeweiligen Rechtsverhältnisse sind im Hinblick auf die typologische Einordnung und die Geltung der unterschiedlichen Vertragsbedingungen sorgfältig zu unterscheiden. Die Ausführungen hier gehen von einer Rechtseinräumung zeitgleich mit der Überlassung der FOSS aus.42

cc) Schriftform

164

Für die Schaffung und Übertragung von Nutzungsrechten gilt der Grundsatz der Formfreiheit, eine Schriftform ist nicht erforderlich.43 Das OLG Frankfurt a.M.44 geht mit einer weit verbreiteten Auffassung davon aus, dass Nutzungsrechte nicht nur formlos, sondern insbesondere auch stillschweigend eingeräumt werden können. Bestehende Ausnahmen vom Grundsatz der Formfreiheit erscheinen im vorliegenden Kontext größtenteils nicht relevant. Einerseits müssten unbekannte Nutzungsarten betroffen sein, § 31a Abs. 1 Satz 1 UrhG, oder aber eine Rechtseinräumung an künftigen noch nicht bestimmten Werken, § 40 Abs. 1 UrhG. Weitere Möglichkeiten stellen rechtsgeschäftliche Vereinbarungen zwischen den Beteiligten dar.

165

Hier kann allenfalls zum Tragen kommen, dass viele FOSS Lizenzen bereits seit den 1990er Jahren bestehen und aktuelle technische Möglichkeiten besonders im Zusammenhang mit der Verbreitung der Cloud-Nutzung sich demgegenüber tatsächlich als damals noch unbekannte Nutzungsarten darstellen könnten.45 Andererseits ist es jedoch so, dass es sich dabei im Wesentlichen um Server Client Anwendungen handelt, die bereits mit der ersten Nutzung von Computern und Internet bekannt waren und nur in einen anderen technischen Rahmen übertragen wurden. Durch diese Übertragung wurden auch keine neuen Absatzmärkte kommerzialisiert,46 da im Wesentlichen Software, die zuvor über einen Kauf erworben wurde, nunmehr alternativ über Miete genutzt werden kann.47

1 Jaeger/Metzger, Open Source Software, Rn. 247, demzufolge die durch freie Lizenzen eingeräumten Nutzungsrechte dem Erwerber gerade in erster Linie die Weiterentwicklung und den Vertrieb der FOSS ermöglichen sollen, anders als dies bei den sonst üblichen EULA der Fall ist. Zu Recht weisen Jaeger/Metzger, Open Source Software, Rn. 246, darauf hin, dass in allen Fällen, in denen die Software zur bloßen Benutzung erworben wird, keine vertragliche Einräumung von Nutzungsrechten erforderlich ist. 2 Jaeger/Metzger, Open Source Software, Rn. 255. 3 Mantz, in: Kilian/Heussen, Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn. 41, auch Rn. 39. 4 Das mag bei der (Mit-)Überlassung von eigener, proprietärer Software, soweit diese von der FOSS getrennt werden kann und nicht infiziert ist, durchaus anders sein. 5 Lapp/Salamon, in: jurisPK-BGB, § 305 Rn. 17. 6 Schöttle, DSRITB 2020, 833, 835; Galetzka/Hackel, MMR 2019, 452, 457f.; Czychowski, GRUR-RR 2018, 1; Mantz, GRUR Int. 2008, 20, 21; Strobel, MMR 2003, 778, 780; Mantz, in: Kilian/Heussen, Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn. 41, 39; Metzger/Jaeger, GRUR Int. 1999, 839, 846; Sujecki, JurPC Web-Dok 145/2005, Abs. 10 m.w.N. 7 OLG Köln, 31.10.2014 – I 6 U 60/14, K&R 2015, 57, Rn. 69; LG München I, 19.5.2004 – 21 O 6123/04, MMR 2004, 693; LG Frankfurt a.M., 6.9.2006 – 2-6 O 224/06, CR 2006, 729; nicht problematisiert von LG Köln, 20.10.2017 – 14 O 188/17, GRUR-RR 2018, 11, ab Rn. 80. 8 Allgemein für Lizenzverträge Lettl, Urheberrecht, § 5 Rn. 13; Grützmacher, in: Wandtke/Bullinger, UrhG, § 69c Rn. 75. 9 Mantz, in: Kilian/Heussen, Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn. 9. 10 BGH, 3.11.2004 – VIII ZR 375/03, NJW 2005, 53, 54. 11 LG Frankfurt a.M., 6.9.2006 – 2-6 O 224/06, CR 2006, 729, 731; Metzger/Jaeger, GRUR Int. 1999, 839, 843; Mantz, in: Kilian/Heussen, Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn. 9. 12 Siehe LG Frankfurt a.M., 6.9.2006 – 2-6 O 224/06, CR 2006, 729, 731; kritisch, aber dies zumindest für möglich haltend Grützmacher, in: Wandtke/Bullinger/, UrhG, § 69c Rn. 110. 13 LG Frankfurt a.M., 6.9.2006 – 2-6 O 224/06, CR 2006, 729, 731; ebenso LG München I, 19.5.2004 – 21 O 6123/04, MMR 2004, 693, 694. Nach dem BGH soll es für eine wirksame Einbeziehung nicht ausreichen, wenn die entsprechenden AGB branchenüblich sind, aber eine Einbeziehungsvereinbarung fehlt, BGH, 15.1.2014 – VIII ZR 111/13, NJW 2014, 1296. 14 Spindler, in: Schricker/Loewenheim, UrhG, Vor §§ 69a ff. Rn. 29. 15 Jaeger/Metzger, Open Source Software, Rn. 254, m.w.N. in Fn. 995; Mantz, in: Kilian/Heussen, Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn. 42; Spindler, in: Schricker/Loewenheim, UrhG, Vor §§ 69a ff. Rn. 30. 16 Fälle aus der Rechtsprechung betrafen, soweit ersichtlich, stets Sachverhalte, bei denen Programmierer im Rahmen kommerzieller Weiterentwicklung und Weiterverbreitung tätig geworden sind. OLG Köln, 30.9.2016 – 6 U 18/16, GRUR-RR 2017, 138 (markenrechtliche Entscheidung mit dem Bezugspunkt zur GPL-2.0) dürfte eine absolute Ausnahme darstellen; in Rn. 19 der Entscheidung (GRUR-RR 2017, 138, 139) stellt das OLG fest, dass der Beklagte als Student neben der kostenlosen Zurverfügungstellung seiner Software keinerlei weitergehende geschäftliche Tätigkeit entfaltet hatte und dass keinerlei Bezug zu einer geschäftlichen Tätigkeit erkennbar war. 17 https://www.derstandard.at/story/2000101285309/programmieren-ist-fuer-jeden-aber-nur-wenn-man-englisch-spricht. 18 Allgemeine Auffassung: Mantz, in: Kilian/Heussen, Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn. 44; Redeker, IT-Recht, Rn. 622. Darüber hinaus kommt bei der verbreiteten Formulierung, z.B. in Ziff. 11 GPL-2.0 „... soweit gesetzlich zulässig ...“ ein Verstoß gegen § 305 Abs. 2 Nr. 2 BGB in Betracht. Dann fehlt es an einer wirksamen Einbeziehung. Soweit ersichtlich, hat diese Unwirksamkeit noch kein deutsches Gericht bejaht, daher birgt diese Feststellung ein gewisses Risiko. 19 LG München I, 19.5.2004 – 21 O 6123/04, ZUM 2004, 861, 864 ab I. B. 20 Mit derselben Begründung verneint OLG Köln, 31.10.2014 – 6 U 60/14, GRUR 2015, 167, 172, unter ff), bei der CCPL eine unangemessene Benachteiligung und eine überraschende Klausel. 21 BGH, 6.4.2005 – XII ZR 132/03, NJW 2005, 2225. 22 Soweit ersichtlich, wird selten Bezug genommen auf § 307 Abs. 1 Satz 2 BGB, jedoch verbreitet eine Unwirksamkeit (teilweise pauschal) nach § 307 BGB erörtert, respektive die Wirksamkeit nach § 307 BGB in Frage gestellt, siehe Grützmacher, in: Wandtke/Bullinger, UrhG, § 69c Rn. 115. 23 Czychowski, GRUR-RR 2018, 1, 4; gegen die Annahme eines Dauerschuldverhältnisses Redeker, IT-Recht, Rn. 617; gegen eine unangemessene Benachteiligung auch Spindler, in: Schricker/Loewenheim, UrhG, Vor § 69a Rn. 31, mit Verweis auf OLG Köln, 31.10.2014 – 6 U 60/14, GRUR 2015, 167, 172, unter ff). 24 Galetzka/Hackel, MMR 2019, 452, 458, die darauf hinweisen, dass ein solcher Verstoß auch unverschuldet erfolgen kann. 25 Galetzka/Hackel, MMR 2019, 452, 458 (die auch auf § 309 Nr. 4 BGB hinweisen); Czychowski, GRUR 2018-RR, 1, 4. 26 In diesem Sinne wohl auch Czychowski, GRUR-RR 2018, 1, 4f., der auf § 309 Nr. 4 BGB im Zusammenhang mit § 307 Abs. 2 Nr. 2 BGB hinweist und die Unwirksamkeit einer Bestimmung annimmt, durch die der Verwender von der gesetzlichen Obliegenheit freigestellt wird, den anderen Vertragsteil zu mahnen oder ihm eine Frist für die Leistung zu setzen. 27 Zwar nicht für Ziff. 4 GPL-2.0, aber für die Nutzungsbedingungen der Nutzung des Spiels „World of Warcraft“ wegen fehlender Interessenabwägung und unter Berufung auf das Fristsetzungserfordernis eine Unangemessenheit dieser Bedingungen bejahend LG Berlin, 28.1.2014 – 15 O 300/12, BeckRS 2014, 5045, unter II. 2. a) a.E. und b). Siehe auch Galetzka/Hackel, MMR 2019, 452, 458; Czychowski, GRUR-RR 2018, 1, 4. 28 Jaeger/Metzger, Open Source Software, Rn. 291. 29 Vgl. nur Jaeger/Metzger, Open Source Software, Rn. 300, 310. 30 BGH, 20.11.1984 – IVa ZR 104/83, BGHZ 93, 23; OLG Saarbrücken, 28.8.2013 – 1 U 97/12, NJW-RR 2014, 139. Ein Teil der Lehre lehnt dieses Verständnis des § 521 BGB ab und will § 521 BGB nur auf die Verletzung von Leistungspflichten anzuwenden, siehe Mansel, in: Jauernig, BGB, § 521 Rn. 1. 31 Koch, in: Müko-BGB, § 521 Rn. 2, 7. 32 Vgl. dazu die Entscheidung des BGH, 20.11.1984 – IV a ZR 104/83, BGHZ 93, 23 (nur §§ 523, 524 BGB), allerdings vor der Schuldrechtsreform und seitdem nicht bestätigt, einerseits und Kühle, in: jurisPK-BGB, § 521 BGB (Stand: 1.2.2020), Rn. 25f. (Haftung nach den allgemeinen Vorschriften), andererseits. 33 Das wird ein häufiger Anwendungsfall sein. 34 Vgl. Kühle, in: jurisPK-BGB, § 521 BGB Rn. 1–8. 35 Weiterführend hierzu Jaeger/Metzger, Open Source Software, Rn. 276–356, die acht denkbare, unterschiedliche Vertragskonstellationen aufzeigen. 36 Galetzka/Hackel, MMR 2019, 452, 457 („sternförmiger Erwerb vom jeweiligen Urheber“). 37 Spindler, in: Schricker/Loewenheim, UrhG, Vor §§ 69a ff. Rn. 29, mit der Unterscheidung nach horizontaler und vertikaler Entwicklung. 38 So Metzger/Jaeger, GRUR Int. 1999, 839, 847; Jaeger/Metzger, Open Source Software, Rn. 289. 39 Vgl. hierzu nur den Wortlaut des § 328 Abs. 1, Abs. 2 BGB. 40 Jaeger/Metzger, Open Source Software, Rn. 42. 41 Dies ist vergleichbar dem Traufhöhennachbarschaftsfall des BGH, 29.11.1974 – V ZR 73/73, NJW 1975, 344. Wie in der dort herangezogenen Argumentation muss, damit die FOSS entsprechend weitergegeben werden kann, jeder Empfänger der FOSS zugleich berechtigt sein, die entsprechenden Pflichtangaben von demjenigen einzufordern, der die FOSS weitergibt oder zur Verfügung stellt. 42 Zum möglichen Auseinanderfallen der unterschiedlichen Zeitpunkte und hieraus resultierenden Konsequenzen siehe Jaeger/Metzger, Open Source Software, Rn. 276–356. 43 Paul, in: Hoeren/Sieber/Holznagel, Hdb. MultimediaR, Teil 7.4 Rn. 75. 44 OLG Frankfurt a.M., 15.8.2014 – 11 W 5/14, GRUR 2015, 374; Schulze, in: Dreier/Schulze, UrhG, § 31 Rn. 22; Ohly, in: Schricker/Loewenheim, UrhG, Vor § 31ff. Rn. 30; BGH, 29.4.2010 – I ZR 69/08, ZUM 2010, 580, Rn. 29. 45 Eingehend dazu Schöttle, MMR 2020, 801, für ASP und SaaS, mit dem Hinweis, dass die BSD Lizenz in der Ursprungsfassung aus dem Jahr 1990 und die MIT Lizenz aus dem Jahr 1988 stammt. 46 Dietrich, ZUM 2010, 567, 572. Siehe auch BGH, 19.5.2005 – I ZR 285/02, GRUR 2005, 937 – Der Zauberberg mit übertragbarem Rechtsgedanken, dass die DVD-Verwertung gegenüber der Videokassettenvermarktung keine neue Nutzungsart darstellt. 47 Ob dies allerdings als Argument ausreicht, mag durchaus zweifelhaft sein. Auch Schöttle, MMR 2020, 801, 805, gelangt letztlich zu dem Ergebnis, dass diese Frage nicht mit einem einfachen Ja oder Nein beantwortet werden kann.

2. Was FOSS Lizenzen generell ausmacht

166

Zu den grundlegenden Prinzipien und typischen FOSS Lizenzvorgaben gehören – vereinfacht dargestellt – drei wesentliche Punkte:

 – Die Nutzung und Bearbeitung von FOSS (= interne Verwendung) sind weitgehend ohne Einhaltung von Bedingungen gestattet.

 – Die Weitergabe bzw. der Vertrieb von FOSS ist nur unter Bedingungen gestattet, z.B. bei Einhaltung von Pflichtangaben.

 – Freigabe von Source Code und Copyleft Prinzip dominieren bei Erfassung, Bewertung und Umsetzung von FOSS Lizenzvorgaben.

a) Kein Problem bei der reinen Nutzung

167

Alle FOSS Lizenzen zeichnen sich dadurch aus, dass sie die Nutzung von FOSS zur eigenen Verwendung und mit Einschränkungen auch deren Bearbeitung (ausführlich zur Veränderung/Umarbeitung/Bearbeitung siehe Rn. 192ff.) weitgehend bedingungsfrei gestatten. Die bestimmungsgemäße Benutzung i.S.d. § 69d Abs. 1 UrhG erfährt auf diese Weise eine Konkretisierung durch die Vorgaben der jeweils einschlägigen FOSS Lizenz.