GPL und andere Lizenzen in Linux


Christian Thiel

89077 Ulm

Dokument auch im Microsoft Word Format verfügbar


ABSTRACT

Das freie Linux-System verbreitet sich immer mehr. Dieses Papier befasst sich mit den Softwarelizenzen, unter welchen wichtige Komponenten wie der Kern (General Public License GPL), die BASH (GPL), KDE (Qt Public License) oder Apache (Apache License) veröffentlicht werden. Auch seltenere Varianten wie die Artistic license, die BSD-license, die MIT-license oder die GNU Free Documentation License haben einen eigenen Abschnitt. Dabei werden alle relevanten Aspekte der jeweiligen Lizenz erläutert und bewertet. Einen großen Raum nimmt die Erklärung des „viralen“ Copyleft-Prinzips der Free Software Foundation ein.

Außerdem wird der Begriff „OpenSource“ ausführlich definiert und die Lizenzen unter ihm eingeordnet. Es werden Überlegungen angestellt, welche Lizenzen kompa­tibel sind, also welche Programme zusam­men­gepackt werden dürfen. Am Schluß steht ein Exkurs zum Haftungsrecht im Bezug auf Lizenzierung und Lizenzen.

Das Ergebnis wird ein grober Überblick über die Lizenzen unter Linux sein, der den Leser ermutigt, die für sein Programm passende auszuwählen.



1. EINLEITUNG

Das freie Linux-Betriebssystem ist inzwischen weit verbreitet. In dieser Arbeit werden die Grundlagen der verschiedenen Softwarelizenzen, die bei Linux-Programmen zu finden sind, erklärt, und die Lizenzen verglichen. Außerdem wird aufgezeigt, warum es Microsoft oder anderen Firmen bisher schlecht gelingen konnte, Linux durch proprietäre Erweiterungen zu nicht-freier Software zu machen. Der Begriff “Open Source” wird definiert. Am Schluß wird noch ein Überblick über das Haftungsrecht im Bezug auf Lizenzen gegeben.

2. Die verschiedenen Lizenzen

2.1 General public License (GPL)

Die GPL5 wurde von Richard Stallman (oft mit RMS abgekürzt) verfasst. Stallman gründete 1985 die Free Software Foundation (FSF) 5, die zum Ziel hat, Beschränkungen beim kopieren, weiterverteilen, verstehen und modifizieren von Computerprogrammen auszumerzen. Zu diesem Zweck wurde das Projekt “GNU-Betriebssystem” (“Gnu is not Unix”) ins Leben gerufen, dessen Endprodukt eine Alternative zu freier Software darstellen sollte. Die für GNU geschriebenen Programme wurden unter die GPL gestellt.

Das fast geniale an dieser Lizenz ist, dass sie das Copyright benutzt, um sicherzustellen, dass Programme, die auf mit ihr lizenziertem Code aufbauen, keine anderen, eigenen Lizenzen haben dürfen, sondern ebenfalls der GPL unterliegen. Für dieses Verfahren, dass mit legalen Mitteln die Software zur Verwendung freigibt und verhindert, dass Code in proprietären Produkten verwendet wird, hat Stallman den Begriff “Copyleft” geprägt, der 1984 (1985) von Don Hopkins scherzhaft aufgebracht wurde. Copyleft soll ausdrücken, dass das Resultat dieser Lizenz das genaue Gegenteil von Copyright ist (scherzhaft: Copyleft: all rights reversed). Warum dieser Ansatz vielleicht problematisch ist, werden wir später sehen.

Die GPL 5 fängt mit einem Vorwort von Richard Stallman an, in dem er seine Beweggründe dafür darlegt, die GPL so zu gestalten, wie sie ist, und die Vorgehensweise erklärt: Die Software wird unter ein Urheberrecht (Copyright) gestellt, und allen Menschen die Lizenz angeboten, die Ihnen das Recht gibt, die Software zu vervielfältige, zu verbreiten und/oder zu verändern.

Paragraph 0 stellt fest, das die Lizenz für jedes Programm und jedes andere Werk gilt, also nicht nur auf Programme anwendbar ist. Allerdings gibt es zum Beispiel speziell für Dokumentation die GNU Free Documentation License (FDL). Die Lizenz gilt für jedes Programm, welches den Hinweis trägt, das es gemäß den Bestimmungen der General Public License verbreitet werden darf. Die Vereinbarungen betreffen ausschließlich die Vervielfältigung, Verbreitung und Bearbeitung des Programms. Das Ausführen unterliegt keinerlei Einschränkungen, es kann also auch für kommerzielle Zwecke genutzt werden. Kritisch ist in diesem Zusam­men­hang lediglich die Bestimmung, das Ausgaben des Programms der GPL unterliegen, wenn der Inhalt ein auf dem Programm basierendes Werk darstellt. Beispiele hierfür wäre das Ergebnis eines parser generators wie “flex” oder “bison”. Für Binary Code, der von GNU-Compilern erstellt wurde, scheint die Lizenz nicht zu gelten 5.

In Paragraph 1 wird gefordert, dass mit jeder Kopie ein entsprechender Copyright-Vermerk sowie ein Haftungs­ausschluss veröffentlicht, alle Vermerke, die sich auf die Lizenz und das Fehlen einer Garantie beziehen, unverändert gelassen werden und des weiteren allen anderen Empfängern des Programms zusammen mit dem Programm eine Kopie dieser Lizenz zukommt. Damit sichert sich der Autor und alle nachfolgenden Program­mierern Haftungsansprüchen gegenüber ab und stellt sicher, dass die GPL textuell immer mit verbreitet wird.

Für das Kopieren der Software darf Entgelt verlangt werden, man darf auch eine Garantie für das Programm anbieten! Diese Klausel stellt die Grundlage für die vielen Linux-Distributionen dar. Dass die Preise nicht in den Himmel steigen, dafür sorgt die Marktwirtschaft. Es ist noch anzumerken, dass niemand verpflichtet ist, den (u.U. verbesserten) Code weiterzugeben, die Erwei­terungen können auch firmenintern genutzt werden, ohne dass sie zurück an die weltweite Entwickler-Gemeinde gelangen.

Unter welchen Bedingungen ich Weiterentwicklungen des Codes, also ein auf dem Programm basierendes Werk, weiterverbreiten darf, ist in Paragraph 2 geregelt. Drei Anforderungen werden gestellt:

  1. Alle Änderungen müssen im Programm (mit Datum) dokumentiert werden. Das hat den Sinn, den Autor des jeweiligen Codes ausfindig machen zu können, bzw. ist der ursprüngliche Autor dagegen geschützt, dass später hineinprogrammierte Fehler auf ihn zurückfallen. Die Entsprechenden Hinweise sind jedoch in der Praxis so gut wie nie vorhanden 5.

  2. Es muss sichergestellt werden, dass jedes verbreitete Programm “that in whole or in part contains or is derived from the Program or any part thereof” Dritten ohne Lizenzgebühr und unter der GPL zur Verfügung gestellt wird.

  3. Wenn das veränderte Programm bei der Ausführung interaktiv Kommandos einliest, soll die GPL Copyright-Notice ausgegeben werden und ein Hinweis darauf, wie der Benutzer den vollen Text der GPL einsehen kann.

