Cette histoire pourrait-elle se répéter pour Linux ? Il est vrai que
la licence GPL (GNU General Public License) offre aux développeurs Open
Source le droit explicite d’utiliser et transformer n’importe quel
projet sous GPL, ouvrant ainsi la porte à une "divergence de code"
potentiellement nuisible. Pourtant, apparent paradoxe, les développeurs
Open Source considèrent ce droit à la divergence comme un mécanisme de
protection contre le risque réel de divergence. Et ils fustigent
l’absence de ce droit dans la licence SCSL (Sun Community Source
License) utilisée pour Java, Solaris et Jini, considérant SCSL comme
une piètre alternative à la GPL, pourtant plus permissive.

C’est un défi pour ceux qui veulent implanter Linux en milieu
professionnel : il leur faut sans doute se battre pour surmonter les
craintes des utilisateurs que GNU/Linux ne s’éparpille en des centaines
de versions incompatibles du fait de l’absence de prise en charge par
une unique grande société. Et voici où je veux en venir, demandant s’il
n’est pas extravagant que les licences Open Source garantissent à
quiconque le droit de faire précisément ce que l’on souhaite éviter.

Cela vous semble contradictoire ? C’est vrai, c’est une réponse rapide
et grossière. Le détail arrive : Linux ne se divisera pas parce que
cela représenterait pour le diviseur un travail excessif pour un profit
nul : les améliorations intéressantes seraient absorbées par le courant
principal tandis que le reste de la branche divergente, inutile, serait
écarté ou ignoré.

Ce phénomène se constate pour Linux, malgré que ce n’ait pas
toujours été le cas pour des projets antérieurs, et c’est là
précisément l’effet de la licence du code-source de Linux.

DES EXEMPLES REMARQUABLES DE DIVERGENCES

1. Unix —> des dizaines d’Unix "propriétaires"

Si vous connaissez l’histoire d’Unix, vous savez qu’Unix était un
produit accidentel des laboratoires Bell d’AT&T, vers 1969. Je vais
négliger beaucoup de détails de cette longue histoire, mais ce qu’il y
a de plus important à connaître est qu’AT&T était à l’époque sous le
coup d’une mesure de justice antitrust (qui a expiré vers 1980) qui lui
interdisait d’entrer dans le secteur des ordinateurs et du logiciel. Se
trouvant ainsi dans l’impossibilité légale de vendre Unix, AT&T vendit
des licences pour son code-source (et aussi par la même occasion le
droit d’utiliser le nom déposé "Unix") à des universités comme celle de
Berkeley, ainsi qu’à des sociétés privées comme IBM, Apple, DEC, Data
General, SGI, SCO, HP, etc.

