Tu as bien résumé la situation et je suis assez d'accord avec ton approche pragmatique sur les firmwares (notamment ton 3 pour du court terme).
Un bémol néanmoins, si - pour l'instant - il peut être judicieux de "comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels" comme tu le dis il ne faut pourtant pas oublier sur le long terme qu' "Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal (que j'interprète comme tu le fais : il s'agit bien en fait de logiciel, il n'y a pas trop de raison de le traiter différemment a priori que le logiciel libre).
En effet, il peut tout à fait y avoir des bugs dans ce firmware et il est intéressant d'avoir les sources libres pour avoir quelquechose de fiable (et je ne parle même pas de backdoor dans du firmware de modem...).
Après, tout reste une question de transiger (ou pas) avec la liberté sur le long terme : ce travail de libération des firmwares aura sans doute lieu, la question AMHA revient bien à "maintenant ou dans la prochaine version ?".
Avoir dans Etch l'installeur qui sait faire appel aux firmwares déjà disponibles de manière séparée du pilote, déjà dans non-free, permettra de ne pas trop ralentir les efforts faits pour la liberté.
L'étape saine adoptée sur Debian pour les pilotes non-libres (systématiquement enlevés du kernel pour ceux qui restaient et placés dans non-free) pourra (AMHA en temps utile) être adoptée sur les firmwares : déjà les séparer systématiquement du code des pilotes (utilisation de firmware_class pour le chargement notamment, ce qui permet de placer les fichiers de firmware dans le repository non -free). Il ne faut pas oublier qu'il reste pas mal de pilotes ayant des déclarations de tableaux avec des suites de chiffres hexadécimaux généralement correspondant à un firmware) et que cela réclamera effectivement un peu de boulot (pendant et après Etch) pour scinder en deux ; 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.
PS : j'ai réagi à ton post parce que ta distinction du CPU sur lequel tourne le firmware (CPU principal ou pas) me rappelle tout de même fortement 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") : c'est oublier que le firmware reste du logiciel et que la question de sa licence se pose réellement (notamment pour la distribution vu qu'il se retrouve sur une galette comme tu le dis, mais il est possible d'envisager d'aller plus loin puisqu'un firmware alternatif a son intérêt dans certains cas ; qui a parlé d'utiliser le processeur DSP des fast 800 pour faire de l'analyse de Fourier ;-) ).
[^] # Re: Pondération
Posté par BAud (site web personnel) . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 4.
Un bémol néanmoins, si - pour l'instant - il peut être judicieux de "comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels" comme tu le dis il ne faut pourtant pas oublier sur le long terme qu' "Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal (que j'interprète comme tu le fais : il s'agit bien en fait de logiciel, il n'y a pas trop de raison de le traiter différemment a priori que le logiciel libre).
En effet, il peut tout à fait y avoir des bugs dans ce firmware et il est intéressant d'avoir les sources libres pour avoir quelquechose de fiable (et je ne parle même pas de backdoor dans du firmware de modem...).
Après, tout reste une question de transiger (ou pas) avec la liberté sur le long terme : ce travail de libération des firmwares aura sans doute lieu, la question AMHA revient bien à "maintenant ou dans la prochaine version ?".
Avoir dans Etch l'installeur qui sait faire appel aux firmwares déjà disponibles de manière séparée du pilote, déjà dans non-free, permettra de ne pas trop ralentir les efforts faits pour la liberté.
L'étape saine adoptée sur Debian pour les pilotes non-libres (systématiquement enlevés du kernel pour ceux qui restaient et placés dans non-free) pourra (AMHA en temps utile) être adoptée sur les firmwares : déjà les séparer systématiquement du code des pilotes (utilisation de firmware_class pour le chargement notamment, ce qui permet de placer les fichiers de firmware dans le repository non -free). Il ne faut pas oublier qu'il reste pas mal de pilotes ayant des déclarations de tableaux avec des suites de chiffres hexadécimaux généralement correspondant à un firmware) et que cela réclamera effectivement un peu de boulot (pendant et après Etch) pour scinder en deux ; 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.
PS : j'ai réagi à ton post parce que ta distinction du CPU sur lequel tourne le firmware (CPU principal ou pas) me rappelle tout de même fortement 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") : c'est oublier que le firmware reste du logiciel et que la question de sa licence se pose réellement (notamment pour la distribution vu qu'il se retrouve sur une galette comme tu le dis, mais il est possible d'envisager d'aller plus loin puisqu'un firmware alternatif a son intérêt dans certains cas ; qui a parlé d'utiliser le processeur DSP des fast 800 pour faire de l'analyse de Fourier ;-) ).