Forum Linux.général librairie GPL

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
1
juil.
2005
Il y a un truc que je ne comprend pas dans la licence GPL.
Si j'utilise une librairie de fonction en licence GPL alors mon programme doit etre GPL (je dit bien utiliser, sans rien modifier).
Mais par contre, quand j'utilise linux pour faire tourner un programme, alors la je ne suis pas oblige de le distribuer en GPL, Pourtant linux aussi est en GPL, et j'utilise bien des fonctions du noyau linux pour faire tourner mon programme (ouverture de fichier, gestion de la memoire, ...) ?
  • # ! Attention LGPL inside

    Posté par  . Évalué à 2.

    Quand tu utilises le noyau Linux, tu ne l'utilises pas directement... tu passes par la glic qui elle est sous license LGPL...
    • [^] # Re: ! Attention LGPL inside

      Posté par  . Évalué à 2.

      Pas sûr, puisque si c'était le cas, la glib utilise le noyau sous GPL, elle ne devrait pas pouvoir être sous GFDL...
    • [^] # Re: ! Attention LGPL inside

      Posté par  . Évalué à 2.

      Et les appels-systèmes du noyau Linux sont eux aussi sous LGPL.

      De plus, cette obligation de passer le logiciel sous GPL n'existe que s'il y a intégration entre ton programme et celui sous GPL... Les shells, par exemple, utilisent bien des programmes GPL (à chaque fois que leur utilisateur tape une commande correspondant à un programme GPL), mais ça ne les fait pas passer sous GPL pour autant.

      Plus généralement, si ton programme utilise un programme GPL, mais uniquement par l'intermédiaire d'un fork()+execve() (ou d'un simple execve()), il n'est pas tenu de passer sous GPL : il n'y a pas intégration.
    • [^] # Re: ! Attention LGPL inside

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      sauf que si on resonne comme ca, la glibc devrait etre en GPL et non LGPL car la GPL du noyau est contaminante !

      J'ai plus qu'une balle

      • [^] # Re: ! Attention LGPL inside

        Posté par  . Évalué à 3.

        sauf que si on resonne comme ca, la glibc devrait etre en GPL et non LGPL car la GPL du noyau est contaminante !

        Inutile de raisonner si bruyamment ;-) , de toutes façons, rien n'interdit de rajouter des droits à la GPL, y compris celui de s'y lier sans passer sous GPL, et c'est ce qui a été fait pour passer tous les appels-systèmes du noyau sous LGPL.
  • # Élément de réponse

    Posté par  . Évalué à 4.

    En fait, c'est un des points pas très clairs de la GPL, je crois. Parce que ça sous-tend quelque chose de très technique, qui est lié à la liaison dynamique.

    En gros, pour utiliser une bibliothèque dans un programme, tu as deux moyens : la liaison statique (c'est à dire que tu compiles ta bibliothèque en même temps que ton programme, et ton binaire contiendra les deux -- il sera autonome, en fait), et la liaison dynamique (tu ne compiles pas en même temps, ton binaire ne pourra s'exécuter que si l'utilisateur a aussi, sur sa machine, le binaire de la librairie). Si j'ai bien compris, si la bibliothèque est GPL, dans le premier cas, ton programme doit être GPL, mais pas dans le deuxième cas. C'est dans ce contexte que tu utilises les fonctions du noyau (tu ne recompiles pas ton noyau avec ton programme), et tu as donc le droit de les utiliser sans pour autant mettre ton programme en GPL).

    De même, tu as le droit d'utiliser les sorties d'un programme GPL dans une appli propriétaire. Par exemple, tu as le droit de lancer une commande (ps -a par ex.), de regarder ce qu'elle renvoie et d'en faire ce que tu veux.

    Le principal problème, c'est qu'évidemment, il existe toujours des cas très limite. Les plug-in, par exemple, sont à mon avis un exemple de problème où ça vaut le coup de s'arracher les cheveux. Un plug-in GPL peut-il fonctionner avec un soft non GPL, ou vice-versa? De plus, ça rend la GPL complètement inapplicable pour quelque chose qui n'est pas exactement un logiciel, ou pour un logiciel qui n'est pas distruibué sous forme de binaires (un script par exemple). Wikipédia, qui est en GFDL, souffre du même genre de problèmes d'interprétation : peut-on inclure une image sous un autre licence, un bout de texte sous une autre licence, quid du droit de citation (puisque la GPL est contaminante, ça suggèrerait que la citation passe sous GPL, ce qui n'est pas le cas), etc etc.

    Si tu trouves ça compliqué, je pense que c'est normal. C'est quand même très compliqué, et il vaut mieux faire confiance aux autres :-) Par exemple, si debian définit tel logiciel comme libre et compatible GPL, bah il vaut mieux leur faire confiance.
    • [^] # Re: Élément de réponse

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Je suis en peu dubitatif sur ce resonnement !

      Prenons un exemple parlant : QT.
      Si je cree un programme en utilisant QT et que je fait une liaison dynamique, alors je devrait pouvoir distribuer mon programme sous la forme d'une licence commercial. Dans ce cas je connais une entreprise qui se retrouverait vite sur la paille !!

      En fait je pose cette question car je risque d'etre confonte au probleme : Pour mon stage je doit realiser un programme pilotant un microcontroleur par USB, sous windows ET sous linux. Sous windows j'ai utilise le driver standart HID (comme ca pas de drivers a ecrire), ce qui m'a permis d'utiliser dev-cpp (car j'ai lu que pour ecrire un driver kro on est OBLIGE d'utiliser visual C++).

      Maintenant je voudrait faire le meme programme sous linux. Pour cela j'ai vu qu'il existe une librairie (elle est pas terminee mais devrait etre utilisable) nommee libhid. Seulement voila elle est en GPL et bien personnes ne veut entendre parler d'application GPL dans l'entreprise (en plus ce serait une appli pour l'armee).

      voila mon probleme

      J'ai plus qu'une balle

      • [^] # Re: Élément de réponse

        Posté par  . Évalué à 3.

        Dans ce cas precis, si libhid n'est pas LGPL ou BSD, tu ne peux tout simplement pas l'utiliser si tu ne veux pas que ton code soit GPL.
      • [^] # Re: Élément de réponse

        Posté par  . Évalué à 3.

        Pas de chance. Tu as trois possibilités :
        - faire une appli GPL,
        - utiliser une autre bibliothèque,
        - réécrire cette bibliothèque.

        Quand une bibliothèque est sous GPL, c'est justement pour empêcher qu'on ne l'utilise depuis un programme non GPL.
      • [^] # Re: Élément de réponse

        Posté par  . Évalué à 3.

        À mon avis, la subtilité est dans la licence des headers de la librairie. Par exemple, dans ceux de la librairie standard de G++, on peut lire:

        "// As a special exception, you may use this file as part of a free software
        // library without restriction. Specifically, if other files instantiate
        // templates or use macros or inline functions from this file, or you compile
        // this file and link it with other files to produce an executable, this
        // file does not by itself cause the resulting executable to be covered by
        // the GNU General Public License. This exception does not however
        // invalidate any other reasons why the executable file might be covered by
        // the GNU General Public License."

        Donc tu peux faire "#include <vector.h>" sans pour autant passer ton programme sous GPL. Dans les hearders de qt sous Linux, on lit:

        "** This file may be distributed and/or modified under the terms of the
        ** GNU General Public License version 2 as published by the Free Software
        ** Foundation and appearing in the file LICENSE.GPL included in the
        ** packaging of this file.
        **
        ** Licensees holding valid Qt Enterprise Edition or Qt Professional Edition
        ** licenses may use this file in accordance with the Qt Commercial License
        ** Agreement provided with the Software."

        À mon avis, voila pourquoi on a le droit d'utiliser QT dans un contexte commercial quand on a acheté la licence.

        Maintenant, c'est vrai que je ne comprends plus cette histoire de linkage statique et dynamique, car même en cas de linkage dynamique, on doit inclure les headers. Si les headers sont en GPL, de toutes manières, le logiciel doit être GPL. Si les headers offrent le choix, alors on peut avoir certainement plus de latitude.

        Je me suis un peu balladé sur Internet, et on peut lire les deux versions. Ce sont deux interprétations différentes de la GPL :

        1) le linkage statique est interdit, le linkage dynamique est possible (dans ce cas, quel est l'intéret de la LGPL?)
        2) aucun linkage n'est autorisé, sauf cas particulier : noyau, glibc, etc.

        J'ai peur de t'avoir embrouillé plus que nécessaire :-)

        • [^] # Re: Élément de réponse

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          De ce que j'ai compris, a partir du moment ou j'utilise une librairie GPL (GPL pur !) je doit fournir mon programme sous licence gpl un point c'est tout (pas de linkage dynamique ou statique )!

          J'ai plus qu'une balle

  • # Et pour les drivers ??????

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Je crois avoir bien compris le probleme em se qui concerne les librairies, en gros

    si GPL "pur" alors progamme en GPL !

    Mais en se qui concerne les drivers GPL qui sont integre au noyau, en toute logique vu que les appel systemes sont sous LGPL je devrais pouvoir les utiliser sans pour autant avoir un programme GPL ?

    Je me pose la question car mon programme utilise le drivers hiddev, mais il ne fait que lire le fichier /dev/usb/hiddev et il lui passe des parametres par ioctl !

    voila

    J'ai plus qu'une balle

Suivre le flux des commentaires

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