Lorsqu’une personnalité notoire du Libre comme Carl Chenet s’attaque avec pertinence à la tendance massive du « tous sur GitHub » et égratigne la communauté du Libre pour son immobilisme (et même sa paresse !), Framasoft trouve que c’est une bonne occasion de lui donner un peu plus de voix encore.

S’adressant principalement aux développeurs, il pointe les dangers d’un service centralisateur, privateur, qui uniformise les pratiques en étouffant les alternatives. Ça ne vous rappelle rien ? Oui, les mêmes écueils contre lesquels nous vous mettons en garde dans notre campagne degooglisons ! Ajoutons que nous avons déjà basculé sur GitLab, comme le recommande Carl, dès 2014 et mis à la disposition de tous depuis le mois de mars 2015 notre GitLab qui héberge à ce jour 3017 projets, 2071 utilisateurs inscrits, 242 groupes.

Nous reprenons ici avec son autorisation le récent billet de Carl qui a déjà suscité d’intéressants commentaires et en provoquera probablement d’autres ici même.

Le danger GitHub

Un article de Carl Chenet d’abord publié sur son blog

Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez GitHub (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de GitHub par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.

L’octocat, mascotte de GitHub

Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par GitHub ont pris une place considérable dans l’ingénierie logicielle ces dernières années.

Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.

1. Points critiques

1.1 La centralisation

L’application GitHub appartient et est gérée par une entité unique, à savoir GitHub, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.

De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas GitHub, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on n’est pas « dans le coup » quand on n’utilise pas GitHub, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).

1.2 Un logiciel privateur

Lorsque vous interagissez avec GitHub, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de GitHub on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec GitHub). Et surtout un outil crucial propriétaire fourni par GitHub qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.

1.3 L’uniformisation

Travailler via l’interface GitHub est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant GitHub comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils GitHub en travaillant pour une autre société. Cette fréquence de l’utilisation de GitHub dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.

L’uniforme évoque l’armée, ici l’armée des clones

2. Validité des points critiques

2.1 Les critiques de la centralisation

Comme dit précédemment, GitHub est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée.  Des attaques massives par déni de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de GitHub elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.

L’excuse n°1 des programmeurs pour se lâcher sans scrupules : « GitHub est en panne »

— Hé, au boulot les gars ! — Github est en panne !

— Ah bon, continuez alors.

2.2 Les critiques relatives à l’usage d’un logiciel privateur

Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek,  car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.

Les tenants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser GitHub. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.

FreeBSD, principal projet des BSD sous licence MIT

Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de GitHub elle-même, l’utilisation du gestionnaire de suivi de bugs de GitHub pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.

GitHub propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de GitHub  ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par GitHub ?

L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez GitHub serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800 000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez GitHub ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de GitHub.

Debian, l’un des principaux projets du Logiciel Libre

avec autour de 1000 contributeurs officiels

2.3 L’uniformisation

La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.

GitHub a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.

Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur GitHub avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.

Et c’est bien dommage car GitHub, en proposant une expérience unique et originale à ses utilisateurs, taille à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à GitHub d’initier à Git les nouveaux arrivants dans le développement  à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.

Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?

Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.

L’effet GitHub est donc délétère au point de vue des effets qu’il entraîne : la centralisation,  l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre « Cher GitHub… » met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de GitHub d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.

Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternatives et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capables de programmer devraient avoir ce réflexe. Vous n’aimez pas ce qu’offre GitHub ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.

Logo de Gitlab, une alternative possible à GitHub

en choisissant la version Communauté

Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à GitHub et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.

Finalement, l’utilisation de GitHub suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec GitHub. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.

Le « lion » du Libre assoupi devant la cheminée (allégorie)

Liens :

• Source de l’article : blog de Carl Chenet
• Notre GitLab ouvert à tous (pour sortir de Github)

Trouver des auteurs de logiciels libres, c’est relativement simple. Il n’y a qu’à se pencher sur un paquet Debian pour en trouver. Trouver des artistes qui mettent leurs productions sous licence libre, c’est déjà un peu plus rare.

Connaissez-vous David Revoy ? Non ? Et pourtant, vous avez sans doute déjà vu des projets auxquels il a contribué. Il a en effet travaillé (entre autres) à plusieurs projets de la fondation Blender : Sintel, Tears of Steel…

Mais c’est plutôt son webcomic Pepper & Carrot qui nous a poussés à l’interviewer. D’une rare qualité, les aventures de cette jeune sorcière et de son chat nous ont séduits, tant par les dessins magnifiques que par son humour.

Bonjour David. Tu peux te présenter un peu ? Ton parcours, ton travail, tes projets…

Bonjour, j’ai 34 ans et je suis un Montalbanais passionné de dessin et d’informatique depuis l’enfance. Au cours de ces quinze dernières années, j’ai eu un parcours de freelance passant par l’illustration (couverture de livre et jeu de société), par le concept-art (décors/engins et persos dans les jeux vidéos) et parfois par la direction artistique de projets.
L’an dernier, j’ai créé Pepper&Carrot, un projet de webcomic libre et open-source financé grâces au mécénat des lecteurs. Peu après et grâce au succès de la série, j’ai décidé d’arrêter le freelance pour me consacrer à plein temps à la création de nouveaux épisodes et aux extras (traductions, tutoriaux, wiki, téléchargements gratuits…).

Tu expliques sur ton site pourquoi tu as choisi l’Open Source. Tu peux nous faire un petit résumé pour nos lecteurs qui ne maîtrisent pas la langue de Shakespeare ?

Je vais essayer de résumer ça mais tout d’abord je tenais à vous remercier, car j’ai abordé le libre entre 2003 et 2005 grâce au portail de Framasoft d’il y a dix ans. A l’époque j’utilisais Windows XP et cela m’a permis d’adopter Blender, Inkscape, Firefox, LibreOffice et FileZilla. Mon abandon total des logiciels propriétaires s’est fait peu de temps après. Je venais d’acheter un nouveau PC livré avec ‘Windows Vista’ pré-installé. J’avais une licence ‘XP pro’ en boîte et je comptais réinstaller ce système car tous mes logiciels dépendaient de ce système. Malheureusement pour moi, la carte mère du PC Vista n’avais pas de pilote pour XP disponible et mes licences logicielles professionnelles (Photoshop, Painter, Manga Studio; plusieurs milliers d’euros) était toutes instables avec Windows Vista. Mettre tout à jour était très coûteux et n’apportait aucunes nouvelles fonctionnalités.

Cette stratégie de mise à jour forcée me paraissait injuste. Je ne voulais pas alimenter les créateurs d’un tel système avec mon argent. C’est donc cet événement qui m’a poussé vers le 100% GNU/Linux. Voici une vidéo d’époque :

