Christian Galetzka

Praxishandbuch Open Source


Скачать книгу

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

      46

       FOSS in Java und Android

       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

      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

      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