© federico rostagno, 123RF

Rechtliche Auseinandersetzungen über Open-Source-Software nehmen zu. Seit Kurzem ist klar: Bei Lizenzverletzungen droht neben Unterlassungsansprüchen auch Schadensersatz. Was bedeutet das für Unternehmen, die OSS in eigene Produkte integrieren?

Erfahrungsgemäß dauert es immer eine Weile, bis sich Juristen mit technischen Entwicklungen auseinandersetzen. Häufig werden Rechtsstreitigkeiten dann zuerst in den USA ausgefochten – in die deutschen Gerichtssäle gelangen die Themen erst Jahre später.

Erstaunlicherweise lief die Entwicklung beim Thema Open-Source-Software (OSS) umgekehrt: Es war ein deutsches Gericht, das Landgericht München, das sich im Jahr 2004 erstmals mit der Wirksamkeit der GPL und den Rechtsfolgen ihrer Verletzung auseinandersetzte (LG München, Urteil vom 19.05.2004 – 21 O 6123/04, [1]). Zwar folgte im selben Jahr auch eine Entscheidung jenseits des Atlantiks, dennoch waren es in der Folgezeit immer wieder deutsche Gerichte, die von sich reden machten.

Dabei hat das vergleichsweise junge Rechtsgebiet eine rasante Entwicklung durchlaufen. Noch vor wenigen Jahren stand die Wirksamkeit der OSS-Lizenzen selbst auf dem Prüfstand. Doch inzwischen ist dieses Thema abgehakt: Die grundsätzliche Wirksamkeit der wichtigsten OSS-Lizenzen erkennen die Gerichte an.

Schadensersatz

In gerichtlichen Streitigkeiten der jüngeren Zeit ging es nicht mehr nur um das Einhalten der Lizenzpflichten selbst, sondern ums Geld, und zwar in Form von Schadensersatz. Wegweisend war eine Entscheidung des Landgerichts Bochum aus dem Jahr 2011 (LG Bochum, Urteil vom 20.01.2011 – 8 O 293/09), die erstmals in Deutschland bei OSS-Lizenzverletzungen einen Schadensersatzanspruch dem Grunde nach bejahte.

Das betroffene Unternehmen hatte versehentlich eine deaktivierte OSS-Komponente ausgeliefert, die eigentliche Software rief sie gar nicht auf. Die Entwickler der Firma hatten schlicht vergessen, Lizenztext und Sourcecode mitzuliefern. Die Parteien einigten sich auf eine Schadensersatzzahlung von 15 000 Euro.

Ein Jahr zuvor hatte bereits ein US-Gericht in dem Verfahren Busybox gegen Westinghouse (US District Court for the Southern District of New York, 09 Civ. 10155 (SAS)) einen Schadensersatzanspruch in Höhe von 90 000 Euro bejaht. Zudem verpflichtete sich das Unternehmen in diesem Verfahren, die betroffenen, noch auf Lager befindlichen Geräte – Flachbildfernseher – für wohltätige Zwecke zu spenden.

Ging es bislang im Wesentlichen nur um Unterlassungsansprüche, so haben mit der Entscheidung des Landgerichts Bochum die Auseinandersetzungen um die Einhaltung von OSS-Lizenzbedingungen einen neuen Höhepunkt erreicht. Bis dahin wurde vereinzelt noch bezweifelt, dass bei kostenlos verfügbarer OSS überhaupt ein Anspruch auf Schadensersatz möglich ist – doch auch diese Frage dürfte jetzt geklärt sein.

Abbildung 1: Versehentlich oder nicht? Das spielt auch bei Lizenzen keine Rolle, ebenso wenig, ob die Software wirklich aufgerufen wird. © Sergey Lysenkov, 123RF

Communities

Bei großen OSS-Projekten ist vor dem erfolgreichen Durchsetzen von Schadensersatzansprüchen oft noch eine besondere Hürde zu nehmen: Haben mehrere Personen eine OSS-Komponente als Miturheber gemeinsam entwickelt, kann ein Entwickler zwar Unterlassungs- und Schadensersatzansprüche allein geltend machen. Leistung kann er jedoch nur für alle Miturheber verlangen.

