Source : Sony sort un disque de Bob Dylan uniquement pour éviter le domaine public (Numerama)

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

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sky, LIAR, lerouge, yann, Goofy, peupleLa, KoS, Nys, Julius22, okram, 4nti7rust, zn01wr, lamessen

Des sauvegardes pour votre santé mentale

Austin Appel

Austin Appel, alias « scorche », est un professionnel de la sécurité informatique qui passe son temps à casser (il est dûment autorisé, évidemment) des choses précédemment réputées sécurisées. On le croise souvent enseignant le crochetage de serrure durant des conférences de sécurité et de hacking. Dans le monde de l’open source, il fait une foule de choses pour le projet Rockbox et a œuvré bénévolement pour le projet One Laptop Per Child (un ordinateur portable par enfant).

Les sauvegardes c’est bien. Les sauvegardes c’est super. Un administrateur compétent fait toujours des sauvegardes régulières. On apprend ça dans n’importe quel manuel traitant de l’administration des serveurs. Le problème c’est que les sauvegardes ne sont vraiment utiles qu’en cas d’absolue nécessité. Lorsque quelque chose de grave arrive au serveur ou à ses données et qu’on est forcé de se replier sur autre chose, les sauvegardes viendront à point nommé. Cependant, cela ne devrait jamais arriver, n’est-ce pas ? À n’importe quel autre moment, à quoi cela sert-il pour vous et votre environnement serveur d’avoir des sauvegardes ?

Avant d’aller plus loin, il est important de noter que ce conseil vaut pour les administrateurs serveurs des plus petits projets open source — la majorité silencieuse. Si vous maintenez des services qui vont engendrer une grande frustration, et même peut-être faire du tort s’ils sont indisponibles, vous devriez considérer ceci avec la plus grande circonspection.

Pour le reste d’entre nous qui travaillons sur d’innombrables petits projets ayant des ressources limitées, nous avons rarement deux serveurs séparés pour la production et les tests. En vérité, avec tous les services qu’un projet open source doit maintenir (système de gestion de version, services web, listes de diffusion, forums, ferme de compilation, bases de données, traceurs de bogues ou de fonctionnalités, etc.), des environnements de test séparés sont souvent de l’ordre du rêve. Malheureusement, l’approche courante de l’administration systèmes est d’avancer avec précaution et mettre les systèmes à jour uniquement en cas de nécessité absolue, afin d’éviter tout problème de dépendance, de code cassé, ou n’importe laquelle des millions de choses qui pourraient mal se dérouler. La raison pour laquelle vous êtes nerveux n’est pas que vous pourriez manquer d’expérience. Il est important de savoir que vous n’êtes pas seul dans ce cas. Que nous l’admettions ou non, beaucoup d’entre nous ont été (et sont probablement encore) dans cette situation. Il est triste que cette inaction — découlant de la peur de détruire un système fonctionnel — conduise souvent à des services en fonctionnement qui ont souvent plusieurs versions de retard, ce qui implique de nombreuses failles de sécurité potentiellement sérieuses. Cependant, soyez assuré que ce n’est pas la seule manière de jouer le jeu.

Les gens ont tendance à jouer un jeu différent selon qu’ils aient une infinité de vies ou qu’ils doivent recommencer depuis le début dès lors qu’une seule erreur a été commise. Pourquoi devrait-il en être autrement pour de l’administration systèmes ? Aborder le concept de sauvegardes avec un état d’esprit offensif peut complétement changer votre conception de l’administration systèmes. Au lieu de vivre dans la peur d’une dist-upgrade complète (ou de son équivalent pour yum, pacman, etc.), celui qui est armé de sauvegardes est libre de mettre à jour les paquets d’un serveur, confiant dans le fait que ces changements pourront être annulés si les choses tournent au vinaigre. La clé du succès réside tout entière dans l’état d’esprit. Il n’y a aucune raison d’avoir peur tant que vous avez vos données sauvegardées sous la main comme filet de sécurité lorsque vous sautez le pas. Après tout, l’administration système est une expérience d’apprentissage permanente.

