Opensource Software – Seite 2

Landgericht Hannover mit (unbrauchbarer) Entscheidung zur GPL

Beim Landgericht Hannover (18 O 159/15, hier bei JurPC) ging es um eine unter einer GPL-Lizenz lizensierten Software, die insbesondere ohne beigefügten Lizenztext zum Download gestellt wurde. Die Entscheidung – im einstweuiligen Rechtsschutz ergangen – ist erst einmal nicht überraschend, wenn letztlich erkannt wird, dass ein Unterlassungsanspruch besteht, wenn unter Verstoss gegen die jeweiligen Lizenzbedingungen eine GPL-basierte Software zum Download gestellt wird. Überraschend ist, dass selbst im Jahre 2015 Gerichte immer noch mit absoluten Basics erhebliche Probleme haben:

Der Entscheidung ist nirgendwo zu entnehmen, ob es nun um die GPLv2 oder die GPLv3 ging. Wer sich auskennt wird zu Recht darauf verweisen, dass auf Grund der kurzen Zitate klar sein dürfte, dass es um die GPLv2 ging – gleichwohl betrachte ich es als äusserst kritisch, wenn ein Landgericht dies nicht von sich aus sauber klarstellen kann.
Richtig schwierig wird es für mich aber, wenn ich lese, dass man ersthaft mit der „auflösenden Bedingung einer allgemeinverbindlichen, auf Gesetz oder höchstrichterlicher Rechtsprechung beruhenden, eindeutigen Klärung“ Probleme hat. Es soll laut Landgericht nicht klar sein, was damit gemeint ist. Ich weiss nicht, ob das Gericht hier schlicht nicht wusste, dass der Bundesgerichtshof diese Klausel ausdrücklich mehrfach (!) in dieser Formulierung „abgesegnet hat“; oder ob man die Einzelfall-Entscheidung in der es um den EUGH ging einfach nur nicht begriffen hat: Jedenfalls ist an diesem Punkt die Entscheidung schlichtweg falsch. Dabei setze ich derartiges Grundwissen zur Formulierung von Unterlassungserklärungen als zwingend voraus, was das Landgericht hier gemacht hat ist mir nicht mehr zugänglich.

Im Ergebnis eine aus meiner Sicht vollkommen unbrauchbare Entscheidung, die wohl zu Unrecht die abgegebene Unterlassungserklärung nicht beachtet hat. Eine vollständige Analyse ist nicht möglich, da die Entscheidung den Sachverhalt unsauber aufarbeitet, sowohl hinsichtlich des Lizenztextes als auch hinsichtlich der abgegebenen Unterlassungserklärung. Sie ist als Grundlage für Analysen schlicht ungeeignet, dient aber als gutes Beispiel dafür, womit man selbst vor Landgerichten rechnen muss.

Anspruch auf Updates: IT-Sicherheit von Software & Hardware als Faktor der Produkthaftung

Gibt es einen Anspruch auf Updates: Auf Spiegel-Online ist ein bemerkenswerter Beitrag zu lesen, der sich mit der IT-Sicherheit von Herzschrittmachern beschäftigt. Dort wird angesprochen, dass die IT-Sicherheit von Herzschrittmachern auf den Prüfstand gehört, insbesondere eingebaute Software offen gelegt sein sollte und ein Zugriff von außen abgesichert sein muss.

Das Thema ist ideal geeignet, um eine zunehmende Problematik zu verdeutlichen, denn hier geht es um ein äusserst sensibles Produkt an extrem gefährlicher Stelle – und offenkundig ist nicht einmal in diesem Bereich IT-Sicherheit ein Thema. Dabei haben Unternehmen auch in juristischer Hinsicht sehr gute Gründe, sich mit der IT-Sicherheit zu beschäftigen, die in Zukunft über die Produkthaftung eine ganz enorme Rolle spielen wird.

Gesetzgebung: Entwurf eines Gesetzes zur Reform des Kaufrechts und des Bauvertragsrechts

Vorsicht, wer nur den Titel des Gesetzentwurfs liest, der begeht den schweren Fehler es als Spezialmaterie abzutun. Denn hinter dem Titel „Entwurf eines Gesetzes zur Reform des Bauvertragsrechts und zur Änderung der kaufrechtlichen Mängelhaftung“ steckt keineswegs ein kleines Reförmchen das sich im Schwerpunkt auf das Baurecht spezialisiert. Vielmehr geht es um tiefgreifende Änderungen in der Struktur des Schuldrechts BT und des Kaufrechts mit kleineren Änderungen im Werkvertragsrecht. Ein Blick vorab kann sich lohnen.