Im Fall von Schadensersatzansprüchen müsste er also alle Miturheber benennen – was bei vielen, von einer offenen Community entwickelten Projekten schlichtweg unmöglich ist. Das bedeutet jedoch nicht, dass bei OSS generell keinerlei Schadensersatzansprüche zu fürchten sind. Zahlreiche OSS-Komponenten, die in größeren Standardpaketen enthalten sind, haben einzelne Entwickler geschrieben. Auch ein vermeintliches Gemeinschaftswerk wie eine Linux-Distribution lässt sich oft auf Komponenten herunterbrechen, die Einzelne entwickelt haben. Und diese müssen sich mit niemandem abstimmen, wenn sie Schadensersatzansprüche geltend machen.

Drittwirkung

In den USA ist derzeit das Verfahren Versata Software gegen Ameriprise Financial Services anhängig, das aufhorchen lässt: Ein Software-Unternehmen verklagt einen Kunden unter anderem wegen unerlaubter Manipulation der vom Software-Unternehmen bezogenen Software. Der Kunde wehrt sich mit dem Argument, in der Software sei eine Drittkomponente enthalten, die unter der GPL lizenziert sei und deren Copyleft-Effekt dazu geführt habe, dass das gesamte Softwarepaket unter der GPL zu lizenzieren ist. Die gesamte Software dürfe somit auch dekompiliert und verändert werden.

Die Entscheidung zu dieser Frage steht noch aus. Sollte das Gericht der Argumentation des Kunden folgen, würde dies die Konsequenzen bei Verletzungen von OSS-Lizenzpflichten erheblich verschärfen: Zum einen könnte nicht nur der Urheber der jeweiligen Software selbst gegen eine Verletzung vorgehen, sondern auch Dritte, die an der Entwicklung der OSS-Komponente gar nicht beteiligt waren, hätten diese Möglichkeit.

Zum anderen wäre nach diesem Verständnis in Fällen, in denen der Copyleft-Effekt greift, ein Anspruch auf Modifikation und Dekompilierung der Software gegeben, ohne dass sich das betroffene Software-Unternehmen dagegen wehren könnte. Aus proprietärer Software könnte so mit einem Schlag ein Open-Source-Projekt werden – das Geschäftsmodell des betroffenen Unternehmens wäre erledigt. Es bleibt abzuwarten, ob sich das Gericht der Argumentation des Kunden anschließt.

Eines zeigt das Verfahren allerdings jetzt schon: Streitigkeiten über OSS-Lizenzen werden nicht mehr ausschließlich von Mitgliedern der OSS-Community initiiert. Freie Lizenzen dienen inzwischen auch als ein Verteidigungsmittel bei Auseinandersetzungen zwischen Unternehmen, die an der Entwicklung gar nicht beteiligt waren.

Häufige Fehler

Schiefgehen kann Vieles beim Umgang mit Drittkomponenten – auch aus rechtlicher Sicht. Schließlich gibt es Hunderte, ja Tausende verschiedener Lizenztexte, die unterschiedlichste Rechte und Pflichten mit sich bringen. Dennoch sind es in den meisten Fällen immer dieselben wenigen Fehler, die beim Umgang mit OSS-Komponenten gemacht werden.

Fehler Nummer eins: Wer nicht weiß, welche Drittkomponenten sich im eigenen Produkt verstecken, hat keine Chance, Lizenzverletzungen überhaupt zu erkennen und zu vermeiden. Da hakt es oft schon. So wird oft keine Liste der Drittkomponenten geführt, die in der eigenen Entwicklung stecken. Zwar verstecken sich die einzelnen Lizenzdateien nicht selten in irgendwelchen Unterverzeichnissen der Software, eine vollständige und abschließende Aufzählung gibt es jedoch nicht.

Das unbekannte Produkt

Doch selbst wenn solche Listen existieren, geben sie oft nicht mehr wieder als die Hauptlizenz der eingesetzten Drittkomponente. Diese Komponente ist in der Regel nur unter der Lizenz aufgeführt, die ihr Entwickler angegeben hat. Dabei ist jedoch Vorsicht geboten: Häufig geht dieser Entwickler nicht anders vor als man selbst – nämlich modular: In der Drittkomponente stecken weitere Komponenten, die ihrerseits weitere Komponenten enthalten, und so weiter.

Gelten für Teile der Software von der Hauptlizenz abweichende Pflichten, dann muss das Unternehmen auch diese selbstverständlich ebenfalls beachten. Hier hilft nur ein rekursiver Scan über den eingesetzten Code. Das klingt auf den ersten Blick mühsamer, als es ist. Mit entsprechender Software-Unterstützung lässt sich die Aufgabe in überschaubarer Zeit bewerkstelligen.

