LPGL - Ist man verpflichtet die alte Version zur Verfügung zu stellen, die man im eigenen Produkt verwendet hat?



  • Bsp:

    Man verwendet in einer Software eine Bibliothek mit der Version 1.0 die als Lizenz die LGPL hat.

    Da man den Quellcode zur Verfügung stellen muss, stellt man nun diesen auf den eigenen zum Lesen öffentlichen FTP Server.

    Nach ein paar Monaten kommen von der Bibliothek neue Versionen heraus, diese wird aber nicht durch einen Patch oder ähnliches im eigenen Produkt verwendet.

    Frage:

    Muss man die damals verwendete alte Version (also 1.0) zur Einhaltung der LGPL online stellen, oder genügt es, wenn man immer nur die aktuellste Version der Bibliothek, die unter der gleichen LGPL Version steht, online stellt?



  • Natürlich die Version, die im Projekt verwendet wird.



  • Ich bin gar nicht sicher ob man den Source irgendwie zugänglich machen muss so lange man keine modifizierte Version der LGPL Library verwendet. Aber ich kenn mich damit auch nicht wirklich aus, also... hab nix gesagt 😃

    Die "fiesere" Einschränkung der LGPL ist aber: man muss es Nutzern ermöglichen das eigene Produkt mit neueren Versionen der LGPL Lib zu verwenden.
    Dummerweise sind viele LGPL Libs nicht wirklich darauf ausgelegt ebendas zu ermöglichen. In C++ heisst das z.B. im Prinzip dass sich die Header-Files nicht ändern dürfen, weil sizeof()- oder Layout-Änderungen von Klassen bedeuten dass man auch das "konsumierende" Projekt neu übersetzen müsste.

    Lustig sind dabei dann Projekte wie z.B. LIVE555, die gleich überhaupt keinen DLL-Build anbieten. Auf Systemen die Shared-Objects verwenden geht es vermutlich auch so, aber auf Windows (das von LIVE555 offiziell als Plattform unterstützt wird) ist man "angeschissen". Es sei denn man bastelt sich den DLL-Support selbst, was dann aber bedeutet dass man den so modifizierten Code auf jeden Fall wieder selbst irgendwo hosten muss. (Bzw. auf Nachfrage zugänglich machen, falls das reichen sollte.)
    Und das über-ulkige daran ist dann: man würde sich diesen Aufwand im Prinzip für nichts machen, da ich mal davon ausgehe dass die Maintainer einer Library die keinen DLL-Build anbietet auch nicht darauf achten werden keine "DLL-breaking-changes" in neuen Versionen zu machen.

    Bei Java, C# oder allgemein Sprachen die ein weniger "hartes" Bindungsmodell verwenden ist es dagegen oft kein Problem. (Ausser natürlich es werden Änderungen gemacht die sowieso niemals kompatibel sein können, wie z.B. das Umbenennen von Klassen, Funktionen oder dergleichen.)

    ps: Libs mit reinem C-Interface sind natürlich auch oft unproblematisch.


Anmelden zum Antworten