Diese Anforderungen betreffen das veränderte Werk als Ganzes. “If identifiable sections of that work are not derived from the Program, and can be reasonably con­sidered independent and separate works in themselves”, dann müssen diese Abschnitte nur unter die GPL gestellt werden, falls sie als Teil eines Ganzen verbreitet werden, das ein auf dem Programm basierendes Werk darstellt. Ein Zusammenpacken einer unab­hängigen Arbeit mit einem GPL-Programm läßt die Rechte dieser Arbeit unverändert. Letzteres befähigt die Distributoren, kom­merzielle Software mit Linux auf der gleichen CD auszuliefern.

Dieser Paragraph ist es, aufgrund dessen der GPL kommunistische Tendenzen vorgeworfen werden, und ihr eine virenartige Natur zugeschrieben ist. Die Vorwürfe sind nicht unberechtigt, schließlich steht jedes Programm, das auf GPL-lizenzierten aufbaut, auch wieder unter der GPL und ist somit frei verfügbar und gehört niemandem. Das hindert Microsoft und andere Firmen daran, die Strategie des „embrace and extend“ anzuwenden, bei der offene Standards um nützliche proprietäre Funktionen erweitert werden, die dann durch Marktsättigung zum Standard werden und nicht mehr OpenSource sind. Das ist allerdings hier unmöglich, da, wie schon gesagt, jegliche Erweiterungen unter der GPL stehen müssen.

In Paragraph 3 wird festgelegt, dass der Quellcode grundsätzlich maschinenlesbar mitverbreitet werden muss. Alternativ kann auch ein mindestens drei Jahre lang gültiges Angebot mitgeliefert werden, den Quellcode zu eigenen Kopierkosten auf einem üblichen Medium zuzusenden. Als Quellcode gilt übrigens “the preferred form of the work for making modifications to it.”

Laut Paragraph 4 darf das Programm nicht verviel­fältigt, verändert, weiter lizenziert oder verbreitet werden, sofern es nicht durch diese Lizenz ausdrücklich gestattet ist, sprich weiter unter der unveränderten GPL steht. Damit wird eigentlich nur sichergestellt, dass Paragraph 3 immer Anwendung findet.

Paragraph 5 erinnert ein wenig an Microsoft-Praktiken: durch eine Handlung, bei MS das Benutzen des Pogramms, hier das Verändern oder Verbreiten der Software, wird die Lizenz akzeptiert. Paragraph 6 schlägt noch mal in die gleiche Kerbe wie die Para­graphen drei und vier.

Im nächsten Abschnitt, Paragraph 7, geht es etwas tiefer in den Rechtsdschungel hinein. Es wird (in Deutschland eine Standardklausel) festgestellt, dass die (Rest-)Lizenz weiterhin Gültigkeit behält, selbst wenn einzelne Teile davon nicht rechtmäßig oder nicht durchsetzbar seien sollten. Außerdem wird der Code “rein” gehalten: Falls jemandem, der Code unter der GPL veröffentlichen will, Bedingungen auferlegt sind (z.B. durch Patente, Gerichtsbeschluß), die den Bedingungen der GPL widersprechen, so darf er sie nicht unter ihr veröffent­lichen. Damit soll verhindert werden, dass von Programmieren fremde Patente benutzt und dann tief in das freie System hinein gewoben werden, was dem Patentinhaber gegenüber extrem verletzlich machen würde. Eine interessante Frage wäre, was passiert, wenn ein unwissentlich das Patent verwendende Programm unter die GPL gestellt würde. Wäre dann der Autor für den Schaden haftbar, der dadurch entsteht, dass das Patent jetzt unter GPL steht? Tut es das überhaupt? Muss es entfernt werden? Aber dafür gibt es leider noch keine Präzedenzfälle. Ich persönlich glaube, dass der erste, der eine Patentverletzung einzu­klagen versucht, welche die Verbreitung von Linux unmöglich machen würde, mit einer sehr starken öffentlichen Reaktion rechnen muss.

Paragraph 8 bringt noch den Trick, dass der Urheber des Programms bestimmte geographische Regionen als Verbreitungsgebiet ausschließen darf, wenn in diesen Regionen ein Patentschutz o.ä. besteht, den sein Programm verletzen würde. Es wurde wahrscheinlich damit gerechnet, dass sich die Entwickler-Gemeinde und die Endbenutzer nicht um diese Beschränkung kümmern, aber sie stellt doch ein gewisses Problem dar, weil die GPL-Software (und ev. darauf aufbauende Distributionen) plötzlich nicht mehr überall völlig legal und frei wären, d.h. der Programm-Fundus mit derart eingeschränkten Programmen „kontaminiert“ würde.

Die GPL wird von der Free Software Foundation gewartet und eventuell verändert, wobei der ursprüngliche Geist erhalten bleiben wird. Laut Paragraph 9 hat jeder Lizenznehmer das Recht, die im Programm angegebene Version oder jede spätere als hier zutreffend anzusehen.

Der Paragraph 10 beinhaltet den Hinweis, das man, falls man das Programm in einem andersartig lizenzierten freien Programm verwenden will, vom Autor unter Umständen die Erlaubnis dazu bekommt. Meiner Ansicht nach hat der Autor jedoch, der ja immer noch das Copyright hält, auch die Möglichkeit, einer Firma die kommerzielle Verwendung/Weiterentwicklung seines Codes zu erlauben (siehe auch 5). Der schon unter der GPL veröffentlichte Code bliebe jedoch frei.

Die letzten beiden Paragraphen sollen die Programmierer/Verbreiter vor Regressansprüchen schüt­zen. In Paragraph 11 wird, mit der Begründung, dass das Programm ja kostenlos lizenziert wird, jegliche Gewähr­leistung ausgeschlossen und ausdrücklich gesagt, dass die Software noch Fehler enthalten kann. In Paragraph 12 wird für jeden, der das Copyright hält, oder das Programm unter der GPL verändert oder weitergibt, die Haftung für Schäden gleich welcher Art ausgeschlossen, falls dies nicht gesetzlich verboten ist oder schriftlich die Haftung zugesichert wurde.

Unterhalb des Textes der Lizenz sind noch Hinweise zu finden, wie man sein eigenes Programm unter die GPL stellt: Jede Quelldatei sollte eine Copyrightzeile enthalten, sowie einen (vorgegebenen) Text mit Verweis auf die GPL, und wie man diese einsehen kann. Die letzte Zeile gibt noch einen Hinweis auf die Library GPL, die eine leicht andersartige Lizenz darstellt, und auf die ich im nächsten Abschnitt eingehen werde.

