Open-Source-Lizenzen

GPC

Inhalt:

1 Urheberrecht
2 Lizenzen im Detail
2.1 Die GPL
2.2 Die LGPL
2.3 Weitere Lizenzen
2.3.1 Die BSD- und MIT Lizenz
2.3.2 Die Mozilla Public License
3 Schlussbemerkung
4 Links

1 Urheberrecht

Das Lizenzrecht ist in Deutschland eng mit dem Urheberrecht verknüpft. Nach § 1 UrhG sind Computerprogramme urheberrechtlich schützbare Werke, sofern es sich um eine "persönliche geistige Schöpfung" handelt (siehe § 2 UrhG).

Das Urheberrecht dient dazu, das Veröffentlichungs- und Verwertungsrecht an einem Werk zu regeln: "Das Urheberrecht schützt den Urheber in seinen geistigen und persönlichen Beziehungen zum Werk und in der Nutzung des Werkes. Es dient zugleich der Sicherung einer angemessenen Vergütung für die Nutzung des Werkes." (§ 11 UrhG).

Laut § 7 UrhG ist der Autor der Software der Urheber. Wurde das Programm von mehreren Personen entwickelt, sind diese nach § 8 UrhG Miturheber. Urheberschaft muss man nicht extra beantragen, man erhält sie automatisch auf Lebenszeit. Anders als in den USA kann man in Deutschland das Urheberrecht auch an niemanden abtreten, sondern muss Lizenzen für sein Werk vergeben.

Durch Anwendung einer Lizenz auf ein Computerprogramm legt der Urheber fest, zu welchen Bedingungen seine Software genutzt werden darf.

2 Lizenzen im Detail

In diesem Abschnitt wird ein Überblick über bekannte Open-Source-Lizenzen und ihre rechtlichen Auswirkungen auf eine Software gegeben.

Doch zuerst soll geklärt werden, was eine Lizenz rechtlich ist, nämlich ein Vertrag. Sobald man einer Lizenz zustimmt, schließt man einen Vertrag mit dem Lizenzgeber ab. Da ein Vetrag nach deutschem Recht nicht schriftlich sein muss, ist es unerheblich, ob die Zustimmung beispielsweise per Klick auf den "Ich stimme zu"-Button entsteht.
Sobald die Lizenz akzeptiert wurde, ist sie rechtskräftig. Wer die Lizenz nicht liest, zustimmt und dann ein Problem hat, kann sich nicht herausreden. Die Lizenz gilt.

2.1 Die GPL

Die GPL wurde 1989 von der amerikanischen GNU-Organisation zum Schutz von Open-Source-Software entwickelt. Im Jahre 1991 wurde Version 2 veröffentlicht, die bis heute starke Verbreitung findet. Im Frühjahr 2007 wurde die Version 3 veröffentlicht, die u.a. neue Artikel zum Thema Softwarepatente beinhaltet. Allerdings hat sie sich noch nicht durchgesetzt, weswegen hier Version 2 besprochen wird.

Die GPL regelt das Vervielfältigungs-, Bearbeitungs- und Verbreitungsrecht.

Das Vervielfältigungsrecht stützt sich dabei auf §§ 19, 69c Nr. 1 des UrhG. Es steht dem Nutzer frei, ob er die Software als Quellcode (Art. 1 GPL) oder in Binärform (ausführbare Datei, siehe Art. 3 GPL) vervielfältigt. Für die Software selbst darf man aber keine Gebühren verlangen, jedoch für die Anfertigung der Kopien oder andere Serviceleistungen für die Software.
Des Weiteren muss bei Vervielfältigung dem Empfänger der Software der Lizenztext der GPL zugänglich gemacht werden. Ebenfalls muss der Quellcode zur Verfügung gestellt werden, wenn die Software nur in Binärform weitergegeben wird.