Bien sûr, si vous ne validez pas vos sauvegardes, vous reposer sur elles devient un jeu très dangereux. Heureusement, les administrateurs systèmes expérimentés savent que le commandement « Garde des sauvegardes à jour » est toujours suivi par « Valide tes sauvegardes ». À nouveau, c’est un mantra que les gens aiment réciter. Ce qui, en revanche, ne tient pas de façon élégante dans un mantra entraînant est la manière de valider rapidement et simplement ses sauvegardes. La meilleure manière de dire qu’une sauvegarde est fonctionnelle est, bien sûr, de la restaurer (de préférence sur un système identique qui n’est pas en cours d’utilisation). Mais, une fois encore, en l’absence d’un tel luxe, on doit faire preuve d’un peu plus de créativité. C’est là (tout du moins pour les fichiers) que les sommes de contrôle peuvent vous aider à vérifier l’intégrité de vos fichiers sauvegardés. Dans rsync, par exemple, la méthode utilisée par défaut pour déterminer quels fichiers ont été modifiés consiste à regarder la date et l’heure de la dernière modification, ainsi que la taille du fichier. Cependant, en utilisant l’option ‘-c’, rsync utilisera une somme de contrôle MD4 de 128 bits pour déterminer si les fichiers ont changé ou non. Bien que ce ne soit pas toujours la meilleure idée à mettre en œuvre à chaque fois en toute occasion — à cause d’un temps d’exécution beaucoup plus long qu’un rsync normal et d’une utilisation accrue des accès disques — cette méthode permet de s’assurer que les fichiers sont intègres.

Le rôle d’un administrateur systèmes peut être éprouvant par moments. Il n’est cependant pas nécessaire de le rendre plus stressant que nécessaire. Avec le bon état d’esprit, certaines commandes de précaution apparemment à but unique et limité peuvent être utilisées comme des outils précieux qui vous permettent de progresser de façon agile, tout en gardant votre santé mentale intacte et la vitesse tant appréciée dans les projets open source.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang :lerouge, lamessen, CoudCoud, Kev, peupleLa (relectures),Goofy, Jej, Julius22, kalupa, 4nti7rust, ga3lig, Tsigorf, maat

Aimer l’inconnu

Jeff Mitchell

Jeff Mitchell passe ses journées de travail à s’activer sur tout ce qui touche aux ordinateurs et aux réseaux et son temps libre à barboter dans toutes sortes de projets de logiciels libres et open source. Ce qu’il préfère c’est la convergence des deux. Après avoir travaillé en tant qu’administrateur systèmes professionnel de 1999 à 2005, il maintient son niveau de compétences en les mettant bénévolement au service de projets libres en divers lieux. Ces temps-ci, son activité pour le Libre est dédiée à l’administration systèmes pour KDE¹ et c’est l’un des développeurs principaux du lecteur Tomahawk². Jeff vit actuellement à Boston, aux États-Unis.

Récemment, à mon travail, j’ai fait partie d’une équipe qui faisait passer les entretiens d’embauche pour un poste d’administrateur systèmes. Après avoir parcouru quelques dizaines de curriculum vitae nous avons finalement convoqué notre premier candidat. Celui-ci — appelons-le John — avait aussi bien l’expérience de petites structures, style laboratoire informatique, que de plus vastes opérations dans des centres de données. À première vue, les choses se présentaient bien, si ce n’est qu’il avait eu cette réponse bizarre à quelques-unes de nos questions : « je suis administrateur systèmes ». Le sens de cette phrase n’a pas été immédiatement clair pour nous, jusqu’à ce que l’échange suivant ait lieu :

Moi : Donc, vous avez dit que vous n’avez pas d’expérience avec Cisco IOS, mais qu’en est-il des réseaux en général ?

John : Eh bien, je suis administrateur systèmes.

Moi : Oui, mais que diriez-vous sur les concepts de réseau ? Les protocoles de routage comme BGP ou OSPF, les VLANs, les ponts réseaux…    

John, exaspéré : Je suis administrateur systèmes.

C’est à ce moment-là que nous avons compris ce qu’il voulait dire. John ne nous disait pas qu’il connaissait toutes ces choses que nous lui demandions puisqu’il était administrateur systèmes ; il nous expliquait que parce qu‘il était administrateur systèmes, il n’en savait rien. John était administrateur systèmes et cela signifiait pour lui que ces tâches étaient celles d’un administrateur réseau. Sans surprise, John n’a pas obtenu le poste.

