Traductions de cette page

Le procès antitrust Microsoft et le logiciel libre

Avec le dénouement proche du procès antitrust contre Microsoft, se pose la question de ce qu'on doit demander à Microsoft, s'il 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 http://www.appraising-microsoft.org/).

Les réponses évidentes - restreindre les contrats entre Microsoft et la constructeurs d'ordinateurs ou démembrer la société - ne feront pas une différence cruciale. La première réponse pourrait encourager la disponibilité de machines avec un système GNU/Linux pré-installé, mais c'est ce qui se produit de toutes façons. L'autre encouragerait principalement d'autres développeurs d'applications propriétaires à s'affirmer, ce qui ne ferait que proposer à l'utilisateur final d'autres alternatives pour renoncer à leur liberté.

Je propose donc trois remèdes qui permettraient aux systèmes d'exploitation logiciels libres comme GNU/Linux de s'affirmer comme alternative technique, tout en respectant la liberté des utilisateurs. Ces trois remèdes sont directement destinés à 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. Ils s'occupent aussi directement des méthodes énoncées par Microsoft (dans les «Halloween documents») pour faire obstacle au logiciel libre. Il serait des plus efficace d'utiliser les trois remèdes ensemble.

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

   Pour que cette exigence soit réellement incontournable, il ne devrait pas être permis à Microsoft d'utiliser un accord de non divulgation avec d'autres organisations pour excuser le développement d'une interface secrète. La règle serait que, s'ils ne peuvent publier l'interface, ils ne peuvent en mettre une sur le marché.

   Cependant, il serait acceptable de permettre à Microsoft de commencer l'implémentation d'une interface avant la publication des spécifications de celle-ci, pourvu qu'ils mettent à disposition 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 qu'ils demandent comment faire un certain travail, le tribunal sommerait Microsoft de répondre à ces questions. Toute question à propos d'interfaces (qu'il faut distinguer des implémentations techniques), 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 : http://www.cptech.org/at/ibm/ibm1984ec.html.

2. Exiger de Microsoft qu'il n'use de ses brevets qu'en cas de défense seulement, dans le domaine du logiciel. (S'il apparaît qu'un de leurs brevets s'applique à d'autres domaines, ces derniers pourraient entrer, ou non, dans cette exigence). Ceci bloquerait une autre tactique de Microsoft mentionnée dans les «Halloween Documents» : utiliser les brevets pour stopper le développement du logiciel libre.

   Nous devrions donner à Microsoft l'option d'user soit de l'auto-défense, soit de la défense mutuelle. L'auto-défense consiste à proposer des licences croisées de tous les brevets gratuitement avec quiconque voudrait le faire. La défense mutuelle consiste à proposer une licence sur tous les brevets au sein d'un groupement auquel tout le monde peut se joindre -- même ceux qui n'ont pas de brevets en propre. Le groupe offrirait une licence sur tous les brevets des membres à tous les membres.

   Il est crucial de s'attaquer au problème des brevets, car ce n'est pas bon que Microsoft publie les spécifications d'une interface, s'ils ont prévu d'y intégrer un élément breveté (ou dans la fonctionnalité à laquelle elle donne accès), ce qui ferait que nous autres, nous n'aurions pas le droit de le mettre en oeuvre.

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 d'implémenter un logiciel pour qu'il tourne sur 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 peuvent participer à une compétition avec Windows. Ôter cet obstacle serait une aide précieuse. Si un arrangement est négocié avec Windows, y inscrire ce genre de mesure n'est pas impossible -- ce serait une question de négociation.

En avril de cette année, Ballmer, de Microsoft, a annoncé un projet possible de publication du code source de certaines parties de Windows. Il n'est pas clair si cela implique d'en faire un logiciel libre ou de quelle portion de Windows il s'agirait. Mais si Microsoft rend d'importantes portions de Windows libres, cela pourrait résoudre ces problèmes concernant ces portions. (Ce qui serait aussi une contribution à la communauté du logiciel libre, si le logiciel en question peut être utile à d'autres buts que celui de faire tourner d'autres programmes propriétaires de Microsoft).

Par contre, qu'on puisse utiliser comme logiciel libre une partie de Windows est moins crucial que d'être autorisé à implémenter toutes ses parties. Les remèdes proposés ci-dessus sont vraiment ceux dont on a besoin. Ils vont libérer la voie au développement d'une alternative vraiment supérieure à Microsoft Windows, quelque soit le champ dans lequel Microsoft ne fait pas de Windows un logiciel libre.

Autres textes à lire