Schließlich ist es noch interessant, welche Teile in Linux denn der GPL unterliegen. Seit einiger Zeit ist dies sogar der Kernel! Linus B. Torvalds behielt sein Copyright, veröffentlichte den Kernel aber unter der GPL. Linus hat übrigens auch in Europa die Markenrechte an Linux (Deutsche Marke 2088936, EU Markenanmeldung 000851246). 1998 befand ein großer Linux-CD-Distri­butor, dass ca. 28% des Sourcecodes vom GNU-Projekt stammten5, also unter GPL stehen. Die restlichen Programme stehen meist auch unter der GPL, manchmal unter der LGPL oder unter der BSD-Lizenz. Prominente GPL-Vertreter sind zum Beispiel der Compiler GCC, GNU Emacs, die Bourne Again Shell (BASH), GNU tar, GDB und GNU Make, oder die Oberflächen GNOME und KDE (ursprünglich war KDE nicht unter GPL, deshalb wurde GNOME ins Leben gerufen).

Die GPL kann übrigens auch auf andere Werke als Software angewandt werden (laut Paragraph 0), und es haben sich schon erste alternative Felder aufgetan. So z.B. das GNUsic-Projekt5, das in Japan gestartet wurde, und Musikstücke unter die GPL stellt, damit sie jeder verwenden kann55. Eine erste CD ist auch schon zu kaufen beziehungsweise steht zum Download bereit.

2.2 Lesser GPL (LGPL)

Die Lesser GPL5 der Free Software Foundation ist eine Variante der GPL. Sie erlaubt es, proprietäre Software mit dem Programm zu linken, daher kommerzielle Anbieter können auf den Funktionen der unter LGPL stehenden Bibliothek aufbauen. Früher hieß sie Library GPL, aber das suggerierte, dass sie für alle Bibliotheken zu verwenden sei, was nicht im Interesse der Autoren und der FSF lag. Zum Beispiel wurde ein proprietäres Programm nur deshalb ganz unter die GPL gestellt, damit es GNU Readline, eine GPL-Bibliothek welche Kommandozeilen-editieren für die BASH erlaubt, verwenden konnte. Die LGPL selbst war nur für spezielle Fälle, wie zum Beispiel die GNU C Bibliothek gedacht. GNU C war der einzige C-Compiler für Linux, und proprietäre Software hätte unter Linux dann nicht kompiliert werden können, was von der Verwendung von Linux abgeschreckt hätte. Deshalb wurde der Compiler unter die weniger restriktive LGPL gestellt.

Es muss also Fallweise zwischen den beiden Lizenz-Spielarten unterschieden werden. Laut den Autoren5 ist die LGPL hauptsächlich für den Fall gedacht, dass eine freie Bibliothek Funktionen zur Verfügung stellt, die für proprietäre Software aus anderen Quellen leicht verfügbar wäre. In diesem Fall würde es keinen Vorteil bringen, die Bibliothek nur freier Software zur Verfügung zu stellen (unter GPL); Die LGPL hingegen würde Hersteller proprietärer Software ermutigen, die Bibliothek zu nutzen und zu verbreiten.

Im Folgenden werden noch kurz einige Paragraphen angesprochen, die sich der GPL gegenüber signifikant unterscheiden.

In Paragraph 0 wird „der gesamte Sourcecode“ exakter definiert als „all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library“, um die Verbreitung sämt­licher Quellen sicherzustellen und Modifikationen leichter zu machen.

Paragraph 2, der die Modifikation des Codes und die Weitergabe erlaubt, hat eine zusätzliche Erfordernis: Falls die Bibliothek sich auf eine Funktion bezieht, die von einer Anwendung zur Verfügung gestellt wird, so muss die Bibliothek auch in dem Fall noch funktionieren, dass die Anwendung die Funktion eben nicht besitzt. Damit wird verhindert, dass Bibliotheken unter der GPL von proprietärer Software abhängig werden. In Paragraph 3 wird darauf hingewiesen, dass man diese Bibliothek auch unter der GPL veröffentlichen könnte.

Ein Werk, dass eine LGPL-Bibliothek benutzt, also dazu vorgesehen ist, mit ihr gelinkt oder kompiliert zu werden, ist laut Paragraph 5nicht selbst unter der LGPL. Das ändert sich jedoch beim linken selbst, die ausführbare Software ist dann wieder unter der LGPL. Es werden auch noch zwei feine Abgrenzungen genannt, die das neue Programm unter die Lizenz stehen oder von ihr befreien, aber die Grenzen sind schwammig und sind „not precisely defined by law“.

Einen Schritt zurück geht es in Paragraph 6: Auf einer LGPG-Bibliothek basierende Arbeiten dürfen unter einer Lizenz eigenen Wunsches veröffentlicht werden, falls sichergestellt ist, dass die Lizenz Veränderungen durch den Benutzer zur eigenen Verwendung erlaubt und auch das Reverse Engineering zum Debuggen solcher Ände­rungen nicht verbietet. Der Sourcecode muss wieder (auf eine von fünf Arten) mitgeliefert werden.

Paragraph 7 gibt die Erlaubnis, eine LGPL-Bibliothek mit einer anders lizenzierten zu einer einheitlichen Bibliothek zusammenzufassen, falls die beiden von auch getrennt zur Verfügung gestellt werden.

Der Rest der Lizenz entspricht der GPL. Am Ende findet man ebenfalls wieder eine Anleitung, um eigene Bibliotheken unter die LGPL zu stellen.

2.3 GNU Free Documentation License (FDL)

