Comment la règle de liaison statique vs dynamique GPL s'applique-t-elle aux langages interprétés?
À ma connaissance, la GPL interdit la liaison statique du code non GPL au code GPL, mais autorise la liaison dynamique du code non GPL au code GPL. Alors, quel est-il lorsque le code en question n'est pas lié du tout parce que le code est écrit dans un langage interprété (par exemple Perl)?
Il semblerait trop facile d'exploiter la règle si elle était considérée comme une liaison dynamique, mais d'un autre côté, il semblerait également impossible de référencer légalement le code GPL à partir d'un code non-GPL s'il était considéré comme statique! Les langages compilés ont au moins une distinction entre la liaison statique et la liaison dynamique, mais lorsque toute la "liaison" ne fait qu'exécuter des scripts, il est impossible de dire quelle est l'intention sans une licence explicite!
Ou ma compréhension de ce problème est-elle incorrecte, ce qui rend la question théorique? J'ai également entendu parler d'une "exception de chemin de classe" qui implique une liaison dynamique; cela ne fait-il pas partie de la GPL mais plutôt quelque chose qui peut y être ajouté, donc la liaison dynamique n'est autorisée que lorsque la licence inclut cette exception?
Quant à la question spécifique concernant les langues interprétées, GPL FAQ est très clair :
Le programme interprété, pour l'interprète, n'est que des données; une licence de logiciel libre comme la GPL, basée sur le droit d'auteur, ne peut pas limiter les données sur lesquelles vous utilisez l'interpréteur. Vous pouvez l'exécuter sur toutes les données (programme interprété), comme vous le souhaitez, et il n'y a aucune exigence quant à la licence de ces données pour quiconque.
Quant à la question générique sur la liaison dynamique vs statique. Tout d'abord, la FSF et Stallman estiment que peu importe que la liaison soit statique ou dynamique, la GPL infecte dans les deux cas. De la FAQ FSF GPL:
Si le programme relie dynamiquement les plug-ins , et qu'ils se font des appels de fonction et partagent des structures de données, nous pensons qu'ils forment un programme unique, qui doit être traité comme une extension du programme principal et des plug-ins. Cela signifie que la combinaison du plug-in couvert par la GPL avec le programme principal non libre violerait la GPL.
et
La liaison [nom de votre programme] de manière statique ou dynamique avec d'autres modules est faire un travail combiné basé sur [nom de votre programme]. Ainsi, les termes et conditions de la licence GNU General Public License couvrent l'ensemble de la combinaison
Cependant, cela est discutable du point de vue juridique. Dans le seul cas qui a été porté devant les tribunaux concernant les liens dynamiques - Galoob c. Nintendo - La Cour d'appel a statué que le travail dérivé "doit incorporer une partie du travail protégé par le droit d'auteur sous une forme quelconque". Ce qui n'est pas le cas avec la liaison dynamique.
Quoi qu'il en soit, que la liaison dynamique infecte ou non, il existe un moyen de contourner le problème. Il est utilisé par exemple par Nvidia pour fournir des pilotes binaires pour Linux. Vous créez un wrapper (L) GPL, mais en tant qu'auteur, vous êtes autorisé à ajouter une exception spéciale pour le lien avec une source fermée spécifique. Vide FAQ FSF GPL .
Remarque: il s'agit d'une question juridique. Programmers.SE n'est pas un forum juridique, c'est un forum de programmation. Bien que les gens ici connaissent un peu la programmation, ils ne connaissent rien à la loi. Si vous voulez poser une question juridique, vous devriez le demander dans un forum juridique, où il y a des gens qui savent réellement quelque chose sur le sujet.
La GPL ne dit rien sur la liaison statique ou dynamique. Il ne dit même rien sur la liaison pas du tout. Chaque avocat ou juge à qui j'ai parlé dit que la question des liens statiques et dynamiques est complètement hors de propos.
Le droit d'auteur concerne la créativité. La liaison statique vs dynamique est un détail d'implémentation technique. Que quelque chose soit lié statiquement ou dynamiquement ou non n'est pas un acte créatif, il ne peut pas changer le statut de copyright d'une œuvre.
Dans votre question, vous parlez de "langues interprétées". Mais ce terme n'a pas de sens: il n'y a pas de langage interprété. Un langage est un ensemble abstrait de règles et de restrictions mathématiques. Un langage n'est ni interprété ni compilé. Une langue juste est. Le terme "langage interprété" n'est pas seulement faux, il est non sensible. Si l'anglais était une langue tapée, ce serait une erreur de frappe.
L'interprétation et la compilation sont des traits de l'interprète ou du compilateur (duh!), Pas la langue. Chaque langue peut être implémentée avec un interpréteur, et chaque langue peut être implémentée avec un compilateur. La plupart des langues ont les deux. La plupart des implémentations de langage modernes combinent même les deux dans un seul moteur d'exécution.
La mise en œuvre Rubinius Ruby, par exemple, contient un compilateur statique à l'avance qui compile Ruby en code octet Rubinius, un interpréteur qui interprète l'octet Rubinius) et un compilateur dynamique juste à temps qui compile le code d'octet Rubinius en LLVM IR, que l'infrastructure LLVM compile à son tour en code machine natif. Le MacRuby Ruby Implementation ne contient pas de interprète du tout, il compile Ruby code directement en LLVM IR, puis en code machine natif.
D'un autre côté, il existe des interprètes pour C ou C++.
Tout cela n'est que des détails techniques. Cela n'a aucun rapport avec le droit d'auteur.
Cela n'a tout simplement pas de sens que le fait que quelqu'un viole ou non le droit d'auteur de quelqu'un d'autre dépend de la décision ou de la tierce personne d'exécuter le programme avec un interprète ou de le compiler en premier.
La question est de savoir si une œuvre dérive d'une autre œuvre ou non. Il peut être lié dynamiquement et toujours dérivé, et il peut être lié statiquement et pas dérivé du tout.
Aucune idée de combien de vérité il y a là-dedans, et IANAL, etc .; mais dans mon interprétation, ce qui est important est de savoir si la bibliothèque que vous liez est sous une forme quelconque incluse dans le "binaire" (où "binaire", dans le cas des langages de programmation dynamiques, est juste le code source tel que distribué; c'est ce que je fais de la définition de la FSF de "binaire" dans ce contexte).
Donc, si vous référencez des bibliothèques à partir de votre code sans les inclure dans votre distribution, je considérerais cela comme l'équivalent d'une "liaison dynamique", alors que si vous regroupez les bibliothèques avec votre produit ou copiez-collez des parties de la bibliothèque dans votre propre code, le scénario de "liaison statique" s'appliquerait. Ceci, au moins, est dans l'esprit de la GPL: vous pouvez librement tiliser (exécuter, inspecter, référencer) le logiciel GPL sans restrictions, mais dès que vous dérivez à partir de celui-ci (en liant ou en copiant des parties de celui-ci dans votre propre produit distribuable), il devient viral et votre logiciel doit également être GPL.