L’équipe d’OpenHatch organise régulièrement des rencontres, ateliers, événements, sprints, hackathons, etc. invitant de nouveaux contributeurs à participer au développement de logiciels libres. Elle nous livre ici le fruit de son expérience.

L’enthousiasme et la motivation sont indispensables mais ne peuvent faire l’économie d’une solide organisation et réflexion en amont. Happy Hacking 🙂

Note : On remarquera que les deux livres cités en référence pour aller plus loin font partie de nos traduction Framabook : Libres conseils et Produire du logiciel libre.

 

 

Le guide de l’événement libre in situ

The In-Person Event Handbook

L’équipe OpenHatch – février 2014
(Traduction : Omegax, zak, François, Ju, MrTino, Wan, Asta, François, goofy, amha)

Faire en sorte que votre projet soit prêt pour de nouveaux contributeurs

Il semble que chaque jour apparaisse un nouvel atelier, hackaton ou autre sprint, où des projets open source sont invités à travailler avec de nouveaux contributeurs. À OpenHatch, nous avons nous-mêmes souvent organisé ce genre d’événements ! Nous avons découvert que pour en tirer un profit maximal, il est important de planifier les choses en amont. Expliquer vos objectifs, identifier les tâches appropriées, et tester l’organisation de votre projet sont autant de points indispensables pour aboutir à de belles réalisations et passer un bon moment. Ce travail a grandement amélioré nos expériences, et nous pensons qu’il mérite l’effort significatif qu’il mplique.

Nous avons créé ce guide pour aider les projets open source à se préparer pour ces événements. Nous avons utilisé notre propre projet, l’application web OpenHatch.org, comme un exemple dans ce qui suit. Au bas de la page, vous trouverez des aide-mémoires. Elles contiennent en condensé les conseils dispensés dans ce guide, et peuvent vous aider à monitorer vos progrès durant la phase de préparation de votre projet.

Les sources de ce guide sont libres. Un tas de merci à nos contributeurs. (Vous pouvez contribuer, vous aussi !)

Définir des objectifs

Vous devez être capable de présenter clairement vos objectifs pour l’événement, car cela donne à votre groupe une ambition générale à atteindre. Vous pouvez donc commencer par vous demander :

Quel est l’objectif global de votre projet ?

Il vous faut une réponse courte (un paragraphe ou moins) à cette question que vous pourrez utiliser pour attirer les contributeurs potentiels vers votre projet. Les détails, c’est bien joli, mais vous ne devriez pas avoir besoin d’être trop technique à ce moment là. À de nombreux événements, comme les sprints PyCon, on vous demandera un court résumé à exposer devant tout le monde. Pourquoi ne pas vous y préparer ?

Exemple :

L’objectif de OpenHatch est de rendre les communautés de logiciels libres plus accueillantes pour les nouveaux venus. Pour ce faire, nous fournissons documents et support logistique pour animer des ateliers « Introduction à l’open source », un site web avec des ressources libres, des « missions d’entraînement », un découvreur de talents parmi les bénévoles, et plusieurs autres projets en cours de réalisation.

Que voulez-vous accomplir à cet événement ?

Réfléchissez à ce que vous souhaitez voir spécifiquement réalisé lors de cet événement. Vous pouvez catégoriser ces objectifs selon les différentes parties du projet, si vous en avez plusieurs. Il devrait être spécifié clairement de quelle manière ces actions contribueront au progrès général du projet. Toutefois, il ne s’agit pas de « tâches » — il devrait être toujours nécessaire de diviser ces objectifs pour mieux les atteindre.

Il est utile de les lister en termes d’objectifs « principaux » et « étendus ». Avoir des objectifs principaux réalistes et bien définis vous donne quelque chose à célébrer à la fin de l’événement, tandis que les objectifs étendus ou secondaires vous permettent de prévoir le cas excitant où vous vous retrouviez avec une équipe nombreuse et efficace, capable d’accomplir une tonne de travail.

En général, il vaut mieux avoir trop d’objectifs que pas assez, mais priorisez-les. Lorsque vous arriverez à l’étape du découpage en tâches, prenez le temps de traiter en détail chaque objectif avant de passer au suivant.

Exemple :

• Faire une nouvelle mission d’entraînement
  • Objectif principal : Choisir une compétence sur laquelle baser une nouvelle mission d’entraînement, et concevoir cette mission. En créer une maquette.
  • Objectif étendu : Implémenter la maquette et la faire tester par des volontaires de l’événement.
• Faire le ménage dans le suivi de tickets
  • Objectif principal : Passer en revue l’outil de suivi, et étiqueter les tickets selon le « ménage » à y faire. Un bug doit-il être vérifié ? Un patch doit-il être testé ? Une demande de fonctionnalité doit-elle être être rattachée à un jalon ?
  • Objectif étendu : Utiliser ces étiquettes comme guide pour « faire le ménage » . Vérifier les bugs, tester les patches, etc.

Installation du projet

Dans notre expérience, la phase d’installation du projet est l’obstacle majeur à la participation. Nous avons vu (et conduit !) des événements où les participants passaient le plus clair de leur temps à seulement mettre en place leur environnement de développement et faire connaissance avec le projet. Si notre objectif est de permettre à de nouveaux venus de contribuer, tâchez d’estimer le temps qu’il faut pour installer votre projet. Puis trouvez un ami qui n’est pas familier avec votre projet pour voir combien de temps il faut vraiment. Vous pouvez aussi trouver quelqu’un pour vous aider à faire cela dans #openhatch.

Documenter et améliorer le processus à l’avance peut faire économiser du temps et de l’énergie à tout le monde. Si vous savez qu’une partie de votre projet sera inévitablement dévoreuse de temps, assurez-vous que tous les participants savent exactement à quoi s’en tenir.

Toutes les informations ci-dessous devraient être documentées dans un fichier LISEZ-MOI placé à la racine de votre dépôt. Vous pouvez également placer cette information dans une section « Vous voulez participer ? » sur le site web de votre projet, et/ou vous pouvez inclure un lien vers le LISEZ-MOI dans la signature de votre liste de diffusion ou dans la barre de statut de votre canal IRC.

Comment trouver une communauté et des mainteneurs pour le projet

Les informations des contacts devraient être explicitement affichées, étant donné que vous pourriez avoir des contributeurs éloignés ou des contributeurs qui voudraient démarrer en amont de l’événement. Les types d’informations de contacts peuvent inclure :

• Un lien vers votre mailing-list ;
• Votre nom de canal et de serveur IRC (avec le lien vers le guide pour installer IRC et le lien vers sa version webchat) ;
• Les comptes de réseaux sociaux tels que Identi.ca, Twitter ou Facebook si votre projet en possède ;
• Le contact des mainteneurs du projet, si vous vous sentez à l’aise pour le mentionner.

Si vous avez une préférence pour le type de prise de contact, précisez-le.

Exemple:

OpenHatch laisse en deux endroits des informations de contact que nous essayons le plus possible de garder à jour et en cohérence l’un avec l’autre. Il y a nos informations de contacts dans la documentation, référencées principalement depuis notre répertoire où sont déposés les codes sources, et nos informations de contacts dans le wiki, référencées à partir de la page d’accueil du site web.

La structure du projet

Décrivez la structure de base de votre projet. Quels sont les plus gros composants et où sont-ils situés ? Comment ces composants interagissent-ils ? Puis décomposez chaque partie. Vous n’avez pas à parler de chaque fichier ou sous-dossier de votre projet, mais prenez soin de ne pas prendre pour acquis que chaque nouveau venu comprendra le sens de tel script, ou la manière dont interagissent tels fichiers, ou dans quel langage est programmée telle partie du projet.

Selon la taille et la complexité de votre projet, cela peut être une tâche particulièrement imposante. Chez OpenHatch, nous travaillons toujours à documenter la structure complète du projet. Nous recommandons de commencer par une explication « en vue d’ensemble » de la structure projet – juste assez de détails pour remplir d’une demi-page à une page. Quand vous aurez plus de temps, vous pourrez rentrer dans le détail, en commençant par les parties du projet sur lesquelles les gens travaillent le plus souvent (ou qui sont plus susceptibles de faire l’objet de sprints ou de hackatons). Si vous utilisez d’autres frameworks ou librairies, vous pouvez gagner du temps en mettant des liens vers leur documentation et leurs tutoriels.

Exemple :

Une description d’ensemble de la structure du projet OpenHatch peut être trouvée dans « Project Overview ». Une description de la structure de OH-Mainline (le dépôt derrière notre site web) y est présente.

Comment mettre en place un environnement (« de développement ») local

Pour contribuer à votre projet, les gens ont généralement besoin d’une version locale du projet où ils peuvent faire des modifications et les évaluer. Plus votre guide d’installation/développement est détaillé et clair, mieux c’est.