Dans bien des projets open source, la spécialisation est une malédiction et non une bénédiction. Qu’un projet relève d’une catégorie ou l’autre dépend souvent de la taille de l’équipe de développement ; la spécialisation à l’extrême peut entraîner de graves perturbations dans un projet en cas de départ d’un développeur, que ce soit en bons ou mauvais termes, qu’on le regrette ou non. Il en va de même pour les administrateurs systèmes de projets open source, bien que la pénurie générale de ces derniers semble autoriser aux projets une marge de tolérance parfois dangereuse.

L’exemple le plus flagrant qui me vienne à l’esprit impliquait un projet spécifique dont le site de documentation (y compris toute celle de l’installation et de la configuration) était indisponible depuis plus d’un mois. La raison : le serveur était en panne et la seule personne qui en avait l’accès naviguait sur un « bateau pirate » avec les membres du parti pirate suédois. C’est une histoire vraie.

Cependant, tous les points de défaillance ne sont pas dus à l’absence des administrateurs systèmes ; certains sont artificiels. Sur un gros projet, les décisions des droits d’accès à l’administration systèmes étaient assumées par un seul administrateur. Il ne s’était pas seulement réservé certains droits d’accès uniquement pour lui-même (vous l’avez deviné : oui, il a disparu pendant un certain temps, et oui, cela a causé des problèmes) ; il avait aussi décidé de la façon dont les droits d’accès devaient être accordés, en fonction de la confiance qu’il portait personnellement au candidat. La « confiance », dans ce cas, se fondait sur une seule chose : non pas le nombre de membres de la communauté qui se portait garant pour cette personne, ni depuis combien de temps cette personne était un contributeur actif et de confiance pour le projet, ni même depuis combien de temps il connaissait lui-même cette personne dans le cadre de ce projet. Au lieu de cela, elle reposait sur la façon dont il connaissait personnellement quelqu’un, ce par quoi il entendait la façon dont il connaissait cet individu en personne. Vous imaginez bien à quel point cela est adapté à une équipe d’administrateurs systèmes disséminée sur toute la planète…

Bien sûr, cet exemple ne fait qu’illustrer la grande difficulté pour un administrateur systèmes open source de trouver le juste milieu entre sécurité et capacité. Les grandes entreprises peuvent se permettre d’avoir du personnel redondant, et ce, même si le travail se répartit selon différentes responsabilités ou domaines de sécurité. La redondance est importante. Mais qu’en est-il si la seule possibilité d’avoir une redondance pour l’administrateur systèmes est de prendre la première personne se présentant au hasard sur votre canal IRC ou une personne quelconque proposant son aide ? Comment pouvez-vous raisonnablement avoir confiance en cette personne, ses capacités et sa motivation ? Malheureusement, seuls les contributeurs principaux du projet ou une petite partie d’entre eux peuvent savoir quand la bonne personne se présente en utilisant le même modèle de toile de confiance³ qui sous-tend une grande partie du reste du monde open source. L’univers des projets open source, leurs besoins et les personnes qui veulent contribuer à un projet particulier forment une extraordinaire diversité ; par conséquent, la dynamique humaine, la confiance, l’intuition et la manière d’appliquer ces concepts à un projet open source sont de vastes sujets, bien au-delà de la thématique de ce court article.

Une chose importante a cependant facilité la découverte de cette ligne d’équilibre sécurité/capacité : l’essor des systèmes de gestion de versions distribués, ou DVCS (NdT : Distributed Version Control System, système de gestion de version distribué). Auparavant, les contrôles d’accès étaient primordiaux car le cœur de tout projet open source — son code source — était centralisé. Je me rends bien compte que beaucoup doivent penser : « Jeff, tu devrais pourtant le savoir, le cœur d’un projet, c’est sa communauté, pas son code ! ». Ma réponse est simple : les membres de la communauté vont et viennent, mais, si quelqu’un fait accidentellement un « rm -rf » sur tout l’arbre du système de gestion de versions de votre projet et que vous manquez de sauvegardes, combien de ces membres de la communauté vont continuer à s’investir dans le projet et aider à tout recommencer à zéro ? (Mes propos se basent sur une histoire vraie dans laquelle un membre de la communauté saoul qui s’énervait à déboguer un bout de code, lança un « rm -rf » sur toute sa contribution, avec l’intention de supprimer tout le code du projet. Par chance, il n’était pas administrateur systèmes et n’avait donc pas accès au dépôt central, et il était trop saoul pour se rappeler qu’il travaillait seulement sur une copie du projet.)

