Code is Law – Traduction française du célèbre article de Lawrence Lessig

Chiara Marra - CC byLe 5 mars dernier, Tristan Nitot se pose la question suivante sur Identi.ca : « Je me demande s’il existe une version française de Code is Law, ce texte sublime de Lessig ».

Monsieur Nitot qui évoque un texte sublime de Monsieur Lessig… Mais que vouliez-vous que nos traducteurs de Framalang fassent, si ce n’est participer à modifier favorablement la réponse de départ étonnamment négative !

Écrit il y a plus de dix ans, cet article majeur a non seulement fort bien vieilli mais se serait même bonifié avec le temps et l’évolution actuelle du « cyberespace » où neutralité du net et place prise par les Microsoft, Apple, Google et autres Facebook occupent plus que jamais les esprits et nos données[1].

Bonne lecture…

Le code fait loi – De la liberté dans le cyberespace

Code is Law – On Liberty in Cyberspace

Lawrence Lessig – janvier 2000 – Harvard Magazine
(Traduction Framalang : Barbidule, Siltaar, Goofy, Don Rico)

À chaque époque son institution de contrôle, sa menace pour les libertés. Nos Pères Fondateurs craignaient la puissance émergente du gouvernement fédéral ; la constitution américaine fut écrite pour répondre à cette crainte. John Stuart Mill s’inquiétait du contrôle par les normes sociales dans l’Angleterre du 19e siècle ; il écrivit son livre De la Liberté en réaction à ce contrôle. Au 20e siècle, de nombreux progressistes se sont émus des injustices du marché. En réponse furent élaborés réformes du marché, et filets de sécurité.

Nous sommes à l’âge du cyberespace. Il possède lui aussi son propre régulateur, qui lui aussi menace les libertés. Mais, qu’il s’agisse d’une autorisation qu’il nous concède ou d’une conquête qu’on lui arrache, nous sommes tellement obnubilés par l’idée que la liberté est intimement liée à celle de gouvernement que nous ne voyons pas la régulation qui s’opère dans ce nouvel espace, ni la menace qu’elle fait peser sur les libertés.

Ce régulateur, c’est le code : le logiciel et le matériel qui font du cyberespace ce qu’il est. Ce code, ou cette architecture, définit la manière dont nous vivons le cyberespace. Il détermine s’il est facile ou non de protéger sa vie privée, ou de censurer la parole. Il détermine si l’accès à l’information est global ou sectorisé. Il a un impact sur qui peut voir quoi, ou sur ce qui est surveillé. Lorsqu’on commence à comprendre la nature de ce code, on se rend compte que, d’une myriade de manières, le code du cyberespace régule.

Cette régulation est en train de changer. Le code du cyberespace aussi. Et à mesure que ce code change, il en va de même pour la nature du cyberespace. Le cyberespace est un lieu qui protège l’anonymat, la liberté d’expression et l’autonomie des individus, il est en train de devenir un lieu qui rend l’anonymat plus difficile, l’expression moins libre et fait de l’autonomie individuelle l’apanage des seuls experts.

Mon objectif, dans ce court article, est de faire comprendre cette régulation, et de montrer en quoi elle est en train de changer. Car si nous ne comprenons pas en quoi le cyberespace peut intégrer, ou supplanter, certaines valeurs de nos traditions constitutionnelles, nous perdrons le contrôle de ces valeurs. La loi du cyberespace – le code – les supplantera.

Ce que contrôle le code

Le code élémentaire d’Internet est constitué d’un ensemble de protocoles appelé TCP/IP. Ces protocoles permettent l’échange de données entre réseaux interconnectés. Ces échanges se produisent sans que les réseaux aient connaissance du contenu des données, et sans qu’ils sachent qui est réellement l’expéditeur de tel ou tel bloc de données. Ce code est donc neutre à l’égard des données, et ignore tout de l’utilisateur.

Ces spécificités du TCP/IP ont des conséquences sur la régulabilité des activités sur Internet. Elles rendent la régulation des comportements difficile. Dans la mesure où il est difficile d’identifier les internautes, il devient très difficile d’associer un comportement à un individu particulier. Et dans la mesure où il est difficile d’identifier le type de données qui sont envoyées, il devient très difficile de réguler l’échange d’un certain type de données. Ces spécificités de l’architecture d’Internet signifient que les gouvernements sont relativement restreints dans leur capacité à réguler les activités sur le Net.

Dans certains contextes, et pour certaines personnes, cette irrégulabilité est un bienfait. C’est cette caractéristique du Net, par exemple, qui protège la liberté d’expression. Elle code l’équivalent d’un Premier amendement dans l’architecture même du cyberespace, car elle complique, pour un gouvernement ou une institution puissante, la possibilité de surveiller qui dit quoi et quand. Des informations en provenance de Bosnie ou du Timor Oriental peuvent circuler librement d’un bout à l’autre de la planète car le Net empêche les gouvernements de ces pays de contrôler la manière dont circule l’information. Le Net les en empêche du fait de son architecture même.

Mais dans d’autres contextes, et du point de vue d’autres personnes, ce caractère incontrôlable n’est pas une qualité. Prenez par exemple le gouvernement allemand, confronté aux discours nazis, ou le gouvernement américain, face à la pédo-pornographie. Dans ces situations, l’architecture empêche également tout contrôle, mais ici cette irrégulabilité est considérée comme une tare.

Et il ne s’agit pas seulement des discours nazis et de pornographie enfantine. Les principaux besoins de régulation concerneront le commerce en ligne : quand l’architecture ne permet pas de transactions sécurisées, quand elle permet de masquer facilement la source d’interférences, quand elle facilite la distribution de copies illégales de logiciels ou de musique. Dans ces contextes, le caractère incontrôlable du Net n’est pas considéré comme une qualité par les commerçants, et freinera le développement du commerce.

Que peut-on y faire ?

Nombreux sont ceux qui pensent qu’il n’y a rien à faire : l’irrégulabilité d’Internet est définitive. Il n’est rien que nous puissions faire pour y remédier. Aussi longtemps qu’il existera, Internet restera un espace incontrôlable. C’est dans sa nature même.

Mais rien n’est plus dangereux pour l’avenir de la liberté dans le cyberespace que de croire la liberté garantie par le code. Car le code n’est pas figé. L’architecture du cyberespace n’est pas définitive. L’irrégulabilité est une conséquence du code, mais le code peut changer. D’autres architectures peuvent être superposées aux protocoles de base TCP/IP, et ces nouvelles couches peuvent rendre l’usage du Net fondamentalement contrôlable. Le commerce est en train de construire une architecture de ce type. Le gouvernement peut y aider. Les deux réunis peuvent transformer la nature même du Net. Il le peuvent, et le font.

D’autres architectures

Ce qui rend le Net incontrôlable, c’est qu’il est difficile d’y savoir qui est qui, et difficile de connaître la nature des informations qui y sont échangées. Ces deux caractéristiques sont en train de changer : premièrement, on voit émerger des architectures destinées à faciliter l’identification de l’utilisateur, ou permettant, plus généralement, de garantir la véracité de certaines informations le concernant (qu’il est majeur, que c’est un homme, qu’il est américain, qu’il est avocat). Deuxièmement, des architectures permettant de qualifier les contenus (pornographie, discours violent, discours raciste, discours politique) ont été conçues, et sont déployées en ce moment-même. Ces deux évolutions sont développées sans mandat du gouvernement ; et utilisées conjointement elles mèneraient à un degré de contrôle extraordinaire sur toute activité en ligne. Conjointement, elles pourraient renverser l’irrégulabilité du Net.

Tout dépendrait de la manière dont elles seraient conçues. Les architectures ne sont pas binaires. Il ne s’agit pas juste de choisir entre développer une architecture permettant l’identification ou l’évaluation, ou non. Ce que permet une architecture, et la manière dont elle limite les contrôles, sont des choix. Et en fonction de ces choix, c’est bien plus que la régulabilité qui est en jeu.

