Wer auch immer mal drueberlesen will, hier ein Uebersetzungsvorschlag:
###### Von John Hunter als Antwort auf dieselbe Frage verfasst
Denken Sie darüber nach, Ihre Programme unter einer freizügigeren Lizenz zu veröffentlichen? Die meisten grundlegenden wissenschaftlichen Programmierwerkzeuge für Python (Scipy, Numpy, MatPlotLib, iPython, vtk, enthought tool suite, ....) sind unter einer BSD-artigen Lizenz lizensiert und können GPLierte Quelltexte nicht weiterverwenden.
Mein normaler "Lizenzierungsentwurf" steht hier darunter:
Ich fange mit einer Zusammenfassung dessen an, was viele von Ihnen bereits über "Open-Source-Lizenzen" wissen. Ich gehe davon aus, daß diese Darstellung weitgehend richtig ist, obwohl es kein rechtskräftiger Text ist, und wenn Sie rechtskräftig fehlerfreie Aussagen möchten, sollten Sie an dieser Stelle auf die ursprüngliche Referenz bezugnehmen. Die Open-Source-Initiative ist ein "Clearing House" (- d.h. eine Art Prüfsiegel-Vergabestelle, Anm. d. Übersetzers -) für OS-Lizenzen, und dort kann man mehr dazu lesen.
Die zwei in der Praxis dominanten Lizenzvarianten sind der GPL-Typ und der BSD-Typ. Es gibt noch unzählige weitere Lizenzen, die bestimmte Einschränkungen für die Wiederverwendung von Quelltexten vornehmen, aber der Zweck dieses Textes ist es, die Unterschiede zwischen GPL- und BSD-Varianten zu betrachten, besonders im Blick auf meine Erfahrungen bei der Entwicklung von MatPlotLib und im Gespräch über Lizenzfragen mit anderen Entwicklern.
Die am besten bekannte und vielleicht am weitesten genutzte Lizenz ist die GPL, die über das Erteilen aller Rechte bezüglich des Quelltextes einschließlich der Weiterverbreitung hinaus eine besondere Verpflichtung mit sich bringt. Wenn Sie GPL-Quelltext in ihrem eigenen Code verwenden oder einbinden, müssen Sie ihr Produkt unter einer mit GPL kompatiblen Lizenz veröffentlichen. Das heißt, Sie sind gezwungen, den Quelltext anderen Leuten zur Verfügung zu stellen und ihnen auch das Recht zur Weiterverbreitung einzuräumen. Viele der bekanntesten und am weitesten verbreiteten Open-Source-Projekte wurden unter der GPL veröffentlicht, einschließlich Linux, gcc und Emacs.
Die zweite große Gruppe sind die BSD-artigen Lizenzen (die die MIT- und die Python-PSF-Lizenz umfassen). Diese erlauben im Grunde genommen, alles mit dem Quelltext zu machen, was man möchte: Ihn nicht beachten, ihn in Ihr eigenes quelloffenes Projekt einbauen, ihn in Ihr eigenes proprietäres (- d.h. dem Eigentümer bestimmte Rechte vorbehaltendes "nicht-freies", Anm. d. Übersetzers -) Projekt einzuschließen, ihn verkaufen, oder was auch immer. Python selbst wurde unter einer BSD-kompatiblen Lizenz veröffentlicht, in dem Sinne, daß von der PSF-Lizenz-Seite zitiert wird:
"Es gibt keine GPLartige "copyleft"- Einschränkung (- d.h.: keine Verpflichtung zum Beibehalten der Veröffentlichungsmodalitäten, Anm. des Übersetzers -). Die Verbreitung von binär codierten Versionen von Python, verändert oder nicht, ist zulässig. Es ist nicht erforderlich, etwas von Ihrem Quellcode zu veröffentlichen. Sie können auch Erweiterungsmodule für Python schreiben und sie ausschließlich in binärer Form zur Verfügung stellen."
Bekannte Projekte, die unter BSD-artiger Lizenz im Sinne des alles erlaubenden letzten Paragraphen sind das BSD-Betriebssystem, Python und TeX.
Ich halte die Entscheidung für eine Lizenz für eine wichtige, und ich befürworte eine BSD-artige Lizenz. Gemäß meiner Erfahrung ist der wichtigste Rohstoff, den ein quelloffenes Projekt braucht, Nutzer. Natürlich ist, etwas Sinnvolles zu leisten, eine Voraussetzung dafür, Nutzer zu bekommen, aber ich nehme auch an, daß Nutzer zu haben so etwas wie die Voraussetzung dafür ist, etwas Sinnvolles zu leisten. Es ist sehr schwierig, etwas in einem Vakuum zu gestalten, und Nutzer tragen durch ihre Vorschläge für weitere Funktionen und ihre Fehlersuch zu guter Software bei. Wenn Sie den Bedarf einiger Nutzer befriedigen, wird das unweigerlich dazu führen, daß sie den Bedarf einer großen Gruppe von Nutzern befriedigen. Und aus Nutzern werden Entwickler, insbesondere wenn sie selbst über einige Fähigkeiten verfügen und auf eine Funktion stoßen, die sie eigentlich bräuchten, oder wenn sie an ihre wissenschaftliche Abschlußarbeit gehen. Wenn Sie erst einmal eine große Menge Nutzer und eine Anzahl von Entwicklern haben, setzt ein Netzwerkeffekt ein, der die Zahl der Nutzer und Entwickler exponentiell anteigen läßt. In der Open-Source-Sprache wird das manchmal als "Wettkampf um Geistesanteile" (engl. "competing for mind share", d. Übersetzer) bezeichnet.
Daher nehme ich an, dass die Hauptsache (oder zumindest die wichtigste Nebensache), die ein quelloffenes Projekt haben kann, Geistesanteile sind, was heisst, dass Sie so viele Nutzer, wie Sie kriegen können, Ihre Software nutzen lassen möchten. Auch wenn Sie sie kostenlos verteilen, müssen Sie Ihre Software vermarkten, so als ob Sie dafür bezahlt würden. Aber wie das jetzt mit der Lizensierung zusammenhängt, fragen Sie?
Viele Softwarefirmen werden für ihre eigene Software keinen GPL-Code nutzen, nicht einmal die, die sich für die Entwicklung quelloffener Software einsetzen wie beispielsweise enthougth, aus der legitimen Erwägung heraus, dass eine Nutzung der GPL ihren eigenen Code aufgrund seiner viralen Natur "infiziert". Eigentlich wollen sie das Recht behalten, bestimmten proprietären Code zu veröffentlichen. Und meiner Erfahrung nach fördern einige der besten Entwickler, weil die die Mittel haben, eine Sache erledigen zu lassen, auch eine langweilige, wenn sie sie in ihrem Code brauchen. Zwei der MatPlotLib-Backends (FLTK und wx) wurden von privaten Firmen beigetragen, die MatPlotLib entweder intern oder als kommerzielles Produkt nutzen - ich habe meine Zweifel, ob diese Firmen MatPlotLib nutzen würden, wenn der Quelltext unter der GPL stünde. Meiner Erfahrung nach ist der Nutzen einer Zusammenabeit mit dem privaten Sektor real, während die Furcht, dass irgeneinein private Firma Ihren Quelltext "stiehlt" und in einer proprietären Anwendung verkauft, ohne Sie zu entschädigen, das nicht ist.
Es gibt inzwischen eine Menge GPL-Quelltext auf der Welt, und es passiert in der Entwicklung von MatPlotLib immer wieder, daß wir, wenn wir bestimmte Algorithmen wiederverwenden wollen, auf die Jagd nach einer nicht-GPL-Version gehen müssen. Jüngst geschah das bei der Suche nach einem guten Konturen-Algorithmus. Ich befürchte, dass die "Lizenzgefechte", deren Auswirkungen schon bei vielen Projekten spürbar werden, das Potential haben, der Entwicklung quelloffener Software wirklichen Schaden zuzufügen. Es gibt zwei schlechte Möglichkeiten. 1) Mit GPL weitermachen und den Geistesanteil des privaten Sektors aufgeben. 2.) Auf GPL-Code verzichten und die Unterstützung des privaten Sektors behalten. Das ist eine sehr harte Entscheidung, weil es eine Menge Software sehr hoher Qualität gibt, die GPL ist, und wir sie nutzen müssten; nicht umsonst bezeichnet man die Lizenz als "viral".
Die dritte Möglichkeit, die mich dazu bewegt dies zu schreiben, ist, die Leute, die Code unter der GPL veröffentlicht haben, davon zu überzeugen, sie unter einer BSD-kompatiblen Lizenz wiederzuveröffentlichen. Viele Leute entscheiden sich für die GPL, wenn sie ein Software-Paket veröffentlichen, weil es die bekannteste Lizenz für quelloffenen Quelltext ist, und sie denken nicht weiter über Fragen wie die hier angesprochene nach, wenn sie eine Lizenz auswählen. Wenn man sie anspricht, sind solche Entwickler oft dafür zugänglich, ihren Quelltext unter einer freizügigeren Lizenz wiederzuveröffentlichen. Fernando Perez hat es so mit iPython gemacht, das unter der LGPL veröffentlicht worden ist und dann wiederveröffentlicht wurde unter einer BSD-Lizenz, um die Verbindung mit dem Quelltext von MatPlotLib, Scipy und enthought zu vereinfachen. Die LGPL ist freizügiger als die GPL, indem sie nicht-virale Verknüpfungen erlaubt, aber trotzdem sind viele Firmen aus rechtlichen Erwägungen einer Nutzung abgeneigt, und Sie können LGPL-Quelltext nicht für ein proprietäres Produkt wiederverwenden.
Insofern ermutige ich Sie, Ihren Quelltext unter einer mit BSD vereinbaren Lizenz zu veröffentlich und, wenn sie auf einen Open-Source-Entwickler treffen, dessen Quelltext Sie nutzen möchten, diesen ebenfalls zu ermutigen, dasselbe zu tun. Geben Sie ihm ruhig dieses Dokument weiter.
Anmerkungen, Verbesserungsvorschläge, Korrekturen usw. senden Sie bitte an jdhunter at ace.bsd.uchicago.edu
Anmerkungen zur Uebersetzung:
Ich habe versucht, den Gebrauch von Anglizismen einigermassen gering zu halten; allerdings habe ich da, wo eine deutschsprachige Formulierung deutlich sperriger wuerde, dann doch der englischen Version den Vorzug gegeben. Insofern kommt es zu einem Nebeneinander von "Open-Source" und "quelloffen".
Gar nicht recht uebersetzen konnte ich: "Code" (auch in der Hybridform "Quellcode"), "Projekt", "proprietär", "kompatibel", "legitim", "copyleft", "Modul" (in der Hybridform "Erweiterungsmodul"), "Software". Manches davon duerfte aber auch kaum noch als Anglizismus auffallen. "copyleft" habe ich in Klammern erklaert, weil es als Wortspiel unuebersetzbar ist, andererseits aber wohl noch nicht so selbsterklaerend wie "copyright". Eigentlich haette ich gerne auch fuer den Ausdruck "proprietaer" eine kurze Erlaeuterung - schon, weil, wie man hieran sehen kann, ich nicht einmal selbst weiss, was sich dahinter nun eigentlich verbirgt. (Ich setze es mit "kaeuflich" gleich, vermute aber, dass das eine verfaelschende Vereinfachung des Sachverhalts darstellt?)
Bei Namen kenne ich oft die "gebräuchliche" deutsche Schreibweise nicht, insbesondere bezüglich der Groß- und Kleinschreibung (z.b. "Emacs" oder "emacs"?)
Und habe ich "backend" richtig mit "Datenbank" uebersetzt? Oder waere "Erweiterung" richtiger?
Auch fuer "reuse" boete sich vielleicht eine andere Uebersetzung als "wiederverwenden" an; sprachlich haette ich "einbauen" oder "mitbenuzen" vorgezogen, bin mir aber nicht sicher, ob das noch in das englische "reuse" faellt?
Edit:
Ich habe jetzt meine Anmerkungen vollständig aus dem Text herausgenommen. Interessieren würde mich noch, ob es bessere Übersetzungen für die folgenden Stellen gibt bzw. ob ich korrekt übersetzt habe:
John Hunter hat geschrieben:My standard "licensing pitch" is included below:
Meine Übersetzung hat geschrieben:Mein normaler "Lizenzierungsentwurf" steht hier darunter:
Hier erweckt die Übersetzung meines Erachtens einen falschen Eindruck, weil ja kein ausformulierter "Lizenzierungsentwurf" folgt, sondern eher Erwägungen zur Lizenzauswahl.
John Hunter hat geschrieben:python itself is released under a BSD compatible license, in the sense that, quoting from the PSF license page
Meine Übersetzung hat geschrieben:
Python selbst wurde unter einer BSD-kompatiblen Lizenz veröffentlicht, in dem Sinne, daß von der PSF-Lizenz-Seite zitiert wird:
John Hunter hat geschrieben:There is a lot of GPL code in the world, and it is a constant reality in the development of matplotlib...
Meine Übersetzung hat geschrieben:Es gibt inzwischen eine Menge GPL-Code auf der Welt, und es passiert in der Entwicklung von MatPlotLib immer wieder...
Und noch zwei Dinge sind mit aufgefallen:
John Hunter hat geschrieben:GPLd code
Das angehängte -d habe ich jetzt mal zu einem "-ierten" gemacht, in der Annahme, dass es darum ging, aus "licence" das Adjektiv "licenced" zu machen?
John Hunter hat geschrieben:a good contouring algorithm
Ist "Konturen-Algorithmus" als Übersetzung irreführend?
(Man achte auf den Satz von Luzandro, der dick angestrichen ist und dann auf meine Antwort.).
