Articles précédents : Développeur
- [102] Un Clone de MultiDeskOS en opensource
- [13] Résumé GNOME 18.07.2003
- [45] Qt GPL pour DirectFB en version pre-alpha
- [62] Nouvelle beta Red Hat Linux
- [7] JOFFAD 1.0 est disponible
- [40] GPS 1.2.2 : GNAT Programming System est dispo
- [10] Sistina announce Sistina GFS 5.2
- [61] Le dernier Linux 2.5 est sorti
- [211] Résumé GNOME 06.07.2003
- [42] QSA 1.0 est disponible
Liens connexes
- Le courriel sur mane.comp.jakarta.poi.devel (409 hits)
- Le texte de la LGPL (365 hits)
- Du choix de sa licence GNU (383 hits)
- Le troll sur /. (600 hits)
Dépêche modérée par
Développeur : La LGPL s'applique à Java exactement comme pour C/C++
Posté par Anthony (). Modéré le 23 juillet 2003.
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).
![[en]](../../../images/en.png)
Le courriel sur mane.comp.jakarta.poi.devel (409 hits)-
Le texte de la LGPL (365 hits)
-
Du choix de sa licence GNU (383 hits)
-
Le troll sur /. (600 hits)
> Lire la dépêche (45 commentaires, moyenne: 1,9).
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é.
2ème lien
le texte de la LGPL
xmpp:ofaurax@jabber.fr
Re: La LGPL s'applique à Java exactement comme pour C/C++
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 Anthony () le 23/07/2003 à 17:34. (lien). Évalué à 2.C'etait en effet une remarque capitale :)
desole, mais travaillant aux US, j'ai un peu perdu de vue la nomenclature francaise .... et les accents.-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par Guillaume Leclanche (page perso, ) le 23/07/2003 à 18:18. (lien). Évalué à 2.Le problème, c'est pas tellement que tu te sois trompé (ça peut arriver à tout le monde), mais c'est que le modérateur n'ait pas corrigé avant de valider (là, en revanche, c'est son travail!).
-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par Nÿco (Jabber id, page perso, ) le 23/07/2003 à 18:29. (lien). Évalué à 1.OK, c'est corrigé.
Maintenant, il reste ça :
> C'est à dire qu'un import java est équivalent au link en C (la liaison dans java est entièrement au runtime, pour ceux qui n'auraient pas remarqué) .
Vous avez des propositions pour link (liaison ?) et runtime ? Y'a copyright aussi un peu plus loin...--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par MrTout (page perso, ) le 23/07/2003 à 18:41. (lien). Évalué à 5.Je propose :
C'est à dire qu'un « import » java est équivalent à une édition de lien en C (la liaison en java est entièrement réalisée à l'exécution, pour ceux qui n'auraient pas remarqué).
-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par Rolland Dudemaine () le 23/07/2003 à 18:41. (lien). Évalué à 2.link -> edition de liens
au runtime -> a l'execution
-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par dvrasp (page perso, ) le 24/07/2003 à 08:34. (lien). Évalué à 2.Faut pas exagérer.
Il y a des termes techniques qui traduits en français ne sont plus clairs.
<< Link >> ne devrait pas être traduit, au même titre que << import >>, parce que ça fait référence à un processus bien précis que l'on a l'habitude de nommer comme ça. (Et ce sont des mots que l'on reconnît rapidement si l'on lit la dépêche en diagonale.)
Bon, << runtime >> est plus discutable.-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
-
-
-
-
-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par gnap gnap (page perso, ) le 23/07/2003 à 17:44. (lien). Évalué à 1.Il s'agit en fait d'une « libraire LGPL ». Sympa la demoiselle.
Re: La LGPL s'applique à Java exactement comme pour C/C++
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 Francois Revol (page perso, ) le 23/07/2003 à 20:28. (lien). É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 Anthony () le 23/07/2003 à 21:31. (lien). É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++
-
-
-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par Richard Van Den Boom () le 24/07/2003 à 05:38. (lien). É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
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 Snark_Boojum () le 23/07/2003 à 20:16. (lien). É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
-
-
[^]Re: Si j'ai bien compris
Posté par Anthony () le 23/07/2003 à 21:33. (lien). É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
-
[^]Re: Si j'ai bien compris
Posté par Nelis (page perso, ) le 24/07/2003 à 08:07. (lien). É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 ?--
Vache qui rit, à moitié dans son lit-
[^]Re: Si j'ai bien compris
Posté par Anthony () le 24/07/2003 à 14:26. (lien). É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
[+] puisqu'on est dans les trolls
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 Gabriel Santonja () le 23/07/2003 à 20:43. (lien). É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
-
[^]Re: puisqu'on est dans les trolls
Posté par Strass (page perso, ) le 24/07/2003 à 07:59. (lien). É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 HappyPeng () le 27/07/2003 à 20:01. (lien). É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++
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 JPz (page perso, ) le 24/07/2003 à 08:05. (lien). É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 dvrasp (page perso, ) le 24/07/2003 à 08:44. (lien). É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 JPz (page perso, ) le 24/07/2003 à 09:08. (lien). É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 reno () le 24/07/2003 à 08:56. (lien). É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 morge () le 24/07/2003 à 09:07. (lien). É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 JPz (page perso, ) le 24/07/2003 à 09:14. (lien). É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 William Steve Applegate (page perso, ) le 24/07/2003 à 12:47. (lien). É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.
--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par JPz (page perso, ) le 24/07/2003 à 13:56. (lien). É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 #3588 () le 24/07/2003 à 17:55. (lien). É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 JPz (page perso, ) le 25/07/2003 à 07:16. (lien). É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 #3588 () le 25/07/2003 à 08:09. (lien). É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 Nelis (page perso, ) le 25/07/2003 à 08:08. (lien). É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 ?--
Vache qui rit, à moitié dans son lit-
[^]Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par #3588 () le 27/07/2003 à 21:19. (lien). É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 !
-
-
-
-
-
-
-
Cette page a été générée par Templeet en 0.1597s (dont 0.0171 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.