Update: Der Bundesrat hat noch Nachbesserungswünsche im April 2016 geäussert, dazu das Plenarprotokoll (S. 169) und ein Bericht bei Haufe. Insbesondere die Position von Handwerkern soll nachgebessert werden.
Gesetzgebung: Entwurf eines Gesetzes zur Reform des Kaufrechts und des Bauvertragsrechts weiterlesen

Haftung bei Open Source Software

Haftung bei Opensource Software: Freie Software ist heute Enorm verbreitet. Insbesondere im Bereich des Internet ist festzustellen, dass zahlreiche Standardprogramme und auch Standard-Protokolle in Form freier Software auftreten. Regelmäßig funktioniert dies dann so, dass hier in irgendeiner Form Programmierer beteiligt sind, die quasi ehrenamtlich an dem Projekt mitarbeiten.

Durchaus berechtigt ist dann die Frage, wie man rechtlich damit umzugehen hat, wenn plötzlich ein Fehler auftritt, der nachweislich von einem bestimmten Programmierer – oder auch verschiedenen Programmierern – stammt, speziell wenn letztendlich ein erheblicher Schaden aufgetreten ist. Gerade im Internet, wenn standardisierte Protokolle betroffen sind, ist das Risiko hier nicht klein zu reden, wenn man bedenkt wie viele kommerziell erfolgreich Plattformen bestimmte Projekte einsetzen. Hierzu ein kleiner Überblick.

Copyleft bei Opensource-Lizenz

Copyleft in Opensource-Lizenz: Die Idee des „Copyleft“ – als sprachliche Anspielung auf „Copyright“ – geht dahin, dass eine einmal frei lizenzierte Software immer einer Lizenz mit entsprechenden Lizenzbedingungen unterliegen muss. Der Grundgedanke ist zum einen, dass Software die einmal frei entwickelt wurde, nicht dem „freien Markt“ wieder entzogen werden kann. Zum anderen geht es darum, dass derjenige der einen Nutzen aus dieser Software zieht und die Software gegebenenfalls modifiziert, dies dann auch anderen zur Verfügung stellen muss.

Somit wird dann in Lizenzen mit „Copyleft“ vorgesehen, dass die Software zwar frei verwendet und modifiziert werden kann, aber die bisherige Lizenz oder eine kompatible Lizenz weiterverwendet werden muss. Wer das nicht tut, der verliert das Nutzungsrecht. Das Ergebnis ist, dass Software durch diese Lizenz „infiziert“ wird, man spricht insoweit auch von einer „viralen Lizenz“.

Abmahnung wegen GPL Verstoss in Form von Linux Firmware mit initrd und netfilter

Ich hatte das Thema in der Vergangenheit bereits mehrmals angesprochen: Wer Opensource-Software nutzen möchte, muss darauf achten die zugehörigen Lizenzbedingungen einzuhalten. Insbesondere da bei der Firmware verbreiteter Hardware gerne in irgendeiner Form auf Linux zurückgegriffen wird, muss daran gedacht werden, dass bei Auslieferung der Hardware die Bedingungen der GPL (Version 2) einzuhalten sind.

Nachdem das Landgericht Berlin bestätigt hat, dass auf Linux basierende Softwarepakete in der Gesamtheit der GPL unterliegen (siehe hier von mir dazu) zeigt sich das häufig unterschätzte Risiko in diesem Bereich.
Abmahnung wegen GPL Verstoss in Form von Linux Firmware mit initrd und netfilter weiterlesen

GNU General Public License: GPL ist mit deutschem Recht vereinbar

Es gibt zwei ältere wegweisende Entscheidungen in der deutschen Rechtsprechung, die sich mit der Wirksamkeit der GPL – damals noch mit der GPLv2 – beschäftigt haben und hier der Vollständigkeit halber erwähnt seien: Die Entscheidung des LG Berlin (16 O 134/06) aus dem Jahr 2006 und natürlich die Entscheidung des LG München I (21 O 6123/04) aus dem Jahr 2004. Kurz kann man feststellen, dass beide Entscheidungen zu dem Ergebnis kamen, dass die GPL grundsätzlich wirksam ist. Etwas ausführlicher betrachtet findet man hier, gerade beim LG München I, die wesentlichen damaligen Fragen beantwortet:

Wer seine Software der GPL unterstellt, verzichtet nicht auf sein Urheberrecht. Das Ergebnis ist, dass eine der GPL unterstellte Software auch nur im Rahmen der GPL (oder eines sonstigen eingeräumten Nutzungsrechts) genutzt werden kann – man kann nicht erklären, dass ein „Verzicht auf Urheberrechte“ vorliegt und die Software damit quasi „herrenlos“ ist.
Der „Rechterückfall“ der GPL im Fall eines Verstosses gegen die Nutzungsbedingungen der GPL ist rechtswirksam, was bedeutet, dass das Nutzungsrecht entfällt wenn man die Regeln der GPL nicht einhält. (Dazu bei uns: Wie kann ein GPL Verstoß geheilt werden?)
Bei den Regeln der GPL handelt es sich nach deutschem Recht um Allgemeine Geschäftsbedingungen, die einer Prüfung der §§305ff. BGB unterliegen. Dass die AGB dabei verbindlich nur in englischer Sprachfassung vorliegen, ist kein Problem, da „Englisch in der Computerindustrie die gängige Fachsprache ist“ (so das LG München I), wobei man sich das Hintertürchen offen lässt, wie es gegenüber Verbrauchern aussieht.
Das Prinzip des Copyleft begegnet ausdrücklich keinen Bedenken.

Wozu nichts gesagt wurde ist der umfassende Haftungsausschluss, der jedenfalls bei oberflächlicher Betrachtung mit deutschem Recht in dieser Form – jedenfalls gegenüber Verbrauchern – wohl nicht vereinbar ist (siehe dazu nur den Bundesgerichtshof, VIII ZR 174/12, hier bei uns). Rechtsprechung dazu fehlt, die Sichtweise der Literatur zum Thema, die einen Schenkungsvertrag annimmt und damit eine Einschränkung der Haftung auf Vorsatz und grobe Fahrlässigkeit überzeugt allerdings.

Opensource-Software & Copyleft: Auf Linux-Kernel basierendes Softwarepaket unterliegt als Sammelwerk der GPL

Das Landgericht Berlin (16 O 255/10) hatte sich mit einer Software (Firmware) zu beschäftigen, die in einem DSL-Router zum Einsatz kam und als Kern auf den Linux-Kernel aufsetzte. Diese Firmware wurde korrekt als Sammelwerk im Sinne des Urheberrechtsgesetzes eingestuft:

Ein Sammelwerk liegt vor, wenn die Auswahl oder Anordnung der das Sammelwerk bildenden Elemente eigenschöpferisch ist. Geschützt ist dabei auch die Kleine Münze, also diejenigen Gestaltungen, die bei einem Minimum an Gestaltungshöhe gerade noch urheberrechtsschutzfähig sind (Wandte/Bullinger, UrhR, 3. Auflage 2009, § 4 UrhG Rn. 5 m.w.N.). Nach diesem Maßstab stellt die Firmware der Klägerin ein nach § 4 Abs. 1 UrhG geschütztes Sammelwerk dar. Die Firmware besteht aus zahlreichen einzelnen Dateien […] Teil dieses Sammelwerks ist der so genannte Kernel, der auf dem Linux-Betriebssystem basiert und der als so genannte Open-Source-Software den Bedingungen der GNU General Public License (GPL), Version 2, unterliegt.

Das Landgericht stellte klar, dass die GPL zu beachten ist und hierbei insbesondere das „Copyleft-Prinzip“ wirksam ist. Das bedeutet, dass Weiterentwicklungen bzw. Modifikationen von GPL-Software weiterhin der GPL zu unterliegen haben – wenn man also einen Linux-Kernel als Basis nutzt und darauf aufbauend eine Software entwickelt (wie hier die Firmware des Routers mit sehr vielen Funktionen), unterfällt die im Ergebnis ebenfalls der GPL. Dieser Grundsatz soll auch bei Sammelwerken gelten, selbst wenn die GPL-Software nur „die Basis“ ist und alles weitere eigenständig darauf aufgesetzt ist:

Für Sammelwerke bestimmt § 2 GPL, dass Werke, die Open Source Software enthalten, als Ganzes den Bedingung der GPL unterliegen (Determann, GRUR Int 2006, 645, 648 f. m.w.N.). Hintergrund dieser Regelung ist, dass derjenigen Nutzer, der von den Vorteilen der freien Software in einem maßgeblichen Umfang profitiert, sich auch an den Bedingungen der GPL festhalten lassen muss. Die Infizierung eines Sammelwerks insgesamt bei Verwendung von Open-Source-Software in einzelnen Teilen eines Sammelwerks begegnet keinen Bedenken, da das Sammelwerk eine einheitliche Funktionalität aufweist und maßgeblich von den Open-Souce-Bestandteilen abhängt.

Das Ergebnis: Wer ein Software-Komplett-Paket erstellt, das als Sammelwerk mit GPL-Software arbeitet oder gar darauf basiert, muss das wahrscheinliche Risiko sehen, dass sein Gesamtwerk der GPL unterliegt. Das bedeutet dann zum einen die Erfüllung der Pflichten die sich aus der GPL ergeben, also speziell hinsichtlich des Angebots des Quelltextes. Aber auch dass man gegen Dritte wenig Möglichkeiten hat, sein Urheberrecht an dem selbst erstellten Teil durchzusetzen – die „Infektion“ der GPL kann sich hier durchaus als „Gift“ auswirken, gerade wenn (wie bei Linux) auf die GPLv2 abgestellt wird.

