Le 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

Tout 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.

C’est le troisième billet du Framablog sur Al Jazeera et son dépôt de vidéos sous licence Creative Commons By.

Il annonce le fait que désormais on n’y trouve plus uniquement des documents sur la récente de guerre de Gaza, mais également de reportages sur la vie quotidienne en Iraq.

Le blog des Creative Commons se félicite de la nouvelle (traduit ci-dessous).

Après, c’est une question de point de vue et d’appréciation, parce que, même si moi aussi je ne parle pas arabe, les thèmes choisis peuvent tout aussi bien entrer dans la catégorie « vie quotidienne en Irak » que dans la catégorie moins neutre « difficultés de la vie quotidienne en Irak sous occupation américaine » (cf cet enfant gravement blessé de l’image ci-contre issue du reportage The child Abdullah).

Vie quotidienne en Irak – De nouvelles vidéos Al Jazeera

Daily life in Iraq – new footage at Al Jazeera

Jane Park – 14 janvier 2010 – Creative Commons Blog
(Traduction Framalang : Quentin et Pierre)

Al Jazeera a inauguré l’an passé son dépôt d’archives sous licence Creative Commons : 12 vidéos filmées à Gaza, placées sous la plus libre des licence CC, la CC-Attribution. Depuis lors, la collection d’Al Jazeera a grossi ; des vidéos sur la vie quotidienne et la culture en Irak comptent parmi leurs derniers reportages.

Regardez la vidéo de cet artiste iraquien sculptant un Minaret et peignant un arbre. Les sculptures semblent être enrobée dans de l’or ou une autre matière – je ne suis pas tout à fait sûr car je ne parle pas couramment arabe. La bonne nouvelle est que ce film, ainsi que toutes les autres vidéos archivées, est sous licence BY, ce qui permet à quelqu’un d’aider à les traduire en anglais ou dans une autre langue, pour être utilisées par les diffuseurs concurrents ou intégrées à des documentaires.

D’autres vidéos traitent du réseau de communication en Irak, de l’usine pharmaceutique de Samarra et des fermes de volailles.

Vous pouvez aussi monter ces vidéos pour raconter une histoire fascinante, que ce soit par un clip de 30 secondes ou un film de 20 minutes. Peut-être même l’accompagnerez-vous d’une bande sonore sous licence CC… Soyez créatif ! Énormément de matériel est disponible sous licence CC. Toutes les vidéos de la vidéothèque Creative Commons d’Al-Jazeera sont disponibles via la licence CC BY. Ceci signifie que vous pouvez les éditer, les adapter, les traduire, les remixer ou en faire tout autre usage tant que vous créditez Al-Jazeera. Les personnes intéressées pourront ajouter le dépôt d’archivage d’Al-Jazeera dans leurs flux Miro.

Le 21 janvier 2010 va donc sortir la « biographie autorisée » de Richard Stallman aux éditions Eyrolles. Et autant vous prévenir tout de suite, comme c’est un évènement de taille pour nous, on risque d’y revenir souvent ces prochains jours sur ce blog.

Dans un précédent billet nous dévoilions simplement la couverture du livre. Aujourd’hui ce n’est plus une minute mais carrément quarante-cinq minutes d’attention qui sont requises si vous voulez en savoir plus (mais alors pour le coup, beaucoup, beaucoup plus).

Il s’agit de la vidéo de l’intervention que nous avons donné l’été dernier aux Rencontres Mondiales du Logiciel Libre de Nantes. La conférence s’intitulait, avec la modestie qui nous caractérise, « La passionnante histoire d’un livre sur Richard Stallman ».

Mais quand bien même ce titre ne soit qu’un clin d’œil à un film célèbre, on peut cependant se risquer à affirmer que nous sommes en face d’un projet pour le moins original. D’abord parce qu’il s’agit du ouvrage collaboratif sous licence libre signé chez un éditeur classique, mais aussi et surtout parce qu’il est plutôt rare de voir le sujet même d’une biographie décider de corriger et modifier sa propre biographie à l’occasion de sa traduction !

La conférence balaie la chronologie du projet et met en scène quatre des principaux acteurs impliqués. Par ordre d’apparition :

• Alexis Kauffmann (Framasoft), à l’initiative du projet
• Christophe Masutti (Framasoft), animateur principal du projet
• Chloé Girard (La Poule ou l’Œuf), pour le logiciel de rédaction et publication du projet
• Muriel Shan Sei Fan (Eyrolles), l’éditrice du projet

—> La vidéo au format webm

Autres liens de téléchargement (torrents inclus)

Le jeudi 21 janvier prochain sera une date un peu particulière pour Framasoft, puisqu’il s’agira de l’aboutissement d’un long et passionnant projet initié ici-même il y a plus de deux ans.

Nous vous en dirons plus très prochainement mais en attendant voici en avant-première la couverture définitive du livre.

Le Framablog termine l’année avec une traduction de poids qui offre quelque part une excellente transition entre la décennie précédente et la décennie suivante, parce que le vaste sujet évoqué sera, mais en fait est déjà, un enjeu crucial pour l’avenir.

Le mot « open » est servi à toutes les sauces en ce moment dans le monde anglophone. Un peu comme l’écologie, c’est un mot à la mode qui pénètre de plus en plus de domaines, et tout le monde se doit de l’être ou de feindre de l’être sous peine d’éveiller les soupçons, voire la réprobation.

Mais dans la mesure où il n’en existe pas de définition précise, chacun le comprend comme il veut ou comme il peut. Et l’écart peut être grand entre un logiciel libre et une multinationale qui se déclarent tous deux comme « open ». Une multinationale comme Google par exemple !

Il n’est pas anodin que le vice-président de la gestion des produits et du marketing, Jonathan Rosenberg, ait pris aujourd’hui sa plume pour publiquement expliquer (ou tenter d’expliquer) dans le détail ce que Google entendait par « open », dans un récent billet du blog officiel de la société intitulé, excusez du peu, The meaning of Open (comme d’autres s’interrogent sur the meaning of life).

Tout comme l’autre géant Facebook, Google est en effet actuellement sous la pression de ceux qui, entre autres, s’inquiètent du devenir des données personnelles traitées par la société^[1]. Et cette pression ira croissante au fur et à mesure que Google aura une place de plus en plus grande sur Internet, à grands coups de services qui se veulent à priori tous plus intéressants les uns que les autres.

« Don’t be evil » est le slogan à double tranchant que s’est donné Google. Nous ne sommes certainement pas en face du diable, mais ce n’est pas pour autant que nous allons lui accorder le bon Dieu sans confession.

À vous de juger donc si, dans le contexte actuel, ce document est une convaincante profession de foi.

Nous avons choisi de traduire tout du long « open » par « ouverture » ou « ouvert ». L’adéquation n’est pas totalement satisfaisante, mais laisser le terme d’origine en anglais eut été selon nous plus encore source de confusion.

L’ouverture selon Google

Google and The meaning of open

Jonathan Rosenberg – 21 décembre 2009 – Blog officiel de Google
(Traduction non officielle Framalang : Goofy et Olivier)

La semaine dernière j’ai envoyé un email interne sur le sens de « l’ouverture » appliquée à Internet, Google et nos utilisateurs. Dans un souci de transparence, j’ai pensé qu’il pouvait être opportun de partager également ces réflexions à l’extérieur de notre entreprise.

Chez Google nous sommes persuadés que les systèmes ouverts l’emporteront. Ils conduisent à davantage d’innovation, de valeur, de liberté de choix pour les consommateurs et à un écosystème dynamique, lucratif et compétitif pour les entreprises. Un grand nombre d’entre elles prétendront à peu près la même chose car elles savent que se positionner comme ouvertes est à la fois bon pour leur image de marque et totalement sans risque. Après tout, dans notre industrie il n’existe pas de définition précise de ce que peut signifier « ouvert ». C’est un terme à la Rashomon (NdT : expression issue du film éponyme de Kurosawa) : à la fois extrêmement subjectif et d’une importance vitale.