Die FDL5 der Free Software Foundation soll eine große Lücke in kostenlosen Betriebssystemen (wenn schon nicht in den kommerziellen) schließen: Es gibt zwar viele Programme, doch diese sind nicht ausreichend dokumentiert. Ein Paradebeispiel ist Perl, gute Bücher darüber gibt es eigentlich nur bei O`Reilly, und dort sind sie nicht frei 5. Andererseits ist eine vorhandene Doku­mentation ein Knackpunkt, um ein Programm weiter­entwickeln zu können, da Verbes­serungen ins Handbuch aufgenommen werden sollten, um nicht zu einem kom­pletten Chaos zu führen, wie jeder Informatiker wissen sollte. Andererseits muss nicht die gesamte Anleitung frei sein, es genügt, wenn die technischen Kapitel ange­passt werden können.

Nun werden die wichtigen Abschnitte der FDL vorgestellt, um zu zeigen, wie sie die oben erläuterten Ziele erreicht:

In der Präambel wird gleich zu Anfang klargestellt, dass diese Lizenz das Copyleft zum Ziel hat. Der Abschnitt 1 macht einige Definitionen, er klärt Begriffe wie „Modifizierte Version“, „Unveränderbare Sektionen“, „Titelseite“ oder „Transparente Kopie“. Letzteres heißt, dass das Exemplar in einer maschinenlesbaren Form vorliegt, deren Spezifikationen offengelegt sind. Damit wird offensichtlich auf die langsam erscheinenden proprie­tären E-Book-Formate abgezielt. Interessant ist, dass nur sogenannte „Sekundäre Sektionen“ als unveränderbar lizenziert werden können; sie befassen sich ausschließlich mit der Beziehung des Autors zum allgemeinen Thema des Dokuments, enthalten also zum Beispiel einen historischen oder philosophischen Bezug.

Abschnitt 2 lässt wörtliche Kopien des Werkes zu, allerdings müssen sie auch unter der FDL stehen, und es dürfen keine technischen Maßnahmen ergriffen werden, um die Verbreitung und das Lesen weiterer Kopien einzuschränken.

Abschnitt 4 gibt die Erlaubnis, modifizierte Kopien des Dokuments zu machen und zu verbreiten, sprich das Werk weiterzuentwickeln. Die verbreitete Version muss auch wieder komplett unter die FDL gestellt werden, außerdem müssen 14 Punkte beachtet werden. Diese stellen sicher, dass die ursprünglichen Autoren erkennbar sind, aber veränderte Werke nicht den Namen dieser Autoren missbrauchen können. Unveränderliche (invariante) Sektionen des Dokuments müssen wort­wörtlich erhalten bleiben. Wohlmeinende Äußerungen von Dritten zu dem Werk müssen aus ihm entfernt werden, da sie sich auf das ursprüngliche bezogen.

Die Abschnitte 5 und 6 erlauben das Zusammenfassen von Dokumenten, die unter dieser Lizenz stehen, beziehungsweise das Bilden von Sammlungen. Abschnitt 7 gibt die Möglichkeit, unabhängige Dokumente mit solchen unter der FDL auf einem Medium zu verbreiten, ohne dass sich jeweils die Lizenzierung ändert.

Abschnitt 8 erlaubt das Übersetzen und stellt es mit einer Modifikation auf den gleichen Rang. Unveränderliche Sektionen dürfen nur mit Genehmigung des Copyrightinhabers durch Übersetzungen ersetzt werden. Abschnitt 10 schließlich erlaubt, wie die GPL, nach Wunsch spätere Versionen der FDL als für dieses Dokument gültig anzusehen.

Die Lizenz enthält auch noch ausführliche Anweisungen darüber, wie die Cover zu gestalten sind. Diesen Aspekt habe ich aus Platzgründen vernachlässigt.

2.4 BSD license

BSD ist ein Betriebssystem, das aus A&T Unix entstand und an der University California Berkeley entwickelt wurde. Inzwischen gibt es die freien Varianten OpenBSD, PicoBSD, FreeBSD und NetBSD. Warum diese Lizenz 5 in einem Artikel über Linux auftaucht, liegt daran, dass einige Programme unter einer BSD-Lizenz in Linux eingesetzt werden. Alle vier Lizenzen sind bis auf die Wortwahl äquivalent 5, sie hatten nur alle ein Pro­blem, auf das noch eingegangen wird.

Die Lizenz ist im Gegensatz zu denen der Free Software Foundation kurz.1 Sie erlaubt die Weiterverteilung und Benutzung als Binary oder im Sourcecode, mit oder ohne Veränderungen, vorausgesetzt dass einige Bedingungen eingehalten werden. Die weitergegebenen Versionen müssen die ursprüngliche Copyrightzeile enthalten, und die Liste der Bedingun­gen. Außerdem darf der Name des Autors nicht ohne dessen schriftliches Einverständnis dazu benutzt werden, für das vom Code abgeleitete Produkt Werbung zu machen.

Es folgt ein Disclaimer, der von Seiten des Autors jegliche Garantien (implizierte und ausdrückliche) ausschließt und dessen Haftung für Schäden ausschließt, auch wenn er von der Möglichkeit solcher Schäden gewusst haben sollte.

Die Lizenz ist also wesentlich freier als die GPL, sie erlaubt die kommerzielle Weiterverwendung, darauf basierende Produkte dürfen proprietär sein. Unter BSD-Lizenz veröffentlichter Code darf also auch beliebig verändert und weitergegeben werden, so dass der Unterschied einer Glaubensfrage gleichkommt.

Allerdings hatte die BSD-Lizenz bis 1999 ein großes Problem: die Anzeigenklausel. Sie bestimmte, dass alle Werbematerialien, die Fähigkeiten oder die Benutzung der Software erwähnen, folgenden Satz enthalten: “ This product includes software developed by the University of California, Berkeley and its contributors.”5 Nun bereitet es ja keine größeren Schwierigkeiten, diesen Satz in jede Anzeige aufzunehmen. Nur war es so, dass Programmierer, welche ihre Software unter dieser Lizenz veröffentlichten, den in die Anzeige aufzunehmenden Satz auf ihren Namen umänderten. Das Ergebnis war, dass zum Beispiel NetBSD 75 solcher Sätze auflisten musste, und zwar schon 1997! Seit Juni 1999 verzichtet die University of California darauf, diese Klausel in ihren Lizenzen zu verwenden.

2.5 MIT / X Consortium license

Die Lizenz5 wurde ursprünglich vom X Consortium verwendet, und zwar bis zur Veröffentlichung von X11R6.3. Die nächste Version sollte als nicht-freie Software auf den Markt kommen. Dann jedoch über­gaben sie die X-Entwicklung der Open Group 5, die aufgrund von Protesten überlegte, X unter GPL zu stellen. Das XFree86-Projekt5, das mit XFree86 eine frei verteilbare Implementation des X-Windows-Systems herstellt, die auf Unix-Maschinen läuft, entschied sich jedoch plötzlich, keinen “copyleft” - Code anzunehmen, und die OpenGroup, oder genauer X.org, mussten X unter der bisherigen Lizenz veröffentlichen5.

Diese ist relativ kurz. Es wird jeder Person, welche die Software und die begleitende Dokumentation erhält, die kostenlose Erlaubnis erteilt, die Software zu verwenden, zu kopieren, modifizieren, verteilen, zu sublizenzieren und/oder Kopien zu verkaufen. Empfängern der Software können die gleichen Rechte eingeräumt werden. Insgesamt ist jedoch zu beachten, dass in allen (auch auszugsweisen) Kopien das ursprüngliche Copyrights und die Lizenz enthalten sind. Die Lizenz gilt hier jedoch nur für den übernommenen Teil!

Es folgt ein Disclaimer, der jegliche Garantien für die Software verneint und den Copyrightinhaber von jeglicher Haftung und anderen Ansprüchen freispricht, die in Verbindung mit der Software entstehen könnten. XFree und die Open Group haben zur MIT-Lizenz noch den Hinweis hinzugefügt, dass ihre Namen nicht ohne ihr schriftliches Einverständnis benutzt werden dürfen, um damit zu werben oder die Verbreitung der Software zu erhöhen.

2.6 Perl Artistic License

Der prominenteste Vertreter von Programmen, die unter der Artistic License5 stehen, ist Perl von Larry Wall, deshalb PerlArtistic License.

Laut der Präambel soll die Lizenz dem Copyrightinhaber eine Art “artistische”/Künstlerische Kontrolle über die Entwicklung des Codes/des Packages erlauben und trotzdem eventuellen Benutzern das Recht einräumen, die Software zu kopieren, weiter­zu­ver­treiben und sogar zu ändern. Die Lizenz kommt vom Umfang fast an die GPL heran und ihrem Zweck der Entwicklungs-Kontrolle recht nahe.

Sie beginnt mit einigen Definitionen, die hier übersprungen werden. Sofern nötig, werden sie später noch kurz erläutert. Die Standard-Version (also die vom Autor herausgegebene, die nur von ihm autorisierte Änderungen enthält), darf laut Nummer 1 kopiert und weitergegeben werden, sofern “you duplicate all of the original copyright notices and associated disclaimers.”

Laut Nummer 2 dürfen Fehlerbehebungen, Kompati­bilitäts­verbesserungen und andere Änderungen ange­bracht werden, sofern sie aus der Public Domain oder vom Autor stammen. Die resultierende Version heißt dann immer noch Standard-Version. Die Software bleibt dadurch frei verfügbar. Kritisch ist nur, dass die Annahme gemacht wird, Verbesserungen aus der Public Domain seien wirklich solche, da das Resultat als Standard-Version immer noch unter dem guten Namen des Autors steht.

Mit Nummer 3 wird erlaubt, das Package in jeder Weise zu verändern, vorausgesetzt, dass in jede Datei ein deutlicher Hinweis aufgenommen wird, wann und wie diese geändert wurde. Darüber hinaus dürfen die veränderten Programme entweder nur in der eigenen Firma oder Organisation benutzt oder müssen frei verfüg­bar gemacht werden (zum Beispiel indem man sie in die Public Domain stellt. Auf jeden Fall dürfen keine Entgelte für das Programm selbst, höchstens für das Kopieren verlangt werden.). Es gibt auch die Möglichkeit, veränderten Versionen andere Namen zu geben und die Unterschiede in einer Extraseite des Handbuches zu beschreiben. Entscheidend ist, dass ich alle Veränderungen dokumentieren muss, selbst wenn ich sie nur auf meinem eigenen Computer benutze!

Aufbauend darauf, darf laut Nummer 4 das Package in Objekt-Kode oder als Executable verbreitet werden, falls auf eine von drei Arten sichergestellt ist, dass Änderungen gegenüber der Standard-Version für den Empfänger klar erkenntlich sind. Auch muss der Sourcecode bezogen werden können. Wie bei Nummer 3 gibt es die Alternative einer gesonderten, anders­lautenden Vereinbarung mit dem Copyright-Inhaber.

Nummer 5 gibt das Recht, das Package zusammen mit anderen in einer Distribution zu vertreiben, sogar gegen jedwede Gebühr, solange ich das Package zusammen nicht als meine eigene Arbeit ausgebe. Allerdings muss das Interface der ursprünglichen Software laut Nummer 8 vor dem Benutzer verborgen werden.

Skripte und Bibliotheken, die als Input für das Package genutzt werden oder dessen Output darstellen, fallen laut Nummer 6 nicht unter diese Lizenz. Das gleiche gilt (Nummer 7) für Subroutinen in anderen Sprachen, die benutzt werden, um bestimmte Subroutinen des Packages zu emulieren.

Die Bestimmungen in Nummer 9 und 10 sind schon bekannt, sie verbieten das Bewerben des Produkts mit dem Namen des Autors und schließen alle Garantien aus, interessanterweise jedoch nicht die Gewährleistung.

Insgesamt hat der Autor die Kontrolle über seinen Code, aber Weiterentwicklungen sind möglich, sie müssen nur nachvollziehbar sein. Der kommerziellen Verwendung des Package steht wenig entgegen. Überdenkenswert scheint mir lediglich Nummer 2 zu sein, wo Modifika­tionen im Namen des Autors vorgenommen werden könnten. Die Lizenz ist ausdrücklich für (Sprach)Biblio­theken optimiert und zugeschnitten, was sie an manchen Stellen ziemlich technisch werden lässt.

2.7 Q Public License

Die Qt-Bibliothek der Norwegischen Firma TrollTech steht unter der QPL5. Qt wird unter anderem dazu benutzt, um KDE zu entwickeln. Diesbezüglich hat TrollTech auch noch ein spezielleres Abkommen mit den Entwicklern dieser Oberfläche5. Ursprünglich war Qt nicht frei, aber im November 1998 entschied sich TrollTech für eine neue Lizenz, unter anderem weil vom GNU-Projekt eine Bibliothek namens “Harmony” geplant war, die Qt für KDE ersetzen sollte5. Eine “kommer­zielle Lizenz von Qt kostet NOK 9300,- pro Fenstersystem und Entwickler und erlaubt es, Qt zu verändern und mit Qt entwickelte Programme (auch ohne Quellcode) zu verkaufen”5.

TrollTech gibt die Erlaubnis, die Lizenz für eigene Produkte unter dem Namen QPL zu verwenden. Das anwendbare Recht und der Gerichtsstand dürfen angepasst werden (Oslo wäre auch ein wenig unpraktisch). Insgesamt darf das unter QPL stehende Qt kopiert und verbreitet werden (Artikel 2). Modifikationen müssen in Form von Patches geschehen (Artikel 3), bei Verbreitung den Sourcecode enthalten und auch unter dieser Lizenz stehen.

Interessant ist eigentlich nur der Artikel 6, der sich damit befasst, was mit Qt (allgemein: QPL-lizenzierte Pro­gramme) benutzenden (linked) eigenen Programmen geschieht: Die Programme dürfen eine eigene Lizenz besitzen und verbreitet werden, vorausgesetzt, dass alle Empfänger auch den Sourcecode einsehen können und die Empfänger sich verpflichten, die Software und Veränderungen inklusive Sourcecode weiterzugeben. Das heißt, die QPL ist keine echte OpenSource-Lizenz, da nur darauf aufbauende Programme frei sind, die Software selbst einer strikten Kontrollen durch die Herstellerfirma unterliegt, die sogar darum bittet, von jedem mit Qt geschriebenen Programm ein Exemplar auf ihren FTP-Server zu bekommen.

2.8 Apache Licence

Die Apache-Lizenz5 wird, wie der Name schon sagt, für den Apache-Webserver verwendet. Ob ihrer offenen Art gibt es von diesem aber auch schon kommerzielle, proprietäre Varianten wie Stronghold. Die Apache Software Foundation (vormals Apache Group)5 will haupt­sächlich sicherstellen, in vom Programm abgeleiteter Software namentlich erwähnt zu werden.

Im Detail muss eine, verändert oder unverändert, verbreitete Version den Copyright-Hinweis sowie die Lizenz enthalten (Nummer1 und 2). Außerdem haben sie, genau wie Werbung dafür, einen Hinweis auf die zu Grunde liegende Apache-Software und einen Link zur ApacheGroup Webseite zu enthalten(Nummer 6).

Vom Apache-Server abgeleitete Produkte dürfen ohne schriftliche Genehmigung nicht das Word „Apache“ enthalten oder damit beworben werden(Nummer 5). Natürlich werden am Schluß noch alle Garantien verneint sowie (bei einem Web-Server verständlich) ausführlich jegliche Haftung ausgeschlossen.

Die Lizenz krankt natürlich, wie die ursprüngliche BSD-Lizenz, daran, dass die Liste der inkorporierten Software bei Werbeanzeigen irgendwann sehr lang wird.

2.9 Netscape Public License (NPL)

Der Communicator Source Code wurde von Netscape unter die NPL5 gestellt. Diese ist zwar OpenSource, aber nicht Copyleft. Außerdem gibt es noch einige andere Einschränkungen5.

Die NPL beginnt mit einigen Definitionen, von denen zwei wichtig sind: “Größeres Werk” (“Larger Work”) meint ein Werk, welches NPL-Code mit eigenem Code kombiniert. “Modifikationen” heißen, wenn der Code als Serie von Dateien veröffentlicht wird, alle Hinzu­fügungen zu einer Datei die NPL-Code enthält, oder alle Dateien die Teile von NPL-Code enthalten.

In Nummer 2 wird das Recht eingeräumt, den kompletten Kode weiterzuverbreiten, auszuführen und zu kopieren. Patentrechte von Netscape werden dadurch nicht berührt. In Nummer 3 und 7 wird gefordert, dass die veränderten Versionen wieder der NPL unterliegen, und mit dem Sourcecode verbreitet werden müssen. Alle Änderungen, die vorgenommen wurden, müssen in einer extra Datei dokumentiert werden.

Netscape wird von Zeit zu Zeit die NPL ändern, und der Benutzer kann die neue Lizenz auf NPL-Code anwende, wenn er will. Will man die NPL für eigene Programme benutzen, so darf der Text nicht geändert werden, oder der Name NPL kann nicht benutzt werden.

Natürlich werden in Nummer 7 noch alle Garantien verneint. Für Schäden muss allein der Endbenutzer auf­kommen. Der Gerichtsstand wird mit Kalifornien fest­gelegt.

Nummer 3.7 erlaubt es, die NPL-Software zu erweitern, und die Änderungen proprietär zu halten, einfach indem im NPL-Programm neue Subroutinen-Aufrufe hinzu­gefügt werden, die Routinen selbst aber als ein „Größeres Werk“ in einer separaten Datei untergebracht werden und nicht der NPL unterliegen. Das macht die Lizenz inkompatibel mit der GPL, die verlangt, dass aller abgeleiteter oder gelinkter Code wieder unter der GPL (NPL) steht.

Außerdem gibt es dann noch die sogenannten Amen­dments, wo sich Netscape in den Sektionen 5.2 und 5.3 ziemlich viel herausgenommen hat. Diese Abschnitte ermöglichen es der Firma, Code, der von irgend jemandem als Erweiterung zum Communicator geschrieben wurde, als kommerzielles Produkt, das nicht unter der NPL steht, weiterzuverwenden.

Insgesamt ist die Lizenz unübersichtlich und verflochten gestaltet und schwer zu verstehen. Man hat den Eindruck, dass verschiedene Formulierungen nur dazu vorhanden sind, den Inhalt zu verschleiern, was auch die vielen Definitionen am Anfang nahelegen. Lizenzen wie BSD oder GPL drücken sich klarer aus.

Die Mozilla Public License (MPL)5 ist übrigens nichts anderes als die NPL ohne die Amen­dments.

2.10 Weitere Lizenzen

Damit sind sicherlich noch nicht alle Lizenzen abgedeckt, die bei Programmen unter Linux Verwendung finden, aber die wichtigsten wurden besprochen.

Erwähnenswert sind vielleicht noch die Sun Community Source License unter der StarOffice steht55, die IBM Public License5, die Python license5, die zlib/libpng license5, die LaTeX Project Public License oder die Apple License (APSL, siehe auch 5).

Eine Übersicht mit Kommentaren findet sich auch unter5.

3. OpenSource oder nicht?

Der Begriff OpenSource wurde 1998 von einer Gruppen aufgebracht, der auch Eric Raymond angehörte. Durch den gewollten zeitlichen Zusammenhang mit der Ankündigung von Netscape, den Sourcecode ihres Browsers freizugeben, kam es zu einem großen Medien­echo und einer schnellen Verbreitung des Begriffs. Es wurde versucht, ein Trademark für den Begriff einzutragen (was 1999 aus formaljuristischen Gründen scheiterte), und opensource.org ging ans Netz5.

Auf der Grundlage von Debians Free Software Guidelines5 wurde die Definition von OpenSource festgelegt5. Außerdem wurde ein Zertifizierungs-Programm ins Leben gerufen5, welches für Program­me und Distributionen das Label “ OSI Certified Open Source Software” vergibt. Dazu wird von der Open Software Initiative eine Liste5 mit Lizenzen heraus­gegeben, welche mit der Definition übereinstimmen. Ein Programm darf dann vom Autor mit dem Label geschmückt werden, falls es ausschließlich unter einer oder mehreren solcher gelisteten Lizenzen steht.

Nun aber die offizielle Definition von OpenSource5: In Nummer 1 wird gefordert, dass die Software frei weiterverbreitet werden darf, auch zusammen mit anders lizenzierter und auch gegen Bezahlung. Der Sourcecode muss immer verfügbar sein (Nummer 2), wird er nicht mitgeliefert, soll er gegen Eigenkostenerstattung zu beziehen sein. Es wird explizit verboten, den Code unüber­sichtlich zu gestalten. Veränderungen am Programm sollen gestattet sein, und die neue Version muss unter der gleichen Lizenz weiterverbreitet werden können (Nummer 3). Das soll sicherstellen, dass eine peer review genauso möglich ist wie eine schnelle Weiter­entwicklung. Die Verbreitung des modifizierten Kodes darf dahingehend beschränkt werden, dass Änderungen in separaten Patch-Dateien geliefert werden, und das ursprüngliche Programm unangetastet bleibt. Auch darf verlangt werden, veränderten Programmen andere Namen zu geben(Nummer 4). Dieser Absatz erinnert an die Artistic License; dem Autor wird die Möglichkeit gegeben, seinen Ruf zu schützen, der Benutzer weiß, wer eine Änderung verbrochen hat. Es dürfen keine Personengruppen diskriminiert werden (Nummer 5), was auf die bekannten Exportbeschränkungen der USA abzielt; OpenSource – Programme dürfen keine solchen Beschränkungen in ihrer Lizenz enthalten, höchstens zum Beispiel darauf hinweisen, dass die Software laut Gesetz nicht in bestimmte Gebiete verbreitet werden dürfte. Auch dürfen keine “Zielfelder” diskriminiert werden, daher die kommerzielle Verwendung muss möglich sein (Nummer 6). Weitere Empfänger dürfen nicht zu non-disclosure-Vereinbarungen oder ähnlichem gezwungen werden (Nummer 7). Die mit dem Programm verbundenen Rechte “must not depend on the program's being part of a particular software distribution”(Nummer 8). Daher, Programme die als Teil einer kommerziellen Zusammen­stellung vertrieben werden, sind auch außer­halb dieser OpenSource und können von der ganzen Gemeinschaft benutzt werden. An Software, die zusammen mit dem Programm verbreitet wird, dürfen keine Anforderungen bezüglich der Lizenz gestellt werden. Es ist Anzumerken, dass die GPL sich trotzdem als OpenSource qualifiziert, da ihr viraler Effekt nur für Software gilt, die Teile von GPL-Programmen benutzt.

Bis jetzt (April 2000) wurden die folgenden besprochenen Lizenzen in die OSI-Liste aufgenommen: wie schon erwähnt die GPL, die LGPL, BSD-license, MIT license, Artistic license, die MPL und die QPL. Die Apache license qualifiziert sich nicht, da sie in Nummer 2 die Weitergabe von Executables ohne Sourcecode erlaubt.

Einige Leute, wie zum Beispiel Richard Stallman, finden den Begriff OpenSource unglücklich gewählt 5, sie bevorzugen weiterhin FreeSoftware im Sinne der GPL. Die offiziellen Definitionen liegen zwar nicht weit auseinander, aber als OpenSource zählen für jemanden, der sich nicht näher damit beschäftigt hat, alle Programme, deren Quellcode er einsehen kann. Das heißt aber lange noch nicht, dass Modifikationen oder gar die Weitergabe der Software erlaubt sind, wie man am Beispiel des Programms Xv sehen kann. Anderer­seits macht das Wort Free viele Manager, die dabei an kostenlos und nichts damit verdienbar denken, nervös, was einen harmloseren Begriff nötig erscheinen ließ.

Die OpenSource-Bewegung insgesamt hat schon beträchtliche kommerzielle Erfolge erzielt. Sieht man das Internet als das Ergebnis einer Entwicklung mit freien Standards und Programmen (Apache und Sendmail im Rückgrat des Netzes), so hat dies den Boden für eine Milliardenschwere Industrie der InternetServiceProvider und kommerzielle Webseiten wie Yahoo ermöglicht. Auch werden durch freie Software neue Formen von Dienstleistungen möglich, und Firmen wie RedHat etablieren sich, stellen ihre Software sogar komplett unter die GPL und verdienen nur am Service. Ein etwas anderer Ansatz ist das Verfahren, den Sourcecode und das Programm zur nicht kommerziellen Nutzung freizugeben, sonst aber Geld zu verlangen, wie es etwa bei dem GhostScript-Paket inzwischen der Fall ist.

Das Hauptargument für freie Software ist natürlich, dass dadurch bessere Programme entstehen, dass der Quell­code über das Internet von vielen Interessierten durch­gesehen wird, was Bugs ausmerzt. Weiterentwicklungen sind schnell möglich und stehen dann allgemein zur Verfügung. Hat jemand eine gute Idee oder ein spezifisches Problem, fängt er mit programmieren an und findet bald Helfer, er muss nicht auf einen Geldgeber warten, der erst eine Kosten/Nutzen Rechnung aufstellt. Diese Wirtschaftlichkeitsprüfungen gehen natürlich nicht sehr lange in die Zukunft, es hat sich jedoch gezeigt, dass das Potential wichtiger Ideen erst in einigen Jahren sichtbar wird. Das WWW wurde lediglich für eine nicht marktrelevante Gruppe entwickelt, nämlich für Atom­physiker.

Freie Software könnte auch als ein Ergebnis der fortschreitenden Globalen Vernetzung und der Zusam­men­­arbeit gesehen wurden. Ihre jetzige Position errichte sie ja durch das weltweite Internet als Medium. Auch steht sie genau genommen in der westlichen Tradition der Wissenschaft, die neue Erkenntnisse an alle Interessierten weiterverbreitete (meistens jedenfalls).

Ein interessanter Artikel zu diesem Thema ist von Tim O`Reilly5; Richard Stallman nimmt im Bezug auf Freie Software einen relativ fundamentalistischen Standpunkt ein5; Einen Überblick über die verschiedenen Arten von freier und nicht-freier Software5 gibt es bei der Free Software Foundation;