Tu as travaillé sur pas mal de jeux vidéos. Pourquoi faire une BD ? C’était quelque chose qui te trottait dans la tête ou ça t’est arrivé comme ça ?

J’aime beaucoup les jeux vidéos et le cinéma d’animation, mais être auteur de bande-dessinée c’est mon rêve d’enfance. C’est la passion que j’ai toujours essayé de préserver. La BD, c’est l’art qui me touche le plus et celui dans lequel je m’exprime avec le plus de liberté. Pour la création de Pepper&Carrot, c’est vrai que c’est arrivé un peu « comme ça ». Tout a commencé un dimanche soir d’avril 2014 particulièrement calme, j’ai fait un speedpainting (une peinture numérique à la tablette graphique). J’ai enregistré ce qui ce passait à l’écran par coïncidence ce jour-là :

J’avais là une petite sorcière, un chat, une scène… La semaine qui a suivi j’ai ajouté d’autres cases et cela a formé une petite histoire. L’épisode 1 est né ainsi.

Ce petit projet personnel a eu beaucoup de succès, alors j’ai décidé de faire un épisode 2. Puis 3, puis 4… Ce mois-ci, je fais l’épisode 14. L’audience me porte par son enthousiasme. C’est ainsi qu’est né et continue de grandir Pepper&Carrot; un pas devant l’autre, très connecté au présent.

Tu utilises des logiciels libres ou open-source, mais lesquels ? Et qu’est-ce qui t’as décidé à libérer tes œuvres ?

J’utilise essentiellement Krita sur Linux Mint. Mes outils secondaires sont Inkscape, Blender, Gimp, Mypaint, G’Mic et Imagemagick.

J’ai commencé à libérer mes œuvres à la Blender Foundation quand je travaillais sur la direction artistique du court-métrage Sintel. C’était dans le cahier des charges de mettre tous les dessins préparatoires en Creative Commons Attribution. J’ai pu donc faire l’expérience directe de travailler avec cette licence très ouverte au sein d’une grande audience. L’expérience fût très positive. C’est ainsi que j’ai appris à connaître, et ensuite adopté les licence Creatives Commons.

Tes projets sont sous licence CC-BY, CC-BY-SA, CC-BY-NC-ND, copyright classique… Qu’est-ce qui détermine la licence que tu utilises ?

C’est déterminé par des préoccupations juridiques. D’abord il y a les dessins qui sont tellement « copyrightés » par mes clients que je ne peux ni en parler et ni même les montrer. Ce sont les contrats de jeux-vidéos, de cinémas sous NDA (Non Disclosure Agreement : accord de non-divulgation) que j’ai remplis durant mes années freelance. Les dessins « copyrightés » simplement sont ceux où je reçois l’autorisation d’afficher le dessin en basse résolution sur mon site.

La licence CC-By-NC-ND encourage le partage Internet mais empêche les travaux dérivés, les modifications et l’utilisation commerciale. J’ai longtemps utilisé ceci pour mes travaux personnels plus activistes comme pour le « Yin-Yang de la faim dans le monde ». Des groupements politiques m’ont déjà démarché pour détourner ou s’approprier ce dessin. Leur donner l’autorisation d’office serait trop dangereux.

La licence CC-By-Sa, c’est celle qui offre tout, mais demande la mise à disposition des sources de l’œuvre sur une licence également libre. Une façon de forcer l’évolution du libre à rester libre.

La licence CC-By, c’est quand je décide de tout partager, et de ne garder que le crédit participatif à l’élaboration du dessin. C’est la licence que je trouve la plus libre et aussi la licence que j’ai choisie pour tout Pepper & Carrot.

Il y a des personnes qui ne connaissent pas (encore) Pepper&Carrot… Comment tu les présenterais ?

Je les présenterais en BD, tel qu’ils le sont mais si je devais le faire avec que du texte, je passerais la main à ce petit texte issu de l’article de LinuxFr, par l’auteur Eingousef (édité par ZeroHeure, Yvan Munoz, BAud, M5oul, Benoît Sibaud et palm123 et modéré par ZeroHeure / Licence CC by-sa) :

Des personnages mignons, des chats, une influence manga/anime, de l’héroic-fantasy, des clins d’œil au logiciel libre, de l’humour décalé et de la poésie dans un univers épique, des licences libres et des sources complètes, des contributions à des logiciels libres et jeux libres… David Revoy a tout pour plaire aux geeks. Ce dessinateur aux multiples talents, qui s’est fait connaître dans la communauté du libre surtout par son impressionnant travail de concept artist sur les trois derniers Open Movies de la Blender Foundation (Sintel, Tears of Steel et le projet Gooseberry), s’est lancé l’année dernière dans la réalisation d’un webcomic libre, « Pepper & Carrot ». Celui-ci met en scène les aventures décalées de Pepper, une petite sorcière courageuse et casse-cou, mais qui a tendance à sous-estimer ses capacités, et de Carrot, son chat à l’intelligence quasi-humaine, mais éternel esclave de ses instincts, dans l’univers féerique du Royaume d’Hereva, avec ses villes volantes, ses fées, ses phénix, ses dragons-vaches, ses canards-drakes et ses sorcières rivales…

Le mode de financement de Pepper & Carrot est basé sur l’économie participative (Tipeee, Patreon, les dons…). Comment y es-tu venu ? Ça marche bien ?

J’y suis venu car je ne voulais pas proposer Pepper&Carrot aux éditeurs papier. L’édition est un milieu en crise que je connais assez bien grâce à mes années de travail dans l’illustration. Un univers ou la loi du marché prime sur tout. Pepper&Carrot aurait été sans doute dénaturé, standardisé, aseptisé et réduit au bon vouloir des commerciaux, des distributeurs, des actionnaires… du pognon pour le pognon. Quand on élimine la voie de l’édition classique, il ne reste plus grand chose pour exercer la BD à plein temps. Je ne suis ni riche ni « fils de » pour vivre de la BD sans en demander une contrepartie financière. J’ai un loyer mensuel à payer, un corps à nourrir, un matériel informatique à entretenir, donc solliciter le mécénat des lecteurs était ma seule possibilité.
De nos jours, ça marche grâce à la générosité des lecteurs. Financièrement, je suis loin de mes années freelance. Je gagne un petit SMIC pour autant d’heures de travail par semaine qu’il en est humainement supportable (sans congé, sans arrêts maladies, sans retraite). Mon projet en 2016 : arriver à maîtriser la production des épisodes et réduire les heures pour retrouver une vie personnelle en dehors de Pepper&Carrot (une coquetterie que je me suis refusée au cours des 15 derniers mois).

Tu as plein de rêves pour Pepper&Carrot… Comment t’es venue l’idée d’afficher ces douces ambitions ? Cette liste avance bien ?