Grundsätzlich darf jeder den Quellcode (Art. 1 GPL), als auch die Binärform (Art. 3 GPL) einer GPL-Software bearbeiten, egal zu welchem Zweck. Auch dies stützt sich auf § 69c Nr. 2 UrhG. Die GPL sieht in Art. 2a jedoch vor, dass jegliche Änderungen deutlich gekennzeichnet und mit Datumsangaben versehen werden müssen, damit ersichtlich ist, wie der aktuelle Quellcode zustande gekommen ist.

Dem Urheber steht nach § 14 UrhG der Schutz des Urheberpersönlichkeitsrechts zu. Dies bedeutet, dass der Urheber im Ernstfall einem Dritten das Ändern der Software untersagen kann, z.B. wenn mit Absicht die Qualität der Software verschlechtert wird und somit der gute Namen des Urhebers beschädigt wird.

Die Weitergabe von GPL-Software wird durch die Paragraphen §§ 17, 69c Nr. 3 UrhG geregelt. Gibt man ein GPL-Programm weiter, so muss dies nach Art. 2b GPL weiterhin unter der GPL stehen, unabhängig davon, ob Änderungen vorgenommen wurden. Außerdem muss man dem Empfänger dieselben Rechte einräumen, die man auch selbst beim Erhalt der Software bekommen hat (Art. 6 GPL). Dies bedeutet, dass man eine GPL-Software nicht einfach "unfrei" machen kann, indem man restriktivere Regeln bzw. eine proprietäre Lizenz darauf anwendet. Dieses Prinzip nennt sich auch "Copyleft".

Sofern man in seine Software GPL-Code einbaut oder die Software von einer GPL-Software abgeleitet wurde, muss die Software laut Art. 2b GPL ebenfalls unter die GPL gestellt werden. Tut man dies nicht, ist das ein Verstoß gegen die GPL.

Ein Verstoß gegen eine Bestimmung der GPL hat immer auch ein Erlöschen der gewährten Rechte durch § 158 Abs. 2 BGB zur Folge. Dies bedeutet, man darf die Software z.B. nicht mehr verändern oder weitergeben.

Der Standardtext der GPL enthält auch einen Haftungsausschluss, der den Autor der Software vor Ansprüchen bei Mängeln und Schäden der Software schützen soll. In den USA ist so eine Passage durchaus zulässig, während sie in Deutschland unwirksam ist, da die GPL nach §§ 305 ff BGB eine Form der Allgemeinen Geschäftsbedingungen darstellt. Bei grob fahrlässiger Handlung (z.B. Weitergabe von Software mit ihm bekannten Fehlern) haftet der Programmierer dann auch.

Selbstverständlich ist es auch möglich, die GPL (oder eine andere Lizenz, die Modifikationen erlaubt) als Grundlage für eine eigene Lizenz zu benutzen und sie dann zu verändern, um diese modifizierte Version dann auf Software anzuwenden. Ein populäres Beispiel, bei dem dies der Fall ist, ist das wxWidgets-Framework, dessen Lizenz auf der LGPL basiert.

2.2 Die LGPL

Die Einschränkungen, denen GPL-Software im kommerziellen Bereich unterliegt, haben die GNU-Organisation veranlasst, im Jahre 1999 die LGPL einzuführen. Sie wurde mit Softwarebibliotheken im Hinterkopf geschaffen, ist aber auch auf Anwendungssoftware anwendbar. Inzwischen ist auch die LGPL in der Version 3 verfügbar, jedoch wird hier nur auf Version 2.1 eingegangen.

Grundsätzlich gelten für die LGPL die gleichen Regeln bzgl. Vervielfältigungs-, Bearbeitungs- und Verbreitungsrecht, die auch für die GPL gelten, abgesehen von folgendem Unterschied: Die LGPL ermöglicht es, LGPL-Software in sein Programm einzubinden, ohne jedoch das eigene Programm ebenfalls unter die LGPL stellen zu müssen, da die Software nun die GPL-Software nutzt, aber nicht davon abgeleitet ist (Art. 5 LGPL).