Prenons tout d’abord les architectures d’identification, ou de certification. Il existe de nombreuses architectures de certification dans le monde réel. Le permis de conduire, par exemple. Lorsque la police vous arrête et vous demande vos papiers, ils demandent un certificat montrant que vous êtes autorisé à conduire. Ce certificat contient votre nom, votre sexe, votre âge, votre domicile. Toutes ces informations sont nécessaires car il n’existe aucun autre moyen simple pour établir un lien entre le permis et la personne. Vous devez divulguer ces éléments vous concernant afin de certifier que vous êtes le titulaire légitime du permis.

Mais dans le cyberespace, la certification pourrait être ajustée beaucoup plus finement. Si un site est réservé aux adultes, il serait possible – en utilisant des technologies de certification – de certifier que vous êtes un adulte, sans avoir à révéler qui vous êtes ou d’où vous venez. La technologie pourrait permettre de certifier certains faits vous concernant, tout en gardant d’autres faits confidentiels. La technologie dans le cyberespace pourrait fonctionner selon une logique de « moindre révélation », ce qui n’est pas possible dans la réalité.

Là encore, tout dépendrait de la manière dont elle a été conçue. Mais il n’est pas dit que les choses iront dans ce sens. Il existe d’autres architectures en développement, de type « une seule carte pour tout ». Dans ces architectures, il n’est plus possible de limiter simplement ce qui est révélé par un certificat. Si sur un certificat figure votre nom, votre adresse, votre âge, votre nationalité, ainsi que le fait que vous êtes avocat, et si devez prouver que vous êtes avocat, cette architecture certifierait non seulement votre profession, mais également tous les autres éléments vous concernant qui sont contenus dans le certificat. Dans la logique de cette architecture, plus il y a d’informations, mieux c’est. Rien ne permet aux individus de faire le choix du moins.

La différence entre ces deux conceptions est que l’une garantit la vie privée, alors que l’autre non. La première inscrit le respect de la vie privée au cœur de l’architecture d’identification, en laissant un choix clair à l’utilisateur sur ce qu’il veut révéler ; la seconde néglige cette valeur.

Ainsi, le fait que l’architecture de certification qui se construit respecte ou non la vie privée dépend des choix de ceux qui codent. Leurs choix dépendent des incitations qu’ils reçoivent. S’il n’existe aucune incitation à protéger la vie privée – si la demande n’existe pas sur le marché, et que la loi est muette – alors le code ne le fera pas.

L’identification n’est qu’un exemple parmi d’autres. Prenons-en un deuxième, concernant la confidentialité des informations personnelles. RealJukebox est une technologie permettant de copier un CD de musique sur un ordinateur, ou de de télécharger de la musique sur le Net pour la stocker sur un disque dur. Il est apparu en octobre que le système était un peu trop curieux : il inspectait discrètement le disque dur de l’utilisateur, puis transférait à l’entreprise le fruit de ses recherches. Tout ceci en secret, bien entendu : RealNetworks n’avait prévenu personne que son produit collectait et transférait des données personnelles. Quand cet espionnage a été découvert, l’entreprise a tout d’abord tenté de justifier cette pratique (en avançant qu’aucune donnée personnelle n’était conservée), mais elle a fini par revenir à la raison, et a promis de ne plus recueillir ces données.

Ce problème est dû, une fois de plus, à l’architecture. Il n’est pas facile de dire qui espionne quoi, dans le cyberespace. Bien que le problème puisse être corrigé au niveau de l’architecture (en faisant appel à la technologie P3P, par exemple), voici un cas pour lequel la loi est préférable. Si les données personnelles étaient reconnues comme propriété de l’individu, alors leur collecte sans consentement exprès s’apparenterait à du vol.

Dans toutes ces circonstances, les architectures viendront garantir nos valeurs traditionnelles – ou pas. À chaque fois, des décisions seront prises afin de parvenir à une architecture d’Internet respectueuse de ces valeurs et conforme à la loi. Les choix concernant le code et le droit sont des choix de valeurs.

Une question de valeurs

Si c’est le code qui détermine nos valeurs, ne devons-nous pas intervenir dans le choix de ce code ? Devons-nous nous préoccuper de la manière dont les valeurs émergent ici ?

En d’autres temps, cette question aurait semblé incongrue. La démocratie consiste à surveiller et altérer les pouvoirs qui affectent nos valeurs fondamentales, ou comme je le disais au début, les contrôles qui affectent la liberté. En d’autres temps, nous aurions dit « Bien sûr que cela nous concerne. Bien sûr que nous avons un rôle à jouer. »

Mais nous vivons à une époque de scepticisme à l’égard de la démocratie. Notre époque est obsédée par la non-intervention. Laissons Internet se développer comme les codeurs l’entendent, voilà l’opinion générale. Laissons l’État en dehors de ça.

Ce point de vue est compréhensible, vu la nature des interventions étatiques. Vu leurs défauts, il semble préférable d’écarter purement et simplement l’État. Mais c’est une tentation dangereuse, en particulier aujourd’hui.

Ce n’est pas entre régulation et absence de régulation que nous avons à choisir. Le code régule. Il implémente – ou non – un certain nombre de valeurs. Il garantit certaines libertés, ou les empêche. Il protège la vie privée, ou promeut la surveillance. Des gens décident comment le code va se comporter. Des gens l’écrivent. La question n’est donc pas de savoir qui décidera de la manière dont le cyberespace est régulé : ce seront les codeurs. La seule question est de savoir si nous aurons collectivement un rôle dans leur choix – et donc dans la manière dont ces valeurs sont garanties – ou si nous laisserons aux codeurs le soin de choisir nos valeurs à notre place.

Car c’est une évidence : quand l’État se retire, la place ne reste pas vide. Les intérêts privés ont des objectifs qu’ils vont poursuivre. En appuyant sur le bouton anti-Étatique, on ne se téléporte pas au Paradis. Quand les intérêts gouvernementaux sont écartés, d’autres intérêts les remplacent. Les connaissons-nous ? Sommes-nous sûrs qu’ils sont meilleurs ?

Notre première réaction devrait être l’hésitation. Il est opportun de commencer par laisser le marché se développer. Mais, tout comme la Constitution contrôle et limite l’action du Congrès, les valeurs constitutionnelles devraient contrôler et limiter l’action du marché. Nous devrions examiner l’architecture du cyberespace de la même manière que nous examinons le fonctionnement de nos institutions.

Si nous ne le faisons pas, ou si nous n’apprenons pas à le faire, la pertinence de notre tradition constitutionnelle va décliner. Tout comme notre engagement autour de valeurs fondamentales, par le biais d’une constitution promulguée en pleine conscience. Nous resterons aveugles à la menace que notre époque fait peser sur les libertés et les valeurs dont nous avons hérité. La loi du cyberespace dépendra de la manière dont il est codé, mais nous aurons perdu tout rôle dans le choix de cette loi.

Lawrence Lessig est professeur de droit des affaires au Centre Berkman de la Harvard Law School. Son dernier livre, « Le code, et les autres lois du cyberespace » (Basic Books), vient d’être publié (voir http://code-is-law.org). Le site du Centre Berkman pour l’Internet et la Société est http://cyber.law.harvard.edu.

Notes

[1] Crédit photo : Chiara Marra (Creative Commons By))




Ouvrir ses logiciels mais fermer ses données à l’ère du cloud computing

Katayun - CC byVoici une courte traduction qui aborde furtivement deux sujets selon nous intéressants. Le premier n’est pas nouveau puisqu’il évoque la traditionnelle différence d’approche entre le logiciel libre cher à Richard Stallman et l’open source, à ceci près que l’avènement du cloud computing lui donne un nouvel éclairage.

Le second est peut-être plus original puisqu’il met en parallèle les logiciels et les données pour constater un mouvement opposé.

