Lorsque la distribution GNU/Linux Ubuntu est sortie en 2004, son père fondateur Mark Shuttleworth a signalé lui-même le premier « bug » : Microsoft détient la majorité du marché (Microsoft has a majority market share).

Il s’agissait symboliquement, et avec humour, de montrer le cap à suivre en désignant le principal concurrent.

Aujourd’hui la donne a changé et Shuttleworth a décidé hier de marquer ce bug comme résolu (fix released), quand bien même cela ne signifie pas, loin de là, qu’Ubuntu ait gagné comme il s’en explique ci-dessous.

Remarque : Nous en profitons pour signaler que Framasoft sera présent en masse à l’Ubuntu Party de Paris, avec stand et 3 mini-conférences le samedi 1er juin.

Bug #1 : Microsoft détient la majorité du marché

Bug #1 (liberation) : Microsoft has a majority market share

Mark Shuttleworth – 30 mai 2013 – Launchpad Ubuntu
(Traduction : Penguin, Mowee, Cryptie, quack1, @zessx, Asta, misc, MFolschette, Samusz + anonymes)

Aujourd’hui, l’utilisation de l’informatique dans la vie de tous les jours est beaucoup plus importante qu’elle ne l’était en 2004 : les téléphones, tablettes et autres appareils nomades sont devenus une part non négligeable de notre vie numérique. D’un point de vue compétitif, cet édifiant marché est une bénédiction pour la concurrence. Avec notamment iOS et Android, qui tous deux représentent une part significative du marché (Voir Windows en dessous de iOS et Android réunis avec ce graphique.

Android n’est peut-être pas mon premier choix de (noyau) Linux, ni le vôtre, mais c’est sans aucun doute une plateforme open source qui offre des avantages pratiques et économiques aux utilisateurs, comme à l’industrie. Ainsi, nous avons d’un côté de la concurrence et de l’autre une bonne représentation de l‘open source dans l’informatique personnelle.

Même si nous n’avons joué qu’un petit rôle dans ce changement, je pense qu’il est important pour nous de reconnaître qu’il a eu lieu. Du point de vue d’Ubuntu, le bug est maintenant clos.

Évidemment, ce bug a aussi un aspect social. Pour beaucoup, il a fait office de déclaration d’intention. Mais il est préférable pour nous de nous concentrer sur l’excellence de notre propre travail, plutôt que considérer notre impact sur le produit des autres. Depuis les (nombreuses) années que ce bug est référencé, nous avons trouvé comment être excellents dans le cloud, et j’espère que nous trouverons aussi bientôt comment l’être sur les postes de travail des développeurs, et peut-être même sur toute la quantité d’appareils que les utilisateurs réguliers peuvent utiliser. Je préférerais désormais que nous trouvions un cri de ralliement qui célébrerait ces idées et leur management.

Il est important de remarquer que de nos jours, si vous êtes dans le domaine de l’informatique dématérialisée (NdT : cloud computing), l’équipe de service d’infrastructure (NdT : IaaS) de Microsoft est très compétente et travaille dur pour que Linux soit parfaitement supporté par Azure, ce qui rend le travail avec eux très plaisant. Si l’évolution du marché a peut-être joué un rôle dans tout ça, les circonstances ont changé et les institutions se sont adaptées. Nous nous devons donc de le faire aussi.

Cela dit, il est bon de prendre du recul et de visualiser combien tout cela a changé depuis 2004, et à quelle vitesse ! Avec Ubuntu, notre but est de proposer à tous une expérience utilisateur formidable, que ce soit pour les développeurs, pour la production en entreprise ou tout simplement l’utilisateur final. Et tout cela avec un large support de matériel. Nous évoluons dans un environnement dynamique qui ne cesse de changer d’année en année. C’est donc pour cela que nous devons sans arrêt nous remettre en question, que ce soit au niveau de notre façon de faire, nos pratiques, les outils que nous utilisons ainsi que les relations que nous entretenons en interne et en externe. Corriger ce problème n’en est qu’un tout petit exemple.

Une nouvelle traduction de Cory Doctorow

L’industrie américaine du divertissement au Congrès : autorisez-nous légalement à déployer des rootkits, des mouchards, des logiciels rançonneurs et des chevaux de Troie pour attaquer les pirates !

US entertainment industry to Congress: make it legal for us to deploy rootkits, spyware, ransomware and trojans to attack pirates!

Cory Doctorow – 26 mai 2013 – BoingBoing.net
(Traduction : Mowee, ehsavoie, audionuma, Asta)

La « Commission sur le Vol de la Propriété Intellectuelle Américaine », qui porte bien comiquement son nom, a finalement rendu son rapport de 84 pages complètement folles. Mais dans toute cette folie, il y a une part qui l’est encore plus que le reste : une proposition pour légaliser l’usage des logiciels malveillants afin de punir les personnes soupçonnées de copies illégales. Le rapport propose en effet que ce logiciel soit chargé sur les ordinateurs et qu’il détermine si vous êtes un pirate ou non. S’il soupçonne que c’est le cas, il verrouillera votre ordinateur et prendra toutes vos données en otage jusqu’à ce que vous appeliez la police pour confesser vos crimes. C’est ce mécanisme qu’utilisent les escrocs lorsqu’ils déploient des logiciels rançonneurs (NdT : ransomware).

Voilà une preuve supplémentaire que les stratégies en terme de réseau des défenseurs du copyright sont les mêmes que celles utilisées par les dictateurs et les criminels. En 2011, la MPAA (Motion Picture Association of America) a dit au Congrès qu’ils souhaitaient l’adoption de la loi SOPA (Stop Online Piracy Act). Selon eux, cela ne pouvait que fonctionner vu que la même tactique est utilisée par les gouvernements en « Chine, Iran, Émirats Arabes Unis, Arménie, Éthiopie, Arabie Saoudite, Yémen, Bahreïn, Birmanie, Syrie, Turkménistan, Ouzbékistan et Vietnam. » Ils exigent désormais du Congrès que soit légalisé un outil d’extorsion inventé par le crime organisé.

De plus, un logiciel peut être écrit de manière à ce que seuls des utilisateurs autorisés puissent ouvrir des fichiers contenant des informations intéressantes. Si une personne non autorisée accède à l’information, un ensemble d’actions peuvent alors être mises en œuvre. Par exemple, le fichier pourrait être rendu inaccessible et l’ordinateur de la personne non autorisée verrouillé, avec des instructions indiquant comment prendre contact avec les autorités pour obtenir le mot de passe permettant le déverrouillage du compte. Ces mesures ne violent pas les lois existantes sur l’usage d’Internet, elles servent cependant à atténuer les attaques et à stabiliser un cyber-incident, pour fournir à la fois du temps et des preuves, afin que les autorités puissent être impliquées.

De mieux en mieux :

Alors que la loi américaine interdit actuellement ces pratiques, il y a de plus en plus de demandes pour la création d’un environnement légal de défense des systèmes d’informations beaucoup plus permissif. Cela permettrait aux entreprises de non seulement stabiliser la situation, mais aussi de prendre des mesures radicales, comme retrouver par elles-mêmes les informations volées pouvant aller jusqu’à altérer voire détruire ces dernières dans un réseau dans lequel elles n’ont pourtant aucun droit. Certaines mesures envisagées vont encore plus loin : photographier le hacker avec sa propre webcam, infecter son réseau en y implantant un logiciel malveillant ou même désactiver voire détériorer physiquement le matériel utilisé pour commettre les infractions (comme son ordinateur).

Source : La Commission sur le Vol de la Propriété Intellectuelle Américaine recommande les malwares !

Un coup on souffle le chaud, un coup on souffle le froid, Google est bipolaire vis-à-vis du logiciel libre, des formats ouverts et du respect de la vie privée.

C’est d’autant plus flagrant lorsque pour critiquer Google on s’en réfère à ses propres déclarations.

Et l’on se retrouve, sans crier gare, du jour au lendemain, avec une messagerie instantanée potentiellement amputée de ses qualités précédentes…

Google abandonne les standards ouverts pour la messagerie instantanée

Google Abandons Open Standards for Instant Messaging

Parker Higgins – 22 mai 2013 – EFF.org
(Traduction : Penguin, TheCamel, audionuma, Asta, KoS)

Au milieu du tourbillon médiatique qui entoure sa conférence I/O annuelle, Google a lâché quelques informations malheureuses sur ses plans concernant sa messagerie instantanée. À plusieurs endroits sur le web, la société remplace son actuelle plateforme « Talk » par une nouvelle dénommée « Hangouts » qui réduit drastiquement le support du protocole ouvert de messagerie instantanée connu sous le nom de XMPP (ou Jabber de manière informelle) et supprime également l’option de désactivation de l’archivage de toutes les communications en messagerie instantanée. Ces changements représentent une bascule des protocoles ouverts vers des protocoles fermés ainsi qu’un recul flagrant pour de nombreux utilisateurs.

Une régression pour l’interopérabilité

Auparavant, le support complet de XMPP par Google signifiait que les utilisateurs pouvaient communiquer avec des interlocuteurs utilisant d’autres services de messagerie instantanée, voire hébergeant leur propre serveur de messagerie instantanée. Ce type de décentralisation est une bonne chose : il diminue la dépendance à un service particulier, ce qui en contrepartie permet aux différents services de se différencier sur des aspects importants comme la qualité, la fiabilité ou le respect de la vie privée.

Certains utilisateurs, par exemple, ne souhaitent peut-être pas fournir à Google des informations sur le contenu de leurs messages, quand et d’où ils se sont connectés, ou bien avec qui ils ont l’habitude de clavarder. Les informations concernant les personnes avec qui les utilisateurs communiquent peuvent être sensibles ; souvenez vous, ces données étaient au cœur du retour de bâton qui frappa Buzz, un ancien réseau social, lorsqu’il décida de les rendre publiques par défaut.

La possibilité de fédérer différents services permet aux utilisateurs de faire leur choix eux-même. Voici une explication issue de la propre documentation de Google concernant la plateforme « Talk », dans une partie intitulée « Communications ouvertes » :

Le choix du service vous permet de choisir votre fournisseur en vous basant sur des facteurs plus importants tels que les fonctionalités, la qualité de service et le prix, tout en conservant la capacité de communiquer avec qui vous voulez.

Malheureusement, ce n’est pas le cas de nombreux services IM (messagerie instantanée) et VOIP (voix sur IP) aujourd’hui. Si les personnes avec qui vous souhaitez communiquer sont toutes connectées à des services IM/VOIP différents, vous devez créer un compte chez chacun d’entre eux pour pouvoir communiquer.

Le nouveau protocole Hangouts soulève précisément les questions que Google souligne ci-dessus. Les utilisateurs n’ont d’autre choix que d’utiliser les serveurs de Google ou se déconnecter des gens qui les utilisent. Les utilisateurs de Google ne sont pas informés du changement : leurs copains qui utilisent jabber.org, member.fsf.org, ou n’importe quel autre service qui utilise XMPP n’apparaîtront tout simplement plus dans la liste des contacts en ligne.

Ces changements sont le résultat de l’abandon par Google d’un sous-ensemble particulier du standard XMPP, le server-to-server federation. Mais pour le moment, Google continue à utiliser la partie connexion client-serveur, ce qui signifie que dès lors que vous êtes connecté avec un compte Google, vous pouvez utiliser n’importe quelle application utilisant ce protocole.

C’est important pour plusieurs raisons. Une des plus importantes est qu’aucun client officiel Google ne propose le chiffrement des communications Off-the-Record (OTR), qui devient un composant critique pour la sécurité des communications en ligne. Si les deux participants dans un échange sur messagerie instantanée utilisent chacun un chiffrage OTR, ils disposent d’une liaison sécurisée d’un bout à l’autre, ce qui signifie que personne, y compris leur fournisseur de service, ne peut lire le contenu de leurs messages.

Des changements dans l’historique

Malheureusement, un autre changement de la part de Google pourrait forcer les utilisateurs à faire un choix difficile, à savoir utiliser ou non ces clients externes tels que Pidgin, Adium, Gibberbot ou Chatsecure pour discuter. Le dilemme vient en particulier de la manière dont Google a changé sa façon d’archiver les conversations et de les présenter à l’utilisateur.

Précédemment, les utilisateurs pouvaient désactiver l’« historique de conversation », ce qui empêchait la sauvegarde des messages instantanés sur leur compte Gmail. Avec les nouveaux paramètres, les utilisateurs qui ne veulent pas conserver une copie de leur conversation accessible via Gmail doivent désactiver l’« historique Hangout », et ce pour chaque contact^[1]. Le problème est que les utilisateurs peuvent seulement désactiver l’historique Hangout avec un compte Google Hangout officiel.

Donc tant pis pour les utilisateurs soucieux de leur vie privée qui veulent utiliser le chiffrement Off-the-Record et qui désirent garder leurs messages loin de leur compte Gmail. Et s’ils veulent continuer à discuter avec leurs amis sur Google chat, ils ne peuvent même pas le faire autre part.

Depuis la semaine dernière, Google demande aux utilisateurs de remplacer l’application Android Talk par Hangouts et de passer à Hangout au sein de Gmail dans Chrome. Soyez vigilants avant d’effectuer la mise à jour, soyez vigilants du coût pour la liberté de ces « améliorations ».

Que devrait faire Google ?

Dans son explication publique officielle de son abandon du support de XMPP, Google a expliqué que c’était une décision difficile, rendue nécessaire par des contraintes techniques. Mais même si le nouveau protocole obéit à de nouvelles contraintes techniques, cela n’empêche pas la compagnie de le rendre public et interopérable. Libérer les spécifications de Google Hangouts serait un bon premier pas. Fournir des client et des serveurs open source en serait un second. Il est clair que certaines fonctionnalités vidéo de Hangouts ont été implémentées dans un but spécifique à Google. Mais ce n’est pas une excuse pour nous emmener vers un monde où les seuls choix concrets sont des logiciels et des protocoles de chat propriétaires.

Une autre initiative simple à mettre en œuvre au bénéfice des utilisateurs aurait été d’incorporer le support de Off-the-Record dans le client Hangout officiel. Si de telles possibilités de confidentialité étaient proposées aux utilisateurs, cela atténuerait le fait d’offrir des options de protection de la vie privée seulement dans le logiciel propriétaire de Google.

Dans le document Google « Communications ouvertes » cité ci-dessus, l’entreprise explique en quoi c’est un véritable engagement d’ouvrir les canaux de communication :

La mission de Google est de rendre l’information mondiale universellement accessible et utile. Google Talk, qui permet aux utilisateurs de communiquer instantanément avec leurs amis, leur famille et leurs collègues via des appels vocaux et des messages instantanés, reflète notre conviction que les communications devraient être accessibles et utiles.

Nous sommes frustrés et déçus de voir Google reculer face à cette mission.

Crédit photo : Osde8info (Creative Commons By-Sa)

Début 2006, Cory Doctorow publiait une courte nouvelle de science-fiction qui à peine sept ans plus tard, avec l’explosion de l’impression 3D (et le climat ambiant de guerre contre la bidouille et le partage) prend malheureusement déjà des accents prémonitoires…

Crime d’impression

Printcrime

Cory Doctorow – janvier 2006 – Nature.com
(Traduction : Rigas Arvanitis, relecture aKa)

Copiez cette histoire

Les flics ont bousillé l’imprimante de papa quand j’avais huit ans. Je me souviens son odeur de pellicule fondue dans le micro-ondes et le regard d’intense concentration de papa quand il la remplissait de produit, ainsi que l’odeur de produit chaud qui en sortait.

Les flics sont rentrés les matraques à la main, l’un d’eux récitait l’ordre d’arrestation dans un haut-parleur. C’était un des clients de papa qui l’avait dénoncé. La iPolice payait en produits pharmaceutiques de haute qualité : des produits d’amélioration des performances, des suppléments de mémoire, des booster métaboliques. Le type de produits qui coûtent une fortune dans une pharmacie ; le type de produits que l’ont pouvait imprimer à la maison, si on n’avait pas peur de voir sa cuisine envahie soudain par des mecs gros et gras, les matraques à la main, cassant tout sur leur passage.

Ils ont aussi détruit le buffet de grand-mère, celui qu’elle avait ramené de la campagne. Ils ont aussi détruit notre petit réfrigérateur et le purificateur d’air sous la fenêtre. Mon oiseau a échappé à la mort en se cachant dans un coin de la cage quand l’un des flics gros et gras transformait la cage en un amas de fil de fer informes sous sa botte.

Papa, ce qu’il a souffert ! Quand ils ont fini, il donnait l’impression de s’être battu contre toute une équipe de rugby. Ils le traînèrent à la porte et laissèrent les journaleux le regarder de près avant de le pousser dans la voiture, tandis qu’un porte-parole disait au monde que l’organisation criminelle de papa était responsable de contrebande pour au moins 20 millions et que mon papa, parfait méchant désespéré, avait résisté pendant son arrestation.

J’ai tout vu sur mon téléphone. En regardant les restes du salon sur l’écran, je me suis demandé comment on pouvait imaginer, en voyant notre modeste petite maison, que c’était là la demeure d’un baron du crime organisé. Evidemment, ils emportèrent l’imprimante et la montrèrent comme un trophée aux journaleux.

La petite étagère où elle se trouvait auparavant paraissait comme un autel bien vide dans la cuisine. Quand je me suis rendu à la maison pour récupérer mon pauvre petit canari affolé, j’y ai posé un robot de cuisine qui avait été monté avec des pièces imprimées par notre imprimante, afin de ne pas attendre plus d’un mois avant d’avoir à imprimer de nouvelles pièces mobiles et des accessoires. A cette époque, je savais monter et démonter n’importe quel objet imprimé.

A mes 18 ans, ils ont relâché papa de prison. Je ne l’avais visité que trois fois : le jour de mes 10 ans, le jour de mes 50 ans et à la mort de maman. Cela faisait 2 ans que je ne l’avais pas vu et il était devenu l’ombre de lui-même. Il avait été handicapé suite à une bagarre en prison et jetait en permanence des coups d’œil derrière lui. J’étais pas fière quand le taxi nous a lâché devant la maison et j’essayais de garder mes distances à côté de ce squelette ruiné et boiteux qui montait les marches.

« Lanie, » dit-il en s’asseyant, « Tu es une fille intelligente, je le sais. Tu saurais pas, par hasard, où je peux me procurer une imprimante et un peu de produit ? »

Je serrais les poings si fort que mes ongles s’enfonçaient dans ma paume. Je fermais les yeux : « Tu as été 10 ans en prison, papa. 10 ans ! Tu ne vas pas risquer de rempiler en imprimant encore des robots et des produits pharmaceutiques, des portables et des chapeaux de mode ? »

Il sourit. « Je ne suis pas stupide, Lanie. J’ai appris la leçon. Aucun portable et aucun chapeau ne vaut la peine d’aller en prison. Je ne vais plus imprimer ces trucs, plus jamais. » Il avait une tasse de thé à la main qu’il sirotait comme si c’était un verre de whisky. Il ferma ses yeux et s’étendit sur la chaise.

« Viens là, Lanie, laisse moi te souffler à l’oreille. Laisse moi te dire ce que j’ai décidé pendant ces 10 ans passés derrière les barreaux. Viens écouter ton stupide papa. »

Je sentis un peu de honte pour l’avoir rabroué. Il avait l’air d’avoir perdu la boule, c’était clair. Dieu seul savait ce qu’on lui avait fait subir à la prison. « Oui, papa ? » dis-je en me penchant vers lui.

« Lanie, je vais imprimer des imprimantes. Des tas d’imprimantes. Une pour chacun. Ça oui, ça vaut la peine d’aller en prison. Ça vaut tout l’or du monde. »

C’est ce qui arrive à un développeur britannique.

Il s’en réjouit et nous avec 😉

Le gouvernement britannique me paye pour faire de l’open source toute la journée

The UK government pays me to write open source all day

Jake Benilov – 17 mai 2013 – QuickPeopleBlog
(Traduction : RyDroid, goofy, @zessx, Sylvain, MFolschette, Asta, Chuckman + anonymes)

Je suis développeur. Voici le graphique récapitulant mes contributions open source sur Github pour les 12 derniers mois (les carrés verts représentent les jours où j’ai fait des commits dans des dépôts open source) :

Bien que je fasse aussi de l’open source pendant mon temps libre, la plupart de ces points verts apparaissent pendant mes heures de travail au Government Digital Service (NdT. unité gouvernementale chargée de revoir le fonctionnement des services gouvernementaux en ligne), une équipe du Bureau du Cabinet britannique.

Je ne suis pas un cas isolé dans mon équipe. Si vous jetez un coup d’œil à la page Github du GDS, vous trouverez beaucoup de code. Mieux encore, notre travail ne se déroule pas seulement en marge des TIC gouvernementales : nous sommes responsables du site GOV.UK, la principale plateforme de publication du gouvernement britannique, et l’accès principal à toutes les opérations gouvernementales.

Un point où j’ai peut être exagéré : comme James Stewart (un des directeurs développement du GDS) le souligne, le GDS fait aujourd’hui du « code ouvert » plutôt que de « l’open source ». Cela signifie que le GDS rend les sources disponibles sous une licence de libre diffusion (LLD), mais ne soutient ou n’établit aucune communauté autour. Dans tous les cas, le « code ouvert » est génial pour de nombreuses raisons.

Équité envers le contribuable

Les sources gouvernementales devraient être ouvertes. Après tout, si le code a été écrit grâce aux impôts du contribuable, ce n’est que justice que le contribuable puisse l’avoir en retour. Fait intéressant, le critère n°15 du Digital by Default Service Standard (NdT. document explicitant les critères auxquels doivent répondre les services gouvernementaux en ligne) récemment publié devrait institutionnaliser cela et faire en sorte que tous les futurs projets du gouvernement britannique soient mandatés pour ouvrir leurs sources par défaut :

Rendez tout nouveau code source ouvert et réutilisable, et publiez-le sous les licences appropriées (ou fournissez une raison valable pour laquelle ce n’est pas possible pour certaines parties spécifiques du code source)

Équité envers la communauté de l’open source

Nous utilisons des langages et frameworks open source (la majorité de GOV.UK est écrite en Ruby et Scala), des serveurs web open source, nous gérons et configurons nos sources avec des outils open source (Git et Puppet), et nous déployons sur les systèmes d’exploitation open source (tournant sous Linux). Redistribuer n’est que justice.

Transparence

Disposer de mon code source GDS sur GitHub facilite ma vie de développeur au GDS. Si j’ai besoin d’intégrer, de réutiliser ou d’étendre un autre composant du GDS, j’ai juste à cliquer dans mon navigateur ou à cloner le dépôt.

La transparence bénéficie aussi à ceux en dehors du GDS. Besoin de connaître les règles pour calculer une pension d’État ? Regardez les sources. Vous avez trouvé un bug dans la page des jours fériés ? Vous pouvez soumettre une pull request pour le corriger.

Je connais des sociétés qui ont des programmes open source internes, et c’est certainement un pas dans la bonne direction, mais le fait de rendre presque tout disponible nous rapproche de l’idéal d’une propriété commune du code.

En bonus, puisque les bidouilles et les raccourcis sont visibles par tout le monde, il en résulte une diminution des bricolages hasardeux.

Réutilisation

Bien qu’une bonne partie du code que nous écrivons est spécifique à nos problématiques, une large part est générique, et pourrait facilement être adaptée à l’usage d’autres administrations centrales, régionales ou locales, ou dans le secteur privé. En fait, les gens commencent déjà à le faire. Vous voulez du bon code pour un front-end ? Le voici. Vous voulez un système de login unique de qualité gouvernementale ? Le voilà. Vous voulez construire vos propres réponses intelligentes ? Ne vous gênez pas.

Marketing

Le « code ouvert » est un bon argument marketing pour l’image de marque du GDS. Quand je dis à d’autres hackers que je fais de l’open source au travail, les sourcils se lèvent. J’ai entendu des gens extérieurs au GDS en parler en termes de « startup gouvernementale » ; il est évident que l’open source améliore l’image de la marque.

Pour le CV

Pour des raisons purement égoïstes, il est vraiment agréable d’avoir un portfolio de mon travail, un endroit où je peux apporter aux gens une preuve tangible de ma capacité (ou mon incapacité ?) à coder en Ruby.

J’aimerais que davantage d’employeurs fassent cela (et pas seulement le secteur public). Si le vôtre ne le fait pas, peut-être que les raisons évoquées ci-dessus pourront aider à le convaincre de changer d’avis ?

« L‘open source n’est pas une zone de guerre. Les hommes ne sont pas tous des connards. » Tel est le titre d’un article publié par des femmes de la communauté Perl.

Un constat sensiblement différent du billet Sexisme chez les geeks : Pourquoi notre communauté est malade, et comment y remédier de MarLard, qui fit couler beaucoup d’encre récemment dans la blogosphère francophone.

L’open source n’est pas une zone de guerre. Les hommes ne sont pas tous des connards.

Open Source Is Not A Warzone. Not Every Man Is A Dick.

Collectif féminin de la communauté Perl – Mai 2013 – Site personnel de Su-Shee
(Traduction : audionuma, Sphinx, tcit, Ag3m, Garburst, audionuma, goofy, MFolschette, Asta, Hype, KoS + anonymes)

Nous sommes des femmes techniciennes. Nous faisons de l‘open source. Nous faisons partie de la communauté open source.

Nous assistons à des conférences techniques, participons à des groupes d’utilisateurs et à des hackatons avec nos collègues développeurs masculins.

Et nous aimons ça.

Nous avons le sentiment que l’écrasante majorité des hommes à qui nous avons affaire sont des personnes intelligentes, certains sont même des mecs sympas qu’on aime bien.

Oui, nous avons rencontré des connards dans nos vie. Oui, nous avons subi des agressions, parfois même en public et au grand jour. Oui, nous nous sommes fait taper dessus régulièrement et sans finesse, nous avons été dégoutées et dérangées et parfois nous avons frôlé la panique. Certaines d’entre nous ont connu la violence. On nous a tripoté le cul et les nichons, on s’est fait reluquer, siffler et on a eu droit au crétin bourré qui se met en travers. Oui, certaines d’entre nous ont atteint le proverbial plafond de verre durant leurs carrières.

C’est le côté le plus négatif de nos vies et en effet, nous jugeons les réunions et les rencontres selon le degré de bien-être, le sentiment de sécurité et le niveau de connerie affichée ou dissimulée qu’on y ressent.

Mais ce n’est qu’UN aspect du fait d’être une femme et nous ne voulons pas laisser cet aspect dominer notre manière de vivre et de nous comporter dans les communautés techniques de notre choix.

Nous avons le sentiment que la tendance à développer des codes de conduite, des règlements et des règles spécifiquement pour les conférences techniques et d’autres rassemblements liés à la technologie dépasse de beaucoup la réalité que nous avons connue jusqu’à présent.

Nous ne soutenons pas la généralisation de la culpabilité diffuse à un genre tout entier et nous ne voulons pas être suspicieuses envers chacun de nos collègues participant à une communauté.

Nous considérons également les rassemblements de techniciens comme des événements professionnels. Nous attendons donc de chaque participant qu’il se comporte selon les règles que les communautés open source considèrent comme « professionnelles ». Les présentations grossières que l’on a vues lors d’événements récents ont provoqué un scandale suffisant pour faire le point sur cette question.

Nous souhaitons également utiliser un vocabulaire approprié : une « agression » est un acte de violence, un acte agressif pour prendre l’ascendant sur une personne. Nous ne ressentons pas une médiocre tentative de drague comme une agression. Un regard indiscret dans notre décolleté n’est pas une agression. Si quelqu’un nous touche sans le vouloir, ce n’est pas une agression. Le « bisou » français typique est quelque chose de culturel et pas une agression. Une accolade (hug) peut être un acte absolument amical et pas une agression, même s’il peut ne pas être bienvenu.

Nous aimons aussi penser logiquement, et en tant que femmes techniciennes, nous pouvons même nous défendre avec des statistiques : considérant que nous représentons à peu près 1 % à 20 % (ce qui est déjà un pourcentage de femmes extrêmement haut) de n’importe quelle communauté, rencontrer seulement 2 connards dans une conférence de 500 personnes est une chance FANTASTIQUE, nulle part ailleurs dans nos vies quotidiennes la probabilité n’est aussi faible.

Débattons également des problèmes légaux : comment un code de conduite pourrait-il aider contre les agressions, les viols ou les passages à tabac ? Tout ça est DE TOUTE FAÇON illégal à peu près partout dans le monde. Il existe DÉJÀ un code de conduite : la loi, aussi partiale et faible soit-elle.

Regardons les choses en face : aucun connard ne va être stoppé par un code de conduite impuissant à interdire les comportements inopportuns, c’est bien pour cela que ce sont des connards. Cependant, une grande proportion d’hommes se feront discrets, par culpabilité, parce que ce sont ceux qui se remettent en question, de manière réfléchie, par rapport à leur propre connerie.

Nous préférons que le bon goût, le professionnalisme et les comportements se développent grâce à une culture de bon goût, de plaisanteries, d’idées de fond et de standards, et non par l’écriture d’une longue liste de choses déplaisantes et interdites. Nous préférons agir contre le comportement des connards lorsqu’il se manifeste.

Mais nous considérons aussi les rassemblements open source comme des événements sociaux et nous allons le dire en public : lors d’un événement social il peut y avoir de la *hum* sexualité, de l’amitié, des taquineries ou du flirt. Cela fait partie du fait que les humains vivent ensemble. Nous considérons la libération sexuelle des années 70 comme un progrès qui nous a donné, à nous les femmes, de nouvelles libertés pour vivre comme nous le voulons. Nous n’y renoncerons pas.

Nous nous voyons dans la tradition du féminisme responsabilisant, de l’émancipation en ayant appris à dire non, en étant capables de nous défendre nous-mêmes et nous ne voulons pas être les victimes indirectes d’actes de surprotection « globaux » qui au fond condamnent chaque comportement social entre les hommes et les femmes.

Nous sommes des « femmes du Perl » et à vrai dire notre communauté nous plaît plutôt bien.

(Peut-être êtes-vous membre d’une communauté complètement différente et, néanmoins d’accord avec nous : faites-le moi savoir :)).