In der Praxis wird dies realisiert, indem die LGPL-Software per dynamischen Linken erst zur Laufzeit mit der Software verknüpft wird. Somit ist die LGPL-Software nicht Teil der Software und die Software ist auch nicht von der LGPL-Software abgeleitet.
Zusätzlich erlaubt es die LGPL-Lizenz, darunter lizenzierte Software jederzeit unter die GPL-Lizenz, also eine restriktivere, zu stellen.

Bekannte Bibliotheken, die unter der LGPL stehen, sind z.B. GTK+ und gtkmm.

2.3 Weitere Lizenzen

2.3.1 Die BSD- und MIT Lizenz

Neben den sehr populären GNU-Lizenzen existieren noch eine Reihe weiterer Lizenzen, die sich vor allem in Punkten wie Weitergabe und Verwendung in kommerziellen Programmen unterscheiden. Eine davon ist die BSD-Lizenz, die 1982 von der Berkeley Universität erstellt und im Jahr 2000 das letzte mal geändert wurde. Die BSD-Lizenz enthält nur drei Artikel und einen Haftungsausschluss, da das Ziel eine möglichst einfache und verständliche Lizenz war.

Die BSD-Lizenz räumt dem Autor der Software mehr Rechte und Freiheiten als die [L]GPL ein. So ist es z.B. möglich, BSD-Software in einer kommerziellen Software zu verwenden, ohne die kommerzielle Software unter die BSD-Lizenz stellen zu müssen. Auch ist das "Copyleft"-Prinzip nicht Teil der BSD-Lizenz.
Die einzige Restriktion ist, dass der Name der Urheber (Berkeley Universität von Kalifornien oder der Name von Softwareentwicklern) nicht zum Bewerben einer Software verwendet werden darf.

Diese Version der BSD-Lizenz ist auch als "3-Clause BSD" bekannt, da ihr die ursprüngliche vierte Klausel fehlt. Diese Klausel besagt, dass ein Hinweis auf die Berkeley Universität enthalten sein müsse:

All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors.

Allerdings war diese Klausel inkompatibel zur GPL und wurde auf Wunsch von Richard Stallman im Jahre 1999 entfernt. Nichtsdestotrotz verwendet z.B. NetBSD noch die alte "4-clause BSD"-Lizenz.

Die MIT-Lizenz ist im Jahre 1988 am Massachusets Institute of Technology (MIT) entstanden. Sie ist zur "3-clause BSD"-Lizenz gleichwertig, nur dass kein Verbot besteht mit dem Namen des Urheberrechtsinhabers für die Software zu werben. Die MIT-Lizenz wird u.a. von den Projekten Fluxbox, Ruby on Rails, Paint.NET und ncurses verwendet.

2.3.2 Die Mozilla Public License

Die MLP-Lizenz wird hauptsächlich von der Mozilla Foundation für ihre Produkte (Firefox, Thunderbird, ...) verwendet und ist sehr viel weniger verbreitet als die [L]GPL bzw. BSD-Lizenz. Entstanden ist die MPL bei Netscape Communications (Version 1.0) und wurde bei der Mozilla Corporation weiterentwickelt (Version 1.1).
Die MPL ist in Bezug auf Vervielfältigungs-, Bearbeitungs- und Verbreitungsrecht vergleichbar mit der LGPL, allerdings realisiert die MPL ein wesentlich schwächeres "Copyleft". Beispielsweise ist hier eine Vermischung von MPL- und proprietärem Code kein Problem. Die unter der MPL lizenzierte Software bleibt unter der MPL und der Code, der auf Basis oder um den MPL-Code geschrieben wurde, kann nach Belieben lizenziert werden.

3 Schlussbemerkung

Viele Unternehmen scheuen oft vor dem Einsatz von Open-Source-Software zurück, da sie Risiken (hauptsächlich im Lizenzbereich) fürchten, die so gar nicht existieren. So findet man z.B. zu den Artikeln der GPL im UrhG bzw. BGB entsprechende Paragraphen, die die Lizenzbestimmungen mittels deutschem Recht durchsetzbar machen.