Nous sommes nombreux à souhaiter que les logiciels deviennent de plus en plus libres. Mais des Google et des Facebooks ont également envie que nos données suivent le même chemin pour pouvoir les manipuler tout à leur guise. C’est même fondamental pour eux puisque c’est tout leur business model qui est construit sur cela.

Or nous nous inquiétons chaque jour davantage du devenir de nos données, et si nous les souhaitons « libres » c’est avant tout libres de ne pas être contrôlées et exploitées sans notre consentement. Liberté et ouverture n’ont donc clairement pas le même sens chez les uns et chez les autres[1].

Il faut dire que dans les nuages : logiciels, formats, fichiers et données s’entrechoquent. Quand par exemple vous faites du traitement de texte directement en ligne (Google Docs, Zoho, etc.), c’est un peu tout à la fois qui est sollicité, sans qu’on n’arrive plus trop bien à les distinguer.

« Ouvrons » nos logiciels mais « fermons » nos données ? C’est en résumé, la question brutale que pose ce billet.

Libérez mes logiciels, pas mes données

Open source my software but not my data

Dana Blankenhorn – 27 avril 2010 – ZDNet (Blog Linux and Open Source)
(Traduction Framalang : Kovalsky, Barbidule et Goofy)

Comme Google avant lui, Facebook fait l’objet d’une attention accrue pour son interprétation du terme « ouvert » dans le monde en ligne.

Que les logiciels soient libres est une bonne chose. Mais que les données soient ouvertes ? Peut être pas tant que ça.

L’affirmation classique concernant le logiciel est qu’à moins que vous utilisiez l’AGPL, à moins que tout ne soit ouvert y compris vos sources secrètes, vous n’êtes pas vraiment ouvert, vous prétendez seulement l’être. Ouvert serait juste un autre mot pour dire que vous n’avez rien à cacher.

Je n’y ai jamais cru. L’open source n’est pas la même chose que le logiciel libre, c’est une des premières leçons qu’on m’a apprises quand j’ai commencé ce combat. (Richard Stallman s’en est chargé personnellement.)

L’open source est un continuum de choix, allant de l’idéal des logiciels libres de Stallman jusqu’au code de Microsoft sous restrictions serrées. L’open source est né en réaction logiciel libre de Stallman, et parfois en opposition à celui-ci.

Précédemment, j’ai mis au point une courbe de l’open source, pour illustrer l’étendue des choix disponibles. Plus vous avez besoin d’une participation de la communauté, plus vous êtes en bas de la courbe. Plus votre contrôle de la propriété du code augmente, plus vous êtes en haut.

Plus tard j’ai modifié cela en élaborant une courbe du développement open source, prenant en compte différents modèles de développement.

Ce qui est notable à propos de l’essentiel du code conçu pour être utilisé en ligne, c’est qu’il n’est généralement pas en bas de la courbe. Même Google n’est pas en bas de la courbe, bien qu’il soit un membre de la communauté open source tout à fait respectable. Google ne soutient pas l’AGPL.

Mais qu’en est il des données ? Qui décide du statut des données en ligne ? Est ce que la décision vous appartient, ou revient-elle aux entreprises qui hébergent les données ?

Facebook a assimilé les données à du logiciel, et il se permet alors de les diffuser dans la nature, en affirmant qu’il ne fait que suivre les principes de l’open source.

Quand vous comparez libre et propriétaire dans le monde logiciel, le libre semble formidable. Mais comparez-les sous l’angle des données, sur le mode « vos données seront ouvertes sauf si vous dites non », et les Sénateurs vont y voir une violation de la vie privée. En particulier si, comme Facebook, vous vous étiez vous-même défini jusqu’à récemment comme un réseau privé sans risque pour les enfants, et non comme un classique espace ouvert du Web.

Il est facile pour les logiciels de se déplacer vers le haut ou le bas de la courbe de l’open source. Pour les données cela se révèle problématique.

Notes

[1] Crédit photo : Katayun (Creative Commons By)




Quand la Maison Blanche se joint à la communauté du Libre

Beverly & Pack - CC byLa vaste communauté Drupal compte un contributeur bien particulier puisqu’il s’agit ni plus ni moins de la Maison Blanche.

C’était déjà bien d’adopter le célèbre CMS libre pour faire tourner le site officiel (ce que nous avions signalé dans un précédent billet), mais c’est encore mieux de participer à son amélioration en reversant le code spécifique développé pour l’occasion, et en le faisant savoir sur son blog (traduit ci-dessous)[1].

Un billet et une traduction directement suggérés par ce journal LinuxFr de Francois G (auteur de la rafraichissante nouvelle de science-fiction Églantine et les ouinedoziens) dont la présentation se suffit à elle-même :

« Le site de la Maison Blanche vient de diffuser le code source des améliorations qu’ils ont apportés au projet Drupal (à noter tous les liens vers le site du projet Drupal dans le billet).

Les 3 bonnes nouvelles :

  • La Maison Blanche a compris qu’elle peut être maître de ses outils informatiques.
  • Elle en profite (modifications spécifiques) et en fait profiter les autres (diffusion à tous).
  • Elle communique sur cette action. De ce fait, elle annonce officiellement son support et son utilisation des logiciels libres.

Compte tenu de la volonté de l’Élysée de copier la Maison Blanche, on peut espérer un changement de politique chez nous. »

WhiteHouse.gov participe à l’Open Source

WhiteHouse.gov Releases Open Source Code

Dave Cole – 21 avril 2010 – The White House Blog
(Traduction Framalang : Quentin Theuret et Julien Reitzel)

Dans le cadre de nos efforts continus pour développer une plateforme ouverte pour WhiteHouse.gov, nous mettons à disposition de tous une partie du code source personnalisé que nous avons développé. Ce code est disponible à tous pour l’analyser, l’utiliser ou le modifier. Nous sommes impatients de voir comment des développeurs à travers le monde pourront utiliser notre travail dans leurs propres applications.

En reversant une partie de notre code source, nous bénéficions de l’analyse et de l’amélioration d’un plus grand nombre de personnes. En fait, la majorité du code source de WhitHouse.gov est dès à présent open source car il fait partie du projet Drupal. Le code source que nous relâchons aujourd’hui ajoute des fonctionnalités à Drupal dans trois domaines importants :

1. Évolutivité : Nous publions un module nommé Context HTTP Headers, qui permet aux webmasters d’ajouter de nouvelles métadonnées au contenu qu’ils publient. Nous utilisons cela pour nos serveurs qui manipulent des pages spécifiques, comme la mise en cache de ce type de page pendant 15 minutes ou ce type pendant 30. Un second module concernant l’évolutivité s’appelle Akamai et il permet à notre site web de s’intégrer avec notre réseau d’envoi de contenu Akamai.

2. Communication : Beaucoup d’agences gouvernementales ont des programmes actifs d’emails qu’ils utilisent pour communiquer avec le public à travers des services qu’ils fournissent. Nous avons une liste de diffusion pour la Maison Blanche, où vous pouvez trouver les mises à jour des nouveaux contenus et des initiatives. Pour rendre plus dynamique l’adaptation des emails aux préférences des utilisateurs, nous avons intégré l’un des services les plus populaires pour les programmes d’emails gouvernementaux dans notre CMS avec le nouveau module GoDelivery.

3. Accessibilité : Nous prenons très au sérieux nos obligations pour être sûrs que WhiteHouse.gov soit accessible le plus possible et nous nous sommes engagés à tendre vers les standards d’accessibilité décrits par la Section 508. Dans le cadre de cette conformité, nous voulons être sûrs que toutes les images sur notre site Web aient des métadonnées appropriées pour les rendre visibles sur des logiciels de lecture vocale. Pour nous aider à atteindre cela, pour que ce soit plus facile de gérer les contenus photos et vidéos que vous voyez sur notre site, nous avons développé Node Embed.

Notes

[1] Crédit photo : Beverly & Pack (Creative Commons By)




Geektionnerd : Mono

Dans la famille des grands trolls de la communauté, je demande Mono.

On attend avec impatience un futur dessin sur la Fondation Codeplex qui nous valu une belle passe d’armes entre Manuel de Icaza (à l’origine de Mono) et Richard Stallman (co-auteur de sa framabiographie) 😉

J’en profite pour signaler le concours de scénario lancé par notre ami Gee à l’occasion du prochain premier anniversaire de son blog.

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)




Toute recherche scientifique digne de ce nom doit ouvrir son code informatique

TenSafeFrogs - CC byVoici un récent article du Guardian qui tourne paradoxalement autour du logiciel libre et des formats ouverts mais sans véritablement les nommer.

Nous avons cependant jugé qu’il avait son intérêt dans la mesure où la science et la recherche ont désormais de plus en plus recourt à l’informatique pour traiter des données et en tirer analyses et conclusions[1].

Or comment voulez-vous que l’on puisse valider les résultats si les applications utilisées sont propriétaires ou si les chercheurs eux-mêmes ne mettent pas le code de leur programme à disposition ?

L’article s’appuie sur la récente affaire dite du « Climategate » qui a fait grand bruit outre-Manche (et étrangement peu de cas chez nos grands médias français).

Quand recherche sérieuse rime avec libération du code informatique

If you’re going to do good science, release the computer code too

Darrel Ince – 5 février 2010 – The Guardian
(Traduction Framalang : Kovalsky et Olivier)

Les programmes informatiques prennent chaque jour plus de place dans le travail scientifique. Mais partie prenante dans les conditions de l’expérience vous devez pouvoir les vérifier comme en atteste la bataille qui se joue autour des données sur le changement climatique.

On retiendra de l’affaire concernant la révélation publique des e-mails et des documents de l’Unité de Recherche Climatique de l’Université d’East Anglia qu’ils mettent en lumière le rôle du code informatique dans la recherche climatique. Il y a notamment une série de « README » produite par un programmeur de l’UEA connu sous le nom de « Harry ». Ces notes sont celles de quelqu’un qui lutte avec du code ancien non-documenté, et des données manquantes. Et pourtant, on parle bien d’un élément de l’une des trois bases de données climatiques principales dont se sont servis les chercheurs du monde entier pour en tirer analyses et conclusions.

Beaucoup de scientifiques du climat ont refusé de publier leur programme informatique. À mes yeux, ça n’est ni scientifique, ni responsable, parce que les logiciels scientifiques sont réputés pour leur manque de fiabilité.

L’Histoire nous a appris à ne pas faire une confiance aveugle aux logiciels scientifiques. Par exemple le Professeur Les Hatton, un expert international en tests logiciels, résident de l’Université du Kent et de Kingston, a mené une analyse approfondie de plusieurs millions de lignes de code scientifique. Il a montré que les logiciels présentaient un nombre exceptionnellement élevé d’erreurs détectables.

Par exemple, les erreurs de communication entre les modules de logiciels qui envoient les données d’une partie d’un programme à une autre se produisent à une fréquence de 1 pour 7 communications en moyenne dans le langage de programmation Fortran, et de 1 pour 37 communications dans le langage C. C’est d’autant plus inquiétant qu’une seule et unique erreur est susceptible d’invalider un programme informatique. Plus grave encore, il a découvert que la précision des résultats chute de six chiffres significatifs à un chiffre significatif après traitement par certains programmes.

Les travaux d’Hatton et d’autres chercheurs indiquent que les logiciels scientifiques sont souvent de mauvaise qualité. Il est stupéfiant de constater que cette recherche a été menée sur des logiciels scientifiques commerciaux, produits par des ingénieurs logiciels soumis à un régime de tests, d’assurance qualité et à une discipline de contrôle des modifications plus connue sous le nom de gestion de configuration.

À l’opposé, les logiciels scientifiques développés dans nos universités et nos instituts de recherches sont souvent produits, sans assurance qualité, par des scientifiques qui n’ont pas de formation en ingénierie logicielle et donc, sans aucun doute, l’occurence des erreurs sera encore plus élevée. Les fichiers « Harry ReadMe » de l’Unité de Recherche Climatique sont une preuve flagrante de ces conditions de travail. Ils résument les frustrations d’un programmeur dans sa tentative de conformer ses séries de données à une spécification.

Le code informatique est au coeur d’un problème scientifique. La science se définit par sa potentielle remise en cause : si vous érigez une théorie et que quelqu’un prouve qu’elle est fausse, alors elle s’écroule et on peut la remplacer. C’est comme cela que fonctione la science : avec transparence, en publiant chaque détail d’une expérience, toutes les équations mathématiques ou les données d’une simulation. Ce-faisant vous acceptez et même encouragez la remise en question.

Cela ne semble pas être arrivé dans la recherche climatique. De nombreux chercheurs ont refusé de publier leur programme informatique, même ceux qui sont encore utilisés et qui ne sont pas sujet à des accords commerciaux. Le Professeur Mann, par exemple, refusa tout d’abord de fournir le code, employé pour construire en 1999 le graphique en cross de hockey, qui a démontré que l’impact de l’homme sur le réchauffement climatique est un artefact unique de la dernière décennie (il l’a finalement publié en 2005).

La situation n’est pas aussi désastreuse pour tous les travaux académiques. Certaines revues, économiques et économétriques par exemple, imposent que l’auteur soumette ses données et ses programmes au journal avant publication. Un cas fondamental en mathématiques a également fait parler de lui : la preuve « par ordinateur » de la conjoncture des quatre couleurs par Appel et Haken. Cette démonstration a partagé la communauté scientifique puisque pour la première fois le problème de la validation du théorème s’est trouvé déplacé vers le problème de la validation de l’algorithme d’exploration et de sa réalisation sous forme de programme. Bien que critiquée pour son manque d’élégance, la preuve n’en était pas moins correcte et le programme informatique, publié et donc vérifiable.

Des organismes et des individus, ralliés à l’idée du quatrième paradigme, attachent beaucoup d’importance au problème de l’informatique scientifique à grande échelle et à la publication des données. C’était l’idée de Jim Gray, un chercheur expérimenté de Microsoft, qui a identifié le problème bien avant le Climategate. Actuellement, la recherche consacrée aux mécanismes qui pourraient faire du Web un dépôt pour les publications scientifiques est très active, elle englobe également les logiciels et la formidable quantité de données qu’ils consomment et génèrent. Un certain nombre de chercheurs mettent au point des systèmes qui montrent le progrès d’une idée scientifique, des premières ébauches d’idées jusqu’à la publication papier[2]. Les problèmes rencontrées avec la recherche climatique apporteront un élan à ce travail pour qu’il soit accéléré.

Donc, si vous publiez des articles de recherche qui s’appuient sur des programmes informatiques, si vous prétendez faire de la science mais que vous refusez de publier les programmes en votre possession, je ne peux vous considérer comme un scientifique. J’en irais même jusqu’à dire qu’à mes yeux les publications basées sur ces programmes seront nulles et non avenues.

Je trouve incroyable qu’une faute de frappe puisse être à l’origine d’une erreur dans un programme, un programme qui pourrait à son tour être à l’origine de décisions portant sur des milliards d’euros, et le pire, c’est que la fréquence de ces erreurs est élevée. Les algorithmes (ou copules gaussiennes), sur lesquels se sont appuyées les banques pour s’assurer que les crédits sub-prime étaient sans risque pour eux, ont été publiées. La facture était salée. La facture du changement climatique sera aussi élevée. Raison de plus pour qu’aucune erreur dans les calculs ne soit tolérée là non plus.

Notes

[1] Crédit photo : TenSafeFrogs (Creative Commons By)

[2] Voir à ce sujet l’article du Framablog : Première démonstration « open source » d’un théorème mathématique.




Comment détruire votre communauté en 10 leçons

