La LGPL s'applique à Java exactement comme pour C/C++

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
23
juil.
2003
GNU
Dave Turner, Monsieur License de la FSF a confirmé l'interprétation de la Apache Software Foundation concernant l'utilisation de classes Java provenant d'une Jar sous LGPL.

La section 6 de la licence s'applique dans le cas de Java. C'est à dire qu'un import java est équivalent à l'édition des liens en C (la liaison dans java est entièrement au runtime, pour ceux qui n'auraient pas remarqué) .

Ce qui signifie que si vous faites des modifications à une bibliothèque LGPL que l'on utilise de cette manière, vous devez publier les modifications selon les termes de la licence. La situation est la même que pour du C/C++.

Le probleme d'Apache est qu'ils veulent leurs bibliothèques sous une licence plus permissive que celles de GNU (en particulier sur le copyright). Cette clarification m'a paru nécessaire après l'énorme incompréhension suivant la publication par /. d'un troll assez bien ficelé sous le titre « La LGPL est virale pour Java ».

L'auteur sous-entendait que les classes java liées au runtime avec des .jar sous LGPL devaient être sous LGPL également. J'espère avoir dissipé cette confusion.

Le problème vient de la formulation floue du dit article 6 :

As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. [...]

Certains ont vu la une faille pour les langages dont la "liaison" s'effectue au runtime comme Java, ce qui vient d'être clarifié.

Aller plus loin

  • # Re: La LGPL s'applique à Java exactement comme pour C/C++

    Posté par  . Évalué à 2.

    wow, j'ai du l'envoyer y a une semaine, cette news....
    y a des gens qui ont la chance d'avoir des vacances ;)

  • # Re: La LGPL s'applique à Java exactement comme pour C/C++

    Posté par  . Évalué à 1.

    il y a erreur dans l'intitulé du lien LGPL

  • # 2ème lien

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

    le texte de la LGPL

  • # Re: La LGPL s'applique à Java exactement comme pour C/C++

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

    Bon, je sais que c'est pas d'une importance capitale, mais il faut dire "bibliothèque" et pas "librairie".

  • # Re: La LGPL s'applique à Java exactement comme pour C/C++

    Posté par  . Évalué à 4.

    Un troll, je ne pense pas..

    Je suis convaincu que la majorité des développeurs Java pensait de bonne foi, qu'importé un point jar était l'équivalent de la liaison dynamique pas statique.

    J'ai lu /. et d'ailleurs une bonne partie des intervenant le croyait toujours car l'explication de l'homme de loi de la FSF était aussi claire que d'habitude quand un homme de loi parle, c'est à dire nébuleuse..
    Pff, un avocat ça ne doit pas savoir répondre par oui ou par non..

    Quelqu"un connait-il une license "équivalente" à la LGPL, mais qui n'aurait pas ce problème?

    Ce serait bien si la FSF en proposait une de ce type..

    • [^] #

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

      > Je suis convaincu que la majorité des développeurs Java pensait de bonne foi, qu'importé un point jar était l'équivalent de la liaison dynamique pas statique.

      Et alors, c'est pas le cas ?
      s/porté/porter/ btw

      liaison dynamique == au runtime
      (en fait "dynamique" est + restrictif, on prépare la liaison avec ld avant l'exécution)

      • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

        Posté par  . Évalué à 5.

        c'est bien la le probleme, certains estimaient que : rien ne distingue my_class.class de jar_class.class dans lgpl-jar.jar et qu'a l'edition de lien a l'execution (speciale dedicace a l'academie francaise ;) , celle ci ne rentrant pas dans le cadre de l'article 6 de la lgpl (ce qui est faux d'apres la fsf et apache), obligation etait faite de publier toutes les classes sous lgpl.

        ce qui a conduit certains huluberlus a dire que la license de toutes les classes de sun etant incompatible avec la lgpl on pouvait oublier cette license si on developpe sous java.

        tout cela est faux.

        de plus, le "reel" probleme vise est bien celui specifique de "j'ai modifie le jar sous lgpl mais comme c'est un jar, je dois pas redistribuer les modifs ..." et le message de la fsf est : "tu dois le faire"

        si j'ai poste cette news c'est par rapport au relatif desarroi que cela a cree parmis les entreprises : elles se sont vues (celles qui ont vu le troll passer) forcees de publier leur code sous lgpl pendant un moment.

        Mais bon, en dernier ressort : rien ne lie l'interpretation de la license faite par la fsf a celle que l'utilisateur en fait. En cas de conflit, c un juge qui decide.
        D'ou la necessite imho de clarifier la license.

        • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

          Posté par  . Évalué à 1.

          Apparemment j'avais besoin de cette clarification!

          OK donc faire une librairie (un .jar) en Java est totalement identique a la faire en C/C++ du point de vue de la LGPL.

          (Ouf!) Pas de quoi en faire un fromage, effectivement.

    • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

      Posté par  . Évalué à -1.

      Un troll ? Attend pour voir :
      << Et pour multideskos, c'est valable aussi ? >>

    • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

      Posté par  . Évalué à 2.

      Bon, je ne suis pas un expert mais d'après ce que je comprends de la dépêche, elle prétend exactement ce que tu entends être une croyance erronée : un point-jar LGPL peut être importé par un code non LGPL. Mais si tu modifies le .jar importé, alors tu dois publier les modifications.
      C'est exactement la même chose que "linker" avec une bibliothèque LGPL, autant que je comprenne.
      On dirait que cette news ne dissipe pas tous les doutes :-)

      Cordialement,

  • # Si j'ai bien compris

    Posté par  . Évalué à 4.

    Cela signifie que si je crée une application qui doit tourner sous jboss (http://www.jboss.org/index.html(...)), attendu que jboss est LGPL et que mon application doit importer des classes de jboss pour fonctioner (jnp par exemple), mon application doit forcément être GPL ou LGPL ?

    • [^] # Re: Si j'ai bien compris

      Posté par  . Évalué à 4.

      Si j'ai mieux compris, si on crée une appli qui utilise jboss, mais que l'on patche jboss pour rajouter un truc. Alors ce patch sur jboss doit être distribué.

      Mais le programme qui utilise le jboss patché peut très bien être propriétaire...

      NB: je repompe en plus long la phrase juste avant la phrase en gras...

      • [^] # Re: Si j'ai bien compris

        Posté par  . Évalué à 1.

        Si vous modifiez du code GPL/LGPL vous n'êtes pas obligé de dévoiler ce code modifié, sauf si vous distribuez des binaires, etc. (GPL classique, copyleft)

    • [^] # Re: Si j'ai bien compris

      Posté par  . Évalué à 1.

      non, c'est l'inverse.
      tu licenses ton appli comme tu veux, mais jboss reste sous lgpl.
      et tu redistribue les changements que tu as faits a jboss

      c tout.

      • [^] # Re: Si j'ai bien compris

        Posté par  . Évalué à 6.

        La news est super pas claire

      • [^] # Re: Si j'ai bien compris

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

        C'est vrai que la news n'est pas super claire ... Enfin, maintenant j'ai compris :-)

        Maintenant une nouvelle question, qu'appelle-t-on "modifier la bibliothèque LGPL" ? Si dans mon programme j'étends une classe de la bibliothèque, je suppose que ce n'est pas une modification de la bibliothèque ? Si ? Par contre si je "patch" le jar de la bibliothèque pour remplacer l'implémentation d'une classe, là je dois distribuer cette classe précise sous LGPL. C'est bien ça ?

        • [^] # Re: Si j'ai bien compris

          Posté par  . Évalué à 3.

          tu as bien compris.

          Le pb etait que sous le pretexte des modalites d'editions de liens de java, certains ne redistribuaient pas leurs modifs de la bibliotheque.

          Si tu etends une classe de la bibliotheque dans ton programme ou dans une autre bibliotheque ca passe.
          Si tu etends cette meme classe dans la bibliotheque lgpl (que tu pourrais ainsi redistribuer, modifiee, a tes clients), tu dois publier le patch et la distribuer sous lgpl.

          desole si la news n'est pas super claire.
          L'une des choses a retenir, c'est que la license est un bon endroit pour dissiper les doutes sur tous ces termes et qu'a defaut de le faire, on se retrouve avec des communiques vaseux que tout le monde interprete comme il veut....

    • [^] # Re: Si j'ai bien compris

      Posté par  . Évalué à 1.

      Si vous importez du LGPL votre code peut être libre ou non, c'est toute la différence de la LGPL par rapport à la GPL.

  • # puisqu'on est dans les trolls

    Posté par  . Évalué à -3.

    super la licence ala bsd qui permet à n'importe quelle societe de reprendre le source sans redistribuer quoi que ce soit.

    voila bon troll

    • [^] # Re: puisqu'on est dans les trolls

      Posté par  . Évalué à 2.

      Maintenant je comprends pourquoi les developpeurs de jetspeed viennent de refuser d'integrer un CMS java parce qu'il est GPL, de tete je crois bien qu'ils parlaient de l'aspect viral. C'est bien dommage parce qu'un cms c'est ce qui manque à jetspeed.

      Visiblement l'apache group tient à sa licence, aprés tout c'est un peu normal c'est la leur.

      Maintenant si j'ai bien compris l'aspect viral de la licence LGPL ne porte que sur les sources du composant en LGPL?. Cela ne fait pas un peu tempete dans un verre d'eau?.

      • [^] # Re: puisqu'on est dans les trolls

        Posté par  . Évalué à 2.

        Tu as bien compris.
        c'est une tempete dans un verre d'eau.
        la phrase a retenir c'est le titre de la news.

        Le probleme c'est que qd l'annonce a ete faite par la fsf, la plupart des gens ne l'ont pas comprise.

      • [^] # Re: puisqu'on est dans les trolls

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

        Heureusement, il y a un autre CMS chez la Fondation Apache : Lenya.
        http://cocoon.apache.org/lenya/(...)

      • [^] # Re: puisqu'on est dans les trolls

        Posté par  . Évalué à 1.

        Cet aspect viral n'existe pas puisque vous êtes censé lire la licence du code que vous souhaitez intégrer, pour savoir si vous en avez le droit ou pas. Si votre logiciel est propriétaire et que le code que vous souhaitez intégrer est GPL/LGPL, vous n'en avez pas le droit tant qu'il est propriétaire.

        Où est le virus ?

  • # Re: La LGPL s'applique à Java exactement comme pour C/C++

    Posté par  . Évalué à 1.

    quels sont les arguments pour justifier l'emploi de la licence "apache" plutot qu'une licence LGPL ?

    • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

      Posté par  . Évalué à 3.

      La licence Apache est d'inspiration Berkeley. C'est une licence libre non compatible avec la GPL (d'après la FSF, mais pas d'après la ASF) car elle comporte une clause de publicité. Par exemple je suis un vilain qui reprend du code Apache dans un soft proprio => je suis obligé de mentionner "de façon visible" que j'utilise du code Apache. En fait il s'agit d'une citation à mentionner telle quelle. Dans les faits c'est une licence pragmatique et concise. Le seul problème est sa compatibilité avec la licence open source la plus utilisée (souvent par défaut par des gens qui n'ont pas pris le temps de la comprendre ...), la GPL. Sur ce point la FSF n'a jamais justifié sa position autrement que par un "elle n'est pas compatible car elle demande plus de choses" ou "il y a des clauses incompatibles". Ce n'est pas un troll, c'est juste la vérité. Envoie un mail à la FSF sur le sujet, tu aura une réponse langue de bois. Pourtant l'ASF a demandé à plusieurs reprises des justifications, mais n'ont jamais eu mieux que ça ... Le texte de la licence Apache : 
      /*
 * ============================================================================
 *                   The Apache Software License, Version 1.1
 * ============================================================================
 * 
 *    Copyright (C) 2000-2003 The Apache Software Foundation. All
 *    rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without modifica-
 * tion, are permitted provided that the following conditions are met:
 * 
 * 1. Redistributions of  source code must  retain the above copyright  notice,
 *    this list of conditions and the following disclaimer.
 * 
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 *    this list of conditions and the following disclaimer in the documentation
 *    and/or other materials provided with the distribution.
 * 
 * 3. The end-user documentation included with the redistribution, if any, must
 *    include  the following  acknowledgment:  "This product includes  software
 *    developed  by the  Apache Software Foundation  (http://www.apache.org/(...))."
 *    Alternately, this  acknowledgment may  appear in the software itself,  if
 *    and wherever such third-party acknowledgments normally appear.
 * 
 * 4. The names "Ant" and  "Apache Software Foundation"  must not be used to
 *    endorse  or promote  products derived  from this  software without  prior
 *    written permission. For written permission, please contact
 *    apache@apache.org.
 * 
 * 5. Products  derived from this software may not  be called "Apache", nor may
 *    "Apache" appear  in their name,  without prior written permission  of the
 *    Apache Software Foundation.
 * 
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
 * FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
 * APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
 * INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
 * DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
 * OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
 * ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
 * (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 * 
 * This software  consists of voluntary contributions made  by many individuals
 * on behalf of the  Apache Software Foundation.  For more  information  on the 
 * Apache Software Foundation, please see <http://www.apache.org/>.(...)
 *
 */
      Il s'agit donc d'une licence libre et peu contraignante. Elle a aussi l'avantage d'etre facile à comprendre. En espérant t'avoir apporté un éclairage sur la licence Apache :-)

      • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

        Posté par  . Évalué à 1.

        On s'écarte un peu, mais passons. Cette license ne semble pas spécifier que la distribution sous forme binaire implique la mise à disposition des sources. Là, l'incompatibilité avec la GPL serait évidente. Mais peut-être ai-je manqué quelquechose ?

        • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

          Posté par  . Évalué à 1.

          Effectivement, la licence Apache n'impose pas la redistribution des sources, chose qui est au coeur de la GPL. Pour autant, ce n'est pas le motif de la soit-disant incompatibilité avec la GPL. En effet, la discorde porte sur la clause de publicité. La licence BSD (modifiée) qui équivaut à la licence Apache avec les 3 premiers points n'est pas considérée comme incompatible. Pourtant elle n'impose pas une redistribution des sources.

          Dans les faits, quelqu'un (individu, groupe, entreprise) qui réalise un travail dérivé d'un logiciel placé sous une licence libre non copyleft (BSD, Apache, MIT, ...) aura intéret à publier en retour le maximum de modifications. Pas pour des raisons philosophiques, mais pratiques. Quand la version d'origine monte en version, faire évoluer un travail dérivé en appliquant les mises à jour de la version d'origine est difficile (création de patchs par forcément simples, nécessité de faire des tests d'intégrations). Parfois ça peut aller jusqu'à obliger à ne plus intégrer les évolutions de la version de base. En faisant intégrer dans le logiciel d'origine les modifications "d'intéret général", ça devient nettement plus simple.

    • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

      Posté par  . Évalué à 2.

      Des gouts et des licenses ne se discutent pas :-)

      Note qu'avec la license Apache, au moins ce genre de confusion sur l'utilisation dans les produits dérivés ne se posent pas..

      En plus, si tu veux developper un outil avec la license BSD qui utilise une librairie LGPL, tu est obligé d'utiliser l'édition de lien dynamique pas l'edition de lien statique..

      • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

        Posté par  . Évalué à 1.

        Salut,
        J'ai developpé une appli Java qui utilise JAMA (domaine publique).
        http://www.emse.fr/~mmorge/software/JAHP.html(...)
        Quelle licence choisir (LGPL/GPL/Apache truc bidule) ?

        MM.

        • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

          Posté par  . Évalué à 1.

          Si ça peut t'apporter des éléments de réflexion, voici une entrée de mon blog : http://home.izforge.com/index.php?p=5&c=1(...) .

          La licence Apache pour du Java ça peut etre une bonne stratégie, grace à la clause de pub. Pour un logiciel proprio qui se baserait sur ton code, devoir indiquer "ce logiciel est basé sur xxx développé par trucmuche, un logiciel qui fait yyy, dispo sur http://plopdaplop.com(...)", c'est moins attrayant ... Vu que tu choisis le texte de la clause de pub, ça peut etre dissausif dans certains cas. En revanche vis-à-vis de logiciels libres/open, ça ne pose pas de problème.

          • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

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

            J'ai pas l'impression que les clauses de pub arrêtent qui que ce soit. Pour preuve, la boîte « À propos » d'Internet Explorer annonce sans complexe qu'il est « basé sur NCSA Mosaic. NCSA Mosaic(TM) a été développé par le National Center for Supercomputing Applications à l'Université de l'Illinois à Urbana-Champaign ». Il me semble aussi qu'il y a des versions proprios d'Apache lui-même (Covalent [http://covalent.com/products/server_solutions.html(...)] me vient à l'esprit, mais je ne sais pas s'ils redistribuent leurs modifs. Si tu as plus d'infos...). Les licences de type copyleft sont plus efficaces (à mon humble avis) pour ce qui est d'assurer que le développeur ne se fasse pas entuber pour avoir voulu être trop génereux.

            Envoyé depuis mon PDP 11/70

            • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

              Posté par  . Évalué à 4.

              Disons que le choix d'une licence libre copyleft ou non dépend fortemment du contexte ...

              Je déplore que beaucoup de développeurs choisissent la GPL par défaut, sans l'avoir comprise. Le GPL-quizz est un très bon révélateur. Meme quand tu lis des commentaires sur un site comme celui-ci, tu te rend compte que beaucoup de gens sortent malgré eux des énormités. Par exemple j'en ai vu un l'autre jour qui disait que la licence MIT n'était pas libre. On voit également souvent l'amalgame libre == GPL, pas GPL == pas libre, ce qui est bien entendu absolument faux. La FSF n'a pas (et n'a pas à l'avoir) le monopole du logiciel libre. Ils ont leur vision, mais d'autres comme la Apache Software Foundation ont une vision différente qui a tout autant sa place.

              Le choix d'une licence doit etre un choix stratégique, autrement dit un choix réfléchi et non pas fait par défaut. Il faut tenir compte de ce qui est développé, de son contexte d'utilisation, de ce que l'on veut permettre ou non avec, ... bref c'est très variable.

              Par exemple si je développe un module permettant de lire dans une archive Zip et que je le place sous licence GPL ou LGPL, c'est un peu excessif à mon gout. Il n'y a rien de faramineux là-dedans. En revanche si je m'appelle Mr Trolltech et que je fais Qt, la stratégie de licences GPL/proprio est non seulement logique, mais c'est aussi un coup de maitre. Si je m'appelle Mr Opera et que je fais un navigateur, ma source de revenu qui me permet de vivre est de vendre des licences. Sachant que toute licence libre ou ouverte ammène à une possibilité d'obtention d'une copie à cout réduit .... bye bye ce type de licence ... Si je développe une application dans un domaine convoité où des gens peu scrupuleux peuvent "profiter" (dans le mauvais sens du terme) de mon travail, alors le copyleft peut etre mon arme, meme si on constate à l'occasion des violations de la GPL (et encore, il doit y en avoir un paquet qui ne se verront jamais, ne serait-ce que dans le cadre de développements sur mesure ...).

              Tout ceci pour illustrer que la diversité des tactiques que l'on peut employer. Bref, il faut étudier au cas par cas si le copyleft apporte de la valeur ou si au contraire il en enlève. Et je crois qu'il n'y a pas de règle générale :-)

              • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

                Posté par  . Évalué à 1.

                « Je déplore que beaucoup de développeurs choisissent la GPL par défaut, sans l'avoir comprise. »

                Quitte à ne pas comprendre une licence dans les premiers temps, autant que ce soit celle-là qu'on ait choisie. Si après quelques temps le développeur ne veut pas maintenir le copyleft, il peut passer à une autre licence, voire relicencier les anciennes versions en non-copyleft si ça présente un intérêt. Par contre, celui qui serait parti sur du non copyleft et qui souhaite y passer ne peut le faire que pour les versions suivantes, et ne pourra pas rendre copyleft ce qu'il avait mis en non-copyleft par ignorance.

                « On voit également souvent l'amalgame libre == GPL, pas GPL == pas libre, ce qui est bien entendu absolument faux. La FSF n'a pas (et n'a pas à l'avoir) le monopole du logiciel libre. Ils ont leur vision, mais d'autres comme la Apache Software Foundation ont une vision différente qui a tout autant sa place. »

                Mais toi aussi tu dis une énormité : tu fais comme si « GPL == libre » était le point de vue de la FSF. C'est faux et ils sont clairs là dessus. Il y a des gens qui font la confusion (en fait ils confondent copyleft et libre), mais ils n'ont rien à voir avec la FSF et ça ne correspond pas du tout au discours de la FSF.

                • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

                  Posté par  . Évalué à 1.

                  "Quitte à ne pas comprendre une licence dans les premiers temps, autant que ce soit celle-là qu'on ait choisie."

                  Choisir une licence sans l'avoir comprise me semble un peu léger. Je ne signe pas un contrat sans en comprendre les conséquences :-)

                  "Mais toi aussi tu dis une énormité : tu fais comme si « GPL == libre » était le point de vue de la FSF. C'est faux et ils sont clairs là dessus. Il y a des gens qui font la confusion (en fait ils confondent copyleft et libre), mais ils n'ont rien à voir avec la FSF et ça ne correspond pas du tout au discours de la FSF. "

                  Relis ce que j'ai dit, je parle moi aussi des gens qui font cette confusion et qui estime que la FSF est la référence en matière de libre :-)

                  • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

                    Posté par  . Évalué à 0.

                    « Choisir une licence sans l'avoir comprise me semble un peu léger. Je ne signe pas un contrat sans en comprendre les conséquences :-) »

                    Ben on s'en fout que ce soit léger, parce que c'est ce qui se passe en général. Il n'y a pas de mal à ne pas avoir compris toutes les subtilités et conséquences de la GPL après seulement quelques lectures. Évidemment le cas idéal c'est que tout le monde comprenne parfaitement les licences utilisées. Mais c'est utopique, il ne faut pas trop y compter, donc il vaut mieux faire le choix le plus prudent, ayant le moins de conséquences si on veut changer de licence par la suite.

                    « Relis ce que j'ai dit, je parle moi aussi des gens qui font cette confusion et qui estime que la FSF est la référence en matière de libre :-) »

                    J'ai bien lu avant de répondre justement. Dans ta phrase « Ils ont leur vision... » le « ils » désigne bien la FSF, tu compares à la fondation Apache ensuite. Or on peut très bien considérer la FSF comme une référence puisqu'ils ne dénigrent pas les autres courants du libre, ils expliquent clairement en quoi ils diffèrent. Ils recommandent la GPL mais le chapitre « licence libre » est bien plus vaste... Si les gens qui font la confusion prenaient la FSF comme référence, eh bien ils ne feraient pas de confusions justement ! ;)

                • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

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

                  Quitte à ne pas comprendre une licence dans les premiers temps, autant que ce soit celle-là qu'on ait choisie. Si après quelques temps le développeur ne veut pas maintenir le copyleft, il peut passer à une autre licence, voire relicencier les anciennes versions en non-copyleft si ça présente un intérêt. Par contre, celui qui serait parti sur du non copyleft et qui souhaite y passer ne peut le faire que pour les versions suivantes, et ne pourra pas rendre copyleft ce qu'il avait mis en non-copyleft par ignorance.

                  Moi je dirai plutôt le contraire ... Si je ne sais pas quelle licence choisir, je commencerai par une non-copyleft, car ainsi je reste le seul développeur et j'ai le droit de changer la licence pour une copyleft par la suite. Tandis que si je publie d'abord en copyleft, d'autres personnes vont travailler sur mon code, et je ne pourrais pas repasser l'application modifiée en non-copyleft car il faudrait l'accord de tout les développeurs, la seule version qui pourrait passer en non-copyleft est ma version de base ...

                  Enfin, personnellement je ne me poserais pas la question et je publierais plutôt en copyleft, mais dans le cas d'une personne qui ne saurait pas quoi faire, j'utiliserais plutôt mon raisonnement que le tiens. Qu'en pensez-vous ?

                  • [^] # Re: La LGPL s'applique à Java exactement comme pour C/C++

                    Posté par  . Évalué à 1.

                    Dans ce que je disais, c'est vrai que ce n'était valable qu'avec un seul développeur... Je garde mon point de vue tant que l'auteur est seul développeur. Avec plusieurs auteurs, effectivement ton approche semble plus prudente... mais s'il y a plusieurs auteurs, ça commence à devenir urgent de bien comprendre les licences et de se décider définitivement !

Suivre le flux des commentaires

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