Seite auswählen

Für Nutzer und Entwickler von Open-Source-Software ist eine Auseinandersetzung mit den verschiedenen Software-Lizenzen früher oder später fast unvermeidlich. Was ist eine Software-Lizenz, wie unterscheiden sich die Lizenzen, was ist Copyleft, was darf der Anwender, was der Entwickler? Dieses Dokument versucht gängige Fragen zu beantworten und Empfehlungen für Entwickler zu geben.

Was ist Software?

Behandelt wird:

  • Ausführung von Programmen durch den Computer
  • Unterschied zwischen Binärdateien und interpretierten Programmen
  • Bedeutung des Quellcodes

Eine ungefähre Vorstellung davon, was unter Software zu verstehen ist, hat fast jeder Computernutzer, ob er sie nun selbst entwickelt oder nutzt. Doch wenn man die Unterschiede zwischen verschiedenen Software-Lizenzen verstehen möchte, ist es wichtig, sich auch über die Feinheiten des Software-Begriffs im Klaren zu sein.

Zunächst einmal ist zu unterscheiden zwischen Software die in Binärform vorliegt und solcher, die in umittelbar interpretierbarer Form vorhanden ist. Ein Computerprogramm ist prinzipiell eine Abfolge von Rechenanweisungen. Was für den Endnutzer eine Textverarbeitung mit Bildern ist, ist für den Rechner eine Reihe von Anweisungen, die jeweils aus einem Befehl und seinen Parametern bestehen: “Verschiebe den Inhalt des Registers XY auf den Akkumulator. Addiere die Konstante 3. Löse den System-Interrupt 12 aus.” Repräsentiert werden diese Befehle als eine Folge von Bits, d.h. als die Schaltzustände 1 und 0; man spricht von der Binärdarstellung.

Doch dies ist nicht die Form, in der Computerprogramme geschrieben werden, denn auf der Basis einfacher Rechenoperationen ist es kaum möglich, komplexe, abstrakte Vorgänge aus der realen Welt nachvollziehbar abzubilden. Deshalb gibt es eine Vielzahl sogenannter Programmiersprachen. Einige dieser Programmiersprachen werden kompiliert, das heißt, sie werden in Binärdateien übersetzt, die direkt für den Computer “verständlich” sind. Aus einem menschenlesbaren Programm wie

/* HelloWorld.c - Begrüßung der Welt */
main() {
printf("Hello world!\n");
}

wird die Binärdatei “hello” (unter Windows “hello.exe”), die nur für den Computer verständlich ist. Wer diese Datei aus dem Internet herunterlädt, kann sie zwar ausführen, aber kaum sinnvoll weiterverarbeiten. Dazu würde er den ursprünglichen Quellcode benötigen, also die obige Datei HelloWorld.c. Bei großen Projekten umfasst dieser Code mehrere Millionen Zeilen und Hunderte von Dateien. Neben den Programmanweisungen sind vor allem auch die Quellcode-Kommentare elementar. Diese beschreiben für den Programmierer, was eine bestimmte Anweisung tut — bei der Übersetzung in die Binärform werden sie schlicht ignoriert und sind in der Ergebnisdatei nicht mehr vorhanden.

Daneben gibt es noch so genannte interpretierte Programme. Diese werden nicht direkt in Maschinencode übersetzt, sondern erst beim Ausführen durch einen Interpreter. Solche Programme werden in der Regel im unveränderten Quellcode weitergegeben und können damit ohne Probleme an eigene Bedürfnisse angepasst werden. Das trifft insbesondere auf im World Wide Web gebräuchliche Skripte zu. Konsequenterweise stehen interpretierte Programme besonders häufig unter Open-Source-Lizenzen.

Programme, deren Quellcode nicht verfügbar ist, werden auch als “proprietär” bezeichnet (von property, Eigentum).

Daneben ist zu differenzieren zwischen Programmen und Programmbibliotheken. Ein Programm besteht aus mehreren Quellcode-Dateien, die verschiedene Programmfunktionen beinhalten. Um eine Weiterverwendung von Standardfunktionen (z.B. für die Darstellung von Fenstern und Knöpfen, aber auch für komplexe mathematische Operationen, Internet-Funktionen usw.) zu ermöglichen, werden diese üblicherweise in sog. Programmbibliotheken ausgelagert. Solche Bibliotheken, im Englischen “Libraries”, müssen von einem Programm, welches sie verwendet, eingebunden (“verlinkt”) werden: Das Programm muss wissen, wo die Funktionen zu finden sind. Dabei unterscheidet man zwischen statischer und dynamischer Bindung.