Pour l’idée, je me suis dit que d’afficher clairement mes rêves et mes motivations aiderait les visiteurs du site à me connaître.

Est ce que ça avance ? Difficile à évaluer pour certain rêves. Par exemple pour le rêve numéro 1 : « Donner une conférence au Japon dans une convention Manga à propos de Pepper&Carrot » c’est super difficile à quantifier l’avancement de ce rêve. Mais j’ai déjà une piste ; j’ai reçu un email d’un lecteur Japonais avec les coordonnées d’un événement Manga qu’il connaît. Je vais donc bientôt constituer un beau dossier pdf pour essayer de démarcher cet événement. Quand au rêve « Atteindre l’épisode 100 ! », ce rêve est très quantifiable et avec la publication le mois dernier de l’épisode 13, j’en suis exactement à 13% !

Un petit mot de la fin ? Ou un dessin ? 😀

Un dessin bien sûr ! Merci pour l’interview !

Toutes les illustrations de l’article sont bien évidemment de David Revoy, en CC-BY 🙂

Yann Houry est un professeur de français et auteur de manuels numériques dont nous avions encouragé la libération en 2014.
Nous reproduisons ici, avec son accord, la lettre ouverte (publiée initialement sur son blog), qu’il a adressée à un de nos GAFAM préféré dans laquelle il explique pourquoi il ne publiera plus chez Apple. Celle-ci est extrêmement instructive sur les conditions qu’ils peuvent imposer sur les contenus publiés.

En effet, la situation pourrait être comique si elle n’était kafkaïenne : Yann Houry se voit refuser – une n-ième fois – la publication d’un de ses manuels libres de grammaire sur la plate-forme iTunes au prétexte que « l’orthographe et la grammaire sont incorrects » ! (Le signalement est fait en anglais, en plus…)

Ce genre de pratique montre à notre sens bien les limites d’une trop grande concentration des pouvoirs des plate-formes sur internet : pour être vu, il faudrait publier sur ses plate-formes et pas ailleurs. Or ces dernières gèrent un tel volume de données publiées par leurs utilisateurs, qu’il devient impossible de les valider par des humains. C’est donc la machine qui prend le relais. Et on se retrouve alors avec des cas absurdes, comme celui de la peinture de Courbet, « L’origine du monde », censurée par Facebook.

Yann a finalement décidé de ne plus publier sur iTunes (tout en continuant – nous le regrettons – à publier chez Amazon ou Google Play, avec le risque que le problème se reproduise). Preuve supplémentaire que le secteur de l’édition a décidément bien besoin de se « dégoogliser » lui aussi. Framasoft propose par exemple le catalogue Framabookin.org pour partager, parmi des milliers d’autres œuvres, les ouvrages de sa collection Framabook. À quand le développement de ces « micro-catalogues », qui pourraient très bien être agrégées par des « moissonneurs » afin de proposer une recherche globale, et qui seraient surtout à l’écoute de leurs auteurs ?

Chère Apple,

Ma pomme préférée (alors que c’est moi la pomme), je t’écris pour te dire que je ne publierai plus chez toi.

Depuis que tu t’es amusée, en 2012, à retirer mon livre de ton store parce que j’avais mis « libre et gratuit » sur la couverture, on s’est franchement bien marré ! Souviens-toi, tu m’avais dit : « Si tu veux revoir ton livre sur mon beau magasin, il faut retirer lesdits mots. Ils sont laids. Comment ? Tu l’as déjà fait, petit écrivaillon conciliant ? Eh bien retire « pour iPad » maintenant ! ».

Et je l’avais fait.
Ce n’était qu’un début.
Dernièrement, j’avais écrit « Kobo » dans la préface du livre de grammaire et de littérature (mon dieu, quand j’y repense…). Encore plus récemment, j’ai dû oublier un truc dans la table des matières. Je t’ai envoyé des photos de mon dos que j’ai fouetté. J’espère que tu as aimé.

Et il y en a eu d’autres encore ! À propos du petit recueil que j’avais fait des fables de La Fontaine, j’avais dit que je m’appelais Yann Houry ! Grossière erreur ! Hop, on ne publie pas le livre !
Une fois, une vidéo ne fonctionnait pas ! Et hop ! on retire le livre. Une autre fois, tu as même retiré un livre parce que le « spelling and grammar must be correct » ! Ah ! tu t’es bien foutue de ma gueule ! Et ce en anglais ! Bah oui, tu ne vas quand même pas condescendre à t’exprimer dans la langue de ton interlocuteur ! Enfin ! Rien ne vaudra les mois que tu as mis à publier mon Manuel de 5e pour une raison que toi seule tu es incapable de donner.

Enfin bref. C’en est trop.
Je ne supporte plus. Raison pour quoi, je me barre ! Je m’en vais (et tes larmes – si tu étais capable d’émotion – n’y pourraient rien changer).
Imagine-t-on un éditeur publier puis retirer puis republier puis retirer à nouveau un livre de la vente ? C’est pourtant ce que tu viens de faire avec mon manuel de grammaire. C’est complètement insensé !

Je retire donc tous mes livres de ton store. J’imagine que tu t’en fiches comme de l’an quarante, mais moi ça me fait un bien fou.

Adieu.

Yann

La numérisation des collections patrimoniales des musées devrait constituer une chance pour la diffusion de la culture. Trop souvent hélas, ce n’est pas le cas, à cause du copyfraud auquel se livrent les institutions. Comme l’a dit très justement Pier-Carl Langlais, le copyfraud est l’inverse du piratage : une revendication abusive de droits sur le domaine public pour en restreindre la réutilisation.

Les exemples de copyfraud ne manquaient déjà pas, mais le Reiss Engelhorn Museum de Mannheim en Allemagne a franchi cette semaine une ligne rouge en la matière. L’établissement a en effet décidé d’attaquer en justice la Wikimedia Foundation et Wikimedia Deuschland, pour la diffusion de 17 images d’œuvres du domaine public sur Wikimedia Commons. Depuis 2008, la Wikimedia Foundation a défini une position très claire à propos du copyfraud, en indiquant qu’elle ne reconnaissait pas la légitimité des restrictions rajoutées sur la réutilisation d’images en deux dimensions d’œuvres du domaine public. L’année suivante, une alerte sérieuse s’était produite lorsque le wikimédien Derrick Coetzee avait téléversé sur Wikimedia Commons plusieurs milliers d’images extraites du site de la National Portrait Gallery de Londres. Son geste dénonçait le fait qu’elle portait un copyright alors qu’elles correspondaient à des œuvres du domaine public . La National Portait Gallery avait alors agité la menace d’un procès, sans la mettre à exécution à la différence cette fois du musée Reiss Engelhorn.