Voici quelques éléments pour la mise en place d’un environnement de développement à mettre dans votre guide :

• Préparer leur ordinateur
  • Assurez vous qu’ils connaissent bien les outils de leurs systèmes d’exploitation, comme le terminal / la ligne de commande. Vous pouvez le faire en donnant un lien vers un didacticiel et en demandant aux utilisateurs s’ils le comprennent bien. Souvent, de très bons didacticiels existent déjà, celui d’OpenHatch sur la ligne de commande est disponible ici.
  • Si les contributeurs doivent mettre en place un environnement virtualisé, accéder à une machine virtuelle ou installer un kit de développement en particulier, expliquez-leur comment faire.
  • Donnez la liste de toutes les dépendances nécessaires pour faire tourner le projet, et une explication pour les installer. Fournissez un lien vers de bons guides d’installation, s’il en existe.
• Téléchargement du code source
  • Donnez des instructions détaillées sur comment télécharger le code source du projet, dont les obstacles et problèmes fréquemment rencontrés.
  • S’il existe plusieurs versions du projet, dites clairement quelle version ils doivent télécharger.
• Comment voir / tester les changements
  • Expliquer aux contributeurs comment voir et tester les changements qu’ils ont effectués. Ceci peut varier selon ce qu’ils ont changé, mais faites votre possible pour couvrir les changements les plus fréquents. Cela peut être, tout simplement, afficher un document html dans un navigateur, mais ce peut aussi être plus compliqué.

L’installation pourra différer pour chaque contributeur en fonction de leur système d’exploitation. Vous aurez probablement besoin de créer des instructions séparées pour les utilisateurs de Windows, Mac et Linux, dans différentes parties de votre guide. Si vous entendez ne supporter le développement que pour un seul système d’exploitation, assurez-vous que cela soit dit clairement pour les utilisateurs,

Exemple:

Vous pouvez voir comment OpenHatch annonce cela dans son guide d’installation. Les instructions pour tester des changements peuvent être trouvées là. Des tâches plus spécifiques peuvent avoir leur documentation additionnelle (par exemple la documentation concernant les différents changements du code).

Contributions et retours

Comment les contributeurs doivent-ils procéder pour amener leurs modifications au projet ? Est-ce qu’ils soumettent une pull request sur Github ? Doivent-ils générer un patch et l’attacher à un ticket sur le système de tickets ? Assurez-vous que cette information est explicitement fournie.

Example :

Le guide d’OpenHatch pour soumettre des changements peut être trouvé ici.

Il est aussi utile d’indiquer aux gens comment ils peuvent faire des retours/signaler des bugs sur le projet. Si votre projet n’a pas de système de suivi de tickets, envisagez d’en créer un. Sur Github, tous les dépôts disposent du système de tickets (bien que vous ayez à l’activer en allant dans Settings puis Features). Il y a beaucoup d’autres systèmes de suivi de tickets.

Si votre projet est de petite taille, vous pouvez ne pas avoir besoin ou ne pas vouloir de systèmes de suivi de tickets. Aucun problème. Le principal est que les contributeurs sachent comment vous remonter des informations.

Example :

Les problèmes avec le projet « Open Source Comes to Campus » peuvent être signalés ici. La plupart des autres problèmes liés à OpenHatch peuvent être signalés là.

Les outils tels que le suivi de tickets sont très utiles pour communiquer de manière asynchrone. Ce n’est peut-être pas la solution la plus appropriée lors d’un événement physique. Si vous voulez changer les choses pour l’occasion – comme demander aux participants de vous notifier par IRC les liens vers les nouveaux tickets, pour éviter qu’ils ne passent entre les mailles du filet – assurez-vous de leur en parler !

Vérifiez votre documentation

Vérifiez que cette documentation est complète et effective en la testant auprès de personnes qui n’ont pas participé à votre projet auparavant. Pour chaque sytème d’esploitation, trouvez au moins une personne pour lire votre documentation, tenter d’installer, faire et tester des modifications et participer aux différentes modifications du projet (au choix de votre testeur, ces modifications peuvent être des faux changements ou des vraies tâches). Vérifiez que vos testeurs ont des compétences et/ou une expérience similaire à celle des nouveaux arrivants à votre évènement.

Si vous rencontrez des difficultés pour trouver des personnes pour vous aider, essayez la chaine #openhatch sur IRC.

Assurez-vous que tous les problèmes qui surviennent lors de ce processus de vérification soient intégrés à la documentation. Une fois que la documentation a été vérifiée, ajoutez une ligne au début de votre guide pour annoncer ce qui a été vérifié et quand.

Par exemple :

Instructions de l’environnement de développement testées avec succès sur Ubuntu 12.04 (le 03/10/2013), Mac OS X 10.8 (le 01/10/2013) et Windows XP (en janv. 2005). Vous pouvez consulter cette démarche à OpenHatch ici.

Idéalement, vous devriez vérifer que tout fonctionne : installer, faire des modifications, les tester et les intégrer. Si vous n’avez le temps que pour une seule de ces tâches, nous vous recommandons de vérifier l’intallation. Notre expérience nous a appris que c’est sur ce point qu’émergent la plupart des problèmes.

Définir les tâches des participants

Retournons aux objectifs de l’événement dont nous avons parlé dans la première section. Chaque objectif devrait être décomposé en étapes distinctes qui permettront de l’atteindre. Ces étapes sont les tâches à confier aux participants.

Ces tâches devraient inclure un résumé en anglais simple aussi bien que les informations sur la localisation des modifications (par exemple, quels fichiers ou fonctions sont altérés). Nous recommendons d’inclure une liste des compétences nécessaires (par exemple : compétences en design, Python basique) et des outils (par exemple: Développement sur environnement Mac). Il est aussi utile d’inclure le nombre estimé d’heures que la tâche va prendre, d’étiqueter certaines tâches comme plus ou moins importantes, et de marquer où quelle tâche est dépendante d’une autre.

Cela semble représenter beaucoup de travail mais cela devrait aider vos participants à trouver rapidement et facilement les tâches appropriées pour eux. Etant donné que l’un des objectifs principaux d’un événement en personne est de donner une expérience positive aux participants, nous pensons que cela en vaut la peine.

Créer un système pour suivre les tâches

Nous recommandons l’utilisation d’un wiki ou un document de planification similaire pour garder une trace des tâches. OpenHatch dispose d’un navigateur pour suivre les tâches que nous utilisons pour nos événements. Vous pouvez, si vous le souhaitez, faire un fork et l’adapter à votre projet ou événement ; cependant, nous vous recommandons d’attendre un peu, car nous allons bientôt faire de grosses améliorations. Quelque chose de très simple, comme un etherpad (NdT : ou Framapad), peut également faire l’affaire (ici, un cadre et un service exemple que vous pouvez utiliser).

Préparer les tâches

Pour vous rendre compte du nombre de tâches à préparer, nous vous recommandons de vous baser sur la durée de l’événement et le nombre de participants attendus pour prédire la charge en temps/homme de votre projet. Vous pouvez utiliser les estimations de temps que vous avez faites pour évaluer chaque tâche. Nous suggérons que vous prévoyiez 30% de plus que ce dont vous pensez que vous aurez besoin : il vaut mieux avoir trop que pas assez.

Exemple :

• Objectif de base : parcourir l’interface et étiqueter les tickets selon le type de résolution nécessaire. Est-ce qu’un bug doit être vérifié ? Est-ce qu’un patch doit être testé ? Une fonctionnalité doit-elle être rattachée à un jalon ?
  • Tâche 1 : étiqueter les problèmes
    • Compétences et outils nécessaires : compétences de base en anglais, connaissance des concepts de vérification, tests, jalons…
    • Temps estimé : ~20 minutes par problème
    • Pour démarrer : prenez connaissance du suiveur de tickets, et comment il affiche les informations. (Voyez cette documentation.) Demandez un accès Administrateur pour pouvoir ajouter des étiquettes au suiveur.
    • Pour chaque problème : lisez la discussion relative à chaque problème, et identifiez où la communauté intervient dans le signalement de ce problème. Si c’est un bug non vérifié, ajoutez le label non vérifié. Si c’est un patch non testé, ajoutez l’étiquette patch non testé, etc. Si c’est une fonctionnalité qui n’est rattaché à aucun jalon, ajoutez l’étiquette jalon nécessaire.