Ebenso stellen Softwarepatente keine große Gefahr dar, obwohl ein Rechteinhaber untersagen kann, dass ein Open-Source-Programm sein Patent verwendet. Da Software in Deutschland aber nur begrenzt patentierbar ist, ist dieses Risiko als gering einzustufen.

Aufmerksamkeit verlangt allerdings GPL-Software, die man in seine eigene Software eingliedern möchte. Denn in diesem Fall müsste man seine eigene Software auch unter der GPL lizenzieren, was meistens ungewünscht ist.

4 Links

Artchi

Die Informationen waren schon sehr gut und nützlich! Kann sie wenigstens jeder normale Mensch verstehen.

Habe aber eine Frage, an GPC und alle anderen: wer weiß, wie es sich mit der Ms-PL und der Ms-RL verhält? Kann die jemand hier vielleicht kurz erklären oder hat URLs zu deutschen Beschreibungen? OK, english geht auch, aber dann kein Rechtsanwalt-Englisch, sondern für Dummies.

GPC

Artchi schrieb:

Habe aber eine Frage, an GPC und alle anderen: wer weiß, wie es sich mit der Ms-PL und der Ms-RL verhält?

In Bezug auf einen besonderen Aspekt oder eher so eine allgemeine Beschreibung? Habe mich bisher nämlich noch nicht damit beschäftigt. Alles was ich beim Überfliegen erkennen konnte, ist dass die Ms-RL - abgesehen von einer Bedingung mehr - identisch zur Ms-PL ist und beide Lizenzen von der OSI als Open-Source-Lizenzen anerkannt wurden.

Artchi

Ich habe versucht die MS-Lizenzen zu lesen und zu verstehen. Nur tut man sich ja schon bei deutschen Texten schwer. Ich habe z.B. nie die GPL gelesen.

Die Ms-RL z.B. erfüllt die OSI-Regeln. Die 10 Regeln kann man nachschauen, die verstehe sogar ich. D.h. was das angeht, besteht kein Aufklärungsbedarf. Aber MS hat ja die zwei Lizenzen nicht aus Jux und Dollerei entwickelt. Und genau da interessiert mich, was sie ausmachen. Z.B. macht die GPL aus, das man immer den Code wieder veröffentlichen muß. Das ist sowas prägnantes, das in den OSI-Regeln nicht drin steht. Macht aber die GPL aus... selbst wenn man nicht den gesamten GPL-Text liest.

So ungefähre Beschreibungen würden mich für die "neuen" MS-Lizenzen interessieren. Ich weiß eigentlich nicht, warum ich sie benutzen sollte, würde ich eine Lizenz für mein Projekt brauchen? Nicht weil es MS ist, sondern weil ich keine Infos dazu habe.

Ich habe zur Zeit ein Projekt unter CPL. Die CPL habe ich gewählt, weil ich eine deutsche Beschreibung eines Rechtsanwalt aus einer iX-Veranstaltung gelesen habe. Ohne diese, hätte ich die CPL nie verstanden.

Eigentlich so ähnlich wie du den Artikel geschrieben hast...

GPC

Hm, okay. Ich kann mal danach schauen, möchte aber nichts versprechen

geeky

http://blogs.sun.com/chandan/entry/copyrights_licenses_and_cddl_illustrated

*D*Evil

Hmm ... kannst du evtl. noch etwas auf die Unterschiede zwischen LGPLv2.1 und LGPLv3 eingehen? Wollte generell auf die LGPL zurückgreifen. Nur ist jetzt die Frage welche Version ratsam ist/wäre.
Vielen Dank schonmal ...

GPC

(D)Evil schrieb:

Nur ist jetzt die Frage welche Version ratsam ist/wäre.

Das hängt von deinen Anforderungen ab.