Le thème de l’ouverture est au centre de nombreuses discussions ces derniers temps chez Google. J’assiste à des réunions autour d’un produit où quelqu’un déclare que nous devrions être davantage « ouverts ». Il s’ensuit un débat qui révèle que même si l’« ouverture » fait l’unanimité, nous ne sommes pas forcément d’accord sur ce qu’elle implique concrètement.

Face à ce problème récurrent, j’en arrive à penser que nous devrions exposer notre définition de l’ouverture en termes suffisamment clairs, afin que chacun puisse la comprendre et la défendre. Je vous propose ainsi une définition fondée sur mes expériences chez Google et les suggestions de plusieurs collègues. Ces principes nous guident dans notre gestion de l’entreprise et dans nos choix sur les produits, je vous encourage donc à les lire soigneusement, à les commenter et les débattre. Puis je vous invite à vous les approprier et à les intégrer à votre travail. Il s’agit d’un sujet complexe et si un débat à lieu d’être (ce dont je suis persuadé), il doit être ouvert ! Libre à vous d’apporter vos commentaires.

Notre définition de l’ouverture repose sur deux composantes : la technologie ouverte et l’information ouverte. La technologie ouverte comprend d’une part l’open source, ce qui veut dire que nous soutenons activement et publions du code qui aide Internet à se développer, et d’autre part les standards ouverts, ce qui signifie que nous adhérons aux standards reconnus et, s’il n’en existe pas, nous travaillons à la création de standards qui améliorent Internet (et qui ne profitent pas seulement à Google). L’information ouverte comprend selon nous trois idées principales : tout d’abord les informations que nous détenons sur nos utilisateurs servent à leur apporter une valeur ajoutée, ensuite nous faisons preuve de transparence sur les informations les concernant dont nous disposons, et enfin nous leur donnons le contrôle final sur leurs propres informations. Voilà le but vers lequel nous tendons. Dans bien des cas nous ne l’avons pas encore atteint, mais j’espère que la présente note contribuera à combler le fossé entre la théorie et la pratique.

Si nous pouvons incarner un engagement fort à la cause de l’ouverture, et je suis persuadé que nous le pouvons, nous aurons alors une occasion unique de donner le bon exemple et d’encourager d’autres entreprises et industries à adopter le même engagement. Et si elles le font, le monde s’en trouvera un peu meilleur.

Les systèmes ouverts sont gagnants

Pour vraiment comprendre notre position, il faut commencer par l’assertion suivante : les systèmes ouverts sont gagnants. Cela va à l’encontre de tout ce en quoi croient ceux qui sont formatés par les écoles de commerce, ceux qui ont appris à générer une avantage compétitif durable en créant un système fermé, en le rendant populaire, puis en tirant profit du produit pendant tout son cycle de vie. L’idée répandue est que les entreprises devraient garder les consommateurs captifs pour ne laisser aucune place à la concurrence. Il existe différentes approches stratégiques, les fabricants de rasoirs vendent leurs rasoirs bon marché et leurs lames très cher, tandis que ce bon vieux IBM fabrique des ordinateurs centraux coûteux et des logiciels… coûteux aussi. D’un autre côté, un système fermé bien géré peut générer des profits considérables. Cela permet aussi à court terme de mettre sur le marché des produits bien conçus, l’iPod et l’iPhone en sont de bons exemples, mais finalement l’innovation dans un système fermé tend à être, au mieux, incrémentale (est-ce qu’un rasoir à quatre lames est vraiment tellement mieux qu’un rasoir à trois lames ?). Parce que la priorité est de préserver le statu quo. L’autosatisfaction est la marque de fabrique de tous les systèmes fermés. Si vous n’avez pas besoin de travailler dur pour garder votre clientèle, vous ne le ferez pas.

Les systèmes ouverts, c’est exactement l’inverse. Ils sont compétitifs et bien plus dynamiques. Dans un système ouvert, un avantage compétitif n’est pas assujetti à l’emprisonnement des consommateurs. Il s’agit plutôt de comprendre mieux que tous les autres un système très fluctuant et d’utiliser cette intuition pour créer de meilleurs produits plus innovants. L’entreprise qui tire son épingle du jeu dans un système ouvert est à la fois douée pour l’innovation rapide et la conception avant-gardiste ; le prestige du leader dans la conception attire les consommateurs et l’innovation rapide les retient. Ce n’est pas facile, loin de là, mais les entreprises qui réagissent vite n’ont rien à redouter, et lorsqu’elles réussissent elles peuvent générer de gigantesques dividendes.

Systèmes ouverts et entreprises prospères ne sont pas inconciliables. Ils tirent parti de l’intelligence collective et incitent les entreprises à une saine concurrence, à l’innovation et à miser leur succès sur le mérite de leurs produits et pas seulement sur un brillant plan marketing. La course à la carte du génome humain est un bon exemple.

Dans leur livre Wikinomics, Don Tapscott et Anthony Williams expliquent comment, au milieu des années 90, des entreprises privées ont découvert et breveté de grandes portions des séquences de l’ADN et ont prétendu contrôler l’accès à ces données et leur tarif. Faire ainsi du génome une propriété privée a fait grimper les prix en flèche et a rendu la découverte de nouveaux médicaments bien plus difficile. Et puis, en 1995, Merck Pharmaceuticals et le Centre de Séquençage du Génome de l’Université de Washington ont changé la donne avec une nouvelle initiative « ouverte » baptisée l’Index Génétique Merck. En trois ans seulement ils ont publié plus de 800 000 séquences génétiques et les ont mises dans le domaine public et bientôt d’autres projets collaboratifs ont pris le relais. Tout cela au sein d’un secteur industriel où la recherche initiale et le développement étaient traditionnellement menés dans des laboratoires « fermés ». Par sa démarche « ouverte », Merck a donc non seulement modifié la culture d’un secteur entier mais aussi accéléré le tempo de la recherche biomédicale et le développement des médicaments. L’entreprise a donné aux chercheurs du monde entier un accès illimité à des données génétiques, sous forme d’une ressource « ouverte ».

Les systèmes ouverts permettent l’innovation à tous les niveaux, voilà une autre différence majeure entre les systèmes ouverts et fermés. Ils permettent d’innover à tous les étages, depuis le système d’exploitation jusqu’au niveau de l’application, et pas uniquement en surface. Ainsi, une entreprise n’est pas dépendante du bon vouloir d’une autre pour lancer un produit. Si le compilateur GCC que j’utilise a un bogue, je peux le corriger puisque le compilateur est open source. Je n’ai pas besoin de soumettre un rapport de bogue et d’espérer que la réponse arrivera rapidement.

Donc, si vous essayez de stimuler la croissance d’un marché entier, les systèmes ouverts l’emportent sur les systèmes fermés. Et c’est exactement ce que nous nous efforçons de faire avec Internet. Notre engagement pour les systèmes ouverts n’est pas altruiste. C’est simplement dans notre intérêt économique puisque un Internet ouvert génère un flot continu d’innovations qui attirent les utilisateurs et créé de nouveaux usages, pour finalement faire croître un marché tout entier. Hal Varian note cette équation dans son livre Les règles de l’information :

 le gain = (la valeur totale ajoutée à une industrie) x (la part de marché dans cette industrie) 

