Hallo zusammen

Kennt sich jemand mit GPL aus?

So wie ich das verstanden habe darf man GPL Bibliotheken uneingeschränkt verwenden, auch von nicht-GPL Programmen aus, solange kein Modifizieren, Kopieren oder Verteilen der GPL Bibliothek stattfindet. D.h. für Inhouse-Projekte darf ich GPL-Bibliotheken uneingeschränkt verwenden. Veröffentlichen darf ich das Programm dann aber nicht. Ist das korrekt?

Falls dem so ist; wie sieht es mit folgendem Szenario aus: Ich schreibe ein Projekt und verwende eine selbstgeschriebene DLL abc.dll, die aber kompatibel mit einer GPL-DLL ist (die heisst auch abc.dll). Darf die Gegenpartei meine DLL gegen die GPL-DLL austauschen? Der Unterschied zwischen meiner und der GPL-DLL ist nur die Geschwindigkeit der Verarbeitung. Mir ist es egal, wie schnell das ganze läuft; aber darf der Kunde die DLL austauschen, ohne die GPL-Lizenz zu verletzen? Weder ich noch der Kunde hat die GPL-Bibliothek modifiziert, kopiert oder verteilt. Ist das erlaubt, Grauzone oder verboten?

Danke,
dph

delfiphan hat folgendes geschrieben :

So wie ich das verstanden habe darf man GPL Bibliotheken uneingeschränkt verwenden, auch von nicht-GPL Programmen aus, solange kein Modifizieren, Kopieren oder Verteilen der GPL Bibliothek stattfindet.

Nein, das ist falsch. Laut GPL setzt auch das dynamische Linking von GPL-DLLs voraus, dass auch das einbindende Projekt unter der GPL steht. (Ja, es gibt auch andere, die das anders sehen. Ich finde in der GPL steht das so, dass es so zu verstehen ist.)

Genau das ist der Unterschied zwischen GPL und LGPL. Unter der LGPL darfst du LGPL-DLLs in Closed-Source Projekten nutzen.
(Und unter der MPL sogar Units, die darunter stehen, einkompilieren, solange du diese nicht modifizierst.)

delfiphan hat folgendes geschrieben :

Ich schreibe ein Projekt und verwende eine selbstgeschriebene DLL abc.dll, die aber kompatibel mit einer GPL-DLL ist (die heisst auch abc.dll).

Du benutzt also die selbe Schnittstelle. Und diese steht aber unter der GPL. Also darfst du das nicht.

Möglich ist aber das ganze über Tricks. Irgendwo habe ich das mal gelesen. Wenn du selbst eine LGPL-DLL schreibst und von deinem Projekt aus ansprichst, die wiederum die GPL-DLL nutzt, dann geht das. Denn eine LGPL-DLL darf die GPL-DLL nutzen. Du wiederum darfst die LGPL-DLL einbinden (musst aber natürlich darauf achten, dass du in der Schnittstelle zu deinem Projekt keinen Code der GPL-DLL nutzt). (Ich glaube so war das.) Den entsprechenden Artikel müsstest du auch irgendwo finden mit den Stichworten GPL und DLL oder so.

Solange das Projekt nicht weiterverteilt wird, sollte das imho kein Problem sein. Sobald man das dann aber doh veröffentlicht, hat man natürlich ein Problem.

Zu der kompatiblen dll: Auch das sollte imho kein Problem sein. Wenn nur die Schnittstelle übernommen wird, greift afaik die GPL nicht. Was der Kunde dann macht, ist ganz alleine seine Sache. Es gibt ja auch für andere Closed-Source Programme Plugins, die unter der GPL stehen.

Du hast die GPL mit der LGPL verwechselt. Solche Dlls darfst du auch in nicht (L)GPL Projekten verwenden

Gausi hat folgendes geschrieben :

Solange das Projekt nicht weiterverteilt wird, sollte das imho kein Problem sein.

Ist es auch nicht. Es besteht bei veränderten Versionen natürlich kein Veröffentlichungszwang oder so.

Gausi hat folgendes geschrieben :

Zu der kompatiblen dll: Auch das sollte imho kein Problem sein. Wenn nur die Schnittstelle übernommen wird, greift afaik die GPL nicht.