Giuseppe Bognanni - CC bySi vous avez le malheur de développer un projet « open source » au sein de votre entreprise alors vous courrez le risque de voir arriver une « communauté » qui peut à tout moment s’agréger autour du code source de votre logiciel et en menacer sa bonne gouvernance.

Heureusement le développeur Josh Berkus est là pour vous expliquer point par point comment faire pour être certain de ruiner et dissoudre toute velléité communautaire (au cours d’une intervention donnée il y a un mois à la Linux.Conf.au et relatée ici par Jonathan Corbet)[1].

Un article évidemment ironique (qui détourne les howto), mais qui donne à réfléchir sur les relations subtiles et complexes qui peuvent exister entre les communautés et les entreprises qui œuvrent sur un même projet.

Pas toujours facile de se comprendre en effet quand les uns disent plutôt « logiciel libre » et les autres plutôt « open source » (voire même parfois carrément « fauxopen source »).

Et puis, c’est pratique, puisqu’on dispose ainsi de tout ce qu’il ne faut pas faire pour réussir un projet communautaire.

On notera que Josh Berkus avait la société Sun Microsystems en tête lorsqu’il a énoncé son propos (Sun soutient notamment MySQL et OpenOffice.org). Mais comme il le précise lui-même a posteriori sur son blog, cela peut s’appliquer à n’importe quelle « corporate open source » et de citer alors entre autres Red Hat, Microsoft, IBM, Cisco, SugarCRM, Novell, Compiere, Borland, Google, ou encore Apple. « Si vous avez à faire à une compagnie qui possède un projet open source, vous pouvez être sûr à 95% qu’elle suit au moins un des dix points mentionnés ci-dessous »

Et de conclure positivement sur la nécessité de cultiver l’un des mots clés les plus importants de la communauté : la confiance.

Comment détruire votre communauté : mode d’emploi

How to destroy your community

Jonathan Corbet – 18 janvier 2010 – LWN.net
(Traduction Framalang : Olivier, Daria et Don Rico)

Le réputation de Josh Berkus en tant que hacker de PostgreSQL n’est plus à faire, mais ce n’est pas sa seule compétence, puisqu’il a aussi acquis une précieuse expérience durant sa pige au « Laboratoire de Destruction des Communautés », plus connu sous le nom de Sun Microsystems. Il y a suivi « l’enseignement breveté en 10 étapes » pour apprendre à débarrasser un projet de toute ingérence de la communauté.

La présentation très dynamique qu’a donnée Josh à la Linux.Conf.au sur le sujet était la première discussion de la miniconf L’économie de l’open source ; l’audience lui a réservé un accueil chaleureux.

Si vous êtes développeur dans une grosse entreprise, vous vous rendrez rapidement compte que les communautés de développement des logiciels libres sont une plaie. Dites adieu à vos plans marketing, par exemple, car elle se chargera d’introduire le logiciel dans des pays où vous êtes absents et pour lesquels vous n’avez pas de plan. Ils flanqueront par terre vos prévisions produits en sortant des innovations non-prévues, en implémentant des fonctionnalités des années avant ce que vous aviez planifié, ou pire encore, des fonctionnalités qui devaient être réservées à la version propriétaire de votre logiciel. Les communautés de logiciels libres sont d’éternelles insatisfaites, elles n’ont de cesse de vouloir améliorer les choses. Elles ont tendance à redéfinir les relations avec vos partenaires et vos clients, et vos commerciaux ne savent plus à quel saint se vouer. Et sans arrêt elles vous dérangent : un e-mail par ci, une conférence à laquelle vous devriez assister par là, etc.

Mais heureusement, des solutions existent pour vous débarrasser de la menace que représente cette communauté. Il suffit d’appliquer une ou plusieurs des étapes suivantes.

1. Rendez le projet dépendant d’outils complexes

Il a remarqué qu’en général, les entreprises n’ont pas de problème avec cette technique puisqu’elles aiment s’appuyer sur leurs propres outils. Pour les projets où la communauté n’est pas la bienvenue, il faut par exemple employer des systèmes singuliers qu’on ne trouve nulle part ailleurs. Un système de contrôle de version propriétaire (NdT : version control system) est absolument obligatoire. Mieux encore, un outil de suivi des problèmes (NdT : issue tracking system) avec un nombre limité de licences, afin que tout le monde doive s’y connecter avec le même compte.

N’oubliez pas de mettre en place un site Web qui respecte la parité : 50% du temps planté, 50% du temps opérationnel. Ne pas mettre de site à disposition ne suffira pas : dans de telles situations, la communauté a la fâcheuse habitude de créer le sien. Avec un site bancal, en revanche, vous vous en prémunirez et vous assurerez que l’information restera bien cachée.

2. Attirez les participants nocifs et optimisez les dégâts qu’ils peuvent engendrer

Ce cas particulier nécessite quelques étapes :

  1. Prenez sur vous et engagez-vous dans de longs débats avec ces personnes et dénoncez-les sur les listes du projet.
  2. Au bout d’un certain temps, bannissez-les par décret ; évitez à tout prix tout processus communautaire.
  3. Les gens bannis déverseront leur bile ailleurs. Vous devez les suivre et poursuivre votre débat sur ces sites externes.
  4. Enfin, la communauté se plaindra de ce comportement. Votre réponse sera simple : réintégrez les enquiquineurs à la communauté. Reprenez à la première étape et recommencez.

D’après Josh, un casse-pieds bien pris en main peut annihiler une communauté de plusieurs centaines de membres.

3. Ne fournissez pas de documentation

Aucune information utile ne devrait être disponible, ni pour le code, ni sur les méthodes de compilation, rien sur le processus de soumission de correctif, ni sur le processus de sortie, rien de rien. Puis, quand on demandera de l’aide, répondez « Lis la notice, bordel ! » (NdT : RTFM pour Read the fucking manual)

4. Prenez les décisions relatives au projet en petit comité

Pour bien commencer, vous pouvez organiser vos réunions en ligne en ne prévenant les participants que très peu de temps à l’avance. Pour que cette technique soit vraiment efficace, prévoyez ces réunions à des heures incompatibles avec le fuseau horaire commun à la plupart des membres de la communauté.

Le mieux est encore de tout faire en visioconférence : vous exclurez de fait environ un tiers de la planète pour qui elle se déroule de nuit, de plus, les gens ont un boulot, tant pis pour eux aussi. Mais le must reste encore d’organiser les réunions en personne au siège de la société.

5. Sortez la grosse artillerie juridique

S’impliquer dans le projet devrait rimer avec accords de participation alambiqués, contrats de licence protégeant le contenu du site Web, accords de confidentialité, marques déposées, etc. Pour ne pas faire les choses à moitié, tous ces documents devraient être modifiés en catimini à peu près tous les deux mois.

6. Choisissez avec soin l’agent de liaison avec la communauté

Votre meilleur candidat : quelqu’un de solitaire, quelqu’un qui n’a pas d’amis et qui n’apprécie pas vraiment les autres. Si vous n’en avez pas sous la main, prenez le membre de votre équipe qui a le plus de travail, quelqu’un avec des responsabilités en développement et en gestion, et qui travaille déjà au minimum 70 heures par semaine. Dans ce cas, il est primordial de ne pas le décharger de la moindre de ses responsabilités.

Quelqu’un qui ne maîtrise pas la technologie fera aussi l’affaire. Prenez un spécialiste de Java pour assurer la liaison dans un projet en Perl. Ou, si vraiment ces solutions ne sont pas possibles, laissez simplement la place vacante pendant des mois.

7. Rendez opaques les prises de décision

Les entreprises réfractaires aux communautés devraient, d’après Josh, s’inspirer des Nations Unies et créer des processus longs et complexes. Personne ne doit savoir qui prend réellement les décisions, c’est très bon pour transformer les contributeurs en éléments nocifs. Il va de soi que les règles devraient être immuables ou presque.

8. Faites n’importe quoi avec les licences