Si l’on peut déplorer un tel comportement de la part d’une institution patrimoniale, ce sera peut-être aussi l’occasion pour un tribunal de se prononcer sur la légalité des pratiques de copyfraud. Comme le dit la fondation Wikimedia dans sa réponse au musée, la reproduction fidèle de tableaux ne crée pas une « nouvelle œuvre » et il est improbable que ces photographies satisfassent au critère de l’originalité, impliquant que le créateur imprime « l’empreinte de sa personnalité » dans son œuvre pour bénéficier d’une protection.

En France également, nombreux sont les établissements culturels se livrant à des pratiques de copyfraud. Le site Images d’art, lancé récemment par la Réunion des Musées Nationaux, comporte plus de 500 000 œuvres numérisées provenant de nombreux musées français. Mais toutes ces images portent le copyright du photographe les ayant réalisées, ce qui en interdit la réutilisation. Quelques institutions choisissent pourtant au contraire de diffuser librement leurs images et certaines comme le Musée des Augustins à Toulouse ou le Musée des Beaux Arts de Lyon ont engagé des partenariats avec Wikimedia France pour diffuser leurs images sur Wikipédia . Mais elles restent encore minoritaires.

Le plus inquiétant, c’est que la loi française risque bientôt d’évoluer pour légaliser les pratiques de copyfraud. Le recours au droit d’auteur par le musée Reiss Engelhorn reste juridiquement très fragile et la fondation Wikimédia peut encore affronter un procès avec des chances sérieuses de l’emporter. Mais la loi Valter, actuellement en cours d’adoption, s’apprête à consacrer la possibilité pour les établissements culturels de fixer des redevances de réutilisation sur les reproductions d’œuvres qu’elles produisent — y compris à partir des œuvres du domaine public —  en les assimilant à des données publiques.

Là où devant la justice allemande, on peut encore revendiquer le droit de réutiliser le domaine public librement, ce ne sera peut-être bientôt plus possible en France.

Lionel Maurel (Calimaq)

*  *  *  *  *

Wikimedia Foundation et Wikimedia Deutschland invitent instamment le musée Reiss Engelhorn à abandonner ses poursuites concernant des œuvres d’art du domaine public.

source : cet article du blog de Wikimedia
Traduction Framalang : KoS, goofy, Bromind, sebastien, r0u

Le 28 octobre, le musée Reiss Engelhorn de Mannheim, en Allemagne, a intenté un procès à la Wikimedia Foundation et ensuite à Wikimedia Deutschland, la branche allemande du mouvement international Wikimedia. L’objet en est une plainte pour copyright concernant 17 images d’œuvres d’art du musée qui relèvent du domaine public et qui ont été mises en ligne sur Wikimedia Commons. Wikimedia Foundation et Wikimedia Deutschland examinent la plainte et feront une réponse commune avant l’échéance fixée en décembre.

La Wikimedia Foundation et Wikimedia Deutschland maintiennent fermement leur engagement à rendre les œuvres publiques gratuites et libres d’accès. Les institutions publiques telles que les galeries et musées ont la même mission, et ont été des alliées historiques pour rendre accessibles à tous les connaissances du monde entier. Avec ce procès, le musée Reiss Engelhorn limite l’accès public à d’importantes œuvres culturelles qui seraient inaccessibles autrement pour le reste du monde.

Les peintures, portraits et autres œuvres d’art concernés par ce procès sont exposés au sein du musée Reiss Engelhorn, mais sont déjà présents dans le domaine public. Quoi qu’il en soit, la loi allemande sur le droit d’auteur peut s’appliquer aux photographies des œuvres qui appartiennent au domaine public, selon différents critères incluant l’artiste créateur de l’œuvre lui-même, la compétence et les efforts qui ont été mis dans la photographie, la créativité et l’originalité, et enfin l’art en tant que tel. Le musée Reiss Engelhorn prétend que ces images sont soumises au droit d’auteur car le musée a rémunéré le photographe qui a pris certaines d’entre elles, ce qui lui a demandé du temps, de la compétence et des efforts pour les prendre. Le Musée Reiss Engelhorn affirme encore que, à  cause de ce droit d’auteur, les images des œuvres d’art ne peuvent pas être partagées au travers des Wikimedia Commons.

Les œuvres du domaine public affrontant l’hydre du droit d’auteur (allégorie)

(Hendrick Goltzius, Cadmus (Statens Museum for Kunst). Licence Domaine public via Commons)

La Wikimedia Foundation et Wikimedia Deutschland estiment que le point de vue du musée Reiss Engelhorn est erroné. Les lois sur le droit d’auteur ne doivent pas être utilisées à mauvais escient dans le but de contrôler la dissémination d’œuvres d’art appartenant au domaine public depuis longtemps, telles que les peintures exposées au musée Reiss Engelhorn. Le but du droit d’auteur est de récompenser la créativité et l’originalité, et non de créer de nouveaux droits limitant le partage en ligne d’images d’œuvres du domaine public. De plus, même si la loi allemande accorde quelques droits sur ces images, nous pensons qu’utiliser ces droits dans le but d’empêcher le partage des travaux du domaine public va à l’encontre de la mission du musée Reiss Engelhorn et de la ville de Mannheim et appauvrit l’héritage culturel mondial.

De nombreuses institutions se sont donné pour mission de rendre leurs collections le plus accessible possible pour le monde entier. En octobre, le musée des Arts et Métiers d’Hambourg, en Allemagne, a rendu sa collection accessible librement en ligne. Le Rijksmuseum d’Amsterdam a fourni un accès en ligne à toutes ses peintures, y compris la possibilité de les télécharger et d’utiliser les reproductions sous licence domaine public CC0. Au Danemark, SMK (Statens Museum for Kunst, la Galerie Nationale du Danemark) a rendu publiques ses images et vidéos numériques sous la licence CC-BY. La British Library [N.d.T : Bibliothèque de Grande-Bretagne, équivalent de la BNF] et le Japan Center for Asian Historical Records [N.d.T : le Centre japonais d’archives historiques asiatiques] ont conjointement libéré plus de 200 gravures japonaises et chinoises dans le domaine public.
Ces institutions culturelles conservent les valeurs du domaine public et protègent le droit de prendre part à notre héritage culturel. La tentative du musée Reiss Engelhorn de créer un nouveau copyright dans le domaine public va à l’encontre des principes européens sur le domaine public.

L’armée française part en campagne contre le copyfraud

(image issue du catalogue en ligne de The British Library, aucune restriction de droit d’auteur connue – Voir tous les détails)