Toutes choses étant égales par ailleurs, une augmentation de 10% de l’un ou l’autre de ces deux facteurs devrait produire au résultat équivalent. Mais dans notre marché une croissance de 10% génèrera un revenu bien supérieur parce qu’elle entraîne des économies d’échelle dans tout le secteur, augmentant la productivité et réduisant les coûts pour tous les concurrents. Tant que nous continuerons d’innover en sortant d’excellents produits, nous prospèrerons en même temps que tout notre écosystème. Nous aurons peut-être une part plus petite, mais d’un plus grand gâteau.

En d’autres termes, l’avenir de Google dépend de la sauvegarde d’un Internet ouvert, et notre engagement pour l’ouverture développera le Web pour tout le monde, y compris Google.

La technologie ouverte

Pour définir l’ouverture, il faut commencer par les technologies sur lesquelles repose Internet : les standards ouverts et les logiciels open source.

Les standards ouverts

Le développement des réseaux a toujours dépendu des standards. Lorsqu’on a commencé à poser des voies ferrées à travers les États-Unis au début du 19ème siècle, il existait différents standards d’écartement des voies. Le réseau ferré ne se développait pas et n’allait pas vers l’ouest jusqu’à ce que les diverses compagnies ferroviaires se mettent d’accord sur un écartement standard. (Dans ce cas précis la guerre de standards a été une vraie guerre : les compagnies ferroviaires sudistes furent obligées de convertir plus de 1100 miles au nouveau standard après que la Confédération eut perdu contre l’Union pendant la Guerre Civile.)

Il y eut un autre précédent en 1974 quand Vint Cerf et ses collègues proposèrent d’utiliser un standard ouvert (qui deviendrait le protocole TCP/IP) pour connecter plusieurs réseaux d’ordinateurs qui étaient apparus aux USA. Ils ne savaient pas au juste combien de réseaux avaient émergé et donc « l’Internet », mot inventé par Vint, devait être ouvert. N’importe quel réseau pouvait se connecter en utilisant le protocole TCP/IP, et grâce à cette décision à peu près 681 millions de serveurs forment aujourd’hui Internet.

Aujourd’hui, tous nos produits en développement reposent sur des standards ouverts parce que l’interopérabilité est un élément crucial qui détermine le choix de l’utilisateur. Quelles en sont les implications chez Google et les recommandation pour nos chefs de projets et nos ingénieurs ? C’est simple : utilisez des standards ouverts autant que possible. Si vous vous risquez dans un domaine où les standards ouverts n’existent pas, créez-les. Si les standards existants ne sont pas aussi bons qu’ils le devraient, efforcez-vous de les améliorer et rendez vos améliorations aussi simples et documentées que possible. Les utilisateurs et le marché au sens large devraient toujours être nos priorités, pas uniquement le bien de Google. Vous devriez travailler avec les organismes qui établissent les normes pour que nos modifications soient ajoutées aux spécifications validées.

Nous maitrisons ce processus depuis un certain temps déjà. Dans les premières années du Google Data Protocol (notre protocole standard d’API, basé sur XML/Atom), nous avons travaillé au sein de l’IEFT (Atom Protocol Working Group) à élaborer les spécifications pour Atom. Mentionnons aussi notre travail récent au WC3 pour créer une API de géolocation standard qui rendra plus facile le développement d’applications géolocalisées pour le navigateur. Ce standard aide tout le monde, pas seulement nous, et offrira aux utilisateurs beaucoup plus d’excellentes applications mises au point par des milliers de développeurs.

Open source

La plupart de ces applications seront basées sur des logiciels open source, phénomène à l’origine de la croissance explosive du Web de ces quinze dernières années. Un précédent historique existe : alors que le terme « Open Source » a été créé à la fin des années 90, le concept de partage de l’information utile dans le but de développer un marché existait bien avant Internet. Au début des années 1900, l’industrie automobile américaine s’accorda sur une licence croisée suivant laquelle les brevets étaient partagés ouvertement et gratuitement entre fabricants. Avant cet accord, les propriétaires du brevet des moteurs à essence à deux temps contrôlaient carrément l’industrie.

L’open source de nos jours va bien plus loin que le groupement de brevets de l’industrie automobile naissante, et a conduit au développement des composants logiciels sur lesquels est bâti Google : Linux, Apache, SSH et d’autres. En fait, nous utilisons des dizaines de millions de lignes de code open source pour faire tourner nos produits. Nous renvoyons aussi l’ascenseur : nous sommes les plus importants contributeurs open source du monde, avec plus de 800 projets pour un total de 20 millions de lignes de code open source, avec quatre projets (Chrome, Android, Chrome OS et le Google Web Toolkit) qui dépassent chacun un million de lignes. Nos équipes collaborent avec Mozilla et Apache et nous fournissons une plateforme d’hébergement de projets open source (code.google.com/hosting) qui en accueille plus de 250 000. Ainsi, non seulement nous savons que d’autres peuvent participer au perfectionnement de nos produits, mais nous permettons également à tout un chacun de s’inspirer de nos produits s’il estime que nous n’innovons plus assez.

Lorsque nous libérons du code, nous utilisons la licence ouverte, standard, Apache 2.0, ce qui signifie que nous ne contrôlons pas le code. D’autres peuvent s’en emparer, le modifier, le fermer et le distribuer de leur côté. Android en est un bon exemple, car plusieurs assembleurs OEM ont déjà tiré parti du code pour en faire des choses formidables. Procéder ainsi comporte cependant des risques, le logiciel peut se fragmenter entre différentes branches qui ne fonctionneront pas bien ensemble (souvenez-vous du nombre de variantes d’Unix pour station de travail : Apollo, Sun, HP, etc.). Nous œuvrons d’arrache-pied pour éviter cela avec Android.

Malgré notre engagement pour l’ouverture du code de nos outils de développement, tous les produits Google ne sont pas ouverts. Notre objectif est de maintenir un Internet ouvert, qui promeut le choix et la concurrence, empêchant utilisateurs et développeurs d’être prisonniers. Dans de nombreux cas, et particulièrement pour notre moteur de recherche et nos projets liés à la publicité, ouvrir le code ne contribuerait pas à atteindre ces objectifs et serait même dommageable pour les utilisateurs. La recherche et les marchés publicitaires se livrent déjà une concurrence acharnée pour atteindre les prix les plus justes, si bien que les utilisateurs et les publicitaires ont déjà un choix considérable sans être prisonniers. Sans parler du fait qu’ouvrir ces systèmes permettrait aux gens de « jouer » avec nos algorithmes pour manipuler les recherches et les évaluations de la qualité des publicités, en réduisant la qualité pour tout le monde.

Alors lorsque que vous créez un produit ou ajoutez de nouvelles fonctions, il faut vous demander : est-ce que rendre ce code open source va promouvoir un Internet ouvert ? Est-ce qu’il va augmenter le choix de l’utilisateur, du publicitaire et des partenaires ? Est-ce qu’il va en résulter une plus grande concurrence et davantage d’innovation ? Si c’est le cas, alors vous devriez passer le code en open source. Et quand vous le ferez, faite-le pour de bon ; ne vous contentez pas de le balancer dans le domaine public et puis de l’oublier. Assurez-vous que vous avez les ressources pour maintenir le code et que vos développeurs soient prêt à s’y consacrer. Le Google Web Toolkit, que nous avons développé en public en utilisant un gestionnaire de bogues et un système de version publics, est ainsi un exemple de bonnes pratiques.

L’information ouverte

La création des standards ouverts et de l’open source a transformé le Web en un lieu où d’énormes quantités d’informations personnelles sont régulièrement mises en ligne : des photos, des adresses, des mises à jour… La quantité d’informations partagées et le fait qu’elles soient enregistrées à jamais impliquent une question qu’on ne se posait pas vraiment il y a quelques années : qu’allons-nous faire de ces informations ?

