Le procès antitrust contre Microsoft, propositions de la FSF

Avec le dénouement proche du procès antitrust contre Microsoft, se pose la question de ce qu'on doit exiger d'elle, si elle perd. Ralph Nader est même sur le point d'organiser une conférence à ce sujet [à la date où cet article a été écrit, en mars 1999] (voir appraising-microsoft.org/).

Les réponses évidentes (restreindre les contrats entre Microsoft et les constructeurs d'ordinateurs ou démembrer la société) ne feront pas une différence déterminante. La première réponse pourrait favoriser la mise sur le marché de machines avec un système GNU/Linux pré-installé, mais c'est ce qui se produit de toute façon. L'autre encouragerait surtout d'autres développeurs d'applications privatrices¹ à s'affirmer, ce qui ne ferait que proposer à l'utilisateur final des alternatives pour renoncer à sa liberté.

Je propose donc trois mesures qui permettraient aux systèmes d'exploitation libres comme GNU/Linux de s'affirmer comme alternative technique, tout en respectant la liberté des utilisateurs. Ces trois mesures sont directement destinées à régler les trois plus gros obstacles au développement de systèmes d'exploitation libres et à leur donner la capacité de faire tourner des programmes écrits pour Windows. De plus, elles répondent directement aux méthodes décrites par Microsoft (dans les « documents de Halloween ») pour faire obstacle au logiciel libre. Le plus efficace serait d'utiliser les trois à la fois.

1. Exiger de Microsoft qu'elle publie une documentation complète sur toutes ses interfaces entre composants logiciels, sur tous ses protocoles de communication et sur tous ses formats de fichiers. Cela bloquerait l'une de ses tactiques favorites : développer des interfaces secrètes et incompatibles.

   Pour que cette exigence soit vraiment incontournable, on ne doit pas permettre à Microsoft de se servir d'un accord de confidentialité avec une autre organisation comme excuse pour développer une interface secrète. La règle doit être que si elle ne peut publier l'interface, elle ne peut distribuer aucun logiciel qui la mette en œuvre.

   Cependant, il serait acceptable que Microsoft lance l'implémentation d'une interface avant de publier ses spécifications, pourvu qu'elle publie les spécifications en même temps que l'implémentation.

   S'assurer du respect de ces exigences ne serait pas difficile. Si d'autres développeurs se plaignent qu'il manque la description de certains aspects de l'interface, ou de la méthode pour faire une certaine tâche, le tribunal sommerait Microsoft de répondre à ces questions. Toute question à propos des interfaces (qu'il faut distinguer des techniques d'implémentation), devrait recevoir une réponse.

   En 1984, des conditions similaires avaient été incluses dans un accord passé entre IBM et la Communauté européenne, réglant un autre conflit antitrust. Voir cptech.org.

2. Exiger de Microsoft que, dans le domaine du logiciel, elle n'use de ses brevets que pour sa défense (s'il apparaît qu'un de ses brevets s'applique à d'autres domaines, ces derniers pourraient être inclus, ou non, dans cette exigence). Ceci bloquerait une autre des tactiques de Microsoft mentionnées dans les documents de Halloween : utiliser les brevets pour stopper le développement du logiciel libre.

   Nous devons donner à Microsoft l'option d'user, soit de l'autodéfense, soit de la défense mutuelle. L'autodéfense consiste à proposer gratuitement, pour chacun des brevets, une concession réciproque de licence à quiconque la souhaite. La défense mutuelle consiste à donner une licence sur chacun des brevets à un groupement auquel tout le monde peut se joindre (même ceux qui n'ont pas de brevets en propre). Le groupement pourrait sous-licencier tous les brevets des membres à tous les membres.

   Il est essentiel de s'attaquer au problème des brevets, car il ne sert à rien que Microsoft publie les spécifications d'une interface si elle a prévu d'y intégrer un élément breveté (ou de l'intégrer dans la fonctionnalité à laquelle elle donne accès), ce qui nous priverait du droit de la mettre en œuvre.

3. Exiger de Microsoft de ne plus certifier qu'un matériel fonctionne avec les logiciels Microsoft à moins que des spécifications complètes du matériel n'aient été publiées, ce qui permettrait à n'importe quel programmeur de créer un logiciel faisant fonctionner ce même matériel.

   Le secret sur les spécifications matérielles n'est pas en général une pratique de Microsoft, mais il représente un obstacle significatif au développement de systèmes d'exploitation libres qui puissent faire concurrence à Windows. Ôter cet obstacle serait une aide précieuse. Si un arrangement est négocié avec Microsoft, y inscrire ce genre de clause n'est pas impossible (ce serait une question de négociation).

En avril de cette année, Ballmer, de Microsoft, a annoncé qu'il envisageait de publier le code source de certains composants de Windows. On ne sait pas si cela impliquerait d'en faire des logiciels libres, ni de quels composants il s'agirait. Mais si Microsoft libère certains composants importants, cela pourrait résoudre ces problèmes pour les composants concernés (et ce serait aussi une contribution à la communauté du logiciel libre, si les logiciels en question pouvaient servir à autre chose qu'à faire tourner d'autres programmes privateurs de Microsoft).

Néanmoins, qu'on puisse utiliser comme logiciel libre un composant de Windows est moins crucial que d'être autorisé à mettre en œuvre tous ses composants. Les mesures proposées ci-dessus sont vraiment celles dont on a besoin. Elles vont nous ouvrir la voie au développement d'une alternative vraiment supérieure à Microsoft Windows pour les parties de Windows dont Microsoft ne fait pas des logiciels libres.