Bei statischer Bindung wird die Bibliothek direkt in das Binärprogramm eingebunden, also sozusagen mitgeliefert. Bei dynamischer Bindung wird die Bibliothek dagegen zur Laufzeit geladen; ist sie auf dem System nicht vorhanden, muss sie nachinstalliert werden. (Unter Windows handelt es sich hierbei um DLL-Dateien, unter Linux um so-Dateien.) Aus Speicherplatz- und Sicherheitsgründen werden i.d.R. dynamisch geladene Bibliotheken verwendet. Es gibt Open-Source-Lizenzen, die auf Programmbibliotheken spezialisiert sind, so z.B. die unten vorgestellte LGPL.

Was ist eine Lizenz?

Eine Software-Lizenz ist zunächst nichts anderes als ein Vertrag, in dem eine Partei (Lizenzgeber) einer anderen (Lizenznehmer) bestimmte Nutzungsrechte an einer urheberrechtlich geschützten Software überlässt oder beschränkt. Diese Rechte können beinhalten:

  • Allgemeines Nutzungsrecht an der Software
    • Zahl der Nutzer, Art der Nutzung usw.
  • Recht auf Weiterverbreitung der Software
  • Recht auf Veränderung der Binärdateien
  • Recht auf Veränderung des Quellcodes, sofern vorhanden
  • Recht auf Weiterverbreitung veränderter Versionen der Binärdateien oder des Quellcodes
  • Recht auf Verbindung (“Linking”) der Binärdateien oder des Quellcodes mit anderer Software
    • statisches Linking vs. dynamisches Linking

Während bei kommerzieller Software Rechte üblicherweise eingeschränkt werden, geht es bei Open Source bzw. Freier Software (mehr über die Unterscheidung unten) darum, möglichst vielen Menschen eine Veränderung des Codes zu gestatten und damit eine langfristige Verbesserung der Software zu ermöglichen. Die Rechtskräftigkeit von sog. Click-Through-Lizenzen ist fragwürdig, da es sich nicht um individuelle Verträge, sondern um serienmäßig identische Texte handelt und somit die strengen Regeln für Allgemeine Geschäftsbedingungen gelten.

Open-Source-Lizenzen unterscheiden sich von traditionellen “EULAs” (End User License Agreements), da der Anwender sie nicht akzeptieren muss — sie gewähren ihm schließlich nur Rechte, die er unter dem sonst gültigen Urheberrecht gar nicht hätte. Dennoch sind nicht alle Klauseln in gängigen OSS-Lizenzen nach deutschem Recht zulässig [1].

Welche Lizenzen sind verbreitet?

Das SourceForge-Projekt ist mit über 50.000 Projekten der größte Hosting-Anbieter für Open-Source-Software (daneben gibt es andere Anbieter wie GNU Savannah und BerliOS). Im Januar 2003 sah die Verteilung der Projekte nach Lizenzen wie folgt aus:

Deutlich erkennbar ist die massive Dominanz der GNU General Public License und ihrer Schwesterlizenz, der GNU Lesser General Public License (LGPL). Die BSD-Lizenz gehört zu den beliebtesten Alternativen, aber auch die Artistic License, die Apache Software License und die noch junge Mozilla-Lizenz sollten nicht unterschlagen werden.

Die GNU General Public License

Text: Vollständiger Text der GNU GPL Version 3

Die Dominanz der GPL ist historisch wie ideologisch erklärbar. 1983 legte Richard Stallman, Computerpionier am MIT, den Grundstein des GNU-Projekts. GNU sollte das proprietäre UNIX-Betriebssystem (bestehend aus einem Kernel und verschiedenen Anwendungsprogrammen) durch sogenannte “freie Software” ersetzen. Es sollte jedem gestattet sein, den Code der Software frei zu verändern und weiterzugeben. Eine kommerzielle Nutzung war dennoch nicht ausgeschlossen; so verkaufte Richard Stallman selbst frühe Versionen der GNU-Software auf Datenträgern.