Le code du projet est son cœur ; les membres de sa communauté en sont l’énergie vitale. Privé de l’un ou de l’autre, vous aurez du mal à garder un projet vivant. Avec un logiciel de gestion de version (NdT : VCS pour version control system) centralisé, si vous n’avez pas eu la présence d’esprit de mettre en place un système de sauvegarde régulier, vous pourriez, avec de la chance, ré-assembler l’arborescence complète du code source à partir des différents éléments contribués qu’auront gardés les autres personnes. Mais pour la majorité des projets, l’historique du code est aussi important que le code lui-même et cela, vous l’aurez tout de même entièrement perdu.

Ce n’est plus le cas désormais. Quand tous les clones locaux ont tout l’historique du projet et que des sauvegardes de secours peuvent être effectuées chaque nuit, en lançant une tâche planifiée aussi simple que « git pull », les dépôts centralisés ne sont plus que des outils de coordination. Cela en diminue l’importance de quelques degrés. Le projet doit toujours être protégé contre les menaces aussi bien internes qu’externes : les systèmes non corrigés sont toujours vulnérables à des exploits bien connus. Un administrateur systèmes malveillant peut tout mettre sans dessus dessous, un système d’authentification déficient peut permettre l’entrée de codes malveillants dans la base, et un « rm -rf » accidentel sur le dépôt central peut toujours coûter cher en temps de développement. Mais ces défis peuvent être surmontés, et à l’ère des serveurs privés virtuels (VPS) abordables et des centres d’hébergement de données, les absences des administrateurs systèmes peuvent également être compensées. (Il vaut mieux cependant s’assurer d’avoir un accès redondant au DNS ! Oh et mettez aussi vos sites internet sur un dépôt vérifié et certifié [DVCS] , et faites des branches pour les modifications locales. Vous me remercierez plus tard.)

Les DVCS permettent la redondance du cœur de votre projet pour trois fois rien, ce qui est une bonne façon d’aider les administrateurs systèmes à dormir la nuit et nous donne l’impression d’être un peu des maîtres du temps. Cela veut aussi dire que si vous n’êtes pas sur un DVCS, arrêtez de lire immédiatement et passez sur l’un d’eux. Ce n’est pas qu’une question d’espace de travail et d’outils. Si vous vous souciez de la sécurité de votre code et de votre projet, vous migrerez.

La redondance du code source est une nécessité, et en général plus vous avez de redondances, plus vos systèmes sont robustes. Il semble aussi évident que vous voulez une redondance de vos administrateurs systèmes ; ce qui vous semblera peut-être moins évident, c’est que l’importance de la redondance ne se joue pas tant en termes de personnes qu’en termes de niveau des compétences. John, l’administrateur systèmes, a travaillé dans des centre de stockage des données et au sein d’entreprises qui avaient des systèmes d’administration redondants mais des niveaux de compétences rigides, définis. Cela fonctionne dans de grandes entreprises qui peuvent payer pour embaucher de nouveaux administrateurs systèmes avec des compétences à la carte. Mais la plupart des projets open source n’ont pas ce luxe. Vous devez faire avec ce que vous avez. Cela veut dire bien sûr que, pour que l’administration systèmes soit redondante, une solution — et c’est parfois la seule — consiste à répartir la charge : d’autres membres du projet prenne chacun  une ou deux compétences jusqu’à ce qu’il y ait redondance.

Il n’y a guère de différence entre le côté développement et le côté créatif d’un projet ; si la moitié de votre programme est écrite en C++, l’autre moitié en Python, et qu’un seul développeur sait programmer en Python, son départ du projet provoquera de gros problèmes à court terme et pourrait aussi causer de sérieux problèmes à plus long terme. Encourager les développeurs à se diversifier et à se familiariser avec d’autres langages, paradigmes, bibliothèques, etc. entraîne que chacun de vos développeurs gagne en valeur ; cela ne devrait pas choquer : l’acquisition de nouvelles compétences est le résultat d’un apprentissage qui se poursuit tout au long de la vie, et un personnel mieux formé a aussi plus de valeur. (Cela rend aussi le curriculum vitae de chacun plus attractif, ce qui devrait être une bonne motivation.)