• Objectif étendu : utilisez les étiquettes comme un guide pour résoudre chaque ticket. Vérifiez les bugs, testez les patch, etc.
  • Tâche 1 : Vérifier les bugs
    • Compétences et outils nécessaires : compétences de base en anglais, et dans l’idéal connaître les machines virtuelles pour effectuer des tests sur plusieurs OS.
    • Temps estimé : 20 minutes par bug (variance élevée).
    • Pour démarrer : téléchargez l’environnement de développement et assurez vous que vous pouvez lancer le projet. Assurez vous que vous avez un compte sur Le suiveur de tickets et que vous savez ajouter des commentaires ou changer les étiquettes.
    • Pour chaque bug : essayez de reproduire le bug. Enregistrez les résultats dans un commentaire, avec des informations concernant le type de l’OS et sa version. Si possible, effectuez le test sur plusieurs navigateurs. S’il y a plusieurs commentaires récents sur les trois OS majoritaires, ajoutez l’étiquette prêt pour test par le mainteneur (NdT : ready_for_maintainer_review).

Quoi qu’il en soit, les participants doivent être rattachés à une tâche correspondant à leurs compétences et à leurs intérêts. Effectuer ce travail préparatoire fera démarrer les participants immédiatement plutôt que de les faire attendre que vous leur suggériez une tâche adéquate. Dans l’idéal, les organisateurs d’événements auront collecté des informations sur les compétences et intérêts des participants bien en amont, donc vous pourrez adapter la liste à votre groupe de contributeurs.

Rendre explicites les étapes de chaque tâche facilite l’entraide entre les participants. En identifiant clairement les compétences et concepts nécessaires, il devient plus facile pour les gens de dire : « Oh, je comprends comment faire ça ! Attends, je vais te montrer ».

Suite

Il est possible que les contributeurs ne puissent pas finir les tâches sur lesquelles ils travaillent pendant l’événement, ou qu’ils veuillent continuer à participer au projet en travaillant sur d’autres tâches. Penser en amont de l’événement à comment vous allez organiser sa suite rend plus facile l’échange d’informations avec les participants et la planification de la direction de votre projet.

Nous recommandons de demander à chaque participant de répondre aux questions suivantes à propos des tâches sur lesquelles ils ont travaillé. Donnez leur cette liste au début de l’événement : cela les aidera à documenter ce qu’ils font. Vous pouvez imprimer cette liste, l’envoyer par mail aux participants, faire un formulaire web, comme vous préférez.

Par exemple :

• Pour chaque tâche sur laquelle vous avez travaillé, veuillez répondre aux questions suivantes :
  • Sur quelle tâche avez-vous travaillé ?
  • Veuillez documenter brièvement votre workflow. Quelles étapes, dans quel ordre, pourquoi ?
  • Où puis-je trouver le travail que vous avez réalisé pendant l’événement ? Ceci inclut le code, la documentation, les maquettes, et autres choses.
  • Si vous avez créé des comptes pour le projet, veuillez lister les sites et les noms des comptes. Enregistrez le mot de passe dans votre gestionnaire de mot de passes préféré, ou assurez vous que moi ou un autre mainteneur y aie accès.
  • Quels obstacles avez-vous rencontré en travaillant sur cette tâche ? Avez-vous des retours à me faire pour améliorer le processus pour les futurs contributeurs ?
  • Voudriez-vous rester impliqué dans ce projet ? Si oui, dans quelle mesure ?

S’il y a suffisamment d’enthousiasme pour continuer le travail, assurez-vous de rester en contact ! Nous suggérons que vous rassembliez les emails des participants intéressés et que vous les contactiez dans les 48 heures suivant l’événement. Dans votre email, remerciez-les pour leur aide et fournissez des informations sur comment rester dans la communauté par, par exemple, IRC ou des listes de diffusion.

Nous recommendons aussi de prévoir un rendez-vous suite à l’événement. Si vous êtes tous originaires de la même région, essayez de fixer une date après l’événement pour vous et votre équipe au café du coin, à l’espace de coworking, ou à une soirée-projet. Si vous êtes éloignés géographiquement, fixez une date pour vous rencontrer sur IRC ou sur Google Hangout. 2-3 semaines après l’événement est un bon créneau, toutefois cela dépend si vous et vous nouveaux contributeurs êtes très occupés.

Checklists

Merci de votre attention ! Pour vous aider à garder un oeil sur chaque étape, nous avons créé deux checklists pour vous. La version détaillée inclut tous les conseils ci-dessus. La checklist la plus courte inclut les conseils que nous pensons les plus importants. Nous vous recommandons de démarrer avec la cheklist la plus courte. Une fois que vous avez accompli correctement cette checklist, vous pouvez revenir et faire les étapes supplémentaires si vous avez le temps et l’énergie.

Pour voir et/ou imprimer les checklists, se rendre ici.

Remerciements

Merci à tous ceux qui ont contribué ou aidé au projet.

Contributeurs

• Shauna Gordon-McKeon : maintenance, contenu
• Ni Mu : design
• Sheila Miguez : testeuse
• Asheesh Laroia : testeuse

Pour aller plus loin

• Open Advice (NdT : entièrement traduit par nos soins)
• Producing Open Source Software (NdT : entièrement traduit par nos soins)

Comme nous l’avions annoncé il y a un mois ici, demain c’est la journée d’action The Day We Fight Back.

On peut toujours gloser sur la réelle portée d’un tel événement, mais il a le mérite de mettre le focus sur un sujet fondamental, pas assez relayé par les médias et peu pris à bras le corps par nos politiques. L’occasion justement d’en parler autour de nous et de faire avancer la sensibilisation.

Le jour de la contre-attaque : un appel à la communauté internationale pour lutter contre la surveillance de masse

The Day We Fight Back: A Call To the International Community to Fight Against Mass Surveillance

Katitza Rodriguez – 27 janvier 2014 – EFF.org
(Traduction : nitot, Asta, amha, piero, GregR, maxauvy)

Les révélations de Snowden ont confirmé nos pires craintes au sujet de l’espionnage en ligne. Elles montrent que la NSA et ses alliés ont construit une infrastructure de surveillance globale pour « contrôler Internet » et espionner les conversations mondiales. Ces groupes de l’ombre ont sapé les normes de chiffrement de base, et criblé la dorsale Internet avec des équipements de surveillance. Ils ont collecté des centaines de millions d’enregistrements téléphoniques de personnes qui n’étaient soupçonnées d’aucun crime. Ils ont écouté les communications électroniques de millions de personnes, chez elles et à l’extérieur, sans distinction aucune, en exploitant les technologies numériques que nous utilisons pour échanger et nous informer. Ils espionnent les populations alliées, et partagent ces informations avec d’autres organisations, au mépris le plus complet des lois.

Nous n’allons pas laisser la NSA et ses alliés détruire Internet. Inspirée par la mémoire d’Aaron Swartz, alimentée par la victoire contre SOPA et ACTA, la communauté numérique tout entière est unie pour retourner au combat.

Le 11 février, le jour de la contre-attaque (NdT : The Day We Fight Back), le monde va exiger la fin de la surveillance de masse dans tous les pays, tous les états, quels que soient les frontières et les régimes politiques. Les manifestations contre SOPA et ACTA ont été un succès car nous avons tous participé en tant que communauté. Comme le disait Aaron Swartz, tout le monde est devenu « le héros de sa propre histoire ». Nous pouvons choisir une date, mais nous avons besoin de tout le monde, de tous les utilisateurs de l’Internet, pour faire de ceci un mouvement.

Voici une partie de notre plan (mais ce n’est que le début). L’an dernier, avant qu’Ed Snowden ne fasse ses révélations au monde, les militants des droits numériques se sont entendus sur 13 Principes. Ces Principes expliquaient clairement en quoi la surveillance généralisée représente une violation des Droits de l’Homme, et donnaient aux législateurs et juges une liste de correctifs qu’ils pouvaient appliquer aux barbouzes de l’Internet. Ce jour de la contre-attaque, nous voulons que le monde adhère à ces principes. Nous voulons que les politiciens s’engagent à les respecter. Nous voulons que le monde voie que nous sommes concernés.

Voici comment vous pouvez rejoindre le mouvement :

1. Nous encourageons les sites web à faire un lien vers le site The Day We Fight Back. Cela permettra à des personnes du monde entier d’apposer leur signature sous nos 13 Principes, en riposte à la surveillance de masse de la NSA, du GCHQ et d’autres agences de renseignement. Si vous pouvez informer vos collègues sur cette campagne et le site avant la fin de la journée, nous pourrons envoyer de l’information à ce sujet dans chaque pays.

2. Dites à vos amis de signer les 13 Principes ! Nous (NdT : EFF) sommes en train de nous organiser pour nous associer à la journée d’action. Nous allons continuer à utiliser ces Principes pour montrer à ceux qui nous gouvernent que le respect de la vie privée est un droit pour chacun et doit être protégé sans tenir compte des frontières.

3. Courriels : Si vous avez besoin d’un prétexte pour en parler à vos collègues ou à vos proches à ce sujet, le 11 février est pile le bon moment pour leur dire de contacter les politiques locaux sur des sujets comme l’espionnage via Internet. Il faut les encourager à agir et à comprendre l’importance du combat contre la surveillance de masse.

