Un procès de deux ans, une distribution paralysée, un écosystème qui bascule. Au bout, un accord qui retire trois fichiers sur dix-huit mille. L’histoire vaut d’être racontée correctement, parce que le chiffre qui circule cette semaine n’est pas le bon.
Le sujet est ressorti il y a deux jours dans la presse technique anglophone, sous un titre qui claque : AT&T aurait attaqué Berkeley pour 186 lignes de code, et ce procès aurait offert le marché à Linux. La seconde moitié est vraie. La première, je n’ai pas réussi à la vérifier, et ce qu’on trouve à la place est plus intéressant.
D’où vient le code contesté
Il faut remonter avant le procès, sinon on ne comprend pas ce que Berkeley défendait.
BSD n’est pas un Unix concurrent, c’est un Unix d’AT&T que l’université de Californie améliore depuis 1974, sous licence. Pendant quinze ans, tout ce que Berkeley ajoute (la pile réseau, le système de fichiers rapide, la mémoire virtuelle) vient s’empiler sur une base qui appartient à quelqu’un d’autre. Pour utiliser BSD légalement, il faut payer une licence Unix à AT&T.
En juin 1989, Berkeley publie Networking Release 1 : uniquement le code réseau, écrit entièrement en dehors d’AT&T, donc libre de droits. C’est la preuve de concept.
Puis Keith Bostic pose la vraie question : et si on remplaçait tout le reste ? Il lance un appel et organise la réimplémentation des utilitaires standard d’Unix, sans jamais regarder le code d’AT&T. En dix-huit mois, ils sont tous remplacés, et il ne reste que quelques fichiers d’AT&T dans le noyau.
C’est ce qui sort en juin 1991 sous le nom de Networking Release 2 : un système d’exploitation presque complet, librement redistribuable. Presque, parce que ce « quelques fichiers » n’a jamais été zéro, et que Berkeley le savait.
Dix mois plus tard, AT&T attaque.
Ce qui s’est passé
Avril 1992. UNIX System Laboratories, la filiale d’AT&T qui détient Unix, dépose plainte devant un tribunal fédéral du New Jersey. En face : Berkeley Software Design, une jeune société qui vend un Unix pour PC à mille dollars là où AT&T en demande plusieurs dizaines de milliers, et les Regents de l’université de Californie, d’où sort la distribution qui a tout permis.
L’objet du litige est le code. Berkeley a publié Networking Release 2, environ un million et demi de lignes, en affirmant que tout ce qui restait d’AT&T en avait été retiré. USL soutient le contraire.
Ce qui suit ressemble peu à une bataille juridique de cinéma. La demande d’injonction préliminaire d’USL, celle qui aurait tout arrêté, est rejetée après six semaines de délibéré. Puis la procédure s’installe, et elle dure. Le règlement à l’amiable arrive en février 1994, presque deux ans après le dépôt.
Le chiffre du dossier
Voici les termes, et ils tiennent en deux lignes : trois fichiers retirés de la distribution Berkeley, qui en comptait environ dix-huit mille, et soixante-dix fichiers modifiés pour porter une mention de copyright d’USL. La version 4.4BSD-Lite sort ensuite, sans aucun fichier contesté.
Trois sur dix-huit mille. C’est le résultat de deux ans de procédure.
Le chiffre de 186 que reprennent les articles de cette semaine, je ne l’ai trouvé ni dans la fiche encyclopédique du procès, ni dans l’histoire de FreeBSD publiée par Klara Systems, qui sont les deux sources sérieuses auxquelles j’ai accès. Il vient probablement d’un rapport d’expert cité ailleurs, à un stade de la procédure où la liste des fichiers suspects était bien plus longue que la liste finale. C’est plausible. Je ne peux pas l’écrire comme un fait, donc je ne l’écris pas.
Et franchement, le chiffre du règlement est meilleur. Trois fichiers, c’est le genre de chose qu’on corrige un vendredi après-midi.
Ce que le procès a vraiment coûté
Si le résultat est si maigre, d’où vient l’idée que ce procès a changé l’histoire ?
Pas du jugement. De l’incertitude.
Entre 1992 et 1994, personne ne savait ce que BSD allait devenir. Une entreprise qui envisageait de bâtir un produit dessus voyait un procès en cours dont l’issue pouvait rendre son socle illégal. Un développeur qui hésitait entre deux systèmes libres en voyait un poursuivi par AT&T et un autre écrit par un étudiant finlandais que personne n’attaquait.
Jordan Hubbard, cofondateur de FreeBSD, l’a dit sans détour : l’épisode a cédé le terrain à Linux pendant une période critique, marquée par un vide de direction et beaucoup de peur, d’incertitude et de doute dans la communauté BSD.
Ce sont exactement ces deux ans qui ont manqué. Le noyau Linux est annoncé en 1991. En 1994, quand BSD est enfin tiré d’affaire, Linux a eu trois ans pour rassembler des développeurs, des distributions et des utilisateurs. La partie n’était pas techniquement jouée. Elle était socialement jouée, ce qui est plus difficile à rattraper.
Ce que ça dit, et pourquoi ça revient maintenant
J’ai longtemps cru que les technologies gagnaient parce qu’elles étaient meilleures. Cette histoire dit autre chose : elles gagnent parce qu’on peut les adopter sans avoir à demander l’avis d’un juriste.
BSD était, en 1992, techniquement plus mûr que Linux. Il avait la pile réseau, il avait des années d’ingénierie universitaire, il avait des gens qui savaient ce qu’ils faisaient. Ça n’a pas suffi, parce que la question n’était plus « lequel est le meilleur » mais « lequel ne va pas me valoir une lettre d’avocat ».
C’est pour ça que l’histoire revient régulièrement, et qu’elle n’est pas un morceau de folklore. Le même mécanisme tourne aujourd’hui, avec d’autres acteurs. Un modèle dont les poids sont publiés sous une licence maison que personne n’a lue en entier. Une bibliothèque dont le propriétaire change de licence du jour au lendemain. Du code écrit par un assistant dont personne ne sait dire ce qu’il reproduit, et des projets qui, faute de réponse, préfèrent l’interdire.
Dans chacun de ces cas, ce qui coûte n’est pas le procès. C’est l’année où personne ne sait.
Ce que je retiens
Trois choses.
La première : quand un chiffre circule avec un titre qui claque, il y a une chance sur deux qu’il vienne d’une étape intermédiaire d’un dossier, pas de sa conclusion. Deux minutes de vérification suffisent souvent, et cette fois elles ont changé l’article.
La deuxième : la clarté juridique est une fonctionnalité. C’est d’ailleurs pour ça que nous avons fabriqué un décodeur de licence : savoir ce qu’on a le droit de faire ne devrait pas demander un juriste. Pas une formalité qu’on règle après avoir écrit le code, une fonctionnalité, au même titre que la vitesse ou la documentation. Un projet dont la licence est limpide et vérifiable a un avantage concret sur un projet équivalent qui ne l’est pas.
La troisième, et c’est la moins confortable : Berkeley avait raison sur le fond. Trois fichiers, ça veut dire que le nettoyage avait été fait correctement à 99,98 %. Avoir raison n’a servi à rien, parce que le temps que ça prenne d’établir qu’ils avaient raison, la place était prise.
Il y a des batailles qu’on perd en les gagnant.