La plupart des développeurs open source que je connais considèrent comme un défi et un plaisir de s’aventurer sur de nouveaux territoires : c’est justement ce genre d’état d’esprit qui les a menés à développer de l’open source au départ. De même, les administrateurs de systèmes open source sont une denrée rare, et ne peuvent se permettre de s’enliser dans une routine. De nouvelles technologies intéressantes pour les administrateurs systèmes apparaissent constamment et il existe souvent de nouvelles façons d’utiliser des technologies actuelles ou anciennes afin de renforcer l’infrastructure ou d’améliorer leur efficacité.

John n’était pas un bon candidat parce qu’il apportait peu de valeur ajoutée ; et il apportait peu de valeur car il n’était jamais allé au-delà des limites du rôle qui lui était attribué. Les administrateurs systèmes open source qui tombent dans ce piège ne nuisent pas seulement  au projet dans lequel ils sont impliqués sur le moment, ils réduisent  leur valeur pour d’autres projets utilisant des technologies d’infrastructure différentes et qui auraient vraiment besoin d’un coup de main ; cela diminue les capacités globales de la communauté open source. Pour un administrateur de logiciel libre efficace, il n’existe pas de zone de confort.

1. http://www.kde.org/ ^{^}
2. http://www.tomahawk-player.org/ ^{^}
3. http://fr.wikipedia.org/wiki/Toile_de_confiance ^{^}

Que les gros salaires lèvent le doigt, surtout en temps de crise… Mais ce qu’il y a peut-être de plus intéressant dans l’affaire Depardieu, ce qu’elle a rebondi sur une mise en accusation globale du financement du cinéma français, grâce à une tribune mordante de Vincent Maraval dans Le Monde.

On notera au passage que c’est un producteur qui a mis les pieds dans le plat et non un journaliste, ce qui en dit long sur l’inféodation d’une profession qui préfère se voiler la face en se cantonnant à voir des films (gratos) en pondant leur anecdotique et souvent insignifiant « J’aime / J’aime pas ».

« Le système est sclérosé », surenchérit ici Jérémie Nestel, du collectif Libre Accès, en insistant sur une revendication dont le persistant refus devient de plus en plus difficile à justifier : ce qui est financé sur fonds publics doit être placé tôt ou tard sous licence libre. Tard ce serait ici pas plus d’une dizaine d’années en n’attendant surtout pas la trop lointaine échéance du domaine public, 70 ans après les morts de tous les protagonistes d’un film !

Musique, littérature, cinéma… Internet révèle chaque jour davantage une culture soumise à l’industrie culturelle qui ne profite qu’à une minorité, qui criminalise le partage et qui ne peut ou veut s’adapter à son époque.

Pour un cinéma promouvant le droit au partage

URL d’origine du document

Jérémie Nestel - 6 janvier 2013 - Libre Accès
Licence Art Libre

Notre mémoire collective contribue à forger une morale commune fait de références similaires.

Cette mémoire collective repose essentiellement sur « des œuvres de l’esprit ».

L’incapacité des politiques à préserver les biens communs dont ceux issus des œuvres de l’esprit annonce la fin du contrat social de notre société.

Pourquoi aliéner notre liberté à une société privilégiant des intérêts particuliers à l’intérêt général ?

Les débats autour d’Hadopi, du droit d’auteur et des nouvelles taxes demandées au public pour financer des rentes à vie aux stars des médias et aux multinationales du divertissement trouvent un écho à deux articles du monde commentant l’exil fiscal de Depardieu.

Tout d’abord ce premier article du Monde « Depardieu, enfant perdu de la patrie » faisant le parallèle entre la volonté de Depardieu de renoncer à sa nationalité et une thèse de Pierre Maillot sur l’identification des Français aux acteurs.

L’article suggère que « le Français qui se reconnaît dans Depardieu se reconnaît perdu ». En choisissant l’exil et « sa déchéance nationale » Depardieu devient le symbole d’une France dont le lien social est brisé.

Le deuxième article du Monde « Les artistes français sont trop payés », coup de gueule du producteur Vincent Maraval, qui relativise l’exil de Depardieu au regard des salaires indécents des acteurs du cinéma Français.

On y apprend que le salaire des acteurs n’est pas lié à la recette commerciale de leur film mais à leur capacité à obtenir les fonds cumulés du CNC, des taxes, des avantages fiscaux et de la télévision publique.

« Est-il normal qu’un Daniel Auteuil, dont les quatre derniers films représentent des échecs financiers de taille, continue à toucher des cachets de 1,5 million d’euros sur des films coproduits par France Télévision ? »

