[X] Open-Source-Lizenzen

Ben04

Ich kenne mich mit dem deutschen Recht nicht so wirklich aus, allerdings ist das da keine Rechtsberatung?

Vielleicht könntest du noch erwähnen, dass eine ganze Reihe von Software eine GPL nutzt und ein paar Ausnahmen hinzufügen. So zum Beispiel die wxWidgets Lizenzen.

GPC

Ben04 schrieb:

Ich kenne mich mit dem deutschen Recht nicht so wirklich aus, allerdings ist das da keine Rechtsberatung?

Nein, diesen Gedanken hatte ich auch schon, kann ihn aber ausschließen, da es sich um keine Hilfe für ein konkretes Problem eines Ratsuchenden handelt (hab extra noch bei einer Rechtsanwältin nachgefragt, nur um ganz sicher zu gehen).

Vielleicht könntest du noch erwähnen, dass eine ganze Reihe von Software eine GPL nutzt und ein paar Ausnahmen hinzufügen. So zum Beispiel die wxWidgets Lizenzen.

Jo, werde ich einbauen.

Ben04

Vieleicht wäre ein Link zu http://www.opensource.org/licenses/category nicht falsch. Den Title könnte man noch auf Open-Source-Lizenz ändern da du ja an sich auf nichts anderes eingehst.

Jester

Ich finde die Schlußbemerkung auch ziemlich mehrdeutig. Man könnte fast meinen GPL-Software in nem Unternehmen zu verwenden (bzw. darauf aufzubauen) sei völlig unproblematisch. Vielleicht könntest Du zusammenfassend nochmal sagen, welche Software man problemlos verwenden kann, wenn man seine Sourcen nicht offenlegen möchte und solche Dinge.

estartu

Jester schrieb:

Ich finde die Schlußbemerkung auch ziemlich mehrdeutig. Man könnte fast meinen GPL-Software in nem Unternehmen zu verwenden (bzw. darauf aufzubauen) sei völlig unproblematisch. Vielleicht könntest Du zusammenfassend nochmal sagen, welche Software man problemlos verwenden kann, wenn man seine Sourcen nicht offenlegen möchte und solche Dinge.

Ja bitte.
Wie du evtl. schon an meiner Frage bemerkt hast, ist das verwirrend für Leute die es nicht kennen.

GPC

Gut gut. So besser?

Jester

Auf jeden Fall. Allerdings würde ich mir noch ein paar mehr Infos wünschen. Wie ist das mit LGPL-Sachen? Darf ich einfach ne LGPL Software nehmen, modifizieren, erweitern etc. und dann verkaufen ohne die Sourcen herzugeben? Kann ich GPL-Software als externes Modul verwenden ohne Sourcen offenlegen zu müssen? Beispielsweise MySQL-Datenbank, die nur über eine Schnittstelle mit meinem Programm kommuniziert? Vielleicht könnte man da auch sone Art Tabelle machen: Spalten: Open Source Closed Source und mehrere Zeilen: baut auf (L)GPL-Software auf, verwendet (L)GPL-Software als externes Modul etc.

Ein Beispiel für das was Unternehmen bei GPL-Software fürchten, was aber tatsächlich kein Problem ist wäre auch noch nett.

estartu

Jester schrieb:

Auf jeden Fall. Allerdings würde ich mir noch ein paar mehr Infos wünschen. Wie ist das mit LGPL-Sachen? Darf ich einfach ne LGPL Software nehmen, modifizieren, erweitern etc. und dann verkaufen ohne die Sourcen herzugeben? Kann ich GPL-Software als externes Modul verwenden ohne Sourcen offenlegen zu müssen? Beispielsweise MySQL-Datenbank, die nur über eine Schnittstelle mit meinem Programm kommuniziert? Vielleicht könnte man da auch sone Art Tabelle machen: Spalten: Open Source Closed Source und mehrere Zeilen: baut auf (L)GPL-Software auf, verwendet (L)GPL-Software als externes Modul etc.

Ein Beispiel für das was Unternehmen bei GPL-Software fürchten, was aber tatsächlich kein Problem ist wäre auch noch nett.

GPC

Jester schrieb:

Auf jeden Fall. Allerdings würde ich mir noch ein paar mehr Infos wünschen. Wie ist das mit LGPL-Sachen? Darf ich einfach ne LGPL Software nehmen, modifizieren, erweitern etc. und dann verkaufen ohne die Sourcen herzugeben?

Naa, du baust ja auf der LGPL-Software auf und "benutzt" die LGPL-Software nicht einfach nur in deinem Programm.

Kann ich GPL-Software als externes Modul verwenden ohne Sourcen offenlegen zu müssen? Beispielsweise MySQL-Datenbank, die nur über eine Schnittstelle mit meinem Programm kommuniziert?

Nein. Die Software beinhaltet keine Teile oder das Ganze von GPL-Software und ist auch nicht davon abgeleitet.

Vielleicht könnte man da auch sone Art Tabelle machen: Spalten: Open Source Closed Source und mehrere Zeilen: baut auf (L)GPL-Software auf, verwendet (L)GPL-Software als externes Modul etc.

Sorry, ist zeitlich nicht drin. Es stehen grad' Klausuren, Präsis, Assi-Prüfung und noch mehr an. Wenn das rein muss, dann müssen wir den Artikel verschieben.

Ein Beispiel für das was Unternehmen bei GPL-Software fürchten, was aber tatsächlich kein Problem ist wäre auch noch nett.

Ich kann nur die Beispiele aus unserer Firma bringen, daher der Aufruf an die anderen: Postet eure Erfahrungen.

