À la base, le firmware - traduit par Micrologiciel - cela reste du logiciel, exécuté sur un CPU ou assimilé, même si c'est celui du périphérique et non de l'unité centrale. La question de sa licence se pose dès lors qu'il est distribué.
Les constructeurs nous ont habitués jusqu'à maintenant à des licences plus folkloriques les unes que les autres (propriétaire bien sûr... voire non distribuable dans la plupart des cas) ; quitte à demander une licence distribuable (comme une Licence_BSD 2-clauses), autant pousser jusqu'à avoir le code source ET les spécifications : cela permettra la correction de bugs effectivement, améliorera ipso-facto l'interopérabilité particulièrement importante dans le domaine des périphériques et permettra de progresser vers du tout libre.
Cela bénéficie à l'utilisateur final mais aussi aux intermédiaires : bien souvent le constructeur ne fait qu'assembler des composants d'autres constructeurs, mais au final c'est bien lui qui doit s'assurer qu'il y a une intégration et une interopérabilité correcte, dans ces cas-là disposer du firmware en libre peut simplifier la situation (pourquoi embarquer un correctif dans le pilote lorsqu'il pourrait corriger le firmware ? et inversement).
À ce titre, les personnes de OpenBSD font un travail efficace pour les pilotes, à coup de rétro-ingénierie coûteuse en temps, ce qui bénéficie tant au kernel *BSD qu'à Linux. Il y a aussi le projet de Greg Kroah Hartman dont le projet [http://www.linuxdriverproject.org/twiki/bin/view] a recensé 300 développeurs prêts à travailler sur des pilotes libres si les spécifications leur sont fournies http://www.kroah.com/log/linux/linux_driver_project_status-2(...)
Re: Une précision pour un mal comprenant
Pour le Basic_Input_Output_System cela a l'air de bien avancer avec le projet linuxbios renommé en http://www.coreboot.org : il y a quelques cartes mères qui fonctionnent tout de même http://www.coreboot.org/Supported_Motherboards
À la base, le firmware - traduit par Micrologiciel - cela reste du logiciel, exécuté sur un CPU ou assimilé, même si c'est celui du périphérique et non de l'unité centrale. La question de sa licence se pose dès lors qu'il est distribué.
Les constructeurs nous ont habitués jusqu'à maintenant à des licences plus folkloriques les unes que les autres (propriétaire bien sûr... voire non distribuable dans la plupart des cas) ; quitte à demander une licence distribuable (comme une Licence_BSD 2-clauses), autant pousser jusqu'à avoir le code source ET les spécifications : cela permettra la correction de bugs effectivement, améliorera ipso-facto l'interopérabilité particulièrement importante dans le domaine des périphériques et permettra de progresser vers du tout libre.
Cela bénéficie à l'utilisateur final mais aussi aux intermédiaires : bien souvent le constructeur ne fait qu'assembler des composants d'autres constructeurs, mais au final c'est bien lui qui doit s'assurer qu'il y a une intégration et une interopérabilité correcte, dans ces cas-là disposer du firmware en libre peut simplifier la situation (pourquoi embarquer un correctif dans le pilote lorsqu'il pourrait corriger le firmware ? et inversement).
À ce titre, les personnes de OpenBSD font un travail efficace pour les pilotes, à coup de rétro-ingénierie coûteuse en temps, ce qui bénéficie tant au kernel *BSD qu'à Linux. Il y a aussi le projet de Greg Kroah Hartman dont le projet [http://www.linuxdriverproject.org/twiki/bin/view] a recensé 300 développeurs prêts à travailler sur des pilotes libres si les spécifications leur sont fournies
http://www.kroah.com/log/linux/linux_driver_project_status-2(...)
[ Répondre ]