#use wml::debian::template title="Vergleich von Software-Lizenzen"
#use wml::debian::translation-check translation="2bd18a67682540fb7c79d49a858ca9bcfaa704ed"
# $Id$
# Translator: Philipp Frauenfelder (pfrauenf@debian.org)
******Dieses Dokument befindet sich in der
Entwicklung******
Leute, die mit Open Software zu tun haben, neigen dazu, eine
ausgeprägte Meinung über Lizenzen zu
entwickeln. Anfänger kümmert das nicht so sehr, da sie viel
mehr daran interessiert sind, ihr aktuelles Problem zu lösen und
nicht verstehen, was die langfristigen Folgen der Wahl einer Software
mit einer bestimmten Lizenz sein können. (Es ist sogar sehr zweifelhaft,
ob Leute, die keine ausgeprägte Meinung zu Lizenzen haben, alle Nuancen
verstehen.)
Über die Jahre haben einige Lizenzen Berühmtheit erlangt,
weil sie den Software-Autoren die Kontrolle über ihre Arbeit
geben, die sie sich wünschen. Man findet immer noch häufig
Software, die kein sichtbares Copyright besitzt oder eine Lizenz
beinhaltet, die der Autor für seine Bedürfnisse geschrieben
hat. Letzteres kann für die Distributoren der Software (für
solche im Internet als auch für CD-Verkäufer) ziemlich
ärgerlich sein, da viele dieser Lizenzen
weit verbreitete Fehler enthalten, die es
schwer machen, die Software zu verteilen.
Die nun folgende Liste enthält übliche Freie
Software-Lizenzen (frei im Sinne von Freiheit, nicht von gratis) und
einige gute und schlechte Punkte dabei. Es sind nur die Punkte
aufgeführt, die in der Diskussion um die Lizenzen wichtig
sind. Ebenso gibt es Punkte, die unter GUT/SCHLECHT
aufgeführt sind – sie sind gut oder schlecht je nach
Standpunkt.
- Die GNU General Public License (GPL).
ZUSAMMENFASSUNG: Die Quellen müssen verfügbar gemacht werden; die
Software kann verkauft werden; abgeleitete Arbeiten
müssen die selbe Lizenz tragen.
GUT: Es gibt gute Gründe, dass diese Lizenz die am
weitesten verbreitete für Freie Software ist. Sie
leistet guten Schutz für die Rechte der
Software-Entwickler und die Verfügbarkeit der Quellen
garantiert den Benutzern, dass sie sich keine Sorgen um
die zukünftige Unterstützung machen müssen.
GUT/SCHLECHT: Software, die unter Benutzung der GPL veröffentlicht
wird, kann nicht in kommerzielle Software eingebaut
werden. Ob das wirklich schlecht ist, hängt von Ihrem
Standpunkt ab. Personen, die kommerzielle Software
entwickeln, sind oft frustriert, wenn es eine Lösung
für ihr Problem gibt, die aber wegen Lizenz-Problemen
nicht genutzt werden kann. Natürlich können sie sich
immer noch mit dem Autor in Kontakt setzen und versuchen, ob
sie eine Version unter einer anderen Lizenz kaufen können.
Die Meisten, die Software unter den Bedingungen der GPL
veröffentlichen, empfinden diese Einschränkung nicht als Nachteil,
da sie es anderen erlaubt, die Software zu verwenden und zu
verbessern, während sie (für alle praktischen Zwecke) verhindert,
dass wiederum andere Leute Geld aus ihrer Arbeit ohne die Erlaubnis
der Autoren schöpfen.
- Artistic License
http://language.perl.com/misc/Artistic.html.
ZUSAMMENFASSUNG:
GUT:
SCHLECHT:
- Lizenz nach BSD-Art.
ZUSAMMENFASSUNG: Sowohl der Quellcode als auch die Binär-Pakete
müssen die Lizenz enthalten; Werbung muss den Entwickler, der in der
Lizenz genannt wird, anerkennen.
GUT/SCHLECHT: Firmen, die ein Programm allgemein zugänglich
machen wollen (möglicherweise gratis), ohne die Quellen zu
veröffentlichen, greifen oft zu dieser Lizenz. Ein
gutes Beispiel ist eine Firma, die Treiber zu einer
Grafik-Karte herausgeben will. Verfechter von Open Source
würden sowieso die Herausgabe der
Hardware-Spezifikation vorziehen. Falls die Entwicklung
von Treibern für XFree86 hier bezeichnend ist –
XFree86 hat die besten Treiber bei vorhandenen Quellen
geschrieben. Firmen lassen ihr Produkt schlecht aussehen,
wenn sie nur proprietäre Treiber herausgeben, die
erst noch langsam und fehlerhaft sind. Sie können
auch Entwicklungskosten sparen, wenn sie andere Leute den
Treiber für ihre Hardware entwickeln lassen.
GUT/SCHLECHT: Jeder kann den Quellcode nehmen, ihn verändern und
das Resultat dann herausgeben, ohne die Veränderungen zu
veröffentlichen. Ob Sie denken, das sei gut oder schlecht,
ist eine persönliche Einschätzung.
Einige weit verbreitete Fehler in selbstgeschriebenen Lizenzen:
- Entweder Verbot oder Einschränkung des
gewinnorientierten Verkaufs der Software. Das macht es
schwierig, die Software auf CD zu vertreiben. Manche Leute machen
auch den Fehler, schwammige Begriffe wie zum Beispiel
zu
vernünftigem Preis
(reasonable cost
) zu verwenden.
Besser ist es, einfach eine der obigen Lizenzen zu
verwenden, da sie den selben Zweck erfüllen, ohne solche
begrifflichen Schwierigkeiten heraufzubeschwören. Die GPL zum
Beispiel hält die Kosten dadurch niedrig, dass sie jedem das
Verteilen erlaubt – hier regulieren die
Marktkräfte. Wenn einer eine CD mit hoher Gewinnspanne
verkauft, wird es nicht lange dauern, bis Konkurrenten zu einem
günstigeren Preis in den Verkauf einsteigen.
Beachten Sie: die Artistic License benutzt den Begriff
vernünftige Kopier-Gebühr
(reasonable copying fee
), relativiert ihn
aber, so dass er weniger schwammig ist.
- Verbot, eine veränderte Version der Software
zu verteilen. Dies behindert das Verteilen der
Software durch gewisse Gruppen. Zum Beispiel Debian: Da wir
kompilierte Software verteilen, ist es oft nötig, die Quellen
zu verändern, damit die Software kompiliert oder damit sie dem
\
Dateisystem-Standard entspricht. Wenn
wir das machen, dürfen wir die Software anschließend nicht mehr
verteilen.
- Alle Veränderungen müssen dem Autor mitgeteilt
werden. Obwohl es an sich eine gute Idee ist,
Veränderungen/Verbesserungen dem Autor zu melden, damit
sie an ein größeres Publikum verteilt werden
können, kann dies als ein Muss zu verlangen allerdings
Probleme bereiten. Wie viele Leute wissen schon, wo sie sich in
fünf Jahren aufhalten? Besser ist, wenn man schreibt, dass
alle Veränderungen dem Autor mitgeteilt werden
sollten. Die meisten Leute werden sich daran halten.
So eine Klausel wird üblicherweise eingefügt, um
Absplitterungen vom Projekt zu verhindern. Die Erfahrung zeigt
allerdings, dass Absplitterungen bei weiterlaufender
Entwicklung des Projekts nur dann erfolgreich sind, wenn auch
andere Kräfte spaltend wirken.
- Die Software im öffentlichen Eigentum
(
Public Domain
) platzieren, dann aber
Einschränkungen hinzufügen (so wie zum
Beispiel keinen gewinnorientierten Verkauf zu erlauben). Entweder
ist etwas öffentliches Eigentum oder es ist es nicht –
es gibt keine Zwischenebenen. Solche Lizenzen sind bedeutungslos
und es ist wahrscheinlich, dass die zusätzlichen Einschränkungen
vor Gericht nicht durchkommen.