Tout comme le sont d’autres femmes, qui ne seront pas citées ici.

Bien à vous – Su-Shee (Susanne Schmidt), castaway (Jess Robinson), gshank (Gerda Shank), ether (Karen Etheridge), druthb (D Ruth Bavousett), auggy (Augustina Ragwitz), Lady Aleena

L’un des auteurs que l’on traduit le plus sur le Framablog, Glyn Moody, choisit ici de mettre les pieds dans le libre plat.

Et si on n’utilisait plus les licences libres, qui ne sont pas sans poser problèmes, en plaçant directement le code dans le domaine public ?

Les avantages pourraient finalement dépasser les inconvénients !

Remarque : Sur le même thème on pourra également lire (ou acheter) notre framabook Un monde sans copyright… et sans monopole. Sans oublier notre auteur Pouhiou qui place directement ses romans dans le domaine public et s’en explique ici dans un fort intéressant dialogue avec Lionel Maurel aka Calimaq.

Pourquoi il est temps d’arrêter d’utiliser les licences libres

Why it’s time to stop using open source licences by Glyn Moody

Glyn Moody – 13 février 2013 – The H Open
(Traduction : Tr4sK, aKa, Sphinx, Isdf, Penguin, ProgVal, lamessen, Shanx, Amargein, ronane, MFolschette, Isser)

