Appelez le logiciel GPL à partir d'un logiciel non GPL

30

Puis-je (légalement) utiliser un programme qui est publié sous GPL à partir d'un autre programme que j'écris et ne pas avoir à respecter la GPL (pour le programme que j'écris)?

Par exemple, j'ai une interface graphique qui utilise un programme (qui est sous GPL), puis-je cacher le code dans l'interface graphique et même le vendre?

gpl Valmond
la source

Réponses:

30

Vous pouvez utiliser un programme GPL à partir de votre propre programme sans que votre programme soit affecté par la GPL, mais vous ne pouvez pas lier le code GPL à votre propre programme sans que votre programme soit soumis aux termes de la GPL.

Dans l'exemple fourni dans la question, dans lequel vous avez écrit un wrapper GUI autour d'un programme de ligne de commande existant, votre interface graphique n'est pas liée par les termes de la GPL, à condition qu'il s'agisse d'un programme distinct qui exécute le programme GPL dans un processus séparé et communique avec lui uniquement via la ou les interfaces existantes - par exemple, via la ligne de commande et / ou via stdin / stdout.

Quelques bits pertinents de la FAQ GPL :

Où est la frontière entre deux programmes distincts et un programme en deux parties? Il s'agit d'une question juridique que les juges décideront en dernier ressort. Nous pensons qu'un critère approprié dépend à la fois du mécanisme de communication (exec, pipes, rpc, appels de fonction dans un espace d'adressage partagé, etc.) et de la sémantique de la communication (quels types d'informations sont échangées).

Si les modules sont inclus dans le même fichier exécutable, ils sont définitivement combinés dans un seul programme. Si les modules sont conçus pour s'exécuter liés ensemble dans un espace d'adressage partagé, cela signifie presque certainement les combiner en un seul programme.

En revanche, les canaux, les sockets et les arguments de ligne de commande sont des mécanismes de communication normalement utilisés entre deux programmes distincts. Ainsi, lorsqu'ils sont utilisés pour la communication, les modules sont normalement des programmes distincts. Mais si la sémantique de la communication est suffisamment intime, échangeant des structures de données internes complexes, cela pourrait aussi être une base pour considérer les deux parties comme combinées dans un programme plus vaste.

Puis-je publier un programme non gratuit conçu pour charger un plug-in couvert par la GPL?

Cela dépend de la façon dont le programme appelle ses plug-ins. Par exemple, si le programme utilise uniquement des fork et des exécutions simples pour appeler et communiquer avec des plug-ins, les plug-ins sont des programmes distincts, de sorte que la licence du plug-in ne fait aucune exigence concernant le programme principal.

Si le programme relie dynamiquement les plug-ins, qu'ils s'appellent entre eux et partagent des structures de données, nous pensons qu'ils forment un seul programme, qui doit être traité comme une extension à la fois du programme principal et des plug-ins. Pour utiliser les plug-ins couverts par la GPL, le programme principal doit être publié sous la licence GPL ou une licence de logiciel libre compatible GPL, et que les termes de la GPL doivent être suivis lorsque le programme principal est distribué pour être utilisé avec ces plug-ins.

Si le programme relie dynamiquement les plug-ins, mais que la communication entre eux se limite à invoquer la fonction «principale» du plug-in avec certaines options et à attendre son retour, c'est un cas limite.

Notez que la GPL s'applique dans son intégralité au programme de ligne de commande sous-jacent dans tous les cas - si vous le distribuez (par opposition à ce que les utilisateurs l'obtiennent d'une autre source), vous êtes responsable de fournir une copie de la GPL aux utilisateurs, ce qui en fait clair pour eux que le programme de ligne de commande est sous la GPL (même si le wrapper GUI ne l'est pas), et en mettant à leur disposition le code source du programme de ligne de commande sur demande. De la FAQ GPL à nouveau:

Si les gens devaient distribuer des logiciels couverts par la GPL en les qualifiant de «partie» d'un système que les utilisateurs savent être en partie propriétaires, les utilisateurs pourraient être incertains de leurs droits concernant les logiciels couverts par la GPL. Mais s'ils savent que ce qu'ils ont reçu est un programme gratuit et un autre programme, côte à côte, leurs droits seront clairs.

Clause de non-responsabilité standard: je ne suis pas avocat et, même si j'étais avocat, je ne suis pas votre avocat. Si vous avez besoin d'une réponse définitive, consultez un professionnel du droit approprié autorisé à exercer dans votre juridiction.

