Open Source FAQ

Ich gehe davon aus, dass ich Libraries, die unter LGPL stehen, frei verwenden kann. Oder etwa nicht?

Die LGPL ist eine abgeschwächte Fassung der GPL mit einem schwächeren Copyleft. Dabei wird jedoch häufig übersehen, dass die LGPL durchaus noch zu den strengeren Lizenzbedingungen gehört und damit auch die Weitergabe von Libraries ohne Veränderung des Source Codes und mit dynamischer Verlinkung erfordern, dass Lizenztext und Source Code mitgeliefert werden.

 

Muss ich mir Gedanken machen, wenn ich Open Source Software einsetze, aber nicht weitergebe?

Die Verwedung von urheberrechtlich geschützter Software bedarf der Zustimmung durch den Rechteinhaber. Die meisten Open Source Software Bedingungen richten ihre besonderen Vorgaben an denjenigen, der das Produkt verändert oder weitergibt und gewährt den Nutzern ein kostenloses Nutzungsrecht.

Ein Risiko besteht nach unserer Auffassung dann, wenn eine vorherige Bearbeitung und Weitergabe rechtswidrig war oder wenn Bestandteile der Software nur irrtümlich als Open Source bezeichnet, in Wirklichkeit aber nicht freigegeben wurden. Häufig wird auch Freeware für Open Source Software gehalten, wobei es bei Freeware vorkommen kann, dass eine Nutzung im kommerziellen Umfeld überhaupt nicht gestattet ist, sodass die bloße Verwendung schon Lizenzbedingungen verletzen kann.

 

Muss jede Linux-Software unter Open Source gestellt werden?

Reflexartig möchte man antworten „das kann nicht sein" oder „wo kämen wir dann hin?".

Fakt ist, dass zahlreiche Software für Linux entwickelt und geschrieben wurde, die nicht unter Open Source Lizenzen steht. Trotzdem hat das Landgericht Berlin im Fall AVM gegen Cybits entschieden, dass bei der Fritzbox die Verwendung des Linux-Kernels dazu führt, dass die gesamte Firmware unter Open Source stehen müsse. Wie kann das sein?

Das LG Berlin, Urteil vom 08.11.2011, Az. 16 O 255/10 stützt sich auf Ziff. 2 der GPL v2 in der nach Berliner Auffassung von Sammelwerken die Rede sei. Das Landgericht Berlin ist der Auffassung, dass der Linux-Kernel als Sammlung aus vielen verschiedenen Softwareprogrammen ein Sammelwerk sei und dass eine Firmware ebenfalls eine Ansammlung von Software sei. Da der Linux-Kernel im anderen Sammelwerk enthalten sei, erstrecke sich der Copyleft-Effekt auf die gesamte Firmware.

Wer diese Argumentation aus den Urteilsgründen nachvollzieht, muss eigentlich schnell zu dem Ergebnis kommen, dass jede etwas aufwendigere Software ein Sammelwerk aus eigener und fremder Software darstellt. Es wäre recht lebensfremd, anzunehmen, dass Software, die von der Rechtsprechung immer liebevoll als Computerprogramm bezeichnet wird, ein einheitlicher monolithischer Block sein sollte.

Das Landgericht Berlin stellte vor allem darauf ab, dass das von AVM vertretene Produkt, der DSL-Router, eine Gesamtheit darstellt, in der das Betriebssystem Teil einer Gesamtheit ist. Daraus ließe sich folgern, dass nach Berliner Auffassung immer dann eine Gesamtinfektion vorliegt, wenn das ausgelieferte Produkt mit dem Linux-Bestandteil eine Einheit bildet. Würde man dem folgen, dürfte kein integriertes Gerät auf Linux-Basis mehr proprietäre Software enthalten. Genau diese Auffassung wird gerade von vielen Linux- und GPL-Verfechtern vertreten.

Welche Auffassung ist nun richtig?

Für uns praktische Juristen geht es nicht darum, in langen Abhandlungen und seitenlangen Meinungsstreits wissenschaftliche Erkenntnisse herzuleiten, wenn am Ende Gerichte einer anderen Auffassung folgen. Wir geben Prognosen für gerichtliche Entscheidungen und versuchen, uns dabei am Recht zu orientieren. Die Entscheidung des Landgerichts Berlin spricht stark dafür, dass Linux auf eingebetteten Geräten nicht mehr mit proprietärer Software verbunden werden darf. Auf der anderen Seite wird genau dies jedoch noch vielfach praktiziert und von der GPL auch nicht ausdrücklich untersagt. Die GPL knüpft für den Copyleft-Effekt an den Begriff derivative work an und Linus Torvalds hat mit seiner Präambel zur permission note im Linux-Kernel ausdrücklich erklärt, dass Software, die über system calls aufgerufen wird, nicht unter GPL-Lizenz stehen muss. Auf der anderen Seite hat die GPL-Lizenz den Verbreitungsweg in Ziff. 2 der Bedingungen ausdrücklich erwähnt und geht von einem Copyleft-Effekt aus, wenn eine Arbeit als Ganzes verbreitet wird.

Obwohl es gute Argumente für beide Seiten gibt, werden wir derzeit keinem Mandanten Unbedenklichkeit bescheinigen, wenn proprietäre Software auf eingebetteten Geräten unter Linux betrieben wird.

 

Reichen meine Einkaufsbedingungen nicht aus?

Die meisten Unternehmen, die wir beraten, hatten Einkaufsbedingungen in der sinngemäß die folgende Klausel enthalten war:

"Der Lieferant verschafft der XXX AG sämtliche für die Vertragsausführung erforderlichen Nutzungsrechte und garantiert die Freiheit von Rechten Dritter."