4. Lizenzen und Haftung

Nun ist es ja noch interessant zu wissen, ob ich als Autor freier Software irgendwann für Bugs in meiner Software zur Verantwortung gezogen werden kann, die durch einen dummen Zufall zu einem dreitägigen Produktions­stillstand bei BMW geführt haben.

Falls der eigene Name im Produkt nicht auftaucht, weil man (meistens in Verletzung der Lizenz, auch der GPL) auf die Dokumentation der Änderungen verzichtet hat, ist man natürlich fein raus. Für alle anderen Fälle werden jetzt einige Überlegungen5 angestellt, zu denen aber noch keine oder nur Widersprüchliche Gerichtsurteile vor­liegen. Es wird nur das deutsche Recht berücksichtigt, außerdem wird, wie schon erwähnt, nur freie Software betrachtet.

Als Haftungsgrundlage kommen Vertragshaftung, Produzentenhaftung oder Produkthaftung in Frage. Bei der Vertragshaftung könnten Ansprüche entstehen, die auf einem Vertrag beruhen, der abgeschlossen wurde, um die Software zu erlangen. Bei freier Software kann dies aber kein Kaufvertrag sein, da dieser eine beiderseitige Willenserklärung zum Verkauf des Programms voraus­setzt. Dienst- und Werkvertrag kommen auch nicht in Betracht, da eine Vereinbarung zum Erbringen einer Leistung oder eines Werkes vorliegen muss, die Software aber einfach so, ohne Anpassungen, verwendet wird. Miete und Leihe kommen schon eher in Frage, immerhin wird das Programm zur Nutzung “überlassen”. Allerdings ist es fraglich, ob der Software Sachcharakter zugesprochen werden kann, was Voraussetzung für die beiden Verträge ist. Miete kommt auch deshalb nicht in Frage, weil kein Mietzins vereinbart ist. Insgesamt kann also kein Vertrag gefunden werden, der das Verhalten im Umgang mit freier Software beschreibt. Und ohne Vertrag keine Vertragshaftung.

