La fourniture de fichiers objets satisfait-elle à la clause de liaison LGPL?

10

De cette question sur SO , j'ai lu que:

Code source propriétaire + code source LGPL

  • lié statiquement:
    • Soit vous devez libérer les deux parties en tant que LGPL.
    • Ou fournissez tout ce qui permet à l'utilisateur de relier l'application avec une version différente du code source LGPL. Dans ce cas, les autres exigences sont les mêmes que si elle était liée dynamiquement.

Il semble donc que fournir des fichiers objets soit suffisant pour satisfaire LGPL en termes de liaison statique d'une bibliothèque LGPL à une application de code propriétaire. Alors que l'exécutable est lié statiquement, la fourniture des fichiers objets permet à l'utilisateur final de recompiler l'application, en se liant à différentes versions de la bibliothèque.

Est-ce correct et sinon, pourquoi?

lgpl static-linking IvanB
la source

Réponses:

7

Oui, vous avez tout à fait raison. Fournir les fichiers objets de votre application est suffisant pour satisfaire la LGPL car cela permet à l'utilisateur de remplacer la bibliothèque LGPL par une autre version s'il le souhaite.

La FSF le dit même explicitement dans sa FAQ :

Dans le but de se conformer à la LGPL (toute version existante: v2, v2.1 ou v3):

(1) Si vous établissez une liaison statique avec une bibliothèque LGPL, vous devez également fournir votre application dans un format objet (pas nécessairement source) , afin qu'un utilisateur ait la possibilité de modifier la bibliothèque et de relier l'application.

(2) Si vous établissez une liaison dynamique avec une bibliothèque LGPL déjà présente sur l'ordinateur de l'utilisateur, vous n'avez pas besoin de transmettre la source de la bibliothèque. D'un autre côté, si vous transportez vous-même la bibliothèque exécutable LGPL avec votre application, qu'elle soit liée de manière statique ou dynamique, vous devez également transmettre les sources de la bibliothèque, de l'une des manières prévues par la LGPL.

Ixrec
la source
1
Alors pourquoi les «initiés» et les employés de Qt affirment-ils continuellement le contraire? La LGPL de Qt est-elle modifiée ou quelque chose?
IvanB
Je ne connais pas la situation de Qt, mais en parcourant leurs pages de licence, je ne vois aucun langage qui nie explicitement cette possibilité. Je pense qu'ils l'ont simplement omis en faveur de la recommandation de liens dynamiques (qui est probablement la solution la plus simple pour la plupart des utilisateurs). La formulation la plus pertinente que je vois est: "En cas de liaison statique de la bibliothèque, l'application elle-même peut ne plus être" un travail qui utilise la bibliothèque "et donc devenir soumise à la LGPL. Il est recommandé soit de lier dynamiquement, soit de fournir le code source de l'application à l'utilisateur sous LGPL. ", ce qui est tout à fait raisonnable.
Ixrec
Il semble également que certains modules de Qt ne soient disponibles que sous la GPL plutôt que sous la LGPL, si je lis bien ces pages, il est donc possible que s'ils mentionnaient l'option de liaison statique avec des objets, ils devraient également s'y attacher "sauf si vous utilisez X, Y ou Z" et des détails tangentiels ennuyeux similaires.
Ixrec
1
Dans un monde parfait, la liaison dynamique peut être formidable, mais dans ce monde et lorsqu'il s'agit de Qt, la liaison dynamique est un enfer. Comme plus de 60 mégaoctets de DLL, dont beaucoup l'outil de déploiement n'apporte pas et le marcheur de dépendance ne détecte pas. Dans leur propre FAQ LGPL, je vois un 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.mais rien sur le fait d'être obligatoire.
IvanB
4
En lisant leur FAQ, il semble qu'ils hésitent à faire une (fausse) affirmation que LGPL n'autorise pas les applications propriétaires à se lier statiquement à Qt, tout en étant très diligent à l'impliquer.
IvanB