Open Source

Open Source

Posts 21-28 of 28
  • Oliver Knoll
    Oliver Knoll
    The company name is only visible to registered members.
    Re^2: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Enrico Weigelt wrote:
    ...
    Deswegen darf ich sie mit meinen kommerziellen Anwendungen nicht mehr weitergeben.
     
    So nicht ganz korrekt. Man darf nur nicht mehr statisch dagegen linken.
    Auch das ist nicht ganz korrekt: die GPL betrifft nicht nur den Quellcode (bzw. das kompilieren), sondern v.a. auch den Objektcode - und dort sind auch *dynamisch* gelinkte Objekte von betroffen!

    Ihr jetzt sicher folgende Einwand, warum man denn ueberhaupt closed-source Produkte fuer GNU/Linux kompilieren darf (welche ja schliesslich auch z.B. gegen die C library dynamisch linken), wird eben durch einen dieser Ausnahmenparagraphen in der GPL entkraeftigt, der da besagt, dass gewisse Systembibliotheken wie eben die C Bibliothek von dieser Regelung ausgenommen sind.

    Ich kann diese Regel leider jetzt nicht mit Quelle im Detail nachweisen, weil ich sie auch bloss so auf einer anderen mailing list (Trolltech Qt interest list) gelesen hatte, aber dazumal ging es um eine aehnliche Diskussion: darf man fuer eine GPL Anwendung ein closed source *plugin* Entwickeln, und die Aussage war glaube ich "Nein!", genau aus dem Grund, weil die GPL eben auch das blosse Linken miteinbezieht (statisch oder dynamisch dabei egal).

    Gruss, Oliver
    • 16 Aug 2007, 3:27 pm
  • Oliver Knoll
    Oliver Knoll
    The company name is only visible to registered members.
    Re^4: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Daniel Fischer wrote:
    ...
    Mit C ist das etwas schwieriger (nicht unmöglich), aber bei Java ist die normale Vorgehensweise eine, bei der ich als Entwickler theoretisch eine Anwendung entwickeln kann, die MySQL über JDBC
    Mit Qt (C++ Framework) ist das eine Frage von ca 10 Zeilen mehr Code, um ein Plugin (zur *Laufzeit* nachladbare Komponente) zu erstellen. Von Hand geschrieben (C/C++) kostete mich dies auch in meiner Diplomarbeit Pointshop3d (http://www.pointshop3d.com) nicht mehr als einen Auswand von 2 Tagen (Plugin Loader + Interface definieren, Unix und win32).

    In Java ist das zugegebenermassen mit ClassLoader::loadClass() und Co. noch ein wenig komfortabler ;)

    Dennoch: soweit ich mich erinnern kann, war die Schlussfolgerung einer dieser Diskussionen wirklich die, das eine GPL Anwendung nicht gegen eine closed source Bibliothek linken darf - auch wenn diese bloss als Plugin (also nicht unbedingt fuer das eigentliche Laufen der Applikation notwendig) vorliegt.

    Hier habe ich noch etwas interessantes darueber gefunden, welche obiges eigentlich bestaetigt:

    http://en.wikipedia.org/wiki/GPL_linking_exception

    "When this exception is included, software licensed like this can be linked with any software, free or not."

    Oder mit anderen Worten: wenn eine Bibliothek unter GPL diese exception eben NICHT aufweist, dann darf eine andere NICHT-GPL Anwendung/Bibliothek/Plugin damit eben auch nicht gelinkt werden.

    Gruss, Oliver
    • 16 Aug 2007, 3:46 pm
  • User photo
    Enrico Weigelt
    (not a XING member)
    Re^3: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Oliver Knoll schrieb:

    Auch das ist nicht ganz korrekt: die GPL betrifft nicht nur den Quellcode (bzw. das kompilieren), sondern v.a. auch den Objektcode - und dort sind auch *dynamisch* gelinkte Objekte von betroffen!
    Was aber ab dem Zeitpunkt wo man ein Drop-In-Replacement hat
    schon nicht mehr greifen kann.

    Beispiel: man nehme eine Library foo unter Lizenz A (zB. GPL).
    Einige Programme nehmen jene libfoo.

    Dann programmiert jemand eine zweite Library, die exakt die Schnittstelle
    jener libfoo bietet. Derjenige (bzw. jeder der entsprechend Rechte an der
    zweiten Lib besitzt) kann dann problemlos seine eigene Software gegen
    jene zweite Lib bzw. auch erstere libfoo bauen. Beim dynamischen Linken
    ist dann kein Unterschied zwischen libfoo und neuer libfoo.

    Interessant wird's dann allenfalls beim Vertrieb. Man darf eben nur nicht
    sein Programm zusammen mit der GPL'ed libfoo, sondern allenfalls dem
    Replacement vertreiben.

    Ihr jetzt sicher folgende Einwand, warum man denn ueberhaupt closed-source Produkte fuer GNU/Linux kompilieren darf (welche ja schliesslich auch z.B. gegen die C library dynamisch linken), wird eben durch einen dieser Ausnahmenparagraphen in der GPL entkraeftigt, der da besagt, dass gewisse Systembibliotheken wie eben die C Bibliothek von dieser Regelung ausgenommen sind.
    Ja, die LGPL macht extra die Ausnahme, daß man betreffende Library
    (unverändert) direkt einlinken darf, sogar statisch.

    Ich kann diese Regel leider jetzt nicht mit Quelle im Detail nachweisen, weil ich sie auch bloss so auf einer anderen mailing list (Trolltech Qt interest list) gelesen hatte, aber dazumal ging es um eine aehnliche Diskussion: darf man fuer eine GPL Anwendung ein closed source *plugin* Entwickeln, und die Aussage war glaube ich "Nein!", genau aus dem Grund, weil die GPL eben auch das blosse Linken miteinbezieht (statisch oder dynamisch dabei egal).
    Man braucht nur das Plugin-Interface kompatibel nachprogrammieren,
    und schon ist auch das wieder vom Tisch.


    Gruß
    • 16 Aug 2007, 8:12 pm
  • User photo
    Enrico Weigelt
    (not a XING member)
    Re^5: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Oliver Knoll schrieb:

    Mit Qt (C++ Framework) ist das eine Frage von ca 10 Zeilen mehr Code, um ein Plugin (zur *Laufzeit* nachladbare Komponente) zu erstellen.
    Dafür binden man sich einen Klumpen ans Knie der schon Stunden
    zum Compilieren braucht und überhaupt mit Resourcen nicht grade
    knausrig umgeht.

    Von Hand geschrieben (C/C++) kostete mich dies auch in meiner Diplomarbeit Pointshop3d (http://www.pointshop3d.com) nicht mehr als einen Auswand von 2 Tagen (Plugin Loader + Interface definieren, Unix und win32).
    Zwei Tage für dlopen() ?! ;-o

    Dennoch: soweit ich mich erinnern kann, war die Schlussfolgerung einer dieser Diskussionen wirklich die, das eine GPL Anwendung nicht gegen eine closed source Bibliothek linken darf - auch wenn diese bloss als Plugin (also nicht unbedingt fuer das eigentliche Laufen der Applikation notwendig) vorliegt.
    Heh ?! Waren wir nicht grade beim Gegenteil ?

    Natürlich darf eine GPL-Anwendung gegen proprietären Code linken.
    Wie sonst sollte sonst GNU unter Windows gehen ? ;-o


    Gruß
    • 16 Aug 2007, 8:17 pm
  • Oliver Knoll
    Oliver Knoll
    The company name is only visible to registered members.
    Re^4: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Enrico Weigelt wrote:
    Oliver Knoll schrieb:
     
    Auch das ist nicht ganz korrekt: die GPL betrifft nicht nur den Quellcode (bzw. das kompilieren), sondern v.a. auch den Objektcode - und dort sind auch *dynamisch* gelinkte Objekte von betroffen!
     
    Was aber ab dem Zeitpunkt wo man ein Drop-In-Replacement hat
    schon nicht mehr greifen kann.
     
    Beispiel: man nehme eine Library foo unter Lizenz A (zB. GPL). Einige Programme nehmen jene libfoo.
    Dann programmiert jemand eine zweite Library, die exakt die Schnittstelle jener libfoo bietet. Derjenige (bzw. jeder der entsprechend Rechte an der
    zweiten Lib besitzt) kann dann problemlos seine eigene Software gegen jene zweite Lib bzw. auch erstere libfoo bauen. Beim dynamischen Linken ist dann kein Unterschied zwischen libfoo und neuer libfoo.
    Das ist korrekt.

     
    Interessant wird's dann allenfalls beim Vertrieb.
    Nicht "allenfalls" ;) Bei der GPL geht es um nichts anderes als um die *Weitergabe* von binaries (und eben dem source code und der Beibehaltung der GPL)! Niemand verbietet Ihnen, ein GPL Produkt zu nehmen und dieses nach Ihren Wuenschen umzuprogrammieren, mit weiteren closed-source Bibliotheken zu linken - solange Sie Ihr Endprodukt *nicht oeffentlich* machen (kommerziell oder nicht ist dabei egal).

    Wo in diesem Zusammenhang "in-house tools" anzusiedeln sind (also sie nehmen eine GPL Anwendung, erweitern diese mit nicht-GPL code und verwenden diese "bloss innerhalb der Firma"), weiss ich nicht - ich bin kein Anwalt ;)

    Man darf eben nur nicht
    sein Programm zusammen mit der GPL'ed libfoo, sondern allenfalls dem Replacement vertreiben.
    Das ist ebenfalls korrekt: natuerlich darf ich ein closed-source (oder sagen wir halt einfachheitshalber "Nicht-GPL") Programm vertreiben, sobald ich jeglichen Code, der frueher unter GPL war, durch eine *Eigenentwicklung* ersetzt habe.

    Das geht aber an meiner urspruenglichen Frage vorbei: "Darf ein NICHT-GPL binary (Bibliothek oder Applikation) mit einem GPL binary linken?" Und die Antwort ist eben "Ja, aber bloss wenn die entsprechende GPL die 'link exception' aufweist", siehe ein anderes frueheres posting von mir.

     
    Ihr jetzt sicher folgende Einwand, warum man denn ueberhaupt closed-source Produkte fuer GNU/Linux kompilieren darf (welche ja
    >
    Ja, die LGPL macht extra die Ausnahme, daß man betreffende Library
    (unverändert) direkt einlinken darf, sogar statisch.
    Der Linux-Kernel und die C/C++ runtime libraries sind unter GPL, NICHT LGPL! Siehe "link exception" in der GPL.

    Die GPL macht das ganze natuerlich immer ein wenig einfacher, Code/binaries in ein closed-source Programm zu uebernehmen, das ist schon klar. Aber wir sprechen hier immer von GPL :)

     
    Ich kann diese Regel leider jetzt nicht mit Quelle im Detail nachweisen, weil ich sie auch bloss so auf einer anderen mailing list ..
     
    Man braucht nur das Plugin-Interface kompatibel nachprogrammieren,
    und schon ist auch das wieder vom Tisch.
    Ja, aber meine Fragestellung war gerade umgekehrt: "darf ich ein NICHT-GPL Plugin fuer eine GPL Applikation schreiben (und vertreiben)?" und nicht: "Kann ich zu meiner NICHT-GPL Anwendung ein GPL Plugin schreiben?"


    Und wenn ich von Plugins spreche: technisch gesehen muss ein Plugin - will es die Grundfunktionalitaet der host-Applikation verwenden - eben mit den GPL-Bibliotheken der Applikation linken, und genau dort liegt sitzt eben der Hase im Pfeffer: das geht nur, wenn diese Bibliotheken eben diese "link exception" aufweisen.

    Uhh, alles schrecklich kompliziert :)

    Gruss, Oliver
    • 17 Aug 2007, 11:37 am
  • Oliver Knoll
    Oliver Knoll
    The company name is only visible to registered members.
    Re^6: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Enrico Weigelt wrote:
    Oliver Knoll schrieb:
     
    Mit Qt (C++ Framework) ist das eine Frage von ca 10 Zeilen mehr Code, um ein Plugin (zur *Laufzeit* nachladbare Komponente) zu erstellen.
     
    Dafür binden man sich einen Klumpen ans Knie der schon Stunden zum Compilieren braucht und überhaupt mit Resourcen nicht grade
    knausrig umgeht.
    Pointshop 3D (http://www.pointshop3d.com) brauchte (mit allen Plugins) ca 10 Minuten zum einmal Durchkompilieren. Unsere jetztige Anwendung "ReportManager" (bei AutoForm) braucht ca. 25 Minuten. Qt 3.x selbst braucht ca 40 Minuten.

    Ressourcenverbrauch ist im Vergleich zu Java auessert gering, da keine JVM. Startzeit von PointShop3D < 5 Sekunden, ReportManager ebenfalls.

    Ich verstehe nicht, wohin Ihre Argumentation abzielt?

     
    Von Hand geschrieben (C/C++) kostete mich dies auch in meiner Diplomarbeit Pointshop3d (http://www.pointshop3d.com) nicht mehr als einen Auswand von 2 Tagen (Plugin Loader + Interface definieren, Unix und win32).
     
    Zwei Tage für dlopen() ?! ;-o
    Nein, zwei Tage fuer das Plugin-Interfaces (Mehrzahl!) definieren, dokumentieren, das ganze Plattformunabhaengig machen (nicht nur Unix, auch Windows!), Pluginmanager schreiben (Pluginverzeichnis durchsuchen, Plugin-Menustruktur entsprechend aufbauen (mit Untermenues gemaess Directory-Struktur)), memory management (die Plugins sollen bloss *bei Gebrauch* geladen werden und dann gleich wieder entladen werden).

    Plugins waren dabei saemtliche interaktiven Werkzeuge (Paint tool, Filter tool), der 3D-Renderer (OpenGL, "Punktbasierter Renderer", ...), das Fileformat und die "Plugins" a la Photoshop selbst (im "Pluginsmenu"), also 4 Interfaces.

    Das war das in 2 Tagen ;)

    Bei Interesse: http://graphics.ethz.ch/pointshop3d/documentation.html

     
    Dennoch: soweit ich mich erinnern kann, war die Schlussfolgerung einer dieser Diskussionen wirklich die, das eine GPL Anwendung nicht gegen eine closed source Bibliothek linken darf - auch wenn diese bloss als Plugin (also nicht unbedingt fuer das eigentliche Laufen der Applikation notwendig) vorliegt.
     
    Heh ?! Waren wir nicht grade beim Gegenteil ?
    Ich weiss nicht, ich muss zugeben, ich habe bloss das 1. posting gelesen und die letzten 10 oder so. Aber ich hatte davon gesprochen, NICHT-GPL Code gegen GPL-Code zu linken.

     
    Natürlich darf eine GPL-Anwendung gegen proprietären Code linken.
    Wie sonst sollte sonst GNU unter Windows gehen ? ;-o
    Davon hatte ich eben gerade nicht gesprochen ;) Und dem OP ging es glaube ich auch darum, dass der JDBC-Treiber jetzt eben GPL ist, sprich: "Darf er seine NICHT-GPL Anwendung damit noch linken und vertreiben?" Wenn der JDBC-Treiber eben proprietaer/NICHT-GPL waere, dann waere die Fragestellung ja gar nicht aufgekommen.

    Gruss, Oliver
    • 17 Aug 2007, 11:49 am
  • User photo
    Fritz Knubbel
    (not a XING member)
    Re^7: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Oliver Knoll schrieb:

    Pointshop 3D (http://www.pointshop3d.com) brauchte (mit allen Plugins) ca 10 Minuten zum einmal Durchkompilieren. Unsere jetztige Anwendung "ReportManager" (bei AutoForm) braucht ca. 25 Minuten. Qt 3.x selbst braucht ca 40 Minuten.
    Aktuelles Qt4 kürzlich auf 'nem Athlon64-2X (dualcore) compiliert:
    hat ca. 45 Minuten !

    Ist das nicht abartig ? ;-o

    Ressourcenverbrauch ist im Vergleich zu Java auessert gering, da keine JVM. Startzeit von PointShop3D < 5 Sekunden, ReportManager ebenfalls.
    Es gibt noch mehr JVM's außer der von Sun, einige sogar speziell für embedded
    systems - die sind zuweilen um einiges flotter ;-P

    Ich verstehe nicht, wohin Ihre Argumentation abzielt?
    Vielleicht, daß Qt viel zu fett ist ?

    Gut, es gibt da im Bereich (halb-)kommerzieller OSS noch schlimmerer
    Code-Verbrechen, zB. Openoffice ;-P
    (braucht auf 'nem Athlon64-2X schonmal über 12h !)

    Natürlich darf eine GPL-Anwendung gegen proprietären Code linken.
    Wie sonst sollte sonst GNU unter Windows gehen ? ;-o
     
    Davon hatte ich eben gerade nicht gesprochen ;) Und dem OP ging es glaube ich auch darum, dass der JDBC-Treiber jetzt eben GPL ist, sprich: "Darf er seine NICHT-GPL Anwendung damit noch linken und vertreiben?" Wenn der JDBC-Treiber eben proprietaer/NICHT-GPL waere, dann waere die Fragestellung ja gar nicht aufgekommen.
    hmm, also wenn er auf eine generische API setzt, die dann einen beliebigen
    Treiber (uA. also auch den von mysql) nachladen kann, sehe ich da überhaupt
    kein Problem. Sonst wäre ja das Starten eines GPL-Programms auf einem
    non-GPL OS auch illegal ;-P


    Gruß
    • 12 Feb 2008, 1:34 pm
  • User photo
    Fritz Knubbel
    (not a XING member)
    Re^5: MySQL Lizenzpolititk JDBC-Treiber LGPL -> GPL
    Oliver Knoll schrieb:

    Man darf eben nur nicht
    sein Programm zusammen mit der GPL'ed libfoo, sondern allenfalls dem Replacement vertreiben.
     
    Das ist ebenfalls korrekt: natuerlich darf ich ein closed-source (oder sagen wir halt einfachheitshalber "Nicht-GPL") Programm vertreiben, sobald ich jeglichen Code, der frueher unter GPL war, durch eine *Eigenentwicklung* ersetzt habe.
    Stimmt. Aber die API/ABI darf ich beibehalten.

    Das geht aber an meiner urspruenglichen Frage vorbei: "Darf ein NICHT-GPL binary (Bibliothek oder Applikation) mit einem GPL binary linken?" Und die Antwort ist eben "Ja, aber bloss wenn die entsprechende GPL die 'link exception' aufweist", siehe ein anderes frueheres posting von mir.
    Jain. Man muß unterscheiden zwischen Interface und dem konkreten Code!
    Man darf eine existierende Library natürlich nachbauen (meinetwegen auch
    nur als Stub) und seinen Code dagegen linken. Wenn der dynamische Linker
    dann zur Laufzeit die Original-Lib reinlädt, ist das nicht mehr Sache des Autors
    (der non-GPL-Software), sondern der konkreten Installation des Users.

    Vielleicht kann man sich jetzt darüber streiten, ob der (End-)User sowas tun
    darf, aber der non-GPL-Autor ist dann raus aus dem Spiel. Da die GPL aber
    nur die Distribution und nicht die Benutzung regelt, sehe ich da keine Probleme.

    Ihr jetzt sicher folgende Einwand, warum man denn ueberhaupt closed-source Produkte fuer GNU/Linux kompilieren darf (welche ja
    >
    Ja, die LGPL macht extra die Ausnahme, daß man betreffende Library
    (unverändert) direkt einlinken darf, sogar statisch.
     
    Der Linux-Kernel und die C/C++ runtime libraries sind unter GPL, NICHT LGPL! Siehe "link exception" in der GPL.
    Bei den C++-libs hab ich jetzt nicht nachgeschaut, aber die Glibc ist LGPL.
    Der Kernel ist GPL, aber dagegen link'ed man ja auch nicht.

    Man braucht nur das Plugin-Interface kompatibel nachprogrammieren,
    und schon ist auch das wieder vom Tisch.
     
    Ja, aber meine Fragestellung war gerade umgekehrt: "darf ich ein NICHT-GPL Plugin fuer eine GPL Applikation schreiben (und vertreiben)?" und nicht: "Kann ich zu meiner NICHT-GPL Anwendung ein GPL Plugin schreiben?"
    Das geht in beide Richtungen. Plugins sind ja nunmal keine klassischen Libraries
    (gegen die direkt gelinkt wird), sondern Codestücke, die nachgeladen werden.

    Die Frage lautet also in dem Moment: darf ein non-GPL-Programm eine GPL-Library
    laden und verarbeiten. Wäre das der Fall, dann dürfte man sie nichtmal auf einem
    non-GPL-System *benutzen*, dh. man dürfte ergo auch keine GPL-Programme
    auf einem non-GPL-System starten.

    Und wenn ich von Plugins spreche: technisch gesehen muss ein Plugin - will es die Grundfunktionalitaet der host-Applikation verwenden - eben mit den GPL-Bibliotheken der Applikation linken, und genau dort liegt sitzt eben der Hase im Pfeffer: das geht nur, wenn diese Bibliotheken eben diese "link exception" aufweisen.
    Da sind wir aber wieder beim *umgekehrten* Fall zu den Mysql-Treibern.

    Aber auch das läßt sich prima lösen, indem man einfach die Schnittstelle
    (ABI) der Host-Anwendung exemplarisch nachbaut.


    Gruß
    • 12 Feb 2008, 1:55 pm