Les logiciels libres reposent sur un paradoxe. Afin que les utilisateurs puissent être libres, les licences libres utilisent quelque chose remettant en cause la liberté : le copyright. Ce dernier est un monopole intellectuel se basant sur la restriction de la liberté des gens à partager, la liberté est donc restreinte et non pas étendue. Quand Richard Stallman, en 1985, a créé la GNU Emacs General Public License, cela représentait un bidouillage brillant, maintenant il est peut-être temps de passer à autre chose.

Nous y sommes déjà et des éléments le montrent. Il y a 18 mois, les gens ont commencé à remarquer le déclin des licences copyleft vers des licences plus permissives comme la licence Apache ou BSD. Plus récemment, la croissance de GitHub a attiré l’attention, montrant également que de plus en plus de gens n’utilisent plus de licences sur GitHub (ce qui peut s’avérer problématique d’une certaine manière).

Je ne pense pas que le déclin des licences copyleft soit la preuve d’un échec, bien au contraire ! Je l’écrivais dans mon édito précédent, le logiciel libre a au fond gagné, prenant le pouvoir dans la plupart des secteurs clés de l’informatique. De la même manière, le passage à des licences permissives n’a été rendu possible que grâce au succès du copyleft : les idées participant à la création collaborative et à la contribution à un projet que l’on utilise sont maintenant généralisées. Il n’y a donc plus besoin de licences copyleft « fortes » pour faire respecter ces valeurs, elles font désormais partie de l’ADN des codeurs. Ian Skerrett le déclarait ainsi en 2011 :

