Version classiqueVersion mobile

L’Avenir des idées

 | 
Lawrence Lessig

Première partie. Dot.communs : les biens communs et l’innovation

Chapitre 3. Biens communs et réseaux filaires

Texte intégral

1Wired (« Le Câblé ») est un magazine qui date du début de l’année 1993. Son titre est imprécis, mais il fait référence au public des gens connectés ou, comme le propose un dictionnaire en ligne, ceux qui sont « branchés » sur les technologies numériques. Pour ceux qui restent en dehors de l’univers du numérique, les câblés sont plutôt des têtes d’œuf, des technoïdes dopés à la caféine, rivés à leur écran à une heure du matin. Mais pour ceux qui sont à fond dans la culture numérique, les câblés sont ceux qui comprennent le potentiel de ce lieu qu’on appelle le cyberespace et qui font passer cette potentialité dans la réalité.

2Les caractéristiques de ce groupe ont changé. Au début des années quatre-vingt-dix, ses membres étaient plus intéressés par des logiciels rapides que par de l’argent vite gagné, mais aujourd’hui, c’est plutôt le contraire. Pourtant, s’il existe un groupe qui peut encore être qualifié de « connecté » – ceux qui ont construit l’Internet et continuent à le construire tel que nous le connaissons aujourd’hui –, c’est de ces gens que parle ce chapitre : on y traite des biens communs qu’ils partagent, et des innovations que ces biens ont permises.

3Ces biens communs sont de trois sortes. Il y a d’abord un code commun des logiciels qui ont servi à construire le Net et beaucoup des applications qui fonctionnent sur le Net. Il y a ensuite un savoir commun, la liberté d’échanger des idées et des informations sur la façon dont fonctionne le Net et le code qui ne cesse d’y circuler. Et il y a le bien commun qui résulte de l’innovation produite par la réunion des deux premiers : l’occasion offerte à tout un chacun d’innover et de créer à partir de la plate-forme constituée par le réseau.

4Tous ces biens communs ont été rendus possibles par une certaine culture, ainsi que par cet objet qu’ont produit les informaticiens, à savoir le code. Il s’agit donc de quelque chose qui a à voir avec les normes qui ont façonné cet univers, ainsi que de quelque chose d’inhérent à la nature même du code. L’objectif de ce chapitre est d’explorer à la fois la spécificité de cette culture et la nature particulière de ce code, et de voir comment leur interaction donne lieu à un espace de liberté au niveau des contenus.

5Car c’est au niveau des contenus que se situent les biens communs dont parle ce chapitre. Ceux du chapitre précédent étaient construits grâce à l’architecture end-to-end et ils se situaient au niveau de la couche logique du réseau. Cette fois-ci, même s’ils sont inscrits dans des logiciels comme ceux de la couche logique du niveau inférieur, ces biens communs se situent au-dessus. Ici le code est un contenu, et à la naissance du Net, une bonne partie de ce contenu était libre.

6Comme nous le verrons plus tard (3e partie, chapitre 3), le contenu du code n’est pas fondamentalement différent des contenus avec lesquels nous sommes plus familiers, comme la musique, les films ou les textes (du moins ceux qui sont sous forme numérique). Comme je le montrerai, dans l’environnement numérique, tout ce qui est protégé par la propriété intellectuelle fonctionne en quelque sorte selon le même principe : tout repose essentiellement sur un domaine public riche et étendu. En d’autres termes, les contenus libres d’accès sont décisifs pour construire et développer de nouveaux contenus. Le contenu libre que se partagent les « câblés » n’est qu’un exemple particulier d’un principe plus général.

7Mais pour présenter ces biens communs, il nous faut approfondir encore un peu notre réflexion sur le code. Notre univers est constitué de plus en plus par des environnements codés, à travers les instructions contenues dans des infrastructures matérielles ou logicielles. Mais notre connaissance intuitive de ce qu’est un code risque fort de se révéler insuffisante.

8Le « code » est principalement (à l’origine) écrit par des êtres humains, même si ce code qu’ils écrivent est très différent de celui que les ordinateurs utilisent pour fonctionner. Les humains écrivent des « codes sources », les ordinateurs font tourner des « codes objets ». Un code source est un assemblage assez compréhensible de langages logiques créés pour indiquer à un ordinateur ce qu’il a à faire. Un code objet est une chaîne de 0 et de 1 incompréhensible pour le commun des mortels. Mais un code source est trop difficile à faire exécuter par un ordinateur ; il doit être « compilé », à l’aide d’un « compilateur » avant de pouvoir fonctionner, c’est-à-dire qu’il doit être « traduit » d’un code compréhensible par des humains à un code compréhensible par des machines.

  • 1 chniquement, certaines de ces fonctions pourraient être obtenues si les logiciels étaient des appli (...)

9Le code objet fait donc office de sang dans les veines de l’ordinateur, mais c’est le code source qui relie l’ordinateur à l’homme. Pour comprendre comment fonctionne un logiciel, pour pouvoir le modifier peu ou prou, pour lui donner une plus grande portée ou le connecter avec un autre programme, pour faire tout cela et plus encore avec un logiciel, il faut avoir accès au code source1.

  • 2 Ceruzzi, A History of Modem Computing, p. 108.

10Mais il n’en a pas toujours été ainsi. Quand les ordinateurs ont été inventés, ils n’avaient pas de logiciels, de software. Leurs fonctionnalités étaient littéralement gravées dans les câbles des machines. Ce type d’encodage est évidemment très rigide. Cette façon de faire a été fondamentalement modifiée au début des années soixante2 et aujourd’hui, même si quelques fonctions des ordinateurs restent assurées par du code « gravé » (comme le code ROM [Read Only Memory] qui s’exécute au démarrage de votre ordinateur), la vraie vie des ordinateurs repose sur le logiciel.

11Au départ, personne ne se souciait vraiment de réglementer ce code. Aux débuts de l’informatique commerciale, les entreprises d’informatique écrivaient elles-mêmes les logiciels, mais ceux-ci étaient spécifiques à chacune d’entre elles et elles avaient toutes leur propre système d’exploitation (OS, Operating System, le logiciel de base à partir duquel tous les autres programmes sont exécutés). Ces systèmes n’étaient pas compatibles. Un programme écrit pour une machine IBM ne fonctionnait pas avec un ordinateur de Data General. Dans ces conditions, les fabricants avaient extrêmement peu de raisons de s’inquiéter de voir un de leurs programmes « volé ». Les entreprises d’informatique vendaient des ordinateurs et quand quelqu’un « volait » un logiciel programmé pour un ordinateur spécifique, il ne pouvait le faire fonctionner qu’à la condition de déjà posséder cet ordinateur.

12C’était un monde de machines incompatibles et cela représentait une gêne pour ceux qui avaient besoin de travailler sur plusieurs types d’ordinateurs. Par exemple, l’État dépensait des millions pour l’équipement informatique, mais il commençait à en avoir assez de voir que ses machines ne pouvaient pas communiquer les unes avec les autres. Le même problème se posait pour l’entreprise qui allait inventer ce qui est peut-être le plus important système d’exploitation de l’histoire de l’informatique : AT & T.

  • 3 Pour une histoire de Unix, voir William Shattuck, « The Meaning of UNIX », dans The Unix System Enc (...)

13Car c’est AT & T qui sera le héros de ce chapitre, du moins dans sa première partie. L’entreprise avait acheté beaucoup d’ordinateurs pour faire fonctionner son réseau national de téléphones, car un accord passé avec l’État en 1956 lui interdisait de vendre ou fabriquer des ordinateurs. Elle était donc dépendante de machines construites par d’autres et aussi excédée que le gouvernement de voir que ces machines étaient incapables de communiquer entre elles3.

  • 4 Robert Young et Wendy Goldman Rohm, Under the Radar : How Red Hat Changed the Software Business – a (...)

14Alors les chercheurs des « Bell Labs » décidèrent de se colleter avec ce problème. En 1969, Ken Thompson et Dennis Ritchie entreprirent d’élaborer un système d’exploitation qui pourrait être « adapté » (c’est-à-dire « traduit ») sur toutes les machines4. Cet OS serait donc une plate-forme commune, à partir de laquelle pourraient s’exécuter les programmes. Et comme elle serait commune à beaucoup de machines différentes, il suffirait d’écrire un programme une fois pour toutes pour qu’il puisse fonctionner sur plusieurs ordinateurs différents, moyennant quelques modifications mineures.

  • 5 Ceruzzi, op. cit., p. 94-95.
  • 6 Ibid., p. 92.

