Et à titre indicatif, un ordre d'idée de l'investissement actuel des diverses grandes sociétés dans le noyau Linux, en nombre de développeurs employés.

Je compte ici le nombre de développeurs distincts utilisant une email contenant le nom d'une de ces grosses sociétés et dont au moins un patch a été mergé dans le git de Linus entre la sortie du 2.6.22 et aujourd'hui. Ces chiffres ne sont pas précis ni très justes (par exemple certains développeurs n'utilisent pas leur email corporate dans les patchs, ...), c'est plutôt pour avoir un ordre de grandeur et de comparaison approximatif (pour des chiffres plus précis cf. LWN, où J. Corbet publie des études pointues) :

pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*redhat | sort | uniq | wc -l
41
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*suse | sort | uniq | wc -l
23
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*ubuntu | sort | uniq | wc -l
3
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mandr | sort | uniq | wc -l
0
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*oracle | sort | uniq | wc -l
9
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*google | sort | uniq | wc -l
15
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*ibm.com | sort | uniq | wc -l
72
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*intel.com | sort | uniq | wc -l
25
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*amd | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*sgi | sort | uniq | wc -l
8
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mips | sort | uniq | wc -l
5
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*fujitsu | sort | uniq | wc -l
7
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*sony | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*hp.com | sort | uniq | wc -l
7
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*atmel | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*qlogic | sort | uniq | wc -l
14
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*freescale | sort | uniq | wc -l
10
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mvista.com | sort | uniq | wc -l
9

Sur un total de :
pouet$git log v2.6.22..HEAD | egrep ^Author: | sort | uniq | wc -l
754

[ Répondre ]

Sa remarque concernant les priorité des développeurs (et surtout, de leurs employeurs) est intéressante, et semble assez juste lorsqu'on considère les employeurs jusqu'à cette année (ou, disons, jusqu'en 2006) :

- Oracle et IBM emploient beaucoup de développeurs, et il est très clair que le desktop n'est pas vital pour le business autour de Linux.
- La RHEL de Red Hat n'était peut-être pas non plus très desktop-centrique (?)
- Je crois qu'Intel employait surtout du monde pour le SMP, leurs (mauvais) chipsets RAID, l'architecture Itanium etc.
- Rien à voir avec les priorités du monde corporate, mais le verrouillage de XFree86 ralentissait lourdement les progrès aussi.

Mais il semble qu'ironiquement, c'est au moment où Con Kolivas nous quitte que les priorités basculent (en fait ça à commencé un peu plus tôt, mais les fruits commencent à peine à être récoltés, ie. dynticks, network-manager, l'ordonanceur CFS qui vient à peine d'être intégré dans 2.6.23, mac80211, ...), en particulier grâce au monde de la mobilité bon marché :

- Intel emploie une _foultitude_ de développeurs pour travailler spécifiquement sur le desktop, comme : les principaux développeurs de Xorg, du sous-système drm/dri du kernel, l'économie d'énergie, les principaux développeurs du nouveau framework wifi du noyau (mac80211 et cfg80211), vient de lancer une plateforme semi mobile (moblin), etc. Leur investissement dans "Linux pour le desktop" semble croitre à grande échelle, de jours en jours.
- Red Hat est fortement impliqué dans le projet OLPC (totalement "desktop"), et sort une version de son produit commercial, RHEL5, spécialement orientée desktop (sans parler de leur fort investissement dans Fedora). Ils ont aussi lancé à grands efforts le projet "Mugshot"/Global Desktop. Ils sont aussi l'employeur d'Ingo Molnar, qui a consacré pas mal de temps sur dynticks et sur le nouvel ordonnanceur "fair" CFS (n'en déplaise à CK).
- Ubuntu gagne en popularité, en nombre d'utilisateurs finaux (ce qui doit probablement secouer les à priori et priorités des distros plus anciennes et traditionnellement plus orientées "serveur"). Et Ubuntu dispose désormais de quelques développeurs noyau actifs (or le succès sur le desktop est clairement une priorité stratégique pour Canonical/Ubuntu).
- Apparition de sociétés qui développent essentiellement des produits pour le desktop libre (par ex. autour de Gizmo, Gstreamer, ...)
- L'affaire Dell + Linux a certainement du montrer aux constructeurs que les enjeux (ne serait-ce qu'en terme d'image auprès des "leader d'opinions" que nous sommes) de Linux concernent aussi les produits très "grand public".

La (récente) disponibilité de chipsets mobiles très bon marchés (autour des AMD Geode ou Intel Dothan) permet depuis peu de produire des ordinateurs ultramobiles à très bas prix, où le cout de l'OS est donc extrêmement sensible et significatif : du fait de son prix, Linux a une superbe fenêtre pour s'imposer sur le desktop par ce biais.

À mon avis, c'est ce qu'on compris les boites qui emploient maintenant de nombreux devs pour travailler sur la mobilité et le desktop (Intel et ses projets moblin/classmate/asus eee, Ubuntu et sa future version "semi-embarquée", openmoko, ...)..

[ Répondre ]

D'un autre coté, la cadence d'horloge d'une montre à aiguille est de 1 Hz. Ce qui en fait des machines assez modestes, comparées aux ordinateurs récents, je trouve (sauf les couteuses Rolex).

[ Répondre ]

3 à 5 Watts selon le lien digg dans le journal (5W selon le site de l'engin : http://www.fit-pc.com/ ).

Ce chiffre me semble peu réaliste, voir franchement mensonger, d'autant que la machine inclue un vrai disque dur (pas du SD/CF), une carte graphique et un bus USB (des périphériques assez gourmands).

Pour comparaison, un portable de bonne qualité, finement tuné contre la consommation, écran éteint, réseau coupé, dans le plus bas P-State ACPI (la fréquence la plus basse que le proc supporte) et complétement idle (C-state ACPI C4 99.9 % du temps, c'est à dire que même le cache de la CPU est éteint) se situe généralement aux alentours de 10W, jamais moins de 7W (un exemple : http://thinkwiki.org/wiki/Idle_consumptions ).

[ Répondre ]

Ah et bien justement, on parle de ça dans l'édition du LWN ouverte au public aujourd'hui[1].

Il serait vraiment intéressant que quelqu'un rédige un article sur la programmation économe en énergie pour linuxfr (ou mieux Linux Magazine) : utilisation des évènements plutôt que polls réguliers, utilisation de hal, de inotify ou de gamin, des timers regroupés, regroupement des accès aux block devices, réduction des animations graphiques (elles réveillent xorg), stracer régulièrement son application juste pour vérifier qu'elle ne fait vraiment rien lorsqu'elle est au repos, utiliser le système de notification d'Alsa (plutôt que poller le mixer), audit et disagnostic avec block_dump, strace, ltrace, powertop, lm-profiler et blktrace, ...

Les ventes de portables par an ont maintenant dépassé les ventes de stations de bureau[2][3] : la consommation est donc devenue une problématique majeure pour le succès de « Linux sur le desktop ». Et Linux est une option considérée depuis peu avec beaucoup d'attention par les intégrateurs, maintenant - c'est récent - qu'ils disposent de chipsets x86 mobiles tout-en-un à très bas prix : le coût d'une licence Windows sur le portable final est dans ce cas proportionnellement très significatif. C'est probablement un critère déterminant dans le choix de Linux pour l'Asus EEPC, l'Intel Classmate ou encore l'OLPC, et de l'investissement d'Intel (qui commercialise de tels chipsets bons marché) qui paye des développeurs comme Arjan van de Ven pour travailler à plein temps sur la consommation électrique de Linux.

Linux dispose d'une belle perspective pour s'imposer à travers ce nouveau marché des portables (en particulier des ultraportables à bas prix), mais il faut pour cela qu'on apprenne à programmer de façon économe. Jusqu'à présent, on ne considérait pas vraiment cet aspect spécifique, au coté, par exemple, des améliorations des performances ou de la consommation de mémoire vive. Mais les développeurs noyau essaient d'attirer notre attention sur ce sujet[4].

[1] http://lwn.net/Articles/240253/ (voir aussi http://lwn.net/Articles/228143/ et http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0959.ht(...) ).
[2] http://www.usatoday.com/tech/news/2005-01-23-laptop_x.htm
[3] http://www.msnbc.msn.com/id/8090448
[4] Je pense à PowerTOP d'Arjan van de Ven, mais aussi au fameux Why Userspace Sucks—Or 101 Really Dumb Things Your App Shouldn’t Do, Dave Jones (Red Hat), Proceedings of the Linux Symposium, 2006, Ottawa [https://ols2006.108.redhat.com/reprints/jones-reprint.pdf]

[ Répondre ]

En même temps, sur le fond, il n'a pas tord. Les gens sont souvent intimidés par l'idée de faire un rapport de bug pour le noyau : c'est dommage. Si vous pensez n'avoir pas assez d'informations à reporter, les développeurs vous indiqueront comment obtenir les informations utiles.

L'idéal serait peut-être que Grégory fasse un git-bissect, qui permettrai de trouver l'exact patch fautif. Bissecter entre les noyaux 2.6.21 et 2.6.22 (environ 7000 patches) demande 13 recompiles & reboots (+1 pour tester le 2.6.22 avec le seul patche fautif reverté). Un peu long (surtout les recompiles), mais pas insurmontable.

[ Répondre ]

C'est pour ça qu'il faut compter les lignes avec un utilitaire comme sloccount : il ne compte que les lignes de code, et zappe les fichiers autres que le code (makefiles, doc, ...), et les lignes de commentaires.

En bonus, il décompose le décompte en sous-totaux par langages (ANSI C, C++, asm, ...). voir http://www.dwheeler.com/sloccount/ (ok, pour l'utiliser sous Windows, il faut Cygwin, mais il existe des outils équivalents et natifs, voir par ex. sur http://www.qsm.com/CodeCounters.html ou http://www.programurl.com/code-counter-pro.htm ).

[ Répondre ]

C'est déjà le cas. Il y a dans le noyau, depuis la version 2.6.19 (ou 2.6.20 ?) les fonctions round_jiffies() et round_jiffies_relative() qui arrondissent à la seconde pleine les valeurs de jiffies passées en argument.

L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».

Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).

Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.

Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().

[ Répondre ]

> entre parenthèse la liste des régressions du 2.6.22 me semble minuscule par rapport à l'ampleur des changements

Remarque qu'il ne s'agit que des régressions connues : le noyau est toujours mieux testé juste après la sortie d'une nouvelle version (malheureusement !). Et il ne s'agit (presque) que de régressions, les bugs touchant des nouvelles fonctionnalités ou architectures ne sont pas des régressions. Pendant la phase de développement cette liste a été très longue, par moments. Elle a effectivement été sérieusement réduite (preuve, peut-être, de son efficacité : les problèmes n'ont pas été négligés).

Je suis moins optimiste en ce qui concerne l'ancienne couche Wi-Fi : je n'ai pas l'impression que qui que ce soit travaille à l'adaptation des pilotes prism2.5 ou encore ipw2200, par exemple. Peut-être parce que mac80211 n'est (ou du moins n'était, récemment) pas encore tout à fait adapté aux chipsets fullmac (me semble-t-il avoir lu, je ne suis pas 100% sur que ce soit toujours vrai), et qu'il suffira d'attendre quelques mois de maturation. Peut-être aussi parce qu'il est difficile de restructurer complètement un logiciel éprouvé par le temps sans causer de grosses régressions.

Mais il ne faut pas oublier qu'un certain nombre d'entre eux furent développées en interne par des sociétés commercialisant le chipset mais ne donnant pas les specs, ou sous NDA seulement, et qu'Intel, par exemple, n'a aucune envie de consacrer des ressources pour re-développer un produits qu'ils ne vendent plus, alors qu'il est tellement plus simple d'encourager les utilisateurs à changer de matériel. Quand on disait que « donner les specs, sans NDA, c'est beaucoup mieux que donner un driver GPL » ...

[ Répondre ]

Il ne serait peut-être pas inutile d'aller voir ce que les wikipédiens ont à dire sur le sujet :

http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/9_juil(...)

J'aime en particulier la question déontologique (voir légale) soulevée par David.Monniaux : si les étudiants de Sciences Po' veulent évaluer la rapidité des services de nettoyage municipaux, ils vont graffer les murs de la ville ? S'ils veulent tester la rapidité de la police, vont-ils voler des sacs à main ?

Sinon, notez que Pierre Assouline est acharné détracteur de Wikipédia, de longue date, et qu'il est journaliste (ce qui explique probablement que Libé se fasse echo d'un simple exposé d'étudiants peu sérieux, copinages, ...).

[ Répondre ]

Maintenant que la liste des régression connues est maintenue sur un site web, ce serait bien d'inclure le lien dans les dépêches relatives à la sortie de nouvelles versions du noyau : http://kernelnewbies.org/known_regressions

Quelques précisions et compléments d'informations, en vrac :
* Puisqu'on parle de la liste des régressions. Adrian Bunk maintenait une telle liste durant les derniers mois, qu'il postait chaque semaine sur LKML. Fâché de l'insuccès de son travail (il considère que le 2.6.21 n'aurait pas du sortir en l'état), Bunk a décidé d'abandonner cette tache ingrate, au grand dam des autres développeurs (y compris de Linus) (cf. http://kerneltrap.org/node/8110 ). À cette occasion Google a rappelé qu'ils cherchent à embaucher un « bug master » pour le noyau Linux. Finalement Michal Piotrowski a pris les choses en main et maintient une liste des régression dans un wiki (à l'adresse citée plus haut).

* La nouvelle couche Wi-Fi (<- ça s'écrit comme ceci en fait) s'appelle mac80211 (ou encore d80211). Outres les fonctionnalités citées dans la dépêche, elle mutualise une implémentation MAC logicielle commune pour les divers pilotes, souvent nécessaire avec les chipsets modernes et sots, dits « softmac ». Son intégration dans le noyau standard a parait-il permis de la stabiliser, et simplifiera grandement l'intégration des pilotes récents (nombreux sont ceux qui l'utilisait déjà auparavant, bien qu'elle n'était pas incluse dans le noyau), comme iwlwifi (Intel 4965AGN), les pilotes ralink rt2x00, le nouveau pilote pour le chipset Marvel Libertas, le Broadcom bcm43xx, et bien d'autres. L'ancienne couche Wi-Fi (qui s'appelle ieee80211) est conservée dans le noyau (de nombreux « vieux » pilotes l'utilisent). La perspective d'une telle cohabitation - et du travail de maintenance qui s'en trouve doublé - fut la cause de nombreux débats sur les listes de diffusion. Remarquez aussi que l'API de configuration WEXT du ieee80211 est rendue obsolète par le nouveau mécanisme nommé cfg80211, basé sur netlink (API nl80211). Une couche de compatibilité est toutefois maintenue (avec l'aide, si je me souviens bien, d'une bibliothèque en espace utilisateur).

* La nouvelle couche FireWire (<- ça s'écrit ainsi) est certes plus dense (moins de lignes de codes) mais n'est pas tout à fait complète encore. Par exemple l'eth1394 (émulation ethernet sur FireWire) n'est pas encore porté, si vous utilisez cette fonctionnalité, attendez encore un peu.

[ Répondre ]

Salut,

Une question me chiffonne depuis le début de ce projet : la seule indication de licence sur le contenu, c'est "Copyright © 2007 Frederic Lepied. All Rights Reserved. ", en bas des pages.

Ainsi, pour le moment, toutes nos contributions t'appartiennent, et le contenu n'est pas libre.

[ Répondre ]

Matt Dillon est le « Linus Torvalds » (ou le « Theo de Raadt » si vous préférez, bref, le lead developer quoi) de DragonFlyBSD et fut un de contributeurs majeur de la VM de FreeBSD (travaille qui le qualifie justement pour évaluer l'impact de certains de ces bugs), cf. http://en.wikipedia.org/wiki/Matt_Dillon_%28computer_scienti(...)

Il a livré un rapide commentaire sur les principaux bugs dévoilés dans les récentes erratas d'Intel :

- Ici, celles dont parle spécifiquement Theo (AI65, AI79, AI43, AI39, AI90 et AI99) :
http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)

- Ici celles concernant les Core 2, dont ne parle pas vraiment le message de TdR (en dépit du titre de son email) :
http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)
(et qui font dire à Dillon, au sujet des core/core2 duo : « So, in summary, AE3 scares the hell out of me, and for the others AE5, AE8, AE21, and AE30 look serious. »).

Notez que les descriptions des problèmes dans l'errata d'Intel semblent souvent très vagues (d'où des incertitudes dans l'appréciation des conséquences possibles, selon les développeurs).

Concernant la possibilité de corriger ces problèmes par upgrade du microcode, donnez vous la peine de regarder le pdf d'Intel : la plupart de ces bugs sont marqués : "Plan : No Fix".

À ce sujet, voici l'errata d'Intel au sujet des Core 2 :
http://download.intel.com/design/processor/specupdt/31327914(...)

Et celle au sujet des Core Duo et Core Solo :
http://download.intel.com/design/mobile/SPECUPDT/30922211.pd(...)

[ Répondre ]

dans le cas des core2duo, la mise a jour pour corriger les bugs étaient relativement aisé

À condition que tout ces problèmes soit corrigeables par mise à jour du microcode.

Lorsqu'on parle de la nécessité de mettre à jour le BIOS, dans notre cas, il peut s'agir seulement de ça (le BIOS contenant aussi le microcode, et donc là pas de problème on sait aussi le mettre à jour depuis l'OS), ou bien d'un changement ou d'un workaround pour contourner le bug très différent (le BIOS, ce n'est pas que le microcode hein).

[ Répondre ]

A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?

Ce n'est généralement pas comme ça qu'on procède dans le domaine de la sécu informatique : on parle des bugs connus (« n'utilisez pas le produit x version y pour faire telle chose, il présente des déficiences notable sur le plan sécurité »). Ne serait-ce que pour encourager ceux qui maintiennent le produit à corriger leur failles prompto (et à tacher d'éviter d'en faire d'autres du même genre la prochaine fois), ou permettre à ceux qui utilisent le produit de ne pas tomber dans le cas d'utilisation qui expose le problème. Le boulot des journalistes et des professionnels de la sécurité informatique est de nous avertir pour faire bouger les choses : Cyrix, qui produisait des procs sensiblement buggués en sait quelque chose : ils l'ont senti passer, et heureusement qu'on n'a pas gardé le silence.

Deuxièmement, on parle ici d'un type de bugs un peu particulier, surtout pour le monde du matériel : ce sont des bugs ayant un potentiel fort d'impact sur la sécurité.

Concernant les hypothétiques mais probables bugs « dont on ne sait rien », on peut bien sûr se perdre en conjectures... mais est-ce bien utile ? ça ne l'est surement pas s'il s'agit de dédouaner ceux dont les bugs sont connus !

Tout les cores aussi complexe que les x86 ont forcement des bugs

Et ? faut-il s'abstenir de faire état des problèmes dont on apprend l'existence ? Tu imagine si nous réagissions comme ça pour le logiciel « (n'en parlons pas | ne jetons pas la pierre ) parce que tout logiciel de plus de 1000 lignes contient forcément des bugs » ?

Certains fournisseurs ne publient pas les bugs

Souhaitons que quelques bonnes vieilles full disclosure vienne leur boter le train. Encore une fois, le précédent de Cyrix devrait les inciter à la prudence (je pense à ce sujet qu'AMD est méchamment sur le déclin, et depuis leur rachat d'ATI ils sont sur ma liste noire de constructeurs travaillant comme des cochons, ne filant ni specs ni code libre pour leurs chipsets).

[ Répondre ]

>> tu peux avoir besoin d'interagir avec des modules sous licence incompatibles

> ah, oui effectivement, ça peut être gênant avec la licence PHP c'est ce à quoi tu penses ?

J'ai pensé à ça immédiatement aussi, et aux licences de PEAR et à celle de python, ... mais surtout à la GPLv2. Avec autant de restrictions, ça va être difficile d'utiliser AGPL.

Je ne comprend pas ton argument plus haut, où tu me répond que restreindre la compatibilité à la "v3 ou plus" seulement (au lieu de v2 ou plus) simplifie les choses.

Si des développeurs choisissent la GPLv2 plutôt que la GPLv3, c'est peut être pas par « misunderstandings », comme dirait Eben Moglen, mais peut-être parce que le code était là avant la v3, ou par choix personnel en toute conscience. Tenter de leur forcer la main en créant une incompatibilité arbitraire et articifielle... c'est vraiment les prendre pour des cons.

[ Répondre ]

Mais on parle bien de critiques venant de « libristes » : Linus (quand même), et même mes modestes réserves (pas vraiment des critiques), à moins que tu ne me considère comme un social-traitre (pas très sympa) ?

Personnellement je pense qu'adopter une lecture critique - sans refreiner son enthousiasme lorsqu'on a pesé les arguments - est salutaire. Une lecture critique, ce n'est pas une contestation, ce n'est pas diminuer la grandeur de nos leaders (la FSF, Linus, ...), c'est simplement se réserver le droit de penser par soi même. La FSF mérite mieux que des gens qui accepterai tout sans réfléchir.

> - ils partagent le même idéal, mais ne sont pas d'accord avec la méthode utilisée.

C'est tout à fait ce que je voulais dire, entre linuxfriens nous partageons généralement les mêmes idéaux, mais il n'y a pas de raisons que nous ne discutions pas de la méthode adaptée pour y parvenir.

> (l'exemple de Bush était peut-être un peu trop fort), mais d'opinions et d'idéaux.

Dans ce très récent et très intéressant thread :
http://kerneltrap.org/node/8382
Linus Torvalds utilise aussi l'administration Bush pour une métaphore :


And then the FSF has the gall to call themselves the "protector of
freedoms", and claim that everybody else is evil. What a crock.
[...]
I don't know if you've followed US politics very much over the last six
years, but there's been a lot of "protecting our freedoms" going on. And
it's been ugly. Maybe you could realize that sometimes "protecting your
freedom" is *anything*but*!
Linus

[ Répondre ]

Un autre aspect de cette clause 13 que je trouve très mesquin et politique, c'est celui-ci :

« Notwithstanding any other provision of this License, you have permission to link any covered work with a work licensed under version 3 (or any later version published by the Free Software Foundation) of the GNU General Public License, and to convey the resulting combination. »

Ils auraient pu donner le droit de « linker » le logiciel avec du code sous « GPLv2 or any later version » ; le fait de spécifier le plancher à la v3 me semble une façon franchement mesquine de pousser leur agenda politique en faveur de la GPLv3, de forcer la main (exactement à la façon de http://lwn.net/Articles/176582/ ).

[ Répondre ]

Tu a raison, et j'ai été un peut vite. Il faudrait dire « ton code sera _potentiellement_ sous une licence que tu n'a pas choisi ».

Concrètement, le problème se posera très probablement lorsqu'un mainteneur d'un logiciel acceptera un patch ajoutant du code « GPLv3 ou plus » (dans ce cas, l'ensemble du logiciel devient « GPLv3 ou plus »), ou lorsqu'un autre logiciel, sous v3, intègrera ton code dans son logiciel sous GPLv3 (ce code sera alors considéré « v3 », et tu ne pourra récupérer ses modifications qu'à condition de migrer ton projet en v3).

Des conflits potentiels de ce type se dessinent aujourd'hui. Par exemple : je lis régulièrement la mailing-list de busybox. L'initiateur de ce projet, Bruce Perens, avait choisi une licence "v2 ou plus", mais a quitté le projet depuis plus de 5 ans (et en pratique, on ne retrouve quasiment plus rien de son code initial dans le code actuel). Les développeurs actuels n'aiment pas du tout la v3 et ont voulu indiquer que l'ensemble du projet serait désormais "v2 only". C'est ce moment qu'a choisi Perens pour revenir sur les mailing-lists, non pas pour aider avec le code, mais pour indiquer qu'il s'opposait à cette décision. Il a d'abord tenté de convaincre les développeurs que leur décision était illégale, a échoué, et a finalement annoncé qu'il forkerait le busybox sous v3. Beaucoup de conflits, de développeurs actifs dégoutés ou ulcérés, certains ont abandonné le projet parce que la pression _politique_ de la FSF et de Perens leur tapait sur le système ...

Même pression politique ici : http://lwn.net/Articles/176582/ . La FSF interdit désormais les projets "v2 only" sur Savannah. Pression politique (au sens anglais « politic agenda ») sur les devs kernel et Linus en particulier (voir l'exemple récent dans le lien ci-dessous, http://kerneltrap.org/node/8382 ) où l'on tente (mais de quel droit ?), à répétition, de convaincre Linus de passer en v3 en arguant qu'il « n'a pas compris » (ce qui est gonflé). Ce forcing « politique » montre que la FSF, plutôt que de chercher le consensus pour la nouvelle GPL, ou de refléter et considérer les remarques des développeurs, les premiers concernés, tente de faire passer ses décisions et ses choix de force. La prudence s'impose, donc.

[ Répondre ]