1989 entwickelte das GNU-Projekt für seine Software eine einheitliche Lizenz, die folgende Kriterien erfüllen sollte:

  1. Freiheit das Programm für jeden Zweck auszuführen
  2. Freiheit den Quellcode zu studieren und anzupassen
  3. Freiheit, das Programm zu kopieren
  4. Freiheit, das veränderte Programm zu kopieren

Diese Freiheiten sollten auch langfristig sichergestellt werden. Zu diesem Zweck enthält die GPL zwei wesentliche Klauseln:

  • Jedes Derivat muss ebenfalls vollständig unter der GPL lizenziert werden.
  • Bei Weitergabe des Programmes in Binärform muss der Quellcode des gesamten Programms mitgeliefert oder auf Anfrage ausgehändigt werden.

Wird eine Programmbibliothek unter die GPL gestellt, muss jedes Programm, das diese Bibliothek nutzt (gleich ob statisch einkompiliert oder dynamisch zur Laufzeit aufgerufen) ebenfalls unter der GPL stehen. Wird die GPL mit anderen Werken zusammengestellt (z.B. auf einer CD-ROM-Sammlung oder in Form einer Linux-Distribution) müssen diese anderen Werke allerdings nicht automatisch unter der GPL lizenziert werden.

Das GNU-Projekt erwies sich als recht erfolgreich. Heutige Linux-Systeme beruhen zu großen Teilen auf GNU-Software (dies betrifft eine Vielzahl von Kommandozeilen-Werkzeugen inklusive dem elementaren GNU C-Compiler, zahlreiche Programmbibliotheken, den GNOME-Desktop usw.). Schon aus dieser Tradition heraus verwenden viele neue Open-Source-Projekte die GPL. Die GPL garantiert, dass freie Software stets freie Software bleibt und nicht z.B. Microsoft GNU-lizenzierte Bibliotheken in seine Software einbaut und gleichzeitig weiterhin deren Verbreitung und Veränderung untersagt.

Weitere Bedingungen der GPL (Version 2 von 1991) sind:

  • Beim Programmstart sollte ein Hinweis auf die GPL erfolgen (nicht bindend).
  • Sollte z.B. aufgrund von Patentlizenzforderungen eine freie Verbreitung des Programms unter der GPL nicht möglich sein, darf der Lizenzgeber das
  • Programm nicht unter der GPL weitergeben. So wird sichergestellt, dass ein Lizenzgeber nicht durch die Hintertür die Freiheiten der GPL einschränkt.
  • Der Lizenzgeber kann aus patent- oder urheberrechtlichen Gründen die Verbreitung auf bestimmte Länder beschränken.
  • Die Haftung für entstehende Schäden wird (im Rahmen der rechtlichen Möglichkeiten) ausgeschlossen.

GPL-Mythen

Entgegen anderslautenden Behauptungen führt die Verwendung von GPL-Software nicht dazu, dass automatisch andere verwendete Software unter der GPL lizenziert werden muss. Auch bei der Weitergabe von GPL-Software zusammen mit anderer Software (also z.B. in einer Software-Sammlung) muss diese Software nicht automatisch GPL-lizenziert werden. Lediglich wenn Quellcode anderer Software mit GPL-Software kombiniert wird und das Ergebnis weitergegeben wird, muss dies unter den Bedingungen der GPL geschehen. Eine bloße Anpassung von GPL-lizenzierter Software für den privaten oder unternehmensinternen Gebrauch führt nicht zu einer Pflicht, diese Veränderungen zu veröffentlichen. Das gleiche gilt für die Anpassung z.B. von Website- oder Datenbank-Backends, die für externe Nutzer zugänglich sind, deren Quellcode aber nicht verbreitet wird.

Die GNU Lesser General Public License

Text: Text der Version 3

