Praxishandbuch Open Source. Christian Galetzka
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