Historiquement, les nouvelles technologies de l’information ont souvent permis l’émergence de nouvelles formes de commerce. Par exemple, quand les marchands du bassin méditerranéen, vers 3000 avant JC ont inventé les sceaux (appelés bullae) pour s’assurer que leur cargaison atteindrait sa destination sans être altérée, ils ont transformé un commerce local en commerce longue distance. Des modifications semblables ont été déclenchées par l’apparition de l’écriture, et plus récemment, par celle des ordinateurs. À chaque étape, la transaction, un accord mutuel où chaque partie trouve son compte, était générée par un nouveau type d’information qui permettait au contrat d’être solidement établi.

Sur le Web la nouvelle forme de commerce, c’est l’échange d’informations personnelles contre quelque chose qui a de la valeur. C’est une transaction à laquelle participent des millions d’entre nous chaque jour et qui a d’énormes avantages potentiels. Un assureur automobile peut surveiller les habitudes de conduite d’un client en temps réel et lui donner un bonus s’il conduit bien, un malus dans le cas contraire, grâce aux informations (suivi GPS) qui n’étaient pas disponibles il y a seulement quelques années. C’est une transaction tout à fait simple, mais nous rencontrerons des cas de figure bien plus délicats.

Supposons que votre enfant ait une allergie à certains médicaments. Est-ce que vous accepteriez que son dossier médical soit accessible par une seringue intelligente en ligne qui empêcherait un médecin urgentiste ou une infirmière de lui administrer accidentellement un tel médicament ? Moi je pourrais le faire, mais vous pourriez décider que le bracelet autour de son poignet est suffisant (NdT : voir allergy bracelet). Et voilà le problème, tout le monde ne prendra pas la même décision, et quand on en vient aux informations personnelles nous devons traiter chacune de ces décisions avec le même respect.

Mais si mettre davantage d’informations en ligne peut être bénéfique pour tout le monde, alors leurs usages doivent être régis par des principes suffisamment responsables, proportionnés et flexibles pour se développer et s’adapter à notre marché. Et à la différence des technologies ouvertes, grâce auxquelles nous souhaitons développer l’écosystème d’Internet, notre approche de l’information ouverte est de créer la confiance avec les individus qui s’engagent dans cet écosystème (les utilisateurs, les partenaires et les clients). La confiance est la monnaie la plus importante en ligne, donc pour la créer nous adhérons à trois principes de l’information ouverte : valeur, transparence et contrôle.

La valeur

En premier lieu, nous devons créer des produits qui ont une valeur aux yeux des utilisateurs. Dans de nombreux cas, nous pouvons faire des produits encore meilleurs si nous disposons de davantage d’informations sur l’utilisateur, mais des problèmes de protection de la vie privée peuvent survenir si les gens ne comprennent pas quelle valeur ajoutée ils obtiennent en échange de leurs informations. Expliquez-leur cette valeur cependant, et le plus souvent ils accepteront la transaction. Par exemple, des millions de gens laissent les organismes de cartes de crédit retenir leurs informations au moment de l’achat en ligne, en échange cela leur évite d’utiliser de l’argent liquide.

C’est ce que nous avons fait lorsque nous avons lancé Interest-Based Advertising (la publicité basée sur l’intérêt des utilisateurs) en mars. L’IBA rend les publicités plus pertinentes et plus utiles. C’est une valeur ajoutée que nous avons créée, basée sur les informations que nous collectons. L’IBA comprend aussi un gestionnaire de préférences de l’utilisateur qui lui explique clairement ce qu’il obtiendra en échange de ses informations, qui lui permet de se désengager ou de régler ses paramètres. La plupart des gens parcourant le gestionnaire de préférences choisissent de régler leurs préférences plutôt que de se désinscrire parce qu’ils ont pris conscience de l’intérêt de recevoir des publicités ciblés.

Telle devrait être notre stratégie : dire aux gens, de façon explicite et en langage clair, ce que nous savons d’eux et pourquoi il leur est profitable que nous le sachions. Vous croyez peut-être que la valeur de nos produits est tellement évidente qu’elle n’a pas besoin d’être expliquée ? Pas si sûr.

La transparence

Ensuite, il nous faut permettre aux utilisateurs de trouver facilement quelles informations nous collectons et stockons à travers tous nos produits. Le tableau de bord Google est à ce titre un énorme pas en avant (NdT : le Google Dashboard). En une page, les utilisateurs peuvent voir quelles données personnelles sont retenues par tel produit Google (ce qui couvre plus de 20 produits, notamment Gmail, YouTube et la recherche) et où ils peuvent contrôler leurs paramètres personnels. Nous sommes, à notre connaissance, la première entreprise sur Internet à offrir un tel service et nous espérons que cela deviendra la norme. Un autre exemple est celui de notre politique de confidentialité, qui est rédigée pour des être humains et non pour des juristes.

Nous pouvons cependant en faire plus encore. Tout produit qui récolte des informations sur les utilisateurs doit apparaître sur le tableau de bord. S’il y est déjà, vous n’en avez pas fini pour autant. À chaque nouvelle version ou nouvelle fonctionnalité, demandez-vous si vous ne devriez pas ajouter quelques nouvelles informations au tableau de bord (peut-être même des informations sur les utilisateurs publiquement disponibles sur d’autres sites).

Réfléchissez aux moyen de rendre vos produits plus transparents aussi. Quand vous téléchargez une application pour Android, par exemple, votre appareil vous dit à quelles informations l’application pourra accéder, concernant votre téléphone et vous-même, et vous pouvez alors décider si vous souhaitez ou non poursuivre. Pas besoin de faire une enquête approfondie pour trouver quelles informations vous divulguez, tout est écrit noir sur blanc et vous êtes libre de décider (NdT : allusion à peine voilée aux récents problèmes rencontrés par l’iPhone sur le sujet). Votre produit entre dans cette catégorie ? Comment la transparence peut-elle servir la fidélisation de vos utilisateurs ?

Le contrôle

Nous devons toujours donner le contrôle final à l’utilisateur. Si nous avons des informations sur lui, comme avec l’IBA, il devrait être facile pour lui de les supprimer et de se désinscrire. S’il utilise nos produits et stocke ses contenus chez nous, ce sont ses contenus, pas les nôtres. Il devrait être capable de les exporter et de les supprimer à tout moment, gratuitement, et aussi aisément que possible. Gmail est un très bon exemple de ce processus puisque nous proposons une redirection gratuite vers n’importe quelle adresse. La possibilité de changer d’opérateur est cruciale, donc au lieu de bâtir des murs autour de vos produits, bâtissez des ponts. Donnez vraiment le choix aux utilisateurs.

S’il existe des standards pour gérer les données des utilisateurs, nous devons nous y conformer. S’il n’existe pas de standard, nous devons travailler à en créer un qui soit ouvert et profite au Web tout entier, même si un standard fermé nous serait plus profitable (souvenez-vous que ce n’est pas vrai !). Entretemps nous devons faire tout notre possible pour que l’on puisse quitter Google aussi facilement que possible. Google n’est pas l’Hôtel California (NdT : en référence à la célèbre chanson des Eagles), vous pouvez le quitter à tout moment et vous pouvez vraiment partir, pour de bon !

Comme le signalait Eric dans une note stratégique « nous ne prenons pas les utilisateurs au piège, nous leur facilitons la tâche s’ils veulent se tourner vers nos concurrents ». On peut comparer cette politique aux sorties de secours dans un avion, une analogie que notre PDG apprécierait. Vous espérez n’avoir jamais à les utiliser, mais vous êtes bien content qu’elles soient là et seriez furieux s’il n’y en avait pas.

