Traductions de cette page
Un projet nommé UDI (Uniform Driver Interface) vise à définir une interface normalisée entre les noyaux des systèmes d'exploitation et les pilotes de périphériques. Que devrait faire notre communauté de cette idée?
Le projet UDI serait vraiment une bonne idée à condition, d'une part, qu'il soit techniquement réalisable, et d'autre part que suffisamment de développeurs de systèmes d'exploitation coopèrent sur un pied d'égalité avec les fabriquants de matériel informatique. Cela permettrait de ne développer qu'un pilote pour chaque périphérique. Ce serait profitable à tous et un plus haut niveau de coopération serait alors possible.
Malheureusement, le monde actuel de l'informatique contient à la fois des développeurs de logiciels libres et des développeurs de logiciels propriétaires. Les uns coopèrent avec une communauté et les autres cherchent à la dominer.
Dans ce contexte, l'application du projet UDI ne peut pas profiter à la communauté du logiciel libre. Elle ne pourrait que nous diviser et nous affaiblir.
Quelles seraient plus précisément les conséquences pour nous si Linux supportait UDI et si nous commencions à concevoir de nouveaux pilotes pour communiquer avec Linux à travers UDI?
Seuls les utilisateurs de Windows en tireraient avantage. Les utilisateurs de systèmes libres que nous sommes ne pourraient rien en attendre de positif. Il est vrai qu'UDI ne nous causerait pas directement de tort en retour. Les développeurs de pilotes libres couverts par la GPL pourraient toutefois être découragés de voir leur travail utilisé de cette manière. Ce découragement constituant une grande perte. Il est également possible que l'association des pilotes à un noyau propriétaire constitue une violation de la GNU GPL. Laisser courir une telle tentation est avant tout une grande source d'ennuis.
La gamme de matériels supportés par les logiciels libres n'en sera pas directement affectée. Cette facilité représenterait toutefois une tentation pour les millions d'utilisateurs GNU/Linux qui n'ont pas compris l'importance de revendiquer la liberté pour elle-même. À terme, une baisse indirecte de l'étendue de cette gamme serait donc à craindre. On en arriverait à une situation où la communauté, commençant à accepter cette tentation, utilisera des pilotes propriétaires plutôt que d'en écrire des libres.
Le projet UDI, en lui-même, n'entraverait pas le développement de pilotes libres. Nous pourrions continuer à développer des pilotes libres malgré ce projet, comme nous le faisons actuellement; à condition toutefois qu'un nombre suffisant d'entre nous résiste à la tentation.
Pourquoi rendre la communauté plus faible que nécessaire? Pourquoi ajouter des obstacles inutiles au futur du logiciel libre? Puisque le projet UDI ne nous est pas bénéfique, il est préférable de le rejeter.
Dans ces conditions, il n'est pas surprenant que Intel, un partisan d'UDI, ait commencé à «compter sur la communauté Linux pour soutenir UDI». Quelle est l'approche d'une société riche et égoïste vis-à-vis d'une communauté basée sur la coopération? Demander l'aumône bien sûr. Ils ne risquent rien à demander et pris par surprise, nous serions bien capables de répondre oui.
Une coopération avec UDI n'est pas hors de question. Nous ne devrions pas considérer UDI, Intel ou qui que ce soit comme un Grand Satan. Mais tout accord devra être soigneusement étudié afin de s'assurer qu'il ne profitera pas uniquement aux développeurs de systèmes propriétaires, mais également à la communauté du logiciel libre. Cela signifie, dans ce cas précis, de nous faire avancer d'un pas de plus vers le but ultime dans le domaine des noyaux et pilotes libres : que tous les principaux matériels informatiques soient supportés par des pilotes libres.
Modifier le projet UDI lui-même serait une manière de rendre profitable cette coopération. Éric Raymond a ainsi suggéré que la norme UDI consiste à transformer tous les pilotes en logiciels libres. Cette solution serait idéale, mais d'autres sont également satisfaisantes. On peut, par exemple, exiger la publication du code source en dehors d'accords commerciaux exclusifs, car même si le pilote n'est pas libre, nous pourrions au moins accéder aux informations nécessaires à l'élaboration d'un pilote qui le soit.
Intel pourrait aussi, indépendamment d'UDI, aider la communauté du logiciel libre à résoudre ce problème. Intel pourrait rendre certaines certifications, dont elle contrôle la diffusion, plus complexes pour les développeurs de matériels informatiques qui gardent secrètes les caractéristiques de leurs matériels. Ce système ne constituerait pas une solution en soit mais il pourrait tout de même contribuer à résoudre notre problème.
Le problème de tout accord avec Intel sur UDI est que nous devrions faire notre part de travail dès le commencement, alors que le rôle d'Intel se prolongerait dans le temps. En clair, nous ferions crédit à Intel. Continuera-t-elle à rembourser sa dette? Probablement oui si nous posons tout accord par écrit et qu'il n'existe aucun échappatoire; sans cela, nous ne pouvons compter dessus. Il est de notoriété publique qu'on ne peut pas faire confiance à une compagnie commerciale; il est possible que les gens avec qui nous négocions soient intègres, mais l'avis de leurs chefs prévaudra toujours, et ils peuvent être remplacés un jour ou l'autre. Même un PDG qui possède la majeure partie du capital peut être remplacé à la suite d'une OPA. Il faut toujours signer un engagement écrit quand on passe un accord avec une compagnie commerciale.
Il semble improbable qu'Intel accepte un accord qui satisfasse à nos besoins. En fait, UDI semble avoir été conçu pour garder plus facilement les spécifications secrètes.
Néanmoins, il n'y a aucun mal à ne pas fermer sa porte à clef tant que nous surveillons ceux que nous laissons entrer.
Retournez à la page principale du projet GNU.
Pour les questions et requêtes relatives à la FSF & GNU : gnu@gnu.org. Autres moyens pour contacter la FSF. Merci d'envoyer des commentaires sur cette page web à webmasters@gnu.org, envoyer une autre question à gnu@gnu.org.
Copyright (C) 2000 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
La reproduction exacte et la distribution intégrale de cet article est permise sur n'importe quel support d'archivage, pourvu que cette notice soit préservée.
Dernière mise-à-jour : $Date: 2004/10/27 17:48:31 $ $Author: johnsu01 $
Traduction : ... Révision : trad-gnu@april.org