English [en]   Deutsch [de]   español [es]   français [fr]   Bahasa Indonesia [id]   Nederlands [nl]   polski [pl]   русский [ru]  

Associate members power up the Free Software Foundation. Help smash our goal of 700 new members or donate by December 31st!

Join

80.055 $
450.000 $

Dieses Werk ist eine Übersetzung aus dem Englischen.

Über die Netscape Public License

von Richard Stallman | 1998-10

Die erste Fassung dieses Textes, Über die Netscape Public License, wurde im März 1998 verfasst und handelte noch von deren Entwurf. Der erste verfasste Text betreffend Netscape und Freie Software handelte noch von der Erwägung, den Netscape-Internetbrowser zu Freie Software zu machen.

Die Netscape Public License (NPL) ist, wie sie letztlich im Jahr 1998 entworfen wurde, eine freie Softwarelizenz ‑ hat aber drei entscheidende Mängel: ein Mangel sendet eine schlechte philosophische Botschaft, ein weiterer rückt die Freie-Software-Gemeinschaft in eine ungünstige Position, während der dritte ein größeres praktisches Problem innerhalb der Freie-Software-Gemeinschaft schafft. Zwei der Mängel treffen ebenso auf die Mozilla Public License (MPL) zu. Wegen dieser Mängel halten wir dazu an, weder die NPL noch die MPL für Freie Software zu verwenden.

1. Nicht alle Nutzer sind gleich

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äß der 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 einen 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.

Bei der MPL besteht dieses Problem nicht. Das ist der wesentliche Unterschied zwischen MPL und NPL.

2. Keine Lizenz mit Copyleft

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; dadurch wird die Software nicht unfrei. Beispielsweise versuchen die X.Org-Vertriebsbedingungen nicht annähernd Copyleft umzusetzen, trotzdem ist X.Org 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 X.Org-Bedingungen verwendet werden). NPL-lizenzierte Software ist ebenso Freie Software ohne Copyleft, und dies allein stellt die NPL selbst nicht schlechter als jede andere freie Softwarelizenz ohne Copyleft.

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.

3. Nicht mit der GNU GPL vereinbar

Das gravierendste praktische Problem an der NPL besteht darin, dass sie nicht mit der GNU GPL vereinbar ist. 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, welcher andere Beschränkungen oder Bedingungen hat ‑ wie die NPL.

Mit der GPL unvereinbar zu sein, macht kein Programm unfrei, es wirft keine grundlegende ethische Frage auf. Aber es wirft möglicherweise ein ernsthaftes Problem für die Freie-Software-Gemeinschaft auf, die Quellcodebasis in zwei Sammlungen aufteilend, die nicht miteinander gemischt werden können. Aus praktischen Gründen ist dieses Problem sehr wichtig.

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

4. Eine Anmerkung bezüglich der Namen

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.

(Dies ist zwar kein Problem, nur eine Tatsache, die man wissen sollte.)

Fazit

Da Problem 3 das ernstzunehmendste ist, hoffe ich, dass man Netscape höflich und vernünftig die Wichtigkeit einer Lösung veranschaulicht. Lösungen gibt es, man muss nur entscheiden sie zu benutzen.

Nachfolgend eine Möglichkeit um NPL- und GPL-lizenzierten Quellcode miteinander zu verbinden, 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.

ZUM SEITENANFANG


FSF„Unsere Mission ist die Freiheit zu bewahren, zu schützen und zu fördern, um Rechnersoftware nutzen, untersuchen, kopieren, modifizieren und weiterverbreiten zu können und die Rechte von Freie-Software-Nutzern zu verteidigen.“

Die Free Software Foundation ist der organisatorische Hauptsponsor des Betriebssystems GNU. Unterstützen Sie das GNU-Projekt und die FSF durch den Kauf von Handbüchern und Kleidung, als assoziiertes Mitglied oder mit einer Spende direkt an die FSF oder via Flattr.