Les membres de la communauté étant souvent à cheval sur la question des licences, modifiez la licence et vous avez de bonnes chances de les faire fuir. Évoquer des changements de licence sans jamais vraiment rien modifier peut se révéler encore plus efficace : vous faites fuir les contributeurs actuels qui apprécient la licence choisie sans pour autant en attirer d’autres, adeptes eux de la future licence supposée.

9. N’accordez jamais, au grand jamais, l’accès au commit à quelqu’un d’extérieur à l’entreprise

Ce devrait être une règle (tacite évidemment) : seuls les employés peuvent avoir les droits de commit (NdT : avoir ces droits revient à avoir accès et contrôle sur le code source du dépôt officiel du logiciel). Vos réponses doivent être évasives, « problèmes légaux, on y travaille » est une bonne carte à jouer. Afin que cette mesure prenne tout son effet, choisissez un employé qui n’écrit pas de code et confiez lui l’accès au commit sur le projet.

10. Réfugiez-vous dans le silence

Laissez les questions sans réponse, ne dites rien. Maîtriser cette technique peut rendre, à elle seule, toutes les autres inutiles. C’est le meilleur moyen de détruire une communauté qui existe.

En conclusion, Josh ajoute que grâce à Sun, il peut témoigner de l’efficacité de toutes ces techniques. Mais Sun est loin d’être la seule entreprise dans cette situation. Un ancien du X Consortium a avoué à Josh qu’eux aussi avaient un jour recouru à chacune de ces méthodes. Ces compétences de destruction de communauté sont monnaie courante dans l’industrie du logiciel.

Mais que faire si votre entreprise veut au contraire se bâtir une communauté ?

Il paraît évident qu’elle devrait alors s’employer à appliquer à l’inverse les méthodes énumérées ci-dessus. Mais d’après Josh, la clé de voûte du système reste la confiance. À l’instar du mariage, développer une communauté peut prendre des années, mais une seule infidélité détruira la confiance qui en constitue le socle. Ainsi, une entreprise peut perdre la moitié de sa communauté en un week-end. Pour ne pas connaître ce triste sort, il faut avoir confiance en la communauté et agir de sorte que cette confiance soit réciproque.

Notes

[1] Crédit photo : Giuseppe Bognanni (Creative Commons By)




Sécurité US et non discrimination du Libre ne font pas bon ménage sur SourceForge

Katie Tegtmeyer - CC byLa forge logicielle SourceForge n’est plus à présenter. C’est le plus grand dépôt d’applications libres au monde, qui se comptent en centaine de milliers.

Or petit scandale et réelle polémique, SourceForge vient tout récemment et sans préavis d’en barrer l’entrée aux ressortissants de l’Iran, la Corée du Nord, Cuba, du Soudan et de la Syrie, pour se mettre en conformité avec une loi américaine sur la sécurité nationale[1].

Tant pis pour les développeurs et utilisateurs de ces cinq pays et tant pis aussi pour les principes non discriminants qui régissent le logiciel libre.

Pour évoquer ce problème nous avons choisi de traduire la news du Register, mais nous aurions tout aussi bien pu choisir cet article de ComputerWorld dont la conclusion interpelle : « La seule manière d’empêcher réellement les pays sur liste noire d’avoir accès aux dépôts de logiciels libres hébergés aux USA est d’interdire aux Américains de participer au mouvement open source ! »

SourceForge raye 5 nations de la carte open source

SourceForge bars 5 nations from open source downloads

Dan Goodin – 26 janvier 2010 – The Register
(Traduction Framalang : Olivier)

Certains pays sont plus égaux que d’autres

Le dépôt de logiciels open source, SourceForge.net, bloque désormais automatiquement les adresses Internet des utilisateurs de l’Iran, la Corée du Nord, Cuba, le Soudan et la Syrie au prétexte d’appliquer une loi empêchant les ressortissants de ces pays de télécharger des logiciels libres.

Les réactions des puristes du mouvement des logiciels libres et open source ne se sont pas fait attendre. Ils militent pour que chacun ait accès au code, à la seule condition qu’il respecte les termes de la licence. À l’instar du dépôt open source de Google, les termes d’utilisation de Sourceforge interdisent depuis longtemps à quiconque résidant dans un des pays placés sur la liste de sanction de l’US Office of Foreign Assets Control d’envoyer ou de télécharger du code.

Depuis la semaine dernière, SourceForge a commencé à bannir certaines adresses IP pour faire respecter cette interdiction. Dans un article paru lundi, Sourceforge n’annonce pas la raison de ce changement, mais il affirme néanmoins que cette décision ne cadre pas avec la philosophie de l’entreprise :

« Cependant, notre participation à la communauté open source ne peut pas nous faire oublier que nous vivons dans le monde réel et que nous sommes tenus aux lois qui régissent le pays d’où nous exerçons », peut-on lire dans l’article. « Notre obligation est de suivre ces lois et nos vœux, aussi humanistes soient-ils, ne peuvent pas s’y soustraire. »

Les critiques de cette restriction ne se firent pas attendre. Dans les commentaires, sur le blog de SourceForge, une personne note que cette restriction entre en conflit avec la Section 5 de la définition de l’Open Source qui stipule que les licences ne doivent pas établir une discrimination « entre des personnes ou des groupes de personnes ». Les critiques soutiennent également que ces restrictions ne sont pas compatibles avec le discours que tenait la semaine précédente Hillary Clinton, la Secrétaire d’État américaine, encourageant un Internet libre.

Notes

[1] Crédit photo : Katie Tegtmeyer (Creative Commons By)




Il était une fois un livre sur et avec Richard Stallman

Biographie de Stallman - Couverture Eyrolles - 3D HarrypopofLe livre Richard Stallman et la révolution du logiciel libre – Une biographie autorisée, qui est sorti le 21 janvier aux éditions Eyrolles, possède trois auteurs.

Il y a bien entendu Sam Williams, auteur de la version d’origine en anglais. Mais si nous n’étions qu’en face de sa simple traduction, il demeurerait alors le seul auteur de l’ouvrage. Or deux autres noms apparaissent : Richard Stallman lui-même et Christophe Masutti de Framasoft.

Pourquoi cette originalité et pourquoi méritent-ils tous deux de venir s’associer à Sam Williams ? Vous le saurez en parcourant l’histoire peu commune de ce livre, telle qu’elle a été vécue par Christophe.

Il nous propose une très jolie formule pour expliquer les intentions et les apports de Stallman :
il a souhaité « hacker » le livre.

Avec le même état d’esprit, ou plutôt la même éthique, que lorsqu’il se trouvait, plusieurs dizaines d’années auparavant, jeune programmeur parmi les siens au département de recherche en intelligence artificielle du MIT.

Il était une fois un livre sur et avec Richard Stallman

Christophe Masutti – janvier 2010 – GNU Free Documentation License

Christophe MasuttiTout a commencé en mars 2007, lorsque Alexis Kauffmann a posté un message sur le forum du réseau Framasoft, invitant les volontaires à participer à la traduction du livre de Sam Williams, Free as in Freedom: Richard Stallman’s Crusade for Free Software, publié en 2002 chez O’Reilly sous la licence libre GNU Free Documentation License.

Framasoft a une certaine habitude des traductions et s’est même constitué avec le temps une équipe entièrement dédiée à cela, le groupe Framalang. Il se trouve qu’à cette époque Framalang ne chômait pas et nous ne souhaitions pas leur rajouter une charge de travail supplémentaire avec un livre de quelque 300 pages !

Nous avons donc fait le choix de proposer directement le projet dans un wiki public, et pas n’importe lequel d’entre eux : Wikisource, la bibliothèque libre du réseau Wikimedia. Lors d’une conférence tenue aux Rencontres mondiales du logiciel libre 2009 de Nantes, Alexis donne plus de détails sur le mode opératoire : quelqu’un avait déjà traduit la préface et le premier chapitre du livre sur un site personnel, ce qui nous a servi de base pour créer la structure de l’ensemble du projet sur Wikisource. L’objectif était bien entendu d’arriver à nos fins mais il s’agissait également d’une expérience, celle d’une ambitieuse traduction collaborative et spontanée ouverte à tous, exactement comme on crée, modifie et améliore les articles de Wikipédia.

