Wenn man eine Lizenz wählt, die man für das Projekt benutzen will, sollte man wenn irgendwie möglich, eine bereits existierende wählen. Exisitierende Lizenzen sind aus zwei Gründen besser:
Bekanntheit. Wenn Sie eines der drei oder vier verbreitetsten Lizenzen benutzen, wird man nicht das Gefühl haben, sich um den rechtlichen Rahmen kümmern zu müssen, wenn sie Ihren Code benutzen wollen. Für diese Lizenz, haben sie das nämlich schon vor langem gemacht.
Qualität. Wenn Sie nicht gerade ein paar Rechtsanwälte parat haben, ist es unwahrscheinlich, dass Sie sich eine rechtlich wasserdichte Lizenz ausdenken. Die erwähnten Lizenzen, sind mit viel Mühe und Erfahrung entstanden; Wenn Ihr Projekt keine äußerst außergewöhnlichen Bedürfnisse hat, werden sie es wahrscheinlich nicht besser machen.
Siehe „Eine Lizenz für Ihre Software“ in Kapitel 2, Der Einstieg, um eine dieser Lizenzen auf Ihr Projekt anzuwenden.
Wenn Sie wollen, dass Ihr Code die größtmögliche Anzahl an Entwickler und Derivate erreicht, und es sie nicht stört, wenn Ihr Code in proprietären Anwendungen benutzt wird, sollten Sie die MIT- / X-Window-System-Lizenz wählen (der Name kommt durch seine Nutzung für den Code vom ursprünglichen X-Window-System veröffentlicht von dem Massachusetts Institute of Technology). Die grundsätzliche Botschaft dieser Lizenz ist, "Du kannst mit diesem Code machen was du willst." Sie ist mit der GNU GPL kompatibel, sie ist kurz, einfach und leicht zu verstehen:
Copyright (c) <Jahr> <copyright Inhaber> Hiermit wird unentgeltlich, jeder Person, die eine Kopie der Software und der zugehörigen Dokumentationen (die "Software") erhält, die Erlaubnis erteilt, uneingeschränkt zu benutzen, inklusive und ohne Ausnahme, dem Recht, sie zu verwenden, kopieren, ändern, fusionieren, verlegen, verbreiten, unter-lizenzieren und/oder zu verkaufen, und Personen, die diese Software erhalten, diese Rechte zu geben, unter den folgenden Bedingungen: Der obige Urheberrechtsvermerk und dieser Erlaubnisvermerk sind in alle Kopien oder Teilkopien der Software beizulegen. DIE SOFTWARE WIRD OHNE JEDE AUSDRÜCKLICHE ODER IMPLIZIERTE GARANTIE BEREITGESTELLT, EINSCHLIESSLICH DER GARANTIE ZUR BENUTZUNG FÜR DEN VORGESEHENEN ODER EINEM BESTIMMTEN ZWECK SOWIE JEGLICHER RECHTSVERLETZUNG, JEDOCH NICHT DARAUF BESCHRÄNKT. IN KEINEM FALL SIND DIE AUTOREN ODER COPYRIGHTINHABER FÜR JEGLICHEN SCHADEN ODER SONSTIGE ANSPRUCH HAFTBAR ZU MACHEN, OB INFOLGE DER ERFÜLLUNG VON EINEM VERTRAG, EINEM DELIKT ODER ANDERS IM ZUSAMMENHANG MIT DER BENUTZUNG ODER SONSTIGE VERWENDUNG DER SOFTWARE ENTSTANDEN.[61]
Wenn Sie es vorziehen, dass Ihr Code nicht in Proprietären Anwendungen verwendet wird, oder es Ihnen zumindest egal ist, ob es in proprietären Anwendungen verwendet werden kann, sollten Sie die GNU General Public License (de. Allgemeine Öffentliche Lizenz) verwenden (http://www.fsf.org/licensing/licenses/gpl.html). Die GPL ist wahrscheinlich die heute am weitesten verbreitete Lizenz für freie Software; diese breite Bekanntheit, ist an und für sich schon eine der großen Vorteile der GPL.
Wenn man eine Bibliothek schreibt, die hauptsächlich dazu gedacht ist, als Teil anderer Anwendungen verwendet zu werden, sollten sie genau überlegen, ob die Einschränkungen die von der GPL vorgegeben werden, mit den Zielen von Ihrem Projekt vereinbar sind. Manchmal – zum Beispiel, wenn Sie versuchen eine konkurrierende, propritäre Bibliothek, mit der gleichen Funktion, zu ersetzen – kann es aus strategischer Sicht sinnvoller sein, Ihre Lizenz derart zu wählen, dass es in proprietären Anwendungen verwendet werden kann, auch wenn Sie das sonst nicht so gerne sehen würden. Die Free Software Foundation hat sogar eine alternative zur GPL geschrieben, für genau diese Umstände: die GNU Library GPL, später zur GNU Lesser GPL umbenannt (meistens wird das Kürzel LGPL verwendet). Die LGPL hat weniger Einschränkungen als die GPL und kann leichter min nicht freier Software zusammen benutzt werden. Es ist jedoch auch etwas komplex und erfordert etwas Zeit zum Verständnis, wenn Sie also nicht die GPL verwenden, empfehle ich einfach ein Lizenz der Art von MIT/X zu verwenden.
Eine der Konsequenzen der GPL, ist die Möglichkeit – zwar klein aber dennoch vorhanden – sich oder oder Ihr Projekt in einer zu leiten, ob die GPL wirklich "frei" ist oder nicht, in Anbetracht der Einschränkungen auf die Verwendung vom Code – nämlich die Einschränkung, dass Code nicht unter irgend einer anderen Lizenz verbreitet werden darf. Für manche, bedeutet diese Einschränkung, dass die GPL weniger "frei ist" als die toleranteren Lizenz, wie die MIT/X Lizenz. Dieses Argument führt natürlich meistens darauf, dass "mehr Freiheit" zwangsläufig besser ist als "weniger Freiheit" (wer ist schließlich nicht für Freiheit?), woraus folgt, dass diese Lizenzen besser sind, als die GPL.
Diese Debatte ist ein weiteres der beliebten heiligen Kriege (siehe „Vermeiden Sie Heilige Kriege“ im Kapitel Kapitel 6, Kommunikation). Vermeiden Sie die Beteiligung daran, zumindest in den Foren des Projekts. Versuchen Sie nicht zu beweisen, dass die GPL weniger, gleich viel oder mehr Freiheit bietet als andere Lizenzen. Betonen Sie statt dessen, die spezifischen Gründe, die Ihr Projekt zur Wahl der GPL geführt hat. Wenn ihre weite Verbreitung eines der Gründe war, sollten Sie das sagen. Wenn die Übertragung einer freien Lizenz auf Abgeleitete Werke auch eines der Gründe war, sollten Sie das ebenfalls erwähnen, lassen Sie sich aber nicht in eine Diskussion darüber verleiten, ob der Code dadurch mehr oder weniger "Frei" ist. Freiheit ist ein komplexes Thema und es macht wenig Sinn darüber zu reden, wenn Begriffe als Vorwand benutzt werden vor dem Wesentlichen.
Da ich hier jedoch ein Buch schreibe und nicht eine E-Mail an einem Verteiler, gebe ich zu, dass nie das Argument "die GPL ist nicht frei" nie ganz verstanden habe. Die einzige Einschränkung die von der GPL auferlegt wird, ist dass andere daran gehindert werden, weitere Einschränkungen zu machen. Zu behaupten, dass sie deswegen weniger frei wäre, erschien mir immer als ob man sagen würde, dass ein Gesetz gegen Sklaverei die Freiheit reduziert, da es manche daran hindert, Sklaven zu besitzen.
(Im übrigen, wenn Sie sich tatsächlich auf eine Debatte darüber einlassen wollen, machen Sie die Sache durch aufrührerischen Gleichnisse nicht schlimmer als nötig.)
Eine nicht unwesentliche Menge an freie Software wird unter einer BSD Lizense veröffentlicht. Die ursprüngliche BSD Lizenz wurde für die Berkeley Software Distribution verwenden, indem die Universität von Kalifornien wichtige Teile einer Unix Implementierung veröffentlichte. Diese Lizenz (der genaue Text findet man im Abschnitt 2.2.2 auf http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6) wurde im Geiste der MIT/X Lizenz geschrieben, bis auf eine Klausel:
Jegliche Werbematerialien, die Funktionen oder die Nutzung dieser Software erwähnen, müssen die folgende Anerkennung einschließen: Dieses Produkt beinhaltet Software die von der Lawrence Berkeley Laboratory der Universität von Kalifornien entwickelt wurde.
Diese Klausel machte die Ursprüngliche BSD-Lizenz nicht nur inkompatibel zur GPL, sonder setzte auch noch ein gefährliches Beispiel: während andere Organisationen ähnlichen Klausel in ihre freie Software schrieben – wobei sie den Namen Ihrer Organisation anstatt von "Lawrence Berkeley Laboratory der Universität von Kalifornien" einsetzten – wurde jedem der die Software verbreiten wollte, eine immer größere Bürde auferlegt, jede einzelne Firma zu erwähnen. Zum Glück, wurden viele Projekte, sich dieser Problematik bewusst und ließen diese Klausel einfach fallen. 1999 schließlich sogar die Universität von Kalifornien.
Das Ergebnis ist die überarbeitete BSD-Lizenz, die einfach die ursprüngliche BSD-Lizenz ist, ohne die Werbeklausel. Diese Geschichte macht den Begriff BSD-Lizense jedoch etwas mehrdeutig: ist damit das Original oder die überarbeitete Fassung gemeint? Ich ziehe deshalb die MIT/X Lizense vor, die im wesentlichen gleichwertig ist, und nicht unter dieser Mehrdeutigkeit leidet. Es gibt jedoch vielleicht ein Grund die BSD Lizenz der MIT/X Lizenz vorzuziehen, die BSD-Lizenz beinhaltet nämlich diese Klausel:
Weder der Name der <ORGANIZATION> noch die Namen seiner Teilhaber dürfen zur Werbung oder Förderung von Produkten verwendet werden, die von dieser Software abgeleitet werden, ohne explizite vorherige schriftliche Zustimmung.
Es ist ohne ein solche Klausel nicht klar, ob jemand der die Software erhält, das Recht hat, den Namen des Lizenzgebers zu verwenden, die Klausel lässt daran aber keinen Zweifel. Organizationen, die sich um Markenrecht sorgen machen, mögen deshalb die überarbeitete BSD-Lizenz vorziehen. Im allgemeinen, impliziert eine liberale Urheberrechts-Lizenz jedoch nicht, dass Empfänger das Recht haben ihre Marken zu benutzen oder zu verwässern – Urheberrecht und Markenrechte sind zwei paar Schuhe.
Wenn Sie die überarbeitete BSD-Lizenz verwenden wollen, finden sieh hier eine Vorlage http://www.opensource.org/licenses/bsd-license.php.
[61] Diese freie Übersetzung, von http://de.wikipedia.org/wiki/MIT-Lizenz wird zum besseren Verständnis benutzt, es ist keine offizielle oder im rechtlichen Sinne Anerkannte Übersetzung. In Ihrer Anwendung sollten die Originalfassung verwenden, die Sie hier finden: http://www.opensource.org/licenses/mit-license.php
[62] The history of the license and its name is a bit complicated. The first version of the license was originally released by Affero, Inc, who based it on the GNU GPL version 2. This was commonly referred to as the AGPL. Later, the Free Software Foundation decided to adopt the idea, but by then they had released version 3 of their GNU GPL, so they based their new Affero-ized license on that and called it the "GNU AGPL". The old Affero license is more or less deprecated now. If you want Affero-like provisions, you should use the GNU version. To avoid ambiguity, call it the "AGPLv3", the "GNU AGPL", or for maximum precision, "GNU AGPLv3".