LG Bochum: Verstoss gegen LGPL ist Urheberrechtsverletzung

Das Landgericht Bochum (8 O 293/09) hat im Übrigen – wenig überraschend – bestätigt, dass eine Verletzung der Lizenzbedingungen der GNU Lesser General Public License („LGPL“) eine Urheberrechtsverletzung darstellt. Die Entscheidung selbst ist hinsichtlich der Lizenzrechtlichen Frage wenig ergiebig, da zwischen den Parteien der Lizenzverstoß unstreitig war – insofern erschöpft sich die Entscheidung darin, dass die Bedingungen der LGPL in Deutschland Bestand haben.

Es gibt also bei der Verwendung von LGPL-Software in proprietärer Software nur den allgemeinen Hinweis, zwingend die Lizenzbedingungen einzuhalten. Insbesondere ist sich vor dem immer noch verbreiteten Irrtum zu bewahren, LGPL SOftware sei „vogelfrei“ – tatsächlich gibt es auch hier zu beachtende Bedingungen, seien sie auch „weniger“ als bei der rigiden GPL.

Übrigens: Die Verwender wollten sich damit verteidigen, die enthaltene, unter der LGPL stehende Bibliothek, sei lediglich „vergessen“ worden und ohne jegliche Funktionalität. Tatsächlich kann so etwas geschehen, etwa wenn man im Entwicklungsprozess auf externe Bibliotheken setzt, diese ersetzt und schlicht vergisst, die entsprechenden Dateien zu löschen. Das Gericht hat aber gleichwohl – zu Recht – entschieden, dass dies nichts am Urheberrechtsverstoß ändert. Insofern sei daran erinnert, dass jedenfalls der Unterlassungsanspruch verschuldensunabhängig ist!

Zum Thema

OLG Düsseldorf zur kommerziellen Verwendung von GPLv2 Software

Beim OLG Düsseldorf (I-20 U 176/11) ging es um Opensource-Software, die unter der GPLv2 lizenziert war und im Rahmen einer kommerziell vertriebenen Settop-Box weiter gegeben wurde. Mit dem OLG ist es kein Problem, eine unter der GPL lizenzierte Software zu modifizieren und dann weiter unter dem markenrechtlich geschützten Namen zu vertreiben, solange klar wird, dass es sich weiterhin um eine fremde Software handelt.

Die Anpassung der Software alleine, sofern nur notwendige Details geändert werden, stellt für sich noch nicht zwingend ein Problem dar:

Die angesprochenen Verkehrskreise nehmen bei derartigen Veränderungen jedenfalls so lange eine Übereinstimmung der Programme an, wie die wesentlichen Funktionen identisch sind und insbesondere von Drittanbietern angebotene Plug-Ins, also Ergänzungen, Verwendung finden können. Gerade die auf die Benutzeroberfläche aufsetzenden Programmergänzungen begründen die angesprochene Notwendigkeit, die Software mit ihrem Namen zu bezeichnen.

An dieser Stelle, der Frage der Benutzung des Namens, liegt auch der Unterschied zur früheren Entscheidung des OLG Düsseldorf (I-20 U 41/09). Kurz festhalten kann man insofern das Fazit, dass man Opensource-Software im zu erwartenden Rahmen anpassen darf, um sie unter gleichem Namen mit eigener Hardware zu vertreiben – man darf aber keine eigene Software erstellen und dann weiter unter dem früheren Namen vertreiben.

Das ist insofern überzeugend und mit der hier vom OLG Düsseldorf vorgenommenen Wertung auch vertretbar, weil man am Ende durchaus fragen darf, was der Nutzer erwartet, wenn er den Namen der Software hört: Nämlich das eigentliche Produkt. Bekommt er es, nur mit notwendigen Änderungen versehen, wird er nicht enttäuscht. Erhält er aber was vollkommen anderes, sieht er nicht nur sich enttäuscht, sondern der eigentliche Programmierer hat auch noch ein Zuordnungsproblem bei dem von ihm geschaffenen Namen.

Erfreulich klar gestellt wurde auch, dass der Vertrieb von GPLv2 Software in kommerzieller Hardware keinen Bedenken begegnet:

Die GPLv2 verbietet lediglich, für die Nutzung des Programms ein Entgelt zu verlangen. Der Verwendung in einer Hardware, die ihrerseits nur entgeltlich vertrieben wird, steht sie gerade nicht entgegen.

Das ist (nicht nur) angesichts der Verbreitung von Android-Geräten durchaus auch eine Bemerkung wert.