Existe-t-il une faille dans la GPL qui permet de relier les logiciels propriétaires aux bibliothèques GPL?

Examinons un scénario hypothétique:

La société X écrit un programme propriétaire (A) qui établit une liaison dynamique avec une bibliothèque propriétaire (B). La société Y souhaite utiliser une bibliothèque de remplacement (C) sous licence GPL, et écrit donc une bibliothèque wrapper (D) qui se lie dynamiquement à A et C et traduit les appels d'API utilisés par A aux appels d'API utilisés par C.

Comme D est destiné à être utilisé avec C et utilise les appels API de C, il s'agit d'un travail dérivé de C et doit donc être distribué selon les termes de la GPL *. En conséquence, le travail combiné de A et D doit également être distribué sous les termes de la GPL, ce qui est impossible étant donné que la société Y ne possède pas le code source de A. Cela dit, tant que la société Y distribue D par elle-même , Il n'y a pas de problème. Cependant, quelles que soient les actions de la société Y, la société X ne viole pas la GPL en distribuant A, même sans B. La simple existence de D ne signifie pas que A est soudainement une œuvre dérivée de C (par D) qui doit être autorisée sous la GPL aussi.

Voici l'échappatoire: rien n'empêche la société X d'écrire sa propre version de D, de la distribuer séparément de A et de dire aux utilisateurs finaux d'utiliser D au lieu de B lors de l'exécution de A. Il semble qu'une entreprise soit capable de concevoir un programme propriétaire pour utiliser une bibliothèque GPL sans violer la GPL, tant qu'un module wrapper est utilisé pour isoler le programme propriétaire de la bibliothèque GPL et que ce module est distribué séparément.

Suis-je correct dans mon raisonnement? Est-ce une véritable faille dans la GPL?

* D est également un travail dérivé de A, mais pour les besoins de ce scénario, la société X a explicitement autorisé la création de D et lui a permis d'être autorisé sous la GPL.

IANAL, mais voici mon avis sur ce qui est autorisé dans les limites de la GPL:

• diffuser l'œuvre combinée "A - B" en public: très bien, peut se faire sous n'importe quelle licence propriétaire

• créer un wrapper lib D pour C par Y: très bien, cela n'implique pas que A doit être placé sous GPL

• utiliser le produit combiné "A - D - C" en interne par Y: également très bien, la GPL n'a pas besoin d'ouvrir l'open source A tant que la combinaison n'est pas distribuée au public

