L'idée que Debian puisse envisager un « compromis avec la liberté » pourrait décevoir certains, mais il ne faut pas surévaluer le problème : il ne s'agit pas de rendre Debian peu à peu non libre, ou de commencer à intégrer n'importe quel logiciel dans main.
En fait le cas des firmwares est spécifique, pour au moins trois raisons :
1) Le cas des firmwares est spécifique. Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal, mais dans le matériel ; les problèmes habituels des drivers proprios : de sécurité (backdoors etc.), d'évolution de l'OS (freinée par les drivers propriétaires), de stabilité du système (fragilisée), de maintenabilité etc. ne se posent pas spécifiquement. Lorsque vous achetez (ou vendez) un ordinateur domestique, il contient généralement une foultitude de tels firwmares déjà intégrés dans le matériel. Tout le monde s'accommode de ça, faute de choix (achèteriez vous un PC sans son bios ?) ; mais de nos jours, pour économiser une peu de ROM, les fabriquants préfèrent de plus en plus fréquemment que les firmwares soient chargés dans le matériel à la volée par l'OS plutôt qu'intégrés d'emblée dans une puce.
Cette proposition ne se résume donc pas a un « nous voudrions faire admettre n'importe quel logiciel non libre dans main, celui-ci est un candidat parce qu'il est très utile ». Pour preuve, si l'acceptation des firmwares est proposée, ce n'est pas le cas pour les drivers non libres (nVidia, ATI, ...).
En somme, on pourrait comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels : on (les distros Linux, le site gnu.org, Wikipédia ...) ne refuse pas d'intégrer une image sous prétexte qu'elle n'est pas fournie avec ses fichiers « sources » de développement (PSD Photoshop, XCD Gimp, photos initiales ...), ce qui importe c'est le droit de réutilisation et redistribution (et éventuellement modification).
2) En pratique, outre la question de l'utilisabilité d'un OS sans les firmwares adaptés au matériel, un autre problème se pose pour Debian : le fait d'enlever les firmwares binaires du kernel demande beaucoup de ressources et de temps, des compétences précieuses (devs. kernel) et c'est une opération a réitérer à chaque mise à jour. En bref, cette tache ralentie fortement le projet. Par exemple le choix du kernel d'Etch (2.6.17 ou 2.6.18) est fortement subordonné à cette question (pas le temps d'intégrer 2.6.18 s'il faut enlever les firmwares avant de le tester dans sid).
3) Le code source des firmwares en question serait probablement bien souvent inexploitable avec les outils (la toolchain) GNU car les microgiciels sont souvent développés avec des environnements de dev. propriétaires (donc quand bien même nous disposerions des sources, nous ne pourrions pas facilement construire les packages binaires à partir d'elles, c'est le fameux « ftbfs »).
La question fréquemment évoquée à ce sujet est celle de l'utilisabilité d'un OS qui ne peut pas s'installer sur son contrôleur SCSI (ou SATA, RAID ...), ou qui ne peut pas initialiser les cartes réseau, à une époque où les firmwares externes (chargés par l'OS) deviennent la nouvelle norme. Vous voyez, ce n'est pas la seule question à se poser.
# Pondération
Posté par herodiade . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 10.
En fait le cas des firmwares est spécifique, pour au moins trois raisons :
1) Le cas des firmwares est spécifique. Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal, mais dans le matériel ; les problèmes habituels des drivers proprios : de sécurité (backdoors etc.), d'évolution de l'OS (freinée par les drivers propriétaires), de stabilité du système (fragilisée), de maintenabilité etc. ne se posent pas spécifiquement. Lorsque vous achetez (ou vendez) un ordinateur domestique, il contient généralement une foultitude de tels firwmares déjà intégrés dans le matériel. Tout le monde s'accommode de ça, faute de choix (achèteriez vous un PC sans son bios ?) ; mais de nos jours, pour économiser une peu de ROM, les fabriquants préfèrent de plus en plus fréquemment que les firmwares soient chargés dans le matériel à la volée par l'OS plutôt qu'intégrés d'emblée dans une puce.
Cette proposition ne se résume donc pas a un « nous voudrions faire admettre n'importe quel logiciel non libre dans main, celui-ci est un candidat parce qu'il est très utile ». Pour preuve, si l'acceptation des firmwares est proposée, ce n'est pas le cas pour les drivers non libres (nVidia, ATI, ...).
En somme, on pourrait comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels : on (les distros Linux, le site gnu.org, Wikipédia ...) ne refuse pas d'intégrer une image sous prétexte qu'elle n'est pas fournie avec ses fichiers « sources » de développement (PSD Photoshop, XCD Gimp, photos initiales ...), ce qui importe c'est le droit de réutilisation et redistribution (et éventuellement modification).
2) En pratique, outre la question de l'utilisabilité d'un OS sans les firmwares adaptés au matériel, un autre problème se pose pour Debian : le fait d'enlever les firmwares binaires du kernel demande beaucoup de ressources et de temps, des compétences précieuses (devs. kernel) et c'est une opération a réitérer à chaque mise à jour. En bref, cette tache ralentie fortement le projet. Par exemple le choix du kernel d'Etch (2.6.17 ou 2.6.18) est fortement subordonné à cette question (pas le temps d'intégrer 2.6.18 s'il faut enlever les firmwares avant de le tester dans sid).
3) Le code source des firmwares en question serait probablement bien souvent inexploitable avec les outils (la toolchain) GNU car les microgiciels sont souvent développés avec des environnements de dev. propriétaires (donc quand bien même nous disposerions des sources, nous ne pourrions pas facilement construire les packages binaires à partir d'elles, c'est le fameux « ftbfs »).
La question fréquemment évoquée à ce sujet est celle de l'utilisabilité d'un OS qui ne peut pas s'installer sur son contrôleur SCSI (ou SATA, RAID ...), ou qui ne peut pas initialiser les cartes réseau, à une époque où les firmwares externes (chargés par l'OS) deviennent la nouvelle norme. Vous voyez, ce n'est pas la seule question à se poser.