15Dans l’histoire de l’informatique, ce besoin d’un langage compatible entre les plates-formes n’était pas nouveau. ALGOL en fut l’un des premiers résultats5 de même que COBOL, quand l’État annonça qu’il n’achèterait ou ne louerait que des ordinateurs capables de faire fonctionner ce langage6. Mais la naissance d’Unix, comme fut appelé le système d’exploitation de base d’AT & T, fut l’étape la plus importante. En effet, AT & T ne se contenta pas d’élaborer cet OS matriciel, la société décida aussi de le laisser à la portée de tous. En effet, suivant les obligations imposées par l’accord de 1956, AT & T n’avait pas le droit de vendre un système d’exploitation, de sorte que K. Thompson et D. Ritchie, ses inventeurs, réussirent à convaincre la société de simplement le communiquer à tous ceux qui le voudraient.

  • 7 Ibid., p. 283 (le résultat fut que « UNIX fut une bénédiction pour les départements d’informatique (...)

16Les universités furent les premières à saisir l’occasion d’utiliser ce système d’exploitation gratuit7. Les départements d’informatique pouvaient utiliser (avec quelques restrictions) le code source pour enseigner l’écriture des OS à leurs étudiants. Ce code pouvait être critiqué, exactement comme un étudiant de littérature anglaise peut critiquer une pièce de Shakespeare parce qu’il peut en lire le texte. Et, à mesure que la compréhension de l’OS s’améliorait, les corrections des bogues du système étaient répercutées vers AT & T. Ce système fut à l’origine d’un vaste et puissant réseau de gens ayant appris le langage d’Unix, ainsi que de toute une génération formée par Unix.

17En ce sens, à cette époque, Unix était un bien commun. Son code était un bien commun, la connaissance générée par ce code était un bien commun, et la capacité d’améliorer ce code et d’innover à partir de lui était un bien commun. Personne n’avait besoin d’autorisation de la part d’AT & T pour apprendre comment fonctionnait son système de fichiers, ou comment l’OS gérait les imprimantes. Unix était une mine de connaissances mise à la disposition de tous. Á partir de cette mine, bien des choses ont été construites.

18Avec le temps cependant, la liberté d’accès au code des logiciels commerciaux commença à changer. En même temps que la compatibilité des plates-formes s’améliorait, que les produits devenaient plus nombreux et les utilisateurs plus divers, les entreprises qui créaient ces produits exercèrent de plus en plus de contrôle sur la façon dont on pouvait les utiliser. Le code se divisa en deux « branches », comme un chemin qui bifurque, se développant dans des directions différentes et incompatibles, et de plus en plus privatisées. Au lieu d’être des partenaires dans le processus de développement et d’utilisation de systèmes informatiques, les utilisateurs devinrent des consommateurs, et les fournisseurs de codes furent moins enclins à les laisser copier par d’autres.

19L’une des manifestations de cette montée de la réglementation s’avéra être un événement décisif dans l’histoire de l’informatique. Richard Stallman, chercheur au MIT (le « Massachusetts Institute of Technology ») était convaincu depuis la première heure du bien-fondé des principes de l’ouverture (comme on parle de « société ouverte »), ou plus généralement des principes de liberté. Bien sûr, cela ne concernait pas le monde entier, mais pendant la plus grande partie des années soixante-dix, ce fut la norme dans l’informatique. Les exceptions étaient mal vues.

20Le laboratoire où travaillait Stallman possédait une imprimante reliée à son réseau et les programmeurs qui travaillaient là avaient écrit un programme ingénieux pour les prévenir quand elle tombait en panne. Par exemple, s’il y avait un bourrage de papier, elle envoyait un message aux utilisateurs du réseau, et quelqu’un se trouvant proche de la machine allait alors rétablir la situation.

  • 8 Young et Rohm, op. cit., p. 20.

21En 1984, le laboratoire améliora le programme qui faisait fonctionner l’imprimante (le « pilote », driver), et Stallman demanda alors au fournisseur une copie de son code source pour pouvoir adapter le système d’alerte de la machine à la nouvelle version du pilote. L’entreprise refusa et informa Stallman que ce code était désormais fermé. Plus personne n’était autorisé à travailler dessus8.

  • 9 Voir Richard Stallman, « The GNU Operating System and the Free Software Movement », dans Chris DiBo (...)

22Aux yeux de Stallman, c’était une véritable faute morale. La somme de connaissances contenues dans ce pilote avait été produite par beaucoup de gens, qui n’étaient pas tous des employés du fournisseur. Dès lors, il y avait quelque chose d’injuste à ce que cette entreprise mette ces connaissances sous clé. Et cette injustice fit germer en Stallman l’idée d’un mouvement de résistance face à cette appropriation9.

  • 10 Dans le monde idéal de Stallman, ce bien commun serait construit avec du code non-propriétarisé. Ce (...)

23Ce mouvement vit le jour en 1985, quand Stallman fonda la « Free Software Foundation », la « Fondation pour un logiciel libre ». Son objectif était d’encourager le développement de logiciels distribués avec leur code source. Le principe était de garantir que les connaissances contenues dans ces logiciels ne seraient pas captives et fermées aux autres. Le but était de faire du code un bien commun10.

24Sans le vouloir, AT & T donna une forte impulsion à ce mouvement. Après son démantèlement en 1984, l’entreprise était libérée de l’interdiction d’exercer des activités informatiques qui lui était imposée depuis 1956. Maintenant soulagée de cette restriction, AT & T décida donc d’entrer sur le marché de l’informatique. L’un de ses atouts était Unix. La société décida donc d’en réglementer l’accès. À partir de 1984, ce logiciel ne serait plus libre et les entreprises, les universités et les particuliers désireux de l’utiliser devraient passer un contrat de licence avec AT & T.

25Pour beaucoup, ce fut une trahison de plus. Une génération avait passé sa vie professionnelle à apprendre le système Unix et à l’utiliser comme base de développement. Voici qu’AT & T prétendait posséder un droit exclusif sur le résultat de ce travail. Alors que l’entreprise s’était servie des suggestions qui lui avaient été faites et qu’Unix avait été amélioré en retour, AT & T voulait maintenant commercialiser ces améliorations en rendant ce code exclusif et non-libre.

26Face au revirement d’AT & T, les réactions furent véhémentes. Berkeley distribuait une version d’Unix ; après le changement de politique d’AT & T, le produit de Berkeley dut se soumettre à un remaniement en profondeur pour en extraire le code d’AT & T et de le transformer en une version (« BSD Unix ») échappant aux contraintes de la compagnie.

  • 11 NU » pour « Not Unix » ; le G initial transforme ces initiales militantes en un acronyme humoristiq (...)

27Mais Stallman réagit d’une façon plus productive et ambitieuse. Il voulait élaborer une version libre d’Unix qui serait structurellement libre et le resterait. C’est ainsi que la Free Software Foundation démarra le projet GNU, acronyme signifiant « GNU is Not Unix »11. Le projet GNU consistait d’abord à mettre au point l’ensemble des outils nécessaire pour construire un système d’exploitation, avant de les utiliser pour bâtir un OS GNU.

  • 12 Peter Wayner, Free for All : How Linux and the Free Software Movement Undercut the High-Tech Titans(...)

28Stallman se consacra à ce projet tout au long des années quatre-vingt en lui ajoutant des outils de façon progressive. D’abord « Emacs », extraordinaire éditeur de texte, puis un compilateur encore plus important, le « GCC » (« GNU C Compiler »)12. Peu à peu, le projet rassembla tous les outils qui seraient nécessaires à un OS.

  • 13 Pour une discussion sur Richard Stallman et l’histoire GNU/Linux, voir ibid., pp. 9, 34-36, 67-68 ; (...)

29Mais alors que les années quatre-vingt touchaient à leur fin, le projet commença à ralentir. Stallman avait contracté une maladie des mains qui le priva de la capacité de taper au clavier pendant un certain temps. Alors qu’il s’attaquait à la phase finale du projet, la construction du noyau du système d’exploitation GNU, le kernel (le cœur d’un OS), son rythme de travail se trouvait ralenti de manière alarmante. Il avait réuni tous les ingrédients requis pour faire fonctionner un OS, mais il lui en manquait le noyau13.

  • 14 Voir par exemple Linus Torvalds et David Diamond, Just for Fun : The Story of an Accidentai Revolut (...)

30En Finlande, un jeune étudiant en informatique souhaitait avoir la possibilité de faire des expériences sur un système d’exploitation. Unix était un standard qui valait de l’or, et Linus Torvalds n’était pas riche14.

31À la place, il commença à jouer avec « Minix », un OS pédagogique conçu par le professeur d’informatique Andrew Tannenbaum. Minix fonctionnait sur un ordinateur personnel mais il était construit comme un outil d’enseignement. Il était donc incomplet. Aussi, en 1990, Torvalds commença à construire un substitut à Minix, qu’il diffusa sur Internet en 1991. Ce code était diffusé par le biais d’un contrat de licence appelé General Public Licence (GPL), dont nous parlerons plus tard. Chacun était libre de s’en emparer et de l’utiliser, dans la mesure où l’utilisateur ne s’approprierait pas ce qu’il en aurait tiré.

  • 15 En combinant vers 1992 Linux avec le système GNU incomplet, on obtint un système d’exploitation lib (...)
  • 16 Pour une histoire récente et passionnante de la naissance de Linux, voir Glyn Moody, Rebel Code : L (...)

32Dès lors, les gens se rendirent compte rapidement qu’en travaillant un peu sur la convergence entre les éléments développés par Stallman et ceux du noyau de l’OS de Torvalds, il devenait possible de mener à son terme le projet de Stallman et de créer un OS libre et ouvert de type Unix, sans être Unix. « Linux » vit le jour assez rapidement, Linux, ou « GNU/Linux » pour ceux qui veulent honorer les deux contributeurs15. GNU/Linux était une plate-forme disponible avec son code source ; chacun pouvait s’en servir et construire à partir d’elle. Pour la même raison, chacun pouvait l’étudier pour l’améliorer. Nombreux furent ceux qui saisirent cette occasion, et en très peu de temps, GNU/Linux devint très performant16.

  • 17 Linus Torvalds, « The Linux Edge », dans Chris DiBona, Sam Ockman et Mark Stone, éds., op. cit., p. (...)
  • 18 Torvalds, ibid., p. 101.

33Tellement performant, en fait, que c’est actuellement le système d’exploitation qui progresse le plus vite dans le monde. Il est distribué par une foule de sociétés, commerciales ou non, et il a été adapté sur tous les principaux processeurs ; c’est « le système d’exploitation le plus largement répandu qui soit disponible sur PC », dit Torvalds17. Il existe une version de Linux pour processeurs PPC (utilisés par les ordinateurs Macintosh) et il en existe une version pour les processeurs utilisés par Sun. Rapidement, GNU/Linux est en train de devenir l’Unix imaginé par Thompson et Ritchie : une plate-forme sur laquelle n’importe qui pourrait « écrire une seule fois, et exécuter partout »18. À l’image de Mère Nature elle-même, GNU/Linux est en train de rapidement devenir universel, et libre.

34Comme je l’ai déjà précisé, GNU/Linux est un projet à « code ouvert », où le logiciel transporte son code avec lui et impose que ce code soit mis à la disposition du public. Il peut être lu et modifié par un utilisateur, et ses éléments peuvent être repris et utilisés par d’autres programmeurs. Ainsi, à partir de ce code, GNU/Linux construit un bien commun du code, de la connaissance, et de l’innovation .

35Mais Linux n’est qu’un exemple parmi un grand nombre de projets à code ouvert présents sur le réseau dès sa naissance. Ce n’est ni le premier, ni le seul, ni peut-être même le plus important d’entre eux. Pour comprendre à quel point le mouvement pour le code ouvert est vaste, il nous faut aussi mentionner les autres projets.

36Par exemple, le projet qui a conduit au serveur « Apache » est au moins aussi important, et il a eu plus de succès que GNU/Linux (tout du moins en termes de parts de marché). Un serveur est cet élément de l’infrastructure du Net qui « sert » du contenu. Quand vous allez sur une page Web et que vous en voyez les contenus, l’ordinateur qui les diffuse est un « serveur ». Dans les premiers jours du Web, on s’attendait à ce que des sociétés comme Netscape Corporation construisent et vendent des serveurs. Netscape l’a fait, comme d’autres, y compris Microsoft. Mais à côté de ces tentatives commerciales, il existait une version d’un serveur Web disponible librement. Il s’agissait du serveur HTTP, produit par le « National Center for Supercomputing Applications » (NCSA).

37Le serveur du NCSA était satisfaisant, mais facilement bogué. Cependant, comme c’était un projet subventionné par l’État, son code source était disponible et la seule obligation imposée par le NCSA aux utilisateurs et aux programmeurs qui en modifieraient le code, c’était qu’ils mentionnent NCSA comme co-auteur.

38Un groupe d’utilisateurs précoces du protocole HTTP commença alors à s’échanger des « rustines » de colmatage, patches, sur le serveur, des améliorations aussi bien que des corrections de bogues qui permettaient d’exécuter le code plus efficacement. À partir d’un certain moment, le groupe décida de former un collectif pour bâtir un nouveau serveur à partir de celui du NCSA. Ils l’appelèrent « Apache », aussi bien en raison de la fierté associée à ce nom que parce que, étant le fruit d’une succession de patches, c’était un serveur « à patches ». Ils le diffusèrent comme serveur libre et ouvert.

  • 19 Moody, op. cit., p. 130. Voir aussi Dorte Toft, « Open Source Group Forms Nonprofit », Industry Sta (...)

39Apache rencontra rapidement le succès. À mesure que ses parts de marché grandissaient, les utilisateurs fournissaient davantage de patches en retour. Les développeurs travaillèrent dur pour les intégrer et la qualité du serveur s’améliora rapidement, de sorte qu’Apache devint vite le serveur numéro un dans le monde. À ce jour, deux tiers des serveurs sur le World Wide Web sont des serveurs Apache et, comme le dit Glyn Moody, « si le débat fait encore rage pour savoir si des logiciels open source comme GNU/Linux peuvent jamais espérer surpasser Microsoft, Apache l’a déjà fait »19.

40Les programmeurs qui construisirent le serveur Apache n’étaient payés par aucune société du nom de « Apache ». Beaucoup participèrent à temps partiel tout en restant salariés dans différentes entreprises. Selon un des dirigeants du projet, le gourou du Net Brian Behlendorf, ce « principe du bénévolat » fut décisif pour celui-ci. Le travail accompli devait venir de gens qui étaient motivés par l’idée de participer, pas de gens qui étaient simplement payés pour programmer de neuf heures du matin à cinq heures de l’après-midi.

  • 20 Voir http://www.isc.org/products/BIND/bind-history.html.
  • 21 Tim O’Reilly, « Hardware, Software, and Infoware », dans Chris DiBona, Sam Ockman, et Mark Stone, é (...)
  • 22 Wayner, op. cit., p. 172.
  • 23 Voir Carolyn Duffy Marsan, « Sendmail Adds Admin Console, IPv6 Support ; New Unix-Based Tool Can Ma (...)

41Linux et Apache sont les deux projets open code les plus en vue, mais il y en a bien d’autres. Élaboré par Larry Wall, « Perl » est un langage de programmation qui permet des manipulations de texte à un degré avancé, et c’est le ciment qui fait fonctionner la plupart des sites Web. Lui aussi fut élaboré comme un projet open source et, porté sur tous les principaux OS, c’est de loin le langage dominant dans sa catégorie. Plus profondément dans les entrailles du code d’Internet, on trouve d’autres systèmes encore plus importants. Le système « Berkeley Internet Name Daemon » (BIND) connecte les noms de domaines (comme lessig.org) aux adresses IP (comme 123.45.67.890), et fut développé à l’origine comme un projet open code au sein de l’université de Californie, à Berkeley. Paul Vixie devint responsable de son développement à partir de la version 4-9.220, et certains affirment aujourd’hui que BIND est « l’application la plus importante de l’Internet »21. Que ce soit vrai ou non, cette application a été développée grâce à un code ouvert. De même « Sendmail », logiciel qui oriente les courriels, est un projet open code développé par Éric Allman22 qui équipe maintenant 75 % des serveurs dans le monde23.

42Ensemble, ces projets constituent l’âme même de l’Internet. Associé aux protocoles de domaine public qui définissent Internet (régis par aucune licence mais disponibles à tous, collectivement désignés comme TCP/IP, y compris les protocoles au cœur du World Wide Web), c’est ce code libre qui a construit Internet. Ce n’est ni un programme unique ni un OS unique. Le cœur d’Internet est fait de cet assemblage de codes construits en dehors du modèle propriétarisé.

43À l’intention des maniaques de la propriété, ou de ceux qui croient que le progrès n’émerge que grâce à des droits de propriété forts et puissants, attardons-nous sur ce point et redisons-le : le plus important lieu d’innovation de notre époque a été construit sur une plate-forme qui était d’accès libre. Ainsi que le dit Alan Cox, qui ne le cède qu’à Linus Torvalds dans la hiérarchie des développeurs Linux, et qui s’exprime dans un article en réplique à une attaque de Microsoft contre les valeurs du code ouvert :

Ce n’est pas grâce à [la propriété intellectuelle] que les grandes avancées de l’ère informatique se sont produites, mais en dépit d’elle. Avant Internet, les protocoles des réseaux privés divisaient les consommateurs, les enfermaient chez leurs fournisseurs et les obligaient à s’échanger leurs données sur des cassettes. Le pouvoir du réseau n’a pas été libéré par les droits de propriété intellectuelle. Il a été libéré par une innovation libre et ouverte partagée par tous.24

44Internet n’a pas été produit par la réglementation puissante et totale de marchands privés ; Internet a été produit par des protocoles ouverts et libres, ainsi que par des logiciels ouverts et libres qui fonctionnaient par-dessus ces protocoles.

45Ce code libre d’accès construit un bien commun. À son tour, ce bien commun diminue le coût de l’innovation. De nouveaux projets peuvent se greffer sur ce code commun ; aucun n’a besoin de réinventer la roue. Ainsi, cette ressource alimente un large champ d’innovation qui n’existerait pas s’il en était autrement.

46Le code libre construit également un bien commun dans le domaine du savoir, et ce, grâce à la nature même de l’information. Quand j’apprends comment faire une page Web, cela n’amoindrit pas la connaissance de la construction des pages Web, car, comme nous l’avons vu, la connaissance est non-concurrentielle, « non-rivale » : le fait que vous sachiez quelque chose ne diminue pas la quantité de choses que je peux connaître.

47Il y a quelque chose de spécifique dans la façon dont ce code libre construit ce bien commun de la connaissance. Le code est un langage performatif : il ne dit que ce qu’il fait. C’est-à-dire que ce n’est pas seulement en le lisant qu’on peut apprendre des choses à propos du code, c’est aussi en le mettant en application.

48Prenons l’exemple du code qui structure le World Wide Web. Les pages Web sont principalement écrites dans un langage de marquage HTML, qui correspond à un ensemble d’étiquettes accrochées aux textes ou aux graphiques que l’on veut afficher. Or, tous les principaux navigateurs Web possèdent une fonction pour révéler le code source d’une page Web que l’on est en train de visiter. Pour savoir comment elle est construite en la visitant, il suffit simplement « d’afficher le code source » sur la page afin qu’elle donne à lire les lignes de codes qui sont à son origine.

49Grâce à cette caractéristique de la grande toile, les programmeurs pouvaient très facilement apprendre à créer des pages Web. L’essentiel de l’apprentissage de départ consistait simplement à copier une page et à la modifier selon ses envies. Même si le code qui la construisait était protégé par des droits d’auteur, il était possible pour tous d’en apprendre quelque chose. Encore une fois, c’est parce que le code agit en même temps qu’il s’exprime que cette efficacité pédagogique en retour était forte.

50Cette fonction du World Wide Web était un choix. Que ce code soit rendu visible n’était pas de l’ordre du nécessaire. D’autres langages, comme l’« AppleScript » d’Apple, permettent facilement aux auteurs de cacher le code exécuté par le logiciel, handicap qui aurait très bien pu être le choix fait pour le World Wide Web.

51Mais dans l’hypothèse de ce handicap, le bien commun en matière de connaissances apporté par le World Wide Web aurait été sérieusement réduit, et en conséquence la croissance et l’innovation du World Wide Web auraient été bien moindres. En le concevant ouvert, on lui assurait une croissance plus rapide.

52Finalement, et c’est ce qui est important pour les idées que je défends ici, c’est un code libre au niveau de la couche des contenus qui construit un bien commun de l’innovation, exactement comme le fait le principe du end-to-end au niveau de la couche logique. En permettant l’accès à ce qu’il produit, et en s’assurant que tout le monde peut bâtir dessus, ce code libre d’accès garantit que l’innovation ne pourra pas être figée. À l’image du caractère simple et neutre du réseau end-to-end, le code libre n’est pas discriminatoire vis-à-vis des innovations.

53Cependant, contrairement au principe du end-to-end, ce bien commun de l’innovation est protégé par la loi. Au mieux, les principes du end-to-end sont protégés par des normes que les programmeurs décident ou non de respecter quand ils développent des logiciels. En revanche, le bien commun de l’innovation construit par le code ouvert est un bien protégé par la loi.

54C’est ce que je vais tenter d’expliquer maintenant dans ce chapitre.

55Le bien commun de l’innovation construit par le code ouvert est protégé par une combinaison de droit contractuel et de droit d’auteur. Nous nous intéresserons plus en détail au droit d’auteur dans le chapitre 3 de la troisième partie ; contentons-nous de dire pour l’instant qu’il s’applique à toutes les formes de création dès lors qu’elles sont fixées sur un support tangible. Comme vos lettres d’amour dès l’instant où vous les écrivez, vos courriels sont protégés par le droit d’auteur dès l’instant où vous les tapez.

  • 25 ertains sont réticents à qualifier ces « droits exclusifs » de « monopoles » : voir Frank Easterbro (...)

56C’est pour aider à résoudre un problème lié à l’information créatrice que la loi crée ce « droit exclusif », c’est-à-dire un droit de monopole25. Ainsi que nous l’avons vu dans la première partie, chapitre 1, l’information est naturellement non-rivale. Même si quelqu’un l’utilise avant moi, il m’en reste encore autant qu’avant. D’autre part, l’information est naturellement non-exclusive. Ainsi que le dit Jefferson poétiquement :

  • 26 Lettre de Thomas Jefferson à Isaac McPherson (13 août 1813), dans The Writings of Thomas Jefferson, (...)

Qui reçoit une idée de moi reçoit du savoir sans que mon savoir en soit diminué ; de même, qui allume sa bougie à la mienne reçoit de la lumière sans me plonger dans l’obscurité, [on y reviendra].26

57Mais ces deux caractéristiques sont à l’origine d’un problème de motivation pour les auteurs. Sans possibilité de réglementer la duplication de son travail créatif, l’auteur n’a pas non plus celle d’en tirer profit. Pour certains auteurs, cela signifierait qu’ils consacreraient moins de temps à produire, ce qui conduirait à une réduction de l’innovation créatrice.

58Le droit d’auteur a été imaginé pour servir de remède à ce problème. Il essaie d’apporter une solution en accordant un droit limité aux auteurs : le droit exclusif de réglementer certaines utilisations de leur travail pendant une certaine période de temps.

59Mais il est évident que ces mesures ne sont d’aucune aide à l’auteur s’il doit exercer ses droits exclusifs seul. Les écrivains ne sont pas des éditeurs. Aussi, ils peuvent accorder des autorisations d’utiliser leurs travaux protégés en passant des contrats appelés licences, dans le cadre de la loi sur le copyright.

60Jusqu’à présent, j’ai parlé de « code ouvert », de « code libre », mais ces termes décrivent deux sortes de licences très différentes. Le modèle de la licence open code fut mis en place par la Free Software Foundation. C’est la « General Public License », ou GPL.

  • 27 La GPL est souvent qualifié de licence « copyleft », mais le copyleft repose fondamentalement sur l (...)

61La GPL fixe les conditions auxquelles quelqu’un a le droit d’utiliser des logiciels libres27. Dans l’ensemble des licences concernant les logiciels, la GPL est unique. Alors que les licences sont généralement utilisées pour limiter les copies que peut faire le titulaire de la licence, la GPL est utilisée pour limiter les restrictions imposées aux copies que ce titulaire peut faire. Tout le monde peut utiliser ou modifier une œuvre sous GPL pourvu que, comme le stipule son préambule,

vous [...] offriez tous les droits que vous possédez aux receveurs. Vous devez vous assurer qu’eux aussi reçoivent ou puissent obtenir le code source.28

62Ainsi que le dit Richard Stallman :

  • 29 Stallman, op. cit., p. 56.

Pour un utilisateur individuel comme vous, un programme est un logiciel libre aux conditions suivantes. Vous avez la liberté d’exécuter ce programme comme vous l’entendez. Vous avez la liberté de modifier le programme selon vos besoins. (Pour que cette liberté soit effective, il est nécessaire que vous ayez accès au code source puisque sans lui il est excessivement difficile d’apporter des changements au programme). Vous avez la liberté de redistribuer des copies gratuitement ou contre une rétribution. Vous avez la liberté de distribuer des versions modifiées du programme, pour que la communauté puisse bénéficier de vos améliorations.29

63En conséquence, une fois sous licence GPL, les logiciels soumis au droit d’auteur restent toujours disponibles pour le public afin qu’il les utilise ou les modifie selon ses désirs, de même pour le code dérivé du code protégé par la GPL. C’est cette combinaison de droit d’auteur et de droit contractuel qui rend « libre » le code GPL et le code qui en est dérivé.

  • 30 Voir Moody, op. cit., p. 168

64La GPL n’est pas la seule licence utilisée par le mouvement du code ouvert. Il utilise aussi une seconde catégorie de licences, ordinairement appelées open source, et moins restrictives que les licences du logiciel libre (ou, selon le point de vue, moins créatrices de liberté). Alors que les licences de logiciel libre requièrent que les œuvres dérivées restent libres, les licences open source n’imposent rien de tel30. Microsoft est libre d’utiliser le serveur Apache (mis à disposition sous une licence open source) et de l’incorporer dans des produits dont il est propriétaire ; en revanche, Microsoft n’est pas libre de prendre Linux pour l’incorporer dans Windows.

  • 31 our une discussion plus complète sur les différentes licences et leurs implications, voir David McG (...)

65C’est sans doute une différence importante, mais pas tellement en ce qui nous concerne. La GPL offre un modèle suffisant pour aborder la discussion qui va suivre, de sorte que nous assimilerons les autres licences à la GPL. Quand cela sera nécessaire, nous ferons la distinction entre ces deux types de codes (au sens juridique du terme)31, mais pour le moment, nous pouvons partir du principe que c’est le code de la GPL qui sert de cadre juridique pour le code libre.

66Ainsi que je l’ai dit, Linux est mis à disposition sous licence GPL. Cela signifie que le code source de Linux est diffusé en même temps que le code du programme lui-même, que chacun peut bricoler avec et voir comment il fonctionne.

67Tout code dérivé de ce code ouvert doit lui-même être diffusé sous une licence de type GPL. Le code, et tout le savoir qu’il suppose, sont donc libres et ouverts.

68Le principal argument des partisans de l’open code, c’est que leurs utilisateurs ne sont pas otages de ces projets. Cette affirmation est vraie, mais de deux façons différentes, dont l’une est évidente, l’autre non. Ce qui est certain, c’est que les utilisateurs ou les programmeurs qui adoptent ce code peuvent l’étudier, le manipuler, le modifier selon leurs désirs. Ainsi que le dit Peter Wayner,

  • 32 Wayner, op. cit. p. 260.

le monde du free source [...] est un retour au bon vieux temps où l’on pouvait prendre en main ce qui vous appartenait.32

69Vous pouvez ajouter des fonctionnalités ou corriger celles qui étaient imparfaites telles qu’elles étaient fournies.

70Les autres OS ne sont ni libres, ni ouverts. Par exemple, Apple vend des ordinateurs Macintosh équipés avec Mac OS. Avec les programmes livrés avec Mac OS 9, on trouve un utilitaire appelé « Synchronisation Fichiers », qui permet à un utilisateur d’utiliser synchroniquement deux groupes de fichiers. Si vous avez des ordinateurs portables et des ordinateurs fixes, « Synchronisation Fichiers » vous garantit que les fichiers sont mis à jour sur les deux systèmes.

71Mais il y a un hic avec « Synchronisation Fichiers ». Si vous essayez de synchroniser des fichiers dont les icônes ont été personnalisées (les icônes sont les images sur lesquelles vous cliquez pour ouvrir un fichier dans le bureau), le logiciel provoque une erreur par « manque de mémoire ». En fait, le logiciel est bogué et ce bogue le rend impossible à utiliser sur les systèmes dont les icônes ont été modifiées, alors que la possibilité de modifier les icônes est une des fonctionnalités inscrites dans le système Mac OS. Ainsi, ceux qui utilisent cette dernière fonctionnalités ne pourront pas profiter aussi du programme gratuit de synchronisation livré par Apple avec l’ordinateur.

72Tous les codes sont bogués ; le cas de Mac OS n’a rien de spécial, mais ce qui est intéressant dans cette histoire, c’est la durée pendant laquelle ce bogue tout simple a réussi à survivre. Le programme « Synchronisation Fichiers » a été diffusé en 1998, et ce bogue était encore là en 2000. Pour Apple Computer, la réparation de cette erreur d’allocation mémoire dans ce recoin de Mac OS n’avait rien d’urgent et le bogue restait invaincu.

  • 33 OS X, le dernier système d’exploitation d’Apple, inclut une partie appelée « Darwin » qui est diffu (...)

73Si cette partie de Mac OS avait été ouverte, c’est-à-dire si le code source avait été disponible, il ne fait aucun doute que quelqu’un, quelque part, aurait pu trouver utile de corriger l’erreur que le code avait induite. Ce programmeur aurait pu prendre le code fourni avec Mac OS et il aurait réglé le problème. Ensuite, qu’il ait fait de sa réparation un objet commercial ou non, elle aurait été disponible sans avoir besoin d’attendre deux ans33. Les utilisateurs du programme « Synchronisation Fichiers » n’auraient pas été otages des faiblesses de ce logiciel.

74La liberté de manipuler les logiciels est donc importante. Mais il y a une façon encore plus fondamentale de garantir que les utilisateurs de code ouvert ne puissent pas être retenus en otages, et c’est cette caractéristique de l’open code qui fait le lien avec le principe du end-to-end que nous avons discuté dans le chapitre précédent. De même que l’ouverture du principe end-to-end garantit un réseau neutre qui fait fonctionner votre code et ne dessert pas votre innovation, l’ouverture de l’open code garantit que les fondements de l’environnement informatique restent neutres et ne puissent pas se retourner contre les créateurs. Une plate-forme à code ouvert est une plate-forme qui joue franc jeu. Elle conduit les développeurs à lui faire confiance.

  • 34 Pour une analyse détaillée de ce procès, voir Ken Auletta, World War 3.0 : Microsoft and Its Enemie (...)

75Nous pouvons entrevoir l’importance de cet élément en nous intéressant rapidement à la plus importante poursuite judiciaire concernant le cyberespace qui se soit déroulée jusqu’ici : les États-Unis contre Microsoft34.

  • 35 e gouvernement n’est pas le seul à avancer cette affirmation. Comme le dit le PDG de Red Hat, Bob Y (...)

76Dans cette affaire United States vs Microsoft, les arguments du gouvernement étaient essentiellement les suivants : alors que Microsoft avait construit une importante plate-forme sur laquelle les développeurs du monde entier avait bâti du code, la société avait adopté une pratique qui gelait certaines formes d’innovation. Selon le gouvernement, quand un inventeur mettait au point une technologie qui menaçait la plate-forme de Microsoft, la compagnie utilisait stratégiquement sa plate-forme pour la paralyser. En d’autres termes, tout en protégeant certaines innovations, elle se retournait contre d’autres. Pour le gouvernement, ce schéma était étouffant de la même façon que la mainmise d’AT & T sur les réseaux téléphoniques avait étouffé les innovations qui ne correspondaient pas à son modèle de développement35. Contrairement à ce qui se serait passé avec un réseau respectant le principe du end-to-end, Microsoft avait introduit des règles discriminatoires dans sa plate-forme, et cette discrimination lésait l’innovation.

77Il faut un peu se replonger dans le contexte pour comprendre la position de l’État. A l’époque où Torvalds diffusait le « noyau » de Linux, Microsoft était en train de diffuser la dernière version d’un programme appelé Windows, qui allait recevoir un accueil extraordinaire dans la communauté des utilisateurs. Windows 3.0 se révélait être un outil stable et puissant qui simulait un système d’exploitation à « interface graphique » (GUI, « Graphic User Interface »). Ce n’était pas un système d’exploitation ; c’était simplement un logiciel qui s’exécutait par-dessus un OS sous-jacent appelé DOS (« Disk Operating System »), mais il était suffisamment efficace pour inciter une immense proportion des consommateurs de DOS à l’acheter ou à mettre leur version à jour.

  • 36 Il y a eu des tentatives d’interfaces graphiques pour ordinateurs personnels avant que Microsoft ne (...)

78Avant Windows, les utilisateurs d’ordinateurs personnels équipés d’une architecture Intel (les ordinateurs « compatibles IBM » comme on les appelait) étaient condamnés à utiliser une interface en ligne de commande36. Quand vous démarriez le système, il vous présentait une simple ligne de commande, par exemple, « C : > », et il attendait de vous, l’utilisateur, que vous entriez une commande pour démarrer un programme. C’était un système inspiré d’Unix, initialement destiné aux gens assez expérimentés pour jouer avec Unix.

  • 37 Il est bien connu que l’entreprise n’a pas vraiment écrit ce DOS, elle a simplement obtenu une lice (...)

79Microsoft était à l’origine du « Disk Operating System »37. Quand IBM décida de commercialiser un ordinateur personnel, la société passa un contrat avec Microsoft pour son système d’exploitation. Cependant, guidé par Bill Gates qui est peut-être l’homme d’affaires le plus avisé de notre génération, Microsoft conserva ses droits sur DOS. Peu après, IBM allait en développer sa propre version appelée PC-DOS, mais Microsoft restait libre de fabriquer et de vendre MS-DOS.

80Microsoft répondait mieux aux attentes des consommateurs et, rapidement, c’est MS-DOS qui devint leader sur le marché. Ses programmeurs étaient plus efficaces pour résoudre des problèmes de codes et, à la fin des années quatre-vingt, MS-DOS était largement dominant dans un monde lui-même dominé par les ordinateurs compatibles PC.

  • 38 Stan Miastkowski, « A Cure for What Ails DOS », BYTE (août 1990), p. 107.
  • 39 Affaire Caldera vs Microsoft, 72 F. 2e suppl., pp. 1295, 1299 (district de l’Utah, 1999).

81De plus, Microsoft était soumis à de sérieuses pressions. D’abord, il n’était pas le seul fabricant de DOS. Une compagnie appelée Digital Research élabora DR-DOS, un DOS différent, perçu de plus en plus comme supérieur à celui de Microsoft. En 1990, le magazine BYTE déclarait, à propos de DR-DOS 5.0, qu’il « éliminait beaucoup des imperfections de MS-DOS (pas toutes cependant) » et qu’il lui était largement supérieur38. D’autres magazines tenaient un discours à peu près similaire39.

82Ensuite, les interfaces graphiques étaient une autre menace pour Microsoft. À mesure que les consommateurs adoptaient des PC, ils se trouvaient de plus en plus handicapés par l’interface en ligne de commande, et ils commençaient à s’intéresser à d’autres produits PC. Le plus séduisant était le Macintosh d’Apple, présenté en 1984, qui offrait une interface graphique simple rendant facile l’utilisation d’un PC.

  • 40 Jim Carlton, Apple : The Intrigue, Egomania, and Business Blunders That Toppled an American Icon, N (...)

83Gates admirait le Mac. C’est pour lui que sa société avait d’abord écrit Word et Excel. Et en 1985, Gates avait essayé d’obtenir une licence pour adapter le système d’exploitation du Mac à l’architecture des processeurs Intel40. Ce qui fut peut-être la pire de toutes les décisions de l’histoire de l’industrie informatique, Apple refusa cette offre. Gates lança alors ses troupes dans la création de Windows.

  • 41 Ibid., p. 28.
  • 42 « GUI » pourrait se prononcer comme guy (un « type », un « mec », pl. guys) ; prononcer l’acronyme (...)

84Il est difficile aujourd’hui de se souvenir de l’importance de la menace que Gates pouvait alors ressentir. Microsoft était une petite entreprise par rapport à Apple. En 1984, les ventes annuelles d’Apple atteignaient 1,5 milliard de dollars alors que celles de Microsoft étaient de 98 millions41. Avec le recul, l’inévitable succès de Windows semble évident, mais à cette époque, il est certain que beaucoup de gens de chez Microsoft avaient le sentiment de vivre sous la menace d’une horde de concurrents dont quelques-uns construisaient de meilleurs systèmes d’exploitation (DR-DOS), et dont d’autres construisaient de meilleures interfaces graphiques, plus précisément GUI (les « GUIs » d’Apple, désignés familièrement par « gooeys »42). Gates engagea donc Microsoft à élaborer de meilleurs produits dans chacun de ces deux domaines.

85À partir de 1991, il se rendit compte que le futur serait un monde où le GUI serait intégré au système d’exploitation (GUI-OS). Ce serait Windows 95, mais il faudra un certain temps pour arriver à Windows 95. Il allait intégrer le GUI de Windows 3.0 avec le DOS, offrant aux utilisateurs un système intégré comparable à celui de l’Apple Macintosh.

86L’essentiel cependant était de s’assurer que Microsoft ne perdrait pas sa clientèle de base en opérant ce basculement. La plupart des utilisateurs se servaient de MS-DOS et tous voulaient Windows. L’entreprise estimait donc qu’il était crucial d’occuper le terrain pendant les quatre prochaines années.

87C’est ici que les choses prirent une tournure juridique, et ce qui suit n’est rien d’autre que l’histoire des accusations lancées par les autorités antitrust (et par d’autres) contre la façon dont Microsoft réagissait à la menace à laquelle il faisait face. Mais ces accusations sont solides, le parallèle avec celles qui viendront par la suite est évident. En étudiant les arguments avancés contre la mainmise présumée de Microsoft, l’histoire des biens communs devient plus claire.

88Pour occuper le terrain, Microsoft devait s’assurer qu’aucun adversaire ne réussirait à détourner la clientèle de son système d’exploitation. Étant donné la concurrence croissante des autres systèmes d’exploitation, les risques de défection étaient importants, mais l’instrument pour s’en prémunir était Windows 3.0, logiciel puissant et populaire. Tout le monde voulait l’acheter et, pour un fabricant d’ordinateurs, il était plus important de vendre Windows 3.0 que de vendre n’importe quel DOS.

89Selon le gouvernement, Microsoft a donc utilisé sa mainmise sur Windows pour éliminer la concurrence des autres DOS en pratiquant des politiques de prix qui empêchaient les fabricants de vendre d’autres versions de DOS que MS-DOS, et, selon les autorités de la concurrence de l’Union Européenne, en pratiquant la vente liée de Windows 3.0 et de MS-DOS. De cette façon, Microsoft empêchait ses concurrents de prendre pied sur son marché et il pouvait occuper le terrain jusqu’au moment où il serait capable de faire migrer ses utilisateurs vers Windows 95.

  • 43 « Il y a comportement anticoncurrentiel [strategic behavior] dès que deux individus ou plus interag (...)

90Pour le gouvernement, Microsoft adoptait une « stratégie »43 en restreignant les choix de ses consommateurs pour protéger sa propre position sur le marché. Cette forme de concurrence, alléguait le gouvernement, était anticoncurrentielle. Plutôt que d’autoriser le développement de la compétition entre les systèmes d’exploitation, Microsoft menaçait les concurrents qui construisaient des produits menaçants pour lui.

91En 1994, le gouvernement notifia à Microsoft qu’une plainte allait être déposée pour pratique de prix prédateurs et de vente liée en vue de s’assurer la mainmise sur le marché. Après d’âpres négociations, Microsoft signa un accord, certifiant au gouvernement que la société s’interdirait un certain nombre de comportements spécifiques. Le gouvernement prit acte de la promesse de Microsoft et l’affaire fut réglée.

92Un accord n’est rien d’autre qu’un contrat. Le gouvernement promettait de ne pas poursuivre Microsoft si celui-ci acceptait de ne pas adopter certains comportements. Rien dans ce contrat ne permettait d’affirmer que le comportement reproché avait été illégal ; rien non plus n’empêchait le gouvernement de poursuivre Microsoft pour d’autres pratiques anticoncurrentielles. Aux yeux du gouvernement, ce contrat n’était qu’une solution simple pour mettre un terme aux dommages dont il estime qu’une entreprise s’est rendue coupable, tout en s’épargnant un procès long et coûteux pour démontrer que son comportement était réellement illégal. Si la société qui a passé ce type d’accord refuse de l’exécuter, alors le gouvernement est en droit de saisir les tribunaux pour l’y forcer.

  • 44 Elizabeth Corcoran, « Microsoft Deal Came Down to a Phone Call », Washington Post (18 juillet 1994) (...)

93Après que le gouvernement eut conclu l’arrangement, il fit savoir au monde entier que le marché des systèmes d’exploitation était désormais ouvert à la concurrence et que, selon la promesse de l’assistante du Procureur Général Anne Bingaman, on verrait désormais fleurir la concurrence entre les systèmes d’exploitation44 . Elle affirmait que le champ était ouvert et que les concurrents allaient s’y ruer. Microsoft serait soumis à une pression concurrentielle importante, et sa position de monopole ne serait plus qu’un souvenir.

94Du côté de Microsoft, on voyait cet accord d’un tout autre œil. On estimait qu’il n’aurait aucune conséquence pratique. Comme le disait Bill Gates à la presse,

  • 45 bid.

aucun de nos directeurs de départements ne va changer quoi que ce soit dans sa façon d’agir, de penser ou de s’organiser. Un type est chargé de contrats de licence. Il lira l’accord.45

95Il s’avéra que Microsoft fut le meilleur augure. Peu de temps après l’annonce de l’accord, DR-DOS disparut, IBM annonça qu’il cessait le développement de son système d’exploitation OS/2 ; en fait, tous les concurrents de Microsoft sur le marché du système d’exploitation compatible PC disparurent. L’accord était un acte juridique, mais il n’avait aucune efficacité pratique. Il avait été trop lent à intervenir, et le temps qu’il arrive, le monde qu’il devait réguler avait déjà changé.

96Mais le gouvernement revint à la charge en 1997. Une fois de plus, il affirmait que Microsoft bloquait le marché en adoptant des stratégies destinées à éliminer la concurrence. Cette fois-ci cependant, il ne s’agissait plus de protéger DOS, mais de protéger Windows 95 contre l’apparition d’une nouvelle forme de concurrence : l’Internet.

97Avant 1995, Microsoft n’avait pas encore compris ce que deviendrait Internet, et Bill Gates ne le prenait pas au sérieux. Mais passée cette date, ce fut comme si Gates avait eu une illumination. À travers une série de séminaires, il fit clairement passer l’idée qu’internet était la révolution du futur et que cette révolution était la plus grande menace jamais portée contre Microsoft.

  • 46 David Bank : « À trois heures du matin par un matin pluvieux d’avril 95, Gates annonça par courriel (...)

98Dès que Microsoft commença à se réveiller, on peut presque dire que Gates n’en dormit plus la nuit. Les choses se sont à peu près passées ainsi. La puissance de Microsoft venait du fait que les développeurs d’applications écrivaient leurs programmes pour la plate-forme de Microsoft. Aussi longtemps qu’ils continueraient, Microsoft resterait puissant. Mais Internet leur offrait un nouveau champ d’action. Grâce à la technologie de navigateurs comme Netscape, associée à un langage de programmation comme Java, les développeurs trouveraient de plus en plus opportun d’écrire leurs programmes directement pour le Net. Cela réduirait la dépendance du public vis-à-vis de Windows, ce qui réduirait en retour la puissance monopolistique de Microsoft. Ainsi, un produit qui pouvait se substituer partiellement à Windows menaçait maintenant de miner son pouvoir46.

  • 47 Le gouvernement s’est appuyé sur des preuves fournies par les propres courriels et déclarations de (...)

99Qu’on pense que cette menace était fondée ou non, il y a assez de preuves que Bill Gates la prenait au sérieux47. Microsoft se mit donc à nouveau sur la défensive. Et, comme avec DOS au début des années 90, la société avait besoin d’occuper le terrain pour les utilisateurs de Windows 95 pendant qu’elle élaborerait une suite d’applications réseau capable de tenir tête à la menace de l’association Java/Netscape.

  • 48 On a sans doute tort de sur-interpréter le terme assez vague « levier », leverage, mais il est clai (...)

100Il y parvint grâce à une stratégie de défense familière. Comme avec MS-DOS et Windows 3.0, l’objectif était de s’assurer qu’une portion significative de la clientèle ne quitterait pas Windows 95 sans attendre que celui-ci soit adapté à l’univers des réseaux. Mais cette fois, la stratégie de Microsoft ne passerait pas par une application de confort que tout le monde aurait envie d’avoir, elle passerait par l’intégration d’un navigateur Microsoft dans le cœur même du système d’exploitation Windows 95. Tous les fabricants d’ordinateurs qui voulaient vendre un PC basé sur une architecture Intel devraient le vendre avec Windows 95. Microsoft tira parti de cette situation en s’assurant que les consommateurs auraient en même temps le navigateur Internet Explorer48.

101La méthode suivie pour être certain que les deux éléments iraient ensemble évolua avec le temps. Au départ, le programme était un simple accessoire livré avec le système d’exploitation, exactement comme « Synchronization Fichiers » était livré avec le système d’exploitation du Macintosh. Mais finalement, le programme fut intégré au système d’exploitation afin de faciliter la transition d’autres programmes vers Internet, tout en rendant difficile l’installation d’un autre navigateur dans le système Windows 95.

102Pour le gouvernement, ce comportement était une vente forcée du même genre que celle qui avait été visée à propos de Windows 3.0 et de DOS, et son objectif était identique : Microsoft utilisait sa mainmise sur un système d’exploitation pour mettre en œuvre une stratégie anticoncurrentielle visant à bloquer une innovation menaçante.

103Cette bataille entre le gouvernement et Microsoft n’est pas encore terminée à l’heure où j’écris ceci, mais son importance ne dépend pas vraiment, pour ce qui concerne notre propos, des décisions qui pourraient intervenir en appel. Que les assertions du gouvernement soient ou non avérées, cette affaire peut être mise en parallèle avec les leçons du chapitre 2 de notre première partie. Microsoft était accusé d’utiliser des stratégies anticoncurrentielles destinées à protéger sa position de monopole, c’est-à-dire qu’il utilisait son pouvoir sur un système d’exploitation pour détruire les innovations qui pouvaient remettre ce pouvoir en question. C’est ce que dit David Bank, journaliste au Wall Street Journal :

  • 49 Bank, op. cit., pp. 11, 13.

Chaque produit à succès représentait une menace potentielle pour la plate-forme Windows parce qu’il pouvait devenir lui-même une plate-forme. Microsoft utilisa l’intégration comme une arme pour désamorcer les menaces contre Windows. […] Tous ceux qui ont essayé de rivaliser avec la plate-forme Microsoft ont perdu.49

  • 50 Ibid., p. 212

104Encore une fois, il ne s’agit pas de prétendre que Microsoft a gelé l’innovation en général, et il faut redire que Windows s’est révélé être une aubaine extraordinaire pour l’innovation. Des milliers de programmes ont été écrits pour Windows, et des centaines de milliers de codeurs l’ont utilisé à leur profit. Mais il arrive parfois qu’une innovation remette en question la position de Microsoft, soit en contestant le monopole qu’il a été accusé de détenir, soit en rendant son plan de développement économique moins séduisant pour le futur. Dans cet exemple, selon l’accusation du gouvernement, Microsoft a été prompt à réagir : si votre plan d’affaires menace le sien, Microsoft le coulera. Selon le gouvernement, Gates n’était pas disposé à jouer à armes égales. (De fait, David Bank cite Gates « fulminant » contre un de ses directeurs, Paul Maritz : « Vous nous obligez à jouer à armes égales ! Vous allez couler l’entreprise ! »50).

  • 51 bid., p. 228 Et il est évident qu’il peut contrôler plus que le rythme de l’innovation. Mon souci d (...)

105Que l’on soit d’accord ou non pour dire que Microsoft avait adopté les pratiques que le gouvernement lui reproche (et quelles que soient les décisions finales de la cour d’appel et de la Cour Suprême sur ces violations supposées des lois antitrust), il faut surtout retenir ceci : Microsoft n’a pu se comporter ainsi que parce qu’il pouvait garder la mainmise sur son propre code. Le code source de son système d’exploitation est fermé ; cette source n’est pas révélée au grand public. De cette façon, Microsoft peut le modifier et orienter son code source dans des directions qui correspondent à ses visées stratégiques. C’est parce que son code source est fermé que la société est capable d’adopter des stratégies anticoncurrentielles, comme de le modifier pour gêner ses concurrents. Il peut « réguler le rythme de l’innovation » parce qu’il est le seul à pouvoir trafiquer son code51.

106C’est exactement le genre de possibilité que n’autorise pas un code ouvert. Un projet open code ne peut pas obliger à la vente liée d’un second produit dont les utilisateurs ne voudraient pas ; comme le code source est libre d’accès, les utilisateurs sont toujours capables de dissocier les deux produits. Un projet open source ne peut pas miner un système concurrent ; celui-ci est toujours capable de reprendre le système open source et de réagir. D’une certaine façon, le code source de ces projets est une sorte de contrepoids à leur propre pouvoir ; c’est une limite à sa capacité d’adopter des stratégies anticoncurrentielles contre quoi que ce soit qui serait « surimprimé » sur la plate-forme.

107Ce contrepoids correspond au fait qu’un projet ouvert est toujours susceptible de « bifurquer ». C’est ce qui se passe quand un projet mené dans une direction donnée se subdivise pour se développer dans deux directions, voire plus. Cette possibilité de bifurcation est garantie à la fois par le code (le code source est disponible) et par la loi (parce que la licence des projets open code garantit que les gens sont libres de le reprendre et de le développer dans des directions nouvelles). À partir du même code de base, les développeurs ont la possibilité d’en développer différentes versions, qui peuvent avoir leur propre vie autonome. À l’extrême, ces bifurcations pourraient diviser la communauté des utilisateurs en autant de chapelles. Un projet qui était en pleine prospérité parce qu’il avait tant de milliers d’utilisateurs pourrait disparaître s’il n’était plus soutenu par un nombre suffisant d’entre eux.

  • 52 Un des plus importants clones d’Unix était un projet nommé BSD (« Berkeley Software Distribution ») (...)
  • 53 Il y a un débat intéressant mais non tranché sur la question de savoir si la GPL (la plus stricte d (...)
  • 54 Ibid., p. 210.

108Cette menace que représente la bifurcation n’est pas sans fondement. D’importants projets open source, par exemple BSD Unix, ont déjà bifurqué dans le passé52 et, dans les licences actuelles des projets open code, il n’y a rien qui permettrait de diminuer cette menace pour le futur53. Au contraire, la possibilité d’une bifurcation maintient la pression sur les gardiens d’un projet open code afin qu’ils le développent dans un sens qui convienne à la plus grande majorité des utilisateurs. Ainsi que le dit Peter Wayner, « elle empêche une personne ou un petit groupe de personnes de contrarier un autre groupe »54.

109Ce sont les règles de la démocratie transposées au code. Un système open code ne peut pas trop s’écarter de la volonté de ses utilisateurs sans créer chez certains d’entre eux une importante incitation à diriger le projet dans d’autres directions. Ce qui signifie que la plate-forme ne peut pas utiliser de stratégies anticoncurrentielles contre son propre système. La menace qui a entraîné les poursuites fédérales dans l’affaire Microsoft n’a pas de sens quand un système d’exploitation est construit sur du code ouvert. Et l’absence de comportement anticoncurrentiel incite les tiers à bâtir sur ce code.

110Je ne veux pas dire par là que cette neutralité serait le seul facteur qui amène les programmeurs à travailler sur une plate-forme plutôt qu’une autre. Si 99 % des utilisateurs sont sur une plate-forme fermée et 1 % sur une plate-forme ouverte, alors il y aura une pression importante afin de programmer pour ce groupe ultra majoritaire, sans tenir compte des intérêts des utilisateurs de la plate-forme ouverte.

111Mais ce facteur n’est pas suffisamment bien compris et son effet sur l’innovation est systématiquement ignoré. Le phénomène dont nous parlons est similaire à celui que nous avons vu dans d’autres situations, et notre propos ici comme ailleurs est de mieux reconnaître son rôle dans la construction d’Internet tel qu’il s’est développé.

112Les utilisateurs de projets open source ne sont donc pas retenus en otages. C’est la conclusion qu’on peut retenir pour l’instant de ce qui précède. Ils ne sont pas les otages d’un code de mauvaise qualité : on leur reconnaît le droit de le modifier. Ils ne sont pas otages d’un code manipulable : un code ouvert ne peut pas être détourné pour des usages anticoncurrentiels. Ensemble, ces deux caractéristiques constituent le bien commun de l’innovation créé par Internet. Elles correspondent à l’intérêt public que défend le code ouvert.

113Mais les projets open code présentent une difficulté qui paraît pour beaucoup insurmontable : ils risquent de priver les inventeurs de codes ouverts de toute motivation. Le code ouvert crée un bien commun, mais le risque n’est pas de l’épuiser par surconsommation, comme les abus de vaine pâture. Au contraire, ainsi que le dit Eric Raymond, ce « révolutionnaire par accident » comme il se décrit lui-même, le code ouvert crée plutôt un « bien commun inversé », parce que

  • 55 Eric S. Raymond, op. cit., p. 151.

[...] sa consommation ne réduit pas la quantité de code disponible : elle l’augmente, un peu comme si l’herbe poussait plus vite derrière les moutons.55

114Le problème du code ouvert est au contraire de produire une motivation suffisante pour inciter l’apport de codes nouveaux ou améliorés. En d’autres termes, le code ouvert a un problème d’approvisionnement. Dans un univers où les logiciels se vendent comme du chewing-gum et où l’on considère qu’il est capital de conserver le contrôle de sa duplication, il est difficile à beaucoup de gens de comprendre comment on pourrait motiver les programmeurs pour qu’ils construisent un code qui sera donné gratuitement à qui le voudra.

115Mais ici il est préférable de voir les choses de façon empirique, et non idéologique. Il suffit de regarder autour de soi pour constater l’extraordinaire quantité de codes ouverts qui sont écrits, en dépit de toute possibilité d’en réglementer la copie. Ainsi que le dit Richard Stallman,

  • 56 Wayner, op. cit., p. 289.

nous élaborons quantité de logiciels, et s’il existe une théorie qui dit que ce n’est pas possible, c’est dans la théorie qu’il faut chercher l’erreur.56

116L’existence de cette pratique signifie que les programmeurs ont sans doute bien d’autres motivations pour participer à des projets open code. Cet état de fait montre que la capacité de réglementer le code n’est pas nécessaire pour motiver les individus à programmer.

117Au contraire, il y a beaucoup d’exemples où il peut être intéressant pour une compagnie de soutenir des projets open code sans avoir l’assurance d’en conserver la maîtrise totale. L’exemple le plus connu est celui d’IBM. En 1998, IBM décide d’abandonner son propre serveur pour utiliser le serveur ouvert Apache. D’une part, IBM était libre de le faire parce que ce serveur open source était totalement libre d’accès, d’autre part, la qualité de ce serveur était une motivation suffisante pour le faire.

  • 57 « IBM Extends Software Leadership on Linux », communiqué de presse d’IBM, 8 décembre 2000.

118C’est cette décision qui est à l’origine des relations particulières entre IBM et le mouvement open code. Après avoir adopté le serveur Apache, IBM se tourna vers le système d’exploitation Linux. Plutôt que de maintenir dix systèmes d’exploitation différents pour ses dix architectures différentes, IBM prit conscience de tout l’intérêt qu’il y aurait à les standardiser autour d’un système unique. En 2000, IBM vendait pour 30 millions de dollars de serveurs équipés de Linux. En 2004, IBM s’attendait à atteindre 3,4 milliards de dollars57. Et comme tous les ordinateurs d’IBM auront le même OS, il sera d’autant plus facile d’adapter le code d’un projet à l’autre.

119Mais la compagnie IBM ne s’est pas contentée d’utiliser à son profit les ressources des projets open code, elle a aussi consacré ses propres ressources au développement de Linux et d’Apache (pour plus d’un milliard de dollars selon ses chiffres). IBM utilise donc ses propres fonds pour obtenir quelque chose dont il pourrait profiter gratuitement.

  • 58 Les économistes commencent seulement à examiner les motivations des projets open code. Josh Lerner (...)

120Pourquoi ? Qu’est ce qui peut inciter une entreprise à payer pour ce qu’elle pourrait avoir sans frais58 ?

121Ce comportement, qui au premier abord est difficile à comprendre, cesse de l’être si l’on s’intéresse un peu à la nature des projets qu’IBM soutient.

122IBM gagne de l’argent en vendant des équipements, et il en vend d’autant plus que les logiciels qui fonctionnent dessus sont bons. Ainsi, soutenir des logiciels libres n’est rien d’autre qu’une façon de valoriser les équipements qu’il vend.

123Mais ce qui est plus important, c’est qu’IBM ajoute des éléments aux logiciels libres qu’il soutient. Le serveur Apache a été intégré dans une suite logicielle vendue par IBM, « WebSphere ». WebSphere possède tout un ensemble de fonctions Internet dont Apache n’est pas capable. Ainsi, l’intérêt de WebSphere augmente en même temps que les capacités d’Apache s’améliorent.

124Dès lors, la volonté d’IBM d’améliorer Apache et Linux n’est pas difficile à comprendre. La question qui reste en suspens, c’est de savoir pourquoi IBM restitue ses améliorations à la communauté. Pourquoi ne pas simplement prendre le serveur Apache et l’intégrer dans WebSphere tout en conservant les améliorations pour soi ? En d’autres termes, pourquoi ne pas simplement utiliser les ressources offertes par Apache et ensuite se retirer du mouvement open source ?

125La motivation qui pousse IBM à lui rester fidèle est liée à une caractéristique du processus de développement des logiciels : les programmes informatiques ne sont pas statiques, ils ont besoin d’évoluer. Si IBM voulait divorcer d’Apache en créant une version privée de ce serveur, il lui faudrait supporter un coût bien plus élevé pour maintenir cette seconde version à jour, au fur et à mesure que les fonctionnalités du serveur s’amélioreraient. Les contributions des tiers à l’architecture d’Apache devraient être intégrées à la version privée d’IBM. Repérer et mettre en œuvre ces changements reviendrait extrêmement cher.

126Ne serait-ce que d’un point de vue purement commercial, il est donc plus raisonnable pour IBM de soutenir (au minimum) le principe d’ouverture qui sous-tend Linux et Apache, même sans pouvoir s’approprier toute la valeur de sa contribution au code.

  • 59 Cet argument fait écho à une proposition de Cari Shapiro et de Hal R. Varian dans Information Rules (...)

127Autrement dit, IBM à plus à perdre qu’à gagner à ne pas divulguer ses améliorations59.

128Si ce comportement continue à vous sembler bizarre, replacez-le dans un contexte plus vaste. Le discours dominant en matière de logiciels consiste à dire qu’une entreprise qui a les pieds sur terre n’écrirait jamais de code sans s’assurer de conserver la mainmise totale sur lui. Mais le libre marché ne permet que rarement de se garantir un tel monopole, que ce soit à propos de code ou d’autre chose.

  • 60 La Starbucks Coffee Company est le leader mondial du café haut de gamme, avec une chaîne de détaill (...)

129C’est ce que les juristes ont du mal à saisir (étant eux-mêmes protégés par des règles d’exclusivité, comme les concours). La majorité de ce que notre société produit l’est sans qu’il existe aucune garantie de protection par l’État. Starbucks60 n’a obtenu aucun monopole gouvernemental avant de risquer des capitaux importants en ouvrant des cafés partout dans le monde. Tout ce dont la société était certaine, c’est que les clients de ses cafés devraient payer pour leur café, mais n’importe qui pouvait reprendre l’idée d’un coffee-shop haut de gamme. De la même façon, les fabricants de puces électroniques de par le monde investissent des milliards dans des usines sans jamais avoir la moindre assurance du gouvernement qu’un concurrent n’ouvrira pas une usine juste à côté.

130Dans chacun de ces cas, qui représentent la majorité des situations au sein d’une économie libre, l’idée géniale que peut avoir quelqu’un reste à la disposition de tout le monde. C’est le cas de Burger King et McDonald’s, Peet’s Coffee et Starbucks, de Peapod et de Webvan. Il ne fait pas de doute que les premiers à avoir eu ce genre d’idée commerciale préféreraient qu’elle ne puisse pas être utilisée par d’autres, ou que les autres n’en prennent pas conscience avant qu’ils aient eux-mêmes fidélisé une clientèle pendant une durée suffisante. Mais il est dans la nature des limites imposées aux brevets, comme dans celle des règles de transparence du marché, que les innovateurs ne peuvent pas garder leurs bonnes idées pour eux. Certes, la loi offre une certaine protection pour les idées et un peu plus pour leur expression, mais cette protection est incomplète et comporte des failles. Elle ne garantit jamais un contrôle parfait.

131Pourtant, les innovateurs innovent. Et ils innovent parce que le retour sur investissement quand ils diffusent leur innovation est élevé, même si d’autres personnes en profitent aussi. Les inventeurs ne se tournent pas les pouces en attendant d’être certains d’obtenir un bénéfice garanti ; les vrais capitalistes investissent et innovent en tenant compte du fait que leurs adversaires seront libres de reprendre leurs idées et de les retourner contre eux.

132Ainsi, plutôt que de se demander pourquoi des gens seraient prêts à programmer des systèmes libres, on peut aussi bien se demander pourquoi des gens sont prêts à innover sans être protégés par un monopole d’État. L’histoire nous enseigne que c’était l’idée dominante à une certaine époque. Certains croyaient qu’il était nécessaire de posséder des droits exclusifs pour que l’investissement puisse avoir un sens ; à une époque encore plus ancienne, la monarchie anglaise protégeait beaucoup d’investissements ordinaires à travers des monopoles royaux.

133Cependant, les marchés soumis à la concurrence ne fonctionnent pas de cette façon. On n’accorde pas de part de marché garantie à chaque marchand, on n’accorde pas à chaque nouveau projet économique de monopole sur vingt ans, on n’accorde pas de droits exclusifs à chaque nouvelle façon de faire des affaires. Dans chacun de ces cas, le marché est une cause de motivation suffisante par elle-même pour que le fait de voir des tiers prendre le train en marche ne tue pas l’innovation.

  • 61 our des études identifiant les scénarios dans lesquels cette proposition ne tient pas, voir Douglas (...)

134Dans le contexte du code, les faits nous apprennent la même leçon. Certes, IBM préférerait garder la haute main sur les améliorations apportées à Apache, mais le profit lié à la vente de serveurs de meilleure qualité est une motivation suffisante pour inciter IBM à investir sans bénéficier d’un contrôle total61. De même, si IBM offre des services supplémentaires sur ses serveurs, des serveurs rapides et plus fiables faciliteront la vente des services qui fonctionnent avec.

  • 62 Surnom d’IBM, par référence triple à la dimension proliférante qu’a pu avoir la compagnie à une épo (...)
  • 63 James Boyle, Shamans, Software, and Spleens : Law and the Construction of the Information Society ( (...)

135Ce qui est devenu évident pour « Big Blue »62 commence à le devenir partout ailleurs. Chez les programmeurs, l’esprit commerçant se porte de moins en moins bien. Et à mesure qu’il dépérit, les programmeurs apprennent ce que les marchés libres nous ont appris depuis Adam Smith : que l’innovation fonctionne mieux quand les idées circulent librement63.

136Il ne s’agit pas de dire que les logiciels devraient être entièrement libres ou que l’innovation devrait se passer de toute protection. Je ne suis pas hostile à une protection quand celle-ci est justifiée. Mon propos n’est pas de m’opposer à tous les systèmes de réglementation ; je veux simplement mettre à mal une idée reçue, selon laquelle, si un peu de réglementation est une bonne chose, davantage de réglementation serait forcément mieux.

  • 64 C’est tout spécialement le cas avec les systèmes embarqués qui ont explosé récemment en raison de l (...)

137Mon objectif dans ce chapitre était double. Dans la première partie, j’ai introduit l’idée de « code ouvert » et j’ai montré comment le code ouvert fonctionne au niveau de la couche des contenus pour y susciter les innovations les plus diverses. Ceci, grâce aux raisons avancées par les technophiles – parce qu’il est rapide, pas cher et puissant – , mais aussi pour des raisons qui sont trop souvent méconnues. En effet, en offrant au public une grande quantité de codes et de ressources pour programmer, le code ouvert abaisse les barrières à l’entrée du marché pour les inventeurs64. En construisant une plate-forme neutre, le code ouvert invite à une innovation spécifique. En protégeant cette plate-forme, à la fois par des licences et par la diffusion du code source, le système garantit aux développeurs que cette plate-forme restera ouverte dans le futur.

138Mais cette caractéristique du code ouvert ne se limite pas au domaine du code. Les leçons qu’elle nous enseigne peuvent être généralisées aux autres formes de contenus. Comme nous le verrons quand nous analyserons les lois sur le copyright, le juste milieu entre la liberté et la réglementation des ressources est précisément celui que la loi doit trouver dans le contexte des droits de propriété intellectuelle. Et alors que notre intuition nous enseigne qu’une réglementation plus contraignante entraîne plus d’innovation, ces biens communs sur le réseau des « câblés » suggèrent que le mécanisme est plus complexe. On peut montrer qu’une réglementation moindre sur le code de la couche des contenus a produit plus d’innovation et a contribué à son développement. Conserver cette ressource comme un bien commun accroît sa valeur, parce que des tiers peuvent s’en saisir, et parce que c’est un frein aux stratégies anticoncurrentielles. Nous examinerons ces jeux stratégiques plus en détail dans la troisième partie, chapitre 3.

Notes

1 chniquement, certaines de ces fonctions pourraient être obtenues si les logiciels étaient des applications claires des API (« Applications Program Interfaces »). Dans certaines situations, c’est une distinction importante mais je la laisserai de côté ici. Un programmeur suffisamment exercé pourrait aussi mieux connaître la nature d’un code compilé par l’application de la méthode de l’« ingénierie inversée ». Son succès dépendrait de la qualité de la structure du code originel.

2 Ceruzzi, A History of Modem Computing, p. 108.

3 Pour une histoire de Unix, voir William Shattuck, « The Meaning of UNIX », dans The Unix System Encyclopedia, Palo Alto, Calif., Yates Ventures, 2e éd., 1985, pp. 89, 93-94 ; Peter H. Salus, A Quarter Century of UNIX (Reading, Mass., Addison-Wesley Publishing Company, 1994, pp. 5-61 ; Ronda Hauben, « The History of UNIX », disponible sur http://www.dei.isep.ipp.pt/docs/unix.html .

4 Robert Young et Wendy Goldman Rohm, Under the Radar : How Red Hat Changed the Software Business – and Took Microsoft by Surprise, Scottsdale, Ariz., Coriolis Group Books, 1999, p. 21 ; Donald K. Rosenberg, Open Source : The Unauthorized White Papers, Foster City, Calif., Hungry Minds, 2000, p. 9.

5 Ceruzzi, op. cit., p. 94-95.

6 Ibid., p. 92.

7 Ibid., p. 283 (le résultat fut que « UNIX fut une bénédiction pour les départements d’informatique des universités »).

8 Young et Rohm, op. cit., p. 20.

9 Voir Richard Stallman, « The GNU Operating System and the Free Software Movement », dans Chris DiBona, Sam Ockman, et Mark Stone, éds., Open Sources : Voices from the Open Source Revolution, Pékin et Sébastopol, O’Reilly, 1999, p. 53-54.

10 Dans le monde idéal de Stallman, ce bien commun serait construit avec du code non-propriétarisé. Cependant, Stallman n’est pas hostile à des logiciels commerciaux. Comme il le dit, « les logiciels propriétarisés et commerciaux correspondent à deux notions complètement différentes. Ce qui est commercial fait référence à un arrangement financier sur le logiciel, tandis que ce qui est privé fait référence à ce que les utilisateurs sont autorisés à faire. Le logiciel libre doit autoriser la copie, la modification et l’accès au code source. Ainsi, le logiciel libre est antinomique avec le logiciel propriétarisé, mais il peut y avoir des situations où un logiciel commercial est libre ». Entretien téléphonique entre Hiroo Yamagata et Richard M. Stallman, 8 août 1997.

11 NU » pour « Not Unix » ; le G initial transforme ces initiales militantes en un acronyme humoristique (à prononcer comme gnu, « gnou »). NdT.

12 Peter Wayner, Free for All : How Linux and the Free Software Movement Undercut the High-Tech Titans, New York, HarperBusiness, 2000, p. 36.

13 Pour une discussion sur Richard Stallman et l’histoire GNU/Linux, voir ibid., pp. 9, 34-36, 67-68 ; Stallman, pp. 53-66 ; Mark Leon, « Richard Stallman, GNU/Linux », InfoWorld (9 octobre, 2000), p. 62.

14 Voir par exemple Linus Torvalds et David Diamond, Just for Fun : The Story of an Accidentai Revolutionary, New York, HarperBusiness, 2001 ; Pekka Himanen, Manuel Castells (épilogue), et Linus Torvalds (prologue), The Hacker Ethic and the Spirit of the Information Age (New York, Random House, 2001 ; Paula Rooney, « No. Il : The Dark Horse », Computer Reseller News, (15 novembre 1999).

15 En combinant vers 1992 Linux avec le système GNU incomplet, on obtint un système d’exploitation libre et complet (cette association en elle-même impliqua bien sûr un travail considérable). C’est grâce à Linux que nous pouvons avoir une version du système GNU aujourd’hui », Stallman, op. cit, p. 65.
Quant au nom qu’il convient de donner à ce système d’exploitation – « Linux » ou « GNU/Linux » –, c’est un débat qui fait rage. J’ai d’ailleurs reçu plus d’opinions véhémentes sur ce point que sur tous les autres qui sont abordés dans ce livre. Les partisans du mouvement du logiciel libre soutiennent que ce produit doit s’appeler GNU/Linux et se récrient que le nom « Linux » sous-estime l’importance de Stallman et de la Free Software Foundation. D’autres mettent l’accent sur le travail écrasant qu’a demandé cet OS libre et soutiennent que l’appelation « Linux » est suffisante. Comme me l’a expliqué Bob Young, le directeur de Red Hat, « alors que Linus se voit conférer plus de mérite qu’il n’en n’a vraiment pour avoir apporté les 16 Mo du noyau à cet OS de 800 Mo, Stallman est moins reconnu qu’il devrait l’être. Mais tandis que Linux jouit de bien plus de reconnaissance qu’il n’en demande, Richard en demande plus que ce qu’il mérite », courriel du 8 juin 2001.
Il est malheureux que dans le débat actuel sur les projets open source et le logiciel libre, tant d’énergie soit consacrée à des questions d’onomastique, suscitant de véritables emportements contre ceux qui sont coupables d’employer des termes inappropriés (« libre » là où « ouvert » est requis, ou « fermé » au lieu de « propriétarisé »). Je suis moi-même coupable de certains de ces péchés contre la terminologie et la plupart du temps ce n’est pas délibérément. Je me référerai en général à l’OS Linux en le nommant « Linux », tout en utilisant parfois « GNU/Linux » quand ce rappel sera utile. Le point important ici n’est pas de savoir qu’est-ce qui revient à qui, mais que le noyau de l’OS Linux soit diffusé sous la GPL de la Free Software Foundation. Je crois que c’est un élément clé du débat, et qu’il faut le garder clairement à l’esprit.

16 Pour une histoire récente et passionnante de la naissance de Linux, voir Glyn Moody, Rebel Code : Linux and the Open Source Revolution, Cambridge, Mass., Perseus Press, 2001.

17 Linus Torvalds, « The Linux Edge », dans Chris DiBona, Sam Ockman et Mark Stone, éds., op. cit., p. 101.

18 Torvalds, ibid., p. 101.

19 Moody, op. cit., p. 130. Voir aussi Dorte Toft, « Open Source Group Forms Nonprofit », Industry Standard (1er juillet 1999), sur :
http://www.thestandard.eom/article/0,1902,5377,00.html.

20 Voir http://www.isc.org/products/BIND/bind-history.html.

21 Tim O’Reilly, « Hardware, Software, and Infoware », dans Chris DiBona, Sam Ockman, et Mark Stone, éds. op. cit., p. 172.

22 Wayner, op. cit., p. 172.

23 Voir Carolyn Duffy Marsan, « Sendmail Adds Admin Console, IPv6 Support ; New Unix-Based Tool Can Manage Sendmail-Based E-mail Systems Across a Widespread Organization », Network World (7 février 2000).

24 Alan Cox, « This Is How Free Software Works », Wideopennews 5, 8.6 :
http://www2.usermagnet.com/cox/index.html.

25 ertains sont réticents à qualifier ces « droits exclusifs » de « monopoles » : voir Frank Easterbrook, « Intellectual Property Is Still Property », Harvard Journal of Law & Public Policy 13 (1991), p. 108-09. Techniquement, c’est pourtant ce qu’ils sont, mais cela ne signifie pas que le détenteur d’un droit exclusif est nécessairement en situation de « monopole ». Parler de ces droits en termes de « monopoles » a cependant l’intérêt de faire porter la charge de les défendre à ceux qui prétendent qu’ils sont bénéfiques. Telle était aussi la stratégie de Macaulay au milieu du xixe siècle. Voir Siva Vaidhyanathan, Copyrights and Copywrongs : The Rise of Intellectual Property and How It Threatens Creativity, New York : New York University Press, 2001, p. 142.

26 Lettre de Thomas Jefferson à Isaac McPherson (13 août 1813), dans The Writings of Thomas Jefferson, H. A. Washington, éd., vol. 6, 1861, pp. 175, 180.

27 La GPL est souvent qualifié de licence « copyleft », mais le copyleft repose fondamentalement sur le copyright. [À partir de right, à la fois « droit » (comme dans « main droite ») et « droit » au sens juridique, jeu de mots sur le double sens de left, celui de « gauche » (comme dans « main gauche ») et celui de « laissé », « abandonné », participe passé de to leave : le copyleft, ce serait moins un droit positif qu’un droit négatif, « ce qui me reste comme droit ». NdT.] Sans copyright, il n’y aurait aucun moyen de s’assurer que les utilisateurs d’un logiciel quelconque respectent les obligations du contrat de licence. Par exemple, un logiciel destiné au domaine public ne serait pas en mesure de garantir que ses utilisateurs se sentent liés par la GPL. Mais avec un code soumis au droit d’auteur et diffusé avec la GPL, l’utilisateur doit respecter le contrat, ou devenir contrefacteur.
Comme je le montre plus loin, la GPL n’est pas la seule licence de logiciel libre, ni même peut-être la plus importante. D’autres licences open code s’en différencient en n’obligeant pas à ce que les logiciels ouvrent aussi leur code source. Pour une étude de la compatibilité de la GPL avec le droit allemand, voir Axel Metzger et Till Jaeger, « Open Source Software and German Copyright Law », International Review of Industrial Property & Copyright Law 32 (2001), p. 52.

28 Voir http://www.fsf.org/copyleft/gpl.html.

29 Stallman, op. cit., p. 56.

30 Voir Moody, op. cit., p. 168

31 our une discussion plus complète sur les différentes licences et leurs implications, voir David McGowan, « Legal Implications of Open Source Software », University of Illinois Law Review (2001), pp. 101, 113-19 ; Patrick K. Bobko, « Can Copyright Keep “Open Source” Software Free ? », AIPLA Quarterly Journal 28 (2000), p. 81 ; Ira V. Heffan, « Note : Copyleft : Licensing Collaborative Works in the Digital Age », Stanford Law Review 49 (1997), p. 1487 ; Daniel B. Ravicher, « Facilitating Collaborative Software Development : The Enforceability of Mass-Market Public Software Licences », Virginia Journal of Law & Technology 5 (2000), p. 11.

32 Wayner, op. cit. p. 260.

33 OS X, le dernier système d’exploitation d’Apple, inclut une partie appelée « Darwin » qui est diffusée avec un contrat open source. Voir :
http://www.apple.com/macosx/tour/darwin.html.

34 Pour une analyse détaillée de ce procès, voir Ken Auletta, World War 3.0 : Microsoft and Its Enemies, New York, Random House, 2001 ; David Bank, Breaking Windows : How Bill Gates Fumbled the Future of Microsoft, New York, Free Press, 2001 ; John Heilemann, Pride Before the Fall : The Trials of Bill Gates and the End of the Microsoft Era, New York, HarperCollins, 2001.

35 e gouvernement n’est pas le seul à avancer cette affirmation. Comme le dit le PDG de Red Hat, Bob Young, « Microsoft semble aller jusqu’à dicter aux autres compagnies la vitesse à laquelle elles peuvent sortir de nouveaux produits – voire si elles peuvent même les sortir tout court ». Young et Rohm, op. cit., p. 7.

36 Il y a eu des tentatives d’interfaces graphiques pour ordinateurs personnels avant que Microsoft ne tombe sur le filon Windows, notamment VisiOn (de VisiCalc), Top View (d’IBM), GEM (de Digital Research), et Interface Manager (précurseur de Windows chez Microsoft) ; aucune n’a vraiment réussi à percer. Voir Ceruzzi, op. cit., p. 276.

37 Il est bien connu que l’entreprise n’a pas vraiment écrit ce DOS, elle a simplement obtenu une licence auprès de Tim Paterson, de la compagnie Seattle Computer Products. Microsoft a payé « environ 15 000 dollars pour le droit d’utiliser son travail ». Plus tard, Microsoft déboursa davantage encore pour obtenir tous les droits du logiciel. Ibid., p. 270.

38 Stan Miastkowski, « A Cure for What Ails DOS », BYTE (août 1990), p. 107.

39 Affaire Caldera vs Microsoft, 72 F. 2e suppl., pp. 1295, 1299 (district de l’Utah, 1999).

40 Jim Carlton, Apple : The Intrigue, Egomania, and Business Blunders That Toppled an American Icon, New York, Times Books/Random House, 1997, pp. 39-47.

41 Ibid., p. 28.

42 « GUI » pourrait se prononcer comme guy (un « type », un « mec », pl. guys) ; prononcer l’acronyme comme gooey (« sirupeux, larmoyant, gluant ») est plus péjoratif qu’humoristique. Rappelons qu’en anglais les acronymes peuvent prendre le – s du pluriel (« GUIs »). NdT.

43 « Il y a comportement anticoncurrentiel [strategic behavior] dès que deux individus ou plus interagissent et que leurs décisions individuelles reposent sur ce que chacun attend de l’autre », Douglas G. Baird, Robert H. Gertner et Randal C. Picker, Game Theory and the Law, Cambridge, Mass., Harvard University Press, 1994, p. 1. J’emploie ce terme en le limitant aux cas où le comportement qui en résulte pose des problèmes au sens du droit de la concurrence.
Comme le dit David Bank, la notion de stratégie anticoncurrentielle adoptée par Microsoft pour protéger sa base est au cœur de la structure de ses produits. C’est ce qu’au sein de la compagnie on appelait le « coût stratégique » ou « taxe anti-concurrence ». Bank : « Gates revenait inlassablement sur le même point : être plus “stratégique”. Ce qu’il voulait, c‘était rendre sa clientèle captive, les chaînes aux pieds. Son objectif était de rendre les différents produits Microsoft interdépendants, pour compliquer la tâche des consommateurs qui voudraient passer à la concurrence pour la moindre application » (Bank, op. cit., p. 134). Gates plaçait son souci « d’avantage stratégique » au-dessus du respect du consommateur. Comme il le dit lui-même dans un courriel intitulé « l’ouverture HTML » : « Les gens suggéraient que [le produit] Office devrait fonctionner avec tous les navigateurs et que nous ne devrions pas obliger les utilisateurs à choisir le nôtre. [...] C’était une erreur que je voulais corriger » (ibid., pp. 73-74). C’est pour cela que, suivant ses instructions, le produit devait être désigné comme « Office/Windows/ Microsoft specific » (ibid.). Selon Banks, ce « coût stratégique » était « profondément démoralisant » (ibid., p. 134). Les équipes travaillant sur les logiciels voulaient « vaincre par leur propre mérite » (ibid.), et non pas grâce à des pièges cachés dans le code. Plus généralement, selon Banks, beaucoup d’employés de l’entreprise pensaient que le « coût stratégique » finirait par causer du tort à la compétitivité de Microsoft. Ainsi que Ben Slivka l’a dit à Gates, « je pense que votre idée fixe de “code commun” à tous nos produits comme un but en soi a fini par étouffer l’innovation » (ibid., p. 99). Slivka était partisan d’une « innovation sans entraves », libérée des « contraintes des licences accumulées par l’entreprise » (ibid.). Un autre cadre supérieur nommé Brad Silverberg écrivait : « Je ne veux pas passer ma vie dans des réunions à débattre de problèmes internes, à recevoir des notes excitées de Bill, ou à recevoir de je ne sais pas qui l’injonction de faire des choses contre nature et de laisser tomber des recherches utiles pour “protéger” Windows » (ibid., p. 175).
L’idée qu’une entreprise pourrait réussir sur le marché sans mainmise propriétarisée – c’est-à-dire sans « coût stratégique » – peut sembler à courte vue. Des entreprises comme Cisco démontrent pourtant que le succès peut venir d’autre chose que de jouer à des jeux stratégiques sur les plates-formes. Cisco s’est développée en construisant à partir d’une plate-forme neutre et non-propriétarisée les protocoles TCP/IP. Certes, la concurrence est rude, mais le succès a quand même été au rendez-vous.
Comme je le montre dans le chapitre 6 de la troisième partie, Banks estime que la stratégie interne de Microsoft a désormais évolué en faveur de la neutralité plutôt que d’une « taxe » sur la concurrence.

44 Elizabeth Corcoran, « Microsoft Deal Came Down to a Phone Call », Washington Post (18 juillet 1994), p. A1.

45 bid.

46 David Bank : « À trois heures du matin par un matin pluvieux d’avril 95, Gates annonça par courriel à ses lieutenants les plus proches que “l’Internet est en train de détruire notre position de créateur de standards [...]. Il mine notre puissance de plus en plus chaque jour et à ce rythme il l’aura érodé de manière irréversible au moment où la bande passante large sera généralisée, au rythme où vont les choses actuellement” », Bank, op. cit., p. 26. Pour Gates, le cœur de la menace était Netscape. « En tant que standard, Netscape devient plus important que Windows », écrivait-il. Le navigateur de Netscape « transformerait le système d’exploitation sous-jacent en un bien commun », ibid., p. 27.
Gates était aussi préoccupé par l’adoption de Java par Microsoft. Après avoir lu une analyse qui plaidait pour un développement neutre de Java, il écrivait : « Cela me terrifie . [...] Je ne vois pas encore clairement ce que nos systèmes d’exploitation peuvent apporter de plus à Java pour les rendre suffisamment convaincants pour que nous conservions notre position sur le marché. » Ibid.

47 Le gouvernement s’est appuyé sur des preuves fournies par les propres courriels et déclarations de Gates. Voir United States vs Microsoft, 84F, 2e suppl., 9, pp. 59-60 D.. D.. C., 1999).

48 On a sans doute tort de sur-interpréter le terme assez vague « levier », leverage, mais il est clair que les cadres de Microsoft pensaient que « faire levier » pour Internet Explorer grâce à l’utilisation de Windows était la meilleure façon de gagner des parts de marché. Voir Bank, op. cit., p. 70 (citant Allchin). « Nous devrions d’abord penser à une solution intégrée – là est notre force », ibid., p. 69.
Pour une analyse attentive de la pensée économique actuelle sur la vente couplée et les contrats d’exclusivité (qui sont au centre de l’affaire Microsoft), voir Michael D. Whinston, « Exclusivity and Tying in United States vs Microsoft : What We Know, and Don’t Know », Journal of Economie Perspectives 15 (2001), p. 63.

49 Bank, op. cit., pp. 11, 13.

50 Ibid., p. 212

51 bid., p. 228 Et il est évident qu’il peut contrôler plus que le rythme de l’innovation. Mon souci dans Code and Other Laws of Cyberspace était précisément la réglementation qui peut passer par le code – « le code, c’est la loi » – ; plus le code contrôle notre vie, plus nous devrions être attentifs à savoir qui sont ses programmeurs. Denise Caruso a écrit des pages puissantes sur ce sujet. Selon elle, « il est encore vrai aujourd’hui que les logiciels, écrits par des équipes de programmeurs insomniaques dans des bureaux minuscules qui sentent le renfermé, sont la loi absolue qui régit notre vie numérique. Nous ne sommes pas libres de changer ce code ; nous ne pouvons que nous incliner ou le rejeter. Dans le procès Microsoft [...], la vraie bataille est de savoir quelle loi doit prévaloir, celle du logiciel ou celle de l’État », « The Legacy of Microsoft’s Trial », New York Times (6 décembre 1999), disponible sur :
http://www.nytimes.com/library/tech/99/12/biztech/articles/06digi.html.
Elle ajoute : « Le cyberespace est déjà régi par le code des logiciels, qui décide par sa nature même si et à quelles conditions nous aurons un droit à la vie privée et à l’anonymat, comme il décide de qui peut avoir accès et comment. Certes, ce n’était pas si terrifiant tant que les logiciels qui faisaient fonctionner l’Internet étaient construits sur des standards ouverts, mais la situation est devenue beaucoup plus dangereuse maintenant que le code est devenu commercial, donc privé, et que le public n’y a pas accès pour l’analyser. [...] Si les logiciels commerciaux commencent à déterminer la structure d’Internet, cela conduira à l’apparition d’une sorte de droit privatisé qui devra être réglementé au nom de l’intérêt public et des valeurs démocratiques », ibid.

52 Un des plus importants clones d’Unix était un projet nommé BSD (« Berkeley Software Distribution »). Le projet BSD naquit alors que Unix était encore libre. Après en avoir repris le contrôle, AT & T exigea que BSD cesse sa diffusion. BSD refusa et il y eut un procès. Après de longs débats, le droit de BSD de continuer à diffuser sa version d’Unix (avec quelques modifications d’écriture de code) en dépit d’AT & T fut confirmé par un accord. Pour plus de détails sur le procès BSD et sur BSD en général, voir Wayner, op. cit., pp. 38, 49-54 (sur le procès intenté par AT & T à BSD), et pp. 92- 95 (sur le développement de BSD) ; Cheryl Garber, « USL v. Berkeley », UNIX Review 10 (1992), p. 32.
BSD abandonna son code par un contrat de licence très libéral. N’importe qui était autorisé à en faire n’importe quoi, pourvu que les droits soient énoncés. Mais quand des groupes se mirent en place pour soutenir ce code libre, des divisions apparurent au sein des troupes ; partant de cette base BSD commune, le projet bifurqua entre différentes branches, dont FreeBSD, NetBSD et OpenBSD, entre autres. Wayner, op. cit., pp. 98-99.

53 Il y a un débat intéressant mais non tranché sur la question de savoir si la GPL (la plus stricte des licences open code) ne fait pas plus pour réduire le risque de bifurcation que les licences open code plus laxistes. Comparez Young et Rohm, op. cit., p. 180 (la GPL réduit les risques de bifurcation), et Wayner, op. cit., p. 221 (défendant l’opinion contraire).

54 Ibid., p. 210.

55 Eric S. Raymond, op. cit., p. 151.

56 Wayner, op. cit., p. 289.

57 « IBM Extends Software Leadership on Linux », communiqué de presse d’IBM, 8 décembre 2000.

58 Les économistes commencent seulement à examiner les motivations des projets open code. Josh Lerner et Jean Tirole en ont résumé quelques-unes, à propos de projets fermés : (1) une baisse des coûts due à (a) une bonne familiarité avec le code, grâce par exemple à l’enseignement universitaire, et (b) la possibilité de le personnaliser et un débogage plus facile ; (2) des profits plus élevés, notamment grâce à (a) une meilleure mesure des performances (expertise plus facile à montrer), (b) « une initiative totale » (en raison de l’absence de supervision hiérarchique), et (c) une plus grande fluidité du marché du travail. Voir Josh Lerner et Jean Tirole, « The Simple Economies of Open Source » (document d’étude du NBER, n° 7600, décembre 2000).
James Bessen offre un modèle bien plus ambitieux des bénéfices qu’on peut attendre des projets open code. Il explique que la fécondité de l’open code est supérieure à celle du code propriétarisé quand un bien public est complexe (par ex. un logiciel). Son intuition est que les coûts de débogage d’un logiciel complexe deviennent prohibitifs dans un environnement fermé. Selon lui, « si un produit a 100 caractéristiques indépendantes et que chaque combinaison ne prend qu’une seconde à être testée, le travail ne sera jamais fini avant que le Soleil n’engloutisse la Terre, même si tous les humains passent jusqu’à ce moment-là toutes les secondes de leur vie à tester », James Bessen, « Open Source Software : Free Provision of Complex Public Goods » (document de travail, avril 2001), http://researchoninnovation.org. Bessen conclut que des « droit de propriété forts [...] peuvent en fait limiter la production de biens publics complexes », et que les projets open code bénéficient donc d’un avantage compétitif sur ceux qui sont fermés.

59 Cet argument fait écho à une proposition de Cari Shapiro et de Hal R. Varian dans Information Rules : A Strategie Guide to the Network Economy, Boston, Mass., Harvard Business School Press, 1999, pp. 256-59. Comme ils le montrent, dans un marché qui dépend étroitement de standards, les concurrents ont souvent intérêt à contribuer à des standards publics plutôt que de les privatiser. La bataille sur le standard HTML en est un exemple. Pendant un moment, Microsoft et Netscape essayèrent en même temps de développer leurs extensions de HTML adaptées à leurs propres serveurs et logiciels de développement Web. L’objectif était de se séparer du standard de base commun pour inciter le marché à suivre leur propre architecture. Plus tard cependant, ils décidèrent ensemble apparemment que cet effort ne leur serait pas profitable, qu’il serait mieux d’avoir une plate-forme commune accueillante plutôt que des plates-formes privées de petite taille intéressant chacune peu de monde. Varian et Shapiro montrent à quelles conditions ce comportement devient logique. Voir aussi Hal R. Varian, « Buying, Sharing, and Renting Information Goods », Journal of Industrial Economies 48 (2000), p. 473. À propos de l’attitude de Microsoft face à un HTML neutre, voir Bank, op. cit., p. 74 ; voir aussi ibid., p. 73 (à propos d’« Office »). Voir aussi Moody, op. cit., p. 200. Moody pense que c’est parce qu’Apache était le serveur leader pour le HTTP et qu’il n’était commercialement contrôlé par personne qu’il ne s’est pas écroulé de la même façon : ibid., p. 149.

60 La Starbucks Coffee Company est le leader mondial du café haut de gamme, avec une chaîne de détaillants et de salons de dégustation dans le monde entier. « Peet’s Coffee and Tea » adopte le même principe pour le thé comme que le café. NdT.

61 our des études identifiant les scénarios dans lesquels cette proposition ne tient pas, voir Douglas Lichtman et al., « Shared Information Goods », Journal of Law & Economics 42 (1999), p. 117 ; Hal R. Varian, op. cit., p. 473 ; Douglas Lichtman, « Property Rights in Emerging Platform Technologies », Journal of Legal Studies 29 (2000), p. 615.

62 Surnom d’IBM, par référence triple à la dimension proliférante qu’a pu avoir la compagnie à une époque, au « Big Brother » de 1984 d’Orwell, et à la couleur bleue de son logo. NdT.

63 James Boyle, Shamans, Software, and Spleens : Law and the Construction of the Information Society (Cambridge, Mass., Harvard University Press, 1996, ch. 4.

64 C’est tout spécialement le cas avec les systèmes embarqués qui ont explosé récemment en raison de la capacité d’incorporer librement les éléments essentiels d’un système d’exploitation. Voir « Embedded Linux Basics », http://lw.itworld.com/linux-world/lw-2000-05/lw-05-embedded_p.html ; « Companies Bet on Embedded Linux », http://www.forbes.com/2000/04/07/mu4.html.

© Presses universitaires de Lyon, 2005

Conditions d’utilisation : http://www.openedition.org/6540

Cette publication numérique est issue d’un traitement automatique par reconnaissance optique de caractères.
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search