Dans un communiqué du 11 août 2008, la Commission européenne a écrit : « il faut souligner qu’il est essentiel que les œuvres qui sont dans le domaine public restent accessibles après un changement de format. En d’autres termes, les œuvres qui sont dans le domaine public devraient y rester une fois numérisées et être rendues accessibles par Internet ». Cela a été renforcé par la charte d’Europeana de 2010 qui stipule : « Aucun autre droit sur la propriété intellectuelle ne doit être utilisé pour rétablir une exclusivité sur des matériaux du domaine public. Le domaine public fait partie intégrante de l’équilibre interne du système de droit d’auteur. Cet équilibre interne ne doit pas être rompu par des tentatives pour obtenir ou rétablir un contrôle exclusif via des règles extérieures au droit d’auteur. »

Ces dernières années, le mouvement Wikimédia a bénéficié de partenariats fructueux avec des musées et des galeries à travers le monde grâce à l’initiative GLAM-Wiki, qui aide des institutions culturelles à partager leurs ressources avec le monde entier par le biais de projets de collaboration avec des éditeurs expérimentés de Wikipédia. Ces partenariats ont permis à des millions de personnes de découvrir et d’apprécier des collections situées dans des endroits qu’ils ne pourront jamais visiter. Wikimédia Deutschland, seule, a travaillé avec plus de 30 musées en Allemagne pour rendre leurs collections accessibles gratuitement à n’importe qui n’importe où, au travers des projets Wikimédia. Ces partenariats font partie d’un effort indispensable qui permet aux institutions culturelles et à Wikimédia d’accomplir leur mission de libération de la connaissance et de partage de la culture.

Partout dans le monde des gens utilisent Wikipédia pour découvrir et comprendre le monde qui les entoure. Grâce à Internet, de nombreux obstacles traditionnels à la connaissance et à l’apprentissage ont disparu. Refuser l’accès en ligne à des images du domaine public empêche les gens d’explorer et de partager notre patrimoine culturel mondial. Nous exhortons le musée Reiss Engelhorn à reconsidérer sa position et à travailler avec la communauté Wikimédia pour rendre encore plus accessibles leurs œuvres élevées dans le domaine public.

Michelle Paulson, Legal Director
Geoff Brigham, General Counsel
Wikimedia Foundation

Salut à toi ! (arf, pouvais pas ne pas la faire !)

Voici un projet qui utilise le protocole XMPP pour communiquer tous azimuts, et librement. Les deux sympathiques gaillards qui le portent sont convaincus qu’on n’utilise pas impunément les réseaux sociaux, voire que ce sont eux qui se servent de nous.

Ça tombe bien, c’est ce que nous expliquons aussi avec notre campagne Dégooglisons Internet !

Bon, présentez-vous, les gars. Vous êtes qui ?

Goffi : Salut ! Officiellement nous sommes une association loi 1901 créée en 2014. En pratique 2 amis qui se sont connus sur « le Caillou » (le petit nom qu’on donne à la Nouvelle Calédonie).

Adrien : On s’est connus à la fac de Nouméa, ensuite chacun est allé poursuivre ses études en informatique en France métropolitaine, mais pas dans la même ville. Ce qui ne nous a pas empêchés de rester en contact et puis depuis environ 2 ans, comme j’ai rejoint Goffi sur le projet, on se voit beaucoup plus souvent.

Le nom est issu de la chanson des Bérus ?

Goffi: Oui. Le nom a sa petite histoire : il s’agissait d’éviter un énième nom bateau anglophone, et « salut à toi » semblait bien adapté pour un outil de communication. Et puis la graphie en montagne russe (avec un T majuscule et l’accent) avait un côté amusant: SàT. Quand on a créé l’association en 2014, après avoir utilisé de manière informelle le nom pendant des années, on a demandé aux Bérus si ça ne leur posait pas de problème: non seulement ils ont répondu, mais en plus ils connaissaient déjà le projet (avec le nom ils étaient tombé dessus) ! Ça nous a fait bien plaisir.

Il sert à quoi, votre projet ?

Goffi : À communiquer. Tu peux appeler ça un « réseau social » si tu veux, même si on n’aime pas trop ce terme. Plus concrètement ça permet de faire tout un tas de choses comme bloguer (publiquement ou avec uniquement famille ou amis), partager des fichiers (via un serveur ou en pair à pair), chatter avec une seule personne ou en groupe, jouer, faire du travail collaboratif, etc. Avec plein de trucs sympathiques comme du chiffrement ou des « passerelles » pour lire et écrire sur d’autres réseaux (nous envisageons par exemple d’en faire une pour Diaspora et donc la Framasphère).

Nous avons en projet une version utilisant « Tor » (pour un meilleur anonymat), voire de la visioconférence sur le plus long terme.

C’est aussi une brique pour créer d’autres choses, d’autres réseaux ou outils (finalement on revient toujours aux mêmes choses : publier des messages, commenter, partager des fichiers, etc).

D’où vous est venue l’idée ?

Goffi : Au début (vers 2008/2009) l’idée était de faire un logiciel utilisant « XMPP » (un terme barbare pour désigner un « protocole » libre de communication, soit une sorte de langage que les logiciels peuvent utiliser pour communiquer entre eux) car aucun ne me plaisait tout à fait. Puis rapidement le projet a grossi et s’est politisé. Politisé dans le sens où les outils de communication sont aujourd’hui au centre de nos vies : c’est à travers eux qu’on contacte famille et amis éloignés, qu’on se tient au courant de l’évolution du monde, et même en partie qu’on se forge nos opinions et façons de penser. Un des buts du projet et de l’association est de prendre conscience de ça et d’y réfléchir.

Adrien : Dire que l’outil influence à ce point les personnes, ce n’est pas évident a saisir et je pense que beaucoup trouvent ça un peu farfelu. Mais il y a un bon exemple qui a été donné, justement par quelqu’un de Framasoft, lors de la table ronde sur les nouveaux médias aux Rencontres Mondiales du Logiciel Libre cette année. C’est Pouhiou qui disait qu’en tant que rédacteur de blog, il se devait de suivre les règles de Google s’il voulait que ses articles soient lus. On pense ce qu’on veut de la pertinence de ces règles, toujours est-il qu’il s’agit de critères qui ne sont pas forcément sensibles pour un rédacteur, qui va se retrouver freiné dans sa créativité.

C’est tout du libre ?

Goffi : Oui bien sûr ! On fait très attention à ça, c’est une partie importante de notre philosophie. Nous cherchons à être le plus éthique possible, et nous avons même écrit un « contrat social » qui explique clairement nos intentions. Cela se sent aussi dans notre choix d’une association 1901 pour nous organiser (en autogestion, pas de président/secrétaire/trésorier chez nous), notre refus ferme de la publicité ou encore notre présence régulière sur des événements où on peut rencontrer et discuter « en vrai » avec les gens. D’autre part, nous faisons certains choix comme celui de ne pas être sur les grands réseaux privés (tel que le gros truc bleu ou celui qui a inspiré Stromae).