Das ist genau der Knackpunkt. Im Grunde musst du den Code für die Einbindung der DLL praktisch kopieren. Und genau das ist problematisch.

Da gibt es auch verschiedene Meinungen, aber um Ärger aus dem Weg zu gehen würde ich es nicht darauf ankommen lassen.

Ja, so ganz astrein ist das nicht. Ich meine aber mich daran erinnern zu können, dass das in dem Punkt oft nicht so genau genommen wird. Wie du auch sagst: ist Ansichtssache. Ich persönlich würde die gleiche Namensgebung der dll als eher problematisch ansehen. Das fände ich als Nutzer auch höchst intransparent.

mkinzler hat folgendes geschrieben :

Du hast die GPL mit der LGPL verwechselt. Solche Dlls darfst du auch in nicht (L)GPL Projekten verwenden

Wenn das auf mich bezogen war: Nein, da habe ich nichts verwechselt. Wenn jemand für sein Closed-Source-Programm eine Plugin-Schnittstelle bereitstellt, dann darf jemand Drittes ein Plugin schreiben und dieses unter der GPL vertreiben. Davon wird die Closed-Source-Lizenz des Hauptprogramms nicht beeinträchtigt. Winamp wäre ein Beispiel dafür. Einige Plugins der bass.dll (closed source) stehen auch unter der GPL.
Aber das ist je der umgedrehte Fall - hier ist die Dll ja vorher da und für das Programm essentiell wichtig, wenn ich das richtig verstehe.

Nein im meinte de TE.

Danke für die Antworten. Zum ersten Fall; das Inhouse-Projekt könnte ja ein nicht veröffentliches GPL-Projekt darstellen; daher müssen die Sources nicht veröffentlicht werden. Ich muss ja nur garantieren, dass jemand, der die Binaries hat, die Sources z.B. per Post erhalten kann. Aber eine Pseudo Inhouse-Lizenz scheint mir etwas merkwürdig. Ich brauche für mich selbst ja wohl kaum eine Lizenz

Zum zweiten Punkt. Das Wine-Projekt "kopiert" ja auch die Namen der DLLs und die Funktionen darin.

Also konkret geht es bei mir um FFTW. Davon brauche ich nur einen sehr kleinen Teil, 3 Funktionen (daher ist meine DLL auch ca. 55x kleiner). Wenn ich richtig gegoogelt habe würde mich die kommerzielle Duallizenz von MIT $5000 kosten. So viel bin ich natürlich nicht bereit für eine FFT zu bezahlen.

Die alternative wäre die Math Kernel Library von Intel. Die ist in Benchmarks schneller und kostet nur $400 (das wäre vom Preis her noch akzeptabel). Aber da muss man ein paar duzend DLLs ausliefern (für jeden Prozessortyp eine) und ich müsste meinen Code entsprechend ändern. Ausserdem kriege ich von Intel nur C und Fortran Headers. Die Delphiübersetzung müsste ich selbst machen. Aber so wie's aussieht wird das wohl der Weg sein... (a propos bietet die MKL C-Wrapperfunktionen für FFTW; die kopieren die Namen der FFTW-Funktionen also auch)

Ich dachte jetzt halt nur, wenn das ganze legal wäre würde ich einfach meine kompatible DLL ausliefern und dem Kunden sagen, er könne diese austauschen. Aber wenn das für den Kunden nicht legal ist macht es irgendwie keinen Sinn.

Wenn der Kunde das macht, dann tut er mit ziemlicher Sicherheit nichts illegales. Die Frage ist eher, ob du etwas illegales tust, wenn du das deinem Kunden ermöglichst.

Gausi hat folgendes geschrieben :

Wenn der Kunde das macht, dann tut er mit ziemlicher Sicherheit nichts illegales. Die Frage ist eher, ob du etwas illegales tust, wenn du das deinem Kunden ermöglichst.

Ich ging mal davon aus, dass es höchstens für den Kunden ein Problem ist. Aber du hast schon Recht. Die DLL ist nur kompatibel mit dem Zweck, dass sie ausgetauscht werden kann.