Die GNU LGPL wurde aus einem Dilemma heraus ins Leben gerufen: Auf der einen Seite möchte das GNU-Projekt sicherstellen, dass auch Derivate unter der GPL lizenziert werden und somit die Entwicklung freier Software gefördert wird. Insbesondere bei Programmbibliotheken ist es jedoch meistens wünschenswert, einen einheitlichen Standard zu entwickeln (z.B. für die Darstellung von Programmfenstern und Buttons) — Bibliotheken unter der GPL zwingen proprietäre Entwickler dazu, eigene Bibliotheken zu entwickeln oder zu verwenden. Bei elementaren Bibliotheken wird die Entwicklung proprietärer Software für die betreffende Plattform sogar nahezu unmöglich gemacht, was selbst manchen GNU-Enthusiasten zu weit geht.

Ursprünglich hieß die LGPL “Library General Public License”, sie wurde jedoch in “Lesser” umbenannt, da Richard Stallman befürchtete, sie würde sonst zu häufig für Programmbibliotheken verwendet. “Lesser” soll kenntlich machen, dass die Nutzerfreiheit (im Sinne des GNU-Projekts) pragmatischen Motiven untergeordnet wird. Die LGPL unterscheidet sich von der GPL im Wesentlichen dadurch, dass sie sowohl die statische als auch die dynamische Verlinkung der Bibliothek mit beliebigen Programmen erlaubt, ohne dass automatisch das gesamte Programm unter den Bedingungen der Lizenz stehen müsste. (Allerdings muss ein Reverse Engineering des gesamten Programms gestattet sein.)

Die LGPL erzwingt gleichzeitig das “Copyleft” für den Code der eigentlichen Programmbibliothek: Alle Veränderungen an der Bibliothek selbst müssen wiederum frei verfügbar sein.

Open Source vs. Freie Software

Siehe auch: “Why ‘Free Software’ is better than ‘Open Source‘”, Standpunkt des GNU-Projekts

An dieser Stelle soll kurz auf die Unterschiede zwischen den Begriffen Open Source und Freie Software eingegangen werden.

Vertreter Freier Software, wie des GNU Projekt oder BSD Projekt, legen Wert darauf, zwischen den Begriffen zu differenzieren. Freie Software ist als Begriff seit über 20 Jahren verbreitet und bezieht sich auf die Freiheit, die wesensgebend für sie ist. Da im Englischen für den Begriff “Free Software” die Gefahr eines Mißverständnisses bzgl. des Preises möglich ist, hat die Open Source Initiative (OSI) 1998 “Open Source” als Marketingbegriff für Freie Software vorgeschlagen.

Der Schwerpunkt sollte hierbei auf einer ausschließlich technokratischen Argumentation liegen; auf der Freiheit basierende Erwägung möglicher sozialer, politischer oder volkswirtschaftlicher Auswirkungen von Software wurde als unwichtig und sogar schädlich abgelehnt.

Der Begriff wurde schnell inflationär verwandt und vor allem auch von der proprietären Softwareindustrie gefördert, da er leichten Mißbrauch zuläßt und Fehlinformation Vorschub leistet. So haben u.A. Microsoft und Sun proprietäre “Open Source” Programme marketingtechnisch verwandt.

Bezüglich der Lizenzen unterscheiden sich die Begriffe nur unwesentlich, die Firmen Freier Software wehren sich jedoch zunehmen dagegen, unter dem Oberbegriff “Open Source” subsummiert zu werden, da ihnen dies eine Benachteiligung am Markt verschafft. “Wir sprechen von Freier Software”

Auch der Autor der Open Source Definition, Bruce Perens, hat sich mittlerweile von dem Begriff Open Source distanziert und die Kampagne als einzige Privatperson unterzeichnet.

BerliOS hat sich durch seine Namenswahl auf Open Source festgelegt. In diesem Text wird daher Open Source als Oberbegriff verwendet.

Die BSD-Lizenz

Text: BSD-Lizenz

Die BSD-Lizenz hat eine andere historische Tradition als die GPL bzw. LGPL. Der Name stammt von der Berkeley Software Distribution, einer seit den 1970er Jahren entwickelten UNIX-Distribution, die Anfang der 1990er als Open-Source-Software zur Verfügung gestellt wurde (daraus entwickelten sich verschiedene freie Unices: OpenBSD, NetBSD, FreeBSD usw.). Die Lizenzbedingungen sind einfach:

Das Programm darf in jeder Form, auch in Binärform, weitergegeben werden. Eine Pflicht zur Überlassung des Quellcodes besteht nicht.
Bei der Weitergabe in Binärform muss die Lizenz den Dateien beigefügt werden.
Bei Derivaten darf der Name der Autoren/des Herstellers nicht ohne Erlaubnis für Werbezwecke verwendet werden.

Zusätzlich enthielt die erste Version der BSD-Lizenz eine sogenannte Werbeklausel, die es erforderlich machte, in Werbematerialien auf die Universität Berkeley hinzuweisen. Diese Klausel wurde 1999 aufgrund von Beschwerden aus den Originalen Quellen von 4.4BSD-Lite entfernt. Das FreeBSD übernahm diese Änderung größtenteils für die eigenen Erweiterungen dieser Quellen, NetBSD und OpenBSD folgten dem nicht. Die erste Version der BSD-Lizenz wird dennoch von vielen Open-Source-Projekten verwendet. So finden sich in allen BSD-Versionen (und bei anderen, die BSD-Lizenzierte Software vertreieben) etliche dutzend dieser Klauseln, mit dem Hinweis auf den jeweiligen Verfasser.

Die Mozilla Public License

Text: Mozilla Public License

Als im Februar 1998 der Quellcode des Web-Browsers Mozilla freigegeben wurde, stellte das Mozilla-Projekt gleich auch eine neue Software-Lizenz vor, die Mozilla Public License Version 1.0. Mittlerweile wird die revidierte Version 1.1 verwendet. Die MPL enthält einige neuartige Klauseln, ähnelt aber grundsätzlich der LGPL.

Unterschieden wird zwischen Datei-Derivaten und Werkderivaten. Datei-Derivate sind Änderungen an einzelnen MPL-lizenzierten Dateien, ihre Zusammenführung oder Inklusion in anderen Dateien. Werkderivate sind Werke, die Funktionen aus den MPL-Lizenzierten Dateien aufrufen oder von ihnen aufgerufen werden. Der Source-Code von Datei-Derivaten muss auf Anfrage ausgehändigt werden; Datei-Derivate müssen ebenfalls unter der MPL lizenziert werden. Werkderivate können dagegen beliebig lizenziert werden.

Damit wird sichergestellt, dass die Schnittstellen der Applikation offen bleiben, einzelne Erweiterungen jedoch proprietär sein können. Diese Vorgehensweise ist sicherlich besonders bei einem Web-Browser nachvollziehbar, aber auch für andere modulare Systeme geeignet.

Zwar schreibt die MPL für Datei-Derivate die Aushändigung des Quellcodes vor, erlaubt aber für die Binärdateien beliebige Lizenzierung, sofern die Lizenzbedingungen nicht mit der MPL in Konflikt stehen. So kann z.B. die Verbreitung von bestimmten Binärdateien untersagt werden, die Herstellung und freie Verbreitung von Binärdateien durch Dritte jedoch nicht.

Die MPL enthält auch eine salvatorische Klausel, was bedeutet, dass die verbleibenden Bedingungen auch rechtskräftig sind, wenn es einzelne Bedingungen aufgrund im Lande des Rechtsvorgangs geltender Bestimmungen nicht sind. So könnten z.B. Kryptographie-Exportverbote eine Verbreitung bestimmten Quellcodes verhindern, dies würde jedoch die übrigen MPL-Bedingungen nicht tangieren, sie müssen soweit möglich erfüllt werden.

Seit Version 1.1 erlaubt es die MPL, einzelne Dateien des Werkes unter mehreren Lizenzen zur Verfügung zu stellen, was bei Wahl einer GPL-kompatiblen Lizenz auch die Verbindung derartig designierter Dateien mit GPL-Code ermöglicht.

Die Apache Software License

Text: Apache License 2.0

Die Apache Software Foundation, die von namhaften IT-Unternehmen unterstützt wird, hat für ihre Open-Source-Serverprodukte (am bekanntesten davon der Apache Webserver) eine eigene Lizenz entwickelt. Diese Lizenz erlaubt Veränderungen am Quellcode und die ausschließliche Weitergabe in Binärform, sofern die Lizenzbedingungen beigefügt werden. Sie enthält eine BSD-ähnliche Werbeklausel, die in Version 1.1 auf Dokumentation beschränkt wurde. Sie verbietet außerdem den Gebrauch des Namens “Apache” für Derivate.

