Von El Pseudonymo am Mo, 29. August 2005 um 14:58 #
Mal abgesehen davon, dass hier besser nicht nur zwei Sätze herausgegriffen worden wären... wo ist da denn nun der Unterschied, ob ich direkt gegen eine LGPLed Lib wie GTK linke oder indirekt gegen eine kommerzielle Qt, die wiederum gegen LGPLed Libs gelinkt ist. Wieso kann ich dann bei der Variante meinprogramm+kommerz-Qt reverse engineering verbieten, bei meinprogramm+GTK nicht? Wie du im ersten Satz schon sagtest; Besser nicht nur zwei Sätze aus der LGPL herausgreifen: Punkt 7 in der LGPL macht da einen Unterschied. Oder präziser ausgedrückt, kann einen Unterschied machen.
Etwas was dabei aber noch wichtiger ist, ist dass Qt ja nicht von anderen LGPL Bibliotheken abhängt. Man kann optional welche verwenden. Aber z.B. libungif, libjpeg und libpng, um einige der wichtigsten von Qt ggf. benutzen Bibliotheken zu nennen, sind alle nicht LGPL lizensiert. X11 ist ebenfalls anders lizensiert. Und um die glibc kommt man ja ebenfalls herum, schließlich läuft Qt ja auch auf Solaris, HP-UX und den BSDs und Weiteren.
Von El Pseudonymo am Mo, 29. August 2005 um 18:33 #
> Und um die glibc kommt man ja ebenfalls herum Na aber ich glaube kaum, dass die kommerzielle Qt unter Linux gegen eine andre als die glibc gelinkt wird. Oder gibt es dafür Gegenbeispiele?
Ich glaube auch nicht, dass es derzeit Gegenbeispiele gibt. Aber zumindest wäre es prinzipiell denkbar, und ich würde es auch als praktisch machbar einstufen. Trolltech könnte ja zum Beispiel einen kleinen Stub schreiben, der die C-Standardbibliothek und die benötigten Posix Funktionen gerade soweit implementiert, dass gegen den Stub gelinkt werden kann. Eine dritte Partei könnte den Stub dann soweit weiter implementieren, das an die Funktionen aus der glibc delegiert wird. Dann könnte Trolltech Qt gegen den Stub linken, braucht also die Lizenzkonditionen der glibc gar nicht mehr beachten. Das gleiche gilt für die kommmerziellen Entwickler die gegen Qt linken. Und ein Endanwender könnte die zweite Version des Stubs benutzen, der dann die glibc verwendet. Somit würde nur der Endanwender die LGPL beachten müssen. Aber für den ist das ja kein Problem. Man beachte die folgenden beiden Sätze aus der LGPL: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it)."
Wie du im ersten Satz schon sagtest; Besser nicht nur zwei Sätze aus der LGPL herausgreifen: Punkt 7 in der LGPL macht da einen Unterschied. Oder präziser ausgedrückt, kann einen Unterschied machen.
Etwas was dabei aber noch wichtiger ist, ist dass Qt ja nicht von anderen LGPL Bibliotheken abhängt. Man kann optional welche verwenden. Aber z.B. libungif, libjpeg und libpng, um einige der wichtigsten von Qt ggf. benutzen Bibliotheken zu nennen, sind alle nicht LGPL lizensiert. X11 ist ebenfalls anders lizensiert. Und um die glibc kommt man ja ebenfalls herum, schließlich läuft Qt ja auch auf Solaris, HP-UX und den BSDs und Weiteren.
Na aber ich glaube kaum, dass die kommerzielle Qt unter Linux gegen eine andre als die glibc gelinkt wird. Oder gibt es dafür Gegenbeispiele?
> Und um die glibc kommt man ja ebenfalls herum
Na aber ich glaube kaum, dass die kommerzielle Qt unter Linux gegen eine andre als die glibc gelinkt wird. Oder gibt es dafür Gegenbeispiele?
Ich glaube auch nicht, dass es derzeit Gegenbeispiele gibt. Aber zumindest wäre es prinzipiell denkbar, und ich würde es auch als praktisch machbar einstufen. Trolltech könnte ja zum Beispiel einen kleinen Stub schreiben, der die C-Standardbibliothek und die benötigten Posix Funktionen gerade soweit implementiert, dass gegen den Stub gelinkt werden kann. Eine dritte Partei könnte den Stub dann soweit weiter implementieren, das an die Funktionen aus der glibc delegiert wird. Dann könnte Trolltech Qt gegen den Stub linken, braucht also die Lizenzkonditionen der glibc gar nicht mehr beachten. Das gleiche gilt für die kommmerziellen Entwickler die gegen Qt linken. Und ein Endanwender könnte die zweite Version des Stubs benutzen, der dann die glibc verwendet. Somit würde nur der Endanwender die LGPL beachten müssen. Aber für den ist das ja kein Problem. Man beachte die folgenden beiden Sätze aus der LGPL: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it)."