Source: http://codeplanet.eu/tutorials/development/guides/37-open-source-lizenzen.html?tmpl=component&print=1&page=
Timestamp: 2019-09-16 00:32:55
Document Index: 299949028

Matched Legal Cases: ['§ 1', '§ 2', '§ 11', '§ 7', '§ 8', '§ 19', 'Art. 1', 'Art. 3', 'Art. 1', 'Art. 3', '§ 69', 'Art. 2', '§ 14', '§ 17', 'Art. 2', 'Art. 6', 'Art. 2', '§ 158', '§ 305', 'Art. 5']

Montag, den 10. Dezember 2007 um 14:42 Uhr
Lizenzen im Detail
Die GPL
Die LGPL
Die BSD- und MIT Lizenz
Die Mozilla Public License
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.
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.
Die GPL-Lizenz (Version 2.0)
Die GPL-Lizenz (Version 3.0)
Die LGPL-Lizenz (Version 2.1)
Die LGPL-Lizenz (Version 3.0)
Die BSD-Lizenz (3-clause)
Die MIT-Lizenz
Die MPL-Lizenz (Version 1.1)
Auflistung von Open-Source-Lizenzen
gpl-violations.org - Falls es mal jemand mit der GPL nicht zu genau nahm
Informativer Link zum Thema Lizenzierung
Artikel zum Thema GPL v3 inkl. Vergleich zwischen v2 und v3
Zuletzt aktualisiert am Montag, den 10. Dezember 2007 um 18:04 Uhr