Oui, j'ai l'impression que le débat (sur les m-l Debian) porte maintenant sur le choix entre ces deux alternatives :
1- Soit ils autorisent les fw librement distribuables une bonne fois pour toute (tout en réaffirmant qu'ils préféreraient avoir les sources)
2- Soit ils les autorisent provisoirement dans main pour Etch et juste après la release, ils travaillent à les déplacer dans non-free.
L'option « pas de fw du tout, même dans non-free » semble n'avoir pas beaucoup de supporters en fait.
Cela dit, je trouve à titre tout à fait personnel que la seconde option (révision après Etch) est un pinaillage très coûteux (voir hypocrite), qui, en pratique, n'améliore pas la « liberté » des fw et n'aide pas les LL (au contraire):
- Les déplacer dans non-free c'est encore les supporter un peu, au sens d'en faciliter l'utilisation. D'ailleurs, tourner sur les machines réelles (pécés i386, Apple ppc etc.) qui contiennent des « logiciels non libres » (fw, bioses) déjà intégrés au chipset c'est aussi supporter ces machines (et les logiciels qu'elles contiennent). Bref, une solution si coûteuse ne nous absoudrai pas pour autant ;)
- Personne ne propose la « libération » des fw. La solution 2 préconise seulement de « cachez ce fw que je ne saurai voir, mais cachez le à portée de main pour que je puisse quand même l'utiliser ».
- Les problèmes techniques sont intenses (si on met les fw sur un média séparé, cela suppose que la machine peut accéder au média - pas bon pour le netboot et pas bon s'il faut justement le fw pour accéder au média). Le travail des devs. kernels et des gens qui développent l'installeur serai alors lourdement bloqué pour régler ces questions (+ extraire les fw du kernel, corriger les bugs que ça amène, etc.) au lieu de s'occuper d'autres choses utiles.
- Rendre Linux plus difficile a installer et à utiliser n'aide pas les LL. Dans ce cas précis il est hautement improbable qu'un tel lobbying Debian parvienne à faire fléchir (libérer les sources) un seul vendor. D'une part parce qu'il existera des solutions « de secours », même bancales (fw dans non-free), d'autre part parce que toutes les autres distros et même le kernel vanilla/standard tolèrent la situation comme un pi allé, et enfin parce qu'on aura du mal à répondre a un vendor qui dirait « et bien pourquoi acceptez vous des bios et fw non libres dans le matériel ? ». Si encore cette stratégie permettait d'obtenir la libération des fw ... mais non, tout ce qu'elle va faire, c'est occuper des précieux et bénévoles devs. du libre à bidouiller des solutions mi figue mi raisin au lieu de coder du libre (et, je parie, un autre vote identique avant la release de Etch+1 pour constater qu'il faut de nouveau reporter).
- La position de Debian serait alors très difficile parce que l'upstream (le kernel Linux dans ce cas) a choisi de tolérer ces fw, et envoient bouler les devs Debian lorsqu'ils relancent ce sujet sur LKML. Il leur faudra donc maintenir un fork au fur et à mesure plus déviant de l'upstream, du kernel Vanilla.
- Et surtout, ce parti pris néglige un point important, à savoir que la grande majorité des gens vraiment concernés par cette décision, les devs. kernel de Debian, généralement bénévoles, n'ont pas envie de le faire. D'ailleurs ce débat arrive justement parce que le parti pris « tout les firmwares non libres hors de main », un des objectifs pour Etch, ne semble pas pouvoir être atteint dans les temps (c'est un euphémisme, en fait le plus gros du travail reste à faire), simplement parce que les « philosophes donneurs de leçons sur le libre » des ML Debian ne sont pas les mêmes que ceux qui font le gros du boulot sur le kernel (à de rares exceptions près).
nous avons eu ce boulot à faire sur eagle-usb, cela a par la suite permis d'avoir ueagle-atm qui est beaucoup plus propre grâce à Matthieu et le pilote de Damien Bergamini pour *BSD.
Ne pas confondre, le taf de Bergamini (et je crois aussi sur les modem eagle, à confirmer) n'est pas ce dont il est question : ils ont transformé des drivers non libres en "driver libre + fw/microcode non libre". Là dessus on est tous d'accord, rien ne change : pas de driver non libres.
l'argument récurrent (et trollesque) de Marco d'Itri (en résumé "on s'en fout, libre ou pas, vu que le firmware ne tourne pas sur le même CPU que le noyau linux")
En fait j'ai été convaincu de la pertinence de cet argument par l'exposé de Theo de Raadt (leader d'OpenBSD), je ne connais la position de d'Itri que depuis récemment.
L'argument « on supporte les machines incluant un fw ou bios non libre, et on supporte et distribue les fw non libres via le dépôt non-free » (donc un changement minime sur le plan éthique, voir un peu hypocrite, mais très lourd et au mépris du coût en stabilité et temps de mise en oeuvre), est-il moins trollesque ?
Marco d'Itri est justement un des développeurs kernel de Debian les plus actifs, il est certainement bien au fait du coût d'une telle décision. Le fait qu'il tourne sur une autre CPU fait que ça n'affecte pas le fonctionnement de son Linux bien libre (de même qu'on accepte depuis toujours d'utiliser des bios non libres déjà inclus dans nos pécés, des firmwares non libres dans nos périphériques etc.). C'est donc une différence importante.
Et en aucun cas je crois qu'il ne dit : « on s'en fout libre ou pas ». J'ai plutôt compris ses quelques mails (peux verbeux) comme : « nous n'avons pas les moyens d'un voie alternative, et le problème est mineur ». Mais je suis convaincu qu'il préfère lui aussi les fw libres (tout comme les devs. du noyau Linux, qui ont pourtant toléré l'inclusion de certains de ces fw).
Cette question a trois faces distinctes, il est préférable de ne pas les mélanger et de les considérer toutes pour bien aborder le problème :
- technique (difficulté de séparer les fw, difficulté d'utiliser Debian avec des fw séparés, difficulté de maintenir ça ...)
- éthique (ça c'est le point sensible/émotionel des débats je crois, et pourtant, dans ce cas précis, je crois qu'il devrait passer après les deux autres)
- juridique (peu abordé ici, mais important : que faire si qqun demande les sources d'un fw non libre inclus dans le kernel, donc de facto soumis à la GPL + évidement le fait qu'il faut tout de même trier les fw qu'on a le droit de redistribuer ou pas - qu'ils soient libres ou pas).
Et ne pas oublier qu'on est tous d'accord sur ce point : « si c'est libre, c'est mieux » (ton commentaire semblait dire : ceux qui acceptent une telle concession sont indifférents au libre).
[^] # Re: Pondération
Posté par herodiade . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 6.
1- Soit ils autorisent les fw librement distribuables une bonne fois pour toute (tout en réaffirmant qu'ils préféreraient avoir les sources)
2- Soit ils les autorisent provisoirement dans main pour Etch et juste après la release, ils travaillent à les déplacer dans non-free.
L'option « pas de fw du tout, même dans non-free » semble n'avoir pas beaucoup de supporters en fait.
Cela dit, je trouve à titre tout à fait personnel que la seconde option (révision après Etch) est un pinaillage très coûteux (voir hypocrite), qui, en pratique, n'améliore pas la « liberté » des fw et n'aide pas les LL (au contraire):
- Les déplacer dans non-free c'est encore les supporter un peu, au sens d'en faciliter l'utilisation. D'ailleurs, tourner sur les machines réelles (pécés i386, Apple ppc etc.) qui contiennent des « logiciels non libres » (fw, bioses) déjà intégrés au chipset c'est aussi supporter ces machines (et les logiciels qu'elles contiennent). Bref, une solution si coûteuse ne nous absoudrai pas pour autant ;)
- Personne ne propose la « libération » des fw. La solution 2 préconise seulement de « cachez ce fw que je ne saurai voir, mais cachez le à portée de main pour que je puisse quand même l'utiliser ».
- Les problèmes techniques sont intenses (si on met les fw sur un média séparé, cela suppose que la machine peut accéder au média - pas bon pour le netboot et pas bon s'il faut justement le fw pour accéder au média). Le travail des devs. kernels et des gens qui développent l'installeur serai alors lourdement bloqué pour régler ces questions (+ extraire les fw du kernel, corriger les bugs que ça amène, etc.) au lieu de s'occuper d'autres choses utiles.
- Rendre Linux plus difficile a installer et à utiliser n'aide pas les LL. Dans ce cas précis il est hautement improbable qu'un tel lobbying Debian parvienne à faire fléchir (libérer les sources) un seul vendor. D'une part parce qu'il existera des solutions « de secours », même bancales (fw dans non-free), d'autre part parce que toutes les autres distros et même le kernel vanilla/standard tolèrent la situation comme un pi allé, et enfin parce qu'on aura du mal à répondre a un vendor qui dirait « et bien pourquoi acceptez vous des bios et fw non libres dans le matériel ? ». Si encore cette stratégie permettait d'obtenir la libération des fw ... mais non, tout ce qu'elle va faire, c'est occuper des précieux et bénévoles devs. du libre à bidouiller des solutions mi figue mi raisin au lieu de coder du libre (et, je parie, un autre vote identique avant la release de Etch+1 pour constater qu'il faut de nouveau reporter).
- La position de Debian serait alors très difficile parce que l'upstream (le kernel Linux dans ce cas) a choisi de tolérer ces fw, et envoient bouler les devs Debian lorsqu'ils relancent ce sujet sur LKML. Il leur faudra donc maintenir un fork au fur et à mesure plus déviant de l'upstream, du kernel Vanilla.
- Et surtout, ce parti pris néglige un point important, à savoir que la grande majorité des gens vraiment concernés par cette décision, les devs. kernel de Debian, généralement bénévoles, n'ont pas envie de le faire. D'ailleurs ce débat arrive justement parce que le parti pris « tout les firmwares non libres hors de main », un des objectifs pour Etch, ne semble pas pouvoir être atteint dans les temps (c'est un euphémisme, en fait le plus gros du travail reste à faire), simplement parce que les « philosophes donneurs de leçons sur le libre » des ML Debian ne sont pas les mêmes que ceux qui font le gros du boulot sur le kernel (à de rares exceptions près).
nous avons eu ce boulot à faire sur eagle-usb, cela a par la suite permis d'avoir ueagle-atm qui est beaucoup plus propre grâce à Matthieu et le pilote de Damien Bergamini pour *BSD.
Ne pas confondre, le taf de Bergamini (et je crois aussi sur les modem eagle, à confirmer) n'est pas ce dont il est question : ils ont transformé des drivers non libres en "driver libre + fw/microcode non libre". Là dessus on est tous d'accord, rien ne change : pas de driver non libres.
l'argument récurrent (et trollesque) de Marco d'Itri (en résumé "on s'en fout, libre ou pas, vu que le firmware ne tourne pas sur le même CPU que le noyau linux")
En fait j'ai été convaincu de la pertinence de cet argument par l'exposé de Theo de Raadt (leader d'OpenBSD), je ne connais la position de d'Itri que depuis récemment.
L'argument « on supporte les machines incluant un fw ou bios non libre, et on supporte et distribue les fw non libres via le dépôt non-free » (donc un changement minime sur le plan éthique, voir un peu hypocrite, mais très lourd et au mépris du coût en stabilité et temps de mise en oeuvre), est-il moins trollesque ?
Marco d'Itri est justement un des développeurs kernel de Debian les plus actifs, il est certainement bien au fait du coût d'une telle décision. Le fait qu'il tourne sur une autre CPU fait que ça n'affecte pas le fonctionnement de son Linux bien libre (de même qu'on accepte depuis toujours d'utiliser des bios non libres déjà inclus dans nos pécés, des firmwares non libres dans nos périphériques etc.). C'est donc une différence importante.
Et en aucun cas je crois qu'il ne dit : « on s'en fout libre ou pas ». J'ai plutôt compris ses quelques mails (peux verbeux) comme : « nous n'avons pas les moyens d'un voie alternative, et le problème est mineur ». Mais je suis convaincu qu'il préfère lui aussi les fw libres (tout comme les devs. du noyau Linux, qui ont pourtant toléré l'inclusion de certains de ces fw).
Cette question a trois faces distinctes, il est préférable de ne pas les mélanger et de les considérer toutes pour bien aborder le problème :
- technique (difficulté de séparer les fw, difficulté d'utiliser Debian avec des fw séparés, difficulté de maintenir ça ...)
- éthique (ça c'est le point sensible/émotionel des débats je crois, et pourtant, dans ce cas précis, je crois qu'il devrait passer après les deux autres)
- juridique (peu abordé ici, mais important : que faire si qqun demande les sources d'un fw non libre inclus dans le kernel, donc de facto soumis à la GPL + évidement le fait qu'il faut tout de même trier les fw qu'on a le droit de redistribuer ou pas - qu'ils soient libres ou pas).
Et ne pas oublier qu'on est tous d'accord sur ce point : « si c'est libre, c'est mieux » (ton commentaire semblait dire : ceux qui acceptent une telle concession sont indifférents au libre).