Ben oui, mais du coup est-ce que vous arrivez à vous faire connaître ? Vous savez ce qu’on dit : il faut aller là où sont les gens. Nous, par exemple, on touitte beaucoup.

Adrien : C’est évidemment très difficile de se faire connaître, et parfois c’est un peu décourageant car on a l’impression de bosser dans le vide. Heureusement qu’il y a tout de même quelques personnes qui nous soutiennent, et on espère que la pâte va finir par prendre. Après moi je ne suis pas forcément pour aller toujours chercher les gens là où ils sont. Il y a une partie du chemin que chacun doit faire tout seul. On ne veut pas que les gens viennent utiliser notre outil seulement par effet de mode, on aimerait qu’ils comprennent vraiment pourquoi c’est important et quels sont les enjeux. Ça c’est notre coté politisé, et puis on veut aussi un maximum de transparence et de cohérence. On s’est mis d’accord dès le début qu’on n’utiliserait pas pour le projet les réseaux sociaux populaires que l’on critique.

Goffi : C’est beaucoup plus difficile en effet mais c’est un choix, il y a une question de cohérence avec notre discours : utiliser ces réseaux c’est les justifier, leur donner une raison d’être. On ne jette pas non plus la pierre sur ceux qui y sont (je comprends tout à fait qu’on veuille chercher les gens partout où c’est possible), mais si tout le monde est là bas, l’intérêt des outils libres et standards est amoindri.
Ce qui est triste par contre, c’est qu’on a l’impression de ne pas exister en dehors de ces réseaux (y compris chez les libristes), on manque de canaux alternatifs visibles. J’apprécie d’ailleurs beaucoup votre travail actuel pour fournir des alternatives justement (et celui des autres projets comme Diaspora, Movim, Gnu Social, etc.).

Vous avez lancé une campagne de financement participatif. Quand on a discuté je n’avais pas eu l’impression que c’était votre truc, les histoires de sous. Quel est l’objectif de celle-ci ? Pourquoi il vous en faut ?

Adrien : Ça fait un moment qu’on travaille sur ce projet comme quelqu’un travaillerait dans une boite. Avec beaucoup plus de liberté bien sûr, car on décide de ce que l’on fait, quand et comment. Mais c’est quand même beaucoup de boulot pour lequel on n’est pas payé. Notre but quand on a monté l’association l’année dernière, c’était de récolter suffisamment de fonds au travers des cotisations et dons à l’association pour pouvoir financer des salaires. C’est du financement participatif à l’état pur, ça existe depuis très longtemps et ce qu’on appelle aujourd’hui crowdfunding, c’est la même chose mais avec quelques codes en plus. Cet été, on a lancé une première campagne par nos propres moyens et sans a priori, directement sur notre site web, pour voir ce que ça donne. On a reçu suffisamment de contributions pour pouvoir payer les frais courants de l’association et même un petit plus (merci à tous les soutiens !), mais pas assez pour parler de salaire. On essaie donc maintenant la même chose mais remise au goût du jour.

L’objectif de cette campagne, c’est de financer le développement d’une interface pour les téléphones et tablettes Android. On a besoin pour ça de 3000 euros, même si en réalité il nous faudrait un peu plus, mais tant qu’on n’est pas mieux connus on peut difficilement demander davantage. En pratique, cet argent va servir pour payer un CDD, tout simplement.

Goffi : Pas grand chose à ajouter, on a longtemps hésité avant de faire ce type de campagne, on a finalement décidé de le faire à travers une plate-forme spécialisée dans l’ESS (Économie Sociale et Solidaire). C’est aussi un moyen de nous faire connaître et de gagner en crédibilité (si on réussit !)

Et on peut vous aider autrement ?

Adrien : Nos compagnes et certains amis nous ont beaucoup aidés, notamment pour préparer la vidéo de la campagne. On aime bien la regarder cette vidéo car elle nous donne vraiment l’impression d’appartenir a une communauté. Outre l’argent, c’est de ça qu’on a vraiment besoin, une communauté autour du logiciel. Il y a déjà quelques personnes qui nous filent des coups de main, mais vu l’envergure du projet, il en faut plus. Après chacun peut participer comme il le veut et comme il le peut : utilisateur, développeur, graphiste, testeur, rédacteur de documentation, traducteur, porteur du message… Et on aimerait bien voir plus de personnes qui essaient d’installer Libervia pour le faire tourner sur leur propre serveur. On n’a pas l’intention ni la capacité d’accueillir tout le monde sur https://libervia.org, qui n’est qu’un service de démonstration. Et puis, plus spécifiquement pendant la campagne, on a besoin d’articles qui parlent de nous pour nous faire connaître. Merci Framasoft 🙂

Goffi : En ce moment : soutenir la campagne ! C’est essentiel pour notre crédibilité. Sinon, venir nous voir, en ligne ou en vrai, discuter. Parler de nous nous aide bien sûr, adhérer à l’association (ce qui peut se faire sans cotisation) montre un intérêt certain qui nous motive et nous donne plus de poids. On a beaucoup de mal à se faire connaître à l’étranger, un coup de pouce là dessus serait très utile. Et sinon on aime beaucoup les débats ! En organiser permet non seulement de rencontrer des gens, mais aussi de réfléchir ensemble.
Merci beaucoup à Framasoft, et encore bravo pour votre travail ! Nous apprécions beaucoup ce que vous faites, et c’est un plaisir de discuter avec vous quand on vous croise.

On l’avait déjà évoqué cette rentrée : Framasoft continue de dégoogliser près de chez vous…

Nous avions envie de faire un point sur les temps forts de ces prochaines semaines : entre une tournée à la Réunion, l’avant-première d’un film où le Libre foulera le tapis rouge et une présence massive au Capitole du Libre… nous espérons que vous prendrez le temps de venir boire une limonade (libre) avec nous !

Rappel : vous pouvez retrouver nos précédentes interventions sur cette page.

Octobre et novembre : ça dégooglise près de chez vous

•  … à Thonon-les-bains, le 28 octobre, pour une conférence de Pyg dans le cadre de l‘Université Populaire du Chablais. 
•  … à la Réunion, du 31 octobre au 5 Novembre, où Pyg animera plusieurs conférences et ateliers dans différentes localités de l’île. Vous retrouverez bientôt le programme sur le site du CEMEA.
  
•  … à Paris, le 15 novembre, pour l’avant-première du documentaire « Les nouveaux loups du web », où Pyg co-animera avec Adrienne Charmet (coordinatrice des campagnes de La Quadrature du Net), le débat qui suivra la projection. C’est là un film important, à conseiller partout autour de vous pour mieux faire comprendre le besoin de Dégoogliser Internet. Pour en savoir plus, lire la présentation et l’interview sur le Framablog.
  