IIRC ist die Frage nur, ob mein Programm gemäss Copyrightgesetzt ein "derivative Work" von FFTW ist oder nicht. Das ist IMO nicht der Fall, da ich ja meine DLL ausliefere. Und Funktionsnamen wie "dft_r2c_1d" sind unter dem Copyrightgesetzt wohl nicht als schützenswert einzustufen (keine hinreichende Schöpfungshöhe; kein hinreichendes Mass an Eigenständigkeit) und mein Programm stellt kein "derivative Work" dar. Das wäre in meiner Sicht absurd. Theoretisch kann ich den Code auch so schreiben, dass ich die Namen nicht explizit hartcodiere, sondern, dass diese zur Laufzeit mittels passender Kriterien ausfindig gemacht werden (z.B. suche nach *fft*.dll).

Aber ich werde wohl früher oder später die MKL einbauen, um sicher zu gehen.

GPL wird nicht ohne Grund als viral bezeichnet. Eine GPL-Library darf nur für GPL-Programme genutzt werden. Das ist auch eindeutig von der FSF so gewollt. Freie Software-Lizenzen, die du auch für unfreie Programme verwenden darfst, sind vor allem LGPL und BSD. Guckst du hier: www.gnu.org/licenses/why-not-lgpl.html

Das ist in etwa so zu verstehen: Wenn freie Software nicht an die Sourcen von proprietärer Software kommt, sollen die auch von freier Software keinen Nutzen ziehen. Viel mehr sollen sich die Entwickler von freier Software gegenseitig unterstützen.

Lizenz ist Lizenz, und ich glaube nicht, dass ein Kunde da eine Ausnahme ist. Siehe hier: www.gnu.org/licenses/gpl-violation.html

Trotzdem ist GPL eine Copyright-Lizenz. Es gelten die Copyright-Gesetze. Wenn per Copyright etwas nicht geschützt ist, dann nützt GPL auch nichts. Wenn jemand ein Foto vom blauen Himmel macht, ist dieses Foto nicht schützbar. Da nützt es auch nichts, wenn man da noch Copyright hinschreibt. Dieses Bild wurde z.B. von einem Gericht als nicht schützenswert eingestuft, daher ist das Bild gemeinfrei.

Beim Linken geht es auch weniger um eine Definition innerhalb GPL sondern, ob das Linken das Programm zu einem Derivat der Library macht oder nicht:

Wikipedia hat folgendes geschrieben:

This key dispute is whether or not non-GPL software can legally statically link or dynamically link to GPL libraries. Different opinions exist on this issue. (...) This is ultimately a question not of the GPL per se, but of how copyright law defines derivative works.

Von wegen viral oder nicht, das kommt erst zum Zug, wenn ich das non-GPL Programm mit dem GPL-Teil veröffentliche. Meine Frage bezog sich auf die Fälle, wo ich die GPL-Software nicht mitgebe sondern entweder nur intern verwende oder nur die gleiche Schnittstelle verwende.

Beim ersten Fall würde ich sagen, ich kann mein internes Projekt meinetwegen als GPL bezeichnen, muss die Sources aber nicht veröffentlichen, wenn ich die Executables nicht veröffentliche.

FSF hat folgendes geschrieben:

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

Beim zweiten Fall würde ich jetzt sagen, dass die Funktionsnamen nicht schützbar sind, ist also auch kein Problem.

Du darfst GPL-Programme auch nicht mit unfreier Software ausliefern. Das ist zum Beispiel der Grund, weshalb bei GNU/Linux-Distributionen die unfreien Grafiktreiber nicht mitgeliefert werden dürfen. Diese können lediglich im Nachhinein installiert werden.

Erkläre mir bitte mal, was am Schwarzen Quadrat schützenswerter als an dem verlinkten Bild ist.

Aber OK, Funktionsnamen dürften OK sein.

So, hab jetzt in zwischen ein FFTW kompatibles DLL gemacht, das die Intel IPP verwendet. Die kostet nur $199 und dürfte auf Intel Rechnern schneller sein. Damit ist das für mich gegessen. Jetzt muss ich nur noch herausfinden, welche DLLs ich genau mitgeben muss. Insgesamt sind es 118 DLLs mit 273 MB

Trotzdem danke für die Diskussion

delfiphan hat folgendes geschrieben :

Jetzt muss ich nur noch herausfinden, welche DLLs ich genau mitgeben muss.

Kennst du den Dependency Walker?