« On n’a plus besoin de s’assurer que les développeurs ou les entreprises soient honnêtes. Ils contribuent aux projets open source parce que cela les aide dans leur travail. S’il fallait s’assurer que les développeurs sont honnêtes, pourquoi y aurait-il autant de projets Apache réussis ? Prenons l’exemple du projet Eclipse qui utilise un copyleft faible. Je ne connais que très peu de contributions ayant été intégrées à Eclipse parce que le développeur avait été forcé de contribuer à cause des obligations de licence. Les gens contribuent aux projets qu’ils utilisent parce qu’ils ont saisi le bénéfice qu’ils pouvaient recevoir grâce à leur contribution. »

C’est aussi pourquoi nous ne devons pas nous n’inquiéter du cloud computing — parfois présentée comme la tueuses des licences libres — puisqu’il n’y a pas de distribution obligeant à publier les éventuelles modifications du code. Mais une fois de plus, nous n’avons pas besoin de cette obligation : si une entreprise d’informatique de cloud computing veut pleinement tirer les bénéfices du logiciel libre, elle y contribuera de toute façon. Si elle ne le fait pas, elle n’a rien compris.

Quelle licence devons-nous donc adopter si on n’utilise pas une licence copyleft ? Apache ? BSD ? Pourquoi pas aucune licence du tout , c’est à dire mettre le logiciel dans le domaine public ? Après tout, c’est la conclusion logique du mouvement vers des licences de plus en plus permissives — une qui permet tout.