Cet article nous apprend qu’aucune des grandes productions françaises ne doit sa viabilité économique à son exploitation commerciale mais uniquement au financement public direct ou indirect.

Ces fonds publics ne servent pas à faire émerger une esthétique cinématographique française mais à maintenir une société d’acteurs et de producteurs percevant des millions.

Système complètement sclérosé où les réseaux de distribution des salles de cinéma et des chaînes de télévision sont saturés par des grosses productions françaises ou américaines et incapables de s’adapter à la démocratisation des outils numériques de production cinématographique et à la multiplicité des réalisateurs !

L’article de Maraval aura donné lieu à des réactions en chaîne du milieu du cinéma, Libération annonçant même une série de conférences dédiées.

On y apprendra pèle mêle :

Thomas Langmann : « Le système d’avance sur recette du CNC, symbole de l’exception culturelle française, est devenu un comité de copinage. Formé de trois collèges, les choix de l’avance sur recettes restent entièrement à la discrétion de ces commissions. ».

Olivier Bomsel : « Les chaînes françaises n’achètent donc que des créneaux de diffusion : leur seul actif est la valorisation instantanée par la diffusion ».

C’est peut-être là le plus grand scandale, au final. Qu’importe que des acteurs perçoivent des millions comme Daniel Auteuil grâce à des fonds publics, mais pourquoi priver les Français de leur droit au partage sur des productions qu’ils ont contribué à financer ?

Si Canal plus avec Studio Canal détient un catalogue grâce aux films qu’ils ont produits, pourquoi interdire ce droit aux chaînes publiques, chaînes publiques qui appartiennent aux Français ?

La société française est prise en otage d’une économie cinématographique et musicale défaillante ne pouvant se maintenir qu’en exigeant toujours plus de taxes, et en privant les français de leur droit au partage. Dans ce contexte surprenante intervention de la ministre de la Culture Aurélie Filippetti, à la tribune de Maraval, pour affirmer que le mode de financement du cinéma est « un un système vertueux ». Pour pérenniser un système défaillant on ne parlera pas d’une nouvelle économie bâtie sur le partage mais de régulation.

En toile de fond, de l’affaire Depardieu, on retiendra sa capacité à mobiliser sur une affaire somme toute personnelle, deux présidents de la République : Incroyable pouvoir d’influence des acteurs du cinéma sur le politique !

Ce n’est donc pas demain qu’un Ministre de la Culture affirmera que tout film produit à l’aide de financement public (CNC, de France Télévision, aides régionales, Européenne etc.) puisse être diffusé sous une licence libre favorisant le partage. L’appropriation « des catalogues de films » par les multinationales du divertissement vole à notre humanité des pans entiers de notre culture commune. Il n’est donc pas injuste de penser qu’au bout de dix ans d’exploitation un film puisse être diffusé sous une licence libre compte tenu que ceux qui l’ont réalisé ont déjà été rémunérés.

Le partage, l’échange de films qui ont marqué notre vie est un acte social à l’heure du numérique aussi banal que de chanter en famille des chansons en fin de dîner.

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

Vous avez peut-être remarqué dans les derniers articles publiés sur le framablog que quelques illustrations à l’humour approximatif étaient signées Gégé, le générateur de Geektionnerd. Ce petit jeu graphique vous est aujourd’hui offert en libre-service par Framasoft.

D’où vient-il ?

C’est une conception des Mozilla Labs dont on peut trouver toute la petite histoire et les caractéristiques techniques sur ce blog de Mozilla hacks. Pour simplifier, Willian Carvalho a voulu réaliser avec Canvas (traitement de l’image en JavaScript) ce qui existait seulement en Flash. C’est une chouette et amusante démonstration de ce qu’on peut faire désormais avec le HTML5, que Mozilla défend et promeut comme le langage du Web, plateforme ouverte de développement…

La version Framalab

C’est Cyrille (avec l’aide de Quentin pour la mise en ligne) qui a réalisé une adaptation francophone, avec la complicité de Simon “Gee” Giraudot qui a fourni les images. Vous pouvez trouver les sources librement disponibles sur le github, n’hésitez pas à le forker, à vous installer votre propre version avec vos images et à fabriquer vous-mêmes des bandes dessinées libres.

Comment ça marche ?

C’est vraiment simple et intuitif. Rendez-vous sur la page du générateur de Geektionnerd, choisissez et déplacez les éléments graphiques, saisissez du texte pour vos “bulles”, redimensionnez les éléments avec les flèches haut/bas du clavier et inversez-les avec les flèches droite/gauche. Vous pouvez enregistrer facilement vos créations ensuite.