So oder so – wer Drittkomponenten einsetzt, sollte sich darüber im Klaren sein, welche Komponenten das sind und welche Pflichten daraus folgen. Das gilt übrigens nicht nur für OSS, sondern auch für proprietäre Komponenten. Nicht selten zeigt sich bei einem Softwarescan, dass in dem Produkt nicht nur OSS enthalten ist, sondern auch proprietäre, aber kostenfrei verfügbare Software, die nicht ohne Weiteres vertrieben werden darf. Ein Software-Architekt, der das Thema Lizenz-Compliance vollständig auf dem Radar hat, muss folglich alle – auch kommerzielle – Drittkomponenten mit einbeziehen.

Abbildung 2: Totalschaden: Im schlimmsten Fall hilft nur noch, ganze Teile der Software auszutauschen und von Anfang an neu zu entwickeln. © tobi, 123Rf

Lizenzpflichten

Doch reicht es natürlich nicht aus, nur zu wissen, dass OSS-Komponenten im eigenen Produkt stecken. Es müssen auch die Pflichten der jeweiligen OSS-Lizenzen erfüllt werden, die hinter den Komponenten stehen. Diese Pflichten unterscheiden sich je nach Lizenz.

Die wohl strengsten Anforderungen stellen die Lizenzen der (L)GPL-Familie. Sie verlangen unter anderem bei der Weitergabe der Software das Mitliefern des Lizenztextes sowie das Verfügbarmachen des Sourcecodes. Zwei Pflichten, die in den meisten Fällen relativ einfach zu erfüllen sind und doch immer wieder verletzt werden. Wer sie nicht ausreichend beachtet, findet sich immer wahrscheinlicher vor Gericht. Ihre Verletzung war auch der Auslöser für die eingangs genannten Schadensersatzzahlungen in fünfstelliger Höhe.

Die Copyleft-Falle

Derzeit noch selten gerügt, aber dafür umso gefährlicher ist der Copyleft-Effekt der (L)GPL: Werden (L)GPL-lizenzierte Komponenten in einer bestimmten Art und Weise mit der eigenen Software verbunden, kann ein so genanntes abgeleitetes Werk – “derivative work” – entstehen, das automatisch ebenfalls unter der (L)GPL lizenziert sein muss.

Vereinfacht gesagt heißt das: Entsteht durch die Verbindung der OSS-Komponente mit der proprietären Software ein abgeleitetes Werk, muss das Gesamtpaket, also auch die proprietäre Software, als OSS veröffentlicht werden – einschließlich Sourcecode.

Eine Firma, die eben noch proprietäre Software vertrieben hat, steht nun vor der Wahl: “Open Source gehen” oder die betroffene (L)GPL-Komponente durch eine teure proprietäre Eigenentwicklung ersetzen. Noch schwieriger wird es für jene, die beim Einsatz von OSS-Drittkomponenten keinen Einfluss auf die Lizenzmodelle haben, etwa weil sie zwei unterschiedlich lizenzierte Drittkomponenten miteinander verbinden.

Greift dann der Copyleft-Effekt, müsste die davon betroffene Komponente eigentlich unter der (L)GPL lizenziert werden – was jedoch wiederum nur mit der Zustimmung der Rechtsinhaber möglich ist. Ist ein Lizenzwechsel in der Praxis keine Alternative, bleibt meist nur der Austausch der betroffenen Komponenten.

Noch nicht gerichtlich geklärt ist zum einen, ob in den Fällen, in denen der Copyleft-Effekt greift, gleichzeitig ein Anspruch auf Herausgabe des Sourcecodes gegeben ist oder ob Geschädigte lediglich Unterlassung und Schadensersatz verlangen können. Zum anderen besteht Streit über die Frage, ob lediglich die Urheber der Software derartige Ansprüche geltend machen können oder ob auch Dritte, etwa Anwender der Software – wie die Juristen sagen – “aktivlegitimiert” sind, also klagen können. Möglicherweise wird die anstehende Entscheidung im Verfahren Versata gegen Ameriprise etwas Licht ins Dunkel bringen.

GPL und LGPL