Ces compagnies obtenaient ainsi le droit de concevoir leurs propres
Unixes : IBM édita AIX, Apple sortit A/UX. DEC fit Ultrix, OSF/1 et
Digital Unix (renommé plus tard "Compaq Unix" et maintenant "Compaq
Tru64"). DG/UX fut créé par Data General, IRIX par SGI, HP/UX par HP,
et SCO sortit XENIX qui se transforma en fin de compte en SCO UNIX. On
pourrait en citer encore d’autres que je vous épargnerai.

Le problème, c’est que ce sont ces types qui ruinèrent Unix. Chacun
d’eux vantait son Unix mutant comme un "Unix plus" — tout ce que les
autres ont et plus encore. Ayant besoin de différenciation, c’est
délibérément qu’ils rendirent leurs Unixes incompatibles, alors même
qu’en paroles ils soutenaient les "standards".

Pour les utilisateurs, la messe était dite, et Microsoft s’engouffra
dans la brèche de la désunion comme un char Sherman.
C’est l’exemple classique de divergence, celui qui vient tout de suite
à l’esprit des gens.

2. BSD —> FreeBSD, NetBSD, OpenBSD, BSD OS, MachTen, NeXTStep (qui
s’est récemment transformé en Apple Macintosh OS X Server), et SunOS
(appelé maintenant Solaris)

Les mesures antitrust limitaient donc AT&T qui, ne pouvant vendre
Unix, diffusa des licences très bon marché de son code-source à des
universités, notamment Berkeley. Berkeley joua le rôle de meneur dans
le monde universitaire : ayant accès au code-source, ils réalisèrent
rapidement qu’ils pouvaient le réécrire pour l’améliorer, ce qu’ils
firent peu à peu. Leur version était qualifiée de "BSD" (Berkeley
Software Distribution) et ils étaient heureux de la partager avec
quiconque ayant comme eux une licence d’AT&T pour les sources Unix.

Or leur travail était en général largement meilleur que celui des
laboratoires Bell, en partie du fait qu’il bénéficiait des retours des
universités du monde entier, d’une façon très proche du modèle Open
Source. Au bout de quelques années, sans qu’il y ait eu - de prime
abord - d’intention délibérée, la quasi-totalité du code d’AT&T était
réécrit.

Un beau jour, Keith Bostic, un étudiant inspiré par le projet GNU de
Richard M. Stallman (vous voyez de qui je parle ?), vint trouver les
responsables du développement de BSD et leur proposa de remplacer ce
qu’il restait du travail d’AT&T dans BSD afin de créer un BSD vraiment
libre. Craignant des problèmes avec AT&T, les responsables tentèrent de
se dérober en soulignant à Bostic, afin de le dissuader, l’énormité de
la tâche consistant à réécrire des fonctions clé de BSD. Cet argument
se retourna cependant contre eux car c’est exactement ce que Bostic
fit, et rapidement. Alors, ils durent terminer le travail en
bougonnant. Ils essayèrent ensuite d’éviter qu’AT&T ne se
rende compte de ce qu’ils avaient fait.

Bien sûr AT&T s’en rendit compte, s’en alarma et attaqua en justice.
Encore une longue histoire sur laquelle il vaut mieux passer. Sous la
pression du procès, le freeware BSD se scinda en trois camps : FreeBSD,
NetBSD, et OpenBSD. Mais il y avait aussi des branches privées car la
licence BSD de Berkeley en autorisait la création. SunOS de Sun
Microsystems, MachTen de Tenon Intersystems, BSD OS de BSDI et NeXTStep
de NeXT Computer furent commercialisé sans accès public au code-source,
alors qu’ils étaient pourtant tous basés sur le code-source BSD de
Berkeley.

Notez bien la différence : si vous écrivez un programme et que vous
mettez en circulation son code-source sous licence GPL (GNU General
Public License), quelqu’un d’autre qui vendrait ou distribuerait des
travaux dérivés du vôtre se trouve dans l’obligation d’en publier le
code-source sous les conditions de la GPL. Ce n’est pas le cas si vous
publiez sous licence BSD : n’importe qui peut alors créer une version
dérivée de votre travail et refuser d’en publier les modifications de
code-source. En d’autres termes, il est autorisé à créer des dérivés
"propriétaires".

Un mot à propos des trois variantes de BSD libres : tous étaient des
groupes divergents d’un projet maintenant éteint appelé 386BSD. S’ils
avaient envisagé un temps de refusionner afin d’éviter le travail en
double, ils continuent à l’heure actuelle séparément car ils se sont
spécialisés : FreeBSD recherche la plus grande stabilité possible sur
les processeurs Intel x86, NetBSD tente de fonctionner sur autant de
types de processeurs différents que possible alors que OpenBSD vise la
sécurité la plus stricte possible. En d’autres termes, le projet 386BSD
reste divisé car il existe des raisons convaincantes faisant que tout
le monde a à y gagner.

Mais, là où c’est possible, ces trois projets frères collaborent sur
les tâches les plus coriaces - et ils collaborent également avec les
programmeurs GNU/Linux. Quelques-uns des meilleurs pilotes de matériels
du noyau Linux sont en fait des pilotes BSD. Il existe un haut niveau
de compatibilité entre les trois BSDs, ainsi qu’entre eux et GNU/Linux
 : à la différence des vendeurs d’Unix "propriétaires", les programmeurs
BSD et GNU/Linux sont enclins à éliminer les incompatibilités et à
encourager les standards.

3. emacs —> Lucid emacs —> xemacs, autres emacses "propriétaires"
pour la plupart oubliés, maintenant —> GNU emacs

Appeler emacs "éditeur de texte", c’est un peu comme appeler "bateau"
le paquebot Queen Elizabeth II. Ce programme n’est en principe qu’un
simple programme de manipulation de texte conçu pour traiter des macros
(d’où son nom emacs : éditeur de macros) mais vous pouvez passer tout
votre temps et accomplir à peu près tout ce qu’on peut faire avec un
ordinateur sans jamais quitter le programme.

Il a été écrit autrefois par le légendaire programmeur Richard
M.Stallman (vous voyez qui je veux dire ?), à une époque où quiconque
entrant en relation avec Stallman était présumé partager avec tous le
code-source qu’il produisait, et le faisait la plupart du temps,
d’ailleurs. En fait, la seule licence pour les premières versions de
emacs était un tacite "Faites ce qu’il vous plaît".

Malheureusement pour Stallman, nombre de sociétés voulaient utiliser
son travail, et en faire des dérivés "propriétaires". Il en fut surpris
et déçu, et ce fut là l’une des raisons pour lesquelles il rédigea le
texte de la licence GNU GPL, puis initia le projet GNU (dans le but de
créer un système d’exploitation à la Unix, appelé "GNU", et dont le
caractère libre soit garanti de façon pérenne).

Les différents emacs propriétaires sont tous morts aujourd’hui, à une
exception près : "Lucid Emacs" fut vendu à Sun Microsystems par Lucid
Corporation, avant sa disparition. Sun décida de le renommer "xemacs",
appellation portant à confusion (car xemacs n’intègre pas plus de
support particulier pour le système X Window que les autres emacses),
pour en fin de compte en faire cadeau à quelques programmeurs qui
décidèrent de remettre son code-source en circulation comme logiciel
libre sous la licence GNU GPL de Richard M. Stallman.

Pendant ce temps, Stallman poursuivait le développement de l’emacs
original sous le nom de "GNU emacs", et plaçait la totalité de ses
nouveaux travaux sous la licence GNU GPL, précisément pour éviter
qu’une catastrophe comme celle de Lucid ne puisse se reproduire.

On se demande souvent pourquoi les gens de xemacs ne fusionnent pas de
nouveau leur travail avec la version de Stallman, pour éviter des
tâches qui doublonnent. Les obstacles sont à la fois personnels et
techniques, et parfois difficiles à distinguer. D’abord, Stallman est
vraiment un autocrate. Peut-être d’ailleurs que seul quelqu’un de
vraiment difficile et obstiné était à même d’accomplir autant que lui,
bâtissant tout un monde logiciel libre à partir de presque rien. Par
ailleurs, le code-source de xemacs a été écrit en suivant les principes
de programmation orientée objet, ce qui rend aisément possible à des
développeurs nombreux de se répartir les responsabilités. Le
code-source de GNU emacs, au contraire, est de type classique, et il
est tellement vaste que seul un programmeur génial pouvait espérer le
développer. Ce programmeur-là, seul parmi des milliards, c’est
naturellement Richard M.Stallman.

4. NCSA httpd —> serveur Web Apache

De nos jours, le standard mondial du logiciel de serveur Web s’appelle
Apache, maintenu par un groupe entièrement constitué de bénévoles - ce
qui ne signifie pas qu’ils ne gagnent pas d’argent : lorqu’ils sont
sollicités comme consultants à propos du Web, des membres du groupe
Apache comme Brian Behlendorf se voient proposer un pont d’or, et ces
sollicitations proviennent d’une renommée bien méritée.

Mais, avant qu’il n’y ait Apache, vous lanciez soit "NCSA httpd"
(HyperText Transport Protocol daemon) du National Center for
Supercomputing Applications de l’Université de l’Illinois à
Urbana-Champlain, soit "CERN-httpd" du CERN de Genève. Le daemon NCSA
était plus petit et plus rapide, mais celui du CERN était réputé,
principalement parce qu’il était associé au nom du créateur du Web,
Tim Berners-Lee, qui travaillait comme chercheur au CERN.

"CERN-httpd" (appelé plus tard "W3C httpd") fut toujours un logiciel
du domaine public (c’est à dire que personne n’en était propriétaire).
N’étant plus maintenu, c’est un projet mort. On ne sait pas de manière
claire ce qu’était la licence de NCSA-httpd à l’origine, mais quand le
projet mourut (1996) sa licence était du type "gratuit pour un usage
non commercial seulement".

De toutes façons, des programmeurs d’un groupe on-line qui avaient
conçu des patches (modifications) pour le NCSA-httpd décidèrent soudain
de produire en 1995 leur propre variante, faisant diverger le code.
"Apache" n’était à l’origine que le nom de code provisoire donné par
Brian Behlendorf au projet, mais ses amis développeurs en soulignèrent
la justesse ("a-patchy" server = "apache" ; vous saisissez ?), et le
nom demeura.

C’est un bon exemple de comment et pourquoi les projets Open Source
divergent, sans malice, pour de bonnes raisons : le développement au
NCSA s’était arrêté après que le créateur original, Rob McCool, ait
quitté le Centre. Si c’était arrivé à un produit "propriétaire", il
aurait disparu en laissant tous ses utilisateurs sur le carreau. Or,
compte tenu de l’utilité du produit, le Projet Apache récupéra le
code-source et continua d’aller de l’avant. Apache surpasse maintenant
tous les serveurs Web, sans se soucier de leur marketing et de leurs
budgets de développement.

5. gcc —> pgcc —> egcs —> gcc

Voilà un exemple bizarre. Richard M. Stallman (vous vous souvenez ?)
fonda en 1984 le Projet GNU, qui produisit l’incomparable compilateur C
nommé GNU C Compiler ("gcc"). gcc est conçu pour fonctionner sur
n’importe quel ordinateur vaguement plausible, pas seulement les séries
Intel x86. Et puis d’autres priorités conduisirent peut-être à différer
l’amélioration du support Intel. En tout cas, en 1997, le mieux que gcc
pouvait faire en matière d’optimisation du code sur plate-forme Intel
était de régler le compilateur pour les puces 486. Stallman recevait
supplique sur supplique pour que soit développée l’optimisation pour le
Pentium, mais il les ignorait obstinément.

Alors, un groupe se créa spécialement pour le compilateur Pentium
(Pentium Compiler Group, auquel participait la société CYGNUS
Corporation que venait juste d’acheter Red Hat Software, Inc.). Le
groupe développa tout d’abord une variante très rapide de gcc appelée
"pgcc" (Pentium gcc), puis pour enterrer la hache de guerre avec
Stallman développa "egcs" (Experimental GNU Compiler System), destiné à
être réabsorbé par gcc.

Pour une raison ou une autre, la Free Software Foundation de Stallman
(les développeurs du Projet GNU) continua d’agir comme si egcs
n’existait pas. Mais des distributions GNU/Linux basées sur egcs
commencèrent d’apparaître, et le monde du logiciel libre se mit à
progressivement délaisser gcc.

Ceci peut être vu comme une variante de l’expérience d’Apache. La
capacité à diverger signifie qu’un développeur qui refuse d’aller de
l’avant ne peut bloquer le progrès : quelqu’un d’autre pourra, aussi
courtoisement que possible, assumer le rôle de leader et si nécessaire
faire diverger le projet.

Le coup de force fut évité dans le cas de egcs. En avril 1999, la FSF
réintégra egcs dans la (future) branche principale de gcc, et en confia
tout développement futur à l’équipe egcs, résolvant ainsi le conflit.

6. glibc —> Linux libc —> glibc

C’est un cas presque exactement inverse. Tout système Unix repose de
façon extrême sur une bibliothèque de fonctions essentielles appelée
bibliothèque C ("C library"). Le Projet GNU de Richard M.Stallman (vous
vous rappelez de lui ?) entreprit dans les années quatre-vingts
l’écriture de la GNU C library, ou glibc. Quand Linus et ses amis
programmeurs commencèrent à travailler sur le système GNU/Linux (en
utilisant le noyau "Linux" de Linus), ils cherchèrent des bibliothèques
C libres, et choisirent celle de Stallman. Cependant, ils trouvèrent
que la bibliothèque de Stallman (qui en était à la version
1-point-quelque_chose) n’était pas suffisamment rapide, estimèrent
qu’ils pouvaient l’adapter eux-mêmes au noyau Linux, et décidèrent
alors d’en faire diverger leur propre version, estampillée "Linux
libc". Ils poursuivirent leur effort au cours des versions 2.x, 3.x,
4.x et 5.x mais, en 1997-98, ils constatèrent quelque chose de bizarre
 : la glibc de Stallman, bien qu’encore dans les numéros de version
1-point-quelque_chose, avait développé des qualités stupéfiantes : ses
fonctions internes disposaient d’un système de repérage des versions
autorisant l’ajout de nouvelles versions sans perdre le support des
plus anciennes applications, elle supportait mieux le multilingue, et
permettait de volumineux enchaînements d’exécution [NdT].

Les programmeurs GNU/LINUX décidèrent alors que, même si leur variante
avait paru une bonne idée, cela avait été une erreur stratégique.
Ajouter les améliorations de Stallman à leur version divergente aurait
été possible, mais il était plus facile de simplement se remettre au
standard de la glibc. Et ainsi les bibliothèques glibc 2.0 et
ultérieures ont progressivement été adoptées comme bibliothèque C
standard par les distributions GNU/Linux.

Le numéro de version était un problème mineur : les gens de GNU/Linux
avaient déjà atteint 5.4.47, tandis que Stallman touchait juste au 2.0.
Ils envisagèrent probablement l’espace d’une milliseconde de demander à
Stallman de numéroter sa prochaine version 6.0 pour les arranger. Puis
ils se mirent à rire en disant : "C’est de Stallman que nous parlons,
n’est-ce pas ?", et décidèrent que tenter d’aller contre l’obstination
de Richard n’était une idée judicieuse. Et c’est pour cela que, par
convention, la version 6.0 de la libc Linux et la glibc 2.0 sont
identiques.

7. Sybase —> Microsoft SQL Server

Woody Allen a dit : "Le lion peut s’étendre à côté de l’agneau, mais
l’agneau ne va pas beaucoup dormir". On peut dire à peu près la même
chose des sociétés qui ont conclu des "alliances industrielles" avec
Microsoft Corporation. L’une des sociétés à commettre cette erreur a
été Sybase Corporation, l’éditeur du langage de gestion de bases de
données "Sybase Structured Query Language" (SQL) pour de nombreux
Unixes et pour NetWare. Selon cet accord, Microsoft vendait Sybase à
ses clients, sous l’étiquette Microsoft SQL Server, et avait libre
accès au code-source de Sybase sous réserve d’une clause de
non-divulgation.

Bien sûr, comme on pouvait le prévoir, Microsoft rompit l’accord
lorsqu’il eut appris de Sybase tout ce qui était possible, et relança
Microsoft SQL Server comme son produit maison, concurrent de Sybase. Je
ne sais pas si les versions actuelles de MS SQL Server sont réécrites
de zéro ou si elles comportent du code Sybase sous licence, auquel cas
ce ne serait pas un cas légitime de divergence (laissons de côté Open
Source), mais c’est suffisamment similaire pour m’avoir incité à en
parler.

ANALYSE : POURQUOI LA DIVERGENCE EN OPEN-SOURCE EST À LA FOIS PEU FRÉQUENTE ET SALUTAIRE

Vous, lecteur, pouvez faire diverger n’importe quel projet Open Source
quand vous le voulez. Mais il n’y a pas à s’en inquiéter. Prouvons-le.
Téléchargez une copie du noyau Linux courant depuis
ftp://ftp.kernel.org/. Renommez-le Bidon OS par exemple, puis expédiez
des messages dans tous les endroits auxquels vous pouvez penser
annonçant que Bidon OS s’est séparé de Linux, et tout le bénéfice que
l’on peut attendre de cette situation.

Puis attendez les réactions. Attendez encore un petit peu. Écoutez le
tic-tac de l’horloge. Triez votre collection de peluches. Ouvrez alors
l’arborescence du code-source, pensez un peu à tout ce que pourriez
faire avec, et essayez d’imaginer comment vous aller bien pouvoir faire
pour en trouver le temps.

Bon, c’est un peu injuste. Vous n’êtes probablement pas un
programmeur. Mais imaginons que vous en êtes un. Vous êtes un
programmeur ninja avec un puissant code-fu, toute l’énergie
fondamentale pour réussir et une équipe disciplinée de partisans
enthousiastes férus de programmation. Et donc vous ne faites pas
qu’écouter le tic-tac de l’horloge, vous abattez un sacré bon travail.
Et, en fin de compte, vous améliorez le noyau de façon sensible.

Alors les gens de Linux sourient largement, et vous disent sincèrement
"Merci beaucoup." Comme tous les programmeurs du monde, ils
savent que la programmation est un travail difficile. Ils sont
paresseux, d’une façon constructive, c’est à dire qu’ils ne sont pas
orgueilleux et sont ravis d’utiliser le travail des autres — quand
c’est autorisé.

Oh ! Vous aviez oublié que votre travail était sous licence GPL ?
Travaillant sur un programme dérivé d’une production sous GPL (le
noyau Linux), vous êtes contraint de publier vos améliorations sous
GPL également, afin que chacun puisse librement les utiliser.
C’est pourquoi vous étiez le seul à croire travailler à la création de
Bidon OS : en réalité, vous travailliez à améliorer Linux.

Et voilà pourquoi les divergences sont rares courantes en code
OpenSource, et encore moins (précisément) si le code est sous licence
GPL : les perfectionnements amenés par un groupe soi-disant divergent
sont librement disponibles pour la communauté entière.

Mais, comme le montrent la plupart des exemples non-GPL ci-dessus, la
divergence n’est pas toujours un choix. C’est parfois une soupape de
sécurité vitale dans le cas ou les développeurs en charge du projet
arrêtent de travailler ou encore décident d’en interrompre la
progression. Le fait que d’autres puissent s’en saisir est une bonne
chose.

Il existe une troisième raison qui explique l’existence de divergences
et qui est susceptible d’atteindre la communauté GNU/Linux en fin de
compte : la spécialisation. Vous vous rappelez que c’est ce qui s’est
passé avec les trois versions de BSD libre — quoique le choc de titans
du procès entre AT&T et Berkeley rende cette situation-là singulière.

Mais c’est comme ça, n’importe qui peut un jour proposer à l’équipe en
charge du noyau Linux une quelconque extension hors du champ du projet.
Si des ressources associées sont créées et s’il y a des raisons
suffisantes à son existence, cette branche progressera.
Dans ce cas, Linux divergera — et ce sera une bonne chose car il y
aura alors deux projets forts plutôt qu’un seul, chacun d’entre eux se
concentrant sur un rôle important que l’autre ne peut remplir.

Et si cela arrive, les branches divergentes partageront certainement
leur code-source et leurs informations, exactement comme le font les
différentes variantes de BSD, parce qu’il est logique de procéder
ainsi.

Le monde en sera plus riche, grâce à la divergence et au partage.

Rick Moen
Légèrement modifié par Zack Brown et Tom Davey.

Copyright (c) 1999 Rick Moen, rick@linuxmafia.com

Rick Moen (rick@linuxmafia.com) est un membre très actif de la communauté Linux. Auteur établi à San Francisco, il était auparavant
responsable de l’administration système chez Linuxcare.

Adaptation française Jean Peyratout
27 novembre 1999

Cette information est libre et gratuite ; vous pouvez la redistribuer
et / ou la modifier selon les termes de la licence GNU GPL (GNU General
Public License) publiée par la Free Software Foundation, à votre choix
la version 2 de cette licence ou une version ultérieure.