Voilà pourquoi nous avons une équipe, le Data Liberation Front (dataliberation.org) (NdT : le Front de Libération des Données), dont le travail consiste à rendre la « désinscription » facile. Leurs derniers hauts faits : Blogger (les gens qui choisissent de quitter Blogger pour un autre service peuvent facilement emporter leurs données avec eux) et les Docs (les utilisateurs peuvent maintenant rassembler tous leurs documents, présentations, feuilles de calcul dans un fichier compressé et le télécharger). Créez vos produits en ayant ceci à l’esprit. Vous pouvez le faire grâce à une bonne API publique (NdT : interface de programmation) répertoriant toutes les données de vos utilisateurs. N’attendez pas d’être en version 2 ou 3, discutez-en le plus tôt possible et faites-en une fonctionnalité dès le démarrage de votre projet.

Lorsque les journalistes du Guardian (un quotidien anglais de premier ordre) ont rendu compte des travaux du Data Liberation Front , ils ont déclaré que c’était « contre-intuitif » pour ceux qui sont « habitués à la mentalité fermée des guerres commerciales passées ». Ils ont raison, c’est contre-intuitif pour les gens qui sont restés coincés dans leur conception d’école de commerce, mais si nous faisons bien notre travail, ce ne sera plus le cas. Nous voulons faire de l’ouverture la norme. Les gens vont s’y habituer doucement, ensuite elle deviendra la norme et ils l’exigeront. Et s’ils ne l’obtiennent pas cela ne leur plaira pas. Nous considèrerons notre mission accomplie lorsque l’ouverture ira de soi.

Plus c’est grand, mieux c’est

Les systèmes fermés sont bien définis et génèrent du profit, mais seulement pour ceux qui les contrôlent. Les systèmes ouverts sont chaotiques et génèrent du profit, mais seulement pour ceux qui les comprennent bien et s’adaptent plus vite que les autres. Les systèmes fermés se développent vite alors que les systèmes ouverts se développent plus lentement, si bien que parier sur l’ouverture nécessite de l’optimisme, de la volonté et les moyens de pouvoir se projeter sur le long terme. Heureusement, chez Google nous avons ces trois atouts.

En raison de notre dimension, de nos compétences et de notre appétit pour les projets ambitieux, nous pouvons relever des défis importants nécessitant de lourds investissements sans perspective évidente de rentabilité à court terme. Nous pouvons photographier toutes les rues du monde pour que vous puissiez explorer le quartier autour de l’appartement que vous envisagez de louer, à plusieurs milliers de kilomètres de chez vous. Nous pouvons numériser des milliers de livres et les rendre largement accessibles (tout en respectant les droits des auteurs et des éditeurs). Nous pouvons créer un système de mail qui vous donne un gigaoctet d’espace de stockage (maintenant plus de 7 gigas, en fait) au moment où tous les autres services ne vous procurent guère qu’une petite fraction de ce volume. Nous pouvons traduire instantanément des pages Web dans n’importe quelle des 51 langues disponibles. Nous pouvons traiter des recherches de données qui aident les agences de santé publiques à détecter plus tôt les pics d’épidémie grippale. Nous pouvons élaborer un navigateur plus rapide (Chrome), un meilleur système d’exploitation pour mobile (Android), et une plateforme de communication entièrement nouvelle (Wave), et puis nous pouvons ouvrir tout cela pour que le monde entier puisse innover sur cette base, afin de la personnaliser et l’améliorer.

Nous pouvons réaliser tout cela parce que ce sont des problèmes d’information et que nous avons des spécialistes en informatique, en technologie, et les capacités informatiques pour résoudre ces problèmes. Quand nous le faisons, nous créons de nombreuses plateformes, pour les vidéos, les cartes, les mobiles, les ordinateurs personnels, les entreprises, qui sont meilleures, plus compétitives et plus innovantes. On nous reproche souvent d’être de trop « gros », mais parfois être plus gros nous permet de nous attaquer à ce qui semble impossible.

Tout ceci sera pourtant vain si nous négocions mal le virage de l’ouverture. Il nous faut donc nous pousser nous-mêmes en permanence. Est-ce que nous contribuons à des standards ouverts qui bénéficient à l’industrie ? Qu’est-ce qui nous empêche de rendre notre code open source ? Est-ce que nous donnons à nos utilisateurs davantage de valeur, de transparence et de contrôle ? Pratiquez l’ouverture autant que vous le pouvez et aussi souvent que possible, et si quelqu’un se demande si c’est la bonne stratégie, expliquez-lui pourquoi ce n’est pas simplement une bonne stratégie, mais la meilleure qui soit . Elle va transformer les entreprises et le commerce de ce tout début du siècle, et quand nous l’aurons emporté nous pourrons effectivement ré-écrire les topos des écoles de commerce pour les décennies à venir.

Un Internet ouvert transformera notre vie tout entière. Il aura le pouvoir d’apporter les informations du monde entier jusque dans le creux de la main de chacun et de donner à chacun le pouvoir de s’exprimer librement. Ces prédictions étaient dans un e-mail que je vous ai envoyé au début de cette année (repris ensuite dans un billet du blog) et qui vous décrivait ma vision du futur d’Internet. Mais maintenant je vous parle d’action, pas de vision. L’Internet ouvert a ses détracteurs, des gouvernements désirant en contrôler l’accès, des entreprises luttant dans leur intérêt exclusif pour préserver le statu quo. Ces forces sont puissantes et si elles réussissent, nous allons nous retrouver entravés dans un Internet fragmenté, stagnant, à coût élevé et à faible concurrence.

Nos compétences et notre culture nous offrent l’occasion et nous donnent la responsabilité d’empêcher que cela n’arrive. Nous croyons que la technologie a le pouvoir de répandre l’information. Nous croyons que l’information a le pouvoir d’améliorer les choses. Nous croyons que la majorité ne profitera de cette révolution que grâce à l’ouverture. Nous sommes des techno-optimistes confiants dans l’idée que le chaos de l’ouverture profite à tout le monde. Et nous nous battrons pour la promouvoir en toutes occasions.

L’ouverture l’emportera. Elle l’emportera sur Internet et gagnera par effet boule de neige beaucoup de domaines de notre vie. L’avenir des gouvernements est la transparence. L’avenir du commerce est l’information réciproque. L’avenir de la culture est la liberté. L’avenir de l’industrie du divertissement est l’interactivité. Chacun de ces futurs dépend de l’ouverture d’Internet.

En tant que chefs de produits chez Google, vous élaborez quelque chose qui nous survivra à tous, et personne ne sait dans quelles directions Google poursuivra son développement, ni à quel point Google va changer la vie des gens. Dans cette perspective, nous sommes comme notre collègue Vint Cerf, qui ne savait pas exactement combien de réseaux feraient partie de ce fameux « Internet » et qui l’a laissé ouvert par défaut. Vint a certainement eu raison. Je crois que le futur nous donnera raison aussi.

Ah qu’il était doux et rassurant le temps de l’informatique à grand-papa où nous avions nos ordinateurs fixes qui se connectaient de temps en temps et où nous luttions avec confiance et enthousiasme contre le grand-méchant Microsoft !

Ce temps-là est révolu. Nous entrons dans une autre décennie et il se pourrait bien que le principal sujet de conversation de la communauté du logiciel libre dans les dix ans à venir ne soit plus Microsoft (symbole du logiciel propriétaire, j’ai mal à mes fichiers !) mais Google (symbole de l’informatique dans les nuages, j’ai mal à mes données personnelles !)^[1].

Firefox, bouffé par Chrome ? Ubuntu, court-circuité par Chrome OS ? Le Web tout entier se transformant petit à petit en un fort joli Minitel 2.0 bourré de services Google à tous les coins de rue ? Ces différents scénarios ne relèvent pas forcément de la science-fiction.

Le problème c’est que nous n’avons plus un Microsoft en face d’une limpide ligne de démarcation. Le problème c’est que nous avons affaire à rien moins qu’au premier contributeur open source de la planète. Et cela rend légèrement plus complexe le positionnement…