Zu beachten ist im Übrigen, dass die Texte von GPL und LGPL, was den Copyleft-Effekt angeht, leider recht vage formuliert sind und viel Raum für Interpretationen bieten. Findet sich zum Beispiel eine Stellungnahme des betreffenden Entwicklers zu seinem Verständnis des Copyleft auf der Website des Softwareprojekts, so ist diese auf jeden Fall ebenfalls zu berücksichtigten.

Bei der Kombination von Komponenten mit einem Copyleft-Effekt sind einige Grundregeln zu beachten: So tritt nach allgemeiner Auffassung der Copyleft-Effekt dann auf, wenn (L)GPL-Softwarebibliotheken mit einem proprietären Produkt statisch verlinkt sind.

Für einen ersten Anhaltspunkt zu einzelnen Fragen der Auslegung der (L)GPL-Lizenzbedingungen – auch zur Reichweite des Copyleft-Effekts – kann sich ein Blick in die FAQ der Free Software Foundation [2] lohnen, auch wenn sich deren Meinung nicht mit derjenigen der betroffenen Entwickler oder eines Gerichts decken muss.

Nur graue Theorie?

Obwohl der Copyleft-Effekt bislang bei gerichtlichen Auseinandersetzungen nur eine untergeordnete Rolle spielt, ist er dennoch kein theoretisches Problem. Viele Software-Anbieter setzen ihn nämlich schon bewusst ein und vertreiben ihre Produkte im Wege des Dual Licensing: als Open-Source-Software unter der GPL und als proprietäre kommerzielle Software.

So setzen etwa einige Anbieter von Datenbank-Komponenten darauf, dass bei Einbindung des jeweiligen Datenbank-Konnektors in eine proprietäre Komponente der Copyleft-Effekt eine Offenlegung des Gesamtprodukts verlangt. Sie bieten für diesen Fall eine kommerzielle, kostenpflichtige Lizenz ohne einen Copyleft-Effekt an.

In der Praxis wird oft mit Klassifizierungen und Schematisierungen von OSS-Lizenzen gearbeitet, um die wichtigsten Pflichten tabellarisch zu erfassen. Das ist gut und auch sinnvoll, um schnell einen Überblick über die wesentlichen Anforderungen der einzelnen Lizenzen zu bekommen. Es darf aber nicht darüber hinwegtäuschen, dass letztlich alle Lizenzen individuelle Verträge darstellen, die lückenhaft und interpretationsbedürftig sein können. Im Ergebnis kommt es also auf jede einzelne Vertragsklausel an. Das macht die Arbeit mit OSS sicher nicht einfacher, hilft aber Überraschungen zu vermeiden.

Patente, Marken & Co.

Es gibt noch eine ganze Reihe weiterer Besonderheiten, die beim Einsatz von OSS beachtet werden wollen, so etwa patentrechtliche Konsequenzen (besonders bei der (L)GPLv3) oder marken- und namensrechtliche Ansprüche.

Angesichts der jüngsten Entwicklung verwundert es, dass sich viele Unternehmen entweder immer noch keine Gedanken zum Einsatz von OSS machen oder OSS aus Angst vor den damit verbundenen rechtlichen Risiken ablehnend gegenüberstehen – manchmal entgegen der längst etablierten Praxis im eigenen Haus. Nicht selten geschieht dies aus Unwissenheit über die eigenen Verhältnisse: Das Management meint, dem vermeintlich vorübergehenden Phänomen OSS mit einer restriktiven Politik entgegentreten zu können. Dabei nimmt es zu Unrecht an, die eigenen Softwareprodukte seien eine komplette Eigenentwicklung, während der Einsatz von Open-Source-Repositories in der Entwicklungsabteilung längst Alltag ist.

Ein vollständiges Verbot von OSS entspricht damit oft weder den Gepflogenheiten im Unternehmen selbst noch ist es in wirtschaftlicher Hinsicht durchsetzbar. Denn das würde bedeuten, weite Teile der in der eigenen Software eingesetzten Drittkomponenten durch teure proprietäre Alternativen auszutauschen oder von Grund auf neu zu entwickeln.

Abbildung 3: Das Risiko ist kontrollierbar, das aber erfordert ein Konzept. © Le Moal Olivier, 123RF

Open-Source-Compliance

“Open Source ist überall, es ist unvermeidbar. […] Eine Policy gegen freie Software ist praktisch unmöglich und bringt einen klaren Wettbewerbsnachteil.” Das stammt aus einem Report der Analysten Gartner [3]. Es hilft nichts, den Kopf in den Sand zu stecken und zu hoffen, dass trotz einer fehlenden OSS-Policy nichts passiert. Denn es sind nicht nur die Entwickler der OSS-Komponenten, die bei einer Verletzung der Lizenzbedingungen Ansprüche anmelden.

