Liebe Liste,
ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
Es ist ein Projekt in Planung, das unter anderem von einer GPL-Library und einer proprietären Library abhängig sein würde.
Das eigentliche Projekt müsste man einerseits unter GPL stellen, um die Auflage der GPL-Library zu erfüllen. Andererseits hätte man dann insgesamt ein GPL-Projekt, das von einer proprietären Library abhängig ist.
Um die proprietäre Library komme ich im praktischen Einsatz leider nicht herum. Und dass diese unter eine freie Lizenz gestellt wird, ist extrem unwahrscheinlich.
Eine Controlled-Interface-Exception für die verwendete GPL-Library zu erhalten, das ist ebenfalls sehr unwahrscheinlich. (http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface)
Und die übrigen Punkte der GPL-FAQ behandeln eher den umgekehrten Fall, dass man freie Software in ein proprietäres Projekt einbinden will. Die helfen mir daher auch nicht weiter. (http://www.gnu.org/licenses/gpl-faq.html)
Was kann ich tun, um diese Situation aufzulösen? Welche der nachfolgenden Lösungen wäre für die Auflagen der GPL akzeptabel?
1) Das Projekt wird dynamisch gegen die proprietäre Library gelinkt, fertig. Ich habe mir zu viele Sorgen darum gemacht.
2) Das Projekt wird dynamisch gegen die proprietäre Library gelinkt, kann aber auch ohne die Library funktionieren, mit entsprechend eingeschränkter _Funktionalität_.
(d.h. die Library ist optional)
3) Das Projekt wird dynamisch gegen die proprietäre Library gelinkt. Ist sie nicht vorhanden, wird stattdessen eine freie (aber sehr einfache) Implemetierung genutzt. Das Projekt würde dann auch ohne sie funktionieren, vollständig, aber mit entsprechend geringerer _Qualität_ der Ergebnisse.
(d.h. es gibt eine klare Schnittstelle, durch die die Library austauschbar ist.)
4) Die proprietäre Library wird mit einem Wrapper versehen und in einem eigenen Prozess gestartet. Über ein RPC via stdin/out kommuniziert das Projekt mit der Library.
(auch hier eine klare Schnittstelle, durch die die Library austauschbar ist.)
5) Nicht die proprietäre Library, sondern die verwendete GPL-Library wird in einen Wrapper verpackt. Das eigentliche Projekt wird nicht unter GPL, sondern unter eine BSD-artige Lizenz gestellt.
6) ... Habe ich eine Möglichkeit übersehen? ...
Vielen Dank schon einmal für euren Rat.
Gruß Volker
Hallo,
ich bin jetzt kein Experte, habe mich mit dem Thema aber intensiv beschäftigt. Also bitte meine Antworten nur unter Vorbehalt akzeptieren.
On Tue, Jun 29, 2010 at 12:05:51PM +0200, Volker Grabsch wrote:
Liebe Liste,
ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
Vielleicht besser die FTF fragen, dort sind imho Experten: http://fsfe.org/projects/ftf/
Es ist ein Projekt in Planung, das unter anderem von einer GPL-Library und einer proprietären Library abhängig sein würde.
Das ist ein Problem, da beide Bibliotheken in den selben Adressraum geladen werden. Ob nun dynamisch oder statisch gelinkt wird, macht keinen Unterschied.
Das eigentliche Projekt müsste man einerseits unter GPL stellen, um die Auflage der GPL-Library zu erfüllen. Andererseits hätte man dann insgesamt ein GPL-Projekt, das von einer proprietären Library abhängig ist.
Um die proprietäre Library komme ich im praktischen Einsatz leider nicht herum. Und dass diese unter eine freie Lizenz gestellt wird, ist extrem unwahrscheinlich.
Eine Controlled-Interface-Exception für die verwendete GPL-Library zu erhalten, das ist ebenfalls sehr unwahrscheinlich. (http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface)
Das sieht dann ziemlich schlecht aus.
Und die übrigen Punkte der GPL-FAQ behandeln eher den umgekehrten Fall, dass man freie Software in ein proprietäres Projekt einbinden will. Die helfen mir daher auch nicht weiter. (http://www.gnu.org/licenses/gpl-faq.html)
Was kann ich tun, um diese Situation aufzulösen? Welche der nachfolgenden Lösungen wäre für die Auflagen der GPL akzeptabel?
- Das Projekt wird dynamisch gegen die proprietäre Library gelinkt, fertig. Ich habe mir zu viele Sorgen darum gemacht.
Definitiv falsch.
Das Projekt wird dynamisch gegen die proprietäre Library gelinkt, kann aber auch ohne die Library funktionieren, mit entsprechend eingeschränkter _Funktionalität_.
(d.h. die Library ist optional)
Du meinst via dlopen? Da bin ich mir unsicher, aber ich glaube kaum, dass das erlaubt ist. Die Bibliothek wird immer noch in den selben Adressraum geladen.
Das Projekt wird dynamisch gegen die proprietäre Library gelinkt. Ist sie nicht vorhanden, wird stattdessen eine freie (aber sehr einfache) Implemetierung genutzt. Das Projekt würde dann auch ohne sie funktionieren, vollständig, aber mit entsprechend geringerer _Qualität_ der Ergebnisse.
(d.h. es gibt eine klare Schnittstelle, durch die die Library austauschbar ist.)
Wenn diese freie Implementierung existiert, dürfte das erlaubt sein. Wenn nicht, dann nicht. Interessierte Nutzer könnten dann die freie Bibliothek weiter ausbauen... Ob es eine unfreie Bibliothek gibt, die auch genutzt werden könnte, ist für die freie Welt uninteressant.
Die proprietäre Library wird mit einem Wrapper versehen und in einem eigenen Prozess gestartet. Über ein RPC via stdin/out kommuniziert das Projekt mit der Library.
(auch hier eine klare Schnittstelle, durch die die Library austauschbar ist.)
Das sollte erlaubt sein. Aber auch da bin ich unsicher.
- Nicht die proprietäre Library, sondern die verwendete GPL-Library wird in einen Wrapper verpackt. Das eigentliche Projekt wird nicht unter GPL, sondern unter eine BSD-artige Lizenz gestellt.
Wie 4.
- ... Habe ich eine Möglichkeit übersehen? ...
Kommt drauf an.
- Ist das Projekt überhaupt zur Veröffentlichung bestimmt? Wenn man es nur für den Eigenbedarf macht, gibt es keine Probleme mit der GPL. Das ist etwas, das viele übersehen.
- Du hast jetzt nicht gesagt, um was für Bibliotheken es sich handelt. Wenn es eine Systembibliothek ist, bzw. eine größere Komponente des Systems oder des Compilers, dann gibt die GPL schon eine Ausnahme dafür.
- Wer könnte klagen? Der Urheber der GPL-Bibliothek oder der Urheber der proprietären Bibliothek. Also sollte man diese Fragen an die stellen. Wenn man deren ausdrückliche Erlaubnis hat, dann ist es egal, was in den Lizenzen steht.
Ich hoffe, das hilft, auch wenn ich keine definitiven Antworten geben kann.
Mailing-Listen list@akfoerster.de schrieb:
On Tue, Jun 29, 2010 at 12:05:51PM +0200, Volker Grabsch wrote:
ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
Vielleicht besser die FTF fragen, dort sind imho Experten: http://fsfe.org/projects/ftf/
Vielen Dank für den Hinweis! Ich habe die FTF soeben angeschrieben. Mal sehen, was die dazu sagen.
Das Projekt wird dynamisch gegen die proprietäre Library gelinkt. Ist sie nicht vorhanden, wird stattdessen eine freie (aber sehr einfache) Implemetierung genutzt. Das Projekt würde dann auch ohne sie funktionieren, vollständig, aber mit entsprechend geringerer _Qualität_ der Ergebnisse.
(d.h. es gibt eine klare Schnittstelle, durch die die Library austauschbar ist.)
Wenn diese freie Implementierung existiert, dürfte das erlaubt sein. Wenn nicht, dann nicht.
Naja, die freie Implementierung müsste man halt bauen. Für die interne Entwicklung habe ich schon einen Stub, den könnte man ausbauen.
Die Frage ist, ob sich das wirklich lohnt, oder ob das nur ein "hässlicher Trick" ist, der allgemein gar nicht akzeptiert ist.
Interessierte Nutzer könnten dann die freie Bibliothek weiter ausbauen... Ob es eine unfreie Bibliothek gibt, die auch genutzt werden könnte, ist für die freie Welt uninteressant.
Das ist genau die Frage. Wann darf ich in einem GPL-Projekt eine Teilkomponente gegen eine proprietäre austauschen? Benötige ich dazu Prozess-Trennung, oder geht das auch eleganter über Plugins bzw. Shared-Libraries?
Die proprietäre Library wird mit einem Wrapper versehen und in einem eigenen Prozess gestartet. Über ein RPC via stdin/out kommuniziert das Projekt mit der Library.
(auch hier eine klare Schnittstelle, durch die die Library austauschbar ist.)
Das sollte erlaubt sein. Aber auch da bin ich unsicher.
Nur leider ist das ziemlich unpraktikabel, da einige Datenmengen transportiert werden müssten. (Bildverarbeitung)
- Nicht die proprietäre Library, sondern die verwendete GPL-Library wird in einen Wrapper verpackt. Das eigentliche Projekt wird nicht unter GPL, sondern unter eine BSD-artige Lizenz gestellt.
Wie 4.
Ditto.
- ... Habe ich eine Möglichkeit übersehen? ...
Kommt drauf an.
- Ist das Projekt überhaupt zur Veröffentlichung bestimmt? Wenn man es nur für den Eigenbedarf macht, gibt es keine Probleme mit der GPL. Das ist etwas, das viele übersehen.
Danke für den Hinweis. Ich habe das in meiner Anfrage an die FTF entsprechend präzisiert.
Es wird in Produkte einfließen, die Auftragsarbeiten für verschiedene Endkunden darstellen. Es ist also kein reiner Eigenbedarf, aber auch keine wirkliche Veröffentlichung.
- Du hast jetzt nicht gesagt, um was für Bibliotheken es sich handelt. Wenn es eine Systembibliothek ist, bzw. eine größere Komponente des Systems oder des Compilers, dann gibt die GPL schon eine Ausnahme dafür.
Auch das habe ich in der Anfrage an die FTF präzisiert. Danke für den Hinweis.
Nein, es sind leider keine Systembibliotheken, es geht kurz gesagt um Bildverarbeitung, sowohl auf Pixel- als auch auf Metadaten-Ebene.
Gruß Volker
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Volker,
On 06/29/2010 12:05 PM, Volker Grabsch wrote:
- ... Habe ich eine Möglichkeit übersehen? ...
solange "nur" die GPL verletzt wird und nicht die Lizenz der unfreien Software, koennen die Copyright-Inhaber der freien, GPL'ten Software entscheiden, dass fuer dieses spezielle Derivat im Speicher eine Ausnahme gilt - oder diese im Vornherein explizit fuer diese eine unfreie Software formulieren. Man koennte dies evtl. mit einer Duallizensierung GPL/LGPL machen, wobei letztere die Restriktion auf diese bestimmte unfreie Software enthaelt fuer das Derivat.
(aber: IANAL)
LG Alex
- -- Alexander Kahl GNU/Linux Software Developer
Hallo,
On Tue, Jun 29, 2010 at 12:05:51PM +0200, Volker Grabsch wrote:
Liebe Liste,
ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
Es ist ein Projekt in Planung, das unter anderem von einer GPL-Library und einer proprietären Library abhängig sein würde.
In diesem Zusammenhang lesenswert sollte auch das "Linking Paper" des European Legal Network sein [0,1].
Viele Grüße Michael
[0] http://fsfe.org/news/2010/news-20100719-01.de.html [1] https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument
Michael Kesper mkesper@fsfe.org schrieb:
On Tue, Jun 29, 2010 at 12:05:51PM +0200, Volker Grabsch wrote:
ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
Es ist ein Projekt in Planung, das unter anderem von einer GPL-Library und einer proprietären Library abhängig sein würde.
In diesem Zusammenhang lesenswert sollte auch das "Linking Paper" des European Legal Network sein [0,1]. [...] [1] https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument
Besten Dank für den Hinweis. Aber zumindest die Zusammenfassung lässt genau die Punkte offen, um die es mir ging:
| Dynamic linking | | Legal view: a dynamically linked library may or may not cause the program | to be a derivative / collective work including the library. Scenario | dependent on external factors (development process, APIs, existence of | other libraries with same functionalities)
Ähnlich offen ist der RPC-Fall:
| Interprocess communication | | Legal view: No copyleft obligations, as most IPC/RPC involves well | separated and clearly differentiated programs. In some limited | circumstances, the intimacy, nature of and organisation of the data | exchanged could give rise to the two programs being viewed as a single | work.
Auch wenn offenbar einer RPC-Schnitstelle eher "geglaubt" wird als einer dyanmischen Library, dass sie separat ist: In beiden Fällen gibt es Probleme, falls die Kommunikation zu "intim" ist. Was auch immer das heißen mag.
Wer weiß, vielleicht läuft das irgendwann darauf hinaus, dass man seine Schnittstellen (APIs, IDLs) als "GPL-konform" zertifizieren kann, d.h. die Verwendung einer zertifizierten Schnittstelle garantiert unabhängig Werke im Sinne der GPL. Wer sicher gehen will, dass er die GPL nicht verletzt, sollte GPL-inkompatiblen Code stets über eine zertifizierte Schnittstelle anbinden. Das wär's doch. ;-)
Gruß Volker
Volker Grabsch vog@notjusthosting.com schrieb:
Michael Kesper mkesper@fsfe.org schrieb:
On Tue, Jun 29, 2010 at 12:05:51PM +0200, Volker Grabsch wrote:
ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
Es ist ein Projekt in Planung, das unter anderem von einer GPL-Library und einer proprietären Library abhängig sein würde.
In diesem Zusammenhang lesenswert sollte auch das "Linking Paper" des European Legal Network sein [0,1]. [...] [1] https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument
Besten Dank für den Hinweis. Aber zumindest die Zusammenfassung lässt genau die Punkte offen, um die es mir ging: [...]
Kurzer Nachtrag: Die ausführliche Fassung lässt diese Punkte ebenfalls offen.
Bei "Dynamic linking" gibt es zwar einen Punkt "3)", der meinen Fall ganz gut beschreibt. Aber weiter unten heißt es dann, Punkte 1-2 und 4-5 seien klar, und 3 sei ein Streitpunkt dazwischen.
Und bei "RPC" findet sich fast der gleiche schwammige Satz über "Intimität" wie in der Zusammenfassung.
Meine Folgerung bleibt somit bestehen:
Wer weiß, vielleicht läuft das irgendwann darauf hinaus, dass man seine Schnittstellen (APIs, IDLs) als "GPL-konform" zertifizieren kann, d.h. die Verwendung einer zertifizierten Schnittstelle garantiert unabhängig Werke im Sinne der GPL. Wer sicher gehen will, dass er die GPL nicht verletzt, sollte GPL-inkompatiblen Code stets über eine zertifizierte Schnittstelle anbinden. Das wär's doch.
;-)
Gruß Volker