Un an plus tard, le bilan était contrasté. Nous avions bénéficié de l’exposition de Wikisource et de nombreuses personnes étaient venues participer. Mais quantitativement il restait encore beaucoup à faire et qualitativement ce qui avait été fait manquait singulièrement de cohérence et d’harmonie (ne serait-ce que pour se mettre d’accord sur la traduction de tel ou tel terme important et récurrent). Et puis nous butions sur des questions aussi élémentaires que la décision de « clore » un chapitre traduit, ce qui sur un wiki aussi fréquenté ne va pas de soi.

Ne nous en déplaise, il fallait mettre un peu de « cathédrale dans le bazar », c’est-à-dire un peu de verticalité dans l’horizontalité du projet. Alexis a alors pris la décision de relancer le projet sur le blog de Framasoft, en invitant les bonnes volontés à se regrouper sur une liste de discussion dédiée et créée pour l’occasion. Pour ma part, je pris l’initiative d’animer cette liste qui compta rapidement une bonne dizaine d’inscrits (dans le livre vous trouverez en préambule les remerciements à cette liste nominative de participants).

Notre première décision consista à créer ailleurs un deuxième wiki, mais cette fois-ci loin des regards du réseau Wikimedia. Il ne s’agissait pas de jouer les cachottiers, mais nous en étions arrivés à la conclusion qu’il n’était plus possible de continuer à travailler sur Wikisource, dans la mesure où à tout moment une personne externe à la liste pouvait s’en venir tout « bouleverser » (c’est, j’en conviens fort bien, ce qui fait tout le charme de Wikipédia, mais à cette période d’un projet si spécifique nous souhaitions avant toute chose être efficaces et coordonnés dans notre travail).

Nous nous trouvions cependant face à un dilemme : d’un côté la traduction d’origine sur Wikisource restait bien entendu ouverte et continuait sa vie de texte wiki (bien que fort peu active, puisque la liste avait capté une bonne part de l’énergie disponible) et de l’autre côté, le travail sur notre nouveau wiki prenait forme et la traduction avançait plutôt bien. Une fois terminée, notre intention était de reverser la traduction de Free as in Freedom dans Wikisource, quitte à « écraser » les contributions effectuées dans l’intervalle (ces contributions peuvent néanmoins être réhabilitées grâce à l’historique des modifications). Aujourd’hui, on peut donc trouver sur Wikisource cette traduction française de Free as in Freedom publiée par Sam Williams en 2002. Modulo le fait que quelqu’un est peut-être venu en déplacer un mot il y a une heure 😉

Notre traduction avançait donc plutôt bien jusqu’à obtenir une forme convenable à la relecture en novembre 2008, avec en prime la décision définitive d’en faire un volume de plus de la collection de livres libres Framabook.

Une petite parenthèse est ici nécessaire. En effet, nous travaillions depuis peu en étroite collaboration avec l’équipe de La Poule ou l’Oeuf, qui est une chaîne éditoriale en ligne pour la production de livres, pensés comme unités d’une collection, permettant un rendu final de type TeX, PDF, ePub ou HTML. Ce livre était aussi pour nous l’occasion d’implémenter dans le système non seulement l’ouvrage mais aussi la maquette générale de notre collection Framabook. Nous sommes très heureux du résultat car non seulement la Poule ou l’Oeuf a servi pour la mise en page du livre publié chez Eyrolles, mais ce sont désormais tous les framabooks qui vont bénéficier de la puissance de cet outil et des compétences de l’équipe de la Poule ou l’Oeuf.

Parenthèse fermée. Un mois plus tard, en décembre 2008, j’écrivis à Sam Williams pour lui demander une préface. Il accepta, tout en me précisant qu’il aurait bien aimé que Richard Stallman eût participé aux éventuelles modifications de l’ouvrage en anglais mais que finalement cela ne s’était pas produit. À ce moment-là, je ne compris guère l’allusion qui trouva son explication quelques jours plus tard.

Nous réfléchissions également aux illustrations possibles de l’ouvrage. Il y avait une belle photo de Richard Stallman dans le livre d’origine chez O’Reilly, tirée du site web personnel de Richard. Je contacte donc ce dernier, non seulement pour lui demander l’autorisation d’utiliser sa photo, mais aussi pour l’informer que nous comptions publier la traduction en français (une traduction en italien avait été publiée en 2003).

C’est là que tout a basculé (positivement).

Il faut savoir que le livre Free as in Freedom n’a jamais obtenu l’appui formel de Richard Stallman. Pire : Richard aurait déjà affirmé qu’il était hors de question de venir lui demander un autographe sur le livre. On peut légitimement se demander pourquoi… Certes le travail de Sam Williams est d’abord un travail de journaliste, et il dresse un portrait sans concession de la personnalité de Richard Stallman : introverti, controversé, irascible et intransigeant. Tous ceux qui se sont rendus au moins une fois à l’une de ses conférences et qui sont au courant de ses activités, ont une bonne idée de ce que je veux dire.

Mais ce n’est pas sur ce point que Richard Stallman était en désaccord avec l’ouvrage : il y avait des erreurs manifestes voire des interprétations faussées dans les faits concrets relatés dans l’ouvrage. En somme, un travail mené un peu trop vite et sans assez de recul. Par ailleurs, un programmeur de l’envergure de Richard Stallman met un point d’honneur à vouloir reformuler avec exactitude les approximations, même lorsqu’elles ont été commises volontairement dans le but de rendre l’ouvrage plus accessible. Il n’en demeure pas moins que sous le prétexte de l’accessibilité, certaines approximations transformaient carrément le propos ou les évènements. La manière dont Richard a agit sur le texte est relatée dans sa préface et lorsque le propos relève notamment de l’interprétation personnelle de Sam Williams, les ajouts de Richard sont clairement identifiés dans le livre par des encarts et des notes de bas de page. Les lecteurs pourront donc se faire une bonne idée des transformations ainsi opérées, quitte à aller voir et comparer avec l’original de Sam Williams.

Je prends un exemple : lorsque Sam Williams relate la tension entre Eric S. Raymond et Richard Stallman, on comprend que Raymond accuse Richard d’être la principale cause du manque de réactivité du projet Hurd (le projet de noyau du système GNU), et que cette accusation est fondée (on se doute néanmoins que Raymond n’a pas bien digéré la fin de non recevoir pour les modifications de l’éditeur Emacs qu’il voulait imposer). Pour Williams, et aussi pour Raymond, c’est le « micro-management » à la Stallman, c’est à dire sans concession, qui a freiné Hurd, avec pour conséquence la popularisation du noyau Linux, qui obéit, lui, à un schéma de développement beaucoup plus ouvert. Il serait pourtant simpliste de se contenter de cette interprétation. Richard l’explique autrement, tant en montrant que Hurd n’est pas une mince affaire qu’en montrant aussi que le noyau Linux n’est pas la panacée du point de vue technique comme du point de vue éthique (le plus important à ses yeux).

Bref, suite à mon courriel, Richard me répondit qu’il désirait apporter quelques précisions sur l’épisode LMI et Symbolics, deux entreprises qui débauchèrent le gros de l’équipe de hackers du MIT au début des années 1980. Cet épisode était très important, mais il ne touchait en gros qu’une dizaine de paragraphes dans l’ouvrage. Lorsque j’en fis référence à l’équipe de notre liste de discussion, tout le monde approuva l’idée.

Pourtant, au fil des échanges, Richard me confia qu’il n’avait jamais lu le livre de Sam Williams, et qu’en lisant les chapitres en anglais que je lui envoyais (repris depuis le site personnel de Sam Williams), il ressentait fortement le besoin de le réécrire.

