L'utilisation de la licence GPL/LGPL/AGPL serait en déclin relatif par rapport aux autres licences libres (MIT, BSD, Apache, etc.). Le 451 CAOS Theory blog (du 451 Group) en a fait le constat via un article de Matthew Aslett « On the continuing decline of the GPL » (Sur le déclin continu de la GPL). Cet article est illustré par un graphe simple, en seconde partie de cette dépêche.
En résumé, la « famille » GPL serait passée relativement de 70 % à 50 % en proportion (par une croissance absolue de 15 % alors que le logiciel libre en général aurait progressé de 117 %).
Attention, ce ne sont que des chiffres, donc à prendre avec des pincettes. Il faut analyser et challenger les méthodes de collecte avant d'expliquer et d'en tirer des conclusions trop hâtives. Une lecture attentive de cet article et le suivi des liens permet effectivement de relativiser.
Les chiffres !
L'article s'appuie sur une étude de Black Duck Software, tout en critiquant ouvertement la non-transparence de la méthode d'acquisition de ces données. Des données supplémentaires (et corrélées) ont par ailleurs été obtenus via FLOSSmole (sources Rubyforge, Freshmeat, ObjectWeb et FSF). Le résultat pour les données Black Duck est le graphe qui montre qu'entre octobre 2008 et décembre 2011 (avec une projection jusqu'à septembre 2012), la « famille » GPL est passée relativement de 70 à 50 % de « parts de marché ». Cela suit la courbe de la GPLv2 (60 à 40 %). La variation est effectivement inquiétante, mais le taux reste très élevé.
En outre, ce graphe montre qu'entre janvier 2009 et décembre 2011 (avec une projection jusqu'à septembre 2012), les licences « permissives » que sont les MIT, Apache, BSD et Ms-Pl passent de 15 à 30 %.
Ce qui est précisé dans une mise à jour de l'article — qui est un facteur majeur — c'est que pour la période située entre janvier 2009 et décembre 2011, le volume global de la famille GPL croit de 15 % et les licences permissives de 117 %, ce qui représente globalement un accroissement de 31 %. Donc tout le logiciel libre progresse en volume.
Les « explications »
Les chiffres montrent tout de même clairement que l'on a un déplacement graduel de l'usage de la licence copyleft vers des licences permissives. Cela montre également une constante : la domination très nette de la famille GPL.
Dans un article d'ITworld titré « GPL, copyleft use declining faster than ever », l'auteur Brian Proffitt analyse le premier article.
Une des explications serait que les entreprises éditrices de logiciels libres seraient plus amenées à choisir des licences permissives afin de présenter une approche moins contrôlée face à leurs communautés. On passerait donc d'un modèle de communauté basée sur une licence, à un modèle basé sur une gouvernance et/ou des processus orientés communauté. Ce ne serait donc pas un mouvement de sortie des communautés de la famille GPL vers les licences permissives.
Les données ne vont pas assez loin dans le passé, mais il y aurait un pic de l'usage de la GPL en 2007. Cette chute de la GPL serait due au passage à la GPLv3. On assisterait donc une plus nette distinction entre logiciel libre et open source. Cette explication peut paraître fantaisiste, mais à prendre en considération, tout de même.
Le magazine 01informatique évoquait une autre explication fin 2009 lorsque déjà on parlait de déclin des *GPL: « Contrairement aux idées reçues, ce dédain des développeurs n'est pas dû à la version 3.0. (...) Mais les développeurs semblent préférer de plus en plus se tourner vers des licences moins restrictives comme BSD et Apache. »
Dans l'article initial du 451 group, un autre article écrit en deux parties par Bruce Byfield est pointé « 7 Reasons Why Free Software Is Losing Influence » (partie 1, partie 2), plus sensationnaliste, en guise de tentative d'explication. En gros, cela analyse le déclin du logiciel libre, et ce serait dû à plusieurs facteurs, plus ou moins argumentés :
- 1. Too Many Causes, Too Few Resources
- 2. Failing to Find New Supporters While Neglecting the Old
- 3. The Replacement of Debian with Ubuntu
- 4. Failure to Address New Technologies
- 5. The GPL Version Split
- 6. Not Attending Conferences
- 7. Richard Stallman's Gaffs
Dans un second article d'ITworld (« Evaluating the state of the GPL »), Brian Proffitt envisage d'autres pistes. Il est en effet possible que ce soit plus le mouvement vers les applications qui soit la cause, les AppStore étant hostiles au copyleft.
Slashdot, pointant un article de The Register, dit que l'open source est de plus en plus remplacé par des API « ouvertes » ( « Open Source Increasingly Replaced By Open APIs »)
Et vous ?
Constatez-vous également une tendance durable sur ces dernières années ?
Adhérez-vous à ces analyses et tentatives d'explications ?
# MIT
Posté par rewind (Mastodon) . Évalué à 7.
J'ai constaté que la licence MIT est de plus en plus utilisée, surtout dans la communauté Ruby. J'ai jamais trop compris pourquoi cet engouement pour cette licence ultra-permissive (puisque même le changement de licence est autorisé), mais je pense que RoR a ouvert la voix et a créé une mode pour cette licence.
[^] # Re: MIT
Posté par Antoine . Évalué à 3. Dernière modification le 07 janvier 2012 à 01:21.
Les licences non-copyleft sont également très utilisées dans la communauté Python (et pour Python lui-même, évidemment).
Je pense par ailleurs que la GPLv3 a franchi un seuil de complexité qui la rend rébarbative (ce que n'était pas la GPLv2). Je suis personnellement pro-copyleft, mais franchement la GPLv3 ne me donne pas trop envie de l'utiliser.
Addendum : un autre facteur est la perte de prééminence de la FSF, qui apparaît peut-être moins fiable qu'on ne le pensait, Stallman lui-même commençant à sembler un peu largué.
[^] # Re: MIT
Posté par claudex . Évalué à 4.
Rien ne t'empêche de toujours utiliser la GPL 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MIT
Posté par Antoine . Évalué à 1.
Sauf qu'un des espoirs en utilisant la GPLv2 c'était que la FSF fasse la maintenance correctement et améliore la licence dans les versions suivantes, d'où le « GPLv2 or later » adopté par la plupart des projets. Cet espoir a été déçu, je pense, du point de vue d'un certain nombre de personnes.
[^] # Re: MIT
Posté par Zenitram (site web personnel) . Évalué à 10.
Ce fut le cas (internationalisation car on est plus international aujourd'hui et anti-tivoïsation qui est complètement dans l'esprit de la FSF que de pouvoir utiliser son logiciel modifié avec son matériel).
En quoi sont-ils déçu? Ils n'ont absolument pas renié leur convictions, qu'est-ce qui est illogique par rapport à leur positionnement?
la FSF a complètement fait son boulot sur la maintenance de la GPL, après que ça ne plaise pas aux gens qui voudraient imposer une version logicielle sur un matériel précis, ben... C'est juste qu'il ne sont pas dans la philosophie de la FSF, et devraient chercher une autre licence (ou ne pas mettre "or later").
Bref, n'est-ce pas plutôt eux qui se sont trompé de licence que la FSF qui n'a pas fait son boulot?
[^] # Re: MIT
Posté par Antoine . Évalué à 0.
Je répète : GPLv3 beaucoup trop complexe et illisible.
[^] # Re: MIT
Posté par Zenitram (site web personnel) . Évalué à 0.
Si tu as plus simple pour faire la même chose, n'hésite pas à partager ta science.
Et quitte à me répéter aussi : v2 ou v3, pareil : complexe et incompréhensible (pour un non juriste) dans les deux cas.
C'est une fausse excuse pour la déception. A ce rythme, on peut dire que comme une virgule a été rajoutée, c'est devenu trop compliqué donc ça ne va pas.
PS : j'utilise la LGPLv3, et ben... Elle est bien plus simple! regarde la différence de nombre de caractère entre les deux. ça simplifie bien plus que complexifie, même si du coup il faut un petit paragraphe en plus dans la GPLv3. Donc bon, c'est vraiment un truc bien subjectif...
[^] # Re: MIT
Posté par Antoine . Évalué à 2.
Bonjour, M. le Fin Psychologue. J'ai peur de vous prendre en flagrant délit d'exercice illégal (sans oublier incompétent :-)) de la médecine.
Ou bien : à ce rythme, on tombe dans les arguments fallacieux habituels de Zenitram.
Je veux bien le croire, mais on parlait ici de la GPL.
Par ailleurs, si comme tu le dis la LGPLv3 se base maintenant sur la GPLv3, il faut considérer les deux pour en tirer quoi que ce soit sur la simplicité de la LGPLv3 (puisque tu ne peux pas la comprendre sans comprendre la GPLv3).
[^] # Re: MIT
Posté par Zenitram (site web personnel) . Évalué à 3.
Les deux sont illisibles. La différence est principalement internationalisation + TiVo, c'est tout ce qu'il y a à savoir, après tu colles la licence et zou.
Je ne donc pas trop pourquoi tu n'aurais pas envie d'utiliser la v3 par rapport à la v2 avec la complexité en argument, à moins que tu me dises que la v2 est non complexe (mais la, franchement, j'ai un doute...)
[^] # Re: MIT
Posté par Antoine . Évalué à 3.
La GPLv2 est assez lisible de mon point de vue. Pas simplissime, certes, mais franchement compréhensible.
[^] # Re: MIT
Posté par patrick_g (site web personnel) . Évalué à 7.
Ou pas : http://www.framablog.org/index.php/post/2012/01/04/stallman-avait-raison
[^] # Re: MIT
Posté par Antoine . Évalué à 6.
Disons qu'il n'avait pas raison sur les licences libres appliquées à autre chose que le logiciel, et que la GFDL est un naufrage, si tu veux un exemple.
Il n'avait pas non plus raison sur les restrictions imposées à gcc (d'où montée en puissance de LLVM), si tu veux un autre exemple.
Stallman avait raison quand il a lancé la GPL, le projet GNU et la définition du libre ; depuis, son apport n'a pas été franchement positif. L'article fait référence à ces contributions originelles, pas à une quelconque novation récente de Stallman.
[^] # Re: MIT
Posté par gasche . Évalué à 6.
Je ne comprends pas trop ta position. La Gplv3 traite plus de choses (Tivoization, brevets logiciels...) donc est plus longue, par contre je trouve que le texte est au contraire plus clair. Elle me semble plus lisible que la GPLv2.
Il y a un point que l'on pourrait qualifier de "complexe", qui est le fait que la GPLv3 prévoit son "extensibilité", elle parle de comment on peut ajouter par dessus la GPLv3 des autorisations supplémentaires pour la rendre plus permissive. C'est une partie de la licence qui n'est pas très longue mais un peu abstraite, et donc un peu plus complexe. Pour moi cela correspond à un travail de factorisation, et ma fibre de programmeur me fait apprécier l'initiative. En particulier, la licence LGPL3, du coup, est beaucoup plus courte que la précédente, puisqu'elle est présentée comme un diff par dessus la GPL3.
# Complexité
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
La GPL est trop longue à lire et difficile à comprendre.
A côté BSD et MIT sont des modèles de simplicité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Complexité
Posté par Sébastien Wilmet . Évalué à 5. Dernière modification le 07 janvier 2012 à 13:05.
La GPL est plus complexe, ça c'est certain. Mais est-ce vraiment grave du point de vue des développeurs ? Les licences, ça fait partie du domaine des juristes, c'est normal si un programmeur ne comprend pas tout ou trouve ça barbant à lire. Chacun son métier, après tout.
Personnellement, je n'ai lu ni la GPLv2 ni la v3, par contre je connais les principes généraux (copyleft, tivoïsation pour la v3, etc) auxquels j'adhère. Ensuite je fais confiance à la FSF pour que la licence soit juridiquement correcte. De toute façon je n'ai pas les connaissances nécessaires pour vérifier qu'elle est correcte, alors à quoi bon lire un truc que je comprendrai même pas ?
Quand vous installez un nouveau logiciel libre, vous lisez tout le code source pour vérifier que ça fait bien ce que vous voulez que le logiciel fasse ? Non, vous lisez la liste des fonctionnalités disponibles, et faites confiance aux développeurs pour avoir implémenté ça correctement.
[^] # Re: Complexité
Posté par Antoine . Évalué à 4.
Hein ? Non ce n'est pas normal du tout. Comment peux-tu faire confiance à la licence si tu ne comprends pas ce qu'elle raconte ? Quand tu mets une oeuvre sous GPL, c'est ton travail qui est en jeu.
Et c'est une très mauvaise idée. Je te conseille fortement de lire toutes les licences que tu utilises pour tes logiciels. Et si d'aventure l'une d'entre elles est vraiment trop compliquée, c'est peut-être un indice qu'il vaut mieux éviter de l'utiliser.
[^] # Re: Complexité
Posté par rewind (Mastodon) . Évalué à 3.
Est-ce que tu sais comment marche ta voiture ? Parce que sinon, c'est peut-être un indice pour que tu ne l'utilises pas... Obscurantisme toussa...
[^] # Re: Complexité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Le fabricant, lui, il le sait, et il a bien fait attention.
Si je fais mon code avec une licence au hasard, que des gens participent, puis qu'en cours de route, je m'aperçois que la licence n'est pas bonne, il est possible que je ne puisse plus en changer à cause du code tiers que j'ai accepté.
C'est un problème avec les licences, comme la GPL, qu'on ne peut pas relaxer.
[^] # Re: Complexité
Posté par Zenitram (site web personnel) . Évalué à -2.
Oui, c'est un problème avec la GPL. v2 ou v3, pareil, c'est un jeu de juriste. Et?
Car ce n'est pas de ça dont on parle, mais de la prétendue complexité de la v3 par rapport à la v2. Et la, par contre, on voit beaucoup moins le problème en plus apporté par la v3.
[^] # Re: Complexité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
J'ai pas l'impression qu'on compare la v2 à la v3 dans ce fil, non, pas du tout.
Je crois que ce dont on parle, c'est simplement la complexité de la GPL d'une manière générale, et du fait qu'il est fort peu judicieux de la choisir si on n'est pas bien au fait de tous ces détails de juriste (comparé à une BSD ou MIT), justement.
[^] # Re: Complexité
Posté par Zenitram (site web personnel) . Évalué à -1.
Argh... Ca m'apprendra à suivre deux fils en même temps.
Toutes mes excuses, ici on parle bien de la GPL, toute versions confondue, donc mon commentaire était HS de chez HS.
[^] # Re: Complexité
Posté par Antoine . Évalué à 1.
À quoi sert selon toi la liberté d'étudier le code source dans le logiciel libre ?
Ce serait intéressant de traiter RMS d'obscurantiste parce qu'il refuse d'utiliser du logiciel propriétaire, tiens :-)
[^] # Re: Complexité
Posté par rewind (Mastodon) . Évalué à 2.
Tu réponds à côté de la plaque. On parle de licence, pas de code source. Et si on prend le code source, tout le monde n'est pas ingénieur informaticien et n'est pas apte à comprendre un code source. Et si tu me dis qu'on peut engager un ingénieur, et bien tu peux engager un juriste pour comprendre la licence (puisque son texte est accessible).
Ce n'est pas RMS que je traite d'obscurantiste, c'est toi. Parce que tu refuses d'utiliser qqch que tu ne comprends pas. On dirait un cureton du Moyen-Âge qui brûlait tout ce qu'il ne comprenait pas en le traitant de sorcellerie. RMS, il refuse le propriétaire pour des raisons philosophiques et politiques un peu plus profondes.
[^] # Re: Complexité
Posté par Zenitram (site web personnel) . Évalué à 1.
Pas du tout : il démontre exactement le contraire de ce qu'il pense, plutôt!
Le code source est incompréhensible par un être humain normal, mais on demande que ce soit libre et on fait confiance (sans aucune garantie). Si on veut comprendre, on embauche un informaticien.
La licence est incompréhensible par un être humain normal, mais on demande que ce soit libre et on fait confiance (sans aucune garantie). Si on veut comprendre, on embauche un juriste.
Donc la complexité de la licence n'est pas un problème (sinon il ne faut pas utiliser Linux, qui peut comprendre tout le code de Linux en entier? Linux est trop compliqué à comprendre, donc...).
CQFD.
[^] # Re: Complexité
Posté par Antoine . Évalué à 0.
Non. Les textes juridiques sont censés être compréhensibles par les gens auxquels ils s'adressent.
En réalité c'est toi qui as une attitude bigote, puisque tu refuses la critique (par d'autres que toi !) d'un texte que tu ne cherches même pas à comprendre par toi-même. Et lorsqu'on expose des doutes à propos de ce texte, tu réagis par les insultes.
Le désir de comprendre n'a jamais été obscurantiste, c'est au contraire un des antidotes les plus puissants qui soient. Mais certains préfèrent le confort du suivisme et de la confiance aveugle donnée à un dogme ou une autorité constituée.
[^] # Re: Complexité
Posté par Zenitram (site web personnel) . Évalué à 1.
Pas de problème : tu peux faire des études juridiques. Comme pour des études informatiques. Pourquoi accepter l'un et pas l'autre? Pourquoi accepter du code sur ta machine que tu ne comprend pas?
Non : certains te disent que tu n'as aucune cohérence dans tes propos, et que tu bloques sur un truc bien ridicule vu que tu ne bloques pas sur d'autres choses du même acabit.
C'est juste une connerie de bloquer sur une licence parce que "trop compliquée" pour toi, ce n'est pas de l'obscurantisme car la licence est lisible, avec plein d'explications sur le net. Comme du code en fait.
[^] # Re: Complexité
Posté par Sébastien Wilmet . Évalué à 2.
Bon exemple. Une autre analogie, en programmation orientée objet : la différence entre une interface et une classe (l'implémentation).
Le texte complet de la licence, c'est la classe. Ce qu'on peut lire par exemple sur wikipédia ou autre à propos d'une licence, c'est l'interface. Et de mon point de vue, comprendre l'interface d'une licence suffit, c'est-à-dire comprendre les principes généraux, et les points importants à savoir en tant que développeur.
Il faut voir ça aussi du point de vue des juristes : on a envie que notre licence fasse « ça » et « ça ». À nous maintenant d'implémenter ça comme il faut dans un texte juridique. Comprendre les intentions de départ des juristes (l'interface) suffit donc pour comprendre la licence.
[^] # Re: Complexité
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
L'analogie avec la voiture, ce serait plutôt: est-ce que je dois lire le manuel pour allumer les phares?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Complexité
Posté par Zenitram (site web personnel) . Évalué à 2.
Quand je prend le volant d'une voiture/train/avion/métro/bus, c'est ma vie qui est en jeu.
Comment peux-tu faire confiance à une voiture/train/avion/métro/bus si tu ne comprends pas comment elle fonctionne ?
Je vais répondre à ma question : je fais confiance au constructeur et/ou conducteur (des fois ça a des problèmes, je sais, mais globalement ça va pas mal quand même) comme je fais confiance à la FSF à ce sujet pour faire le mieux possible.
Je sais pas comment tu peux vivre sans jamais faire confiance à ce que tu ne comprend pas, de nos jours... Dans un grotte à la bougie? Parce que dès que tu sors de ça, pour tout comprendre dans ce que tu utilises, du dois en mettre du temps!
Donc non : c'est seulement que ce n'est pas évident de dire autre chose que "faites ce que vous voulez". Encore une fois, si tu as un texte de 3 lignes pour interdire la Tivoïsation, dépêche toi d'apporter ta superbe science.
[^] # Re: Complexité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Il n'est pas responsable des défauts du véhicule.
C'est le point qu'il défend, je crois.
[^] # Re: Complexité
Posté par Antoine . Évalué à 2.
Tout à fait. L'exemple typique c'est les licences Creative Commons non-commerciales (certes non libres, mais ce n'est pas l'élément important ici). Des tas de gens ont eu des interprétations divergentes de la clause non-commerciale. Eh bien, si jamais ils se retrouvent avec des problèmes (juridiques) à cause d'une interprétation erronée de cette clause extrêmement vague pour le commun des mortels, ils l'ont dans le baba : ce n'est pas Creative Commons qui est responsable des dommages occasionnés.
[^] # Re: Complexité
Posté par gasche . Évalué à 4.
La GPLv3 est longue, certes, mais je ne la trouve pas "difficile à comprendre". Je ne dis pas que je comprends toutes les nuances et ce que les avocats vont en conclure, etc., mais quand je lis le texte de la licence je comprends la finalité de chaque paragraphe et je peux décider de si cela me semble acceptable ou non pour mon projet.
As-tu des exemples précis de parties de la licence que tu trouves trop difficiles à comprendre ?
# Exemple de ce soir.
Posté par hocwp (site web personnel) . Évalué à 5.
Tiens ça tombe bien que tu en parles. Je n'ai pas de stats mais j'ai reçu un mail ce soir de quelqu'un intéressé par un de mes programmes (CLFSWM) et qui me demande si je ne peux pas le placer sous une autre licence moins restrictive que la GPL.
Il propose la LLGPL ou mieux, selon lui, justement, une licence de type BSD parce qu'il semble qu'il y ait des problèmes légaux d'utilisation de la GPL avec des implémentations propriétaires de Common Lisp. Il me dit qu'il a des hacks en réserve mais n'a encore envoyé aucun code.
Pour l'instant j'ai lancé une discussion sur la ML mais je pense que c'est caractéristique de ce qui est dit dans la dépêche.
Personnellement je ne suis pas pour ce changement de licence. Je suis très attaché à la GPL et je m'en cogne que mon programme fonctionne ou non sur une implémentation propriétaire. Mais c'est effectivement dommage de perdre un contributeur parce que la licence lui semble trop restrictive. Reste à voir ce qu'en pense les autres contributeurs (et vous ?).
/Fin de la minute perso/ :)
[^] # Re: Exemple de ce soir.
Posté par Damien Thébault . Évalué à 5.
Moi perso quand je fais un bout de code, le but c'est qu'il soit utilisé, que ça soit par un être humain ou un autre programme (qui a été écrit par un être humain, et qui est donc tout simplement un outil).
Du coup la GPL me semble trop restrictive dans le sens où elle empèche un utilisateur d'utiliser mon code à travers son programme (qui peut être sous une autre licence, GPL, propriétaire, moi perso je m'en fout de son code à lui, il fait ce qu'il veut).
Du coup je trouve la LGPLv2 très bien adaptée à mon cas.
Pour rappel le principe c'est qu'on autorise à utiliser mon travail en tant que lib dynamique, du moment que les améliorations à mon code sont reversée ou que mon code n'est pas changé (pour éviter qu'un petit malin ne fasse une évolution d'une lib en ajoutant une API allant directement accéder aux variables internes).
Et perso je suis plutôt LGPLv2(.1) que "LGPLv2 ou supérieur".
Quand c'est un programme c'est un peu différent, je sais pas si la LGPLv2 s'applique mais si il y a un système d'extension ça me dérange pas forcément que ces extensions soit propriétaires (mais j'avoue que c'est plus discutable, j'aimerais bien que ça soit libre puisque ça permet d'avoir un ensemble que tout le monde peut faire évoluer, mais je ne veux pas obliger les utilisateurs à le faire, bah c'est comme un programme sous linux en fait)
[^] # Re: Exemple de ce soir.
Posté par Zenitram (site web personnel) . Évalué à 5.
Pourquoi?
La LGPL n'a absolument rien à voir avec un "type BSD".
La LGPL est juste une version plus "normale" dans le sens où elle protège ton code (copyleft) sans pour autant obliger les autres à prendre la GPL pour leur code externe (qui utilise ton logiciel) ou faire des contorsions techniques (par exemple, quand un logiciel est GPL, on l'adapte pour que la ligne de commande puisse retourner les bonnes infos, c'est plus lent, mais ça marche, alors que ce serait plus correct de passer par un .so/une API, ce que la LPGL autorise. Bref, la GPL est "détournable" dans bien des cas)
Bref, pose-toi la question de savoir si il est pour toi si important d'imposer la GPL aux autres, ou si tu veux juste copylefter ton code. Si la réponse est protéger ton (j'insiste sur ce mot) code sans avoir rien à faire qu'une personne fasse du code proprio pour utiliser ton code (de toutes façons, la GPL ne propose pas beaucoup mieux la dessus, voir plus haut), la LGPL peut mieux répondre aux besoins de tout le monde.
Encore une fois, contrairement à ce que tu penses, la LGPL n'a absolument rien à voir avec la BSD, la LGPL est une licence copyleft très très proche de la GPL. Elle peut te convenir.
[^] # Re: Exemple de ce soir.
Posté par claudex . Évalué à 6.
De ton point de vue.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Exemple de ce soir.
Posté par Zenitram (site web personnel) . Évalué à 2.
Effectivement.
Mon point de vue est que je ne comprend pas cette décision de limite arbitraire : je peux mélanger du GPL et du proprio si je ne fais pas de link statique, pourquoi ne pas être pourfendeur du proprio, vraiment, en interdisant tout proprio avec une distro entière?
La GPL, c'est vraiment bâtard comme truc, et c'est une limite technique artificielle que je n'arrive pas à comprendre. Mais oui, c'est mon point de vue.
[^] # Re: Exemple de ce soir.
Posté par Jean B . Évalué à 5.
Car l'idée à la base est que si un programe proprio utilise une bibliothèque GPL, tu dois tout de même avoir le droit et la possibilité technique de modifier la partie GPL. Ce qui est impossible avec du "link statique".
[^] # Re: Exemple de ce soir.
Posté par Zenitram (site web personnel) . Évalué à 1.
hum... j'ai mis "link statique" mais pas sur qu'on parle de la même chose : je parlais de lier un .so par exemple (pas de faire un seul binaire) plutôt que de passer par un appel de commande.
tu fais un .so sous GPL, le code appelant le .so doit être compatible GPL, alors que ça n'a rien à voir.
Tu fais un .so sous LGPL, le code appelant le .so a la licence qu'elle veut.
la GPL va trop loin (de mon point de vue!) car elle impose des obligations de compatibilité à du code appelant (le code peut être libre mais pas compatible GPL, tu es baisé).
Le problème soulevé n'est pas celui que tu indiques, car ça marche très bien en LGPL. Cet argument est pour le passage en LGPL plutôt.
[^] # Re: Exemple de ce soir.
Posté par hocwp (site web personnel) . Évalué à 2.
Oui évidement. Où est-ce que j'ai dis ça ? Je dis juste qu'il préférerait la (L)LGPL ou une BSD.
Sinon, j'aime la GPL pour le Copyleft : j'en profite en temps qu'utilisateur avec les garanties qu'offre la GPL. J'en fais naturellement de même pour mes programmes.
[^] # Re: Exemple de ce soir.
Posté par Zenitram (site web personnel) . Évalué à 2.
Oups. J'ai un peu lu de travers. Mais comme tu l'élimine aussi vite que les BSD, ça prêtait à confusion.
Tu aimes la GPL pour son côté copyleft, mais la LGPL est aussi copyleft. pareil pour les "garanties" (bien qu'en tant qu'utilisateur, ça n'apporte rien du tout de plus, que des choses en moins pour l'utilisateur, c'est le dev' qui file moins de droits pour avoir plus pour lui, mais bon, passons). La seule différence est une limite arbitraire mise un peu plus loin.
Bref, pourquoi ne pas lui faire plaisir avec la LGPL, tu ne perds pas la développeur et tu ne perds pas le copyleft que tu aimes, tu ne dis pas pourquoi elle ne te conviendrait pas, tu l'"élimines" sans raison, de mon point de vue.
[^] # Re: Exemple de ce soir.
Posté par hocwp (site web personnel) . Évalué à 2.
La (L)LGPL me conviens tout autant que la GPL. J'ai d'ailleurs utilisé la LLGPL pour un autre de mes projets où je savais que je n'aurai pas besoin de code extérieur contrairement à CLFSWM qui est fortement inspiré des codes de Stumpwm (GPL) et Eclipse (GPL), ainsi que de TinyWM (Public domain).
Et dans les faits, il y a très peu de code provenant de ces projets dans CLFSWM : j'ai écris beaucoup de chose from scratch et à ma sauce.
Le problème majeur de la GPL dans le cas du Lisp, d'après ce que j'ai compris, c'est quelle empêche d'utiliser du code GPL avec une implémentation propriétaire. Et effectivement, je n'ai pas d'objection particulière à ce que quelqu'un utilise mon code avec une implémentation propriétaire (il fait ce qu'il veut tant que j'ai la garantie que le code reste libre).
[^] # Re: Exemple de ce soir.
Posté par gasche . Évalué à 3.
D'abord, es-tu sûr qu'il s'agit bien de "perdre un contributeur" ici ? Moi aussi je reçois de temps en temps des mails de gens "intéressés par mon logiciel" et me demandant de faire ceci ou cela. En général, quoi que je réponde par la suite (et en particulier si je prends effectivement le temps de faire ceci ou cela), je n'en entends plus parler. Est-ce qu'il a donné des preuves concrètes qu'il serait prêt à contribuer, par exemple est-ce qu'il a envoyé un patch ?
Ensuite je ne comprends pas trop l'argumentaire dans ce cas. La GPL est plus restrictive que la LGPL si tu utilises le code comme une bibliothèque, mais toi tu as écrit un programme destiné à l'utilisateur final. Quel usage de ton programme met-il en avant pour justifier l'abandon de la GPL ? Si je comprends bien l'intention de la LLGPL, il s'agit de permettre aux gens de développer et distribuer des hooks par dessus ton programme (en utilisant les facilités dynamiques de Lisp) sous une licence quelconque. Ce cas de figure me semble raisonnable, mais est-ce que ça correspond à ce que tu souhaites ?
À ta place je refuserais poliment ce genre de demandes. Quand on est un extérieur qui s'intéresse à un projet, on commence par faire l'effort de s'adapter aux coutumes locales. Quand je participe à un projet déjà existant j'accepte les licences, langages, systèmes de gestion de version etc. en place, je ne commence pas par dire "il est cool ton projet mais tu ne voudrais pas le recoder en ?". Il me semble qu'un extérieur devrait aussi s'adapter à la licence en place (après éventuellement s'être renseignés des raisons de ce choix). Les choix de licence sont personnels et du ressort des détenteurs du copyright. Si la personne en question devient effectivement contributeur et se retrouve à avoir une proportion non-négligeable de ton projet, alors il aura du poids pour suggérer un changement de licence. Avant, c'est rustre.
[^] # Re: Exemple de ce soir.
Posté par hocwp (site web personnel) . Évalué à 1.
Je ne sais pas si je vais perdre un contributeur, mais c'est vrai que d'habitude, je reçois d'abord des patch et personne ne s'est plaint de la licence GPL. Par contre vue l'activité du monsieur sur github, je pense qu'il peut effectivement amener du code.
Le problème semble être qu'il ne peut pas utiliser du code GPL avec une implémentation propriétaire et donc il préfère la LLGPL ou une de type BSD.
Comme toi, mon premier réflexe a été de refuser poliment et d'en discuter avec les autres contributeurs sur la ML. Après tout, si personne n'est contre, la LLGPL me conviens aussi (je n'ai pas l'intention d'éradiquer les implémentations Lisp proprio. Les versions libres me conviennent très bien mais chacun est libre de faire ce qu'il veut).
# .
Posté par CrEv (site web personnel) . Évalué à 10.
En fait ce que je constate c'est que la GPL reste enfermée dans un monde volontairement 100% libre.
Le problème c'est que ce monde n'existe pas.
Au contraire les licences permissives open source ne s'arrêtent pas au monde libre et prennent beaucoup plus en compte la réalité des choses.
Au final c'est toujours le côté politique, idéologie et utopique du logiciel libre vs le monde pragmatique de l'open source.
Dans les faits, je ne rencontre quasiment jamais de code GPL. Parfois du LGPL.
Pour le reste c'est essentiellement du BSD, MIT, apache.
Un exemple parmis d'autres : les "grandes" boites libèrent régulièrement certains de leurs outils (lib, framework, outils, etc). Jamais ces codes ne sont sous GPL/LGPL. Ces codes sont en général sous MIT/BSD.
Pour s'en convaincre il suffit de regarder les projets libérés par google, facebook, twitter, yahoo, etc.
Ces gens ne veulent pas de GPL. Ok, et alors ? Ils libèrent dans des licences encore moins restrictives, tant mieux.
Alors oui, ils peuvent fermer le code quand ils le souhaitent, ils en font des choses propriétaire. Mais il ne faut pas se tromper de sens. Ces codes viennent de l'interne de ces boites. Rien ne les oblige à libérer leurs code. Donc la fermeture en réalité était avant, et non après la release.
Une GPL n'aurait pas vraiment d'intérêt pour eux, à part complexifier les choses (problématique d'inclusion de patch dans leur version interne par exemple).
Les licences permissives permettent au contraire de faire évoluer l'ensemble et surtout leur permet de libérer leurs code avec leurs contraintes. Et je préfère largement que leur code soit libéré en BSD tout en sachant que si je fourni un patch il sera probablement utilisé en interne (en proprio) plutôt qu'ils ne libèrent pas leur code.
Bon, je sais pas si c'est très clair, mais ce qui est sur c'est que la GPL par son côté exclusif et fermé ne convient pas aux entreprises ne faisant pas exclusivement du libre. Les autres licences (BSD, MIT, etc) permettent justement à ces entreprises de libérer leurs programmes comme bon leur semble. Et là c'est gagnant pour tout le monde.
[^] # Re: .
Posté par claudex . Évalué à 5.
C'est eux qui détiennent le copyright du projet, ils font ce qu'ils veulent avec le code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à 3.
Pas avec les patchs.
Une autre solution est que ton patch est filé avec copyrights (donc en interne ils font ce qu'ils veulent), ce que fait Qt par exemple, mais les libristes n'aiment pas trop (ils ne sont jamais contents ceux-la!), donc faire du BSD est une alternative pour arriver au même but en faisant hurler les adorateurs du copyleft (mais pas trop) mais sans devoir demander les copyrights en permanence (au moins, l'utilisation proprio est affichée dès le départ).
[^] # Re: .
Posté par claudex . Évalué à 2.
Ils acceptent les patchs externes dans la majorité des projets qu'il a cité?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: .
Posté par CrEv (site web personnel) . Évalué à 2.
http://code.google.com/p/closure-library/wiki/Contributors par exemple
donc oui il peuvent accepter les patch
après c'est une histoire de politique, sachant en plus qu'en général chez google le projet libre et le projet interne ne sont pas les mêmes (il suffit de lire les commits pour comprendre).
Mais les patch peuvent exister.
[^] # Re: .
Posté par gasche . Évalué à 1.
Je ne comprends pas cet argument. L'intérêt de la GPL pour les boîtes est le même que pour les individus isolés : ils s'assurent que les modifications faites à leur code et diffusées restent libres, et qu'ils peuvent donc les intégrer à leur version upstream si ça leur chante.
Pour la question de l'inclusion des patches, les groupes qui veulent se simplifier la gestion légale demandent de toute façon l'abandon du copyright (cf. ton exemple ci-dessous de la bibliothèque Closure de Google, distribuée sous licence Apache, mais qui demande tout de même un accord sur la licence des contributions (donner ton copyright à Google) avant d'accepter un patch). Donc que le projet soit en GPL ou une licence permissive ne change rien de ce point de vue là, ils conservent le copyright entier et donc la possibilité de le relicencier comme ils le souhaitent.
Pour moi c'est une question de culture et de préférences personnelles, mais dans ton message il n'y a rien qui indique pourquoi les boîtes devraient préférer MIT/BSD à GPL.
[^] # Re: .
Posté par CrEv (site web personnel) . Évalué à 2.
Mais en général ça ils s'en fichent...
D'ailleurs c'est ce que j'essayais d'expliquer : ils ne codent pas de manière libre et ouverte, ils libèrent simplement des codes.
Et dans ce contexte la GPL serait inutilisable : si leur lib (si on prend par exemple guava, guice, des lib bien de base et plutôt centrales dans les projets les utilisant) était en GPL seules les personnes souhaitant faire du GPL pourraient l'utiliser.
En faisant du BSD(-like) tout le monde peut l'utiliser, que ce soit pour du proprio ou non.
Si l'intérêt est de permettre d'utiliser leurs travaux alors la GPL est un non sens car elle est restrictive. Les BSD like sont beaucoup plus adaptées car elles ne présupose pas que les utilisateurs pensent obligatoirement comme la personne qui libère le code.
La GPL s'inscrit malheureusement dans une optique d'enfermement.
Il faut aussi comprendre que ces personnes ne mettent pas en open source dans le but de développer un outil, mais libère des codes déjà développés (pour Google il s'agit parfois de codes de plus de 5 ans...)
[^] # Re: .
Posté par Tryphon_bzh . Évalué à 2.
C'est un peu fort ça...
Pour ma part, je choisis la GPLv3 pour tout mes développements. C'est un choix politique que j'assume, mais je ne trouve pas que ce soit un enfermement. Je me prive tout seul d'une réutilisation de mon code dans d'autres projets utilisant des licences trop permissives (à mon gout). Dommage, car moi aussi j'aime que mon code soit réutilisé... seulement je pense que c'est le meilleur moyen de s'assurer d'une réciprocité.
Oui, je veux faire du code et le partager.
Non, je ne veux pas que l'on puisse l'inclure dans un projet dont je ne pourrai pas disposer des sources.
Je choisis la GPL dans une optique d'ouverture pour favoriser un écosystème de logiciels ouverts.
C'est dans mon intérêt : tous les logiciels que j'utilise sont libres. L'enfermement, c'est une question de point de vue : pour moi c'est une garantie de survie pour l'écosystème que j'utilise. Je ne taxe pas les développeurs qui choisissent les BSD, MIT... d'enfermement, je les trouve juste un peu trop gentils ;-) : ils passent du temps à faire du logiciel de qualité qui peut se retrouver un jour dans Android ou MacOs peut-être, et là, ils n'auront plus le droit de disposer du code du système complet s'ils ont envie de modifier quelque chose (avec quelques nuances pour Android, la difficulté étant de trouver une téléphone assez ouvert pour pouvoir bidouiller)...
Si l'on parle de commerce ou de parts de marché, l'approche "permissive" est sans doute plus pragmatique, ça se défend et je suis bien content qu'il existe cette diversité de point de vue. Je préfère quand Google développe en "permissif" OpenSource plutôt qu'en ClosedSource.
Peut être d'ailleurs que le succès relatif des licences permissives s'explique par l'arrivée de nouveaux acteurs dans l'OpenSource qui ont peur de la GPL.
[^] # Re: .
Posté par CrEv (site web personnel) . Évalué à 5.
Non non, c'est bien ça.
La GPL oblige à rester en milieu fermé (entre GPL quoi) (je parle bien de GPL, pas de LGPL)
Les BSD, MIT ou autre n'obligent rien à ce niveau là.
Enfin, tu veux faire du code, le partager, mais pas avec tout le monde...
Hein ?
Si je développe une lib en BSD. Celle-ci peut se retrouver dans MacOs par exemple. Ok. En quoi je n'aurais plus accès au code la lib que j'ai écris ? Rien, il est toujours disponible de la même manière. Evidemment je n'ai pas accès au code des autres programmes utilisant ma lib. Oué, c'est vrai, et c'est pas grave, je m'en fiche.
Si je met un code en BSD, MIT ou autre, c'est pour qu'il soit utilisé.
(oui la phrase s'arrête réellement là, jusque que ce soit utilisé. Le reste je m'en fiche. Si je met le même code en GPL, je veux bien qu'il soit utilisé mais que
entre gens bienspar d'autres programmes GPL. Mais je n'ai pas à forcer les autres à utiliser du GPL s'ils n'en ont pas envie)Le truc c'est que souvent la FSF (et autre) veulent faire croire que la GPL est la seule vrai solution. Mais les faits montrent le contraire. Toutes les grosses boites qui release du code le font avec des licences type BSD. Jamais (ou presque) sous LGPL, encore moins sous GPL.
Donc je maintiens que oui, la GPL s'inscrit dans une politique d'enfermement. Une politique d'enfermement dans le sens où tout le monde fait pareil et surtout on se place dans un monde où les autres n'auraient pas le droit de faire autrement.
Je suis pour le libre, pour le partage, etc, mais si certains veulent faire du libre ... grand bien leur fasse. Je n'ai pas à les juger ni à les forcer à faire autrement.
Et au final ils font aussi du libre.
En ce sens, les licences BSD like n'obligent à rien, et ça fonctionne.
[^] # Re: .
Posté par gasche . Évalué à 2.
En fait tu utilises deux arguments différents, qui sont chacun intéressants, mais incompatibles entre eux.
D'une part tu dis : quand les grosses boîtes libèrent du code, elles ne cherchent pas à faire vivre un projet libre autour, à récupérer les modifications des autres (ce que facilite la GPL), c'est du code vieux qu'elles ont dans les cartons et qu'elles mettent simplement sur le trottoir en se disant que c'est tant mieux, si n'importe qui s'en sert comme ça lui chante. C'est pour ça qu'ils ne s'embêtent pas avec la GPL, une licence BSD suffit pour les "code dump", et de toute façon ils ne comptent pas intégrer des retours.
D'autre part tu dis : la GPL c'est moins bien parce que regardez, les grosses boîtes utilisent d'autres licences.
Je persiste à dire que le fait d'être un individu ou une entreprise ne change rien en soit : toutes les personnes physiques ou morales qui détiennent du copyright font des choix de licence, héréditaires ((L)GPL) ou non (MIT/BSD), selon les compromis qu'ils veulent entre permissivités et retours des utilisateurs.
Il n'y a rien de spécifique aux individus ou aux entreprises qui force l'un ou l'autre choix. Ce qui change, c'est ce que les gens veulent faire du code qu'ils diffusent :
- s'ils veulent faire vivre un projet autour, le maintenir sur la durée, intégrer les contributions externes, avoir le plus de retour et d'améliorations possible, ça fait du sens de choisir une licence héréditaire (mais on peut aussi prendre une non héréditaire et compter sur le fair play des utilisateurs)
- s'ils ne comptent pas tenir le code à jour ou intégrer des modifications et ne s'intéressent pas à l'usage qui est fait par la suite, en particulier si c'est un "code dump" d'une vieille version ou d'un logiciel qui ne les intéresse plus, alors ils peuvent choisir une licence non héréditaire (donc plus permissive, donc avec un public plus large)
Il y a à la fois des individus et des entreprises qui se retrouvent dans les deux cas. Du fait que 'plein de gens font du "code dump"' tu ne peux pas déduire que les licences héréditaires sont moins bien pour le libre : cette conclusion ne s'applique pas aux gens qui veulent au contraire faire vivre un projet.
Bref, pour moi cette nuance a un intérêt, mais ne permet pas de porter un jugement entre les différentes licences. Par contre, il pourrait servir à expliquer le changement de proportion entre les licences, si plus de gens faisaient du "code dump" aujourd'hui qu'il y a 5 ans. Je ne sais pas si c'est le cas, mais c'est crédible.
[^] # Re: .
Posté par CrEv (site web personnel) . Évalué à 4.
Je pense que tu n'as pas compris.
Je n'ai pas dit que ces boites faisait des "code dump".
J'ai dit que ces boites ont développé avant de publier une version open source. Ca n'empêche absolument pas ces projets de vivre.
Ces projets en réalité n'ont pas besoin de libre pour fonctionner. Il ne s'agit pas de projets libre au sens fonctionnement, communauté, etc (d'ailleurs un projet n'a pas besoin d'être libre pour être communautaire). Mais il s'agit plutôt de projets "open source".
Mais ça ne veux pour autant pas dire qu'ils ne veulent pas de contribution...
Non, ce que je dis c'est : regardez, tous les projets du genre qui sortent sont sur des licences permissives type BSD, MIT, ... Et ce que je dis c'est qu'il y a forcément une raison.
D'ailleurs, même si ça peut être pris comme ça, je ne dis pas "la GPL c'est moins bien", mais je dis que la GPL fonctionne en cercle fermé (ok, la LGPL moins) là où les autres fonctionnement de manière beaucoup plus ouvertes.
Le problème de la GPL est qu'elle souhaite que tout le monde fasse de la GPL.
Je pense surtout qu'il y a de plus en plus de projets open source, et que la progression des projets open source est plus importante que la progression des projets libres.
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à -1.
Pas de soucis sur ce point, mais ça :
Non, tu ne veux pas faire du code et le partager.
Ce que tu veux, c'est faire du code et le partager avec des gens qui font du compatible GPL. Tu mets un critère de sélection à ton partage, pour toi, de ce que je lis, il n'est pas question de partager, mais partager sous conditions.
"Légère" différence.
Il n'y a rien de gentil. C'est un choix. Réfléchi (sauf exceptions, comme toujours).
Bref, je ne critique pas ton choix, c'est le tient et je n'ai rien à dire. Mais dire que tu fais du GPL dans le but de partager, désolé, mais non, tu partages suivant des critères de sélection, le partage ne se fait pas avec tout le monde, si ton but est le partage (sans rien mettre derrière), il te faut changer de licence.
Note : je ne fais pas de BSD, j'assume : je ne veux pas partager (=pas avec tout le monde)
[^] # Re: .
Posté par GuiBrother . Évalué à 1.
Pour moi, GPL, c'est "je partage mais vous devez jouer le jeu", LGPL c'est "je partage et vous pouvez jouer le jeu".
Donc oui GPL est plus restrictif que les autres licences mais quand je vois certains logiciels qui coutent un bras (en argent, vie privée ou autre), sont incontournables car "standard de fait dans le domaine" et que ces logiciels utilisent 80% de bibliothèques libres (LGPL, MIT, ou autre), ça me fait toujours râler. Pas un centimes, pas un patch n'ira aux développeurs de ces bibliothèques ceux-ci ne pourront pas utiliser une seule fonctionnalité sans passer à la caisse !
Si toutes ces bibliothèque étaient GPL, ce serait "ok, si tu profites de 80% des libs, tu joues le jeu et tu laisses tes 20% accessibles aussi, sinon va voir ailleurs"
[^] # Re: .
Posté par CrEv (site web personnel) . Évalué à 2.
Pourquoi râler ?
* personne n'a obligé les libs à releaser en LGPL, MIT ou autre, donc ils respectent les règles
* si 80% provient des libs, qu'est ce qui t'empêche de recoder les 20% ? ça doit pas être si énorme alors...
* (c'est quoi ces softs, car j'en rencontre jamais comme ça...)
Sur ?
La dernière fois que j'ai utilisé un projet sous licence BSD si je ne me trompe, il m'a fallu seulement deux jours pour que je leur envoie un patch. Et pourtant c'est pas pour un produit open source.
Mais d'ailleurs, pour qu'un patch soit envoyé aux dev, il faut que le patch existe. La plupart du temps les libs sont juste utilisées, non modifiées.
Pour le pas un centime, ben normal. Mais ce que soit GPL, LGPL, BSD, etc, rien n'oblige à donner de l'argent. Donc aucun rapport.
Et donc en réalité personne ne le ferait, donc tout le monde recoderait encore et encore les mêmes libs.
Autant la logique de la LGPL est bien (tu modifie, tu release - enfin à tes clients). Autant avec la GPL, c'est plus compliqué : tu utilise (on ne parle même pas de modifier) et tu donne tout ce que tu as fait à tes clients. Sur le principe jsuis pas contre, en réalité ça ne fonctionne absolument pas.
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à 0.
Ca me va. Je réagissais sur le fait qu'il manquait "mais vous devez jouer le jeu" après son "je partage".
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à 0.
Euh... C'est le libre! Tu n'aimes pas le libre, ne fait pas de libre, mais ne râle pas sur les conséquences logiques du libre. Râle plutôt sur ceux qui râles des conséquences normales du libre (bref, râle sur toi ;-) ).
Voit pas le rapport. GPL ou BSD, pareil : rien à faire de l'upstream. Et GPL ou BSD, ils reçoivent des patchs et de l'argent.
Tu te trompes de combat.
[^] # Re: .
Posté par gasche . Évalué à 4.
Je ne suis pas d'accord. Il y a une différence entre ce qui est légitime et ce qui est légal, et il est tout à fait normal de souhaiter que les gens se montrent corrects même dans les cas où ils n'y sont pas forcés par la loi.
Il y a ce genre de débats entre GPL et BSD: la GPL impose (modulo la question de qui est le client, etc.) que les modifications au code lui-même soient redistribuées, la BSD ne l'impose pas. Pourtant les projets sous BSD préfèrent en général qu'on les tienne au courant des changements qu'on fait downstream, mais si ce n'est pas une obligation légale. Il leur arrive même de râler quand les projets ne le font pas. Je ne pense pas qu'on puisse dire qu'ils n'ont pas à râler, parce que "c'est le libre".
Plus généralement il faut savoir faire la part des choses entre ce qui est légalement obligatoire et ce qui est recommandé. Mais ça ne veut pas dire, comme ton message le laisse entendre, que seul l'obligatoire existe et que les gens qui comptent sur les bonnes actions (et qui dont se permettent de râler quand elles n'ont pas lieu) sont de doux idiots. C'est un raisonnement ultra-libéral (tant que le marché ne nous force pas à ne pas polluer en produisant, allons-y à fond et maximisons les gains, le social c'est pour les tartes, et si tu râles, bah c'est la loi du marché mon petit) qui n'est correct ni en économie, ni au sujet du logiciel libre, à mon humble avis; bien sûr c'est subjectif, tu as le droit de raisonner ainsi (tu rentres dans la catégorie "personne peu fréquentable" mais bon), mais ce n'est pas la seule position rationnelle.
# Quelques commentaires
Posté par Croconux . Évalué à 2.
Le truc qui me chiffonne est que comme tu le fais remarquer les méthodes de calculs de ces chiffres sont plutôt opaques et pourtant à partir de là on commence à élaborer des théories sur le pourquoi du comment.
Si une étude dont on ne connaît pas bien les origines indique que les gens plébiscitent les DRMs, faut-il commencer à imaginer les raisons qui poussent les gens à adorer les DRMs ou chercher d'autres études plus transparentes pour confirmer ou infirmer ?
D'autre part, il me semble qu'il faudrait voir aussi la répartition en fonction de la taille et de la vivacité des projets. Si on fait des stats sur les projets hébergés sur une forge quelconque, le soucis est que la plupart n'ont qu'un développeur et sont souvent morts-nés. Beaucoup de gens créent un compte pour partager 3 lignes de codes ou une n-ième réimplémentation de grep parce-que-celle-là-c-est-la-mienne. Dans ce cas, ils ont souvent tendance à choisir une licence permissive (WTFPL). Des projets comme ça il y en a des centaines mais personne ne les utilise (à part peut-être l'auteur pendant les 6 premiers mois).
A côté de ça il y a aussi les projets libérés par des grandes entreprises. Il y a deux grandes famille : Ceux que la boite utilise toujours en interne (Darwin), ie. je libère le truc en espérant que certains l'amélioreront pour que je puisse réintégrer les changements dans ma version proprio (forcément sous une licence permissive). Ce type de projet ne déplace en général pas les foules si les contributeurs ne voient pas bien ce qu'il peuvent en faire. Ca rends service à la boite mais est-ce que c'est utilisable en dehors de la version proprio ? Qui utilise Darwin hors OSX ?
La deuxième est celle des gros flops commerciaux (OpenSolaris, WebOS,...). On libère le truc parce que de toutes façons c'est mort et on n'en fera plus rien. Au bout de 6 mois, ce type de projets n'est souvent plus utilisé par personne. La aussi pas beaucoup de contributeurs.
Je serais curieux de voir ce que ça donne sur les projets les plus actifs (commits ou nouvelles versions régulières) et un minimum utilisés. Après, le choix de la licence dépends beaucoup du type de projet et de l'usage qu'on veut en faire, beaucoup plus que de la mode du moment à mon avis.
[^] # Re: Quelques commentaires
Posté par Zenitram (site web personnel) . Évalué à 2.
Elles ne sont pas opaques : suit les liens, et il est indiqué comment les chiffres sont obtenus. Après, libre à toi de d'une refaire les stats à partir des données, et de deux optionnellement refaire le crawling des sites d'hébergement.
Oui, il y a une limite à l'étude (taille, vie des projets), mais c'est indiqué, et à limite identique (le même crawling sur les mêmes sites), on voit quand même la tendance.
Sans compter que ça ne fait que confirmer ce qu'on voit de manière naturelle (bien plus de monde qui parle d'open-source que de libre/free software, dans la vraie vie)
Si tu penses que cette tendance est fausse, je suis preneur d'étude de ta part qui conclurait objectivement le contraire. Car pour le moment, personne ne dit le contraire (le seule argumentation des pro-copyleft est "certes, mais on nombre absolu, ça augmente", aveu?)
# GPL en contradiction avec les principes de liberté de la FSF
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 0.
J'ai toujours été surpris du fait que R.M. Stallman défende le principe de liberté totale pour l'utilisateur tout en proposant une licence aussi contraignante.
Je ne veux pas cracher dans la soupe, cela a sans doute fait du bien pour faire émerger quelque chose, mais aujourd'hui, ça rend impossible la combinaison de certains logiciels (licences incompatibles) pour des histoires de guerres de chapelles (franchement, vous voyez des différences fondamentales entre les licences copyleft vous ?).
Je pense qu'on en est à un stade où la mayonnaise a pris : le stock de logiciel libre est suffisamment conséquent pour qu'une grande partie de l'industrie du logiciel ait intérêt à y piocher et donc à y contribuer. Les moyens de promotion du logiciel libre gagnent à être différents et en particulier plus ouverts.
On n'en est pas encore là, mais cette tendance concernant les licences GPL (et j'espère aussi les autres licences copyleft) me rassure. Car si elles ont fait émerger quelque chose, elles finiront, je pense, par étouffer le logiciel libre.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par Zenitram (site web personnel) . Évalué à 2.
Un truc que je n'ai pas compris, c'est cette manie de vouloir "tuer" la LGPL, alors que celle-ci permet de garder le copyleft tout en pouvant mélanger avec d'autres licences.
J'ai l'impression que RMS/la FSF n'a pas compris que le monde a changé en 10 ans, et que maintenant on prend des briques, des API, à droite à gauche, et que du coup la GPL est "incompatible" avec le mélange des licences provenant de différent projet, alors que les licences non copyleft ne posent pas ce problème.
Bref, j'ai l'impression qu'à avoir loupé ce changement, en n'adoucissant pas leur position (GPL, GPL, GPL... Non, la LGPL ce n'est pas bien, évitez la...), les pro-copyleft se sont tiré une balle dans le pied : on les ignore de plus en plus.
Dommage, j'aime bien le copyleft, mais ce n'est pas tenable (bon, pour l'instant je diffuse sous LGPL, mais un jour qui sait, je passerai peut-être en BSD/MIT)
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par rewind (Mastodon) . Évalué à 1. Dernière modification le 07 janvier 2012 à 12:41.
'Make Your Open Source Software GPL-Compatible. Or Else.'
http://www.dwheeler.com/essays/gpl-compatible.html
Quelqu'un qui fait du copyleft, il peut tout utiliser (le BSD, le MIT, et même maintenant du Apache 2 et du MPL 2 s'il utilise la GPLv3). C'est le contraire qui n'est pas possible mais d'un autre côté, un pro-copyleft, il s'en fout que des gars BSD n'utilisent pas son code. Donc pour moi, rien de choquant.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par Zenitram (site web personnel) . Évalué à 0.
Fait-moi un produit qui mélange GPL et proprio avec link statique (appel en ligne de commande pour contourner le problème, je sais faire, mais ça ne marche pas à tous les coups et surtout c'est lent), et tu me fais signe, hein. Ne me balance pas un lien qui zappe le problème en balançant un "pour résoudre le problème, soyez compatible GPL", c'est juste la démo que le problème n'est même pas compris. Regarde un titre "GPL-incompatible licenses risk lack of support (GPL most popular)" --> NON. La réponse est : les licences incompatibles GPL font dégager ces emmerdeurs de GPL, ce sont les logiciels GPL qui vont manquer de soutien à force (voir graphique du journal)
Et du Apache 1 et MPL 1? Tiens, bizarre, tu les oublies. Il y a une tonne de licences incompatibles avec la GPL. Ben oui, c'est con, mais : non, pas possible, la GPL fait chier son monde à être incompatible (avec du code libre aussi).
Un truc que tu n'as sans doute pas compris dans mon message : on prendre des briques par ci et par la, et on ne choisit pas la licence des autres briques. Il y a de tout (libre incompatible GPL, proprio... Comme dans une distro en fait, juste que la GPL met une limite arbitraire bizarre et... chiante), et la GPL fait donc chier, donc le logiciel GPL dégage, il est trop casse couille, toutes les autres briques sont compatibles entre elles sans rien réclamer aux autres briques, elles. Et comme la FSF dit que la LGPL c'est bof caca machin chose pas positif, ben... Reste que les non copyleft, ou comment ne pas s'adapter au point de couler son idée de copyleft à être aussi rigide.
Le monde change : le libre bouffe le proprio à force de proprio rigide, mais aussi le non-copyleft bouffe le copyleft à force de copyleft trop rigide (et plus du tout adapté)
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par rewind (Mastodon) . Évalué à 1.
Mais quelqu'un qui choisit la GPL, c'est justement qu'il veut éviter ça. Donc, la GPL remplit bien son rôle. Après, il empêche ceux qui veulent faire du proprio d'utiliser son «produit», mais il s'en fout, c'est son code, il fait le choix qu'il veut et l'autre qui veut faire du proprio, soit il s'aligne (et le gars qui fait du GPL a gagné son pari), soit il va voir ailleurs.
Il ne t'aura donc pas échappé que les versions les plus récentes des licences citées ont tout fait pour être compatible GPL, ce qui montre bien la centralité de la GPL dans le paysage des licences, ce que dit l'article que j'ai mis en lien.
Personnellement, je ne pense pas que si la GPL était plus «souple» (genre LGPL), il y aurait plus de logiciels venant de l'industrie en LGPL. Faut pas rêver, les extensions proprios, c'est pas d'aujourd'hui que ça existe, le problème était le même avec BSD Unix dans les années 70-80 et on voit bien où ça a conduit. Toi qui dis souvent que les gens n'apprennent pas de leurs erreurs, je trouve que tu devrais relire l'histoire d'Unix et de BSD pour voir où mène la souplesse. Pour moi, elle a mené Stallman à la GPL, et le constat est toujours valable à l'heure actuelle.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par Zenitram (site web personnel) . Évalué à 1.
Euh... Juste : tu as vu les courbes? Tu penses que ça va être quoi dans 5 ans? Pas sûr que sa GPL soit la solution miracle (au contraire). Tu as vu la réaction de L. Torvalds sur la GPLv3? Il n'a pas l'air en phase avec RMS, juste un "hasard" que cette licence ai été prise.
Oui, je dis qu'ils n’apprennent pas de leurs erreurs, et l'enfermement "GPL à tout prix" est, de mon point de vue certes, une erreur, la courbe le montre, la, maintenant, et sans doute dans 5 ans. Mais bon, on verra bien, facile, suffit d'attendre.
Et le journal démontre la tendance vers le contraire... la GPL, ça a marché à un moment, comme Internet Explorer pour Microsoft, et comme pour Internet Explorer, la tendance va à la chute. On peut ne pas réagir, on peut réagir et s'adapter à la nouvelle demande, c'est un choix. Microsoft a décidé de réagir (et a quand même du mal à remonter la pente); et la FSF/RMS? Bon, après, ce n'est pas grave pour l'open-source, il reste le non copyleft.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par gasche . Évalué à 5.
Pas la peine de faire du défaitisme non plus. Les choix de licence c'est aussi des effets de mode, ça peut varier. Passer de 70% à 50% c'est une descente, mais ça ne veut pas dire automatiquement qu'on est à 0% dans 3 périodes, et les discours "on peut ne rien faire ou s'adapter à la disparition de la GPL" sont donc un peu prématurés.
On a entendu les mêmes discours au sujet d'Apache qui déclinait contre IIS il y a quelques années (du même ordre, genre de 80% à 50%). Résultat, aujourd'hui Apache n'a pas regagné l'avance perdue, par contre c'est nginx et lighttpd qui sont apparus et au final IIS n'est plus en deuxième position selon certaines mesures.
Bref, difficile de savoir ce que l'avenir ne nous réserve, mais je trouve que tu tires tes conclusions un peu vite.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par rewind (Mastodon) . Évalué à 5.
Le journal ne dit pas que le nombre de soft en GPL baisse, il dit le contraire même. En revanche, il dit qu'en proportion, ça baisse. Ce qui est légèrement différent. Et puis bon, baisser quand on est à 50%, je trouve ça pas si mal que ça. Après, tu peux considérer que c'est foutu. Mais le fait est que la hausse en proportion des autres est dû (comme expliqué ailleurs) aux petits bouts de code qui pullulent depuis l'apparition de github et consors, et aux grosses libérations. Bref, pas vraiment de quoi se réjouir trop vite. Par exemple, doit-on considérer que le code d'OOo passé en licence Apache alors qu'il était en LGPL est une bonne nouvelle ? Je ne le pense pas. Mais tu peux continuer à causer de manière globale sans regarder les détails et crier à la fin du monde GPL.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par ckyl . Évalué à 6.
Tu as 100% raison sur ce coup. De nos jours c'est très rare de faire du pognon avec des libs ou des briques de bases. Seules les applications ou les systèmes entiers font rentrer du cash. Du coup il n'y a plus d’intérêt à garder ça proprio en interne et publier en open source ce qui a une valeur technique mais non business prend tout son sens. Que se soit pour profiter des avantages d'une communauté étendue, se faire un bonne image, ou pousser ses technos.
En tant qu'utilisateur quand tu construis un soft ou un système dans 99% tu évites les dépendances GPL comme la peste. Par ce que ça te met une contrainte monstrueuse sur ton produit pour le reste de sa vie. Adieu tout espoir de dual-licensing, de rachat de ta boite, d'évolution de ta license (enjoy GPL v2 VS v3) etc. Donc quand tu poses dans le pot commun, tu poses dans une licence que tu accepterais en tant qu'utilisateur. Du coup ca fini en ASL/BSD ou assimilé.
Le monde du logiciel à beaucoup changé ces derniers temps. Les briques logiciels open source passent leur temps à être combinées, et l'application unitaire s’efface. Dans ce contexte la GPL se retrouve avec un publique de plus en plus restreint, constitué principalement des petits softs, des applications pour les bureaux libres et des boites voulant faire du dual-licensing.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par Zenitram (site web personnel) . Évalué à 2.
J'ai toujours raison (zut, je n'arrive pas à rentrer dans mes chaussures maintenant :) )
Euh... Je suis si rare que ça? Je vis majoritairement d'une lib (l'interface CLI ou GUI étant du bonus et/ou pour montrer l'exemple), on me paye pour la faire évoluer, pour que cette brique réponde au besoin remonté par le client de mon utilisateur.
J'aurai dit qu'au contraire, on peut faire du pognon avec des libs ET un système entier : l'un et l'autre sont complémentaire (lib = pour les experts techniques, système entier = peinture marketing qui répond au besoin d'un client, hop on sépare les "métiers" et chacun y trouve son compte)
C'est effectivement un bel exemple : hop deux briques en GPLv2 pures depuis des années, une passe en GPLv3 pure, et t'es mort. Bon, finalement, je vais finir par croire que cette v3 a amorcé le déclin en faisant prendre conscience que la GPL allait trop loin!
Ca oui : l'application unitaire est remplacée par une lib unitaire, et l'application au dessus mélange toutes ces libs unitaires. Et la, la GPL est chiante.
Ca ne fait pas/plus beaucoup...
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par ckyl . Évalué à 3.
Tu ne vis pas de tes ventes mais de la facturation de dev non ? Si ca marche fort, ta lib arriveras rapidement à une couverture fonctionnelle suffisante pour que plus personne n'ait besoin de dev et ton business est mort.
Et si tu vis de tes ventes. Il va falloir soit être très au dessus de tout concurrent pour vendre, soit prier pour qu'aucun concurrent open source n'arrive dans la bataille.
Ce que je dis c'est que faire vivre une vraie équipe de dev sur les ventes des libs ou de briques technologiques ca reste très difficile. Par exemple essais de financer JBoss en vendant du netty, du resteasy ou du jBPM ca me semble suicidaire. Par contre tu fais ton pognon sur les applis et les packages que tu vends. Bref les couches techniques sont de plus en plus difficilement monétisables et deviennent des légos. L'open source est en grand réservoir dans lequel tu pioches largement et quelque fois tu déposes pour construire ce que tu vas réellement vendre.
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par gasche . Évalué à 1. Dernière modification le 08 janvier 2012 à 10:27.
Si c'est une dépendance externe, pourquoi la LGPL (avec éventuellement des exceptions de linking si nécessaire) ne serait-elle pas acceptable ?
[^] # Re: GPL en contradiction avec les principes de liberté de la FSF
Posté par claudex . Évalué à 2.
Ça dépend lesquels mais oui.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# CeCILL
Posté par Anonyme . Évalué à 5.
Pour mes futures codes, je pense que je vais me mettre à utiliser CeCILL.
En effet :
[^] # Re: CeCILL
Posté par al.jes (site web personnel) . Évalué à 4.
Dans le même ordre d'idées, j'utilise la licence Art Libre (version 1.3) qui est :
Du coup j'utilise toujours le même contrat de licence, que ce soit pour mes nouvelles, séries, scénarios, documents de réalisation ou que ce soit pour du code.
[^] # Re: CeCILL
Posté par Anonyme . Évalué à 1.
Je ne sais pas pourquoi tu as été moinssé, ton commentaire est plutôt pertinent.
Pour ma part, j’aurai tendance à utiliser la Licence Art Libre pour des œuvres « artistique ». Comme je ne suis pas un vrai hacker, je ne considère pas mon code comme de l’art.
[^] # Re: CeCILL
Posté par Antoine . Évalué à 2.
Il y a aussi des artistes du dimanche.
Par contre la licence Art Libre a un gros défaut pour le code : elle ne requiert pas la mise à disposition du code source. Pour une licence copyleft, c'est une limitation gênante.
[^] # Re: CeCILL
Posté par al.jes (site web personnel) . Évalué à -2.
cf. ma réponse à Arcaik ci-dessous.
Faux. Voici les articles 2.2 et 2.3 de la licence :
L'original étant défini (entre autres) comme étant les sources ou ressources de l’œuvre (donc le code source dans le cas d'un logiciel).
[^] # Re: CeCILL
Posté par Antoine . Évalué à 2.
C'est un contresens. L'original est l'oeuvre dont l'« oeuvre modifiée » est dérivée. Par exemple, si tu fais une photo d'une statue, l'original est la statue. Si tu fais un pastiche de la Joconde, l'original est la Joconde (qui certes n'est pas sous LAL :-)).
« Sources ou ressources » ne désigne pas le code source, dont il n'y a par ailleurs aucune définition dans la LAL (au contraire de la GPL qui évoque la « forme préférée pour la modification »). La LAL ne s'intéresse qu'aux manifestations de l'oeuvre, pas à la manière dont elle a été produite (par exemple la compilation dans le cas d'un logiciel).
[^] # Re: CeCILL
Posté par al.jes (site web personnel) . Évalué à 0.
Je suis bien d'accord avec toi quant à la définition générique d'un original ; je ne parlais là que de la définition donnée par la LAL pour la compréhension de celle-ci. Voici la définition donnée pour la LAL :
La LAL parle bien de ressources.
[^] # Re: CeCILL
Posté par al.jes (site web personnel) . Évalué à 1.
Au temps pour moi, j'aurai dû rappeler ma définition (très subjective) de l'art. Tu noteras qu'au regard de cette définition, tout média peut donner matière à de l'art, code y compris.
De plus, la seule référence directe à l'art (à part dans son nom) se fait dans l'explication de son contexte d'apparition. Donc la licence est vraiment applicable à toute œuvre de l'esprit.
# Autre suggestion
Posté par Ant . Évalué à 4.
Moi j'ai une autre idée, qui me semble beaucoup plus évidente : le marché du développement de logiciels libres est en augmentation avec des nouveaux arrivants issus de divers horizons et qui souhaitent faire une exploitation commerciale de leurs productions.
Du coup, ils sont réticents à utiliser une licence trop restrictive qui limiterait leur possibilités ou l'attrait de leur productions.
[^] # Re: Autre suggestion
Posté par gasche . Évalué à 3.
C'est très crédible.
Ce qui est clair c'est la partie "nouveaux arrivants". Après pourquoi ces nouveaux arrivants utiliseraient-ils moins la GPL en proportion, par rapport aux vieux ? Quelques hypothèses, sans désir d'exhaustivité.
le désir d'exploitation commerciale que tu as évoqué, mais je ne pense pas que ce soit la raison première; d'ailleurs la GPL, dans un schéma de dual licensing, peut être plus propice à l'exploitation commerciale qu'une MIT/BSD; par exemple si Qt et MySQL avaient été mis sous BSD dès le départ, elles n'auraient pas eu clients.
une mauvaise image qu'aurait la GPL, liée à la mauvaise image que l'on diffuse souvent de la FSF (des intégristes qui n'ont rien compris); ils donnent les bâtons pour se faire battre, mais il y a des phénomènes amplificateurs qui ne sont pas innocents (le bloggueur machin qui tweette sur le fait que Stallman ne veut pas de perroquets, etc.)
la jeunesse des projets; l'intérêt de la GPL n'est pas forcément évident à premier abord, et certains développeurs passent à la GPL après d'autres projets où ils n'ont pas été satisfait par le manque d'hérédité sur leur travail. Cf. par exemple Zed Shaw : Why I (A/L)GPL (après c'est une grande gueule à prendre avec des pincettes).
de simples effets de mode, voire de foule; il y a des communautés entières qui utilisent telle ou telle licence sans trop réfléchir, parce que les projets sur lesquels ils se basent l'utilisent, et qu'ils ne connaissent pas bien les questions de licence. Sur beaucoup de points en fait, pas seulement les licences logicielles, la communauté Ruby en particulier joue un peu le rôle de la "communauté d'inculte", qui croit tout savoir et ne prend donc même pas la peine de se renseigner sur comment c'est fait ailleurs.
[^] # Re: Autre suggestion
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Référence nécessaire.
[^] # Re: Autre suggestion
Posté par gasche . Évalué à 1.
Bien sûr, je corrige: "ils n'auraient peut-être pas eu de clients".
[^] # Re: Autre suggestion
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 08 janvier 2012 à 11:01.
Surtout il a rien compris au libre : "I Don’t Want To Be Ignored Again". Ben... GPL ou BSD, c'est pareil à ce niveau. Les libertés, c'est pour celui qui reçoit le code, et le libre n'a rien à battre du développeur qui ne veut pas être ignoré... Le pauvre, si il savait qu'un logiciel GPL peut être utilisé sans que son développeur ne soit au courant...
Gni? Donc PHP, Apache n'ont pas de clients parce que sous BSD-like? Faudrait les prévenir...
Pour exemple, j'ai des clients, et en fait, ils n'ont rien à faire de BSD ou LPGPL (la GPL les dérangent pour d'autres raison, voir mes autres commentaires), ils sont clients car ils ne veulent pas prendre les compétences de dev' pour faire évoluer le produit. copyleft ou non, ça ne change pas le besoin.
Après, le double-licencing est un choix de business model libre, mais pas le seul.
[^] # Re: Autre suggestion
Posté par gasche . Évalué à 2.
Je suis assez d'accord sur le fait que les explications données sont relativement fumeuses, et qu'elles montrent une relative mécompréhension des licences. Il n'empêche que la (L)GPL oblige une personne ayant intégré une brique sous cette licence dans son paquet applicatif à fournir les sources, et que cela peut être compris comme une "obligation de reconnaissance" (même si en fait elle n'est obligatoire qu'envers les clients; en pratique elle est en général distribuée publiquement).
De toute façon à la rigueur que la raison soit bonne ou non "on s'en fiche", si le but c'est de comprendre pourquoi les développeurs utilisent plus ou moins telle ou telle licence logiciel. Si Zed Shaw passe à la GPL pour des raisons qui ne sont pas tout à fait fondées rationnellement, il n'empêche qu'il passe bruyamment à la GPL, qu'il est écouté dans sa communauté, et qu'il pourra avoir de l'influence sur d'autres (effet mouton). Dans l'autre sens il y a aussi des projets qui quittent la GPL pour des raisons relativement bidon, comme Ruby 1.9.3.
Au final ce sont des comportements non rationnels, donc bien que ça ait de l'intérêt de comprendre finement les licences pour expliquer aux gens si leurs décisions correspond à la réalité, ça ne suffit malheureusement pas. Les gens font aussi des choix pour des mauvaises raisons et ces raisons il faut les mentionner, les comprendre et les expliquer, même si elles ne sont pas directement rationnelles...
[^] # Re: Autre suggestion
Posté par Ant . Évalué à 1. Dernière modification le 08 janvier 2012 à 15:33.
Je pense que tous ces arguments sont justes.
Pour un nouveau projet libre mais à prétention commerciale, c'est mon cas personnel, ce n'est pas évident de savoir vers quelle licence se tourner. Il y a la réalité juridique et le problème d'image aussi, important pour certains clients (les gros) ou pour les investisseurs.
Bien sûr, en dehors des "libristes" personne ne pipe rien aux différentes licences, seule la GPL a fait parler d'elle, et pas toujours en bien, d'où la défiance si vous voulez mon avis.
Aujourd'hui on a deux images associées au libre, en caricaturant : le camp des "requins", les grosses sociétés comme free et consorts, qui utilisent le meilleur du libre et en font leur caviar; et puis le camps des "moutons", qui se font tondre, qui travaillent pour rien, qui voudraient que tout soit libre et gratuit, bref qui n'ont aucun sens des "réalités économiques".
Je suis peut-être complètement à côté de la plaque, mais il me semble que basiquement les gens veulent éviter d'être rangés dans le camp des "moutons", coincés par une licence qui les empêchera de gagner leur vie, et qu'historiquement la GPL est plus associée à ce camp.
Mon réflexe à moi, c'est de regarder la licence utilisée par les sociétés du libre "qui ont réussi" (qui sont rentables, à mon sens) et de faire comme eux.
ça paraît bête, mais en définitive c'est toujours défendable.
# Vite dit ?
Posté par sanpi . Évalué à 1.
C'est étrange, en voyant la courbe des licences *GPL suivre celle de la GPLv2 c'est pourtant l'idée que j'ai eu ?!
[^] # Re: Vite dit ?
Posté par Zenitram (site web personnel) . Évalué à 0.
Je serai tenté de dire qu'il y a des chances que ce soit seulement un hasard, je ne vois pas ce que change cette nouvelle version (ceux voulant rester en GPLv2 le pouvant fort bien)
# Quelques interrogations?
Posté par CocoToto . Évalué à 0. Dernière modification le 08 janvier 2012 à 16:53.
Bonjour, je suis un lecteur de passage et un utilisateur de programme libre.
Je souhaite comprendre un détail dans cette phrase
posté dans un commentaire.
Qu'elle est à la définition du mot utilisateur du point de vue de R.M. Stallman. Est-ce qu'il prend comme point de vue l'utilisateur en tant qu'utilisateur (uniquement utilisateur d'un programme) ou utilisateur en tant que développeur ? Autrement dit, est-il question de développeur ou d'utilisateur même si un développeur est aussi un utilisateur mais un utilisateur particulier.
Le copyleft n'est-il pas là pour garantir à un utilisateur de programme (et non pas un développeur) que celui-ci restera libre et ainsi empêcher un développeur de réalisé un programme qui pourrait « enfermé » l'utilisateur d'un programme.
J'aimerai aussi des explications au sujet des BSDs. Si le code d'un programme ou d'une bibliothèque sous licence BSD est modifié (améliorer, ...) est placé sous licence propriétaire ou licence libre avec copyleft, les développeurs ne pourrons pas profiter des améliorations faîtes sur leur propre code donc non réutilisable dans leur propre code. Seul le code d'origine reste sous BSD.
J'espère avoir été clair sur mes interrogations.
Cordialement.
# Commentaire supprimé
Posté par chitest . Évalué à -2. Dernière modification le 11 janvier 2012 à 08:33.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.