Lizenzen, UrheberrechtIm Wesentlichen ist hiermit
das im Angloamerikanischen Raum verbreitete "Copyright" gemeint, auch
wenn diese nicht ganz mit dem Deutschen Urheberrechtsgesetz vergleichbar
ist, werden hier im weiteren nicht zwischen beiden
Unterschieden. und Patente
Die Lizenz die man auswählt hat vermutlich keinen großen Einfluss
auf die Einführung des Projektes, solange es eine Open-Source-Lizenz
ist. Benutzer wählen Software aufgrund von Qualität und
Funktionalität, und nicht wegen Lizenzdetails aus. Trotzdem sollte man
ein Grundverständnis über Open-Source-Lizenzen haben um einerseits
sicherzustellen, dass die Lizenz zu den Zielen des Projektes passt und
andererseits um in der Lage zu sein mit anderen über die Lizenz zu
reden. Bitte beachtet, dass ich kein Anwalt und dass dieses Kapitel
nicht als juristischer Rat zu sehen ist. Dafür braucht man einen
Anwalt oder sollte selbst einer sein.
Terminologie
In jeder Diskussion über Open-Source-Lizenzen stellt man zunächst
fest, dass es viele Begriffe für die gleiche Sache gibt:
Freie Software,
Open Source, FOSS,
F/OSS, und FLOSS. Wir
beginnen damit, diese und einige andere Begriffe zu klären.
Freie Software
Software, die auch im Quelltext frei verteilt und
modifiziert werden kann. Der Begriff wurde zuerst von Richard
Stallman geprägt, der das Prinzip in der GNU General Public
License (GPL) festschrieb, und der die Free Software Foundation
() gründete um das Konzept
bekannt zu machen.
Obwohl "Freie Software" ungefähr genau soviel Software
umfasst wie "Open Source", bevorzugen die FSF und viele andere
den Begriff "Freie Software", da er die Idee von Freiheit betont
und das Konzept frei verteilbarer Software vor allem als
gesellschaftliche Bewegung sehen. Die FSF sieht dass der Begriff
zweideutig ist – es könnte auch "umsonst" bedeuten, anstatt
"frei" wie in "Freiheit" – findet aber dennoch, dass es
alles in allem am besten passt, da andere Varianten im
Englischen eigene Zweideutigkeiten haben. (In diesem Buch wird
"frei" immer im Sinne von "Freiheit" verwendet, nicht im Sinn
von "umsonst".)
Open Source Software
Freie Software unter einem anderen Namen. Doch der Name
spiegelt einen wichtigen philosophischen Unterschied wieder:
"Open Source" wurde geprägt durch die Open Source Initiative
() als eine durchdachte
Alternative zu "Freier Software" um diese attraktiver für
Unternehmen zu machen; als Entwicklungsmethode und nicht als
politische Bewegung. Vielleicht wollte man auch ein anderes
Stigma verschwinden lassen, nämlich dass alles was nichts kostet
auch von schlechter Qualität ist.
Obwohl jede freie Lizenz auch "Open Source" ist, und bis auf
wenige Ausnahmen auch andersherum, bleiben die meisten Leute bei
einem Begriff. Meistens haben diejenigen die "Freie Software"
verwenden einen eher politischen oder moralischen Standpunkt,
während die die "Open Source" bevorzugen es entweder nicht als
eine Frage der Freiheit sehen oder kein Interesse haben, es nach
außen zu zeigen. Siehe auch in
für eine genauere
Geschichte dieses Schismas.
Die Free Software Foundation hat eine
vorzügliche – fürchterlich unobjektive, aber nuancierte und
recht faire – Herkunft der beiden Begriffe unter
veröffentlicht. Die Open Source Initiative verteilt ihre Sicht
auf zwei Seiten:
und .
FOSS,
F/OSS,
FLOSS
Wo zwei sind, darf ein drittes nicht fehlen. Genau dies
passierte mit Begriffen für freie Software. Akademiker, die
vielleicht präzise und umfassende Begriffe gegenüber eleganten
bevorzugen, scheinen sich auf FOSS oder F/OSS für "Freie / Open
Source Software" zu einigen. Eine andere Variante ist FLOSS für
"Freie / Libre Open Source Software"
(libre steht in vielen Sprachen
für "frei" jedoch ohne die Zweideutigkeiten; siehe auch .
All diese Begriffe bedeuten eigentlich das gleiche:
Software die von jedem verändert und verteilt werden kann,
manchmal – aber nicht immer – mit der Einschränkung,
dass abgeleitete Arbeiten wieder unter den gleichen Bedingungen
verteilt werden.
DFSG-verträglich
Verträglich mit den Debian-Richtlinien für Freie Software
(Debian Free Software Guidelines) ().
Dies ist ein weit verbreiteter Test um zu prüfen ob eine Lizenz
wirklich frei (open source, libre, etc.) ist. Das Ziel des
Debian-Projekts ist ein vollständig freies Betriebssystem, so
dass niemand der es installiert daran zweifeln muss ob er das
Recht hat einen Teil oder das ganze System zu verändern oder zu
verteilen. Die Debian-Richtlinien für Freie Software bestimmen
die lizenzrechtlichen Anforderungen die eine Software erfüllen
muss um in Debian aufgenommen zu werden. Da das Debian-Projekt
gründlich darüber nachgedacht hat, wie man so einen Test
erstellt, kamen dabei sehr robuste Richtlinien (siehe ) heraus, und soweit
ich weiss, gibt es weder von der Free Software Foundation noch
von der Open Source Initiative ernsthafte Bedenken dagegen. Wenn
man weiss, dass eine Lizenz DFSG-verträglich ist, kann man
sicher sein, dass sie alle wichtigen Freiheiten einräumt (z.B.
die Möglichkeit ein neues Projekt abzuspalten, auch gegen den
Willen des Originalautors. Alle hier diskutierten Lizenzen
sind verträglich mit der DFSG.
OSI-approved
Anerkannt durch die Open-Source-Initiative. Dies ist ein
anderer oft verwendeter Test ob eine Lizenz alle nötigen
Freiheiten erlaubt. Die OSI-Definition von Open-Source-Software
basiert auf den DFSG, und beinahe jede Lizenz die die eine
Definition erfüllt, erfüllt auch die andere. Über die Jahre gab
es einige Ausnahmen, die aber nur seltene Lizenzen betrafen und
keine von diesen ist hier relevant. Im Gegensatz zum Debian
Projekt hat die OSI eine Liste aller jemals anerkannten Lizenzen
unter . Damit
ist "OSI-anerkannt" eindeutig: Entweder eine Lizenz ist auf der
Liste oder eben nicht.
Die Free Software Foundation stellt auch eine Liste mit
Lizenzen unter
zur Verfügung. Die FSF ordnet die Lizenzen aber nicht nur danach
ein, ob sie frei sind, sondern auch danach ob sie kompatibel mit
der GNU General Public License ist. Kompatibilität mit der GPL
ist ein wichtiges Thema, das in
später in diesem Kapitil besprochen wird.
Proprietär,
Closed Source
Das Gegenteil von "Frei" oder "Open Source". Es steht für
Software die unter traditionellen, kostenpflichtigen
Lizenzbedingungen (Der Nutzer zahlt pro Kopie der Software)
ausgeliefert werden oder zu Bedingungen die restriktiv genug
sind, die Dynamik von Open Source zu unterbinden. Auch Software
die "umsonst" zur Verfügung gestellt wird, kann proprietär sein,
wenn die Lizenz die freie Verteilung und Veränderung der
Software verbietet.
Im allgemeinen sind "proprietär" und "Closed Source"
synonym. "Closed Source" impliziert jedoch , dass der Quellcode
nicht einmal eingesehen werden kann. Da dies bei der meisten
proprietären Software so ist, werden die beiden Varianten
meistens nicht unterschieden. Manchmal wird jedoch proprietäre
Software veröffentlicht, deren Lizenz es erlaubt, den Quellcode
einzusehen. Verwirrender Weise wird dies dann auch "Open
Source" oder "Fast Open Source" genannt, doch das ist
irreführend. Die Sichtbarkeit des
Quellcodes ist nicht entscheidend; wichtig ist was man damit
tun darf. Die Unterschiede zwischen "proprietär" und
"Closed-Source" sind also irrelevant, und man kann die Begriffe
synonym verwenden.
Manchmal wird kommerziell als
Synonym für proprietär verwendet, doch genaugenommen ist das
nicht dasselbe. Denn Freie Software kann verkauft werden,
solange die Käufer ihre Kopien weitergeben dürfen. Sie kann
auch auf anderen Wegen kommerzialisiert werden, zum Beispiel
durch Support-Verträge, Dienstleistungen und Zertifizierungen.
Es gibt millionenschwere Unternehmen die mit freier Software
Geld verdienen, sie richtet sich also weder gegen
Kommerzialisierung, noch gegen Unternehmen. Andererseits
ist sie von Natur aus gegen proprietäre
Software. Dies ist der Punkt warum sie sich von
althergebrachten "pay per copy" Lizenzmodellen
unterscheidet.
public domain
Niemand hat das Recht, das Kopieren der Software
einzuschränken. Dies bedeutet aber nicht, dass die Software
keinen Urheber hat. Der Urheber macht aber von seinen
Verwertungsrechten keinen Gebrauch. Die Tatsache, dass er die
Rechte der Öffentlichkeit einräumt, ändert nichts an seiner
Urheberschaft.
Wenn eine Arbeit "public domain" ist, können Teile davon in
anderen lizenzgeschützten Werken benutzt werden. Dann steht
diese Kopie der Arbeit unter derselben
Lizenz wie das Gesamtwerk. Das betrifft aber nicht die
Verfügbarkeit der Originalarbeit die immer noch "public domain"
ist. Etwas der Öffentlichkeit zu übergeben ist also ein Weg eine
Software "frei" zu machen, gemäß den Richtlinien der meisten
Organisationen die freie Software zertifizieren. Trotzdem gibt
es gute Gründe, eine Lizenz zu verwenden, statt die Software
einfach mit allen Rechten und ohne Pflichten herauszugeben:
Selbst bei freier Software können Einschränkungen sinnvoll sein,
nicht nur für den Urheber, sondern auch für den Lizenznehmer,
wie der nächste Abschnitt zeigt.
copyleft
Eine Lizenz, die das Urheberrecht verwendet um den
entgegengesetzten Effekt zu erzielen. Je nach dem wen man fragt,
sind Lizenzen gemeint, die die Rechte die wir hier diskutieren
einräumen, oder genauer: Lizenzen die diese Rechte nicht nur
einräumen sondern sie erzwingen, indem sie
verlangen, dass diese Rechte mit der Arbeit wandern. Die FSF
verwendet ausschließlich die zweite Form; ansonsten steht es
Unentschieden: Viele verwenden den Begriff wie die FSF, andere
– auch Autoren der Massenmedien – verwenden die
erste Variante. Der Unterschied zwischen den Varianten ist
vielen aber nicht klar.
Das bekannteste Beispiel für die genauere Definition ist
die GNU General Public License, die verlangt, dass jede
abgeleitete Arbeit wieder unter der GPL stehen muss; siehe
weiter unten .
Lizenzaspekte
Obwohl es viele freie Lizenzen gibt, sagen sie in den wichtigen
Punkten doch alle dasselbe: jeder den Quellcode bearbeiten kann,
jeder die Software im Original oder modifiziert verbreiten darf und
dass die Rechteinhaber keine Garantie oder Gewährleistung übernehmen
(Haftungsausschluss ist vor allem wichtig, wenn Leute veränderte
Software einsetzen ohne es zu wissen.) Die Unterschiede zwischen den
Lizenzen reduzieren sich auf einige wenige Punkte:
Kompatibilität mit proprietären Lizenzen
Einige freie Lizenzen gestatten es, den Code in
proprietären Programmen zu verwenden. Das betrifft aber nicht die
Lizenz des proprietären Programms: es ist genauso proprietär wie
vorher, nur enthält es Code von einer nicht-proprietären Quelle.
Beispiele für Lizenzen die das gestatten sind: Die Apache-Lizenz,
die Lizenz des X-Konsortiums, Lizenzen im BSD- oder
MIT-Stil.
Kompatibilität mit anderen freien Lizenzen
Die meisten freien Lizenzen sind kompatibel
zueinander: Das bedeutet, dass Code der unter Lizenz A
entstanden ist und mit Code der unter Lizenz B entstanden
kombiniert wird unter jede der beiden Lizenzen gestellt werden
kann, ohne die einzelnen Lizenzbedingungen zu verletzen. Die
große Ausnahme ist die GNU General Public License, die fordert,
dass jede Arbeit die GPL-lizenzierten Code verwendet auch unter
der GPL stehen muss, und keine weiteren Einschränkungen
hinzufügen darf. Die GPL ist daher nur mit einigen freien
Lizenzen kompatible. Das wird in
genauer diskutiert.
Namensnennung erzwingen
Einige freie Lizenzen verlangen, dass bei Verwendung
des Codes eine Notiz erscheinen muss (die Art und Weise ist
typischerweise vorgeschrieben), die den Autor oder
Rechteinhaber nennt. Diese Lizenzen sind oft kompatibel zu
proprietären, da sie nicht dazu zwingen, die abgeleitete Arbeit
wieder unter eine freie Lizenz zu stellen, sondern nur dazu das
freie Original zu nennen.
Schutz der Marke
Eine Variante die Namensnennung zu erzwingen.
Lizenzen mit einer Bestimmung zum Schutz der Marke, verlangen,
dass der Name der Originalsoftware (oder der Rechteinhaber) ohne
Genehmigung nicht in abgeleiteten Arbeiten
verwendet werden darf. Auch wenn man beim Erzwingen der Namensnennung
darauf besteht, einen bestimmten Namen zu verwenden, während man
beim Schutz der Marke darauf besteht einen bestimmten Namen nicht zu
verwenden, drücken doch beide Ansätze dasselbe aus: Der gute Ruf des
Originals soll erhalten und verbreitet, aber nicht verwässert
werden.
patent snapback
Both the GNU General Public License version 3 and
the Apache License version 2 contain language designed
to prevent people from using patent law to take away the
rights granted (under copyright law) by the
licenses. They require contributors to grant patent
licenses along with their contribution, covering any
patents licenseable by the contributor that would be
infringed by their contribution (or by the incorporation
of their contribution into the work as a whole). Then
they go further: if someone using software under the
license initiates patent litigation against another party,
claiming that the covered work infringes, the initiator
automatically loses all the
patent grants otherwise provided for that work by the
license, and in the case of the GPLv3 loses their right
to distribute under the license altogether.
Schutz der "künstlerischen Integrität"
Einige Lizenzen (z. B. die Perl Artistic License,
oder Donald Knuths TeX License) erfordern, dass bei der
Veränderung und Verbreitung klar zwischen der reinen
Originalversion und Veränderungen getrennt werden soll. Es
werden im Grunde die gleichen Freiheiten wie bei anderen freien
Lizenzen eingeräumt, aber es wird verlangt, dass die
Integrität des Originalcodes leicht zu überprüfen ist. Diese
Lizenzen haben sich nicht über die Sprachen für die sie
geschaffen wurden hinaus nicht durchgesetzt und werden in diesem
Kapitel nicht weiter erwähnt; sie wurden hier nur der
Vollständigkeit halber erwähnt.
Die meisten dieser Bestimmungen schließen sich nicht gegenseitig
aus. Die Gemeinsamkeit ist, dass der Lizenznehmer bestimmte Pflichten
erfüllen muss für das Recht den Code zu verwenden oder weiter zu
verbreiten. Zum Beispiel wollen einige Projekte ihren Namen und ihre
Reputation mit dem Code verbreiten, und das ist es ihnen Wert eine
zusätzliche Bestimmung zum Markenschutz zu erlassen. Je nachdem wie
streng die Bestimmung ist, werden so manche Benutzer ein Programm
nehmen das weniger strenge Bestimmungen hat.
Die GPL und Lizenz-Kompatibilität
Die schärfste Trennlinie verläuft zwischen Lizenzen die
kompatibel zu proprietärer Software sind solchen die es nicht sind;
also zwischen der GNU General Public License und dem Rest. Da das
vorrangige Ziel der GPL-Autoren die Verbreitung freier Software ist,
haben sie die Lizenz so gestaltet, dass es unmöglich ist,
GPL-lizenzierten Code in proprietären Programmen zu verwenden. Siehe
vor allem diese beiden Absätze der GPL (siehe auch ):
Jedes abgeleitete Werk, also alles, was eine gewisse Menge
GPL-lizenzierten Code enthält, muss wieder unter die GPL gestellt
werden.
Es dürfen keine zusätzlichen Einschränkungen
hinzugefügt werden, weder auf das Originalwerk, noch auf
abgeleitete Arbeiten. Der genaue Wortlaut ist: "Sie dürfen keine
zusätzlichen Einschränkungen bzgl. der Ausübung der unter dieser
Lizenz gewährten oder zugesicherten Rechte
vornehmen."Anm. der Übersetzer: Die Übersetzung
der GPL stammt von , das englische
Original findet man im §10 unter
Mit diesen Bedingungen schafft es die GPL-Freiheit ansteckend zu
machen. Steht ein Programm erst einmal unter der GPL, sind die
Bedingungen zur Weitergabe viral – sie
verbreiten sich auf jede Software die diesen Code verwendet. Das macht
es unmöglich GPL-lizenzierten Code in proprietären Programmen zu
verwenden. Aber genau diese Sätze machen die GPL inkompatible mit
einigen anderen freien Lizenzen. Das passiert üblicherweise, wenn die
andere Lizenz z.B. verlangt, die Originalautoren zu nennen, denn das
widerspricht der Bedingung keine weiteren Einschränkungen einzuführen.
Aus Sicht der Free Software Foundation sind diese Folgen
wünschenswert, oder zumindest nicht zu bedauern. Die GPL hält die
Software nicht nur frei, sondern macht sie zu einem Agenten der
versucht auch andere Programme dazu zu bringen
Freiheit zu fordern.
Die Frage ob dies ein guter Weg ist, freie Software zu verbreiten
ist einer der beständigsten heiligen Kriege im Internet (siehe in ) und wir werden hier nicht
näher darauf eingehen. Für uns ist wichtig, dass Kompatibilität mit
der GPL wichtig ist, wenn man eine Lizenz auswählt. Die GPL ist bei
weitem die populärste Open-Source-Lizenz: nach liegt sie bei 68%,
während die nächst-populäre nur 6% erreicht. Wenn man möchte, dass der
Code frei mit GPL-lizenziertem Code gemischt werden kann – und
davon gibt es eine Menge – sollte man eine GPL-kompatible Lizenz
nehmen. Die meisten Lizenzen die mit der GPL kompatibel sind, sind
auch mit proprietären Lizenzen kompatibel, das heisst Code der unter
so einer Lizenz steht kann in sowohl in GPL-lizenzierten als auch in
proprietären Programmen verwendet werden. Die Ergebnis solcher
Kombinationen wären natürlich nicht kompatibel zueinander, da das eine
unter der GPL stünde, das andere aber unter einer closed-source
Lizenz. Das bezieht sich aber nur auf abgeleitete Werke, nicht auf
die ursprüngliche Software.
Glücklicherweise hat die Free Software Foundation eine Liste die
aufführt, welche Lizenzen kompatibel zur GPL sind und welche nicht
(siehe ).
Alle Lizenzen die wir hier diskutiert haben sind auf dieser Liste, auf
der einen oder anderen Seite.
Die Wahl einer Lizenz
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
in , um eine dieser Lizenzen auf
Ihr Projekt anzuwenden.
Die MIT- / X-Window-System-Lizenz
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.Diese
freie Übersetzung, von
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:
Die GNU GPL
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
(). 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.
The GNU Affero GPL: A Version of the GNU GPL for Server-Side
Code
In 2007, the Free Software Foundation released a variant of
the GPL called the GNU Affero GPL
()
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"..
Its purpose is to enforce GPL-like sharing provisions on the growing
number of companies that offered hosted services—software that
runs on their servers, that users interact with only over the
network, and that therefore is never directly distributed to users
as executable or source code. Many such services had been using
GPL'd software, often with modifications, yet didn't have to share
their changes with the world because they weren't distributing any
code.
The GNU AGPLv3's solution to this was to take the regular GPL
and add a "Remote Network Interaction" clause, stating
"...if you modify the Program, your modified version must
prominently offer all users interacting with it remotely through a
computer network ... an opportunity to receive the Corresponding
Source of your version ... at no charge, through some standard or
customary means of facilitating copying of software."
This expanded the GPL's enforcement powers into the new world of
application service providers. The Free Software Foundation
recommends that the GNU AGPLv3 be used for any software that will
commonly be run over a network.
Note that the AGPLv3 is not directly compatible with GPLv2
(though it is compatible with GPLv3, of course). However, most
software licensed under the GPLv2 includes the "or any later
version" clause anyway, so you can just shift it to GPLv3 if and
when you need to mix it with AGPLv3 code. However, if you need to
mix with programs licensed strictly under the GPLv2 (that is,
without the "or any later version" clause), then the AGPLv3 won't
work.
Although the history of the AGPLv3 is a bit complicated, the
license itself is simple: it's just the GPLv3 with one extra clause
about network interaction. The Wikipedia article on the AGPLv3 is
excellent:
Ist die GPL frei oder nicht frei?
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 im Kapitel
). 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.)
Wie sieht es mit der BSD-Lizenz aus?
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
) 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 .
Zuweisung von Urheberrechten
Bei freier Software, mit Codebeiträge von vielen Beteiligten, gibt
es drei Möglichkeiten mit der Zuweisung von Urheberrechten umzugehen. Die erste
ist das Thema ganz und gar zu ignorieren (Kann ich nicht empfehlen). Die
zweite ist eine contributor license agreement (de.
Lizenzvereinbarung für Beitragende)
(CLA) von jedem Beteiligten an dem Projekt
einzufordern, die dem Projekt explizit das Recht erteilt, den Code von
dieser Person nutzen zu dürfen. Das reicht für die meisten Projekte aus
und das schöne daran, ist dass mache Gerichtsbezirke erlauben, dass eine
CLA per E-Mail eingereicht wird. Die dritte Möglichkeit ist, die
eigentlichen urheberrechtlichen Zuweisungen von den Beitragenden zu
bekommen, sodass das Projekt (also irgend eine rechtliche Person,
üblicherweise ein gemeinnützige Organisation) der Inhaber aller
Urheberrechte ist. Rechtlich gesehen, ist das die am ehesten wasserdichte
Lösung, aber auch die am Aufwändigsten für die Beteiligten, weshalb nur
wenige Projekte darauf bestehen.Die Übertragung von
bestimmten Rechten ist, im Gegensatz zum amerikanischen copyright,
nach deutschem Urheberrecht nicht möglich. Aus diesem Grund sollte bei
Open-Source-Lizenzen genau geprüft werden, wie diese nach deutschem
Recht einzuordnen sind.
Beachten Sie, dass selbst bei einem zentralen Inhaber des
Urheberrechts, der Code immernoch frei ist, denn Open-Source-Lizenzen
geben dem Urheber nicht das Recht im nachhinein alle Kopien proprietär
zu machen. Selbst wenn das Projekt als rechtliche Person, eine
kehrtwende machen würde, und anfangen würde jeglichen Code unter einer
restriktive Lizenz zu veröffentliche, würde das kein Problem für die
öffentliche Gemeinte bereiten. Die anderen Entwickler würden einfach
einen Fork anfangen, ausgehend von der letzten freien Version des
Quellcodes, und von da an weitermache, als wäre nichts geschehen. Da sie
wissen, dass ihnen diese Möglichkeit offensteht, sind die meisten
Freiwilligen kooperative wenn man sie darum bittet eine CLA oder die
Übertragung des Urheberrechts zu unterschreiben.
Keine Zuweisung von Urheberrecht
Die meisten Projekte bitten Freiwillige nicht um eine CLA oder der
Übertragung des Urheberrechts. Stattdessen, nehmen sie Code an, solange
es klar scheint, dass der Beitragende vorsah es in das Projekt zu
integrieren.
Üblicherweise ist das auch in Ordnung. Ab und zu, kann sich jemand
dazu entschließen auf Urheberrechtsverletzung zu klagen, mit der
Behauptung, dass sie die eigentlichen Inhaber von dem in Frage stehenden
Code sind und sie sich nie damit einverstanden erklärt haben, dass es
mit dem Projekt unter einer Open-Source-Lizenz veröffentlicht wird. Die
SCO-Gruppe hat sowas beispielsweise mit dem Linux-Projekt gemacht, siehe
für mehr zu
diesem Thema. Wenn das passiert, wird das Projekt keine Dokumentation
haben, die zeigt, dass der Urheber formal das Recht erteilt hat den Code
zu benutzen, was eine rechtliche Verteidigung schwieriger gestalten
könnte.
Lizenzvereinbarung der Beitragenden (CLA)
CLAs bieten wahrscheinlich den besten Kompromiss zwischen
Sicherheit und Bequemlichkeit. Eine CLA ist üblicherweise ein
elektronisches Formular, dass vom Entwickler ausgefüllt wird und an das
Projekt gesandt wird. In viele Gerichtsbezirken, reicht es sie per
E-Mail einzureichen. Eine sicher digitale Signatur unter Umständen
erforderlich sein; fragen Sie einen Anwalt welche Methode für Ihr
Projekt angemessen ist.
Die meisten Projekte benutzen meistens zwei verschiedene CLAs,
eines für Einzelpersonen und eines für Organisationen. In beiden, steht
im wesentlichen jedoch das gleiche: der Beitragende gibt dem Projekt
"...unbefristete, weltweite, uneingeschränkte, unentgeltliche,
gebührenfreie, unkündbare Urheberrecht um die Beiträge und davon
abgeleitete Werke zu kopieren, verbreiten und unter neuer Lizenz
herauszugeben." Sie sollten natürlich wieder einen Anwalt
darum bitten, jede CLA zu überprüfen, wenn Sie es jedoch schaffen all
diese Begriffe hineinzubekommen, sollte es kein Problem sein.
Wenn sie von den Beitragenden CLAs anfordern, sollten Sie betonen,
dass Sie nicht um eine tatsächliche Übertragung des
Urheberrechts bitten. Viele CLAs fangen sogar damit an, die Leser daran
zu erinnern:
Es handelt sich hier ausschließlich um eine
Lizenzvereinbarung; es überträgt kein rechtlichen Zuspruch des
Urheberrechts und ändert nichts an Ihrem Recht Ihre Beiträge für irgend
welche anderen Zwecke zu verwenden.
Hier einige Beispiele:
CLAs für Einzelpersonen:
CLAs für Organisationen:
Übertragung vom Urheberrecht
Die Übertragung vom Urheberrecht bedeutet, dass die Beitragende
dem Projekt den Besitz der Urheberrechte auf ihre Beiträge zuspricht. Im
Idealfall wird das in Papierform gemacht und entweder per Fax oder per
Schneckenpost an dem Projekt geschickt.
Manche Projekte bestehen auf die vollständige Übertragung des
Urheberrechts, da es nützlich sein kann wenn jeglicher Code einer
rechtlichen Person gehört, um die Konditionen der Open-Source-Lizenz
vor Gericht durchzusetzen. Wenn keine einzelne Person das Recht hat das
zu machen, müssen vielleicht alle Beteiligte kooperieren, von denen
vielleicht manche keine Zeit haben oder schlicht nicht erreichbar sind,
wenn das Thema aufkommt.
Verschiedene Organisationen sind unterschiedlich streng, wenn es
darum geht, diese Rechte von den Beitragenden einzufordern. Manche
verlangen einfach eine informelle Stellungnahme von dem Freiwilligen auf
einem öffentlichen E-Mail-Verteiler – so etwas wie "Hiermit
übertrage ich das Urheberrecht auf diesem Quellcode auf das Projekt,
sodass es unter der selben Lizenz veröffentlicht wird, wie der übrige
Quellcode." Zumindest, hat ein Anwalt mit dem ich gesprochen habe, mir
gesagt, das wäre ausreichend, vermutlich weil es sich um einen Kontext
handelt, indem die Übertragung vom Urheberrecht üblich ist und sowieso
erwartet wird, und weil es sich auf Seiten des Projekts um ein Akt im
guten Glauben handelt, um die wahren Absichten des Freiwilligen zu
ermitteln. Die Free Software Foundation andererseits, ist ein Beispiel
für das andere Extrem: Sie verlangen von Freiwilligen ein Dokument
Physikalisch zu unterschreiben und zu versenden, indem das Urheberrecht
formal übertragen wird, manchmal schon für einen einzigen Beitrag,
manchmal für aktuelle und zukünftige Beiträge. Wenn der Entwickler ein
Angestellter ist, verlangt die FSF, dass der Betrieb es ebenfalls
unterschreibt.
Die Paranoia der FSF ist verständlich. Wenn jemand die Bedingungen
der GPL verletzt, indem sie eine Teil ihrer Software in eine Proprietäre
Anwendung verwenden, wird die FSF dagegen vor Gericht ankämpfen müssen,
und in dem Fall, wollen sie, dass ihre Uhrheberrechte, so wasserdicht
wie möglich sind. Da die FSF der Inhaber vom Uhrheberrecht für viele
beliebte Anwendungen ist, sehen sie das als eine ernstzunehmende
Möglichkeit an. Ob ihre Organisation im gleichen Maße peinlich genau
arbeiten muss, müssen Sie mit Beratung durch Anwälte entscheiden. Im
Allgemeinen, sollten Sie CLAs bevorzugen, wenn es keinen bestimmte Grund
das Urheberrecht vollständig zu Übertragen; dass macht die Angelegenheit
einfacher für alle beteiligten.
Doppelte Lizenzierung
Manche Projekte versuchen sich durch ein duales Lizenzmodell zu
finanzieren, bei dem proprietäre Derivate dem Inhaber des Urheberrechts
bezahlen können um den Code in ihre Projekte verwenden zu dürfen, der
Code für andere Open-Source-Projekte aber unter einer frei bleibt. Das
funktioniert natürlich meistens besser für Code-Bibliotheken als für
einzelnen Anwendungen. Die genauen Bedingungen unterscheiden sich von
Fall zu Fall. Oftmals ist die freie Lizenz die GNU GPL, da es bereits
andere daran hindert, den davon abgedeckten Code in ihre Proprietären
Anwendungen, ohne Erlaubnis des Urhebers zu benutzen, manchmal ist es
jedoch eine eigens geschriebene Lizenz mit dem gleichen Effekt. Ein
Beispiel für ersteres ist die hier beschriebene MySQL-Lizenz
; ein
Beispiel für Letzteres ist die hier beschriebene Lizenzierung der
Sleepycat Software .
Sie mögen sich vielleicht fragen: Wie kann ein Urheber eine
proprietäre Lizenz für eine Gebühr anbieten, wenn die Bedingungen der GNU
GPL vorgibt, dass der Code unter keiner restriktiveren Lizenz verbreitet
werden darf? Die Antwort darauf, ist dass die Bedingungen der GPL vom
Urheber auf alle anderen auferlegt; es steht dem Urheber deshalb offen,
sich selber diese Bedingungen nicht aufzuerlegen.
Man kann sich das so vorstellen, dass der Urheber unendlich viele
Kopien der Software in einem Eimer hat, es kann sich entscheiden welche
Lizenz dafür gilt: GPL, proprietär, oder etwas anderes. Das Recht das zu
machen ist nicht an die GPL oder irgend einer anderen Open-Source-Lizenz
gebunden; es ist einfach ein durch das Urheberrecht gegebene
Möglichkeit.
Duale Lizenzierung ist attraktiv, da es freie Software eine
Möglichkeit bietet, eine verlässliche Einkommensquelle zu sichern.
Leider, kann es auch die üblichen Abläufen von Open-Source-Projekte
behindern. Das Problem, ist das jede Freiwillige die einen Beitrag
macht, jetzt an zwei verschiedene Einheiten einen Beitrag macht: Der
freien Version vom Code und der proprietären Version. Auch wenn die
Freiwillige gerne zur freien Version etwas beiträgt, da es bei
Open-Source-Projekten üblich ist, mag es ihr nicht ganz genehm sein, zum
teils-proprietären Einkommen von jemand anderem etwas beizutragen. Dieses
Unannehmlichkeit wird noch verschlimmert, da die duale Lizenzierung von
dem Urheber erfordert, formale, unterschriebene Übertragungen der
Urheberrechts einzusammeln, um sich vor einem aufgebrachten
Freiwilligen zu schützen, der im Nachhinein einen Teil der Gebühren
einfordert. Durch diesen Vorgang, werden freiwillige offenkundig, mit der
Tatsache konfrontiert, dass sie Arbeit machen, die jemand anderem Geld
einbringt.
Das wird nicht allen Freiwilligen stören; schließlich werden ihre
Beiträge auch an die Open-Source-Version gehen, und dass mag ihr
Hauptinteresse sein. Duale Lizenzierung ist trotzdem ein Fall bei dem der
Urheber sich selber ein Recht zuspricht, die andere im Projekt nicht
haben, und wird deshalb irgendwann garantiert Spannungen verursachen,
zumindest bei manchen Freiwilligen.
In der Praxis scheinen Firmen die eine duales Lizenzmodell wählen
keine wirklich gleichberechtigte Entwicklergemeinschaft aufzubauen. Sie
bekommen von außen kleine Bugfixes und Patches gegen Unschönheiten,
müssen jedoch die die meiste Arbeit intern erledigen. Zack Urlocker, der
Vizepräsident für Marketing bei MySQL, sagte mir beispielsweise, dass
die Firma aktive Entwickler im Allgemeinen sowieso einstellt. Die
Entwicklung unterliegt deshalb, wenn auch unter der GPL lizenziert, im
wesentlichen der Kontrolle der Firma, wenn auch mit der (äußerst
unwahrscheinlichen) Möglichkeit, dass jemand der wirklich unzufrieden
damit ist, wie die Firma mit dem Projekt umgeht, einen Fork von dem
Projekt machen könnte. In welchem Maße diese Bedrohung, die Politik der
Firma präventiv gestaltet, weiß ich nicht, in jedem Fall scheint MySQL
jedoch keine Akzeptanzprobleme, in der Open-Source-Welt oder sonstwo zu
haben.
PatenteDas Patentrecht in den USA erlaubt Patente
auf Software, bzw. Ideen. Das europäische Patentrecht ist wesentlich
restriktiver. Die Patentierbarkeit "computerimplementierter Erfindungen"
wurde im Juli 2005 vom EU Parlament mit einer Mehrheit von 95%
abgewiesen. Das Thema ist dennoch auch für Europäer relevant, wenn sie
wollen, dass ihre Software in den USA verwendet
wird.
Software-Patente sind derzeit ein brisantes Thema für freie
Software, da sie eine echte Bedrohung bereitstellen, wogegen sich die
freie Software-Gemeinschaft nicht alleine wehren kann. Mit
Uhrheberrecht und Markenrechte kommt man immer irgendwie klar. Wenn ein
Teil vom Code aussieht als ob es die Urheberrechte von jemand verletzt,
kann man den Teil einfach neu schreiben. Wenn es sich herausstellt, dass
jemand das Markenrecht auf den Namen von Ihrem Projekt hat, müssen Sie
im schlimmsten Fall den Namen ändern. Ach wenn das vorübergehend etwas
Unangenehm wäre, macht es auf lange Sicht keinen Unterschied, denn der
eigentliche Code erfüllt immer noch seine Aufgabe.
Ein Patent bietet jedoch eine pauschale Verfügung über die
Implementierung einer Idee. Es macht weder einen Unterschied wer den
Code schreibt, noch welche Sprache dafür verwendet wird. Sobald jemand
ein freies Software-Projekt beschuldigt, ein Patent zu verletzen, muss
das Projekt entweder aufhören diese Funktion zu implementieren, oder
sich auf eine teure und zeitaufwendigen Gerichtsverhandlung gefasst
machen. Da die Anstifter solcher Klagen meistens Firmen mit tiefen
Taschen – diejenigen mit den Ressourcen und der Neigung sich
Patente überhaupt anzueignen – sind, können es sich die meisten
freien Software-Projekte jedoch nicht letztere Möglichkeit leisten, und
müssen sofort aufgeben, auch wenn sie der Meinung sind, das Patent wäre
vor Gericht wahrscheinlich nicht durchsetzbar. Um solch eine Situation
zu vermeiden, fangen freie Software-Projekte an, von vorn herein
defensiv zu programmieren. Sie vermeiden patentierte Algorithmen, auch
wenn sie die beste oder einzig verfügbare Lösung zu einem Problem wären.
Sun Microsystems und IBM haben auch zumindest eine Geste
gemacht, von der anderen Seite des Problems, indem sie eine
Vielzahl – jeweils 1600 und 500 – ihrer Software Patente, für
die Nutzung durch die freie Software-Gemeinschaft freigegeben haben. Ich
bin kein Anwalt und kann deshalb nicht beurteilen, inwiefern diese
Bewilligungen etwas Nützen, aber selbst wenn das alle wichtigen Patente
sind, und ihre Bedingungen sie wirklich für die Nutzung in irgend einem
Open-Source-Projekt freigeben, ist es dennoch nur ein Tropfen auf dem
heißen Stein.
Umfragen und Einzelberichte zeigen jedoch, dass nicht nur die
Mehrheit der Open-Source-Programmierer, sondern die Mehrheit
aller Programmierer der Meinung sind, dass Software
Patente abgeschafft werden sollten.Siehe
für eines
dieser Umfragen. Open-Source-Programmierer sind
meistens besonders Empfindlich wenn es um dieses Thema geht, und weigern
sich an Projekte teilzunehmen, die sich zu sehr mit der Sammlung und
Durchsetzung von Software-Patente assoziieren. Wenn Ihre Organisation
Software-Patente sammelt, sollten Sie klar, öffentlich und
unwiderruflich erklären, dass die Patente niemals gegen Open-Source-Projekte
durchgesetzt werden, und dass sie nur als Verteidigung benutzt
werden, sollte irgend eine andere Organisation gegen Ihre eine Klage
einreichen. Das ist nicht nur das einzig richtig Vorgehen, es ist gute
Beziehungspflege mit der Open-Source-Gemeinschaft.
RedHat sich hat beispielsweise Zugesichert, dass Open-Source-Projekte
sicher vor ihre Patente sind, siehe
.
Leider ist die Sammlung von Patenten als Schutz ein vernünftiges
Vorgehen. Das derzeitige Patentrecht, zumindest in den USA, ist von
Natur aus ein Wettrüsten: wenn ihre Konkurrenten viele Patente habe, ist
ihre beste Defensive, sich selber möglichst viele Patente anzueignen,
sodass wenn Sie von einer Patentklage betroffen sind, Sie mit einer
ähnlichen Drohung reagieren können – danach setzen sich beide
Parteien meistens hin und arbeiten ein Übereinkommen aus, sodass keiner
von beiden etwas zahlen muss, außer natürlich ihren Anwälten.
Der Schaden für freie Software der durch Patente entsteht ist
jedoch heimtückischer als Bedrohungen bei der Entwicklung von Code.
Software-Patente fördern eine Umgebung der Geheimhaltung unter den
Entwicklern von Firmware, die sich berechtigte Sorgen machen, dass die
Veröffentlichung von Details über die Schnittstellen ihren
Konkurrenten eine technische Hilfe gibt, die darauf aus sind gegen ihnen
Patentklagen zu erheben. Das ist nicht nur eine theoretische Gefahr; es
geschieht beispielsweise, offenbar schon seit einiger Zeit in dem Markt
für Grafikkarten. Viele Hersteller von Grafikkarten geben ungern die
Spezifikationen für ihre Karten heraus, die gebraucht werden um
performate Open Source Treiber für ihre Karten zu schreiben. Dadurch
wird es für freie Betriebssysteme unmöglich diese Karten im vollen
Umfang zu unterstützen. Was bringt die Hersteller dazu, sowas zu
machen? Es macht schießlich keinen Sinn für Sie
gegen Software Unterstützung zu arbeiten; mehr
Betriebssysteme mit Unterstützung für ihre Produkte, bedeutet
schließlich mehr verkaufte Karten. Es stellt sich jedoch heraus, dass
hinter den Türen der Entwickler all diese Hersteller, gegenseitig gegen
die Patente der anderen Verstoßen, manchmal bewusst, manchmal aus
versehen. Patente sind etwas derart unvorhersehbares und derart
weitreichend, dass kein Hersteller für Grafikkarten sich ganz sicher
sein kann, selbst nachdem sie nach Patenten gesucht haben. Hersteller
wagen es deshalb nicht, die vollständigen Spezifikationen ihrer
Schnittstellen offenzulegen, da es dadurch viel zu einfach für
Konkurrenten wäre, sich die Patente herauszusuchen, die von ihnen
verletzt werden. (Die Natur dieser Situation ist natürlich derart, dass
man keine schriftliche Bestätigung über die Ereignisse von den Parteien
erhalten würde; Ich habe davon durch persönliche Unterhaltungen
erfahren.)
Manche freie Software-Lizenzen, beinhalten Klausel, um gegen
Software Patente anzukämpfen, oder zumindest um gegen sie zu warnen. Die
GNU GPL hat beispielsweise folgende Passagen:
7. Sollten Ihnen infolge eines Gerichtsurteils, des Vorwurfs einer
Patentverletzung oder aus einem anderen Grunde (nicht auf Patentfragen
begrenzt) Bedingungen (durch Gerichtsbeschluß, Vergleich oder
anderweitig) auferlegt werden, die den Bedingungen dieser Lizenz
widersprechen, so befreien Sie diese Umstände nicht von den
Bestimmungen dieser Lizenz. Wenn es Ihnen nicht möglich ist, das
Programm unter gleichzeitiger Beachtung der Bedingungen in dieser
Lizenz und Ihrer anderweitigen Verpflichtungen zu verbreiten, dann
dürfen Sie als Folge das Programm überhaupt nicht verbreiten. Wenn
zum Beispiel ein Patent nicht die gebührenfreie Weiterverbreitung
des Programms durch diejenigen erlaubt, die das Programm direkt
oder indirekt von Ihnen erhalten haben, dann besteht der einzige
Weg, sowohl das Patentrecht als auch diese Lizenz zu befolgen,
darin, ganz auf die Verbreitung des Programms zu verzichten.
[...]
Zweck diese Paragraphen ist nicht, Sie dazu zu bringen,
irgendwelche Patente oder andere Eigentumsansprüche zu verletzen
oder die Gültigkeit solcher Ansprüche zu bestreiten; dieser
Paragraph hat einzig den Zweck, die Integrität des
Verbreitungssystems der freien Software zu schützen, das durch die
Praxis öffentlicher Lizenzen verwirklicht wird. Viele Leute haben
großzügige Beiträge zu dem großen Angebot der mit diesem System
verbreiteten Software im Vertrauen auf die konsistente Anwendung
dieses Systems geleistet; es liegt am Autor/Geber, zu entscheiden,
ob er die Software mittels irgendeines anderen Systems verbreiten
will; ein Lizenznehmer hat auf diese Entscheidung keinen
Einfluß.Diese Übersetzung von Katja Lachmann im
Auftrag der S.u.S.E. GmbH – und
überarbeitet von Peter
Gerwinski, G-N-U GmbH – ,
wird hier zum besseren Verständnis verwendet und ist keine
offizielle oder im rechtlichen Sinne anerkannte Übersetzung. Die
Englische Originalfassung finden Sie hier . Die vollständige
deutsche Übersetzung der GPL finden Sie hier
Die Apache Lizenz, Version 2.0
() beinhaltet
ebenfalls Bedingungen gegen Patente. Es legt zuerst fest, dass jeder der
Quellcode unter der Lizenz veröffentlicht, eine Gebührenfreie Lizenz
impliziert, für jegliche Patente die sie halten mögen, der sich auf den
Code anwenden ließe. Zweitens und am geistreichsten, bestraft es jeden
der auf Patent-Verletzung in dem betreffenden Werk klagt, indem es
automatisch im Moment einer solchen Klage, ihnen diese implizite Lizenz
entzieht:
3. Lizenzierung von Patanten. Gemäß den Bedingungen dieser Lizenz,
bewilligt jeder Beitragende Ihnen hiermit eine unbefristete, weltweite,
uneingeschränkte, gebührenfreie, unwiderrufliche (außer wie in diesem
Abschnitt beschrieben) Lizenz auf Patente um das Werk zu erstellen,
benutzen, anzubieten, zu verkaufen, importieren oder anderweitig zu
übertragen, wobei besagte Lizenz sich lediglich auf von dem Beitragenden
Lizenzierbare Patentansprüche bezieht, zwangsläufig verletzt durch ihre
Beiträge oder der Kombination ihrer Beiträge mit dem Werk an dem diese
Beiträge gemacht wurden. Sollten Sie gegen irgend jegliche juristische
Person auf Verletzung von Patenten Klagen (einschließlich einer
Gegenforderung in einem Gerichtsverfahren) unter der Behauptung, dass
das Werk oder ein in dem Werk einbezogener Beitrag, direkt oder
teilweise Patente Verletzt, verfallen alle Ihnen durch diese Lizenz
gewährte Patente für das betreffende Werk nach dem Zeitpunkt an dem
besagte Klage eingereicht wird.Diese freie Übersetzung
wird hier zum besseren Verständnis verwendet und ist keine offizielle
oder im rechtlichen Sinne Anerkannt Übersetzung. Die Englische
Originalfassung finden Sie hier .
Auch wenn es nützlich ist, sowohl rechtlich als auch
politisch, freie Software auf diese Art gegen Patente zu schützen,
reichen diese Schritte letztendlich nicht aus, um der gruseligen Wirkung
die Patente auf freie Software haben, Einhalt zu gebieten. Lediglich
Änderungen an dem Inhalt oder der Interpretation vom internationalen
Patentrecht können das erreichen. Um mehr über das Problem zu erfahren,
und wie dagegen angekämpft wird, schauen sie auf . Der Artikel auf Wikipedia
bietet ebenfalls viele nützliche Informationen zum Thema
Software-Patente.
Ich habe auch eine Blog-Eintrag geschrieben, der die Argumente
gegen Software-Patente zusammenfasst
.
Weitere Quellen
Dieses Kapitel war lediglich eine Einführung in das Thema der
Lizenzierung von freier Software. Ich hoffe zwar, dass es genügend
Informationen enthält, damit Sie mit ihrem Projekt anfangen können,
würde jede ernstgemeinte Untersuchung der Lizenzprobleme schnell den
Rahmen dieses Buchs sprengen. Hier sind einige weitere Quellen zum Thema
der Open-Source-Lizenzierung:
Understanding Open Source and Free
Software Licensing von Andrew M. St. Laurent.
Veröffentlicht durch O'Reilly Media, erste Edition August 2004,
ISBN: 0-596-00581-4.
Dieses Buch dreht sich um die ganze Komplexität, bei
der Lizenzierung von Open-Source-Software, inklusive vieler
Themen die hier ausgelassen wurden. Siehe
für weiteres.
Make Your Open Source Software
GPL-Compatible. Or Else. von David
A. Wheeler, auf
.
Dieser gut geschriebene Artikel erzählt, warum es
wichtig ist, Lizenzen zu benutzen, die zur GPL kompatibel
sind, selbst wenn sie nicht die GPL verwenden. Es streift
auch viele weitere Lizenzfragen und hat viele ausgezeichnete
Links.
Creative Commons ist eine Organisation die eine Reihe
weiterer flexibler und liberale Urheberrechte vorantreiben,
entgegen der üblichen Praxis beim Urheberrecht. Sie bieten
diese Lizenzen nicht nur für Software, sondern auch für
Schriften, Kunst, und Musik an, die sich alle bequem online
auswählen lassen; manche sind Copyleft-Lizenzen, manche sind
nicht Copyleft aber dennoch frei, weitere sind wie das
traditionelle Urheberrecht aber etwas aufgelockert. Die
Webseite der Creative Commons bietet eine sehr klare
Darstellung worum es geht, wenn ich eine Seite wählen müsste
um die philosophische Bedeutung der freien Software-Bewegung
zu zeigen, wäre es diese.