Compte tenu des discussions passionnées qui ont tendance à se produire lorsqu’on émet l’idée qu’il y a un mouvement des licences copyleft traditionnelles vers des licences légèrement plus permissives, je soupçonne que l’idée d’évoluer vers une licence complètement permissive sera choquante pour certains. À l’évidence, cela semblerait impossible, car conduisant « certainement » à l’effondrement du logiciel libre lui-même si celle-ci était largement adopté.

Un article intéressant de Clark Asay, maître de conférences à la Penn State Univerity Dickinson School of Law (et aussi frère de Matt Asay, personnalité connue de tous dans le logiciel libre) étudie cette idée en profondeur et présente quelques arguments convaincants sur le fait que placer les logiciels libres dans le domaine public fonctionne et s’avère bénéfique.

Asay (Clark et non Matt) remarque qu’il y a un coût à utiliser des licences libres en termes de conformité. Les entreprises dépensent énormément d’argent en se préoccupant de faire les choses bien, mais les programmeurs, eux aussi, perdent du temps à s’occuper de détails légaux alors qu’ils pourraient être en train d’écrire davantage de lignes de code. En particulier, l’incompatibilité entre les nombreuses licences et leurs variantes est une barrière importante à de plus larges réutilisations et collaborations. Ces problèmes signifient que les logiciels libres ne sont pas utilisés aussi largement et efficacement qu’ils le pourraient, commercialement ou non. Ces difficultés peuvent expliquer en partie le glissement vers des licences plus « permissives », guidé par le désir d’éviter justement ces problèmes.