Dave Sherohman
la source
1
Il convient de noter que la position de la FSF sur la liaison est minoritaire. (Et, OMI, cela n'a aucun sens. Un processus automatisé ne peut pas créer une nouvelle œuvre.)
David Schwartz
1
Cependant, la FSF a rédigé la GPL. Cela rend leur opinion beaucoup plus pertinente. "Quand nous disons X, nous voulons dire {...}" est généralement accepté par les tribunaux. "Quand vous avez dit X, vous vouliez dire {...}", non.
MSalters
Qu'est-ce que cela signifie par "n'utilise que de simples fork et exec pour invoquer" - quelqu'un peut-il clarifier cela?
Krunal
Ainsi, la GPL peut être facilement contournée en écrivant simplement un wrapper de tuyau pour exécuter le code GPLed dans un processus séparé? Cela semblerait rendre la GPL non pertinente et impossible à appliquer. Et si j'écris ma propre bibliothèque et que je fais un lien avec une bibliothèque sous GPL. Ma bibliothèque autonome séparée devient-elle alors également GPL? Que se passe-t-il si je crée un lien vers la bibliothèque de quelqu'un d'autre en utilisant du code GPL? Leur bibliothèque devient-elle GPL? Si vous répondez non à l'une de ces questions, cela ouvre une faille massive pour contourner facilement la GPL. Si vous répondez oui, vous violez la loi sur le droit d'auteur.
Cerin
@Cerin - La GPL ne s'applique vraiment qu'au code que vous distribuez. Ainsi, bien que vous puissiez écrire un programme qui lie à la fois aux licences GPL et non compatibles GPL, vous ne pouvez pas ensuite distribuer ce programme à des tiers, car il exécuterait du code GPL et non compatible GPL dans le même processus. ("L'utilisation sans redistribution" est considérée par beaucoup comme une faille dans la GPL, car cela signifie que les services Web et autres peuvent contourner la GPL entièrement parce qu'ils exécutent le logiciel eux-mêmes au lieu de le donner aux utilisateurs. La GNU AGPL est un tenter de résoudre ce problème.)
Dave Sherohman
0

Cela dépend de ce que vous entendez par l'utiliser?

  • compilez-le dans votre code
  • utiliser une bibliothèque partagée
  • exécuter un exécutable

Cela dépend également de la version / variante de la GPL sous laquelle se trouve l'autre code.

  • GPL
  • LGPL
  • AGPL
  • Probablement d'autres

Mentions légales: je ne suis pas avocat.

Martin York
la source
-2

Cela dépend de la façon dont votre programme "utilise" le programme GPL. La FAQ GPL a une explication assez longue , mais elle laisse encore beaucoup de place à l'interprétation:

Vous ne pouvez pas intégrer un logiciel couvert par la GPL dans un système propriétaire. (...) Cependant, dans de nombreux cas, vous pouvez distribuer le logiciel couvert par la GPL aux côtés de votre système propriétaire. Pour le faire valablement, vous devez vous assurer que les programmes gratuits et non libres communiquent sans lien de dépendance, qu'ils ne sont pas combinés d'une manière qui ferait d'eux un programme unique. (...) si les deux programmes sont combinés de manière à devenir effectivement deux parties d'un même programme, vous ne pouvez pas les traiter comme deux programmes distincts. La GPL doit donc couvrir le tout.Si les deux programmes restent bien séparés, comme le compilateur et le noyau, ou comme un éditeur et un shell, alors vous pouvez les traiter comme deux programmes distincts, mais vous devez le faire correctement. Le problème est simplement d'ordre de forme: comment décrivez-vous ce que vous faites? Pourquoi nous soucions-nous de cela? Parce que nous voulons nous assurer que les utilisateurs comprennent clairement le statut gratuit du logiciel couvert par la GPL dans la collection.

Je pense que dans votre exemple d'une interface graphique qui existe principalement pour appeler un programme GPL en ligne de commande, les deux forment clairement un seul programme, vous devrez donc publier votre code sous la GPL.

Michael Borgwardt
la source
Non, ils ne "forment clairement pas un seul programme". Tant que le programme de ligne de commande sous-jacent reste capable de fonctionner en l'absence de la superposition GUI, ils sont combinés par "simple agrégation" et ne sont pas "effectivement un seul programme". Notez les exemples dans le texte que vous avez cité - un compilateur se trouve au-dessus du noyau et ne fonctionnera pas sans lui, mais le noyau fonctionnera avec plaisir en l'absence du compilateur.
Dave Sherohman,
1
@Dave: La question de savoir si le programme de ligne de commande sous-jacent peut continuer à fonctionner en l'absence de la superposition de l'interface graphique peut être pertinente si l'état de la licence du programme de ligne de commande est en question - mais la question concerne l'interface graphique, qui est complètement inutile sans le programme de ligne de commande, et donc il est vrai sans l'ombre d'un doute qu'ils forment un seul programme.
Michael Borgwardt,
Remplaçons l'un des exemples de la section que vous avez citée et voyons comment cela tient. "... mais la question concerne le compilateur, qui est complètement inutile sans le noyau, et il est donc vrai sans l'ombre d'un doute qu'ils forment un seul programme." Sauf, bien sûr, que le texte que vous avez cité indique explicitement "vous pouvez les traiter comme deux programmes distincts". Si c'était simplement une question de dépendance, alors vous ne pourriez jamais exécuter un logiciel fermé sous Linux car ce logiciel serait "complètement inutile" sans le noyau (GPLed).
Dave Sherohman
@Dave: Sauf, bien sûr, que les compilateurs et toutes sortes de logiciels fermés ne sont PAS inutiles sans le noyau Linux, car ils peuvent et fonctionnent sur tout ce qui implémente les normes de bibliothèque POSIX et / ou C, et fournissent des fonctionnalités importantes qui leur sont propres . Tout à fait différent d'un wrapper GUI qui existe uniquement pour piloter un programme de ligne de commande spécifique.
Michael Borgwardt, le
3
Vous vous trompez sur la partie GUI, cependant. Cette même enveloppe GUI va travailler avec d' autres programmes de CLI, notamment les versions ultérieures de l'original. Cela est pertinent dans ce contexte, car cela signifie que les droits GPL d'origine sur le programme sous-jacent peuvent toujours être exercés. Si je le recompile pour être 10% plus rapide, la CLI ne me gêne pas.
MSalters
-3

Non.

Le code GPL ne peut être utilisé que par un autre code GPL.

Citant la première ligne de l' article GPL de wikipedia :

La GPL est la première licence copyleft à usage général, ce qui signifie que les œuvres dérivées ne peuvent être distribuées que sous les mêmes conditions de licence.

En plus de cela, la GPL fait plusieurs pages et existe en plusieurs versions.

Attention, coup de gueule personnel à venir!

Personnellement, je n'aime pas beaucoup la licence GPL en raison de sa nature très restrictive et virulente. Ils l'appellent "gratuit" mais c'est en fait tout le contraire, le code GPL ne peut être utilisé par rien d'autre qu'un autre code GPL. Forcer ainsi d'autres projets dans GPL ou être obligé de réécrire des bibliothèques entières, que votre projet actuel soit open source ou non. Il y avait d'énormes projets open source, comme freeBSD par exemple qui ont été obligés de réécrire des centaines de milliers de lignes de code linux parce que leur licence était incompatible, elle était trop "gratuite" dans le sens "faites ce que vous voulez", ce qui est évidemment non compatible avec GPL.

Si vous voulez une licence vraiment "gratuite" dans le sens "faites ce que vous voulez", je recommande la licence BSD ou MIT ... en fait, la plupart des autres licences sont OK. Ce n'est que la GPL qui est vraiment problématique parce qu'elle est restrictive et qu'elle y force les autres. Enfin, c'est trop compliqué.

Ah, oui, c'est aussi un aller simple. La GPL peut utiliser du code / des bibliothèques sous licence de la plupart des licences, mais ces bibliothèques / code ne peuvent pas utiliser le code GPL à leur tour.

dagnelies
la source
Il dit "œuvres dérivées". Cela inclut-il un logiciel qui se lie dynamiquement au code GPL?
plié à droite le
@WTP: certainement oui - tout l'intérêt de la LGPL est d'avoir une licence différente qui le permet.
Michael Borgwardt,
3
Un shell GUI enroulé autour d'un programme en ligne de commande n'est pas un "travail dérivé" tel que défini à des fins de copyright.
Dave Sherohman
1
@Dave Sherohman - cela ne semble pas clair. La réponse acceptée à cette question dit: "À mon humble avis, un emballage pur qui expose simplement la fonctionnalité d'un programme GPL devrait être GPL." Ce n'est pas seulement l'aspect technique de la façon dont ils communiquent, c'est l'intention. Par exemple, traduire un livre, c'est créer une œuvre dérivée. Le convertir au format Kindle serait un travail dérivé. Je pouvais voir un juge décider que l'ajout d'une interface graphique créait une œuvre dérivée. Il faut se méfier.
Scott Whitlock,