von Richard Stallman | 1998-03-10/12
Dieser Text handelt vom Entwurf der Netscape Public License (NPL).
Die Netscape Public License (NPL) steht für einen ernsten Versuch, neue Freie-Software-Vertriebsbestimmungen zu entwerfen. Es ist ein interessanter Versuch, hat aber erhebliche Mängel, die behoben werden müssen. Ein Fehler ist so ernst, dass wir ihn dafür halten sollten, ein Programm unfrei zu machen. Die anderen haben unterschiedliche Konsequenzen: einer sendet eine schlechte philosophische Botschaft, während ein anderer ein größeres praktisches Problem für die Freie-Software-Gemeinschaft schafft.
Die NPL ist noch immer ein Entwurf und wird noch verändert werden. Ziel dieses Textes ist nicht sie anzugreifen und zu verurteilen, sondern zu Verbesserungen an der NPL anzuhalten. Soweit manche dieser Probleme, wenn Sie dies lesen, korrigiert worden sind, umso besser, und wir können jene hinfälligen Sachverhalte beiseite legen.
Das erste von mir in der NPL bemerkte Problem bestand darin, dass sie weder Netscape noch allen anderen die gleichen Rechte wie die GNU General Public License (GPL) gewährt. Gemäß NPL können Beitragende Netscapes Quellcode nur wie in der NPL angegeben nutzen, Netscape kann jedoch beigetragene Änderungen auf jegliche beliebige Weise nutzen ‑ sogar in proprietär lizenzierten Softwarevarianten.
Das Problem hierbei ist subtil, weil dadurch das Programm nicht unfrei wird. Es hält einen nicht davon ab, das Programm weiterzuverbreiten oder es zu ändern. Es versagt einem keine besondere Freiheit. Unter einem rein pragmatischen Gesichtspunkt betrachtet, mag es überhaupt nicht wie ein Problem aussehen.
Das Problem liegt in der tieferen in dieser Bedingung enthaltenen Botschaft. Sie versagt die Vorstellung von Zusammenarbeit unter Gleichgesinnten, auf die unsere Gemeinschaft beruht, und besagt, dass die Mitarbeit an einem freien Programm das Beitragen zu einem proprietären Softwareprodukt bedeutet. Die Einstellung derjenigen, die diese Bedingung akzeptieren, werden sich wahrscheinlich dadurch ändern, und die Änderung wird unsere Gemeinschaft nicht stärken.
Ein Lösungsvorschlag für diesen Mangel an Symmetrie ist, eine zeitliche Begrenzung zu setzen ‑ vielleicht drei oder fünf Jahre. Das würde eine bedeutende Verbesserung darstellen, weil das Zeitlimit die problematische tiefere Botschaft in Abrede stellen würde.
Die praktischen Auswirkungen dieser Bedingung werden von einem anderen Nachteil der NPL auf ein Minimum gebracht: sie ist nicht als eine umfassende Lizenz mit Copyleft konzipiert. Mit anderen Worten: sie versucht nicht wirklich dafür Sorge zu tragen, dass von Nutzern gemachte Modifizierungen als Freie Software verfügbar sind.
Die NPL hat die Form eines Copylefts. Sie besagt explizit, dass alle von Nutzern gemachten Modifizierungen unter der NPL freigegeben werden müssen. Dies bezieht sich jedoch nur auf Modifizierungen am vorhandenen Quellcode ‑ nicht jedoch auf hinzugefügte Unterprogramme, wenn sie in separaten Dateien gespeichert werden. In der Praxis bedeutet das, dass ‑ wenn man möchte ‑ es ganz einfach ist proprietäre Änderungen vorzunehmen: man schreibe den Großteil des Quellcodes in eine separate Datei und nenne die Zusammenstellung einfach ein größeres Werk. Nur die zu den alten Dateien hinzugefügten Unterprogrammaufrufe müssen unter der NPL freigegeben werden, und sie werden allein nicht sehr nützlich sein.
Der Mangel an eigentlichen Copyleft ist keine Katastrophe; es macht die Software nicht unfrei. Beispielsweise versuchen die XFree86-Vertriebsbedingungen nicht annähernd Copyleft umzusetzen, trotzdem ist XFree86 dennoch Freie Software. Berkeley Software Distribution (BSD) ist auch Freie Software ohne Copyleft (obwohl die älteren BSD-Bedingungen einen gravierenden Nachteil besitzen und nicht nachgeahmt werden sollten ‑ möchte man Freie Software ohne Copyleft freigeben, sollten stattdessen die XFree86-Bedingungen verwendet werden). Netscape-Software kann ebenso Freie Software sein, ohne mit Copyleft lizenziert zu sein
Obwohl dies nicht weiter katastrophal ist, ist es trotzdem ein Nachteil. Und weil die NPL aussieht wie eine Lizenz mit Copyleft, werden einige Nutzer möglicherweise davon irritiert sein und könnten die NPL übernehmen, in der Annahme, ihnen würden die Vorteile von Copyleft für ihre Software gewährt werden ‑ obwohl genau das nicht der Fall ist. Um dieses Ergebnis zu vermeiden, werden wir hart daran arbeiten müssen, um über ein Thema aufzuklären, das mit wenigen Worten nicht leicht zu erklären ist.
Das nächste Problem der NPL ist ein K.-o.-Kriterium: nimmt man eine Änderung vor, ist man verpflichtet diese zu veröffentlichen. Private Änderungen für den eigenen Gebrauch sind nicht zulässig; eine Änderung nur an ein paar Freunde weiterzugeben ist ebenso verboten.
Wenn wir über die Belange bezüglich Freie Software nachdenken, fokussieren wir uns normalerweise auf die Freiheit zu verteilen und modifizieren, weil dies das ist, was Softwareentwickler am häufigsten zu verhindern versuchen. Aber die Freiheit KEINE Kopie zu verteilen, wenn man nicht möchte, ist ebenso wichtig. Beispielsweise ist die Freiheit eine Modifizierung vorzunehmen und sie nicht irgendjemanden zu zeigen Teil dessen, was wir Privatsphäre nennen. Die Freiheit, die Modifizierung an wenige Freunde weiterzugeben, nicht aber (oder NOCH nicht) der Öffentlichkeit, ist noch dazu unerlässlich. (Ist das Programm frei, werden die Freunde natürlich frei sein es an andere weiterzugeben, wenn sie wollen ‑ aber sie müssen nicht.)
Das Korrigieren der NPL ist absolut notwendig um diese grundlegende Freiheit zu respektieren, und unsere Gemeinschaft muss nachdrücklich darauf bestehen. Es lohnt sich nicht eine wichtige Freiheit für ein zusätzliches Programm zu opfern, ganz gleich wie nützlich und spannend es auch sein mag.
Es gibt ein weiteres ernsthaftes Problem mit der NPL: sie ist mit der GNU GPL unvereinbar. Es ist unmöglich, NPL- und GPL-lizenzierten Quellcode in einem Programm miteinander zu kombinieren, nicht einmal durch Verknüpfung separater Objektdateien oder Bibliotheken. Ganz gleich wie das gelöst ist, es muss die eine oder die andere Lizenz verletzen.
Dieser Konflikt tritt auf, weil die GPL Copyleft ernst nimmt: sie wurde konzipiert, um sicherzustellen, dass alle Änderungen und Erweiterungen an einem freien Programm frei sein müssen. Damit hinterlässt sie kein Schlupfloch um Änderungen proprietär zu machen, indem man sie in eine separate Datei schreibt. Um dieses Schlupfloch zu schließen, erlaubt die GPL nicht, das mit Copyleft versehene Programm mit Quellcode zu binden, der andere Beschränkungen oder Bedingungen hat ‑ wie die NPL.
Mit der GPL unvereinbar zu sein, macht kein Programm unfrei; es wirft keine grundlegende ethischen Belang auf. Aber es wirft möglicherweise ein ernsthaftes Problem für unsere Gemeinschaft auf, die Quellcodebasis in zwei Sammlungen aufteilend, die nicht miteinander gemischt werden können. Aus praktischen Gründen muss dieses Problem gelöst werden.
Dies durch eine Änderung der GPL zu Lösen, ist möglich, aber das würde zur Folge haben. Copyleft aufzugeben ‑ was mehr schaden als nützen würde. Aber es ist möglich, dieses Problem mit einer kleinen Änderung in der NPL zu lösen [siehe unten für eine konkrete Lösungsmöglichkeit].
NPL steht für Netscape Public License, jedoch steht GPL nicht für „GNU Public License“. Der vollständige Name unserer Lizenz lautet GNU General Public License, kurz GNU GPL, mitunter auch ohne dem Wort GNU einfach nur GPL.
Da Probleme 3 und 4 die Ernstesten sind, hoffe ich, dass man Netscape die Wichtigkeit einer Lösung höflich und vernünftig veranschaulicht. Lösungen gibt es; sie müssen sich nur entscheiden sie zu benutzen. Es gibt Gerüchte, Netscape hätte sich entschieden Problem 3 zu korrigieren ‑ aber es sie wissen zu lassen, dass das für einen selbst wichtig ist, kann keinen Schaden zufügen. Es gibt kein Wort, dass sie planen Problem 4 zu korrigieren.
Nachfolgend eine Möglichkeit, um NPL- und GPL-lizenzierten Quellcode miteinander zu kombinieren, indem diese beiden Absätze der NPL hinzugefügt werden:
A.1. You may distribute a Covered Work under the terms of the GNU
General Public License, version 2 or newer, as published by the
Free Software Foundation, when it is included in a Larger Work
which is as a whole distributed under the terms of the same
version of the GNU General Public License.
A.2. If you have received a copy of a Larger Work under the terms of a
version or a choice of versions of the GNU General Public
License, and you make modifications to some NPL-covered portions
of this Larger Work, you have the option of altering these
portions to say that their distribution terms are that version or
that choice of versions of GNU General Public License.
[Auf eine Übersetzung wurde verzichtet.]
Dies ermöglicht, NPL- mit GPL-lizenzierten Quellcode zu kombinieren, und das zusammengeführte Werk unter den Bedingungen der GNU GPL zu vertreiben.
Es ermöglicht, Modifizierungen an solchen kombinieren Werken unter den Bedingungen der GNU GPL freizugeben ‑ aber am einfachsten ist sie unter der NPL freizugeben.
Wenn man den Nutzen aus A.2 zieht, werden diese Änderungen nur unter den Bedingungen der GNU GPL freigegeben. Diese Änderungen wären also für Netscape nicht greifbar, um sie in proprietäre Varianten einzusetzen. Es ist plausibel, dass Netscape dies als misslich betrachten würde.
Die NPL bietet Entwicklern proprietärer Software jedoch eine einfache Möglichkeit, gemachte Änderungen ganz und gar für Netscape unverfügbar zu machen: indem der eigene Quellcode in separate Dateien gespeichert wird und die Kombination ein größeres Werk nennt. In der Tat ist dies für sie leichter, als es A.2 für GPL-Benutzer ist.
Wenn Netscape meint, es könne mit den Umständen der (effektiv) proprietären Modifikationen leben, ist die Mühe GPL-lizenzierter Modifikationen im Vergleich sicherlich kleiner. Wenn Netscape glaubt, dass praktische Erwägungen den größten Teil der proprietären Softwarewelt ermutigen werden, ihre Änderungen ‑ ohne gezwungen zu werden ‑ zurück an Netscape zu geben, sollten die gleichen Gründe auch in der freien Softwarewelt gelten. Netscape sollte erkennen, dass diese Änderung akzeptabel ist, und, um Freie-Software-Entwickler nicht mit einem ernstzunehmenden Dilemma konfrontierend aus dem Wege gehen, übernehmen.