Die Produzentenhaftung kommt wahrscheinlich auch nicht in Frage. Sie ist Ausfluss des Vertrauensprinzips, das besagt, dass der Kunde davon ausgehen muss, dass er ein gekauftes Produkt gemäß seiner Bestimmung verwenden kann, ohne dabei um Leib und Leben fürchten zu müssen. In der Rechtsprechung hat sich nun herausgebildet, dass sich jeder Produzent, der ein gefähr­liches Produkt in den Verkehr bringt, und um die Gefährdung weiß, strafbar macht. Grundsätzlich sind davon auch Programmierer betroffen, jedoch ist es unwahrscheinlich, dass jemand wissentlich ein gefährliches Produkt in Umlauf bringt. Man sollte jedoch schon einen gewissen Aufwand auf das Eliminieren von Bugs verwendet haben.

Als letztes kommt noch die Produkthaftung in Frage. Sie besagt, dass auch bei nichtschuldhafter Schädigung von Personen oder Sachen eine Haftpflicht entsteht. Allerdings gibt es Ausnahmen. Zum Beispiel, wenn der Fehler nach dem Stand von Wissenschaft und Technik nicht erkannt werden konnte. Oder wichtiger, wenn “das Produkt weder für den Verkauf oder eine andere Form des Vertriebs mit wirtschaftlichem Zweck hergestellt noch im Rahmen [s]einer beruflichen Tätigkeit hergestellt oder vertrieben” wurde (§1, Abs. 2, Ziffer 3 ProdHaftG). Handelt es sich bei dem hergestellten Produkt also um ein nichtkommerzielles, das auch nicht von einer Firma produziert wurde, entsteht keine Haftpflicht. Anders sieht es jetzt bei kommerziellen Distributoren von freier Software aus. Diese fallen als Händler oder Importeure nämlich auch unter das Produkthaftungsgesetz, und können den obigen Haftungsausschluss nicht für sich in Anspruch nehmen. Sie könnten höchstens noch argumentieren, dass die Software überhaupt kein Produkt ist, das ganze Gesetz also keine Anwendung finden kann. Eindeutige Entscheidungen fallen hier schwer. Es gibt allerdings eine Auffassung, wonach in Auftrag entwickelte Software nicht als Produkt anzusehen ist, Standardsoftware schon. Und angesichts der Verbreitung freier Software muss diese fast als Standardsoftware angesehen werden, was die Distributoren somit nicht aus ihrer Verantwortung entläßt.