estartu

Ganz ehrlich? Lieber nen vollständigen Artikel später raus als einen der im Vorfeld bekannte Fragen offen lässt pünktlich.
Wenn wir nen unvollständigen nehmen wollen, können wir meinen nehmen. Ich knabber immer noch an dem gewünschten Erklärtext.

rüdiger

Bezieht sich die LGPL nicht explizit auf dynamische Linkung? Das sollte vielleicht erwähnt werden.

Ansonsten ist ein kritischer Punkt der Haftungsausschluss der wohl in einer derartigen Form in Deutschland gar nicht möglich ist. Es gab da AFAIK sogar mal eine GPL-Like Lizenz von einer deutschen Behöre, um diesem Problem entgegen zu wirken (Ob diese aber je von einem Projekt benutzt wurde ist natürlich eine andere Frage ;))

Ich würde mir auch wünschen, wenn du ein wenig auf die GPLv3 eingehen würdest. Das ist sicher interessant, da viele Leute den Unterschied nicht genau kennen (mich eingeschlossen).

Interessant wäre sicher auch die MPL (Mozilla Lizenz), da diese ja ähnlich der LGPL ist, aber in der Kombination mit proprietärer Software wesentlich freier. Vielleicht kannst du im BSD-Teil auch noch MIT/Zlib-Lizenz erwähnen, da diese afaik relativ ähnlich sind (wobei zlib wohl die Werbeklausel umdreht und MIT so etwas gar nicht hat).

Eine Erwähnung möglicher Doppellizenzierung wäre imho auch wichtig. (Siehe zB MySQL)

Guter Link wäre zB noch http://www.gpl-violations.org/faq/vendor-faq.html (bzw. gpl-violations.org). (Werde mal schauen ob ich noch ein paar gute Links zu dem Thema habe und dann posten).

@estartu
Gibt es MySQL nicht auch mit einer kommerziellen Lizenz? Und bist du sicher dass die Libraries nicht unter der LGPL stehen?

rüdiger

Gerade noch gefunden: http://producingoss.com/en/legal.html

estartu

rüdiger schrieb:

@estartu
Gibt es MySQL nicht auch mit einer kommerziellen Lizenz? Und bist du sicher dass die Libraries nicht unter der LGPL stehen?

Nein, ich bin mir nicht sicher.
Auf jeden Fall durfte das DBMS nichts kosten, frei nach der Werbung: Geiz ist geil. Oder auch: Wir sparen, koste es was es wolle...

Artchi

Dann hätte man PostgreSQL nehmen können: hat mehr Features als MySQL, kostenlos und unter der BSD-Lizenz.

GPC

rüdiger schrieb:

Bezieht sich die LGPL nicht explizit auf dynamische Linkung? Das sollte vielleicht erwähnt werden.

Ja, das ist die Hintertür, durch die die ganze Geschichte funktioniert. Habe ich vergessen einzubauen, da ich's nur in der Präsi angesprochen habe.

Ich würde mir auch wünschen, wenn du ein wenig auf die GPLv3 eingehen würdest. Das ist sicher interessant, da viele Leute den Unterschied nicht genau kennen (mich eingeschlossen).

Mal sehen.

Interessant wäre sicher auch die MPL (Mozilla Lizenz), da diese ja ähnlich der LGPL ist, aber in der Kombination mit proprietärer Software wesentlich freier. Vielleicht kannst du im BSD-Teil auch noch MIT/Zlib-Lizenz erwähnen, da diese afaik relativ ähnlich sind (wobei zlib wohl die Werbeklausel umdreht und MIT so etwas gar nicht hat).

Na ja, ich kann den BSD-Teil in "Weitere OSS-Lizenzen" umbenennen und da was dazu schreiben.

Eine Erwähnung möglicher Doppellizenzierung wäre imho auch wichtig. (Siehe zB MySQL)

Das geht imo in eine andere Richtung als der Rest des Artikels, muss ich mal drüber nachdenken.

Guter Link wäre zB noch http://www.gpl-violations.org/faq/vendor-faq.html (bzw. gpl-violations.org). (Werde mal schauen ob ich noch ein paar gute Links zu dem Thema habe und dann posten).

Jo, wäre cool. gpl-violations.org wird aufgenommen.

Na ja, ich setz den dann mal wieder auf A, nachdem so viele Änderungswünsche eingegangen sind.

rüdiger

http://www.linuxdevices.com/news/NS7621424054.html

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-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 rechtliche 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 selber 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 die selben Rechte einräumen, die man auch selber 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 dass 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.

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 der LGPL-Software abgeleitet.
Zusätzlich erlaubt es die LGPL-Lizenz, darunter lizensierte 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 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 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

GPC

Obigen Post bitte auf thematische Fehler prüfen.

Mehrere Beispiele wurden eingebaut. LGPL- und BSD-Teil wurden erweitert. Die MIT- und MPL-Lizenz wurde aufgenommen. Vergleich zw. GPL v2 und v3 ist nicht drin, da ich mich nicht genug im Bereich Patente auskenne und somit das, was die neuen Artikel der GPL v3 aussagen, von mir nicht mit Paragraphen unterlegbar ist. Der von ruediger gepostete Artikel ist aber verlinkt.

Cheers

GPC

okay, bitte den Artikel auf Rechtschreibfehler durchsuchen. Danke im Voraus

michba

Inhalt:

1 Urheberrecht
2 Lizenzen im Detail
2.1 Die GPL
2.2 Die LGPL
2.3 Weitere Lizenzen
2.3.1 Die BSD-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 rechtliche 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.

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 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.