Diese Klausel war für den Einkäufer meistens sehr komfortabel (manchmal war sogar von der Übertragung ausschließlicher Nutzungsrechte die Rede) bringt bei Open Source Projekten jedoch unnötige Unsicherheiten für beide Teile - sogar für den Einkäufer.

  1. Nachteil für den Lieferanten/ Entwickler. Wer fremde Open Source Software weiterverkauft ist nicht in der Lage, seinem Kunden die Nutzungsrechte an der Software zu verschaffen, da die Lizenzen in der Regel eine Unterlizenzierung ausschließen. Schon in diesem Augenblick verspricht der Entwickler etwas, was er nicht oder nur mit immensem Aufwand erfüllen kann. Die Freiheit von Rechten Dritter ist bei Open Source Software nicht gegeben, da schließlich der ursprüngliche Rechteinhaber weiterhin berechtigt bleibt, die Nutzung seiner Software bei Verletzung der Lizenzbedingungen zu untersagen.
  2. Der Einkäufer hat mit dieser Klausel zwar im Zweifel die Möglichkeit bei Aufdeckung einer Rechtsverletzung Regress zu nehmen, er hat aber meistens keine vertraglichen Möglichkeiten, eine Rechtsverletzung (für die er ja im Außenverhältnis zunächst alleine haftet) zu kontrollieren oder abzuwenden.

 

Was kann mir passieren, wenn ich gegen Open Source Bedingungen verstoße?

Computerprogramme sind urheberrechtlich und durch Gesetz und Lizenzverträge geschützt. Die typischen Rechtsfolgen einer Verletzung sind die Ansprüche auf Beseitigung, Unterlassung, Abmahnkosten, Auskunft und Schadensersatz. Bei vorsätzlichem Handeln kommt auch eine Strafbarkeit in Betracht.

 

Wer kann die Verletzung von Open Source Bedingungen geltend machen?

Für die Geltendmachung von Ansprüchen kommen zwei Personengruppen in Frage. Zum einen die Rechteinhaber, also die Urheber oder deren Rechtsnachfolger, und zum anderen Vertragspartner aus Lizenzverträgen, wenn ein Unternehmen die Software an andere Personen weitergegeben hat.

Bei den Rechteinhabern stellt sich manchmal das Problem, dass kein einheitlicher Softwarehersteller, der sämtliche Rechte besitzt, identifiziert werden kann, weil bei Open Source in vielen Fällen Miturheberschaft einer Vielzahl von Personen vorliegt. Miturheber können auch alleine Unterlassungsansprüche geltend machen, in der Regel jedoch keine Erfüllung von Schadensersatzansprüchen alleine an sich verlangen. Bei einem Sammelwerk, wie beispielsweise einen Betriebssystem, kann eine Alleinurheberschaft an einem einzelnen Produkt durchaus gegeben sein. Manche Open Source Programme haben jedoch auch einen eindeutig identifizierbaren Rechteinhaber wie beispielsweise die C++ Library Qt von Nokia.

 

Wie sichere ich mich gegen meinen Lieferanten ab, damit dieser die Lizenzbedingungen einhält?

Bisher galt es als probates Mittel, sich vom Lieferanten der Software garantieren zu lassen, dass die Software frei von Rechten Dritter ist. Dies verschafft einem im Falle aller Fälle zumindest einen Rückgriffs- oder Freistellungsanspruch, schützt den Verwender jedoch noch nicht vor der eigenen Inanspruchnahme durch Dritte.

Wenn Sie sich Software von Dritten zuliefern lassen, sollten Sie Natur und Herkunft des Codes überprüfen. Zertifizierungen sind dabei eine Möglichkeit, Klarheit durch unabhängige Stellen zu schaffen, sofern diese auf Grundlage klarer Standards prüft. Sie sollten auf jeden Fall die konkreten Bedingungen des Open Source Einsatzes definieren. Unter der bloßen Einhaltung von Open Source Bedingungen könnte Ihr Lieferant etwas anderes verstehen als das Landgericht München I.

 

Wir verwenden Open Source seit vielen Jahren, noch nie hat jemand eine Verletzung von Vertragsbedingungen gerügt. Warum sollte das ausgerechnet jetzt anders sein?

Die Quote der verfolgten Rechtsverletzungen ist vermutlich bei Urheberrechtsverletzungen wesentlich niedriger als bei Parken mit abgelaufenen Parkschein. Wir erleben jedoch eine gesteigerte Aktivität sowohl bei den Rechteinhabern, die die Einhaltung der Lizenzbedingungen durchsetzen wollen, als auch bei großen Industriekunden, die sich zunehmend gegen Rechtsverletzungen gegenüber ihren Zulieferern absichern.

 

Woher weiß ich, welche Bedingungen ich erfüllen muss?

Die Bedingungen stehen im Lizenztext, der jedoch oft schwer verständlich und interpretationsbedürftig ist. Gelegentlich halten die Herausgeber der Software oder der Bedingungen schrittweise Erklärungen und Checklisten bereit, die manchmal über die Lizenzbedingungen hinausgehen. Wir glauben, dass Sie je nach Risikoausrichtung in Ihrem Unternehmen Leitlinien aufstellen sollten, die gerade für die interpretationsbedürftigen Grenzfälle klare Handlungsanweisungen vorsehen.


SITEMAP

  • KONTAKT

    JunIT | Kanzlei für IT- und Wirtschaftsrecht

    Salvatorstr. 21, DE-97074 Würzburg

    +49 931.6639.232

    +49 931.52235

    info@kanzlei-jun.de

    Mo-Do: 08.00 - 18.00 | Fr: 08.00 - 16.30