4. Réseaux sociaux : touittez ! Postez sur Facebook et Google Plus ! Nous voulons faire autant de bruit que possible. Nous voulons vraiment une campagne à l’échelle du globe, où tous les pays sont impliqués. Plus nous serons nombreux à signer les Principes, plus ceux qui nous gouvernent entendront nos exigences visant à arrêter l’espionnage de masse chez nous et dans d’autres pays.

5. Outils : développez des mèmes, des outils, des sites web et tout ce que vous pouvez pour encourager d’autres personnes à participer.

6. Soyez créatifs (NdT : exemple) : préparez vos propres actions et vos propres engagements. Descendez dans la rue. Faites la promotion des Principes dans votre pays. Ensuite, dites-nous ce que vous comptez faire, de façon à ce qu’on fasse un lien vers vos efforts et qu’on leur donne de la visibilité.

Ce serait génial si vous participiez de ces six façons (ou plus encore !) mais franchement, tout ce que vous pourrez faire aidera le mouvement.

Les espions d’Internet ont passé trop de temps à écouter nos pensées et peurs les plus privées. Il est maintenant temps qu’ils nous entendent vraiment à leur tour. Si vous partagez notre colère, partagez aussi nos principes et contre-attaquez.

Crédit photo : Greenoid (Creative Commons By-SA)

Blog vraiment anonyme : mode d’emploi !

« Et si vous me trouvez, je serai vraiment très impressionné. »

Comment créer un blog anonyme

How to Start an Anonymous Blog

Anonyme (évidemment) – 26 janvier 2014 – Untraceable
(Traduction : crendipt, aKa, Diab, Penguin, Omegax, amha, nanoPlink, Paul, Scailyna, Scailyna, Asta, Unnamed, goofy, lamessen)

Introduction

Je crois qu’en suivant les étapes que j’expose dans ce billet, personne ne sera capable de dévoiler mon identité. Mon domaine peut être saisi et mon blog peut être fermé, mais je reste persuadé que mon identité restera un mystère.

Si je dis cela, c’est principalement parce que j’ai confiance dans un outil très important appelé Tor. Les développeurs et administrateurs des nœuds de Tor travaillent pour que chacun puisse être anonyme sur Internet. Tor est une sérieuse épine dans le pied pour la NSA et pour les autres organisations et pays qui font de l’espionnage sur Internet.

Vu que le réseau Tor rend très difficile l’identification des adresses IP et que l’enregistrement de domaines est désormais possible via Bitcoin, je n’ai à aucun moment besoin de fournir une quelconque information personnelle pour la mise en place de ce blog.

Outils et ressources

• Clé USB
• Système d’exploitation Tails
• Réseau Tor
• Bitcoins locaux – Acheter des bitcoins en espèces
• Comptes mail gratuits chez outlook.com et anonymousspeech.com
• Nom de domaine acheté chez IT Itch
• Site statique hébergé sur des pages GitHub

Tails / Tor

Tails est lancé depuis une clé USB qui inclut une partition chiffrée. Cette partition contient un porte-monnaie Bitcoin, le code source du blog et une base de données Keepass. Mes mots de passe pour des services tiers sont des mots de passe très forts générés aléatoirement. Avec Tails, il est difficile de se tromper, car toutes les connexions doivent obligatoirement passer par Tor. Par exemple, pour développer ce blog en local, je dois ajuster les règles du pare-feu pour autoriser les connexions locales au port 4000, télécharger un navigateur différent (Midori) et régler celui-ci pour qu’il n’utilise pas de serveur proxy. Le pare-feu bloque toutes les requêtes externes de Midori, mais je peux accéder à http://localhost:4000.

Donc, à moins d’agir de manière insensée, par exemple me connecter à StackOverflow au moyen de mon vrai compte Google et utiliser l’identifiant de « untraceableblog », je pense qu’il est quasiment impossible de me pister.

Je fais une sauvegarde de la clé USB sur mon ordinateur principal, sur un volume caché TrueCrypt. J’aime le concept des volumes cachés, j’ai l’impression d’être un putain d’espion. L’idée, c’est d’avoir un mot de passe factice qui déverrouille un faux dossier chiffré et un mot de passe réel pour déverrouiller le vrai dossier chiffré, sans qu’il y ait aucun moyen pour les autres de savoir lequel vous déverrouillez. Dans mon faux dossier chiffré, je garde ma base personnelle de Keypass, de cartes de crédit, et des scans de mon passeport et permis de conduire. Donc si quelqu’un me force à entrer mon mot de passe pour déverrouiller mon ordinateur et découvre que j’ai un volume TrueCrypt, il n’aura aucun moyen de savoir si j’ai entré le mot de passe réel ou bidon.

Cette fonctionnalité autorise une légère protection contre les tentatives d’extorsion de votre mot de passe par la force.

La plupart du temps, je cache la clé dans un endroit secret de la maison. Quand je dois aller quelque part et que je veux pouvoir mettre à jour ce blog, je le sauvegarde sur le volume caché, puis j’efface la clé de manière sécurisée et je peux l’emporter avec moi sans aucune crainte. C’est ce que je devrai faire jusqu’à ce que Tails intègre sa propre fonction pour les « volumes cachés ».

Messagerie électronique

J’ai créé un compte de messagerie gratuit sur Outlook.com et j’utilise anonymousspeech.com pour la vérification et la sauvegarde.

J’ai d’abord essayé Gmail, mais Google rend la création de compte très difficile quand on utilise Tor, à cause de la vérification par téléphone. C’est compréhensible, à cause des gens qui aiment créer un grand nombre de faux comptes pour envoyer du spam.

Blog

Ce blog est libre sur les pages GitHub, il utilise Octopress pour créer un site statique et j’ai installé le thème Page Turner. J’ai envoyé le contenu sur GitHub avec une clé SSH, bien entendu chiffrée et stockée sur ma clé USB.

Il me vient à l’esprit deux vecteurs susceptibles de vous donner des informations sur mon identité :

L’horodatage des messages

Le système d’exploitation Tails dispose d’une bonne stratégie pour forcer l’heure du système à être systématiquement en UTC. Mais si j’écris une série de billets dans les années à venir, vous pourriez en analyser l’horodatage pour déterminer mon fuseau horaire. Cependant, le site compilé indique uniquement la date. Par ailleurs, je voyage beaucoup (ou pas ?) 😉

Analyse de la fréquence des mots et caractères

Vous pourriez être capables de déterminer mon pays d’origine ou mon identité grâce à mes mots et mes phrases. Vous pourriez même trouver une corrélation avec les autres contenus que j’ai publiés en ligne sous ma véritable identité. Je contre cette possibilité en passant tous mes billets dans Google Translate. Je traduis dans une autre langue, puis en anglais et je corrige ensuite les erreurs. C’est parfait pour diversifier mon vocabulaire, mais j’aurais aimé que ça ne casse pas autant le Markdown et le HTML. Jusqu’ici vous pourriez croire que l’anglais est ma seconde langue. Mais laissez-moi vous assurer d’une chose : je n’ai jamais affirmé ni infirmé ce point.

Un des problèmes, c’est que Google peut voir mes messages originaux et probablement aussi la NSA. Si je voulais l’éviter, je pourrais poster des demandes de traductions anonymes et payer les traducteurs en bitcoins.

Statistiques

Les raisons de l’indisponibilité de Google Analytics vous sont données sous « Messagerie électronique ». À la place, j’ai choisi StatCounter.

Mais même si Google Analytics avait été disponible, je n’aurais pas utilisé une ID de suivi liée à mon identité réelle. Beaucoup de blogueurs anonymes ont été trahis par l’annuaire d’ID inversé proposé par Google.

Acheter des bitcoins avec le maximum d’anonymat

J’ai acheté les bitcoins en utilisant un compte anonyme créé via Tor. J’ai trouvé un vendeur qui souhaitait me rencontrer en personne et nous avons convenu d’un rendez-vous. Nous nous sommes rencontrés, je lui ai donné l’argent et il m’a transféré les bitcoins en utilisant son téléphone.

Acheter un nom de domaine avec des bitcoins

IT Itch est un registrar qui accepte les paiements via BitPay. Leurs noms de domaine sont assez chers,15 USD chacun, mais permettent un enregistrement totalement anonyme. Ce fut une démarche facile, mais il a fallu du temps pour que le domaine devienne actif (plus d’une heure). Une fois activé, j’ai configuré les enregistrements DNS pour GitHub Pages, et ensuite mon blog était accessible sur http://untraceableblog.com.

