Entspricht die Bereitstellung von Objektdateien der LGPL-Relink-Klausel?

Aus dieser Frage zu SO habe ich gelesen:

Proprietärer Quellcode + LGPL-Quellcode

statisch verknüpft:
- Entweder müssen Sie beide Teile als LGPL freigeben.
- Oder stellen Sie alles bereit, was es dem Benutzer ermöglicht, die Anwendung mit einer anderen Version des LGPL-Quellcodes zu verknüpfen. In diesem Fall sind die anderen Anforderungen dieselben, als ob sie dynamisch verknüpft wären.

Es hört sich also so an, als würde die Bereitstellung von Objektdateien ausreichen, um LGPL hinsichtlich der statischen Verknüpfung einer LGPL-Bibliothek mit einer proprietären Codeanwendung zufrieden zu stellen. Während die ausführbare Datei statisch verknüpft ist, kann der Endbenutzer durch Bereitstellen der Objektdateien die Anwendung neu kompilieren und eine Verknüpfung zu einer anderen Version der Bibliothek herstellen.

Ist das richtig und wenn nicht, warum dann?

lgpl static-linking

— IvanB
quelle

Ja, Sie sind völlig richtig. Das Bereitstellen der Objektdateien für Ihre Anwendung reicht aus, um die LGPL zu erfüllen, da der Benutzer die LGPL-Bibliothek durch eine andere Version ersetzen kann, wenn er dies wünscht.

Die FSF sagt dies sogar ausdrücklich in ihren FAQ :

Zur Einhaltung der LGPL (alle vorhandenen Versionen: v2, v2.1 oder v3):

(1) Wenn Sie eine statische Verknüpfung mit einer LGPL-Bibliothek herstellen, müssen Sie Ihre Anwendung auch in einem Objektformat (nicht unbedingt im Quellformat) bereitstellen , damit ein Benutzer die Möglichkeit hat, die Bibliothek zu ändern und die Anwendung erneut zu verknüpfen.

(2) Wenn Sie eine dynamische Verknüpfung mit einer LGPL-Bibliothek herstellen, die bereits auf dem Computer des Benutzers vorhanden ist, müssen Sie die Quelle der Bibliothek nicht übermitteln. Wenn Sie jedoch selbst die ausführbare LGPL-Bibliothek zusammen mit Ihrer Anwendung übermitteln, unabhängig davon, ob sie statisch oder dynamisch verknüpft ist, müssen Sie auch die Quellen der Bibliothek auf eine der von der LGPL bereitgestellten Arten übermitteln.

— Ixrec
quelle

Warum behaupten Qt "Insider" und Mitarbeiter ständig etwas anderes? Ist die LGPL von Qt modifiziert oder so?

— IvanB

Ich bin mit der Qt-Situation nicht vertraut, aber beim Überfliegen der Lizenzierungsseiten sehe ich keine Sprache, die diese Möglichkeit ausdrücklich ablehnt. Ich denke, sie lassen es lediglich weg, um die dynamische Verknüpfung zu empfehlen (was für die meisten Benutzer wahrscheinlich die einfachere Lösung ist). Der relevanteste Wortlaut, den ich sehe, lautet: "Im Falle einer statischen Verknüpfung der Bibliothek ist die Anwendung selbst möglicherweise nicht mehr" Arbeit, die die Bibliothek verwendet "und unterliegt daher der LGPL. Es wird empfohlen, entweder dynamisch zu verknüpfen oder die bereitzustellen Anwendungsquellcode an den Benutzer unter LGPL. ", was völlig vernünftig ist.

— Ixrec

Es sieht auch so aus, als ob einige Qt-Module nur unter der GPL und nicht unter der LGPL verfügbar sind, wenn ich diese Seiten richtig lese. Wenn sie also die Option für die statische Verknüpfung mit Objekten erwähnen, müssen sie sich möglicherweise auch darum kümmern "es sei denn, Sie verwenden X, Y oder Z" und ähnliche langweilige tangentiale Details.

— Ixrec

In einer perfekten Welt mag dynamisches Verknüpfen großartig sein, aber in dieser Welt und im Umgang mit Qt ist dynamisches Verknüpfen die Hölle. Wie mehr als 60 Megabyte DLLs, von denen viele das Bereitstellungstool nicht einbringt und der Abhängigkeits-Walker nicht erkennt. In ihren eigenen LGPL-FAQ sehe ich ein,

The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.

aber nichts davon, obligatorisch zu sein.

— IvanB

Wenn sie ihre FAQ lesen, scheinen sie nur schüchtern zu sein, eine (falsche) Behauptung aufzustellen, dass LGPL proprietären Anwendungen nicht erlaubt, statisch mit Qt zu verknüpfen, obwohl sie dies sehr sorgfältig implizieren.

— IvanB