…d’ailleurs n’hésitez pas à en faire profiter tout le monde, peut-être publierons-nous vos meileures réalisations ici, qui sait ?

Et Simon Giraudot, le voilà piraté ? Qu’en dit-il ?

Eh bien nous lui avons posé la question…

Quelle a été ta première réaction quand tu as découvert ce générateur ?

Très bonne ! Lorsque Cyrille a partagé la première version du générateur sur la liste de l’association Framasoft, tout le monde a commencé à jouer avec et à partager ses créations sur la liste. C’est assez marrant de voir mes personnages avec des mots qui ne sont pas les miens dans leur bouche !

D’une certaine façon c’est la continuité logique des créations libres que tu as réalisées avec la série des Geektionnerds ?

À priori c’est pareil. D’ailleurs, les dessins du générateur ne sont pas des dessins « exclusifs », ils sont en fait issus d’articles du blog (donc ils sont déjà sous CC-By-Sa !). Mais oui, c’est l’exacte continuité de ce que je propose dans le Geektionnerd. J’ai placé mes œuvres sous licence libre par conviction, parce que c’est comme ça que je vois « l’art » de manière générale. Le fait que les dessins soient librement modifiables n’est qu’une liberté, mais ça ne veut pas dire que vous allez forcément l’utiliser : grâce à ce générateur, on vous propose d’expérimenter cette liberté et de créer vos propres BD dérivées du Geektionnerd !

Tout le monde peut s’amuser avec ce petit générateur que nous te remercions d’avoir alimenté de tes dessins. Penses-tu que c’est juste un gadget sympathique ou que ça peut déclencher des vocations ?

L’un n’empêche pas l’autre, non ? ;) Blague à part, c’est surtout un outil de loisir, à mon sens. Ça reste du bidouillage de dessins et de textes, je ne me verrais pas réaliser une histoire complète avec ça, par exemple. Mais après, qui sait ? Avec les licences libres, les possibilités sont infinies : imaginez une personne qui a une idée géniale de scénario pour une BD, mais ne sait absolument pas dessiner. Grâce aux contributions que l’on met dans le pot commun de l’art libre (et je ne parle pas que de moi ici mais de tous les artistes libres), il pourrait tout à fait récupérer une énorme base de données de dessins et les arranger comme il le veut pour correspondre à son scénario. Sympa, non ?

Si l’on va un peu plus loin, ce genre de pratiques implique la fin de l’œuvre unique, puisque chacun peut utiliser, copier, remixer, re-créer et diffuser des comic strips ? l’analogie avec les 4 libertés du logiciel libre est frappante, non ?

Oui, c’est exactement ça. Pour autant, il ne faut pas voir ça comme une trahison de l’œuvre ou un manque de respect de l’auteur (ce genre d’argument revient souvent lorsqu’on parle de modifier les œuvres sans l’autorisation de l’auteur - un des principes d’une licence libre). L’œuvre originale, le Geektionnerd, reste une « œuvre unique », si l’on veut. La différence avec une œuvre sous régime de droit d’auteur classique, ce n’est pas que vous allez vous l’approprier et en faire ce que vous voulez : ça, honnêtement, vous le faites aussi avec des œuvres protégées.

La différence, c’est que là, non seulement personne ne viendra vous demander des comptes et vous traiter de voleur, mais en plus, on vous y encourage ! Tu parles de l’analogie avec les 4 libertés du logiciel libre : je pense aussi, personnellement, aux deux modèles que propose Florent Latrive dans son livre Du bon usage de la piraterie. Il explique que, classiquement, on aimait considérer les artistes comme des  « génies romantiques » qui avaient une inspiration naturelle et quasi-divine. Mais l’artiste est en fait plus proche du « hacker », qui s’approprie toutes les informations qui l’entourent pour créer quelque chose de nouveau. Tous les artistes passent leur temps à reprendre, copier, réutiliser les œuvres du passé. La licence libre ne fait que se mettre en accord avec cette réalité qui est pourtant loin d’être spécifique à l’art libre ! On connait la fameuse citation de Picasso, « Les bons artistes copient, les grands artistes volent ». Aurait-il mis ses œuvres sous licence libre si cela avait existé à son époque ? C’est une autre question ;)