Zudem stehen einem auch die eigenen Kunden auf den Füßen, die ihre eigene OSS-Policy beim Einkauf von Software durchsetzen und sicherstellen müssen, dass alle Lizenzpflichten eingehalten werden. Spätestens beim Verkauf des Unternehmens oder Unternehmensteils schlägt die Stunde der Wahrheit.

Lange verdrängte Lizenzprobleme kommen im Rahmen einer Due Diligence ans Tageslicht. Ist die Software dann das Core-Asset des Unternehmens, scheitern derartige Transaktionen nicht selten an einer unklaren Rechtesituation bezüglich der Software. Eine Strategie zum korrekten Umgang mit OSS dient also nicht nur dem Schutz vor Klagen Dritter.

Wer OSS nutzt, muss sich also Gedanken machen, wie er damit verbundene Risiken in den Griff bekommt. Grundstein dafür sollte eine unternehmensweite OSS-Policy sein, die den Einsatz von OSS regelt und ein Minimum an organisatorischen Maßnahmen vorsieht, um Lizenzverletzungen vorzubeugen.

Der erste Schritt ist dabei eine Risiko- und Bedarfsanalyse: Mit welchen Folgen des OSS-Einsatzes kann das Unternehmen leben, welche Konsequenzen sind problematisch? Als Ergebnis dieser Analyse sollten Empfehlungen erarbeitet werden, welche Lizenzen zu vermeiden und welche bei einer Wahlmöglichkeit vorzuziehen sind.

Im nächsten Schritt sollte das Unternehmen ein System aufsetzen, das eine Prüfung der eingesetzten Drittkomponenten sicherstellt. Das Landgericht Hamburg hat dazu in einem Urteil zur GPL entschieden: Ein Unternehmen darf sich “nicht auf die Zusicherung [seiner] Lieferanten verlassen, dass die gelieferte Ware keine Rechte Dritter verletzt.” Vielmehr muss es “durch eigene Begutachtung oder unter Zuhilfenahme von sachkundigen Dritten eine Überprüfung der […] Software in geeigneter Weise durchführen oder veranlassen […], auch wenn das mit zusätzlichen Kosten verbunden ist.” (LG Hamburg, Urteil vom 14.06.2013 – 308 O 10/13)

Art und Umfang eines solchen Systems hängen von der Anzahl der eingesetzten Komponenten ab. In der Praxis reichen solche Systeme von einer einfachen, durch die Entwickler selbst gepflegten Tabelle bis hin zu detaillierten Freigabeprozessen, die von einer eigenen OSS-Compliance-Abteilung betreut und von komplexen Datenbanksystemen unterstützt werden.

Wer Lizenzen mit Copyleft-Effekt einsetzt, muss zudem ausschließen, dass die OSS die eigenen proprietären Produkte infiziert und dass unauflösbare Pflichtenkollisionen entstehen. Er muss den Entwicklern die richtigen Fragen stellen und so herausbekommen, wie die Software eingesetzt wird. Standardisierte Fragenlisten, die auf die jeweiligen Lizenzen zugeschnitten sind, können dabei helfen, den Aufwand zu minimieren.

Fazit

Die Konsequenzen, die bei einer OSS-Lizenzverletzung drohen, haben sich durch die jüngere Rechtsprechung verschärft. Durch finanzielle Anreize für die Rechtsinhaber ist das Risiko gestiegen, dass solche Lizenzverletzungen auch verfolgt werden. Ein Unternehmen, das OSS-Komponenten in eigener Software einsetzt, kommt daher nicht mehr darum herum, eine OSS-Policy aufzusetzen und OSS-Compliance in die unternehmensinternen Prozesse zu integrieren. (mfe)

Der Autor

Dr. Hendrik Schöttle ist Rechtsanwalt, Partner und Fachanwalt für IT-Recht im Münchener Büro der Wirtschaftskanzlei Osborne Clarke. Er berät schwerpunktmäßig im Bereich des IT-Rechts, unter anderem zu Rechtsfragen bei Open-Source-Software. Zu seinen Mandanten gehören international tätige Softwareunternehmen, Technologiekonzerne aber auch Elektronikhersteller.