La plus grande entreprise mondiale de l’open-source ? Google

World’s biggest open-source company? Google

Matt Asay – 16 septembre 2009 – Cnet news
(Traduction Framalang : Julien et Cheval boiteux)

Red Hat est généralement considérée comme la principale société open source de l’industrie, mais c’est une distinction dénuée de sens parce qu’elle est inexacte. Alors que les revenus de Red Hat proviennent des logiciels open source que la société développe et distribue, d’autres entreprises comme Sun, IBM et Google écrivent et contribuent en réalité à beaucoup plus de code open source. Il serait temps d’arrêter de parler d’entreprises open source et de revenir à l’importance du code open source.

L’open source est de plus en plus le socle sur lequel reposent les entreprises d’internet et du logiciel. Myspace a dernièrement fait des vagues en ouvrant les sources de Qizmt, un framework de calcul distribué (qui curieusement tourne sur Windows Server) qui active la fonction « Personnes que tu pourrais connaître » du site. Mais Myspace, comme l’a noté VentureBeat, n’a fait que rattraper la récente ouverture des sources de Tornado par Facebook.

Aucun d’eux ne le fait pour marquer des points auprès des utilisateurs branchés. S’ils le font, c’est motivé par leurs propres intérêts, qui nécessitent de plus en plus souvent d’inciter des communautés de développeurs à adopter et étendre leurs propres applications et services Web.

C’est également un moyen d’améliorer la qualité des logiciels. En adoptant les projets open source d’une entreprise, puis en l’étendant à travers ses propres logiciels open source, la qualité collective de l’open source est forte et croissante, comme le note Kit Plummer d’Accenture.

C’est cette compréhension de l’intérêt qu’il apporte et la qualité qui en découle qui a fait de l’open source une architecture essentielle pour potentiellement tous les logiciels commerciaux, ce qui signifie que Red Hat et d’autres entreprises qui ne font que de l’open source ne sont désormais plus le centre de cet univers.

Le noyau Linux est composé de 11,5 millions de lignes de code, dont Red Hat est responsable à hauteur de 12% (mesuré en termes de lignes de code modifiées). Même si l’on y ajoute le serveur d’applications JBoss Application Server (environ 2 autres millions de lignes de code) et d’autres projets Red Hat, on obtient toujours un total inférieur à d’autres acteurs.

Prenons Sun, par exemple. C’est le principal développeur derrière Java (plus de 6.5 millions de ligne de code), Solaris (plus de 2 millions de lignes de code), OpenOffice (environ 10 millions de lignes) et d’autres projets open source.

Ou bien IBM, qui a contribué à lui seul à 12,5 millions de lignes pour Eclipse, sans parler de Linux (6.3% du total des contributions), Geronimo, et un large éventail d’autres projets open source.

Google, cependant, est la société la plus intéressante de toutes, car elle n’est pas une entreprise de logiciels en soi. J’ai interrogé Chris DiBona, responsable des programmes open source et secteur public de Google, à propos des contributions de la société dans le domaine de l’open source (NdT : Cf Tout, vous saurez tout sur Google et l’Open Source sur le Framablog). Voici sa réponse :