Die Apache Software License ist sehr stark auf Apache-Produkte spezialisiert und empfiehlt sich kaum für allgemeine Open-Source-Applikationen.

Die Artistic License

Text: Artistic License 2.0

Die Artistic License wird für die Programmiersprache Perl verwendet. Perl selbst ist parallel unter der GPL lizenziert, das gleiche gilt für viele Perl-Programme und Bibliotheken. Aufgrund von juristischen Unklarheiten bei bestimmten Formulierungen wurde die Artistic License durch die Clarified Artistic License abgelöst.

Die Artistic License gestattet kostenlose Verbreitung und die Weitergabe von Veränderungen, unterscheidet dabei aber zwischen der sog. Standard-Version und Derivaten davon. Sie erlaubt es, proprietäre Derivate zu erstellen, diese müssen aber eindeutig gekennzeichnet sein (andere Dateinamen, Dokumentation der Unterschiede). Die freie Bereitstellung des Quellcodes eigener Veränderungen kann einmalig erfolgen, z.B. über das Posting im Usenet oder den Upload in ein öffentliches Datei-Archiv. Es dürfen Distributionsgebühren gefordert werden (also Gebühren für die bloße Bereitstellung der Software), aber keine Lizenzgebühren (also Gebühren, die z.B. an die Zahl der Nutzer gebunden sind).

Die Vielzahl von Fallunterscheidungen macht die Artistic License zu einer recht komplizierten Lizenz.

Kompatibilitätsfragen

Bei der Wahl einer Lizenz sollte man sich zunächst überlegen, ob man Code aus anderen Produkten in der eigenen Software verwenden möchte. Das betrifft Bibliotheken oder auch komplette Programmbestandteile. Solcherartig integrierter Quellcode darf nicht einzelne Lizenzbedingungen des Hauptwerks, welches man darum erweitert, zurücknehmen. Enthält z.B. die Lizenz des Hauptwerks eine Werbeklausel, so müssen auch alle Werkderivate diese Werbeklausel enthalten.

Die Kompatibilitätsproblematik ist mitunter hochkomplex, da nicht klar definiert ist, was Hauptwerk und was Derivat ist und welche Lizenzbedingungen dominieren. Entscheidet man sich für die “Standardlizenz”, die GPL, wird man naturgemäß die wenigsten Probleme haben: Man kann ohne Schwierigkeiten Quellcode aus der großen Mehrzahl von Open-Source-Applikationen verwenden, und viele andere Lizenzen wurden angepasst, um mit der GPL kompatibel zu sein. So können GPL-Programme Quellcode, der unter der neuen BSD-Lizenz steht, nach Belieben verwenden; der umgekehrte Weg ist nicht möglich.

Der Hauptunterschied zwischen der GPL und anderen Lizenzen ist das Verbot der Weitergabe in Binärform ohne Bereitstellung des Quellcodes. Ist diese Einschränkung (oder Freiheit, je nach Definition) gewünscht, stellt die GPL ohne Zweifel fast immer die beste (weil kompatibelste) Wahl dar.

Eine ausführliche Diskussion der Kompatibilität anderer Lizenzen mit der GPL findet sich in dem Text “Various Licenses and Comments about Them” des GNU-Projekts.

Anwendung

Die Anwendung einer Open-Source-Lizenz ist prinzipiell einfach. Die Lizenz sollte als Datei dem Programm beigefügt werden — in der Unix-Welt hat sich der Dateiname COPYING eingebürgert. Jede Quellcode-Datei sollte in kurzer Form auf die oder den Urheber, den Namen der Lizenz, die Version und die Datei verweisen, also z.B.:

Diese Datei ist Bestandteil von MegaCalc, 1994-2003 entwickelt von Werner Muster, Klaus Beispiel und anderen, siehe die Datei CREDITS für Details.
MegaCalc ist freie Software unter den Bedingungen der GNU General Public License Version 2. Die Haftung ist ausgeschlossen. Diesem Programm sollte die Datei COPYING beiliegen, welche die Lizenzbedingungen enthält. Sollte dies nicht der Fall sein, können Sie die Lizenz bei der Free Software Foundation (www.fsf.org) anfordern: Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