• distribuer le travail combiné "A - D - C" en public: cela nécessitera que A soit open-source et placé sous GPL (et peu importe si X ou Y ont distribué cette combinaison; en outre, si Y veut faire cela, ils auraient besoin d'une licence de distribution pour A de X, bien sûr)

La question intéressante est maintenant: D&C peut-il être distribué séparément en open source sous GPL, A&B (ou simplement A sans B) peut-il être distribué sous une licence propriétaire, et l'utilisateur final remplace-t-il B by D&C par lui-même?

Ici, la modification finale de "AB" qui rend A dépendant des bibliothèques D & C est effectuée par l'utilisateur final - après distribution . On pourrait donc affirmer que la modification finale n'est effectuée qu'en interne par l'utilisateur final. Et il semble que cela soit possible sans violer la GPL - et ce que vous obtenez est une combinaison fonctionnelle de "AC&D" où A est sous licence propriétaire et C&D sous GPL.

Bien sûr, un avocat ou un juge peut avoir une opinion différente à ce sujet. Pour obtenir une réponse finale, je pense que vous devez attendre que quelqu'un l'essaie et qu'une seconde le poursuive.

Je suppose que pour la plupart des systèmes, il sera difficile de créer une telle constellation sans concevoir "A" depuis le début d'une manière qui fonctionnera de manière transparente avec B ou C. Et dans ce cas, on pourrait penser que A était en quelque sorte dérivé de C.

EDIT: en y réfléchissant un moment, une situation similaire m'est venue à l'esprit: l'écriture et la distribution de plugins sous licence GPL pour les applications de source fermée. Prenons par exemple Photoshop. Je ne pense pas que quelqu'un essaierait sérieusement d'appliquer Adobe à Photoshop open source simplement parce qu'il existe des plugins GPL de fournisseurs tiers. Ici, même une "librairie wrapper" n'est pas nécessaire car il existe une interface bien définie. Cependant, cela changerait-il la situation si Photoshop incorporait certaines de ses fonctions centrales à partir d'un plug-in tiers sous GPL? Je pense que dans un tel cas, il peut devenir très difficile de décider où tracer la ligne, à quel point le produit de source fermée est une œuvre "basée sur" la bibliothèque GPL.

EDIT2: Il existe des bibliothèques à double licence, avec une licence GPL pour une utilisation non commerciale et une licence propriétaire pour une utilisation commerciale comme celle-ci, par exemple. Donc, votre "échappatoire" signifierait développer un produit basé sur une telle bibliothèque (en utilisant la version commerciale, donc la GPL ne s'applique pas à votre produit), livrer votre produit en source fermée sans la bibliothèque au public et laisser la fin- l'utilisateur obtient et installe lui-même la version GPLed. Dans un tel cas, je suppose que le vendeur de la bibliothèque aura de bonnes chances de vous poursuivre avec succès pour violation de licence (si vous ne payez pas pour sa bibliothèque, bien sûr). Vaut-il la peine? Probablement pas. Surtout dans l'exemple que j'ai lié, vous devrez acheter la bibliothèque non plus, car le prix ne dépend pas de la fréquence à laquelle vous vendez votre produit, mais uniquement du nombre de développeurs qui utilisent la bibliothèque pendant le développement.

Enfin, en raison de ces risques juridiques, si j'ai l'intention d'utiliser des bibliothèques open-source au sein d'un produit open-source, j'éviterais les bibliothèques GPL si possible, et je n'essaierais pas de faire usage de cette "faille". LGPL ou GPL avec exception de liaison est beaucoup plus sûr, ou tout type de licence de système d'exploitation non viral.

Un exemple pratique sont les pilotes graphiques propriétaires pour Linux que l'utilisateur final doit installer lui-même. Surtout pour le créateur du pilote propriétaire, si l'utilisateur final distribue le travail combiné, cela crée une obligation légale pour l'utilisateur final (qu'ils ne peuvent éventuellement pas remplir) mais pas pour le créateur du pilote.

Une autre réponse affirme que "puisque le programme dépend de la bibliothèque, c'est toujours un travail dérivé" - mais si le programme ne fonctionne pas réellement parce que la bibliothèque n'est pas là, alors ce n'est pas dérivé.

Mais au final, si vous comptez sur des "failles", vous devez considérer que votre approche n'est peut-être pas la bonne en premier lieu.

La liaison définit un dérivé par la GPL. Cette situation spécifique est ce que la LGPL a été conçue pour gérer: où vous voulez publier la bibliothèque en tant que GPL mais définir la liaison comme limite explicite de la licence appliquée, ou alternativement, où vous voulez établir un lien avec un code GPL mais que vous devez utiliser le vôtre le travail soit publié sous une licence non GPL elle-même.

Dans le cas où l'utilisateur final va faire la liaison (créer son propre code à partir de sources non GPL qui peuvent se lier à une bibliothèque GPL), l'utilisateur final n'a pas effectivement créé une version GPL de tout ce que le produit final est, car il n'est pas autorisé à modifier la licence de la partie non GPL du projet car il n'en est pas le propriétaire. Cela empêche généralement la distribution par l'utilisateur final sous quelque forme que ce soit, mais n'interdit pas son utilisation.

Cela dit, si un projet nécessite qu'il soit construit à partir des sources et distribué uniquement de cette façon, la licence sous laquelle la bibliothèque liée est sans importance, car cela est entièrement hors de la portée du développeur non GPL. Autrement dit, comment pouvez-vous savoir que votre distribution source uniquement sera construite sur gcc contre glibc VS construit sur un compilateur IBM contre leur libc, sauf si vous le spécifiez sous vos propres conditions de licence? Cela se traduit rapidement par une utilisation équitable et des interdictions contre les conditions juridiques inapplicables (pas que le fantasme n'ait pas été inscrit dans la loi à plusieurs reprises récemment).

Je ne suis pas avocat, mais pour autant que je sache, vous n'avez pas raison, car le programme dépend de la bibliothèque - c'est toujours un travail dérivé. De la même manière qu'une séquence est un travail dérivé. Au minimum, il est basé sur les API définies dans la bibliothèque.