Au bas mot, nous avons libéré environ 14 millions de lignes de code. Android dépasse les 10 millions de lignes, puis vous avez Chrome (2 millions de lignes, Google Web Toolkit (300 000 lignes), et aux alentours d’un projet par semaine sorti au cours des cinq dernières années. Vous avez ainsi quelques centaines d’employés Google qui patchent sur une base hebdomadaire ou mensuelle.

Si DiBona se garde bien de suggérer que Google soit devenu le premier contributeur open source (« disons que nous sommes parmi les premiers »), c’est néanmoins probablement le cas, en particulier lorsque l’on considère ses autres activités open source, incluant Google Code, l’hébergement du plus grand dépôt peut-être de projets open source, avec plus de 250 000 projets hébergés, dont au moins 40 000 sont actifs, sans parler de son Summer of Code. Après tout, les lignes de code, bien que fondamentalement utiles, ne sont pas nécessairement la meilleure mesure de la valeur d’une contribution à l’open source.

En fait, Patrick Finch de la fondation Mozilla estime que la meilleure contribution de Google à l’open source n’a probablement rien à voir avec l’écriture de nouveau code :

La plus grande contribution de Google à l’open-source n’est sans doute pas du code, mais de prouver que vous pouvez utiliser Linux à grande échelle sur des machines démarquées (NdT : whitebox hardware).

C’est une étape importante, et qui souligne le fait que le label « entreprise open source » est devenu quelque peu obsolète. Google ne se présente pas, à juste titre, comme une entreprise open source. L’open source fait simplement partie de leur stratégie pour distribuer des logiciels qui vont aider à vendre davantage de publicité.

Sun a tenté de se transformer en entreprise open source, mais une fois que son acquisition par Oracle aura été finalisée, cette dernière ne va certainement pas prendre ce label. Pas parce que c’est un mauvais label, mais simplement parce qu’il n’est plus pertinent.

Toutes les entreprises sont désormais des entreprises open source. Ce qui signifie aussi qu’aucune ne l’est. L’open source est simplement un élément parmi d’autres de la politique de développement et de croissance de ces entreprises, que l’on s’appelle Red Hat, Microsoft, Google ou Facebook.

Et étant donné que les entreprises du Web comme Google n’ont pas besoin de monétiser directement l’open source, on va en fait avoir l’occasion à l’avenir de voir encore plus de code open source émerger de la part de ces sociétés que ce qui a déjà été réalisé par ces traditionnelles « entreprises de logiciels open-source » que sont Red Hat, Pentaho ou MySQL.

En janvier 2008, Bruce Byfield écrivait, dans un article que nous avions traduit ici-même (Ce qui caractérise les utilisateurs de logiciels libres) : « La communauté du Libre peut se targuer d’être une méritocratie où le statut est le résultat d’accomplissements et de contributions ».

Deux ans plus tard, le même nous propose de sonder plus avant la véracité d’une telle assertion, qui ne va finalement peut-être pas de soi et relève parfois plus du mythe savamment auto-entretenu.

Et de poser en guise de conclusion quelques pertinentes questions qui si elles trouvaient réponse participeraient effectivement à combler l’écart constaté entre la théorie et la pratique.

Nos propres discours n’en auraient alors que plus de consistance et de maturité^[1].

Les projets open source et le mythe de la méritocratie

Open Source Projects and the Meritocracy Myth

Bruce Byfield – 2 décembre 2009 – Datamation
(Traduction Framalang : Olivier et Cheval boiteux)

« Ce n’est pas une démocratie, c’est une méritocratie. »

On trouve cette déclaration sur la page de gouvernance d’Ubuntu, mais les notes de version de Fedora présentent quelque chose de similaire, tout comme la page Why Debian for developers et partout où l’essence des projets libres et open source (NdT : FOSS) est débattue.

La méritocratie est un mythe, une de ces histoires que la communauté des logiciels libres et open source aime se conter. Par mythe je n’entends pas mensonge, mais cette méritocratie est une histoire que les développeurs se racontent à eux-mêmes pour les aider à se forger une identité commune.

En d’autres termes, l’idée que les logiciels libres et open source sont une méritocratie est aussi vraie que de dire que les États-Unis sont une terre d’opportunité, ou que les scientifiques sont objectifs. Pour les membres de la communauté des logiciels libres et open source cette idée est primordiale dans leur perception du système et leur perception d’eux-même, car ils ont foi en cette idée que le travail est récompensé par la reconnaissance de leurs pairs et l’attribution de plus de responsabilités

Afin de perdurer, il faut que le mythe renferme une part de vérité, et ainsi personne ne le remet en question. Des exceptions peuvent survenir, mais elles seront justifiées, voire niées.

Cependant, si les mythes de la communauté ne sont pas des mensonges, ils ne révèlent pas toute la vérité non plus. Ils sont souvent des versions simplifiées de situations bien plus complexes.

La méritocratie dans les logiciels libres et open source n’échappe, à mon avis, pas à ce constat. Selon le contexte, si vous contribuez dans un bon projet et faites les choses biens, l’aspect méritocratique des logiciels libres et open source s’ouvrira à vous, c’est souvent le cas.

Mais de là à dire que les communautés ne fonctionnent qu’au mérite, il y a un pas que je ne franchirai pas. Le mérite n’est qu’un facteur à prendre, parmi tant d’autres, le mérite seul ne vous accordera ni reconnaissance, ni responsabilités. Bien d’autres considérations, souvent ignorées, entrent en jeu.

Hypothèses contestables

En invoquant l’argument du mérite on tourne rapidement en rond, c’est l’un des problèmes d’une méritocratie. Une hiérarchie est déjà établie, oui, mais comment ? Au mérite. S’ils n’avaient pas de mérite, ils n’auraient pas leur place.

Pas besoin de chercher bien loin pour voir que seul le mérite ne compte pas dans la hiérarchie des logiciels libres et open source. Les fondateurs du projet, en particulier, ont tendance à conserver leur influence, peu importe l’importance de leurs dernières contributions… si tant est qu’ils contribuent toujours au développement.

Par exemple, lorsque Ian Murdock fonda Progeny Linux Systems (entreprise pour laquelle j’ai travaillé) en 2000, il n’avait pas participé au projet Debian depuis quelques années. Et malgré cela, lorsque l’entreprise s’intéressa à Debian, son statut n’avait pas bougé. Tout portait à croire qu’il n’allait pas s’impliquer personnellement dans le projet et pourtant, s’il n’avait pas refusé la proposition, on lui aurait malgré tout attribué le titre de Debian Maintainer sans passer par le processus habituel.

Plus récemment, Mark Shuttleworth est devenu dictateur bienveillant à vie pour Ubuntu et Canonical, non pas à cause de ses contributions aux logiciels libres, mais parce qu’il disposait de l’énergie et de l’argent pour se propulser à ce rang. Sa position au sein d’Ubuntu ou de Canonical n’est pas remise en cause, mais toujours est-il qu’elle ne doit rien au mérite (au sens où l’entend la communauté), mais plutôt à son influence.

Et les leaders ne sont pas les seuls à gagner de l’influence pour des raisons autres que leur mérite. Dans les projets où certains contributeurs sont rémunérés et d’autres bénévoles, les contributeurs rémunérés ont presque toujours plus d’influence que les bénévoles. Dans certains cas, comme sur le projet OpenOffice.org, les contributeurs salariés peuvent presque entièrement éclipser les bénévoles.

D’autres projets, comme Fedora, repartissent l’influence plus équitablement, mais les contributeurs payés occupent souvent des postes à responsabilité. Par exemple, des dix membres du comité d’administration de Fedora, sept sont des salariés de Red Hat. Idem pour openSUSE où trois des cinq membres du comité sont des employés de Novell, le principal sponsor du projet, et un autre est consultant spécialisé dans les produits Novell. Et la situation est similaire dans bon nombre d’autres projets.

Alors oui, vous allez me dire que les membres payés ont plus de temps à accorder à ces responsabilités. C’est juste, mais ce n’est pas le sujet. Le fait est que les membres payés occupent statistiquement plus de postes à responsabilité que les bénévoles. Et c’est toute le postulat de départ qui est remis en cause, on constate alors que votre statut dans le projet n’est pas directement déterminé par votre mérite.

D’autres moyens de se faire remarquer

La méritocratie semble être le système parfait en théorie. Mais le fait est que la théorie est rarement mise en pratique. Avant de le reconnaître, encore faut-il déjà définir ce qu’est le mérite, la communauté des logiciels libres et open source ne fait pas exception.

Bâtie sur le code, la communauté des logiciels libres et open source valorise principalement la capacité à coder, bien que les plus gros projets soient beaucoup plus variés : tests, rédaction de la documentation, traduction, graphisme et support technique. De nombreux projets, comme Fedora et Drupal, évoluent et tentent de gommer cet a priori, mais cela demeure vrai pour la plupart des projets. Ainsi, les noms connus dans les projets ou les personnes qui font des présentations lors des conférences sont majoritairement des développeurs.

Cet a priori est cependant justifié. Après tout, sans le code, le projet de logiciel libre ou open source n’existerait pas. Et pourtant, le succès du projet dépend autant des autres contributions que du code lui-même.

Et comme le fait remarquer Kirrily Robert, blogueur chez Skud, même si certaines contributions sont moins estimées que d’autres, ça n’est pas une raison de les occulter complètement.

Par exemple, la personne la mieux placée pour écrire la documentation pourrait bien être le chef du projet, mais peut-être alors a-t-il mieux à faire que de rédiger la documentation. Il vaut peut-être mieux qu’une autre personne, même moins douée, rédige la documentation. Dans ce cas, celui qui écrit la documentation devrait être remercié, non seulement pour son travail, mais aussi parce qu’il libère l’emploi du temps du chef du projet. Et pourtant ceci est rarement reconnu dans les projets de logiciels libres ou open source.

L’idée que le mérite soit remarqué, reconnu et recompensé est rassurante dans notre culture industrielle moderne. J’aurai même tendance à penser que c’est encore plus rassurant dans le cercle des logiciels libres et open source, dont de nombreux membres admettent être introvertis, voire même se diagnostiquent eux-mêmes comme étant victime du syndrome d’Asperger.

Mais le mérite est-il toujours reconnu dans les logiciels libres et open source ? Voici ce que Noirin Shirley écrit à propos des obstacles à franchir par les femmes pour participer à cet univers :

Souvent, les valeurs reconnues dans une méritocratie deviennent rapidement le couple mérite/confiance en soi et obstination, dans le meilleur des cas. « Le travail bien fait ne vous apporte pas d’influence. Non, pour gagner de l’influence il faut faire du bon travail et bien s’en vanter, ou au minimum le rappeler à tout le monde régulièrement. » Les femmes échouent à cette étape là.

Shirley suggère ici qu’il faut non seulement être bon et régulier, mais il faut aussi savoir se rendre visible sur les forums, chats et listes de discussion, ainsi qu’aux conférences. Puisque les femmes sont apparemment conditionnées culturellement pour ne pas se mettre en avant, elles sont nombreuses à ne pas être à leur avantage dans un projet de logiciel libre ou open source (idem pour les hommes manquant de confiance en eux). Si elles ne peuvent ou ne souhaitent pas s’auto-promouvoir un minimum, leurs idées peuvent passer inaperçues, être sous-estimées ou carrément écartées.

À l’inverse, selon la même logique, certains gagnent en autorité plus parce qu’ils sont sociables ou opiniâtres que pour ce qu’ils réalisent concrètement (j’ai quelques exemples en tête, mais je ne veux pas faire d’attaque personnelle).

Tout comme la démagogie peut pervertir la démocratie, l’auto-promotion peut pervertir la méritocratie. Si un projet n’y prend pas garde, il se retrouvera bien vite à accepter des contributions, non pas sur la base de leur qualité, mais à cause de la visibilité et de l’insistance de celui qui les propose.

L’attraction sociale et comment s’y soustraire

Dans Le mythe de la méritocratie, Stephen J. McNamee et Robert K. Miller, Jr. avancent que la méritocratie aux États-Unis est influencée par ce qu’ils nomment l’attraction sociale. Ce sont des facteurs comme l’origine sociale ou l’éducation qui peuvent modifier positivement ou négativement la perception qu’ont les autres de nos contributions.

D’après moi, l’attraction sociale touche aussi la communauté des logiciels libres et open source, pas simplement parce qu’elle fait partie de notre société industrielle moderne, mais pour des facteurs qui lui sont propres. Reconnaître son existence n’est pas forcément facile, mais ça n’est pas pour autant une remise en cause de la méritocratie dans les logiciels libres et open source. L’importance du travail réalisé par les contributeurs n’en est pas non plus amoindrie.

Au contraire, reconnaître l’existence de l’attraction sociale peut être un premier pas pour améliorer la méritocratie dans le monde des logiciels libres et open source.

Kirrily Robert émet une idée intéressante. À l’instar des auditions anonymes où les musiciennes sont plus facilement choisies lorsque le sexe de la personne qui postule n’est pas connu, Robert propose que les soumissions soient également anonymes afin que leur évaluation ne soit pas biaisée. Si l’augmentation des contributions féminines lui tient à cœur, ces soumissions anonymes pourraient aussi garantir que seul le mérite entre en ligne de compte pour chaque contribution.

Mais ce n’est là qu’une proposition. Si vous voulez que la communauté des logiciels libres et open source devienne véritablement méritocratique, alors elle doit avoir le courage se poser quelques bonnes questions.

Pour commencer, par quel autre moyen peut-on réduire l’importance de l’auto-promotion ? Comment peut-on s’assurer que les employés et les bénévoles soient réellement au même niveau ? Peut-on redéfinir le mérite pour qu’il ne reflète pas uniquement ce qui est lié au code, mais au succès global du projet ?

Répondre à ces questions n’affaiblira pas le principe du mérite. Au contraire, ce principe de base de la communauté devrait en ressortir renforcé, et mieux utilisé. Et c’est, sans aucun doute, ce que souhaite tout supporter des logiciels libres et open source.

Dis papa chéri , pourquoi ne puis-je dessiner dans ce musée ? Parce que le « copyright » ma fille ! Oui, mais c’est quoi le « copyright », papa ? Euh… c’est une chose de grandes personnes, tu ne peux pas comprendre…

Fin du dialogue fictif entre un père et sa fille. Mais ce qui n’a rien de fictif c’est la situation étrange et pénétrante qui verrait un enfant interdit de prendre son crayon et son carnet pour le simple plaisir d’étudier et garder en mémoire ce qu’il a sous les yeux^[1].

Dieu soit loué, ce n’est pas le cas dans la majorité des musées et cela semble ne concerner que les expositions temporaires et non permanentes.

Il n’empêche que cela existe et en dit déjà long sur les dommages collatéraux désastreux de ces contrats juridiques qui, à trop vouloir se protéger, en arrivent à censurer un acte aussi inoffensif que celui-là.

Remarque : Ce n’est pas la première fois que le Framablog évoque Nina Paley (cf Libération du film d’animation Sita Sings the Blues et The Copyright Song).

Crayonner c’est copier. Copier c’est voler. Bientôt : l’interdiction de respirer

Sketching is copying; copying is stealing. Coming soon: no breathing

Karl Fogel – 29 octobre 2009 – QuestionCopyright.org
(Traduction Framalang : Julien)

Ce n’est certainement pas une nouveauté pour les étudiants des Beaux-Arts, mais pour le reste d’entre nous c’est toujours étonnant de constater que des établissements culturels comme les musées marchent dans le mythe du « copier c’est voler » en interdisant les croquis.

Dans certains cas, par exemple lors d’expositions temporaires, les restrictions concernant la copie sont imposées par l’institution qui prête l’œuvre. Il serait alors intéressant de savoir combien de fois le prêteur impose ces restrictions sur des œuvres qui ne sont pas sous copyright, ou qui autrement ne seraient pas restreintes.

Nina Paley a recueilli quelques exemples à la volée. Vous en connaissez d’autres ?

Le Philadelphia Museum of Art

« Tous les croquis dans les galeries d’exposition ou des œuvres prêtées sont interdits »

D’après la formulation, ceci s’applique à toute oeuvre en prêt, qu’elle soit dans le domaine public ou non. Quelqu’un a lancé une pétition pour obtenir que cette restriction soit levée, mais cela ne semble pas avoir abouti.

Le Musée Royal de l’Ontario : « Il est parfois interdit de dessiner à l’occasion de certaines expositions temporaires en raison d’ententes contractuelles avec les institutions ou les personnes qui nous prêtent des œuvres. ».

Ce serait bien s’ils affichaient ces accords sur le mur, à côté des autres informations qui concernent l’œuvre (et si les prêteurs ne souhaitent pas voir cela affiché peut-être devraient-ils se demander pourquoi).

Le Morris Museum of Art

« Exécuter des croquis des œuvres exposées dans les galeries permanentes du musées à des fins éducatives est autorisé. Faire des croquis ou dessiner à l’intérieur du Morris Museum of Art à des fins de revente ou de reproduction est strictement interdit. … Des restrictions supplémentaires peuvent s’appliquer sur le crayonnage de peintures et d’objets prêtés par d’autres musées. Veuillez vérifier auprès d’un représentant du musée avant de faire des croquis dans les galeries. Il vous sera demandé de signer un formulaire d’autorisation de dessiner et de vous conformer aux règles du musée. »

Par où commencer ? La revente ou la reproduction sont strictement interdites ? On se demande comment les conservateurs du Morris Museum ont reçu leur éducation artistique. Ont-ils réussi à visiter personnellement chaque musée où était exposée une œuvre qu’ils souhaitaient voir ? Et un formulaire « d’autorisation de dessiner » ! L’adjectif « orwellien » est galvaudé, mais parfois c’est le seul mot qui convient. Soyez heureux d’avoir déjà signé votre formulaire d’autorisation de penser.

La National Gallery of Victoria (Australie)

« Les croquis et la prise de notes sont permis dans les zones d’expositions temporaires et de collections permanentes de la National Gallery of Victoria. Cette politique est soumise à l’appréciation des prêteurs individuels ou institutionnels, à condition que les conditions suivantes soient respectées : … Il est important de noter que certains prêteurs individuels ou institutionnels peuvent interdire le crayonnage et la prise de notes dans le cadre des conditions exposées dans les accords de prêt et/ou des contrats d’exposition selon les termes d’une indemnité gouvernementale ou police d’assurance. Dans ces circonstances, le commissaire de l’exposition donnera des instructions spécifiques au personnel de sécurité. Nous demandons à tous les visiteurs de comprendre que dans ces circonstances la National Gallery of Victoria n’a pas d’autre choix que de se conformer aux conditions fixée par les prêteurs. »

De toutes les conditions exposées ici, celle-ci semble la plus raisonnable. Le texte complet montre qu’ils sont en priorité soucieux du public, et quand il s’agit de restrictions imposées par les prêteurs, la galerie admet plus ou moins ouvertement qu’elle regrette que ces restrictions soient toujours nécessaires. Cette politique résulte apparemment en partie d’une protestation du Free Pencil Movement, félicitations à eux pour cette action couronnée de succès. Encore une fois, j’espère que la National Gallery affichera les termes exacts des restrictions demandées par les prêteurs juste à côté des œuvres concernées.

La mentalité du « Copier c’est voler » peut créer des situations terriblement étranges. Ce post de 2005 sur BoingBoing rapporte l’histoire d’une élève de CE1 qui dessinait au North Carolina Museum of Art : « Un gardien du musée a dit aux parents de Julia que faire des croquis était interdit parce que les grands chefs d’oeuvres sont protégés par le copyright, un concept que la jeune Julia ne comprenait pas avant que sa mère ne lui explique le terme ».

Ne t’inquiète pas Julia, tu n’es pas la seule.