Festzuhalten bleibt, dass Autoren freier Programme nicht damit rechnen müssen, für Schäden haftbar gemacht zu werden, solange sie die Software sorgfältig erstellt haben.



Anmerkungen: Im amerikanischen ist sowohl „license“ als auch (ungebräuchlicher) „licence“ eine korrekte Schreib­weise; Die Begriffe Programm, Software, Code und Package wurden in diesem Artikel synonym benutzt; Einige Zitate aus Lizenzen erfolgten in Englisch, um die ursprüngliche Formulierung orginalgetreu zu erhalten.

5. QUELLEN

Angaben in Klammern sind Bemerkungen des Autors.

  1. Kalle Dalheimer, „KDE-Programmierung, Linux für alle!“, Linux-Magazin 11/1997, (Guter Artikel zu KDE und Qt)

  2. Robert Gehring, “ Shareware, Freeware und Public Domain III, Software und Haftungsrecht”, 1997 Linux Magazin

  3. Patrick Goltzsch, „Musikalische Viren“, Telepolis 1999, http://www.heise.de/tp/deutsch/inhalt/musik/2711/1.html

  4. Patrick Goltzsch, “Open Source; Apple macht sich frei?”, Spiegel Online, 31. März 1999, http://www.spiegel.de/netzwelt/technologie/0,1518,15341,00.html

  5. Martin Hufner, „Jenseits des Eigentums – Zur Theorie des Copyleft“, Neue Musikzeitung, Ausgabe 6/99

  6. Michael Maxwell, “Restrictively Unrestrictive: The GPL License in Software Development”, 1998, http://www. daemonnews.org

  7. Tim O`Reilly, „Schlüsse aus der Open-Source-Software-Entwicklung“, Juli 1999, http://www.heise.de/tp/deutsch/special/wos/6433/1.html

  8. Richard Stallman, „Free Software and Free Manuals“, http://www.gnu.org/philosophy/free-doc.html

  9. Richard Stallman, „Linux and the GNU Project, http://www.gnu.org/gnu/linux-and-gnu.html

  10. Richard Stallman, „On the Netscape Public License“, http://www.gnu.org/philosophy/netscape-npl.html

  11. Richard Stallman, “The gnu projekt”, http://www.fsf.org/gnu/the-gnu-project.html

  12. Richard Stallman, „The X Windows Trap“, http://www.gnu.org/philosophy/x.html

  13. Richard Stallman, “ Why ``Free Software'' is better than ``Open Source''”, http://www.gnu.org/philosophy/free-software-for-freedom.html

  14. Richard Stallman, „Why Software Should Be Free“, April 1992, http://www.gnu.org/philosophy/ shouldbefree.html

  15. Richard Stallman, „Why you shouldn't use the Library GPL for your next library“,Februar 1999, http://www.gnu.org/philosophy/why-not-lgpl.html

  16. Apache Software Foundation (vormals Apache Group) http://www.apache.org/foundation/FAQ.html#what

  17. Categories of Free and Non-Free Software”, http://www.gnu.org/philosophy/categories.html

  18. Leserkommentar „Choose GPL if you want to make some money“ zum Artikel „Toward the Encouragement of Copyleft and the GPL“, http://www.linuxtoday.com/stories/6641.html

  19. Die Debian-Richtlinien für freie Software“, http://www.de.debian.org/social_contract#guidelines

  20. Das GNUsic-Projekt, http://www.gnusic.net/

  21. History of the Open Source Initiative“, http://www.opensource.org/history.html

  22. The Open Group, http://www.opengroup.org

  23. The Approved Licenses“, http://www.opensource.org/licenses/

  24. The BSD License Problem“, http://www.gnu.org/philosophy/bsd.html

  25. The Open Source Definition“, http://www.opensource.org/osd.html

  26. The OSI Certification Mark and Program“, http://www.opensource.org/certification-mark.html

  27. Various Licenses and Comments about Them”, http://www.gnu.org/philosophy/license-list.html

  28. What is SCLS?”, http://www.sun.com/microelectronics/communitysource/whatisSCSL.html

  29. The XFree86 Project Inc.“, http://www.xfree86.org/

  30. Die Apache Lizenz, http://www.apache.org/docs/LICENSE

  31. The Artistic License, http://www.perl.com/language/misc/Artistic.html

  32. Berkley/BSD-Lizenz, http://www.xfree86.org/3.3.3/COPYRIGHT5.html

  33. Offizielle General Public Licence der FSF, http://www.gnu.org/copyleft/gpl.html

  34. Offizielle GNU Free Documentation License der FSF, http://www.gnu.org/copyleft/fdl.html

  35. Offizielle GNU Lesser General Public License der FSF, http://www.gnu.org/copyleft/lesser.html

  36. IBM Public License, http://www.research.ibm.com/jikes/license/license3.htm

  37. The KDE Free Qt Foundation Agreement“, http://www.trolltech.com/kde-freeqt/index.html

  38. Mozilla Public License, http://www.mozilla.org/MPL/MPL-1.0.html

  39. Netscape Public License, http://www.mozilla.org/MPL/NPL-1.0.html

  40. Python license, http://www.python.org/doc/Copyright.html

  41. The Q Public License, Troll Tech AS, Norwegen, http://www.trolltech.com/qpl/

  42. Sun Community Source License Principles, http://www.sun.com/981208/scsl/principles.html

  43. XFree86 Copyright“ für Version 3.3.3, http://www.xfree86.org/3.3.3/COPYRIGHT1.html#1

  44. zlib/libpng license, http://www.opensource.org/licenses/zlib-license.html

1 Es gab gegen die FSF auch schon den Vorwurf, sie mache die Vereinbarungen so umfangreich, damit sie niemand komplett durchlese.