Asay se met alors à examiner les deux objections majeures à rendre le code disponible librement, sans aucune licence. La première tient au fait que les entreprises risquent de récupérer du code puis de l’enfermer, ce qui selon lui a peu de chance de se passer puisque, en faisant ainsi, elles écarteraient beaucoup des bénéfices que seuls les logiciels libres offrent :

« Si une société devait prendre la responsabilité d’un projet et le rendre fermé, elle n’obtiendrait certainement pas le travail bénévole que les contributeurs du monde entier ont envie d’offrir aux projets disposant de licences ouvertes. Sans ce travail bénévole, les sociétés perdraient un des avantages les plus significatifs des modèles ouverts d’innovation, et ce travail bénévole resterait probablement fidèle à la version ouverte du projet. C’est pourquoi les sociétés encouragent d’ores et déjà à ouvrir le plus de projets possibles et à y contribuer. Car en faisant ainsi, cela va attirer une force de travail bénévole et déclenchera une innovation correspondant mieux à à leurs besoins et stratégies.

Est-ce que la réciprocité (c’est-à-dire l’obligation de contribuer au projet en contre-partie) permet d’éviter la désertion des contributeurs individuels ? Il semble peu probable que, dans la plupart de cas, les contributeurs individuels aient le temps, l’intérêt et les ressources pour s’emparer d’un projet non-réciproque et d’en créer un équivalent fermé. La littérature suggère que les buts espérés par les individus qui contribuent à des projets aux licences ouvertes, ont peu à voir avoir avec un avantage financier direct. Leurs intérêts pour la contribution résident plutôt dans la créativité, l’amélioration de sa réputation, et les bénéfices financiers indirects. Bien qu’il soit toujours possible pour des contributeurs de s’emparer d’un projet ouvert et de le rendre fermé pour l’intégrer dans leurs propres produits (et ainsi contrevenir à ce modèle ouvert d’innovation), les mêmes raisons qui suggèrent que les sociétés ne le feront pas s’appliquent également aux contributeurs individuels. Les contributeurs individuels sont encore moins à même d’abandonner les buts qu’ils espèrent atteindre dans la contribution à des projets ouverts, en plus de n’avoir que des ressources limitées pour réussir à fermer et maintenir un projet. »

L’autre objection majeure qu’il met en avant est que si le logiciel est placé dans le domaine public, il n’existe aucune exigence pour que tous les programmeurs reçoivent la reconnaissance qu’ils méritent pour leur contribution à un projet. Cette reconnaissance peut être importante en raison de l’estime des pairs dont ils jouissent en retour et peut même aboutir à des compensations économiques sous la forme d’offres d’emploi et d’augmentations de salaire.

Attribution et réputation

Je suis d’accord pour dire qu’attribuer le mérite d’un projet est important, et cela de manière cruciale. En fait, je pense que cela représente la clé du problème concernant les produits numériques partagés sur Internet, étant donné que les bénéfices économiques dépendent de cela. Toutefois, forcer cette attribution grâce à des licences ne représente peut-être pas le meilleur moyen. Asay l’explique ainsi :

« Dans une large mesure, l’approche de la gestion de la propriété intellectuelle choisie par les modèles d’innovation ouverts (c’est-à-dire les licences classiques des projets open source) échoue à remplir ses missions. Par exemple, le respect des licences attribution-only (mention de l’auteur original du projet) provoque l’enfouissement d’une telle reconnaissance dans les documents légaux ; cela fait que la reconnaissance d’une telle paternité devient minime. Cette réalité montre que ceux qui contribuent en utilisant des licences attribution-only, bien qu’étant motivés par une certaine forme de reconnaissance, obtiendront un tout autre type de reconnaissance que celui engendré par la propriété intellectuelle. Dans le monde du logiciel libre et open source, des outils comme GitHub, utilisé largement comme outil social de développement, peuvent fournir plus efficacement la reconnaissance que cherchent les programmeurs. Le fait que de plus en plus de contributions à des logiciels effectuées via GitHub se font sans avertissement de non-respect de la propriété intellectuelle ou des clauses de licences montre que le « prix » d’un tel avertissement à cause d’une documentation légale obscure n’en est pas un, du moins pour ceux qui contribuent. »