IT Itch a fait la grosse erreur de m’envoyer mon mot de passe en texte clair après la création du compte. PAS BIEN ! Si quelqu’un parvient à accéder à mon compte Outlook, il peut se connecter et détruire mon site. Donc j’ai effacé le message et changé mon mot de passe, et heureusement ils ne l’ont pas renvoyé par e-mail.

Comment je pourrais être découvert, 1ère partie

Pister les Bitcoins

En théorie, vous pouvez suivre la trace des transactions Bitcoins et découvrir mon identité. Toutefois, dans ce cas, il est très peu probable que même l’organisation la plus sophistiquée et la mieux financée puisse me découvrir.

Voyez-vous, j’ai acheté ces Bitcoins en utilisant un compte anonyme sur localbitcoins.com (créé en utilisant Tor). Nous avons convenu, le vendeur et moi, de nous rencontrer en personne, et j’ai payé en liquide. Pour dévoiler mon identité, il faudrait que vous puissiez casser les défenses de tous les services que j’ai utilisés ou bien travailler chez eux. Il faudrait par exemple :

1. Accéder à la base de données de ititch.com et trouver l’identifieur de la transaction BitPay pour untraceableblog.com
2. Accéder à la base de données de BitPay et trouver l’adresse Bitcoin qui a envoyé les Bitcoins pour cette transaction
3. Accéder à la base de données de localbitcoins.com. Trouver l’adresse Bitcoin qui a envoyé les Bitcoins à BitPay, retracer la transaction jusqu’à ce que vous trouviez l’adresse localbitcoins du dépôt fiduciaire.
4. À partir de l’adresse du dépôt fiduciaire, vous pourrez trouver le compte localbitcoins, et retrouver les messages que nous avons échangés pour nous rencontrer.
5. Vous devrez vous rendre au point de rendez-vous et espérer qu’il existe des caméras de surveillance qui auraient pu nous enregistrer ce jour-là.
6. Vous aurez enfin besoin d’accéder à la société de sécurité qui possède les enregistrements des caméras de surveillance, obtenir une bonne image de mon visage et faire tourner d’une façon ou d’une autre un logiciel de reconnaissance faciale pour découvrir mon identité. Travailler pour Facebook ou la NSA pourrait aider si vous avez réussi à parvenir à ce point.

Comment je pourrais être découvert, 2ème partie

Tout est hacké. Absolument tout.

Internet est une machine basée sur la confiance et il existe de nombreuses manières de briser cette confiance. Quelqu’un peut générer des certificats SSL de confiance pour n’importe quel domaine, exiger que son FAI route l’intégralité du trafic au travers de ces certificats, ou contrôler un grand nombre de nœuds Tor et réaliser des attaques par analyse de trafic. Je n’entrerai pas dans les détails mais si vous êtes intéressés, vous pouvez en apprendre davantage sur les attaques Tor :

• Comment la NSA attaque les utilisateurs de Tor / Firefox avec quantum et FOXACID
• Articles concernant les attaques sur le blog de Tor

Conclusion

Je n’ai fait ce blog que comme un exercice amusant d’anonymat, même si j’y posterai probablement des choses dans le futur. J’ai simplement utilisé des outils créés par des gens bien plus intelligents que moi et je ne suis sûrement pas le premier blogueur anonyme, mais j’espère vous avoir appris quelque chose.

Bien évidemment, on peut aller beaucoup plus loin que ça. J’aurais pu héberger ce blog sur un VPS que j’aurais loué avec des Bitcoins et installer le serveur comme un service Tor masqué. L’adresse IP du serveur aurait été totalement protégée mais, de ce fait, vous n’auriez pu consulter ce blog qu’au travers du réseau Tor, et les liens de nœud Tor (TBR) ça ne fait pas très chouette en page d’accueil. J’aurais également pu faire toutes mes actions depuis un cybercafé, juste au cas où Tor serait compromis, mais je n’aurais pas été découvert. Enfin, j’aurais pu choisir un domaine en « .se » si j’avais eu peur de l’intervention du gouvernement américain. C’est ce qui est actuellement utilisé par The Pirate Bay, et les Suédois leur laissent toute liberté d’action.

N’hésitez pas à m’envoyer quelques Satoshis (fractions de Bitcoins) si vous aimez ce billet : 146g3vSB64KxxnjWbb2vnjeaom6WYevcQb.

Et si vous me trouvez, je serai vraiment très impressionné.

Crédit illustrations : AndyRobertsPhotos (Creative Commons By) et XKCD

Yann Houry est professeur de lettres. Il place ses supports de cours depuis 2007 sur le site Ralentir Travaux, bien connu de ses collègues. Il y propose notamment des manuels complets pour les classes de Sixième et de Quatrième.

Nous lui avions ouvert nos colonnes en septembre 2012 parce que, contrairement aux maths où l’on a Sésamath, il est rare de trouver des ressources pédagogiques en libre diffusion en français. Nous souhaitions également pouvoir discuter avec lui de son choix du support iPad et de la licence Creative Commons By-NC-SA pour le contenu de son site et ses manuels.

Or justement, il souhaite abandonner aujourd’hui cette clause NC, qui pose selon nous problème dans l’éducation, et s’en explique ci-dessous. Nous en sommes ravis (d’autant que cela ouvre la voie à une possibilité d’édition Framabook). Et il n’est pas anodin que le titre de son annonce s’intitule Unchain my site !

« J’ai fait mes calculs. J’aurais besoin de 2000 à 2500 € pour acheter diverses choses (nouvel ordinateur, un micro, quelques logiciels, etc.). Une telle somme est donc la condition du changement de licence. Cela en vaut-il la peine ? J’avoue que je suis assez curieux de le découvrir. Peut-être cette demande fera-t-elle un joli flop. En ce cas, la question de la licence ne taraude que moi. »

Nous appuyons sans réserve la démarche en invitant nos visiteurs à participer à la collecte, histoire de montrer que nous sommes nombreux à être taraudés par le bon choix d’une licence 😉

Pour cela, se rendre sur le site Ralentir Travaux et cliquer sur la bandeau du haut.

Unchain my site

URL d’origine du document

Depuis sa création, Ralentir travaux a eu vocation à être diffusé le plus largement possible. Le site n’est-il pas né du désir d’offrir à tous – surtout aux élèves ne bénéficiant d’aucun soutien scolaire – la possibilité de trouver une aide sans inscription, sans mot de passe ou sans contrepartie quelconque ? Il s’agissait aussi de proposer, à l’enseignant désireux de trouver un peu d’inspiration, des ressources qu’il pourrait adapter à sa guise.

Dès lors la liberté était inscrite dans les gènes du site. J’avais d’ailleurs repris à mon compte ces mots de Condorcet afin de montrer que la notion de propriété intellectuelle était un abus qu’il fallait dénoncer^[1].

Par le passé, j’usais du mot «libre» sans trop savoir quelle notion il recouvrait. Plus tard, je découvrais les licences Creative Commons et m’emparait de celle-ci. Cela signifiait : fais ce que tu veux, mais ne vends pas. Or cette clause non commerciale (et cela a été dit de nombreuses fois) est un frein à la diffusion du savoir. Et Ralentir travaux n’a pas vocation à se recroqueviller sur lui-même dans la crainte d’une exploitation commerciale. Ce serait un non-sens. Au reste, nombreuses sont les personnes requérant l’autorisation d’utiliser telle ou telle partie du site, et invariablement la réponse est affirmative. Seule une demande était restée sans suite en raison de cette fameuse clause NC…

Il est donc nécessaire de recourir à une nouvelle licence. Seuls le partage à l’identique et la reconnaissance de la paternité de l’œuvre seront exigés. Que l’on me pardonne ce dernier sursaut d’orgueil (que m’accorde le droit), mais je tiens encore un peu à ma progéniture ! J’ai juste envie de lui donner un peu le large, et d’observer de loin ce qu’elle devient entre les mains de ceux qui voudront bien s’en emparer, et, je l’espère, la diffuser plus largement encore.

Mais, avant d’adopter une telle licence, je voudrais poser une condition. Il y a quelque temps j’affichais un bandeau afin de susciter les dons. Je paie les frais d’hébergement et ceux liés à l’achat du nom de domaine, les logiciels ou leurs mises à jour. Que dire de mon Mac acheté en 2008, si ce n’est qu’il est vieillissant^[2] ? Je ne demande pas de salaire pour les années passées à bâtir Ralentir travaux, mais je veux bien un peu d’aide pour continuer l’œuvre. Or ces dons, malgré la promesse que pouvaient constituer les milliers de visites quotidiennes^[3], se sont montrés largement insuffisants^[4]. En un an, à peine de quoi acheter InDesign ou un logiciel de ce type…

J’ai fait mes calculs. J’aurais besoin de 2000 à 2500 € pour acheter diverses choses (nouvel ordinateur, un micro, quelques logiciels, etc.). Une telle somme est donc la condition du changement de licence. Cela en vaut-il la peine ? J’avoue que je suis assez curieux de le découvrir. Peut-être cette demande fera-t-elle un joli flop. En ce cas, la question de la licence ne taraude que moi.

Toujours est-il que nombre de sites recourent annuellement aux dons. Je m’en remets donc à ce principe. Et encore ! je n’attends même pas une cotisation annuelle, mais celle de sept ans passés à construire le site et plus encore, puisque je n’entends pas m’arrêter là (le manuel de 5e est déjà en chantier).

Bref, il ne reste plus qu’à organiser ce financement, mais vous pouvez d’ores et déjà faire un don sur Ralentir travaux en cliquant sur la bannière du haut de chaque page.

Passé le seuil financier susmentionné, Ralentir travaux (tout : le site, les manuels) devient libre.

Si les abeilles disparaissaient de la surface du globe, l’homme n’aurait plus que quatre années à vivre, estiment certains apiculteurs.

Or on assiste depuis une décennie à un phénomène inquiétant en Europe : le syndrome d’effondrement des colonies d’abeilles.

Et si le Libre permettait d’améliorer la situation en rendant plus accessible la création de ruches ?

Tel est, en gros résumé, l’objectif principal du projet Open Source Beehives qui propose, entre autres choses, des plans de ruches à monter soi-même sous licence libre (CC By-SA).

Un réseau intelligent de ruches open source peut-il stopper l’apocalypse chez les abeilles ?

Can A Smart Beehive Network Of Open-Source Hives Help Stop The Bee Apocalypse?

Ben Schiller – 18 novembre 2013 – FastCoExist.com
(Traduction : goofy, ardeur, Llu, KoS, Asta, Penguin, Llu + anonymes)

Le projet Open Source Beehives (NdT : Ruches Open Source) vise à ouvrir la voie à l’apiculture à la maison, avec des plans de ruche simples et bon marché. Les abeilles mourant par millions, il faut propager l’information.

Des millions d’abeilles sont mortes — et c’est un vrai problème car nous en avons vraiment besoin. Une centaine de cultures agricoles (d’une valeur estimée à 30 milliards de dollars) dépendent des abeilles pour la pollinisation, sans compter qu’en bénéficient également toutes sortes d’animaux et de plantes. Nous ne pouvons pas vivre sans abeilles.

Les causes de ce syndrome d’effondrement des colonies d’abeilles (appelé Colony Collapse Disorder en anglais, ou CCD) n’ont pas encore été clairement établies, bien qu’il existe deux suspects principaux, selon une étude récente de l’USDA (NdT : United States Department of Agriculture, le Département de l’Agriculture des États-Unis). Un coupable potentiel est un acarien parasite appelé Varroa destructor, qui suce un fluide du système circulatoire des abeilles et qui porte un virus. L’autre suspect est l’augmentation de l’utilisation d’une classe de pesticide appelée néonicotinoïde. Depuis 2006, époque où les néonicotinoïdes ont commencé à être utilisés largement, les apiculteurs ont signalé qu’ils avaient perdu de 30 % à 90 % de leurs ruches.

Quelle que soit la cause, les agriculteurs vont devoir reconstituer la population d’abeilles, ce qui implique plus de ruches et davantage d’apiculteurs. Le projet Open Source Beehives espère y parvenir en diffusant des plans de ruches simples et bon marché pour qu’il soit facile à n’importe qui de fabriquer la sienne, et encourager la collaboration entre les concepteurs, les techniciens, les chercheurs et les amoureux des abeilles. Pour l’instant, il existe deux modèles : le Colorado Top Bar (dépôt sur GitHub) et le Warré (dépôt sur GitHub). Les équipes à l’origine de ces plans travaillent constamment sur des améliorations.

« Ce plan, facilement transportable, peut être réalisé à partir d’une simple planche de contre-plaqué et s’assemble en quelques minutes sans vis ni colle, comme une Wikihouse pour abeilles » déclare Tristan Copley Smith, de Open Tech Forever, un groupe qui diffuse la technologie open source. Open Tech Forever a imaginé le concept de ruche open source à peu près au même moment qu’un autre groupe, le Fab Lab de Barcelone, l’un et l’autre espèrent désormais impliquer d’autres personnes.

Outre la propagation de ruches bon marché, leur but est d’améliorer la surveillance des abeillles. Ils appellent tous les deux à la conception de capteurs bon marché, pour mesurer l’humidité, la température et d’autres paramètres. Cela aidera les apiculteurs à suivre la santé des colonies et les chercheurs à en apprendre davantage sur ce qui se passe réellement à l’intérieur de la ruche. La version Warré est déjà installée à différents endroits, les capteurs ont été testés à Barcelone, Paris et Bruxelles. Vous pouvez en découvrir davantage sur cette technologie ici :

« Notre objectif est de créer un réseau maillé de colonies intelligentes, qui crée des données ouvertes, partagées sur la plateforme Smart Citizen pour étudier le syndrome d’effondrement et ses causes », explique Colpey Smith. « Nous voulons encourager et faciliter l’apiculture à la maison, tout en éduquant les apiculteurs aux bonnes pratiques et à la création de systèmes d’alerte automatisés ».

Dans cette lettre ouverte du projet Open Source Beehives, vous trouverez plus d’informations sur leurs plans et comment vous investir. « Nous sommes à la recherche de collaborateurs intéressés pour tester nos ruches et nos capteurs avec des colonies actives, si possible dans l’hémisphère sud où c’est actuellement le printemps » dit Copley Smith. « Nous aimerions faire un maximum de tests avant de lancer une campagne Kickstarter en janvier. »

Il y a vingt ans, Daniel Ichbiah écrivait :

La connaissance planétaire est à la portée de votre micro-ordinateur. Des bibliothèques bourrées à craquer de littérature, images et sons. Des plus beaux tableaux du musée du Louvre jusqu’à la plastique de Cindy Crawford en passant par des mélopées new age inédites, des extraits de Thelonious Monk ou l’intégrale des Fables d’Ésope. Un geyser d’informations indescriptible. Avec la possibilité de communiquer avec des milliers de passionnés du même sujet, d’échanger idées, documents, clips vidéo… Il ne s’agit pas d’un rêve éveillé. Cela ne se passe pas en 2020, ni même en 2010 ! Vous pouvez l’avoir chez vous en 1994. Il s’agit d’Internet, le réseau qui regroupe déjà trente millions de branchés du monde entier.

Aujourd’hui… le même enthousiaste d’alors publie un pamphlet pour dénoncer la confiscation de nos biens culturels par les nouvelles superpuissances.

Aujourd’hui… ou plutôt non, c’est déjà hier que pour une poignée de dollars Google s’est approprié la culture mondiale. C’est hier que nous avons vu le mouvement inéluctable par lequel les éditeurs finissent par passer des accords de numérisation des imprimés avec Google. Et c’est bien cette année qu’a éclaté le scandale de la numérisation concédée par la BNF (oui, la Bibliothèque Nationale de France !) à des opérateurs privés qui mettent ainsi la main sur le domaine public.

Dans ce contexte, la décision de la Bibliothèque Nationale norvégienne semble d’une audace inouïe, alors qu’on devrait la considérer comme allant de soi : donner l’accès numérique à leur culture à tous les citoyens devrait être un principe partagé. Même en France.

Lire une page à la plage… (Photo mikemol– CC BY 2.0)

La Norvège s’apprête à numériser tous les livres en norvégien, et autorisera les adresses IP norvégiennes à les lire tous, quel que soit le copyright

Article original du magazine Techdirt

Traduction Framalang : audionuma, sinma, goofy, KoS, Penguin, peupleLà, Sky, lamessen

Voici une nouvelle plutôt étonnante qui nous vient de Norvège :

La Bibliothèque Nationale de Norvège prévoit la numérisation de tous les livres d’ici le milieu des années 2020. Oui, tous. Tous les livres. Du moins les livres en norvégien. Des centaines de milliers de livres. Chacun des livres du fonds de la Bibliothèque Nationale.

Bon, dans n’importe quel pays normal — appelons « normal » un pays où le copyright a atteint des sommets de démence monopolistique —, si lesdits livres étaient encore sous copyright, et à supposer que leurs éditeurs en aient au préalable autorisé une version numérique, on ne pourrait probablement y avoir accès que dans un réduit spécialement conçu à cet usage au troisième sous-sol de la Bibliothèque Nationale, et les lire sur un (petit) écran, sous le regard de gardiens placés de chaque côté, chargés de vérifier qu’aucune copie illégale n’est effectuée.

Voici tout au contraire ce qui va se passer avec la collection numérisée de la Bibliothèque Nationale norvégienne :

Si, selon l’adresse IP de votre machine, vous résidez en Norvège, vous aurez la possibilité d’accéder à tous les ouvrages du XX^e siècle, y compris ceux qui sont encore sous copyright. Les œuvres hors copyright, quelle que soit la période, seront accessibles en téléchargement.

Comme le souligne avec humour Alexis C. Madrigal dans son article du magazine The Atlantic, il peut y avoir des conséquences plutôt intéressantes à ces approches de la numérisation si différentes entre la Norvège et les USA :

Imaginez les archéologues numériques du futur tombant sur les vestiges d’une civilisation datant du début du XXI^e siècle, dans un antique data center au fin fond de la toundra en plein réchauffement climatique. Ils fouillent tout cela, trouvent quelques débris de Buzzfeed et de The Atlantic, peut-être un fragment de l’Encyclopaedia Britannica, et puis soudain, brillant comme une pépite au milieu des résidus numériques : une collection complète de littérature norvégienne.

Tout à coup, les Norvégiens deviennent pour les humains du XXVII^e siècle ce que les Grecs de l’Antiquité ont été pour notre Renaissance. Tous les couples des colonies spatiales se mettent à donner à leurs enfants des prénoms comme Per ou Henrik, Amalie ou Sigrid. La capitale de notre nouvelle planète d’accueil sera baptisée Oslo.

Voilà ce qui arrive aux pays qui imposent des lois abusives en matière de copyright. Non seulement elles empêchent les artistes d’aujourd’hui de créer leurs œuvres en s’appuyant sur celles de leurs prédécesseurs — une pratique qui était habituelle pendant des siècles avant que n’apparaissent récemment les monopoles intellectuels — mais ces lois vont jusqu’à mettre en péril la conservation et la transmission de cultures entières, tout cela en raison du refus des éditeurs d’adapter la règlementation du copyright à notre temps, c’est-à-dire d’autoriser la numérisation à grande échelle et la diffusion à la façon dont la Norvège l’envisage.

 – – –
En savoir plus : La page de présentation de la politique de numérisation sur le site de la National Library of Norway

La Banque de France a publié ce jeudi 5 décembre une note sur le bitcoin « monnaie non régulée qui n’offre aucune garantie ». Cela a été repris dans tous nos grand médias, d’autant que la banque centrale chinoise s’y est mise à son tour, interdisant officiellement à ses institutions d’utiliser cette drôle de monnaie (conséquence directe : chute momentanée de son cours en yuans de près de 35%).

Or, quand on lit les articles de la presse nationale, on est frappé par le long exposé anxiogène des risques que représente bitcoin, reprenant ainsi les arguments dans la Banque de France, trop rarement (litote) contrebalancé par ses avantages.

Or ils sont nombreux, à commencer par, tiens, tiens, pouvoir (enfin) se passer des banques… CQFD

Maintenant que le bitcoin a grandi et que de plus en plus d’organismes l’acceptent comme mode de paiement, la guerre est ouvertement déclarée. Parce que se passer des banques, c’est tout simplement révolutionnaire par les temps qui courent où l’économique a pris le pas sur la politique…

PS tout à fait personnel : Les banques (avec la complicité des gouvernements) ont quand même beau jeu de nous faire la leçon après la crise des subprimes. 2 infos récentes du mois dernier qui intéressent beaucoup moins les médias que les pseudo-problèmes sociétaux (et surtout pas sociaux) du mariage, du racisme ou de la prostitution : une rallonge de 1,5 milliard d’euros aux collectivités pour qu’elles renoncent à tout contentieux contre les banques et Euribor, Libor : la manipulation des taux coûtera 1,7 milliard d’euros d’amende à six banques européennes (mais minimisées selon leur ordre d’arrivée). On nous prend vraiment pour des cons !

Pourquoi les banques déclarent la guerre au Bitcoin

Why Banks are Declaring War on Bitcoin

Mark Maunder – 5 décembre 2013 – Blog personnel
(Traduction : Goofy, crendipt, Shanx, Jérémie, Jérémie, Tr4sK, Asta, Omegax, Sky + anonymes)

Et si nous vivions dans un monde où toutes les transactions se faisaient de personne à personne et ne coûtaient quasiment rien ?

Et si nous vivions dans un monde où la valeur de l’argent épargné augmentait petit à petit, non pas grâce aux intérêts, mais simplement parce que, avec le temps qui passe, vous pouvez acheter plus de trucs avec la même somme ?

Et si s’endetter devenait une très mauvaise idée parce que, si vous détenez 10 unités de monnaie aujourd’hui, et que la valeur de celle-ci augmente lentement, alors vous devrez graduellement de plus en plus d’argent ? Ainsi, personne ne voudrait s’endetter.

Et si s’endetter devenait une très mauvaise idée parce qu’épargner devient une très bonne idée, parce que quelle que soit la somme que vous possédez, elle vaut de plus en plus à mesure que le temps passe ? Elle augmente non pas parce qu’elle est exploitée par une banque, mais parce que plus de gens veulent la même somme.

C’est le monde vers lequel nous nous dirigeons, car c’est ainsi que Bitcoin fonctionne. Un univers en parallèle des banques qui laisse celles-ci en position de faiblesse.

Bitcoin n’est pas une banque centrale où l’afflux d’argent peut-être régulé par une charte, charte pouvant être contrôlée par les lobbys et manipulée par les grands industriels. L’apport de la monnaie Bitcoin est gouverné par un algorithme, et cet algorithme assure que le Bitcoin sera toujours sujet à la déflation. Cela signifie que le rythme auquel la monnaie Bitcoin est créée ralentira progressivement pour complètement s’arrêter tôt ou tard. Par conséquent, aussi longtemps que l’activité économique (qui dicte la demande monétaire) augmente doucement, cette devise vaudra progressivement un peu plus.

Traditionnellement, la déflation, pendant laquelle la monnaie vaut plus et les prix des denrées et services chutent, est le pire cauchemar des économistes. Ceci parce que lorsque vous êtes en déflation, les salaires baissent. La plupart des consommateurs sont endettés d’une façon ou d’une autre. Si vous devez 100 000 dollars pour votre maison et que votre salaire passe de 50 000 à 30 000 dollars par an, vous avez un gros problème. Vous commencez à dépenser moins, l’activité économique ralentit et cela alimente une déflation plus forte. Une économie peut ainsi entrer dans une spirale déflationniste.

Dans l’économie Bitcoin, la déflation est au cœur de la devise. Cela signifie que c’est une très mauvaise idée d’emprunter de l’argent en Bitcoin parce que vous devrez de plus en plus au fur et à mesure que le temps passe et que vous ne serez jamais en mesure de le rembourser. En revanche, si vous ne vous endettez jamais et que vous décidez d’épargner, l’argent que vous conservez vaudra un peu plus chaque jour.

C’est un cauchemar pour les banques parce qu’elles veulent que vous empruntiez toujours plus afin que vous payiez des intérêts sur vos emprunts. Elles veulent ainsi maintenir un écart entre les intérêts que vous payez, et ceux qu’elles paient pour emprunter l’argent qu’elles vous ont prêté.

C’est un plus grand cauchemar encore parce que les banques veulent que vous ouvriez un compte d’épargne et y déposiez de l’argent afin que vous puissiez percevoir des intérêts dessus et rester en phase avec l’inflation. Si vous ne déposez pas suffisamment d’argent à la banque dans un contexte inflationniste, votre argent perdra de la valeur. Mais si vous déposez de l’argent dans une banque, elle l’investira à votre place, percevra des intérêts, vous reversera des intérêts à un taux plus bas et conservera la différence. Donc si vous n’alimentez pas un compte d’épargne parce que votre argent prend de la valeur automatiquement par la déflation, les banques perdent.

Pour résumer, vous n’empruntez pas et vous ne déposez pas votre argent dans un compte d’épargne ou un compte d’investissement pour suivre le rythme de l’inflation, par conséquent les banques perdent les revenus des prêts et des dépôts qui leur permettent d’emprunter peu et de prêter beaucoup, qui est un de leurs modèles économiques de base.

Donc, que reste-t-il à faire aux banques ? Eh bien, elles pourraient seulement passer leur temps à faciliter les transactions comme le font Visa, Mastercard, le réseau SWIFT, Western Union Money Transfer et d’autres. Mais on a déjà dit que les transactions Bitcoin sont faites de personne à personne et coûtent très peu. Les banques ne perçoivent même pas ce revenu.

Et c’est pour cela que les banques travaillent très, très dur en coulisse pour essayer de tuer Bitcoin avant qu’il ne les tue. Voilà quelques exemples :

• Capital One ferme les comptes bancaires si Bitcoin est mentionné.
• Les comptes Coinabul ont été fermés par Chase et US Bank parce qu’ils vendaient des Bitcoins.
• La plupart des banques canadiennes ”Big 6” ont fermé les comptes bancaires de quiconque facilitait l’échange de Bitcoin.
• Commonwealth bank, la plus grande banque australienne, a fermé le compte de Coinjar pour avoir traité des transactions par Bitcoin.
• De même, certains individus ont déclaré que leur compte bancaire a été fermé pour avoir simplement transféré de l’argent de leur compte personnel pour acheter des Bitcoins.
• Citi Foundation, la branche de bienfaisance de Citi Group, a investi dans une étude qui essayait de lier Bitcoin à la récente arrestation du créateur du marché noir Silk Road. L’étude a été discréditée en quelques minutes par la publication d’un membre de Reddit et plus tard retirée.

Les banques qui sont le plus effrayées sont celles qui se développent dans les pays comme l’Afrique du Sud, où les frais de transactions sont bien plus élevés que dans les pays développés. Ces frais sont élevés car les déposants ont tendance à être en moins bonne santé et épargnent de plus petites sommes, donc pour contrebalancer le fait qu’il y ait moins d’argent pour que les banques puissent investir, celles-ci assomment leurs clients avec de gros frais de transactions. Les pays développés ont tendance à avoir de nombreuses populations migrantes qui envoient de l’argent dans leurs familles à l’aide de services tels que Instant Money qui permet l’envoi d’un code par SMS à une personne qui peut ensuite aller dans un supermarché local afin de recevoir la somme associée. Les frais de transactions pour de tels services sont élevés et si Bitcoin devient un mode de transfert et de stockage d’argent plus efficace en terme de coûts, les banques des pays développés vont perdre un business très lucratif.

La guerre contre le Bitcoin vient tout juste de commencer. Les banques traditionnelles ont un gros stock de munitions pour la mener car leurs munitions c’est l’argent.

L’Internet des débuts était plus libre que celui d’aujourd’hui. Les monnaies chiffrées sont peut-être plus libres aujourd’hui qu’elles ne le seront jamais.

Annexe

On pourra relire à l’occasion ces 3 articles du Framablog :

• Bitcoin libérera-t-il la monnaie à l’échelle d’Internet ?
• Comment le Bitcoin peut faire tomber les États-Unis d’Amérique
• La monnaie électronique, 33 questions à Lionel Dricot (alias Ploum)

À l’occasion de notre présence lors des RMLLd sur l’île de la Réunion, voir cet article, nous avons eu l’occasion de rencontrer Jean-Noël Rouchon, qui fait partie de ces « artisans du libre » de plus en plus nombreux, sa structure (Mithril) proposant de nombreux services autour du logiciel libre.

Mais Jean-Noël est aussi le développeur du logiciel de gestion pour le suivi d’exploitations agricoles Agritux. Et l’histoire de la naissance de ce logiciel étant plutôt intéressante, nous souhaitions vous la faire partager.

Bonjour Jean-Noël, peux-tu te présenter ?

Je m’appelle Jean-Noël Rouchon, j’ai 32 ans et je vis à Saint-Joseph, sur l’île de la Réunion. Je suis passionné d’informatique depuis tout jeune ce qui m’a poussé à en faire mon métier. J’ai découvert Linux et monde du logiciel libre quand j’étais étudiant en 2000 avec une mandrake (la 7.2 si je me souviens bien) et j’ai très vite été happé par cet univers-là et la philosophie qui en découle.

Après ma maîtrise, j’ai travaillé pour une entreprise spécialisée dans le logiciel de gestion, mais je ne me trouvais pas à l’aise dans le monde du logiciel propriétaire. J’ai donc fini par créer ma petite entreprise, Mithril Informatique.

Quelles sont les activités principales de Mithril ?

Je travaille sur trois grands axes en même temps :

• la maintenance de parc informatique, il s’agit principalement de mettre en place et de maintenir des serveurs Linux pour diverses utilisations (serveur de fichiers, base de données, mails, contrôleur de domaine, virtualisation, proxy, portail captif, etc.)
• le développement d’applications : je me suis spécialisé dans deux langages, le C et le Ruby. J’utilise principalement le C pour des applications multimédias et le Ruby pour des applications métiers (soit application web, soit interface en Gtk)
• la formation : je complète mon offre par de la formation sur divers sujets (bureautique, distribution Linux, logiciels de gestions, etc.)

L’ensemble des mes prestations est consultable sur le site.

Tu es le développeur d’Agritux, mais… c’est quoi Agritux ?

Agritux est un logiciel de gestion pour le suivi d’exploitations agricoles.

Il permet de faire le suivi par parcelles et par cultures de la production de cultures végétales en gardant une trace des intrants et de la main d’oeuvre utilisée.

Le but étant surtout de pouvoir éditer un « cahier de culture », document officiel qui peut être demandé lors d’un contrôle de l’exploitation par exemple. Il est développé en Ruby avec une interface en Gtk, il fonctionne sous Linux et Windows (et probablement Mac OS aussi mais je n’ai pas eu l’occasion de le tester). Il est bien sûr sous licence libre (GPLv3) et le code source est téléchargeable sur gitorious.

Comment est né ce logiciel ?

L’idée du logiciel a commencé à naître lors des RMLLd de 2011 à St-Joseph. J’ai participé à ces premières Rencontres Mondiales du Logiciel Libre décentralisées en tant que membre d’un GUL de la Réunion (Libre974) et j’ai eu l’occasion de rencontrer pas mal de monde et en particulier plusieurs agriculteurs faisant le parallèle entre les semences libres et le logiciel libre. J’ai pu longuement discuter avec un agriculteur bio, venu là par curiosité.

L’idée du logiciel libre lui a trotté dans la tête un bon moment puisqu’au début de cette année 2013, il me rappelle pour lui installer une distribution Linux sur son ordinateur et pour lui créer un logiciel de suivi d’exploitation agricole, qu’il n’arrive pas à trouver parmi les logiciels libres déjà existants. Les premières lignes de code d’Agritux sont écrites en avril 2013.

J’ai pu constater qu’Agritux interessait pas mal d’agriculteurs (et d’enseignants de lycée agricoles) à la Réunion. Mais sais-tu si le logiciel interesse des publics similaires en métropole ou à l’étranger ? Comment envisages-tu l’avenir d’Agritux ?

Il y a eu en effet un intérêt certain pour Agritux lors des dernières RMLLd, plus que je ne l’imaginais. J’en déduis que ce type de logiciel correspond à un besoin réel de beaucoup d’agriculteurs.

Depuis ces dernières rencontres, j’ai eu plusieurs contacts de la Réunion mais aussi de la métropole et de Madagascar m’apportant des idées pour la suite.

Le logiciel est encore très jeune, et il y a plein de pistes à explorer pour l’améliorer. Dans le désordre :

• les statistiques économiques
• la gestion de l’élevage
• la gestion de la météo
• la gestion de rotation de cultures
• la traduction du logiciel

Pour mutualiser les coûts de développement, je pense essayer de faire financer les futures évolutions en passant par du crowdfunding et en particulier par la plateforme Openfunding qui est spécialisée dans le financement de logiciels libres.

Étant le seul développeur, il n’y a pas pour le moment de communauté autour de Agritux, juste quelques utilisateurs qui me font parfois des remontées par mail, bien qu’un bug tracker soit disponible.

Si d’autres développeurs sont intéressés pour m’aider à faire évoluer Agritux, ils seront accueillis à bras ouverts !

La Réunion, de par son éloignement avec la métropole, est-elle un terrain propice au développement du logiciel libre, ou des structures comme la tienne sont-elles complètement marginales ?

Je ne connais pas bien la situation du développement de logiciels libres en métropole, mais il me semble que la Réunion est plus propice au développement de petits logiciels spécifiques créé par de petites structures. D’abord parce que les entreprises préfèrent généralement avoir à faire à des prestataires locaux et ensuite parce qu’il y a peu de grosses entreprises et donc peu d’intérêt pour de grosses sociétés d’édition de logiciel d’être présentes ici.

Le souci du coup, c’est que nous devons travailler avec plein de petites entreprises, très différentes les unes des autres, ce qui nous oblige à nous diversifier (ou même nous éparpiller dans mon cas ;)).

C’est pour cette raison qu’un groupement de prestataires de logiciels libres a été créé sur l’île. Il s’agit ici de fédérer nos compétences tout en restant indépendants et de proposer un site web répertoriant un maximum de prestations autour des logiciels libres à la Réunion. Ce groupement s’appelle Prestalibre et l’annuaire est disponible sur le site.

Un petit mot pour la fin ?

Concernant Agritux, toutes remontées de bugs, demandes, propositions, critiques (même mauvaises) sont les bienvenues. De même si des personnes sont intéressées pour participer au développement, à la traduction ou aux tests du logiciel, vous pouvez me contacter à mail AT mithril.re. Agritux a besoin de vous ;) !