•  … à Lyon, le 18 novembre, à la Bibliothèque Municipale de la Part-Dieu, pour l’animation d’un débat suite à la projection du documentaire « Internet Own Boy »
  
•  … à Paris les 18 et 19 novembre, lors du tout nouvel événement « Paris Open Source Summit », fusion des salons « Solutions GNU/Linux » et « Open World Forum »
  
•  … à Toulouse, les 21 et 22 novembre, pour de nombreuses conférences lors du Capitole du Libre. Le programme est en cours de finalisation mais on peut déjà annoncer :
  
  • Dégooglisons Internet, an 2 avec Pyg
  • Créateurs, la confiance paye avec Pouhiou et Fred
  • Wallabag (le logiciel derrière Framabag) par Thomas Citharel
  • Ce n’est pas le logiciel qui est libre… par Pouhiou et Fred
  • Il devrait aussi y avoir un focus sur l’accessibilité et la LSF avec nos ami-e-s de Liberté0
  • Et possiblement des signatures de nos auteurs Libres sur stand, puisque des romans sont sortis récemment/vont sortir chez Framabook 😉 (ceci n’est pas un teaser)

Merci encore à toutes les personnes qui nous invitent dans ces événements, qui les organisent… et surtout à vous qui venez et amenez vos proches afin de les sensibiliser au monde du Libre…

On se retrouve bientôt ?

L’équipe de Framasoft.

 

Problème, ce logiciel ne gérait pas de « comptes privés », c’est à dire qu’il était impossible de rendre « privé » un pad, ni même de le supprimer. Ainsi, si par exemple un enseignant voulait travailler avec une classe sur un sujet d’histoire, il était impossible d’en empêcher l’accès à qui en connaissait l’adresse, ou de le supprimer en cas de séance de tchat qui « dérape » (sauf à faire appel à notre gentille équipe technique, qui devait faire le ménage à la main).

La première version du logiciel, celle hébergée par Bearstech (vous suivez ?) disposait, elle, de cette fonctionnalité. Conséquence : beaucoup de gens continuaient à utiliser l’ancienne version, dont le code source n’était plus maintenu :-/

En juin 2014, Framasoft a donc pris le taureau par les codes, en lançant une campagne de financement participatif qui permettrait de payer le développement par un professionnel d’un plugin de comptes privés sur la nouvelle version du logiciel.

Une vingtaine de jours plus tard, la campagne était un succès, et la somme collectée. Après quelques péripéties, le développement du plugin s’est étalé sur le premier semestre 2015 (lire ici nos comptes rendus réguliers).

En septembre 2015, nous faisions les premiers tests de ce plugin (nommé, MyPads). Et le 6 octobre dernier, Framasoft envoyait (enfin !) le faire part de naissance de ce plugin.

• Société Bearstech : http://bearstech.com/
• Migrer ses « anciens » pads : http://framacloud.org/news/migration-des-pads/
• Framapad, service de rédaction collaborative (avec maintenant sa gestion de comptes privés 😉 ) : https://framapad.org

Vous l’avez sans doute vu passer à plusieurs reprises : notre dessinateur Gee nous a concocté cette année un petit GIF animé (avec variantes) pour illustrer les sorties de nos différents services et a même poussé le concept jusqu’à en faire une vidéo avec musique et effets sonores !

Ce dessin animé est sous licence CC-By-Sa. Et comme chez Framasoft, on est un peu monomaniaques, il l’a bien sûr été réalisé uniquement avec des outils libres ! Ce petit making-of, que vous pouvez également retrouver sur le site de Gee, vous explique les différentes étapes pour réaliser cette courte animation.

Les outils

Bon. Quand Pouhiou m’a envoyé un mail pour me demander s’il y avait moyen de faire un petit GIF avec le scénario qu’il avait écrit (avec une date limite assez serrée), je me suis penché sur les logiciels d’animation libre. J’ai tout d’abord essayé Synfig qui semblait être le plus plébiscité. J’ai importé un personnage bricolé dans Inkscape, j’ai essayé de l’animer en fouillant un peu les menus et en regardant des tutos sur Internet. Sans succès (je dois pas être doué). J’ai laissé tomber quand le logiciel m’a planté entre les mains après avoir cliqué sur un bouton au hasard. J’ai vaguement jeté un œil du côté de Pencil2d, mais ça ne m’avait pas l’air beaucoup plus simple.

Qu’à cela ne tienne. Quand on est un peu pressé, mieux vaut s’en tenir à des logiciels qu’on connaît, même s’ils ne sont pas exactement faits pour la tâche qu’on a à accomplir. En l’occurrence, je me suis contenté d’utiliser :

• Mon chouchou Inkscape pour faire les dessins, on ne change pas une équipe qui gagne (et il est aussi utilisable en ligne de commande, un très gros atout !)
• ImageMagick pour générer le GIF
• Un peu de Ruby pour automatiser un peu le processus

Je préviens d’avance que j’ai procédé volontairement de manière quick’n’dirty. Il est évident que tout ce que j’ai fait peut-être réalisé plus efficacement et proprement si on maîtrise un parser XML, les expressions régulières, etc. etc.

Animons… à l’ancienne !

Puisque je n’utilise aucun outil qui facilite l’animation (pour calculer automatiquement des images entre deux positions-clefs, par exemple) je fais au plus simple : décomposer le mouvement image par image et dessiner chaque image séparément. J’assume du coup le côté « saccadé » car je n’avais franchement pas le courage de faire du 25 images par seconde 🙂

Pour la marche du manchot, une boucle de 8 images :

Pour animer l’uppercut, je me suis inspiré des sprites d’un certain jeu de baston assez connu…

Et pour la partie jardinage, j’ai fait à l’instinct avec une boucle de deux images quand le manchot grattouille la terre.

Reste le soldat qui est beaucoup moins animé mais possède son petit nombre d’images quand même. Je dessine le bouclier vide, sachant que le logo sur le bouclier va varier selon les projets.

Voilà ! Les autres éléments sont fixes (ou pratiquement) :

Et enfin, un fond qui est raccordable à gauche et à droite pour pouvoir boucler facilement.

On assemble…

C’est là où ça devient carrément artisanal (et où, encore une fois, il y a moyen de faire plus simple – et moins gourmand en espace ! – si on sait scripter du SVG comme un chef). Je fais un calque (toujours sur Inkscape) par image, en dupliquant les éléments qui doivent l’être à chaque fois. Du coup le fichier source devient vite très gros…