Et tout l’art du hacker se révéla.

Alors que je lui suggérais d’écrire lui-même son autobiographie (d’un certain côté, j’anticipais sur mes craintes : la retraduction de l’ensemble à partir de toutes ces nouvelles modifications !), il se contenta de me renvoyer des chapitres réécris, sur lesquels je faisais un « diff » (une commande Unix permettant d’afficher les différences entre deux fichiers) pour pouvoir implémenter ces modifications dans la traduction française.

Après tout, qu’est-ce qu’un hacker ? Le lecteur en trouvera une bonne définition historique en annexe de l’ouvrage. L’essentiel est de comprendre que « hacker » signifie surtout améliorer, et qu’un bon hacker qui se respecte ne supporte pas l’imperfection. En toute logique, Richard ressentait tout simplement l’envie irrésistible de « hacker » le livre de Sam Williams. Qui d’autre sinon lui ?

J’énonce tout ceci avec le recul que me permet la parution de l’ouvrage. Dans les faits, je recevais plusieurs courriels par semaine contenant les modifications de Richard. Je les implémentais après les avoir lues, demandé des précisions, et argumenté lorsqu’elles étaient discutables. Bref, un travail soutenu qui nous amena Richard et moi jusqu’au début de l’été 2009.

Un mois auparavant, Alexis avait rencontré Muriel Shan Sei Fan, directrice de la collection Accès Libre aux éditions Eyrolles. Et entre la poire et le fromage, il évoqua « l’aventure » de cette traduction qu’il continuait à suivre attentivement. Muriel trouva le projet tant est si bien intéressant qu’elle nous proposa de le publier chez eux.

Nous acceptâmes, mais ce serait vous mentir que d’affirmer que ce fut une décision facile et unanime dans l’équipe. En effet, nous avons, et nous avons encore, nos habitudes chez InLibroVeritas, l’éditeur si particulier et attachant de tous les autres framabooks, avec qui nous travaillons main dans la main depuis des années pour défendre et faire la promotion du logiciel libre et sa culture.

Plusieurs arguments ont cependant pesé dans la balance. Tout d’abord nous n’avions plus affaire cette fois à un livre sur un logiciel libre particulier (Thunderbird, OpenOffice.org, LaTeX, Ubuntu…). Nous étions face à un livre mutant, une traduction devenue « biographie autorisée » car modifiée et enrichie pour l’occasion par son sujet même. Et pas n’importe quel sujet : la plus illustre des personnalités de la jeune histoire du logiciel libre. Cela méritait assurément de rechercher la plus grande exposition possible. Outre sa capacité de diffusion et distribution, Eyrolles nous offrait aussi son expertise et expérience. Le livre avait été traduit et une première fois relu, mais nous étions néanmoins conscients de sa perfectibilité de par les conditions mêmes de sa réalisation mentionnées plus haut (sachant de plus qu’à ce moment précis de l’histoire Richard n’en avait toujours pas fini avec ses propres modifications). Eyrolles a ainsi retravaillé le texte et mis à disposition du projet plusieurs personnes non seulement pour effectuer de nouvelles relectures mais parfois même pour retraduire certains passages. J’ajoute que nous appréciions la collection pionnière Accès Libre qui abrite en son sein de nombreux ouvrages de qualité sur le logiciel libre. Et enfin dernier argument et non des moindres : sous notre impulsion, Eyrolles allait pour la première fois publier d’emblée un livre sous licence libre, avec tous les avantages et inconvénients que cela suppose.

Nous nous rencontrâmes in the real life, Muriel, Richard, Alexis et moi, au cours d’un déjeuner en marge des Rencontres mondiales du logiciel libre de Nantes en juillet 2009. Nous discutâmes des modalités de publication et surtout, justement, de la question de la licence. L’ouvrage d’origine étant sous licence GNU Free Documentation License (à cause d’un Stallman insistant, Sam Williams s’en explique à la fin de son livre), sa traduction ne pouvait que l’être également. Or publier sous licence libre n’était pas dans les habitudes d’Eyrolles et cela ne rentrait pas forcement dans les « cases » de ses contrats types (rien que le fait d’interdire la classique interdiction de photocopier était une nouveauté). De plus nous connaissons les positions sans concession de Stallman dès que l’on touche à ces questions de licence. Mais nous avons néanmoins réussi sans trop de mal à nous mettre d’accord, et il faut rendre ici hommage aux éditions Eyrolles d’avoir su s’adapter et innover.

La dernière ligne droite fut en tout cas aussi passionnante que stressante, avec ses nombreux va-et-vient entre Richard (apportant ses dernières modifications), Eyrolles (éditant à la volée l’ensemble de l’ouvrage), La Poule (obligée à mettre en forme un texte sans cesse en mouvement) et moi (dispersé un peu partout). Toujours est-il que vers la fin décembre 2009, ouf, nous étions prêts et le projet bouclé. Nous méritions tous ce beau cadeau de Noël que nous nous offrions là 😉

De leur côté, Richard Stallman et John Sullivan vont très prochainement publier en anglais le livre dans sa nouvelle version, aux éditions internes à la Free Software Foundation, ajoutant ainsi une dimension supplémentaire au projet. Non seulement nous touchons les lecteurs francophones, mais le monde anglophone pourra aussi se délecter de ce « hack biographique ». Grâce à la licence libre (et aux efforts de quelques uns), le livre, parti des États-Unis, revient à la maison après un détour par la France qui l’aura transformé !

Pour moi, ce livre n’est pas seulement une biographie, même s’il en a l’apparence et la saveur. Il s’agit d’une histoire, celle du mouvement pour le logiciel libre, qui a influencé profondément l’histoire générale de l’informatique depuis la fin des années 1960. On considère généralement cette histoire à travers celle de l’industrie logicielle ou des composants d’ordinateurs. Mais il manque souvent une approche en termes de pratiques d’ingénierie et de circulation de l’information. Le logiciel libre constitue en cela une belle illustration de l’ingénierie logicielle, qui avance non seulement par projet, mais aussi parce qu’elle est fondamentalement un débat permanent sur la disponibilité et le partage de l’information. Lorsque le partage d’idées est impossible (notamment à cause des brevets) et lorsque les développeurs et les utilisateurs sont restreints dans leurs libertés, alors c’est la société toute entière qui pâti de la pénurie de code et de libertés.

Tous les métiers ont leur déontologie. Les informaticiens ont une éthique et ceux qui la distillent sont les hackers. Par delà ses actes et ses programmes, l’un des principaux mérites de Richard Stallman est d’avoir réussi à concentrer et matérialiser cette éthique dans une simple licence (la fameuse GNU General Public License), qui va non seulement fonder, défendre et diffuser le logiciel libre mais qui constitue aujourd’hui une référence et une source d’inspiration pour d’autres mouvements émancipateurs. En fait, les programmes ont toujours été libres, et c’est un non-sens éthique qui les a rendu privateurs à un moment donné. L’histoire de l’informatique est heureusement loin d’être terminée.

Celle de ce livre touche par contre à sa fin, puisqu’il sera officiellement publié le 21 janvier prochain sous le titre Richard Stallman et la révolution du logiciel libre – Une biographie autorisée. Je remercie chaleureusement tous ceux que cette aventure a mis sur notre chemin. Toutes ces rencontres qui font aussi le sel d’un tel projet. À Framasoft, nous sommes fiers d’avoir pu le mener à son terme. Et malgré le labeur qui n’a pas manqué, ce fut un réel plaisir. Plaisir que nous espérons désormais partager avec le lecteur…

Cette histoire touche donc à sa fin, disais-je, mais, licence libre oblige, rien ne dit qu’il ne subisse pas à l’avenir d’autres métamorphoses. Ne serait-ce que parce que Richard est heureusement toujours parmi nous et qu’il lui reste encore certainement de belles pages à écrire dans le livre de sa vie.