En effet, les personnes et les entreprises ont déjà commencé à utiliser les profils GitHub comme un moyen d’afficher et de mesurer la capacité à coder. Je soupçonne que cela deviendra bientôt la norme, avec des moyens plus formels d’établir sa réputation dans le monde du développment, apparaissant aux côtés de ceux informellement dictés par les normes sociales au sein de la communauté du logiciel libre.

Après avoir abordé les deux principales objections de se passer de licences open source traditionnelles, Asay examine ensuite ce que le domaine public signifierait en pratique :

« Une approche du style domaine public devrait remplacer efficacement les droits d’auteurs automatiques, supprimer tous les droits liés aux brevets (les deux respectant les droits des brevets déjà obtenus ainsi que de façon prospective), et renoncer à tous les recours possibles venant avec eux. Les droits liés au secret commercial, le cas échéant, devraient êtres supprimés dès que le titulaire des droits a publié le logiciel ou le contenu au public. On peut dire que renoncer à tout droit de marques est non seulement inutile mais déconseillé, car les autres pourraient utiliser les marques pour embrouiller les consommateurs quant à la source du logiciel ou du contenu. En effet, c’est exactement pourquoi la licence CC (Creative Commons), qui inclut une licence dédiée au domaine public dans son répertoire légal, exclut expressément les droits de marque dans son outil. »

Ce dernier point sur les marques est important, bien qu’il puisse sembler étrange de prétendre que tous les monopoles intellectuels et marques doivent être conservés, parce qu’ils servent un but très différent de celui du droit d’auteur ou des brevets. Les marques sont conçues pour protéger les consommateurs contre la fraude, plutôt que de chercher à exclure les concurrents, même si c’est la façon dont elles sont souvent utilisées aujourd’hui.

Mais pour les projets open source, les marques sont purement une question de réputation — c’est à dire qu’elles deviennent des garanties de qualité lorsqu’elles sont appliquées à un programme. N’importe qui peut prendre le code et l’utiliser et l’adapter de différentes façons. Mais il ne pourra pas utiliser la marque du projet, car cela impliquerait qu’il s’agit d’une version officielle « approuvée ». Ce qui serait évidemment problématique pour une variété de raisons, à commencer par celle de la sécurité.

Asay aborde également une objection importante dans sa thèse selon laquelle placer un logiciel dans le domaine public serait la meilleure façon de le distribuer : si c’était le cas, pourquoi tout le monde s’en tiendrait à la licence GPL ou Apache ? Comme il le souligne :

« Dans le monde du logiciel libre et open source, par exemple, il n’existe aucun outil reconnu ou largement utilisé dévoué au domaine public. A la place, l’Open Source Initiative et la Free Software Foundation — les deux principales organisations de défense des logiciels libres dans le monde — refusent ou approuvent les licences ouvertes utilisées dans la communauté. S’il est vrai que divers projets pourraient tout simplement ignorer ces licences recommandées et d’adopter une approche par domaine public — certaines ayant essayé de faire exactement cela — cette approche suppose que les organisateurs de ces projets comprennent comment le faire. »

Le fait est qu’il est actuellement assez difficile de placer un logiciel dans le domaine public, premièrement parce qu’il y a un biais culturel contre une telle attitude, même au sein de la la communauté du logiciel libre, et deuxièmement parce que légalement c’est un processus délicat. En effet, Asay suggère que nous avons besoin d’une nouvelle législation — ce qu’il appelle Public Domain Act (NdT, en français : « Loi du Domaine Public ») — pour rendre ce processus plus facile. Il faudra évidemment prendre en compte les différents systèmes de copyright ayant cours dans le monde — par exemple, ceux qui mettent plus l’accent sur les « droits moraux ».

Il y a quelques années, j’ai demandé à Richard Stallman ses points de vue sur la manière dont le copyright devrait être réformé, particulièrement concernant l’aspect logiciel. Voici ce qu’il a répondu :

« Pour la plupart des types de travaux, je pense que le droit d’auteur serait acceptable si nous l’avions (1) fait plus court (je suggère 10 ans), (2) permis la redistribution de copies dans un but non commercial et sans modification, (3) défini comme fair use les réutilisations sous forme de remix. Cependant, je pense que les logiciels et autres œuvres d’usage pratique doivent être libres. »

Notez qu’il pense, lui aussi, que le logiciel devrait être exempt de tout copyright — en d’autres mots, dans le domaine public — mais il a ajouté quelques mises en garde :

« Je serais heureux de voir l’abolition du copyright dans le logiciel si c’était fait de façon à s’assurer que le logiciel est libre. Après tout, l’objectif du copyleft est d’atteindre ce but pour les dérivés de certains programmes. Si tous les logiciels étaient libres, le copyleft ne serait plus nécessaire.

Cependant, l’abolition du copyright peut aussi être faite de manière erronée et pourrait n’avoir aucun effet sur les logiciels propriétaires typiques (qui sont restreints par des CLUF, Contrats de Licence Utilisateur Final, et le secret du code source plus que par le copyright), et ne ferait que porter atteinte à l’utilisation du copyleft. J’y serais naturellement opposé. »

Placer les logiciels libres dans le domaine public serait équivalent à abolir le droit d’auteur pour ces programmes tout en laissant le code propriétaire intact. Est-ce vraiment un problème ? Personnellement, je ne le pense pas, pour les raisons que j’ai mentionnées : toute entreprise prenant du code dans le domaine public et se l’appropriant perd tous les avantages de son ouverture. Il est vrai qu’il reste des programmes hérités des maisons de logiciels à l’ancienne qui ont toujours été propriétaires, mais leurs existence n’affecte pas vraiment le monde plus large du logiciel libre, qui est maintenant arrivé à l’indépendance et à l’autosuffisance. Ce que Microsoft et ses semblables font en ce moment est quelque peu hors de propos.

Bien sûr, le passage au domaine public ne signifiera pas la disparition des licences libres actuelles — elles seront toujours là pour ceux qui souhaitent les utiliser. Comme toujours, le choix et la liberté personnelle sont capitaux. Mais j’espère que les gens y réfléchiront à deux fois avant d’introduire de nouvelles licences, ou même avant d’en mettre à jour d’anciennes. En particulier, j’espère qu’il n’y aura jamais de GNU GPL version 4. Au contraire, nous devons parachever la révolution que Richard Stallman a commencée il y a près de trois décennies en rendant le logiciel libre véritablement libre, en le plaçant dans le domaine public et en brisant les chaînes qui le lient encore à ce monopole vieux de trois cents ans nommé copyright.

