[Traduit de l'anglais]

Le mouvement du logiciel libre et le projet UDI

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 doit 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 fabricants de matériel informatique. Cela permettrait de ne développer qu'un pilote pour chaque périphérique et d'en faire profiter tout le monde. Un plus haut niveau de coopération serait alors possible.

Malheureusement, dans le monde réel nous avons à la fois des développeurs de logiciels libres qui cherchent la coopération et des développeurs de logiciels privateurs1 qui cherchent la domination, avec des conséquences très différentes. En aucun cas l'utilisation d'UDI ne peut avoir d'avantage pour le mouvement du logiciel libre. Son seul effet éventuel serait de nous diviser et nous affaiblir.

Quelles seraient les conséquences pour nous si Linux gérait UDI et si nous commencions à concevoir de nouveaux pilotes pour communiquer avec Linux à travers UDI ?

  • Il serait possible d'utiliser avec des systèmes Windows des pilotes Linux libres couverts par la GPL.

    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 ; 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 privateur constitue une violation de la GNU GPL. C'est chercher les ennuis que d'alimenter une telle tentation.

  • Il serait possible d'utiliser des pilotes Windows privateurs avec des systèmes GNU/Linux.

    La gamme de matériels gérés par les logiciels libres n'en serait pas directement affectée, mais cette facilité représenterait une tentation pour les millions d'utilisateurs de 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, utiliserait des pilotes privateurs 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 qu'Intel, un partisan d'UDI, ait commencé à « chercher de l'aide dans la communauté Linux pour ce projet ». 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 devons pas considérer UDI, Intel ou qui que ce soit comme un Grand Satan. Mais toute proposition devra être soigneusement étudiée afin de nous assurer que notre participation ne profitera pas uniquement aux développeurs de systèmes privateurs, mais également à la communauté du logiciel libre. Cela signifie, dans ce cas précis, d'exiger que la coopération nous fasse faire un pas de plus vers le but ultime dans le domaine des noyaux et pilotes libres : gérer tous les principaux matériels informatiques avec 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 exige de transformer tous les pilotes en logiciels libres. Cette solution serait idéale, mais d'autres sont également satisfaisantes. Par exemple, on peut simplement exiger que le code source soit publié au lieu d'être couvert par le secret industriel, car même si le pilote en question n'était pas libre, cela nous dirait au moins ce que nous aurions besoin de savoir pour écrire un pilote qui le soit.

Intel pourrait aussi, indépendamment d'UDI, aider la communauté du logiciel libre à résoudre ce problème. Par exemple, il pourrait y avoir une sorte de certification recherchée par les développeurs de matériel, qu'Intel contribuerait à délivrer. Si c'était le cas, Intel pourrait accepter de rendre cette certification plus difficile si les caractéristiques du matériel étaient gardées secrètes. Ce ne serait pas une solution parfaite du problème mais cela pourrait aider considérablement.

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. Continuerait-elle à rembourser sa dette ? Probablement oui si nous mettons tout 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 société commerciale ; il est possible que les gens avec qui nous négocions soient intègres, mais ils peuvent être désavoués par leur hiérarchie ou même remplacés n'importe quand. 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 contraignant quand on passe un accord avec une société commerciale.

Il semble improbable qu'Intel nous propose 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 notre porte à clef tant que nous faisons attention de ne pas laisser entrer n'importe qui.


Note de traduction
  1. Autre traduction de proprietary : propriétaire.