GPL-Komponente kapseln und in closed-source software verwenden?
In anderen Threads wurde ja schon reichlich über GPL-Lizenzen diskutiert. Ich habe aber trotzdem nochmal eine konkrete Frage.
In GPL in Teilen meines Softwaresystems ist ja die Rede davon, dass man die GPL-Komponent quasi "kapseln" kann und sie nur noch 'indirekt' verwendet.
Ich stehe gerade vor dem Problem, dass ich gerne eine GPL-V3-Lizenzierte Bibliothek in einer kommerziellen Software einsetzten möchte.
Natürlich kann ich nicht den Quellcode des gesamten Projektes offenlegen. Nicht zuletzt, weil darin auch verschiedene 3rd-Party Komponenten verwendet werden, zu schützendes Know-How darin steckt usw, usw...
Die Struktur sieht so aus, dass ich eine DLL habe, welche intern wiederum Klassen aus der GPL-Bibliothek verwendet. Diese DLL kapselt sozusagen die Verwendung der GPL-Komponente. Alle anderen Komponenten verweisen nur auf diese DLL und nicht direkt auf die GPL-Bibliothek. Es wäre kein Problem diese eine von mir entwickelte DLL mit dem direkten Verweis auf die GPL-Lib auch unter GPL zu stellen und den Source-Code zu veröffentichen, aber das dürfte sich natürlich nicht auf das gesamte Projekt auswirken.
Wenn ich die GPL richtig verstanden habe, müsste ja wiederum jede Komponente, die meine eigene GPL-Bibliothek verwendet, auch wieder unter GPL stehen. Aber gibt es da nicht eine Grenze, bzw. Ausnahme, da ich ja Autor und Rechteinhaber dieser Komponente bin?
Kann das so funktionieren und wäre das rechtlich (eurer Meinung nach) in Ordnung?
P.S.: Ich weiß natürlich, dass hier niemand rechtlich verbindliche Einschätzungen geben kann, aber eine Diskussion und Meinungsaustausch zum Thema wäre trotzdem hilfreich.
Hallo DFDotNet,
nein, GPL ist virulent. Wenn du auf GPL-Komponenten aufbaust, bist du nicht mehr frei in der Lizenz für den von dir geschrieben Teil. Du musst GPL (oder eine kompatible Lizenz) verwenden. In deinem Szenario müsstest du das ganze Projekt unter GPL stellen oder auf die GPL-Komponente verzichten.
In dem anderen Thread ging es um ein echte Client-Server-Anwendung. Die Aufteilung zwischen Client und Server hat sich ganz natürlich ergeben. Ich rate dir dringend davon ab, in deinem Fall eine künstliche Aufteilung in Client und Server vorzunehmen, um die GPL zu umgehen.
herbivore
GPL ist mit Absicht als virulente Lizenz gedacht.
Die Macher sind der Meinung das alles und jede Software offen sein sollte, und durch die GPL wollen sie das "sicherstellen".
Es gibt aber inzwischen fast keinen Bereich der nicht ebenso gut durch LGPL oder echte freie Lizenzen abgedeckt ist.
Welche Bibliotek benutzt du denn?
Hmm, dann ist es doch so wie befürchtet.
Dann werde ich darauf wohl verzichten müssen.
Es geht um ILNumerics.Net. Die Haupt-Bibliothek steht unter LGPL, aber ILNumerics.Drawing steht leider unter GPL.
Evtl. kontaktiere ich den Autor auch mal direkt.
Danke schonmal für die Antworten.
Hallo!
Wie sieht es denn dann aus, wenn man eine Anwendung hat, welche für externe Anbindungen eine Schnittstelle bereitstellt, welche dynamisch Module nachladen kann.
Wenn die Schnittstellenbeschreibung offen liegt und ich einen Wrapper schreibe, welche die Closed-Source-Anwendung über die Schnittstelle mit einer GPL-Komponente verbindet, müsste es dann nicht ausreichen, wenn der Code des Wrappers offen liegt?
Nobody is perfect. I'm sad, i'm not nobody 🙁
Wie sieht es denn dann aus, wenn man eine Anwendung hat, welche für externe Anbindungen eine Schnittstelle bereitstellt
Interessanter Gedanke, vorallem in Bezug auf Anwendungen die Plugin-Systeme beinhalten.
Wenn ein Nutzer der Anwendung ein Plugin schreibt, was auf eine GPL Bibliothek zugreift kann ja keiner vom Entwickler verlangen seinen Source offen zu legen. Lediglich das Plugin selbst müsste dann aus meiner Sicht unter die GPL gestellt werden.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Ja, aber nur wenn dieses System nicht explizit dafür gedacht ist, die Lizenz zu unterlaufen.
Wenn dir OpenSource Lizenzen nicht passen, musst du sie ja nicht benutzen.
Hallo tom-essen,
wenn es für eine Anwendung wirklich sinnvoll ist, dass sie dynamisch Module nachladen kann und sowohl GPL- als auch Nicht-GPL-Module zur Verfügung stehen und die GPL-Module nicht zusammen mit der Software ausgeliefert werden, sondern der Benutzer der Anwendung diese einbindet, wäre das wohl kein Problem. Selbst dann nicht, wenn der Benutzer einen Wrapper schreiben muss. [EDIT]Ist doch ein Problem und ein Verstoß gegen die GPL, siehe weiter unten. Es wäre nur ok, wenn der Autor des GPL-Moduls die Verwendung als Plugin in einer nicht GPL-Anwendung (explizit) erlaubt und das wird wohl so gut wie nie der Fall sein.[/EDIT]
Solange es aber wie schon bei der Client-Server-Überlegung erkennbar nur zur Umgehung der Lizenz gemacht wird, rate ich dringend davon ab. [EDIT]Und nach der Änderung im ersten Absatz kann man sagen, dass es grundsätzlich nicht erlaubt ist, ein Modul, das unter GPL steht und für das es keine explizit Ausnahmevereinbarung gibt, direkt oder als Plugin wiederum direkt oder über einen Wrapper in eine Nicht-GPL-Anwendung einzubinden.[/EDIT]
herbivore
Interessanter Gedanke, vorallem in Bezug auf Anwendungen die Plugin-Systeme beinhalten.
Wenn ein Nutzer der Anwendung ein Plugin schreibt, was auf eine GPL Bibliothek zugreift kann ja keiner vom Entwickler verlangen seinen Source offen zu legen. Lediglich das Plugin selbst müsste dann aus meiner Sicht unter die GPL gestellt werden.
Auf der GNU-Website habe ich dazu diese Infos gefunden:
http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
Es scheint also tatsächlich so zu sein, dass man dann den Code des gesamten System offenlegen müsste. Also auch den der Kern-Komponente und aller PlugIns.
Je mehr ich mich mit der GPL beschäftige, desto mehr bekomme ich den Eindruck, dass der Slogan "Free as in Freedom" (-> siehe hier) nicht wirklich passt.
Denn der "virale" oder "virulente" Character der Lizenz (auch wenn GPL-Anhänger das wohl nicht hören wollen), schränkt die Nutzung (und damit auch die Verbreitung der GPL-Software) wirklich deutlich ein. Vor Allem, wenn bei größeren Projekten andere Parteien mit anderen Lizenz-Modellen involviert sind.
Irgendwie hast du dort was gelesen was ich nicht lesen kann. - Denn ich lese das gegenteilige zu dem was du beschreibst bzw. wird dort zwischen verschiedenen Fällen differenziert.
Ich kann zu dem auch nicht glauben, dass nur weil eine dritte Person ein Plugin zu meiner Anwendung schreibt ich deren Lizenz ändern müsse. - Woher soll ich denn auch erfahren, dass Max Muster dies getan hat, wenn ich weder direkt noch indirekt Kontakt mit ihm habe?
Alles in allem tendiere ich dazu es so zu verstehen, wie herbivore es offen legt.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo DFDotNet,
die Klarstellung "Free as in Freedom" ist nur im Englischen nötig, denn wo die Engländer nur das Wort free haben, gibt es im deutschen frei und kostenlos. Die Klarstellung bedeutet also nur, dass free nicht im Sinne von kostenlos gemeint ist. GPL-Software darf nämlich durchaus was kosten, muss also nicht kostenlos sein. Mit "Free as in Freedom" ist also nicht gemeint, dass die Software besonders frei ist, sondern das Freiheit nicht mit Kostenlosigkeit verwechselt werden soll. Es bedeutet nicht, dass die Freiheit grenzenlos ist. Insofern stimmt es also nicht, dass der Slogan unpassend ist. Man muss ihn nur richtig interpretieren.
Ansonsten kann jeder entscheiden, ob er seine (komplett selbst erstellte) Software unter GPL stellt will oder nicht. Dass GPL Open Source und nicht Freeware ist, sollte sich inzwischen herumgesprochen haben. Üblicherweise stellt die GPL für die Verbreitung von kompletten Programme kein Hindernis dar. Nur bei Bibliotheken unter GPL wird die Virulenz öfter mal als Einschränkung empfunden. Aber keiner behauptet, dass eine Lizenz dazu dient, dem Benutzer möglichst viele Rechte einzuräumen. Im Gegenteil dienen die meisten Lizenzen dazu, die Interessen des Autors zu schützen. Du wirst also damit leben müssen, den Willen der Autoren zu respektieren, egal welche Lizenz sie verwenden.
Außerdem ist es nicht unüblich, die Benutzung von Bibliotheken nur für private Zwecke zu erlauben und für kommerzielle zu verbieten. Das ist auch nachvollziehbar. Im Grunde ist die GPL da sogar gnädig, weil sie den kommerziellen Einsatz nicht verbietet, sondern durch den Zwang zur Offenlegung des Quellcodes nur unattraktiv macht. Aber selbst wenn dies in der Praxis der Wirkung eines Verbot gleichkommt, ist das zumindest nicht schlechter als ein explizites Verbot.
herbivore
Ich kann zu dem auch nicht glauben, dass nur weil eine dritte Person ein Plugin zu meiner Anwendung schreibt ich deren Lizenz ändern müsse. - Woher soll ich denn auch erfahren, dass Max Muster dies getan hat, wenn ich weder direkt noch indirekt Kontakt mit ihm habe?
Die GPL-FAQ sagt doch wörtlich:
if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs [...] If the program dynamically links plug-ins, and they make function calls to each other and share data structures, [...] In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license
Wenn man also PlugIns für ein Framework schreibt, dass Dependency Injection oder ähnliche Mechanismen verwendet, kommt man in die Bredouille, dass man das Hauptprogramm unter GPL (oder kompatible Lizenz) stellen müsste um GPL-Libs für ein PlugIn zu verwenden. wenn man das aber nicht tun kann, da das Hauptprogramm anders Lizenziert ist, steht man in einer Sackgasse und kann die schöne GPL-Komponente leider nicht verwenden.
die Klarstellung "Free as in Freedom" ist nur im Englischen nötig, denn wo die Engländer nur das Wort free haben, gibt es im deutschen frei und kostenlos.
Das ist mir klar, ich meinte damit nur, dass man als Anwender in der Benutzung der GPL-Bibliotheken keinesfalls frei ("wie in Freiheit") ist, da man schließlich einiges beachten muss. Ich muss zugeben, dass ich mich bisher nicht tiefgehender mit der GPL beschäftigt habe (ich war nur mit der LGPL in Berührung gekommen). Darum war mit die Tragweite und - vor Allem - der virulente Character nicht bewusst.
Du wirst also damit leben müssen, den Willen der Autoren zu respektieren, egal welche Lizenz sie verwenden.
Selbstverständlich. Aber schade ist es trotzdem 😉
Ok, überzeugt.
Aber nur in einer Hinsicht: Ich muss mein Programm nicht offen legen. - Der Author des Plugins darf die GPL-Komponente ganz einfach nicht verwenden. Das schriebst du jedoch bereits.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Der Author des Plugins darf die GPL-Komponente ganz einfach nicht verwenden.
bzw. sein Plugin nicht unter GPL stellen, ohne eine Ausnahmeregel vorzusehen.
Hallo ujr,
inflames2k meinte mit "Autor des Plugins" sicher jemanden, der ein Plugin in Form eines Wrappers schreiben möchte, der als Basis eine GPL-Komponente (ohne Ausnahmeregel) verwenden soll. Und dieser Autor hat keine Chance, das zu tun, eben wegen der fehlenden Ausnahmeregel. Siehe auch mein Edit oben in GPL-Komponente kapseln und in closed-source software verwenden?.
herbivore
Wäre es den nicht möglich den Wrapper zusätzlich zur GPL unter die MIT-Lizenz zu stellen? Diese erlaubt doch die Verwendung des source in closed source systemen.
Ich beschütze das was am Wichtigsten ist!
Hallo Seraph,
meiner Ansicht nach schließt die GPL eine zusätzliche Lizensierung über die MIT aus. Nicht zu letzt aus dem von dir genannten Punkt.
Diese erlaubt doch die Verwendung des source in closed source systemen.
~~Ich muss mich korrigieren. MIT_License besagt dazu folgendes:
The license is also GPL-compatible, meaning that the GPL permits combination and redistribution with software that uses the MIT License. ~~ Nach weiteren Recherchen ist das wohl doch nicht ganz richtig, beziehungsweise nicht in diesem Zusammenhang.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo Seraph2402,
würde mich wundern, wenn es so einfach wäre. Wenn die MIT Lizenz etwas erlaubt, was die GPL verbietet, dann kann die Lizenz für den Wrapper zumindest keine rechtliche Auswirkungen auf die benutzte GPL-Komponente haben. Deren Forderung muss also immer noch erfüllt werden und die schlägt dann immer noch auf das Hauptprogramm durch.
herbivore
Auf so ein Beispiel antwortet die GPL-FAQ (glaube ich) auch:
http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper
[...]module B is legally irrelevant
Du hättest das Zitat weiter ausgeholt verwenden sollen. Dein Abschnitt ist nichts sagend.
The fact that proprietary module A communicates with GPL-covered module C only through X11-licensed module B is legally irrelevant; what matters is the fact that module C is included in the whole.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Da hast du recht, ich merke auch grad, dass ich den Satz sogar falsch verstanden hatte, weil ich ihn nur überflogen habe.
Nicht "module B" ist irrelevant, sondern "the fact...".
Aber der Sinn bleibt der gleiche: Ein Wrapper ist nicht zulässig, bzw. kann die Auswirkungen der GPL-Lizenz auf weitere proprietäre Programmteile nicht einschränken.