Zusätzlich empfiehlt es sich (bei bestimmten Lizenzen ist es sogar erforderlich), die Lizenzbedingungen beim Programmstart oder bei der Installation mindestens einmal einzublenden.

Bei mehrsprachiger Software sollte der Hinweis in englischer Sprache eingefügt werden, Anwendungsbeispiele für die einzelnen Lizenzen finden sich in der Liste von Open-Source-Lizenzen der Open Source Initiative.

Mitarbeit beim GNU-Projekt

Fiduciary Licence Agreement der FSF Europe

GPL-Software ist nicht zwangsläufig Bestandteil des GNU-Projekts. Vielmehr kann die GPL für beliebige Projekte eingesetzt werden. Es ist jedoch im Prinzip jedem möglich, sich am GNU-Projekt zu beteiligen (siehe “How you can help the GNU Project” auf der GNU-Homepage). Hierbei ergibt sich ein Problem: Die FSF besteht darauf, dass das Urheberrecht an GNU-Software an sie übertragen wird. Eine vollständige Übertragung der Urheberrechte gibt es jedoch nur im amerikanischen Copyright, nicht aber im europäischen Urheberrecht.

Die Gründe der Übertragung führt die FSF in dem Text “Why the FSF gets copyright assignments from contributors” an: Grundsätzlich ist eine effektive Rechtsausübung nur dem Rechteinhaber möglich. Wenn es zu einem Rechtsstreit kommt, müsste bei einem Software-Projekt mit Dutzenden oder gar Hunderten von Mitarbeitern jeder sein Einverständnis für die Vertretung vor Gericht geben. Dieses Problem wird vermieden, indem alle Rechte an die FSF übertragen werden (eine einmal vergebene Lizenz kann nicht zurückgenommen werden, so dass ein Missbrauch praktisch ausgeschlossen ist).

Im europäischen Recht gibt es jedoch die nichtübertragbaren moralischen Rechte an einem Werk (z.B. das Recht, als Autor identifiziert zu werden). Um eine Übertragung der maximalen Rechte dennoch zu ermöglichen, stellte die FSF Europe gemeinsam mit dem Institut für Rechtsfragen der Open Source Software (ifrOSS) im Februar 2003 das sogennante Fiduciary License Agreement (FLA, dt. Treuhänderische Lizenzvereinbarung) vor.

Das FLA ist eine vertragliche Übereinkunft zwischen FSF und Rechteinhaber zur Übertragung exklusiver Nutzungsrechte an die FSF. Im Gegenzug erhält der Urheber beliebig viele einfache Nutzungsrechte, die z.B. zur Doppel-Lizenzierung (s.u.) erforderlich sind. Die FSF erlangt durch das FLA einen juristischen Vertretungsanspruch. Sie verliert nach der Übereinkunft automatisch alle ihre Rechte, sofern sie versuchen sollte, die Software proprietär zu vertreiben.

Doppel-Lizenzierung

Die hier vorgestellten Open-Source-Lizenzen schließen eine kommerzielle Verwertung des Quellcodes keineswegs aus. Jedoch wird eine solche Verwertung natürlich dadurch erschwert, dass es grundsätzlich jedem erlaubt ist, den Quellcode der Software zu verbreiten. Einige Geschäftsmodelle basieren darauf, Binärdateien der Software kommerziell weiterzugeben und nur die Quellen kostenlos zu verbreiten, die MPL begünstigt ein solches Vorgehen zu einem gewissen Grad. Auch hier kann jedoch prinzipiell jeder Dritte Binärdateien erstellen und kostenlos verbreiten. Gängiger sind Geschäftsmodelle, bei denen Open-Source-Software im Auftrag erstellt wird, was durch Plattformen wie BerliOS SourceAgency erleichtert wird.

Neben diesen Modellen gibt es noch die Option der Doppel-Lizenzierung. Dieses Modell eignet sich vor allem für Programm-Bibliotheken und Plugins. Es beruht darauf, dass die GPL im Gegensatz zur LGPL auch die Verlinkung der Software mit proprietären Applikationen nicht gestattet. Der Urheber hat jedoch grundsätzlich das Recht, seine Software unter mehreren Lizenzen zu verbreiten. So kann z.B. ein Programm sowohl unter der GPL vertrieben als auch kommerziell verkauft werden, wobei die kommerzielle Lizenz die Nutzung in proprietärer Software gestattet, die GPL aber nicht. Um es einfacher auszudrücken: Wer die Programmbibliothek verwenden will, ohne seine eigene Software unter die GPL zu stellen, muss zahlen.