« Le magazine américain New Yorker a annoncé la création d’une boîte informatique sécurisée nommée Strongbox, destinée à recevoir des informations en protégeant l’anonymat des sources » pouvait-on lire récemment sur le site des Écrans, qui ajoute : « La technologie utilisée a été développée par le jeune militant d’Internet et hacker Aaron Swartz, qui était poursuivi par la justice pour avoir pénétré une base de données universitaires et s’est suicidé en janvier ».

Nous avons voulu en savoir plus en traduisant l’article ci-dessous. Difficile de se départir d’une certaine émotion quand on sait ce qu’il lui est arrivé par la suite…

Strongbox et Aaron Swartz

Strongbox and Aaron Swartz

Kevin Poulsen – 15 mai 2013 – The New Yorker
(Traduction : anneau2fer, Penguin, Sky, lgodard, Rudloff, Asta, Jere, KoS + anonymes)

Aaron Swartz n’était pas encore une légende lorsque, il y a presque deux ans, je lui ai demandé de développer une boîte aux lettres anonyme et open source. Ses réussites étaient réelles et variées, mais les événements qui allaient le faire connaître du grand public faisaient encore partie de son futur : sa mise en cause dans une affaire criminelle au niveau fédéral ; son essor en tant que leader du mouvement contre la liberticide Sopa ; son suicide dans un appartement de Brooklyn. Je le connaissais comme programmeur et comme activiste, un membre de la tribu relativement restreinte de gens qui savent transformer des idées en code — un autre mot pour « action » — et qui ont la sensibilité nécessaire pour comprendre instantanément ce que je cherchais : un moyen sûr pour les journalistes de communiquer avec leurs sources.

Il existe une fracture technologique grandissante : les écoutes de téléphones et d’emails, le piratage d’ordinateurs, sont des armes pour quiconque cherche à identifier les sources d’un journaliste. À quelques exceptions, la presse a peu fait pour se protéger : nos efforts en matière de sécurité de l’information tendent à se concentrer sur la partie des infrastructures qui accepte les cartes de crédit.

Aaron était au fait de ce genre de problème. Je l’avais d’abord rencontré en 2006, lorsqu’avec deux autres codeurs, il avait vendu le site d’info communautaire Reddit à Condé Nast, la maison mère de Wired, où je travaille, et du New Yorker. Tous trois se sont retrouvés dans une salle de conférence improvisée près du siège de Wired à San Francisco. Aaron se distinguait de ses collègues — il était angoissé, silencieux, et a expliqué dans un billet de blog à quel point il n’aimait pas travailler là.

Un lundi, il a quitté le bureau pour passer la journée au tribunal tout proche, où une audience avait lieu dans l’affaire Kahle contre Gonzales, une bataille constitutionnelle autour du copyright menée par le professeur de droit Lawrence Lessig. Lorsqu’il est revenu, il m’a demandé, un peu timidement, s’il pouvait écrire quelque chose sur le sujet dans Wired. Le billet de blog de 700 mots qui en résultât était bien écrit et énonçait clairement le sujet. Je me suis posé des questions sur ce jeune patron de start-up qui mettait son énergie dans le débat sur le copyright. Ça, et sa co-création d’un projet d’anonymisation appelé Tor2Web, était ce que j’avais en tête lorsque je l’ai approché pour mon projet de boîte aux lettres sécurisée. Il a accepté de le faire, tout en sachant que le code serait open source — la licence autorisant n’importe qui à l’utiliser librement — lorsque le système serait lancé.

Il se mit à coder immédiatement, pendant que je cherchais les serveurs et la bande passante nécessaires chez Condé Nast. Les normes de sécurité imposaient que le système soit sous le contrôle physique de la société, mais avec sa propre infrastructure isolée. Des autorisations ont du être demandées. Les cadres avaient des questions. Les juristes avaient encore plus de questions.

En octobre 2011, Aaron est venu dans les bureaux de Wired et nous avons travaillé sur quelques détails. Durant les années qui ont suivi, le mutisme tranquille d’Aaron s’est mué en confiance provisoire, sa morosité remplacée par un sourire désarmant et une douce générosité. Avant qu’il ne parte, je suis allé avec lui dans les nouveaux locaux, bien plus grands, de Reddit, qui se trouvaient à côté. Il entra, regarda autour de lui, et ressortit sans que personne ne l’ait reconnu.

Entre-temps, Aaron avait été inculpé pour le téléchargement de 4 millions d’articles de JSTOR, une base de données académique, depuis le réseau public du MIT. Cette affaire a dû lui peser. Mais il n’en parlait pas.

Il vivait a New York à cette époque, mes contacts avec lui étaient donc essentiellement électroniques. Le système, que nous appelions DeadDrop, était, pour nous deux, un projet secondaire, et Aaron en avait beaucoup de prioritaires. J’ai appris son protocole : quand il avait le temps de programmer, je pouvais le joindre par téléphone ou sur Skype. Nous avions de long échanges à propos de sécurité et de fonctionnalités ; Aaron rejetait ceux dont il pensait qu’ils compliqueraient trop le système — clés de chiffrement individuelles pour chaque reporter, par exemple.

À New York, un expert en sécurité informatique nommé James Dolan convainquit un trio de collègues de son industrie de rencontrer Aaron pour examiner l’architecture, et plus tard, le code. Nous voulions être raisonnablement assurés que le système ne serait pas compromis, et que les sources pourraient déposer des document de manière anonyme, afin que même l’organe de presse qui les recevrait ne serait pas capable de dire au gouvernement d’où ils venaient. James a écrit un guide de sécurité pas à pas très détaillé pour les organisations qui implémentent le code. « Il va un peu trop loin », disait Aaron dans un email, « mais ce n’est peut-être pas une mauvaise chose ».

En décembre 2012, le code d’Aaron était stable, et une date approximative de lancement avait été définie. Puis, le 11 janvier, il se suicida. Dans les jours qui suivirent, il était difficile de penser à autre chose que la perte et la douleur de sa mort. Un lancement, comme beaucoup d’autres choses, était secondaire. Son suicide a également fait apparaître de nouvelles questions : à qui appartient le code désormais ? (Réponse : ses dernières volontés indiquaient qu’il voulait que toutes ses propriétés intellectuelles reviennent à Sean Palmer, qui donna sa bénédiction au projet). Est-ce que ses amis proches et sa famille approuveraient de poursuivre le lancement ? (Son ami et exécuteur testamentaire, Alec Resnick, a signalé que c’était le cas). Le New Yorker, qui a un long passé de travail d’enquête sérieux, apparut comme le premier foyer pour le système. La version du New Yorker s’appelle Strongbox et a été mise en ligne ce matin.

Neuf jours après la mort d’Aaron, son avatar Skype si familier, est apparu sur mon écran. Quelqu’un, quelque part, probablement un membre de sa famille, avait démarré son ordinateur. J’ai dû combattre l’envie irrationnelle de cliquer sur l’icône et reprendre notre conversation. Puis il a disparu à nouveau de mon écran.