C
Chrisliebaer
Guest
Ich weise darauf hin, dass es sich bei diesem Beitrag um keine rechtliche Beratung im Sinne des Rechtsdienstleistungsgesetz handelt. Dieser Beitrag enthält lediglich mein laienhaftes Rechtswissen, welches ich durch viele Recherchen im Internet gesammelt habe.
Dieser Beitrag ist das Ergebniss meiner Recheren, nachdem im Chat bereits mehrfach die Disskusion darüber aufkam, ob man die Zustimmung des Pluginautors braucht, wenn man seinen Quellcode modifizieren möchte. Es gab auch noch ein paar andere Fragen, welche ich aber im Laufe des Textes erläutern und beantworten möchte. Sofern dieser Beitrag von jemand in teilen oder ganz Kopier wird und an anderer Stelle veröffentlich wird, bitte ich freundlich um Verlinkung auf diesen Thread.
Ich werde in diesem Text den Begriff Bukkit für das gesamte Gebilde (bestehend aus API und Implementierung), als auch für die reine API verwenden. Der Begriff CraftBukkit bezieht sich jedoch nur auf die Implementierung. Da ich der Meinung bin, dass sich dies aus dem Kontext ergibt, habe ich darauf verzichetet, genauer zwischen dem Projekt und der API zu unterscheiden.
Eine Lizenz ist eine Erlaubnis, etwas bestimtes tun zu dürfen oder auch nicht. Im Bereich der Softwareentwicklung, haben Lizenzen den Zweck, zu erläutern, unter welchen Bedingungen man eine Software Nutzen, Verbreiten oder auch Verkaufen darf. Es gibt eine ganze Menge von Lizenzen. Die meiste Software hat eine eigene Lizenz, die von einem oder mehreren Anwälten geschrieben wurde und entsprechend wasserdicht sein sollte. Die Regeln hierbei sind ziehmlich oft im Kern ihrer Aussage gleich: keine Verbreitung, kein Verkauf, keine Modifikationen.
Freie Software
Neben der Vielzahl an kostenpflichtigen Programmen, hat sich auch eine Fraktion durchsetzten können, die der Meinung ist, dass Quelltext frei sein sollten. Der Begriff "frei" bedeutet nicht, dass man den Quellcode ansehen kann, er bedeutet, dass der Anwender sie studieren, verändern und kostenfrei für alle Zwecke nutzen kann. [1]. Hierbei ist vielleicht gleich noch ein Hinweis im Bezug auf "Open Source" angebracht. Der Begriff Open Source hat nichts mit feier Fotware zu tun. Viel mehr sagt er aus, dass der Quellcode einer bestimmten Software offen ist. Manchmal ist darunter auch zu verstehen, dass man den Quellcode für Geld regulär kaufen kann. Der Begriff sagt jedoch nichts darüber aus, ob man den Quellcode auch weitergeben darf. Es gibt z.B. Firmen, die zwar den Quellcode ihrer Programme offen legen, jedoch die Modifikation oder auch Verbreitung verbieten.
Um sicherzustellen, dass niemand diese Offenheit missbraucht, hat es Lizenzen gebraucht, die ebenfalls wasserdicht sind und auch von einem Rechtslaien angewand werden können. Besonders wichtig sind hierbei die GPL[2] und die LGPL[3] (Vor allem auch für Bukkit).
Die "Spielregeln" sind auch für einen Laien erkennbar und er bekommt von der FSF[4] sogar Hilfe bei der Anwendung. Es handelt sich somit um eine Möglichkeit, mit dem ein Programmierer, auch ohne großes Rechtswissen, sicherstellen kann, dass mit seiner Arbeit nur genau das gemacht wird, was er möchte.
GPL
Die GPL ist eine sehr restriktive Lizenz für freie Software. Sie hat ein strenges Copyleft, was bedeutet, dass sowohl das Werk selbst, als auch alle abstammenden Werke wiederum unter die GPL veröffentlich werden müssen. Dies ist auch immer wieder Kritikpunkt an ihr gewesen. Trozdem hat sie eine sehr weite Verbreitung, da sie sicherstellt, dass niemand die Software in geschlossenen Code umwandeln , oder unter anderen restriktiveren Lizenzen vertreiben kann. Entscheident ist hierbei das Verb "vertreiben", auf das ich gegen Ende nochmal zurück kommen werde. Software, die unter der GPL lizensiert ist, darf z.B. verkauft werden oder von jedem Besitzer kopiert werden. Eine sehr bekannte Software, die unter der GPL lizensiert ist, ist der Linux-Kernel. Nicht zuletzt desshalb, ist der Linux-Kernel in nahezu jedem Router, Handy und Auto "verbaut". Anpassungen sind durch die Offenheit leicht durchzuführen und man kann auf eine schier grenzenlose Menge an Erweiterungen von anderen zugreifen. Dies kann allerdings auch zu einem Problem werden: Möchte man beispielsweise einen, unter der GPL lizensierten, Bildcodec in seine Software einbinden, so muss dadurch die gesamte Software ebenfalls unter der GPL veröffentlich werden und damit auch der Sourcecode.
LGPL
Die LGPL versucht dieses Problem zu umgehen. Das reine "Linken"[5] gegen eine LGPL-Kompontente, erfordert nicht das lizensieren der Software unter der GPL oder LGPL. Der Autor kann immernoch selbst darüber entscheiden ob der die Software z.B. unter einer eigenen Lizenz veröffentlichen möchte. Das L in LGPL steht übrigens für "Lesser" (engl. weniger). Das bezieht sich auf eben diesen Sachverhalt.
Nur wer direkte Änderungen an einer LGPL-Komponenten macht, muss diese offenlegen. Somit ist sichergestellt, dass die Qualität der Komponente selbst stetig steigt, während die "Benutzer" trozdem die Freiheit behalten, ihre Software anderst zu lizensieren. Als Fausregel gilt hier: Die LGPL-Komponenten muss selbständig kompilierbar bleiben. Es gibt jedoch aus Ausnahmen, welche jedoch immer für den Einzelfall betrachted werden müssen. Sofern eine Software die LGPL-Komponente nichtmehr "verwendet", sondern sie mehr oder weniger in ihrem Sinn "erweitert", findet die Sonderregelung der LGPL keine Anwendung.
An der Stelle auch ein kleines Beispiel von manf: Seine Idee war es, dass man eine eigene API schreibt, welche man in den eigenen Plugins implementiert. Da diese API keine Abhängigkeiten zur Bukkit-API hat, fällt sie nicht unter die GPL. Nun entwickelt man ein Bukkit-Plugin, welches diese API benutzt, um die eigenen Plugins zu laden. Außerdem muss diese Komponente alle Events von Bukkit an das eigene Plugin weiterleiten. Das ganze lies sich also so darstellen:
Craftbukkit <---> Bukkit (API) <---> Eigener Wrapper <---> selbstgeschriebene API für eigene Plugins <---> Eigene Plugins
GPL/LGP-Code
frei lizensierbarer Code
Da die eigene API absolut unabhängig vom Rest ist, könnte der Eindruck enstehen, dass man auf diese Weise indirekt gegen Bukkit linken kann, ohne sich an die GPL halten zu müssen. Nach allem, was ich aber gefunden habe, ist dem nicht so. Der Grund liegt darin, dass sowohl die eigene API, als auch die Plugins, die sie verwenden nicht ohne die funktionen von Bukkit existieren können. Ihr einziger Grund ist das umgehen der GPL und sie sind auch nie für etwas anderes gedacht gewesen. Ein Interessantes Beispiel hierzu ist NVIDIA. Damit diese ihren Code auf Linux verwenden können, haben sie einen Wrapper geschrieben, welcher zwischen Treiber und Linuxkernel sitzt. Da diese Treiber jedoch für Windows gedacht waren und der Wrapper lediglich eine Brücke darstellt, ohne die der Treiber trozdem unter Windows laufen würde, wird dies tolleriert, auch wenn es umstritten ist.
Urheberschaft
Jeder, der Code erzeugt, hält in der Regel[6], daran das Urheberrecht (oder im engl. Copyright). Im deutschen Recht, kann ein Urheber seine Urheberschaft nicht völlig abtreten. Dies führt zu interessanten Situationen:
Ich entwickle eine Software, welche diverse mathematische Probleme lösen kann und veröffentliche sie unter der GPL auf github. Nun finden viele Leute meine Software toll und erweitern sie. Um den Gedanken von freier Software zu pflegen, committen sie ihre Änderungen in mein Projekt und ich fügen den Sourcecode zusammen. Das daraus entstehende Werk, wird eine Teilarbeit von verschiedenen Urhebern. Jeder Teil, welcher die Schöpfungshöhe erreicht und in die Codebasis kommt, macht seinen Urheber zu einem Teil der Urheber für dieses Projekt. Er bekommt eine Miturheberschaft.
Nun hat diese Software auch ein Unternehmen auf den Plan gerufen: Diese möchte die Software gerne um eigene Funktionen erweitern, aber da diese Änderungen viel Geld kosten, sollen sie nicht veröffentlich werden. Das Unternehmen wäre auch bereit dafür Geld zu bezahlen. Nun entsteht eine interessante Situation. Da ich das Urheberrecht an meinem Code noch immer halte, kann ich MEINE Teile des Codes für diese Firma neu lizensieren und ihr verkaufen. Ich kann jedoch nicht den gesamten Code neu lizensieren, denn das können nur die jeweiligen Autoren selbst. Also wendet sich die Firma auch an diese (sofern diese noch zu erreichen sind) und bittet um eine eigene Lizenz. Da jedoch die anderen Autoren nur auf anderem Code (meinem oder den eines anderen Autoren) aufbauen, können diese gar keine Zustimmung geben.
Man kann sich das vorstellen, wie ein Baum. Um bestimmte Teiles des Codes neu lizensieren zu dürfen, müssen alle vorherigen Autoren gefragt werden. Da Änderungen jedoch nur selten genau einen Teil betreffen, sondern das Projekt im gesamten Umfassen, benötigt es die Zustimmung aller Autoren für eine neue Lizenz. Es wird schnell klar, dass es recht schnell unmöglich wird, den Code unter einen zweiten Lizenz zu lizensieren.
Bukkit
Bei Bukkit stoßen wir sogar auf eine extrem merkwürdige Lizensierung. Craftbukkit selbst ist unter der LGPL lizensiert. Die API von Craftbukkit, also Bukkit ist widerum unter GPL lizensiert. Wer nun aufgepasst hat, der wird merken, dass demnach auch CraftBukkit unter der GLP lizensiert sein muss, da Craftbukkit gegen die API linken muss und das auch tut, das ist es jedoch nicht. Rechtlich ist das auch nicht in Ordnung und Craftbukkit verletzt damit die GPL. Es gibt dazu auch einen sehr interessanten Beitrag im Bukkit-Forum.
Und nun wollen wir den Wahnsinn perfektionieren. Wenn ich die GPL verwende, dann möchte ich, dass niemand meine Arbeit als Grundlage missbraucht. Dies hätte sich wunderbar für Craftbukkit, also den Kern des Servers angeboten. Somit wäre die Entwicklung von Craftbukkit sichergestellt gewesen. Dies wurde jedoch nicht gemacht. Über die Gründe kann nur spekulliert werden. Ich tippe auf Unwissenheit und zu schnelle Entscheidungen. Im Gegenzug, hätte dafür eigentlich die API als LGPL lizensiert werden, damit Pluginentwickler die Möglichkeit haben, ihre Plugins auch ohne Sourcecode zu veröffentlichen. Beides wurde jedoch nicht gemacht und daher kommen wir zu eine Schluss.
Lizenz von Plugins
Da alle Plugins gegen die API, also Bukkit linken, findet die GPL Anwendung. Daraus folgt unweigerlich, dass jedes Plugin unter der GPL veröffentlich werden muss. Allein dies, wird von vielen nicht beachtet und stellt damit eine Verletzung der GPL dar. Ein Pluginautor hat keine Möglichkeit die Modifikation, Verbreitung oder auchEntfernung seines Namens zu verhindern Es kann ein vermerkt auf den Autoren beigelegt werden, alle Dateien müssen weiterhin mitveröffentlich werden, wenn sie Teil der Lizenz sind.. Außerdem muss der Quellcode in lesbarer Form vorliegen - obfuscated ist nicht[7].
Zeitpunkt der Offenlegung von Quellcode
Wer die Software für private Zwecke oder nur für die interne Verwendung benutzt und dafür Modifikationen durchführt, braucht diese nicht offen zu legen. Genau genommen ist in der GPL nur von "distribution" die Rede, also von der Verteilung einer modifizierten Version der Software. Nun haben wir aber bei einem Plugin erstmal keine Verteilung vorliegen. Das Plugin befindet sich ja nur auf dem Server. In der GPL wird nur geregelt, wie die Software weitergegeben werden muss. Da Cabraca das inzwischen sehr schön zusammengefasst hat, kopieren ich diesen Text einfach hier rein:
Durchsetzung der Rechte
Auch wenn das Bukkit-Team erklärt hat, dass sie ihre Rechte aus der GPL nicht durchsetzten werden, schützt dies nicht vor anderen Autoren, die nur gelegentlich oder einmalig Code an Bukkit übertragen haben. Wie bereits erwähnt, ist jeder Miturheber und kann daher seine Rechte auch gerichtlich Durchsetzten. Ob er es tut ist natürlich eine ganz andere Frage. Dies bedeutet jedoch auch, dass nur Urheber der API die Einhaltung der GPL von euch fordern können. Solange sie das nicht tun, gibt es niemanden, der dies verlangen kann. Das Problem ist nämlich, dass ihr nicht einfach annehmen könnt, dass ein Plugin unter der GPL veröffentlicht wurde. Es wäre ja sogar möglich, dass der Autor von allen Urhebern von Bukkit eine Zustimmung hierfür hat.
Fragensammlung
Hier ein paar Fragen, die ich immer wieder sehe, wenn es um die Lizenz von Bukkitplugins geht.
Darf ich also jedes Plugin bearbeiten, auch wenn es der Autor verbietet?
Nein! Ihr müsst euch an die Lizenz halten, unter der ihr das Plugin erworben habt. Auch wenn der Autor den Code eigentlich unter der GPL lizensieren müsste, so geht euch das nichts an. Ihr befindet euch auf der anderen Seite in der Wertschöpfungskette, was davor passiert kann euch egal sein.
Sind meine Plugins automatisch als GPL lizensiert?
Nein. Automatisch wird gar nichts lizensiert. Wenn ihr das Plugin nicht unter der GPL lizensiert, dann ist es auch nicht unter der GPL lizensiert. Ihr verstoßt dann halt gegen das Urheberrecht des Autoren, aber das kommt erst dann zum tragen, wenn er sein Urheberrecht geltend macht. Ihr könnt eure Plugins also lizensieren wie ihr wollt.
Wieso darf ich mit meinem Code nicht machen, was ich will?
Weil so nunmal die GPL funktioniert. Entweder ihr seid damit einverstanden, oder ihr seid es nicht. Beides geht nicht. In diesem Zusammenhang les ich auch oft, dass man ja Bukkit "nur benutzt". Das ist natürlich total egal, denn GENAU dafür gibt es die GPL. Sollte es wirklich darauf ankommen, zieht ihr auch definitiv den Kürzeren. In der Vergangenheit gab es schon mehrere Urteile in Deutschland, die einem Autoren einer GPL-Software recht zugesprochen haben und Klänger waren immer riesige Firmen, die sich bestimmt bessere Anwälte leisten konnten als ihr.
Okay, ich will das nun richtig machen, wer muss alles den Quellcode bekommen?
Im Grunde jeder, der auch eure Software bekommt, also die .jar-Datei. Wenn ihr euer Plugin auf DevBukkit anbietet, stellt ihr es dem gesamten Internet zur Verfügung und damit müsst ihr auch dem gesamten Internet den Quellcode zugänglich machen. Wenn ihr euer Plugin verkauft, dann müssen alle Käufer den Quellcode erhalten können. Eine extra Gebühr für den Quellcode ist nicht gestattet. Und weil ich das auch schon gelesen habe: Die Bukkitautoren müssen den Quellcode auch nur dann bekommen, wenn sie sich irgendwie das Plugin besorgen können. Wenn ihr das Plugin also verkauft, ist dies also nicht notwendig.
Aber dann können die Leute ja mein Plugin modifizieren!
Richtig und genau dafür ist die GPL da. Damit Leute die Software, die sie verwenden studieren und modifizieren können. Und die GPL geht da sogar noch weiter und erlaubt jedem Käufer eines kostenpflichtigen Plugins die kostenfreie oder kostenpflichtige weitergabe an andere.
Fazit
Wer Plugins also nicht unter der GPL veröffentlich, verletzt das Copyright der Bukkitautoren. Solange diese jedoch nichts dagegen tun, passiert euch auch nichts. Das Problem ist, wie gesagt, nur die Miturheberschaft diverser Autoren, welche alle die Möglichkeit haben, gegen euch rechtlich vorzugehen.
Dieser Beitrag ist das Ergebniss meiner Recheren, nachdem im Chat bereits mehrfach die Disskusion darüber aufkam, ob man die Zustimmung des Pluginautors braucht, wenn man seinen Quellcode modifizieren möchte. Es gab auch noch ein paar andere Fragen, welche ich aber im Laufe des Textes erläutern und beantworten möchte. Sofern dieser Beitrag von jemand in teilen oder ganz Kopier wird und an anderer Stelle veröffentlich wird, bitte ich freundlich um Verlinkung auf diesen Thread.
Ich werde in diesem Text den Begriff Bukkit für das gesamte Gebilde (bestehend aus API und Implementierung), als auch für die reine API verwenden. Der Begriff CraftBukkit bezieht sich jedoch nur auf die Implementierung. Da ich der Meinung bin, dass sich dies aus dem Kontext ergibt, habe ich darauf verzichetet, genauer zwischen dem Projekt und der API zu unterscheiden.
Eine Lizenz ist eine Erlaubnis, etwas bestimtes tun zu dürfen oder auch nicht. Im Bereich der Softwareentwicklung, haben Lizenzen den Zweck, zu erläutern, unter welchen Bedingungen man eine Software Nutzen, Verbreiten oder auch Verkaufen darf. Es gibt eine ganze Menge von Lizenzen. Die meiste Software hat eine eigene Lizenz, die von einem oder mehreren Anwälten geschrieben wurde und entsprechend wasserdicht sein sollte. Die Regeln hierbei sind ziehmlich oft im Kern ihrer Aussage gleich: keine Verbreitung, kein Verkauf, keine Modifikationen.
Freie Software
Neben der Vielzahl an kostenpflichtigen Programmen, hat sich auch eine Fraktion durchsetzten können, die der Meinung ist, dass Quelltext frei sein sollten. Der Begriff "frei" bedeutet nicht, dass man den Quellcode ansehen kann, er bedeutet, dass der Anwender sie studieren, verändern und kostenfrei für alle Zwecke nutzen kann. [1]. Hierbei ist vielleicht gleich noch ein Hinweis im Bezug auf "Open Source" angebracht. Der Begriff Open Source hat nichts mit feier Fotware zu tun. Viel mehr sagt er aus, dass der Quellcode einer bestimmten Software offen ist. Manchmal ist darunter auch zu verstehen, dass man den Quellcode für Geld regulär kaufen kann. Der Begriff sagt jedoch nichts darüber aus, ob man den Quellcode auch weitergeben darf. Es gibt z.B. Firmen, die zwar den Quellcode ihrer Programme offen legen, jedoch die Modifikation oder auch Verbreitung verbieten.
Um sicherzustellen, dass niemand diese Offenheit missbraucht, hat es Lizenzen gebraucht, die ebenfalls wasserdicht sind und auch von einem Rechtslaien angewand werden können. Besonders wichtig sind hierbei die GPL[2] und die LGPL[3] (Vor allem auch für Bukkit).
Die "Spielregeln" sind auch für einen Laien erkennbar und er bekommt von der FSF[4] sogar Hilfe bei der Anwendung. Es handelt sich somit um eine Möglichkeit, mit dem ein Programmierer, auch ohne großes Rechtswissen, sicherstellen kann, dass mit seiner Arbeit nur genau das gemacht wird, was er möchte.
GPL
Die GPL ist eine sehr restriktive Lizenz für freie Software. Sie hat ein strenges Copyleft, was bedeutet, dass sowohl das Werk selbst, als auch alle abstammenden Werke wiederum unter die GPL veröffentlich werden müssen. Dies ist auch immer wieder Kritikpunkt an ihr gewesen. Trozdem hat sie eine sehr weite Verbreitung, da sie sicherstellt, dass niemand die Software in geschlossenen Code umwandeln , oder unter anderen restriktiveren Lizenzen vertreiben kann. Entscheident ist hierbei das Verb "vertreiben", auf das ich gegen Ende nochmal zurück kommen werde. Software, die unter der GPL lizensiert ist, darf z.B. verkauft werden oder von jedem Besitzer kopiert werden. Eine sehr bekannte Software, die unter der GPL lizensiert ist, ist der Linux-Kernel. Nicht zuletzt desshalb, ist der Linux-Kernel in nahezu jedem Router, Handy und Auto "verbaut". Anpassungen sind durch die Offenheit leicht durchzuführen und man kann auf eine schier grenzenlose Menge an Erweiterungen von anderen zugreifen. Dies kann allerdings auch zu einem Problem werden: Möchte man beispielsweise einen, unter der GPL lizensierten, Bildcodec in seine Software einbinden, so muss dadurch die gesamte Software ebenfalls unter der GPL veröffentlich werden und damit auch der Sourcecode.
LGPL
Die LGPL versucht dieses Problem zu umgehen. Das reine "Linken"[5] gegen eine LGPL-Kompontente, erfordert nicht das lizensieren der Software unter der GPL oder LGPL. Der Autor kann immernoch selbst darüber entscheiden ob der die Software z.B. unter einer eigenen Lizenz veröffentlichen möchte. Das L in LGPL steht übrigens für "Lesser" (engl. weniger). Das bezieht sich auf eben diesen Sachverhalt.
Nur wer direkte Änderungen an einer LGPL-Komponenten macht, muss diese offenlegen. Somit ist sichergestellt, dass die Qualität der Komponente selbst stetig steigt, während die "Benutzer" trozdem die Freiheit behalten, ihre Software anderst zu lizensieren. Als Fausregel gilt hier: Die LGPL-Komponenten muss selbständig kompilierbar bleiben. Es gibt jedoch aus Ausnahmen, welche jedoch immer für den Einzelfall betrachted werden müssen. Sofern eine Software die LGPL-Komponente nichtmehr "verwendet", sondern sie mehr oder weniger in ihrem Sinn "erweitert", findet die Sonderregelung der LGPL keine Anwendung.
- Wir nutzen eine Chatlibrary um einen grafischen Client zu programmieren: Da wird die eigentliche Funktion der Library (Der Nachrichtenaustausch zwischen 2 Nutzern) nicht erweitert haben, können wir unseren Chat nun lizensieren, wie wir möchten.
- Wir nutzen eine Chatlibrary und senden anstelle von Nachrichten einen Videostream: Die Library wurde nun benutzt, um mit Hilfe von ihr, eine Funktion zu implementieren, welche die Library um ihre Funktion (den Nachrichtenaustausch) erweitern würde. Es wäre also möglich, dass wir kein neues Werk geschaffen haben, sondern die Library nur erweitert haben und somit nicht von der Sonderregelung gebrauch machen können.
An der Stelle auch ein kleines Beispiel von manf: Seine Idee war es, dass man eine eigene API schreibt, welche man in den eigenen Plugins implementiert. Da diese API keine Abhängigkeiten zur Bukkit-API hat, fällt sie nicht unter die GPL. Nun entwickelt man ein Bukkit-Plugin, welches diese API benutzt, um die eigenen Plugins zu laden. Außerdem muss diese Komponente alle Events von Bukkit an das eigene Plugin weiterleiten. Das ganze lies sich also so darstellen:
Craftbukkit <---> Bukkit (API) <---> Eigener Wrapper <---> selbstgeschriebene API für eigene Plugins <---> Eigene Plugins
GPL/LGP-Code
frei lizensierbarer Code
Da die eigene API absolut unabhängig vom Rest ist, könnte der Eindruck enstehen, dass man auf diese Weise indirekt gegen Bukkit linken kann, ohne sich an die GPL halten zu müssen. Nach allem, was ich aber gefunden habe, ist dem nicht so. Der Grund liegt darin, dass sowohl die eigene API, als auch die Plugins, die sie verwenden nicht ohne die funktionen von Bukkit existieren können. Ihr einziger Grund ist das umgehen der GPL und sie sind auch nie für etwas anderes gedacht gewesen. Ein Interessantes Beispiel hierzu ist NVIDIA. Damit diese ihren Code auf Linux verwenden können, haben sie einen Wrapper geschrieben, welcher zwischen Treiber und Linuxkernel sitzt. Da diese Treiber jedoch für Windows gedacht waren und der Wrapper lediglich eine Brücke darstellt, ohne die der Treiber trozdem unter Windows laufen würde, wird dies tolleriert, auch wenn es umstritten ist.
Urheberschaft
Jeder, der Code erzeugt, hält in der Regel[6], daran das Urheberrecht (oder im engl. Copyright). Im deutschen Recht, kann ein Urheber seine Urheberschaft nicht völlig abtreten. Dies führt zu interessanten Situationen:
Ich entwickle eine Software, welche diverse mathematische Probleme lösen kann und veröffentliche sie unter der GPL auf github. Nun finden viele Leute meine Software toll und erweitern sie. Um den Gedanken von freier Software zu pflegen, committen sie ihre Änderungen in mein Projekt und ich fügen den Sourcecode zusammen. Das daraus entstehende Werk, wird eine Teilarbeit von verschiedenen Urhebern. Jeder Teil, welcher die Schöpfungshöhe erreicht und in die Codebasis kommt, macht seinen Urheber zu einem Teil der Urheber für dieses Projekt. Er bekommt eine Miturheberschaft.
Nun hat diese Software auch ein Unternehmen auf den Plan gerufen: Diese möchte die Software gerne um eigene Funktionen erweitern, aber da diese Änderungen viel Geld kosten, sollen sie nicht veröffentlich werden. Das Unternehmen wäre auch bereit dafür Geld zu bezahlen. Nun entsteht eine interessante Situation. Da ich das Urheberrecht an meinem Code noch immer halte, kann ich MEINE Teile des Codes für diese Firma neu lizensieren und ihr verkaufen. Ich kann jedoch nicht den gesamten Code neu lizensieren, denn das können nur die jeweiligen Autoren selbst. Also wendet sich die Firma auch an diese (sofern diese noch zu erreichen sind) und bittet um eine eigene Lizenz. Da jedoch die anderen Autoren nur auf anderem Code (meinem oder den eines anderen Autoren) aufbauen, können diese gar keine Zustimmung geben.
Man kann sich das vorstellen, wie ein Baum. Um bestimmte Teiles des Codes neu lizensieren zu dürfen, müssen alle vorherigen Autoren gefragt werden. Da Änderungen jedoch nur selten genau einen Teil betreffen, sondern das Projekt im gesamten Umfassen, benötigt es die Zustimmung aller Autoren für eine neue Lizenz. Es wird schnell klar, dass es recht schnell unmöglich wird, den Code unter einen zweiten Lizenz zu lizensieren.
Bukkit
Bei Bukkit stoßen wir sogar auf eine extrem merkwürdige Lizensierung. Craftbukkit selbst ist unter der LGPL lizensiert. Die API von Craftbukkit, also Bukkit ist widerum unter GPL lizensiert. Wer nun aufgepasst hat, der wird merken, dass demnach auch CraftBukkit unter der GLP lizensiert sein muss, da Craftbukkit gegen die API linken muss und das auch tut, das ist es jedoch nicht. Rechtlich ist das auch nicht in Ordnung und Craftbukkit verletzt damit die GPL. Es gibt dazu auch einen sehr interessanten Beitrag im Bukkit-Forum.
Und nun wollen wir den Wahnsinn perfektionieren. Wenn ich die GPL verwende, dann möchte ich, dass niemand meine Arbeit als Grundlage missbraucht. Dies hätte sich wunderbar für Craftbukkit, also den Kern des Servers angeboten. Somit wäre die Entwicklung von Craftbukkit sichergestellt gewesen. Dies wurde jedoch nicht gemacht. Über die Gründe kann nur spekulliert werden. Ich tippe auf Unwissenheit und zu schnelle Entscheidungen. Im Gegenzug, hätte dafür eigentlich die API als LGPL lizensiert werden, damit Pluginentwickler die Möglichkeit haben, ihre Plugins auch ohne Sourcecode zu veröffentlichen. Beides wurde jedoch nicht gemacht und daher kommen wir zu eine Schluss.
Lizenz von Plugins
Da alle Plugins gegen die API, also Bukkit linken, findet die GPL Anwendung. Daraus folgt unweigerlich, dass jedes Plugin unter der GPL veröffentlich werden muss. Allein dies, wird von vielen nicht beachtet und stellt damit eine Verletzung der GPL dar. Ein Pluginautor hat keine Möglichkeit die Modifikation, Verbreitung oder auch
Zeitpunkt der Offenlegung von Quellcode
Wer die Software für private Zwecke oder nur für die interne Verwendung benutzt und dafür Modifikationen durchführt, braucht diese nicht offen zu legen. Genau genommen ist in der GPL nur von "distribution" die Rede, also von der Verteilung einer modifizierten Version der Software. Nun haben wir aber bei einem Plugin erstmal keine Verteilung vorliegen. Das Plugin befindet sich ja nur auf dem Server. In der GPL wird nur geregelt, wie die Software weitergegeben werden muss. Da Cabraca das inzwischen sehr schön zusammengefasst hat, kopieren ich diesen Text einfach hier rein:
Durchsetzung der Rechte
Auch wenn das Bukkit-Team erklärt hat, dass sie ihre Rechte aus der GPL nicht durchsetzten werden, schützt dies nicht vor anderen Autoren, die nur gelegentlich oder einmalig Code an Bukkit übertragen haben. Wie bereits erwähnt, ist jeder Miturheber und kann daher seine Rechte auch gerichtlich Durchsetzten. Ob er es tut ist natürlich eine ganz andere Frage. Dies bedeutet jedoch auch, dass nur Urheber der API die Einhaltung der GPL von euch fordern können. Solange sie das nicht tun, gibt es niemanden, der dies verlangen kann. Das Problem ist nämlich, dass ihr nicht einfach annehmen könnt, dass ein Plugin unter der GPL veröffentlicht wurde. Es wäre ja sogar möglich, dass der Autor von allen Urhebern von Bukkit eine Zustimmung hierfür hat.
Fragensammlung
Hier ein paar Fragen, die ich immer wieder sehe, wenn es um die Lizenz von Bukkitplugins geht.
Darf ich also jedes Plugin bearbeiten, auch wenn es der Autor verbietet?
Nein! Ihr müsst euch an die Lizenz halten, unter der ihr das Plugin erworben habt. Auch wenn der Autor den Code eigentlich unter der GPL lizensieren müsste, so geht euch das nichts an. Ihr befindet euch auf der anderen Seite in der Wertschöpfungskette, was davor passiert kann euch egal sein.
Sind meine Plugins automatisch als GPL lizensiert?
Nein. Automatisch wird gar nichts lizensiert. Wenn ihr das Plugin nicht unter der GPL lizensiert, dann ist es auch nicht unter der GPL lizensiert. Ihr verstoßt dann halt gegen das Urheberrecht des Autoren, aber das kommt erst dann zum tragen, wenn er sein Urheberrecht geltend macht. Ihr könnt eure Plugins also lizensieren wie ihr wollt.
Wieso darf ich mit meinem Code nicht machen, was ich will?
Weil so nunmal die GPL funktioniert. Entweder ihr seid damit einverstanden, oder ihr seid es nicht. Beides geht nicht. In diesem Zusammenhang les ich auch oft, dass man ja Bukkit "nur benutzt". Das ist natürlich total egal, denn GENAU dafür gibt es die GPL. Sollte es wirklich darauf ankommen, zieht ihr auch definitiv den Kürzeren. In der Vergangenheit gab es schon mehrere Urteile in Deutschland, die einem Autoren einer GPL-Software recht zugesprochen haben und Klänger waren immer riesige Firmen, die sich bestimmt bessere Anwälte leisten konnten als ihr.
Okay, ich will das nun richtig machen, wer muss alles den Quellcode bekommen?
Im Grunde jeder, der auch eure Software bekommt, also die .jar-Datei. Wenn ihr euer Plugin auf DevBukkit anbietet, stellt ihr es dem gesamten Internet zur Verfügung und damit müsst ihr auch dem gesamten Internet den Quellcode zugänglich machen. Wenn ihr euer Plugin verkauft, dann müssen alle Käufer den Quellcode erhalten können. Eine extra Gebühr für den Quellcode ist nicht gestattet. Und weil ich das auch schon gelesen habe: Die Bukkitautoren müssen den Quellcode auch nur dann bekommen, wenn sie sich irgendwie das Plugin besorgen können. Wenn ihr das Plugin also verkauft, ist dies also nicht notwendig.
Aber dann können die Leute ja mein Plugin modifizieren!
Richtig und genau dafür ist die GPL da. Damit Leute die Software, die sie verwenden studieren und modifizieren können. Und die GPL geht da sogar noch weiter und erlaubt jedem Käufer eines kostenpflichtigen Plugins die kostenfreie oder kostenpflichtige weitergabe an andere.
Fazit
Wer Plugins also nicht unter der GPL veröffentlich, verletzt das Copyright der Bukkitautoren. Solange diese jedoch nichts dagegen tun, passiert euch auch nichts. Das Problem ist, wie gesagt, nur die Miturheberschaft diverser Autoren, welche alle die Möglichkeit haben, gegen euch rechtlich vorzugehen.
Zuletzt bearbeitet von einem Moderator:
