Et hop, encore un nouveau projet pour le tentaculaire réseau Framasoft ! Il s’appelle Framacalc et il ambitionne de proposer le même service que Framapad mais pour le tableur cette fois.

Pour rappel, Framapad c’est la possibilité de faire du traitement de texte collaborativement en ligne (nous allons du reste vous en proposer une spectaculaire mise à jour très bientôt). Et pour le tableur me direz-vous ? C’est là qu’intervient Framacalc.

Avec Framacalc donc vous vous retrouvez à travailler à plusieurs sur le même tableur toujours accessible sur Internet.

Vous piaffez déjà d’impatience ? Alors rendez-vous tout de suite sur le site dédié pour le tester.

Attention, quand bien même les fonctionnalités tableur sont déjà bien avancées, celles concernant la collaboration et l’exportation sont encore rudimentaires. Ainsi, contrairement à Framapad, on n’est pas capable de savoir qui se cache derrière telle ou telle édition, même si on observe bien les éditions des autres se faire en temps réel. Il n’y a pas non plus encore de fenêtre de chat et l’export ne se fait pour le moment qu’au format HTML.

Il y a encore du boulot donc (mais cela peut déjà convenir pour de nombreuses situations simple et non confidentielles, on pense notamment à l’éducation).

Tout comme Framapad, il y a une solution libre qui se cache derrière. Il s’agit du projet EtherCalc (avec du Node.js sous le capot). Il est déposé ici sur GitHub et, il va sans dire que nous encourageons les installations individuelles car, Framacalc ou Framapad, les projets Framasoft sont aussi voire surtout là pour que le cloud se décentralise librement (et finisse par contrarier ces capteurs de données personnelles que sont Google, Facebook ou Apple).

Avec Framapad + Framacalc, Google Documents n’a qu’à bien se tenir ? Nous n’en sommes pas encore là mais, un jour, qui sait… 🙂

-> Framacalc : Tableur collaboratif en ligne du réseau Framasoft

PS : Nous vous rappelons que ce service libre et gratuit est l’un des nombreux projets du réseau Framasoft qui ne vit que par vos dons. Pour en assurer la pérennité et le développement, merci de soutenir notre association si vous le pouvez/souhaitez.

Avec combien de login et de mots de passe devons-nous jongler dans la journée ?

Beaucoup en effet…

En même encore plus si nous ne les enregistrions pas automatiquement par défaut dans notre machine (avec un gros risque de sécurité). Ou, pire encore, si nous n’avions pas décidé de nous enregistrer sur des services tiers avec notre compte Facebook, Twitter ou Google (avec un énorme risque de se retrouver prisonnier de leurs cages dorées).

À l’heure et à l’ère de la multiplication exponentielle des services Web, la question de l’identification devient cruciale et problématique.

Nous avons besoin d’un système global pratique, sécurisé et auquel nous pourrions faire confiance.. C’est ce que propose Persona, le nouveau système d’authentification de Mozilla.

Il n’est pas forcément aisé de le comprendre de l’intérieur mais c’est pour que ce soit le plus simple possible du côté de l’utilisateur 🙂

Pourquoi Persona de Mozilla apporte la bonne réponse à la question de l’identification

Why Mozilla Persona Is the Right Answer to the Question of Identity

David Somers – 1er octobre 2012 – Blog personnel
(Traduction : greygjhart, ZeHiro, Yho, Evpok, aKa, FredB, Simounet, Mounou, Coyau, Isdf, peupleLa, thot, HgO, salelodenouye)

Le 27 septembre 2012, Mozilla a lancé la première version bêta de Persona. Persona est un système d’authentification d’apparence similaire à OpenID et oAuth, mais qui s’en distingue d’un point de vue technique et fonctionnel.

Nous avons eu la chance de nous associer à Mozilla pour créer la version bêta de The Times Crosswords lors du lancement du Mozilla App Store. Nous sommes ainsi l’un des premiers services tiers à avoir intégré Persona de Mozilla (qui s’appelait encore BrowserID à l’époque), Mozilla en a même fait une vidéo.

Pourquoi un nouveau système d’identification ?

Passons en revue quelques-uns des problèmes d’OpenID et oAuth :

• OpenID utilise des URLs en tant qu’identifiants.
  • Même si fondamentalement l’idée est bonne, cela peut être déroutant pour les utilisateurs. Le risque ? Se voir demander de « choisir un service d’identification » comme Google, LiveJournal, etc. alors qu’en fait vous n’êtes pas du tout en train de vous identifier avec eux.
  • La plupart des sites voudraient que vous leur fournissiez au moins une adresse email pour pouvoir vous contacter. Il faudra donc presque toujours en passer par une étape supplémentaire lors de la première connexion.
• OpenID est un système de connexion incohérent : il faut que vous quittiez complètement le site où vous étiez puis y retourner après vous être authentifié avec un outil tiers. On peut en dire autant d’oAuth (même si certaines de ses implémentations permettent une connexion en un seul clic, comme Twitter).
• oAuth est complexe à implémenter pour les développeurs : cela nécessite le stockage et la gestion de jetons . Il y a également plusieurs versions du protocole, et parfois une authentification supplémentaire (les jetons de rafraîchissement de Google par exemple).
• Tant OpenId qu’oAuth permettent à votre service d’identification (qu’il s’agisse de Google, Facebook, Twitter) de pister chaque site sur lequel vous vous inscrivez.

Comment Persona et BrowserID résolvent-ils ces problèmes ?

• Ils utilisent les adresses email au lieu des URLs. Non seulement les adresses email sont plus faciles à mémoriser, mais vous pouvez aussi utiliser une adresse email par identité ; par exemple votre adresse email de travail ou personnelle.
• Mozilla Persona utilise une « popup », ainsi vous ne quittez pas le site internet sur lequel vous êtes. Mieux encore, si le navigateur supporte le protocole BrowserID, vous n’aurez rien à faire.
• Persona/BrowserID est en général géré par les navigateurs (que ce soit en JavaScript ou en natif) et en tant que développeur vous n’aurez qu’à vérifier que l’utilisateur est bien celui qu’il dit être. Ceci doit être fait sur votre propre serveur, mais peut être implémenté avec à peine plus qu’une requête cURL.
• En plaçant le navigateur au centre du processus d’authentification, les services d’identification ne peuvent pas tracer les visites des utilisateurs, mais ils permettent tout de même aux sites visités de vérifier leur identité. On y parvient en incorporant une cryptographie à clé publique dans le protocole.

Bien entendu, Persona ne vous sera d’aucune utilité quand vous aurez besoin d’accéder à des ressources tierces authentifiées comme vos données Twitter, mais ce n’est pas son rôle. Et c’est la ligne de démarcation qu’il faut entre votre identité et vos données.

Comment ça marche ?

Ce qu’il y a de bien avec la solution Persona de Mozilla, c’est qu’elle se décompose en deux niveaux. Le premier est le service BrowserID amorcé : Persona. Le second est le protocole d’identification en lui-même : BrowserID. En concevant ainsi l’amorçage du protocole, Mozilla évite les problèmes de prise en main et le rend attractif pour les développeurs.

BrowserID

Dans un monde idéal où BrowserID serait massivement adopté, voici ce qui se passerait au moment où vous voulez vous connecter à un site Web :

1. Vous cliquez sur « Connexion ».
2. Votre navigateur vous demande avec quelle adresse email vous voulez vous identifier.
3. Vous êtes connecté.

Et voici ce qui se passerait dans le détail :

1. Vous cliquez sur « Connexion » sur un site désigné ci-dessous par Service Tiers.
2. Votre navigateur vous demande avec quelle adresse email vous voulez vous identifier.
3. Votre navigateur contacte votre Service d’Identification (désigné dans la suite par S.I, par exemple Gmail) en utilisant vos identifiants (adresse email et clé publique) et demande un certificat signé.
4. Optionnel : Votre S.I. vous demande de vous inscrire (avec les habituels identifiant/mot de passe pour cela).
5. Votre S.I. envoie à votre navigateur un certificat signé qui dure 24 heures.
6. Votre navigateur génère une « Assertion ». Elle fait preuve que vous êtes le légitime détenteur de votre adresse email : générée à partir de votre clé privée (stockée dans le navigateur), elle contient le domaine du site pour lequel vous vous authentifiez ainsi qu’une date d’expiration.
7. L’assertion et votre certificat signé sont tous deux envoyés au Service Tiers.
8. À l’aide de votre clé publique (fournie par votre navigateur), le Service Tiers vérifie que votre Assertion semble correcte.
9. Le Service Tiers demande la clé publique de votre S.I. (mais n’envoie aucune information sur l’utilisateur) et s’en sert pour vérifier que le certificat, envoyé par votre navigateur, est également correct.
10. Vous êtes connecté.

Plutôt long le processus ! Mais au moins, il est décentralisé, sécurisé et respecte votre vie privée (votre S.I. ne peut pas savoir quels sites vous êtes en train de visiter).

Si c’était la seule façon d’implémenter BrowserID, son déploiement serait compromis. C’est là que Persona entre en piste.

Mozilla Persona

Mozilla Persona est une application tierce qui fournit une interface de programmation (API) REST plutôt cool pour cacher toute cette cryptographie à clé publique.

• Persona gère la vérification via les services d’identification et agit également comme service d’identification à part entière pour les services tiers qui n’en possèdent pas (ce qui est la cas de tous les fournisseurs d’adresses email actuellement).
• Persona fournit une interface de programmation de type REST pour valider chaque assertion.

En traitant toute la partie cryptographie, implémenter BrowserID ne requiert que quelques lignes de JavaScript (le bouton de login et les callbacks en POST pour envoyer l’assertion au serveur) et une requête cURL (pour valider l’assertion).

Envie de l’utiliser ?

Commencez par jeter un œil sur le Persona Quick Setup (NdT : Installer Rapidement Persona) qui vous fournira les instructions pour ajouter Persona à votre site Web, avec des exemples en JavaScript et une implémentation en Python de la vérification de l’assertion (c’est vraiment très simple). Le tout en une soixantaine de lignes de code.

Nous vous suggérons ensuite de consulter le guide des bonnes pratiques pour vous assurer que vous ne faites rien de travers.

NdT : En annexe deux liens de mozilliens francophones :

• BrowserID par Pierre Rudloff
• BrowserID, implémentation en Java côté serveur par Flaburgan

En 2003 naissait le projet Wikitravel qui est un peu au voyage ce que Wikipédia est à l’encyclopédie : une rédaction collaborative de guides touristiques (pays, ville, etc.), multilingues, sous licence libre et sur un wiki.

Le fait est que cela a plutôt bien marché (exemple avec Paris). Ils en ont même fait de vrais guides papiers.

Sauf que jetez un œil au graphique ci-dessous et vous comprendrez vite que son histoire n’a pas été un long fleuve tranquille. De Wikitravel, on est passé à Wikivoyage pour espérer en arriver aujourd’hui à Wikimedia Travel. C’est tout le charme de la licence libre (en l’occurrence la CC By-Sa) et de ses forks possibles lorsque le projet prend, selon certains, une mauvaise direction.

C’est de cette histoire (à rebondissements) dont il est question dans l’article ci-dessous.

Remarque : On notera que son auteur (créateur de l’application WikiSherpa) est peut-être trop pessimiste car il se pourrait bien qu’on connaisse un happy ending grâce au concours de Wikimedia. Et puis, sans licence libre, on aurait été dès le départ totalement bloqué.

Tirer la leçon de la dramatique et lente agonie de Wikitravel

Lessons From The Dramatic Slow-Motion Death Of Wikitravel

Jon Evans – 29 septembre 2012 – TechCrunch
(Traduction Framalang : @ali0une, Pandark, aKa, LuD-up, @jfomhover, ali0une, lgodard, Karma-sama, martinien, senshu)

Il était une fois, en 2003, deux entrepreneurs avec un rêve. Ils s’appelaient Evan Prodromou et Michele Ann Jenkins, et ils ont rêvé d’un guide de voyage mondial édité collaborativement — un Wikipedia pour les voyages, si vous préférez. Ainsi, il créèrent Wikitravel. Et ils ont fait mentir l’expression anglaise « Lead zeppelin » qui sous-entend que le projet n’aurait jamais pu décoller. Deux ans plus tard, ils furent racheter pour 1,7 million de dollars (~1,3 million d’euros) par une compagnie nommée Internet Brands, pas mal d’argent pour ces nombreuses journées perdues avant que la startup ne devienne populaire. Et Wikitravel prospéra , et en prenant du recul, c’était plutôt bon.

Jusqu’à ce que le paradis s’en vienne à côtoyer les enfers…

Pendant six ans Wikitravel fonctionna bien. Il y avait bien la présence de quelques publicités mais rien d’intrusif. La plateforme technique sur laquelle il tournait prenait de l’âge et avait ses défauts, mais elle fonctionnait, et c’est tout ce qui compte, n’est-ce pas ?

En 2006 cependant, les administrateurs italiens et allemands (bénévoles et indépendants qui réparaient le site, éliminaient le spam, éditaient structure et langage, et le rendaient pour ainsi dire utilisable) ont forké toutes les pages du site en ces langues pour s’en aller migrer vers un nouveau site, appelé Wikivoyage, principalement à cause de la publicité placée par Internet Brands. C’était tout à fait légal parce que tout le contenu de Wikitravel est sous licence Creative-Commons. Et cela n’affecta pas vraiment Wikitravel (et en rien sa partie principale anglaise) qui continua à attirer un demi-million de visiteurs par mois. Son travail de guide pour la planète entière devenait meilleur de jour en jour…

Mais, il y a quelques mois, les administrateurs de Wikitravel en ont eu assez. Ils ont d’abord constaté l’inclusion de nouvelles publicités encore plus invasives et surtout ils ont perdu patience face à leurs demandes répétées de mises à jour techniques restées sans réponses. D’autant plus que quand Internet Brands se décida enfin à effectuer ces mises à jour la plateforme se retrouva toute pleine de bugs ! En conséquence de quoi les administrateurs de Wikitravel baissèrent les bras et voyagèrent à travers l’Internet jusqu’à cette oasis de contenu libre qui s’appelle la Wikimedia Foundation pour lui dire en substance ceci : « Nous n’en pouvons plus de notre logement actuel. Voudriez-vous héberger un site de voyage ? » La Wikimedia Foundation réfléchit, et décida finalement de répondre par l’affirmative.

Et puis l’enfer des procédures judiciaires s’est déchaîné.

Se sentant menacé par ce fork d’un Wikitravel hébergé par Wikimédia, Interned Brands, après avoir semble-t-il initialement proposé un partenariat, « intenta des poursuites contre les contributeurs bénévoles James Heilman et Ryan Hollliday, pour avoir utilisé le mot « Wikitravel » dans la phrase « Communauté Wikitravel » lors de la communication du fork », nous dit David Gerard. En réponse, la Wikimédia Fondation a elle_même intenté une poursuite stratégique contre la mobilisation publique et demandé des explications devant les tribunaux.

Nous allons laisser les sérieux avocats décider du sort de cette aventure. Je veux juste tirer quelques leçons personnelles de cette débâcle :

• N’irritez pas vos utilisateurs les plus fidèles et actifs (NdT : power users). Vous pensez peut-être que la masse globale de vos utilisateurs est ce qui importe le plus, mais ce sont avant tout ces utilisateurs là qui fournissent avec passion le gros du travail. Ils sont pour ainsi dire le cœur et l’âme de votre site, et s’ils partent vous aurez de gros ennuis.
• Ne retardez pas le paiement de votre dette technique. Comme la plupart des dettes, elle subit des interêts composés exponentiels 🙂 Et vous ne connaissez pas son taux d’intérêt jusqu’à ce que vous ayez commencé à la rembourser. Je pense qui si Internet Brands avait géré Wikitravel avec plus de considération et de compétences techniques, le fork n’aurait jamais eu lieu.
• Ne poursuivez pas vos utilisateurs en justice dans un moment d’aigreur et de dépit. Vraiment. Ne le faites pas. N’avons nous donc rien appris de la RIAA (NdT : à comparer avec notre Hadopi) ? Respirez profondément, prenez un calmant, et détendez-vous. En effet, outre la question d’ordre moral, à partir du moment où vous poursuivez vos utilisateurs, vous perdez toute crédibilité aux yeux d’une fraction énorme de l’Internet. Et la crédibilité compte. Hélas, beaucoup de gens ne le réalisent pas, jusqu’à ce qu’ils perdent la leur.

Une version provisoire du nouveau guide de voyage anglophone est maintenant disponible. En attendant la suite…

Lorsque vous parcourez un article de l’encyclopédie libre Wikipédia, vous pouvez bien évidemment le lire, mais aussi écrire (le fameux bouton « Modifier ») et consulter tout son historique, sans oublier converser autour avec les autres contributeurs (lien « Discussion »). Il en va de même avec tout logiciel libre déposé sur une plateforme collaborative comme celle de GitHub par exemple (dont l’approche et les fonctionnalités sociales ont donné un coup de vieux à Sourceforge).

Il y a là une manière bien spécifique de fonctionner et une invitation à s’impliquer.

Dans la mesure ou Wikipédia ou GNU/Linux sont d’incontestables réussites, l’un des plus célèbres penseurs du Net, Clay Shirky, s’est récemment demandé, au cours d’une brillante intervention TED, si on ne pouvait pas fortement s’en inspirer pour faire évoluer la politique en générale et l’élaboration de nos lois en particulier.

Ce que l’on pourrait résumer également ainsi : est-ce que le logiciel libre a des choses à dire, voire à enseigner, à la démocratie ?

Peut-on améliorer la politique avec les outils du logiciel libre ?

Could we use open-source tools to improve politics?

Mathew Ingram – 29 septembre 2012 – Gigaom.com
(Traduction : Lamessen, Barbidule, Evpok, David, peupleLa)

Les principes du logiciel libre ont contribué à créer de nombreux logiciels efficients et utiles, y compris le système d’exploitation GNU/Linux et la surpuissante ressource que représente Wikipédia. Cette même approche pourrait-elle être utilisée pour ouvrir le processus de création des lois ? Clay Shirky assure que c’est possible.

La philosophie du logiciel libre a permis entre autres de construire un système d’exploitation et une encyclopédie collaborative de grande qualité. Pourrait-on en faire de même avec la législation et la politique ? C’est ce que le théoricien de la communication Clay Shirky a proposé dans une récente et remarquée conférence TED (Technologie Entertainment Design) à Edimbourg. L’idée est alléchante, employer les méthodes de GNU/Linux et Wikipédia pour rendre les gouvernements plus ouverts et impliquer davantage les concitoyens, mais est-ce véritablement transposable ? L’écriture de logiciels et de services Web est très différente de celle des lois, et l’histoire du logiciel libre a connu son lot de guerres quasi-religieuses. Mais c’est peut-être notre meilleur espoir.

Après avoir fait une sorte de tour d’horizon du mouvement open source, en accordant la part belle à GNU/Linux, Shirky a consacré une grande partie de son discours à Github, plateforme collaborative et sociale de dépôt de logiciels qui permet à n’importe qui d’éditer, de « forker » en créant sa propre version, et de suivre les changement que font les autres. De GitHub à l’idée de législation collaborative, il n’y a qu’un pas. Et c’est ce que Shirky semble avoir à l’esprit. Il y a déjà eu quelques tentatives de réalisation directement via GitHub. Ainsi un développeur allemand a, par exemple, déposé l’intégralité des lois allemandes sur la plateforme. De cette façon, les citoyens peuvent recommander et suivre les changements.

C’est séduisant sur le papier : une simple plateforme logicielle dédiée à la collaboration pourrait changer la façon dont on développe et met en oeuvre les lois. Mais est-ce réaliste ?

Beaucoup de sceptiques disaient au départ que Wikipédia n’avait aucune chance de marcher. Pourtant elle est bel et bien là et sa réputation et fiabilité sont excellentes, malgré quelques ratés comme l’incident récent impliquant l’auteur Philip Roth. Il est vrai cependant que de nombreux critiques pensent que la « cabale » des éditeurs qui contrôlent l’encyclopédie collaborative a trop de pouvoir.

Force est de reconnaître que le fonctionnement des gouvernements reste de toutes les façons trop opaque à l’ère d’Internet, et donc que Github ne peut pas faire empirer les choses. D’ailleurs Shirky n’est pas le seul à le penser : le développeur Abe Voelker a proposé un « Github pour lois » qui propose exactement la même approche pour concevoir des lois collaborativement. D’autres expériences basées sur ces mêmes idées d’ouverture ont déjà eu lieu en Finlande, Irlande et surtout en Islande avec la rédaction collective de sa nouvelle Constitution (NdT : lire à ce sujet L’Islande, la crise, la révolution et moi et on notera en France l’initiative d’Étienne Chouard avec sa Constitution nationale d’origine citoyenne sur un wiki).

Un des problèmes posés par la transposition d’une solution technique comme Github à un processus culturel et politique de grande ampleur, c’est que créer des lois, même mineures, est très différent de bidouiller un bout de code afin que GNU/Linux puisse reproduire les styles de polices de caractères Windows, ou encore modifier l’article sur George Bush dans Wikipédia (sachant que ces deux exemples en apparence inoffensifs ont donné lieu à de vives polémiques au sein de leur communauté respective). Comment peut-on dès lors espérer que des politiciens puissent, dans les faits, se servir d’un processus similaire pour changer la manière dont fonctionne le gouvernement, le parlement et ses lois ? Comme le suggère Shirky dans sa conférence, il y a une bureaucratie bien installée qui n’a probablement aucun intérêt à renoncer à ce contrôle au profit du bon peuple.

Dans son livre « Here comes Everybody », Shirky a montré l’impact positif d’Internet sur la dynamiques des groupes. Son admiration pour Github semble prendre place dans une recherche d’outils collaboratifs et ouverts axée sur l’humain. Il est clair que nous en avons besoin, et même si Github n’est peut-être pas la bonne réponse, à ce stade, tout peut valoir la peine d’être tenté.

Crédit photo : Fabricio Zuardi (Creative Commons By)

Des années que je présente ici la sortie d’un nouveau livre de notre libre collection Framabook. Je suis pour ainsi dire rôdé à l’exercice, pas une routine mais presque.

Sauf que là je cale un peu. Je ne sais pas trop par quel bout le prendre celui-là. Il faut dire que sa première phrase ne m’aide pas forcément : « Quand t’as eu des hémorroïdes, tu peux plus croire à la réincarnation ».

Grand moment de solitude…

J’apprends ensuite que ce roman-feuilleton a été écrit et blogué en direct. Chaque matin, il fallait écrire au moins 800 mots. Chaque soir, à 17h28, il fallait les publier. Un épisode par jour, quatre jours par semaine. Ce premier tome recueille les épisodes publiés entre le 6 février et le 7 juin 2012 sur le blog NoeNaute.

Soit.

Les journalistes ne me jetteront pas la pierre, mais, quand on manque d’inspiration, on a la tentation d’aller pomper de gros morceaux du Dossier de presse.

#Smartarded – Le cycle des NoéNautes, I est une fantaisie urbaine où on trouve pêle-mêle du Hello Kitty, du café à ouverture facile qui s’ouvre pas, des lézards qui shootent des chats, des coussins berlinois, une concierge hackeuse, des féministes malignes, du Babybel, des chatons, des hémorroïdes (on le saura !), une maladie mentale pénienne et mortelle et des SDF rebelles.

Nous voici donc bien plus avancés ! Enfin, si ça vous a déjà convaincu, c’est par ici.

Moi je préfère poursuivre en reproduisant ce qui ressemble (vaguement) à un résumé :

Smartarded est la contraction de Smart Ass (petit malin tête à claques) et Retarded (débile mental).

L’histoire, c’est celle d’Enguerrand Kunismos. Ce jeune homme de 25 ans avait une carrière prometteuse en tant qu’ingêneur. Une sorte de consultant en connardise qui gagne très bien sa vie en imaginant comment pourrir efficacement la nôtre. Mais un accident lui fait développer des capacités assez étranges… Celles de voir et d’intervenir dans les histoires qui se jouent dans nos têtes. Dans la noétie, la sphère des idées.

Enguerrand est un NoéNaute. Or, les NoéNautes sont peu nombreux. Et ils détestent savoir que d’autres sont, encore, en vie.

Enguerrand découvre le petit monde des NoéNautes et ses règles subtiles en essayant de sauver sa peau. Il nous blogue donc sa cavale avec Fulbert (énigmatique monsieur je-sais-tout au magnifique fessier) dans un road-movie livresque bourré de #hashtags cyniques, de références geek, d’amours LGBT. Et d’un héros qui se prend pour un méchant.

Soit, vous connaissez désormais le chemin vers la sortie (du livre), parce que, de mon côté, je continue encore un peu, d’autant que, prévoyant tout (et même le pire), on nous donne dix bonnes raisons de parler de #Smartarded :

1. Pour que l’auteur écrive la suite
2. Car c’est un livre gratuit qui peut s’acheter
3. Parce que c’est le 647e livre de la rentrée.
4. Pour y découvrir une Toulouse insoupçonnée
5. Car c’est le premier roman libre édité en France
6. Parce qu’un auteur libre est mieux payé qu’un auteur sous copyright
7. Pour frimer sur twitter avec des #hashtags
8. Car c’est le premier roman écrit sur tablette
9. Parce qu’il y a des chatons dedans.
10. Non mais sérieusement, quoi : des chatons !

Notre auteur marque ostensiblement quelques points là (un peu moins de dix quand même). Plus précisément la licence choisie est la CC0 (Creative Commons Zéro) qui est une sorte d’offrande immédiate et volontaire au Domaine Public. Finalement, peut-être qu’il mérite qu’on clique (enfin) sur ce lien.

Tiens, justement, m’aperçois que je n’ai pas encore parlé de l’auteur !

Que dire sinon qu’il s’appelle Pouhiou et que ce n’est pas avec un pseudo pareil qu’on risque un jour d’avoir son article dédié sur Wikipédia.

On va cependant quand même signaler cet entretien sur le site Framabook, ne serait-ce que parce qu’il comporte des questions aussi subtiles que « Pourquoi ton roman est-il Gay & Geek friendly ? » ou encore « La licence libre, c’est parce que t’as pompé ? ».

Et si vous le croisez un jour, ne vous sentez surtout pas obligé(e) de lui dire : « Il faut que je lise ton livre » !

Grande et bonne nouvelle, la Californie est allé au bout de sa réflexion sur l’opportunité des manuels scolaires libres !

C’est de notre point de vue bon sens et évidence mais ça l’est moins quand on pense à la situation dont on a hérité, avec d’énormes résistances de la part de ceux qui éditaient précédemment (et privativement) ces manuels.

Au passage vous remarquerez le choix logique et pertinent de la licence, la Creative Commons la plus dépouillée d’entre toutes : la CC By. Cela fera peut-être réfléchir ceux qui pensent encore que la clause non commerciale NC et/ou non modifiable ND sont bonnes quand il s’agit d’éducation…

Et en France, me direz-vous ? Cela fait six ans (je crois) que nos amis de l’association Sésamath ont publié leur premier manuel libre pour la classe de Cinquième en mathématiques. De véritables pionniers qui depuis ont couvert tout le collège et lorgnent désormais aussi bien sur le primaire que vers le lycée.

Six ans que l’Institution avait en son sein un exemple à soutenir, mettre en avant et montrer aux autres disciplines pour leur emboîter le pas. Pour des raisons que je ne m’explique pas (ou trop bien), elle n’en fit rien ! Il est grand temps de rectifier le tir sinon nous les derniers seront les premiers et nous aurons une fois de plus perdu un temps précieux.

Il est véritablement grand temps ! (et sous licence libre s’il vous plaît !)

L’illustration ci-dessous et un extrait d’une infographie qui résume bien les choses (et les gains) en procédant ainsi.

La Californie entérine officiellement son projet de loi inédit sur les manuels scolaires libres

California passes groundbreaking open textbook legislation

Timothy Vollmer – 27 septembre 2012 – CC Blog
(Traduction Framalang : Cyrille L., ehsavoie, M0tty, Rouage, lgodard, Ag3m)

C’est officiel. En Californie, le Gouverneur Jerry Brown a signé deux projets de lois (SB1052 et SB1053) qui permettront la création de manuels numériques sous licence libre pour les cinquante cours les plus populaires des universités de Californie (cf cette vidéo). Ce projet de loi a été proposé par le président du Sénat par intérim Darrell Steinberg et est passé au Sénat et à l’Assemblée de Californie fin août.

Un élément essentiel de la législation Californienne est que les manuels ainsi créés seront disponibles sous licence Creative Commons Paternité (CC-BY) :

Le manuel et d’autres matériels de cours sont placés sous la licence Creative Commons Paternité qui autorise quiconque à utiliser, distribuer, et créer des travaux dérivés basés sur ce matériel numérique tout en permettant aux auteurs ou aux créateurs d’être crédités pour leurs travaux.

La licence CC BY permet aux professeurs d’adapter le contenu des manuels aux besoins des étudiants, aux sociétés commerciales de se servir de ces ressources et d’en créer de nouvelles à partir des premières (comme par exemple des tutoriels vidéos), et ouvre des portes à la collaboration et à l’amélioration de ce matériel de cours.

Pour les étudiants, l’accès à des manuels abordables est extrêmement important, sachant que le coût de ces manuels augmente quatre fois plus vite que l’inflation, dépassant même les frais d’inscription dans certaines universités. Ainsi, en plus de rendre le manuel numérique disponible librement et gratuitement aux élèves, la loi requiert que les copies imprimées du manuel ne dépasse pas 20$.

C’est une grande victoire pour la Californie, et un exemple bien accueilli de politiques ouvertes qui visent à appuyer les licences libres pour économiser l’argent des familles californiennes et soutenir les besoins des professeurs et des élèves.

Source : Le nouveau film de la Blender Foundation “Tears of Steel” (Creative Commons By)

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

Tu ne partageras point, même ce qui est à toi ! Pas un jour sans une nouvelle affaire #CopyrightMadness du « gang de la GAF » ! (Google, Apple, Facebook)

Cody Jackson, alors en service en Irak, rédige un livre sur le langage de programmation Python. Et pour remercier la communauté de tout ce qu’elle lui a apporté, il décide de le placer sous licence libre Creative Comons By-Sa (exactement comme notre projet Framabook en somme). Il vend la version papier, invite au don, met un peu de pub Google sur le site du projet et propose en libre téléchargement les versions numériques du livre.

Sauf que parmi les liens donnés de ses versions numériques, il a le malheur de proposer du P2P, en l’occurrence du torrent qui pointe directement vers The Pirate Bay ou encore Demonoid.

Quoi ? « Torrent » ! « Pirate Bay » ! C’en est trop pour le robot Mediabot, véritable police automatique du copyright Google. Nous sommes évidemment en présence manifeste de ressources illégales ! Et Google de désactiver illico sans autre forme de procès la pub sur le site de notre auteur. Et ne croyez surtout pas qu’il suffit de retirer les liens incriminés pour que Google remette tout en place. Non, non, le mal est fait.

Et pourtant de mal fait il n’y en eut jamais. Bien au contraire, on voulait juste partager et enrichir le bien commun…

Bien sûr, Google est sous la pression constante des ayants droit de l’industrie culturelle et du Grand Hollywood (qui scrute au quotidien ce qui se passe sur YouTube notamment). Mais avec cet absurde faux positif, Google, son service clientèle déshumanisée et son copyright de fer nous affirment avant tout ceci : puisqu’on ne les envisage même pas, puisqu’on condamne le contenant quel que soit son contenu, il n’y a pas de place actuellement pour les ressources libres sur Internet. Ou, plus généralement, et pour reprendre une expression à la mode, il n’y a pas de véritable place aujourd’hui pour les échanges non marchands.

Edit du 28 septembre : Il y a une suite (favorable) à cette histoire (mais une morale à en tirer ?) que nous vous proposons dans la foulée.

Remarque : Il s’agit d’une nouvelle traduction et vous allez constater un nombre inhabituel de traducteurs dans le crédit ci-dessous. Nous sommes en phase de test pour améliorer Framapad et effectivement, hier soir, c’était spectaculaire, avec, au point culminant de la fête, près de 40 collaborateurs « colorés » travaillant en simultané dans la joie, la bonne humeur et le souci collectif d’un travail de qualité. C’est pourquoi, une fois n’est pas coutume, notre image d’illustration n’a rien à voir avec le font du sujet si ce n’est que dans la forme on l’a obtenu ainsi (cf ce tweet plus précis de @framaka). Ils méritaient bien ce petit hommage (quant à l’évolution du projet Framapad, nous venons d’ouvrir une liste de discussion pour là encore avancer ensemble).

Google et ses droits de copie restrictifs : un auteur condamné pour avoir partagé son propre livre

Google’s Copyright Crackdown Punishes Author For Torrenting His Own Book

Mike Masnick – 27 septembre 2012 – TechDirt.com
(Traduction : volent, metoo, Smonff, greygjhart, doc_lucy, L’gugus, Toerdas, Wan, Yan G., Evpok, goofy, Rouage, Aymerick, slb, peupleLa, 0gust1, Husi10, Mike, Hellow, Dominique, fredchat, fwix_, e-Gor, TheDarkDweller, minimoy, 5h3d0, lamessen)

Au fil des ans, nous avons souligné à de nombreuses reprises le talon d’Achille de Google : son épouvantable service client.

Essayer de communiquer avec Google s’apparente plus souvent à affronter un bloc de marbre inébranlable plutôt que faire face à un réel être humain. Plus récemment, nous nous sommes inquiétés de l’agressivité excessive de Google pour faire « appliquer » le copyright, dans l’espoir de tenir Hollywood (et ses soutiens au gouvernement) à distance. Combinez ces deux problèmes et vous obtenez une incroyable histoire… comme advenue à notre lecteur Cody Jackson.

Il y a quelques années, alors qu’il était en service actif en Irak, Jackson a écrit un livre sur Python (le langage de programmation) intitulé Start Programming with Python (NdT : Débutez la programmation avec Python). Il a décidé de distribuer le livre gratuitement, en guise de remerciements à la communauté du libre qui, d’après ses dires explicites, lui a énormément apporté. Il a toujours fait en sorte que le livre soit disponible en libre accès et donné les liens vers différentes sources à partir desquelles l’obtenir. Dans le même temps, il a proposé aux personnes de le soutenir via des dons. Et pour se faire un peu d’argent, il a également souscrit au service de publicités Google AdSense qu’il a placé sur son site.

La semaine dernière, il a été contacté par un bot (NdT Googlebot : robot d’exploration de Google), l’informant que AdSense avait été automatiquement désactivé. Pourquoi ? Parce que, affirme-t-on, il distribuait illégalement des contenus protégés par des droits d’auteur. Le courriel, que j’ai pu voir, mentionne que son compte a été désactivé pour la raison suivante :

Précisions au sujet de cette violation

CONTENUS SOUS COPYRIGHT : Comme il est stipulé dans nos conditions d’utilisation, les utilisateurs d’AdSense ne sont pas autorisés à placer des publicités Google sur des sites impliqués dans la distribution de contenus sous copyright. Ceci inclut l’hébergement de fichiers sous copyright sur votre site, ainsi que le fait de fournir des liens ou de rediriger le trafic vers des sites qui proposent des contenus protégés. Plus d’informations sur ces conditions d’utilisation sont à disposition sur la page de notre centre d’aide.

Honnêtement les conditions d’utilisation de Google n’ont ici aucun sens. Fondamentalement TOUT site Web « propose du contenu sous copyright ». Si l’on se réfère à ce que Google a envoyé à Jackson, personne ne pourrait plus faire aucun lien vers d’autres sites s’il souhaite utiliser Google AdSense. Google a une armée de très bons juristes spécialisés dans le copyright, mais ils ont du laisser filer ce point. Je suis sûr que Google voulait plutôt parler de « contenu non autorisé » ou « qui porte atteinte au copyright », mais ce n’est pas ce qui est écrit (NdT : Ou alors ils y sont obligés pour se protéger de tout).

Dans les deux cas, cela semble être ridicule et faire preuve d’un excès de zèle que de suggérer que tout lien vers un site qui, croit-on, véhicule, parmi d’autres, du contenu illicite, doit être considéré comme une violation des conditions de service, même si en l’occurrence le lien en question redirige vers du contenu tout à fait légitime. Le courriel donne un lien vers une « page exemple » justificative. Cette page est celle où Jackson annonce qu’il délivre un torrent de la seconde édition de son livre, et renvoie les gens vers The Pirate Bay et Demonoid pour le récupérer. Rappelez-vous, c’est son propre livre, qu’il a publié lui-même et qu’il distribue librement et gratuitement… intentionnellement !

On pourrait faire valoir que les conditions d’utilisation de Google sont ici volontairement trop générales et elles le sont assurément. Déclarer que vous ne pouvez pas créer de lien vers du contenu légal que vous avez vous-même publié sur The Pirate Bay et dont vous êtes le légitime propriétaire pourrait avoir un effet dissuasif négatif pour ceux qui choisiraient de mettre leurs propres œuvres sur des sites similaires.

Jackson a essayé de joindre Google pour obtenir de plus amples informations. Il leur a expliqué la situation et leur a indiqué qu’il en était l’auteur et l’éditeur et que l’œuvre était publiée sous la licence libre Creative Commons Paternité – Partage dans les mêmes Conditions (CC By-Sa), rendant ainsi toutes les copies se trouvant sur The Pirate Bay parfaitement légales et autorisées. Google lui a rétorqué qu’ils examineraient son argumentaire… avant de lui renvoyer le message suivant :

Merci de nous avoir fourni des informations complémentaires concernant votre site. Cependant, après avoir examiné de près le site python-ebook.blogspot.com et avoir pris votre réaction en considération, nous sommes dans l’incapacité de remettre en fonction notre service publicitaire sur votre site à l’heure actuelle, puisque votre site semble toujours violer nos conditions d’utilisation.

Si vous voulez que nous étudiions à nouveau la participation de votre site au programme Ad Sense, merci de consulter les conditions d’utilisation de notre programme et d’apporter les modifications nécessaires à vos pages web. Pour plus d’informations sur vos conditions d’utilisation, merci de visiter cette page.

Confus après lecture et sans sentiment d’avoir violé quoi que ce soit, il a cependant docile supprimé les liens vers les fichiers torrents en question, quand bien même pour lui il était tout à fait sensé de les conserver. Comme il me l’a dit dans son courriel : « BitTorrent a été l’un des premiers vecteurs de diffusion de mon livre, puisque c’est là que mes lecteurs spécialisés sont susceptibles de traîner. Il m’a semblé que déposer un fichier torrent sur le site de torrents le plus populaire coulait de source. »

Aussi a-t-il à nouveau répondu au Googlebot, après donc avoir cette fois supprimé les liens… Et il a reçu à nouveau le même message exactement ! Il avait bien supprimé les liens mais pas la mention explicite des noms « The Pirate Bay » et « Demonoid ». Cela a suffit, semble-t-il, pour que l’équipe de Google AdSense continue de prétendre qu’il viole leurs termes incompréhensibles. Ils refusent de s’en expliquer. Ils n’ont pas l’air de vouloir vraiment comprendre ce que dit Cody Jackson. Ils bloquent, c’est tout.

Ce qui vaut la peine d’être retenu, c’est que l’on entend constamment les gens qui détestent Google se plaindre de ce que ce dernier refuse en quelque sorte d’enlever ses publicités des « sites pirates ». Cet exemple suggère précisément le contraire : Google est d’une agressivité excessive dans sa manière de bloquer, sous toutes leurs formes, les publicités qui s’affichent a proximité de sites qu’il a jugé lui seul problématiques, même si le contenu est garanti 100% légal et autorisé. Ajoutez à cela l’horrible relation client robotisée de Google, et vous avez une situation malheureuse où un auteur est puni pour avoir fait quelque chose de parfaitement légal et ne semble pas pouvoir trouver chez Google une seule personne réelle, faite de chair et d’os, qui prenne réellement le temps de comprendre ce qu’il se passe.

Voilà pourquoi nous sommes si inquiets quand Google intensifie son « automatisation » sous la pression de Hollywood. Les dommages collatéraux ne sont que trop réels.

Mise à jour du 28 septembre ci-dessous : Un épilogue heureux mais une leçon à retenir…

Les annonces Google sont de retour

Google Ads are back

Mike Masnick – 28 septembre 2012 – TechDirt.com
(Traduction : Lamessen, Pascal, L’gugus, Metal-Mighty, Ag3m, ti_tux)

Grace au relais du site Techdirt, mon problème a été entendu par les robots de Google et mon compte Adsense a été réactivé.

En effet, cinq heures après la publication de l’article sur Techdirt, je recevais un e-mail de Google m’informant qu’ils avaient réétudié mon cas, et décidé finalement que je n’avais pas enfreint leur politique sur le copyright. Je pouvais donc faire apparaître à nouveau les publicités Google sur mon blog.

Je vais pouvoir, comme avant, mettre des liens directs vers mon fichier torrent, mais plus vers «The Pirate Bay» ou d’autres sites de torrents. Car ne veux pas me retrouver confronté à ce problème à nouveau (bien qu’il sot assez tentant voir ce qu’il arriverait si je le faisais).

Le bon côté de cette histoire, c’est que cela a attiré l’attention du public sur les problèmes de réglementation du copyright en général et des politiques d’entreprise en particulier. Lorsqu’une personne ne peut pas publier ses propres créations sur Internet parce qu’une autre a peur qu’il y ait infraction au droit d’auteur, il y a un véritable problème.

Certains commentaires sur Techdirt affirment que j’aurai dû prévoir cela en proposant des liens vers The Pirate Bay et Demonoid qui sont considérés comme des « bastions du piratage ». Et pourtant, avoir fait appel à eux pour aider les gens à trouver mon livre (sous licence libre) montre qu’on peut aussi les utiliser de manière tout à fait légale. Que certaines personnes y déposent illégalement des contenus protégés ne fait pas de ces sites le mal absolu. Ce sont simplement des outils et ils sont neutres en soi, un peu comme un couteau, qu’on peut utiliser à bon ou mauvais escient.