In diesem Modell wird die Erstellung freier Software begünstigt, proprietäre Software aber nicht unmöglich gemacht. Eingesetzt wird es v.a. von der Firma Trolltech, welche die für den KDE-Desktop elementaren Qt-Bibliotheken entwickelt. Diese werden unter der GPL und einer kommerziellen Lizenz vertrieben, welche proprietäre Verwendung erlaubt. Auch Sleepycat Software, Hersteller der Datenbank-Bibliothek Berkeley-DB, nutzt dieses Modell. Bei kompletten Applikationen ist es allerdings wenig erfolgversprechend, da die Entwicklung proprietärer Derivate relativ unwahrscheinlich ist.

Nicht zuletzt gibt es auch noch das Geschäftsmodell, die Software als Open Source zu verbreiten, aber für die Dokumentation Geld zu verlangen und diese unter normalem Urheberrecht zu verbreiten. Dieses Modell wird relativ selten genutzt, aber der Erfolg des Verlages O’Reilly beruht zum großen Teil darauf, “proprietäre” Dokumentation für offene Software zu verkaufen.

Übersicht und Schlussfolgerungen

Die diskutierten Lizenzen unterscheiden sich vor allem nach ihrem “Copyleft”-Effekt, d.h. nach der Pflicht, Erweiterungen oder Verbindungen der Software ebenfalls unter einer Open-Source-Lizenz zur Verfügung zu stellen. In dieser Hinsicht ist die BSD-Lizenz die “liberalste” Lizenz und die GPL die “restriktivste”. Copyleft-Befürworter argumentieren, dass die BSD-Lizenz den Benutzer einschränkt, da er nicht mehr alle Versionen der Software frei nutzen kann.

Die folgende Tabelle liefert eine Einordnung der vorgestellten Lizenzen nach ihrem Copyleft-Effekt. Dieser bezieht sich ausschließlich auf verbreitete Versionen der Software. Keine Open-Source-Lizenz schränkt das Recht auf Veränderungen für den privaten bzw. unternehmensinternen Gebrauch ein.

Copyleft-EffektErlaubt direkte Einbindung in proprietären CodeErlaubt Verbindung mit proprietärem Code, der sich in separaten Dateien befindet, aber gemeinsam kompiliert wirdErlaubt indirekte Einbindung in proprietärer Software (statisches oder dynamisches Linking)Erlaubt keine Verbindung mit proprietärer Software
LizenznameBSD
Artistic License
MPLLGPLGPL

Welche Lizenz sollte man verwenden? Das ist auch eine ideologische Frage: Möchte man den Open-Source-Gedanken so weit wie möglich unterstützen, sollte man eine Copyleft-Lizenz wählen, also z.B. die GPL oder die MPL. Möchte man dagegen nicht verhindern, dass proprietäre Applikationen den eigenen Quellcode nutzen und womöglich gewinnbringend vermarkten, kann man sich z.B. für die BSD-Lizenz oder die Artistic License entscheiden. Für Programmbibliotheken bildet die LGPL einen Kompromiss, der den Copyleft-Gedanken aufrecht erhält, aber gleichzeitig die Nutzung in proprietärer Software nicht unnötig erschwert.

Eines sollte man nicht vergessen: Die Urheber haben stets die Möglichkeit, die Lizenz ihrer Software zu ändern. Dies kann zwar Rechte an bestehendem Quellcode nicht einschränken, sehr wohl aber die Rechte an neu hinzugefügtem Quellcode. Sie können auch eine Doppel-Lizenzierung wählen und damit sowohl die Entwicklung freier Software als auch eine kommerzielle Verwertung in Form proprietärer Software unterstützen.

Eine umfassendere Sammlung von Open-Source-Lizenzen und eine Einordnung nach ihrem Copyleft-Effekt (ohne eine detaillierte Diskussion) findet sich im Lizenz-Center des Instituts für Rechtsfragen der Freien und Open Source Software (ifrOSS).