On commence par 2 cycles de marche (soit 16 images). C’est le fond qui bouge. J’ai calculé qu’à la fin des deux cycles, mon personnage devait avoir parcouru à peu près les 2 tiers du décors qui fait 860 pixels de large. On doit donc parcourir (2/3)*860=537,33 pixels en 16 frames. À chaque calque, je duplique le précédent et je sélectionne mon fond : Objet/Transformer/Déplacement horizontal de -35,84 pixels.

Arrivé à la dernière des 16 frames, le nuage doit être dans sa position finale. Je le mets, puis je fais l’opération inverse (copie du nuage sur les calques précédents et mouvement de 35,84 pixels jusqu’à ce qu’il sorte du cadre). Avec toutes ces copies, le fichier fait déjà 11Mio ! Je décide de diviser l’animation en plusieurs fichiers pour ne pas exploser la mémoire de ce pauvre Inkscape…

Le deuxième fichier SVG commence aux éclairs et termine quand le soldat est éjecté de l’écran. Pas grand-chose à dire, pas de formule mathématique ici, j’ai animé en essayant/regardant/corrigeant jusqu’à arriver à un enchaînement qui me semblait bien. Mine de rien, le deuxième fichier fait déjà 20Mio… On passe au troisième fichier !

On commence par recentrer la « caméra » sur notre personnage : rien de bien compliqué, toute l’image bouge en même temps. On en profite pour lancer l’animation du manchot qui grattouille la terre. Rien de bien compliqué pour faire apparaître l’arbre dans une explosion de lumière 🙂

Mais c’est là que les choses se corsent : il faut que je termine en bouclant sur le début, il faut donc que la dernière image se raccorde avec la première. J’ai déjà prévu un fond raccordable, par contre mon personnage a un peu bougé à l’arrache avec le combat et le plantage d’arbre. Et en plus, horreur et damnation, je me rends compte que mon bel arbre dépasse sur la partie de l’image qui apparaît sur la première image !

Aaaargh ! Trois solutions :

• Tout refaire pour placer l’éclair, l’arbre et cie. plus à gauche (non mais ça va pas la tête ?!)
• Recoller le morceau d’arbre sur les premières images pour rester cohérent (mais du coup ce serait bizarre de le voir dès le début)
• Utiliser un habile trucage 🙂

Et c’est la dernière solution (la plus feignasse, j’assume) que j’ai choisie. Et je suis assez content parce que cette petite « triche » ne se voit pratiquement pas (sauf si on le sait). Vous l’avez vue ? Eh bien c’est simple : l’arbre bouge plus vite que le fond sur les dernières images ! De telle sorte qu’il semble naturel qu’il soit sorti de l’image quand on revient sur la première image…

Bon, n’empêche que c’est quand même un peu le bazar, puisque tout doit un peu bouger pour retourner à la position initiale :

• Par rapport au fond, le manchot doit avancer de 327 pixels
• Pour retrouver sa position initiale (sur le bord gauche de l’image), le manchot doit reculer de 80 pixel
• Le fond doit reculer de 400 pixels
• L’arbre doit reculer de 585 pixels

Puisque par rapport au fond, le manchot doit avancer de 327 pixels, on peut calculer le nombre de « pas » qu’il doit faire (= le nombre d’images dans la boucle de marche). On se rappelle que manchot faisait 35,84 pixels par pas au début. Pour parcourir 327 pixels, il lui faut donc 9,12 pas (arrondis à 9). Maintenant qu’on connaît le nombre d’images nécessaires et les déplacements à faire, il n’y a plus qu’à enchaîner ! Pendant 9 images :

• Le manchot bouge de 8,89 pixels
• Le fond bouge de 44,44 pixels
• L’arbre bouge de 65 pixels (sans le problème décrit plus haut, il aurait dû bouger à la même vitesse que le fond, ici il est 46% plus rapide !)

Et voilà ! Nous avons maintenant toutes nos images, y’a plus qu’à assembler !

Scriptons

On est quand même à 3 fichiers SVG qui totalisent 50Mio et 81 calques. Hors de question de se taper les exportations à la main (surtout que je veux pouvoir facilement tester et changer des choses). Du coup, c’est l’heure de scripter. J’ai choisi le Ruby pour plusieurs raisons :

• Déjà, parce que c’est ce que j’utilise en général quand je dois scripter (du coup je maîtrise mieux — mais pas tant que ça vu que je ne scripte pas si souvent)
• C’est un langage relativement dégueulasse (on peut écrire à peu près n’importe quoi) mais qui du coup est simple à faire fonctionner
• C’est rigolo comme langage 🙂

Tout d’abord, comme je l’ai dit en introduction, il faut savoir qu’Inkscape a un mode ligne de commande, et c’est super ! On peut choisir d’exporter un fichier en PNG avec la taille que l’on veut et en sélectionner un objet de la scène. Et ça tombe bien, puisque mes calques sont des objets et qu’en sélectionnant chaque calque un par un dans l’ordre des numéros, on obtient toutes les images de l’animation dans le bon ordre.

Et là, il y a un hic : pour choisir un objet, Inkscape veut qu’on lui donne son ID. Sauf que son ID n’a rien à voir avec le Nom qu’on lui a donné dans Inkscape. Nom que j’avais pris soin d’écrire imgXXX (avec XXX le numéro de l’image). Groumpf. Qu’à cela ne tienne, en faisant un petit grep, on se rend vite compte que les attributs id et name d’un calque sont juste à côté. On commence donc par récupérer l’ID correspondant à chaque calque avec un petit hack un peu crade mais qui marche :

Ensuite, une fois qu’on a récupéré les bons ID associés aux bons noms, on peut lancer l’exportation des calques vers des PNG avec une bête boucle et un appel à Inkscape :

Il ne reste plus qu’à compiler le GIF à l’aide d’ImageMagick. La façon la plus simple de faire est celle-ci :

Mais dans mon cas, je souhaite que certaines frames soient plus longues que d’autres (par exemple, celles où le soldat parle). Dans ce cas-là, j’écris la commande ImageMagick frame par frame en précisant la durée à chaque fois (notez qu’on pourrait ne préciser la durée par défaut qu’après chaque frame qui ne l’utilise pas, mais bon, c’est le script qui s’en charge alors peu importe). J’ai oublié de le copier/coller, mais la variable delay est égale à 10 bien sûr.

ET VOILÀ !

Notre GIF est tout prêt, tout beau. Ensuite, il y a encore moyen de réduire le poids du GIF en réduisant la qualité etc. J’ai aussi généré pas mal de variantes avec des changements de couleur (via des scripts aussi), mais je vous passe les détails. J’arrête là pour le making-of, car si je commence à vous parler de la vidéo (et du son), on n’est pas rendus 🙂

Vous pouvez télécharger le script complet (et éventuellement les sources, mais même compressé, c’est gros !). Tout est libre, toujours sous licence CC-By-Sa.

Faites tourner ! Et bon dimanche 😉