Forum Linux.général Licence GPL quand on compile chez le client

Posté par  .
Étiquettes : aucune
1
10
avr.
2011

Admettons que :

  • j'écris un logiciel hello_world.c qui appelle des .h d'un projet sous GPL. Je compile mon programme (gcc -c hello_world.c) chez moi, je dispose d'un .o
  • le client installe séparément gcc et des bibliothèques GNU, éventuellement je produits un installeur (sous GPL) pour lui faciliter le travail.
  • j'ai aussi distribué script.sh au client. Le script demande : « Le programme hello_world.o a été trouvé ; voulez-vous faire l'édition des liens avec les bibliothèques GPL disponibles ?». L'utilisateur clique sur oui, le script produit un binaire.

J'imagine : Sachant que l'édition des liens est faite sur la machine du client, les restrictions GPL sur la distribution des binaires statiquement ou dynamiquement liés ne s'applique pas à moi mais seulement au client.

Ai-je donc réussi à distribuer hello_world.o sous licence proprio tout en appelant des bibliothèques GPL ? Si ce n'est pas possible, qu'est-ce qui coince ?

(Question dans l'intérêt de la science, je ne compte pas faire un truc pareil.)

  • # gpl .o

    Posté par  . Évalué à 1.

    j'écris un logiciel hello_world.c qui appelle des .h d'un projet sous GPL. Je compile mon programme (gcc -c hello_world.c) chez moi, je dispose d'un .o

    Je dirais que pour suivre la GPL (dans les includes de hello_world.c), si tu donnes hello_world.o à quelqu'un, tu dois aussi lui donner hello_world.c (sous une licence compatible GPL je pense, voire GPL).

    • [^] # Re: gpl .o

      Posté par  . Évalué à 4.

      Je crois que j'ai le droit de réimplémenter une lib GNU, sous licence différente, en partant du manuel. P.ex. wine implémente sous licence GPL l'API d'un OS sous licence proprio. Je peux réécrire la partie des .h dont j'ai besoin (voire, faire confiance aux déclarations implicites de gcc). Pour respecter les formes, je peux aussi coder une implémentation lente, incomplète et bugguée de la lib GNU, sous le nom de libProprio. À l'édition des liens, on pourrait choisir entre libProprio et libGNU.

      Ce que je gagne, c'est que j'ai dépensé très peu de ressources à développer libProprio, mais le client a droit à toute la puissance de libGNU.

      • [^] # Re: gpl .o

        Posté par  . Évalué à 1.

        Je crois que j'ai le droit de réimplémenter une lib GNU, sous licence différente, en partant du manuel. P.ex. wine implémente sous licence GPL l'API d'un OS sous licence proprio.

        Possible, bien que pour wine, c'est dans le sens contraire.

        À l'édition des liens, on pourrait choisir entre libProprio et libGNU.

        T'as peut-être raison, tu peux peut-être réécrire "from scratch" les headers de la lib et donner une implémentation bidon. Du coup, j'aurais pensé que le problème se pose chez le client au link :
        On ne pourrait se lier avec libGNU que si le programme qui se lie est compatible GPL, et avec libProprio que si le programme qui se lie est compatible avec la licence de libProprio, et non pas uniquement que l'on peut s'y lier dès qu'il y a compatibilité d'API/ABI.
        Comme tu aurais développé libProprio avec une licence spécialement pour que le client puisse s'en servir "légalement", il pourrait s'en servir, mais il ne pourrait pas se lier avec libGNU vu que hello_world.o ne serait pas compatible GPL.

        Mais tes exemples gnuplot ou freecad semblent prouver le contraire, alors je sais pas.

        • [^] # Re: gpl .o

          Posté par  . Évalué à 2.

          Pour info, l'opinion des dévs de Gentoo est que une violation de licence dans l'édition des liens n'est pas grave car « il y en a déjà de nombreuses, par exemple avec les drivers binaires nvidia »

          18:35 <@robbat2> at the point of RESTRICT="bindist mirror", we're only ever shipping ebuilds, and any linkage violation is on the end users system, where plenty of it exists already (eg nvidia binary drivers) source

          • [^] # Re: gpl .o

            Posté par  (site web personnel) . Évalué à 3.

            Pour info, l'opinion des dévs de Gentoo est que une violation de licence dans l'édition des liens n'est pas grave car « il y en a déjà de nombreuses, par exemple avec les drivers binaires nvidia »

            Leur point de vue est alors complètement stupide et je pèse mes mots.

            La GPL s'étend sur les travaux dérivés. En gros, si tu écris un code qui a besoin d'un autre bout de code (de taille "conséquente") qui est sous GPL, l'ensemble est sous GPL car ton programme a besoin de ce bout code, c'est donc un "travail dérivé". La manière de lier les 2 n'a aucune importance (liaison statique, dynamique ou réseau).

            La GPL utilise cette notion légal de travail dérivé, qui est en général utilisé pour les traductions ou les représentations d'une œuvre.

            Le cas des drivers Linux est différent. C'est le cas d'utilisation d'un bout de code qui fonctionne ailleurs tout seul. Je crois que cela a commencé avec le code de gestion d'un système de fichier existant avant Linux (minix ?). Le code de NVIDIA existe pour windows et très peu de code est spécifique à Linux. Le driver de NVIDIA a donc du sens, même sortie de Linux, ce n'est donc pas un travail dérivé de Linux.

            "La première sécurité est la liberté"

            • [^] # Re: gpl .o

              Posté par  . Évalué à 2.

              si tu écris un code qui a besoin d'un autre bout de code (de taille "conséquente") qui est sous GPL, l'ensemble est sous GPL car ton programme a besoin de ce bout code,

              Et si mon programme fait « system ("grep") » (ou expr, ou sed) et lit la sortie ? J'ai besoin de grep/expr/sed, je gagne une fonctionnalité deregex mais je n'en fais pas un travail dérivé.

              • [^] # Re: gpl .o

                Posté par  (site web personnel) . Évalué à 2.

                Bonne question.

                Je pense que si ton programme peut s'en passer: Il n'y a pas de dépendance. Si ton programme n'est qu'un wrapper proprio à un programme GPL, cela parait logique qu'il devienne GPL.

                Ensuite, si tu fait system("grep"), tu utilises le grep standard unix, ton script pourrait marcher sous solaris, HP unix, etc... Donc, tu ne dépends pas exclusivement du grep GPL.

                "La première sécurité est la liberté"

            • [^] # Re: gpl .o

              Posté par  (site web personnel) . Évalué à 3.

              Sauf que ce n'est pas l'avis des développeurs de Gentoo, simplement un raccourci qui omet de traduire la partie importante de la remarque :

              we're only ever shipping ebuilds,

              En fait, ils ne sont pas concernés, puisque c'est l'utilisateur qui effectue l'édition des liens. La question se pose si des binaires sont distribués.

              • [^] # Re: gpl .o

                Posté par  . Évalué à 2.

                La question se pose si des binaires sont distribués.

                Oui et c'est même pris en compte, avec la ligne RESTRICT="bindist" qui indique au gestionnaire de paquets d'avertir l'utilisateur s'il demande à créer un paquet binaire à partir de l'installation locale :

                19:37:48 root src/ quickpkg freecad
 * media-gfx/freecad-0.11.3729: package has RESTRICT=bindist!
 * media-gfx/freecad-0.11.3729: it might not be legal to redistribute this.
 * Building package for media-gfx/freecad-0.11.3729 ...                  [ ok ]

 * Packages now in '/usr/portage/packages':
 * media-gfx/freecad-0.11.3729: 16.7M

                • [^] # Re: gpl .o

                  Posté par  (site web personnel) . Évalué à 2.

                  bon, bin si tu le sais, pourquoi la question de ton journal alors ?

                  • [^] # Re: gpl .o

                    Posté par  . Évalué à 3.

                    J'ai l'impression d'être le seul à avoir vu un trou dans la GPL (distribuer une lib bidon et faire l'édition de liens d'une lib GNU distribuée séparément). Je suis un peu préoccupé, alors me renseigne, dans l'espoir d'avoir manqué quelque chose d'évident. Comme rien de particulier n'est apparu dans la discussion, l'étape suivante est de poser la question au Software Freedom Law Center.

        • [^] # Re: gpl .o

          Posté par  . Évalué à 3.

          Je pense que l'autorisation découle de la liberté 0 du logiciel libre : exécuter le code pour ce que je veux su mon poste. Les obligations de la licence ne découlent que de la redistribution.

    • [^] # Re: gpl .o

      Posté par  . Évalué à 3.

      Note que l'excuse « nous ne distribuons aucun binaire » (gentoo distribue uniquement des scripts de compilation) est utilisée en routine par Gentoo pour justifier des « liaisons dangereuses » :

      • gnuplot (licence pas tout à fait libre) lié avec readline (GPL).
      • freecad (GPL+LGPL) qui appelle coin3d (GPL) et opencascade (licence à peu près libre mais incompatible GPL)

      • [^] # Re: gpl .o

        Posté par  (site web personnel) . Évalué à 4.

        àmha ce n'est :

        • ni une "excuse"
        • ni une "justification"

        Cette difficulté de redistribution ne les concerne pas, tout simplement. Tu peux le voir comme un contournement éventuellement, mais je ne suis même pas sûr que cela soit l'esprit, c'est un avantage (ou un inconvénient) induit, selon le point de vue.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.