Lizenzen, Urheberrecht<footnote><para>Im 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.</para></footnote> und Patente

Lizenzen, Urheberrecht<footnote><para>Im 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.</para></footnote> 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. Patente<footnote><para>Das 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.</para></footnote> 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.