PROJET AUTOBLOG


Framablog

source: Framablog

⇐ retour index

Geektionnerd : Dépêches Melba X

vendredi 8 mars 2013 à 14:41

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Sources :

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

S'intégrer au projet par l'action, sans attendre (Libres Conseils 31/42)

mercredi 6 mars 2013 à 16:15

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

Traduction Framalang : merlin8282, goofy, Corentin, lerouge, Asta, peupleLà, Alpha, lamessen, Julius22

Trouver ses marques dans une équipe de promotion

Stuart Jarvis

Stuart Jarvis a commencé à travailler avec l’équipe de promotion de KDE en 2008 en écrivant des articles pour le site web d’actualités de KDE. Il a appris à la dure comment faire bouger les choses dans une communauté du logiciel libre et participe davantage aux activités de l’équipe de promotion en écrivant les annonces des nouvelles versions de KDE et en rédigeant des articles sur les logiciels KDE dans la presse Linux. Il siège maintenant dans le groupe de travail marketing de KDE, contribue à définir la ligne de conduite pour la promotion de KDE et les activités marketing et aide les nouveaux contributeurs à trouver leurs marques. Il fait maintenant aussi partie de l’équipe éditoriale de KDE.News, là où il a commencé à participer.

« C’est celui qui code qui décide » est le mantra du développement dans le logiciel libre. Mais que faire quand il n’y a pas de code ?

Rejoindre l’équipe de promotion et de marketing de votre projet de logiciel libre préféré représente un défi particulier. Pour les nouveaux codeurs, la plupart des projets ont des systèmes de révision du code, des mainteneurs et des pré-versions du logiciel qui les aident à mettre en évidence les erreurs dans le code, ce qui rend moins effrayante la contribution à leur premier correctif.

La promotion peut nécessiter que votre travail soit visible par le public, après une relecture minimale, parfois immédiatement. La nature non-hiérarchisée des communautés de logiciel libre implique qu’il y a rarement une unique personne vers qui vous pouvez vous tourner et qui pourra vous dire si vos idées sont bonnes et prendre des responsabilités à votre place.

Obtenir un consensus versus obtenir des résultats

J’ai d’abord commencé à contribuer à KDE en écrivant des articles pour le site d’actus officiel, KDE.News. J’avais déjà écrit pour des organes de presse, mais j’avais toujours affaire à une personne bien identifiée à qui j’envoyais un brouillon pour avoir un retour et faire les corrections demandées. Dans l’équipe de promotion de KDE, il n’y avait pas une seule personne ou un seul groupe de personnes pour assumer cette tâche. Je devais essayer, juger aux réponses que j’avais sur les brouillons d’articles et décider si j’avais tous les retours dont j’avais besoin et si l’article était prêt pour une publication.

Avec les conseils de contributeurs plus expérimentés, j’ai finalement appris à proposer quelque chose et à le publier en quelques jours s’il n’y avait pas d’objection majeure. Cette approche peut être utilisée par n’importe quel contributeur d’une équipe de promotion de logiciel libre, qu’il soit nouveau ou ancien.

Tout d’abord, travaillez sur la façon dont vous feriez quelque chose, que ce soit écrire un article, changer le texte d’un site web ou donner une conférence dans votre école locale. Planifiez, écrivez l’article ou le nouveau texte. Envoyez vos idées, pour relecture, sur la liste de diffusion de l’équipe de promotion de votre organisation. Surtout, ne demandez pas aux gens ce qu’ils en pensent — vous pourriez attendre des jours ou des semaines sans obtenir de réponse définitive. Signalez plutôt que vous allez publier ou soumettre votre texte, ou mettre en œuvre votre programme à telle date précise, en attendant les objections d’ici là.

Lorsque vous soumettez une date limite, pensez au temps nécessaire à chaque membre actif de l’équipe pour lire ses messages et évaluer votre proposition. Vingt-quatre heures est un minimum absolu pour un simple oui ou non en réponse à une question fermée. Lorsqu’il s’agit de quelque chose nécessitant une lecture ou une recherche, vous devriez envisager un délai de réponse de plusieurs jours.

Si la date limite que vous fixez ne rencontre pas une forte opposition, vous pouvez avancer. S’il existe de gros problèmes par rapport à votre projet, quelqu’un vous le dira. Les choses se font, en réalité. Vous ne serez pas frustré par un manque de progrès et vous aurez la réputation de mener à bien les tâches.

Finalement, c’est vous qui décidez

Les communautés du logiciel libre peuvent facilement devenir des groupes de discussion. Tout le monde a son opinion. Si vous n’êtes pas prudent, les discussions peuvent s’éterniser, s’évanouir au fur et à mesure que les personnes s’en désintéressent et finir sans conclusion convaincante. Cela peut paraître assez difficile à gérer lorsque vous faites partie de la communauté depuis quelque temps : vous avez l’habitude de prendre vos propres décisions et d’avoir votre propre idée sur ceux dont les avis vous importent. Quand vous débutez, cela peut être très déroutant.

Si vous voulez que votre propre travail aboutisse, vous allez probablement devoir faire des choix entre des points de vue opposés. Vous pouvez mettre un terme au débat en donnant un résumé des points principaux et en donnant votre opinion sur ces points. Essayez de ne pas laisser de questions ouvertes en suspens, à moins que vous ne souhaitiez un débat plus long — donnez simplement vos conclusions et dites ce que vous allez faire. Dès lors que vous êtes correct, les autres personnes respecteront probablement votre avis, même si elles ne sont pas d’accord.

Soyez proactif - n’attendez pas qu’on vous demande

Le premier contact avec l’équipe de promotion que vous voulez rejoindre peut très bien être l’envoi d’un courriel sur leur liste de diffusion leur offrant vos compétences. Je pensais pouvoir énumérer mes points forts et espérer que les gens me suggéreraient des choses à faire. En pratique, ça ne fonctionne pas tout à fait comme ça.

La plupart des communautés manquent de volontaires et ont vraiment besoin de vos compétences. Mais comme elles manquent de volontaires, elles peuvent aussi manquer de temps pour donner de bons conseils et encadrer. Si vous voulez travailler sur une partie spécifique du projet, dites-le. Il est beaucoup plus facile pour quelqu’un du projet de dire simplement « Vas-y ! » plutôt que d’essayer d’arriver avec un projet qui correspond à vos compétences.

Même quand vous avez travaillé sur quelques projets et prouvé vos compétences, il y a peu de chances que vous soyez contacté directement pour une tâche. Ceux qui coordonnent l’équipe marketing ne connaîtront pas votre situation personnelle et peuvent donc être mal à l’aise à l’idée de vous demander quelque chose de particulier sur votre temps libre, gratuitement. Une communauté idéale va poster régulièrement — que ce soit sur une liste de diffusion ou une page web — les tâches que des volontaires peuvent prendre en charge. Si ce n’est pas le cas, trouvez vous-même des choses à faire et prévenez la liste de diffusion que vous êtes en train de les faire. Les gens vont le remarquer et cela augmente les chances que vous soyez directement contacté dans le futur.

Si vous êtes proactif, vous pouvez rapidement vous rendre compte que vous êtes l’une des personnes expérimentées de la communauté vers qui les nouveaux venus se tourneront pour avoir des conseils ou du travail à réaliser. Essayez de vous souvenir comment c’était quand vous avez commencé et faites en sorte de faciliter au maximum leur vie de nouveau contributeur.

Coordonner les flux de contributions (Libres Conseils 30/42)

lundi 4 mars 2013 à 15:56

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

Traduction Framasoft : merlin8282, Sphinx, Julius22, goofy, Corentin, lerouge, Asta, peupleLà, okram, Alpha, lamessen

Au confluent de l’amont et de l’aval

Vincent Untz

Vincent Untz est un activiste passionné du logiciel libre, un amoureux partisan de GNOME, ainsi qu’un élément moteur d’openSUSE. Il a été responsable des versions de GNOME de 2008 à 2011, jusqu’à la sortie de GNOME 3.0 ; il a été directeur exécutif de la fondation GNOME (2006-2010) et il dirige l’équipe GNOME chez openSUSE. Quoi qu’il en soit, il trouve plus simple de se décrire comme un « touche-à-tout » (NdT : en français dans le texte) et il travaille dans divers services (certains diraient au petit bonheur la chance) du bureau pour aider openSUSE à rester extraordinaire. Vincent continue à faire du forcing pour que le français soit la langue officielle de GNOME et espère bien réussir bientôt. Sinon, il aime la crème glacée.

Il y a bien longtemps, dans une chambre, la nuit…

J’étais en train de jeter un dernier coup d’œil sur une liste de bogues pour voir si je n’avais pas oublié de fusionner un correctif. Je m’étais bien assuré d’écrire ce que je pensais être une entrée NOUVEAUTÉS au sujet de la nouvelle version. J’ai entré make distcheck (NdT : commande GNU permettant de créer un paquet et de le tester automatiquement dans un répertoire différent de celui de développement pour démarrer le processus de diffusion) et je regardais la console afficher des centaines de lignes. Une archive avait été créée, et j’ai à nouveau vérifié que l’archive se construisait correctement. J’ai vérifié, encore et encore : j’étais inquiet. D’une certaine manière, je ne faisais pas totalement confiance à la commande make distcheck. Après avoir tout vérifié plusieurs fois, j’ai envoyé l’archive sur le serveur et expédié un courriel d’annonce.

J’avais réussi à le faire : j’avais sorti ma première archive d’un logiciel sur le développement dont j’étais récemment devenu co-responsable. Et j’ai certainement pensé : « Ah, maintenant les utilisateurs vont pouvoir apprécier un bon truc ! ». Mais à peine quelques secondes après le chargement de mon archive, quelques personnes l’ont téléchargée et ont rendu ma version réellement accessible aux utilisateurs.

C’est une chose que je tenais pour acquise, car je pensais que c’était une tâche banale. J’avais tort.

Amont et aval

De nombreuses personnes participent au processus d’acheminement du logiciel. Et cet effort se répartit généralement entre deux groupes de personnes d’égale importance dans la manière dont fonctionne le logiciel libre aujourd’hui.

En amont : c’est le groupe qui crée le logiciel. Il inclut évidemment les programmeurs mais, en fonction du projet, d’autres catégories de contributeurs sont également essentielles : designers, traducteurs, rédacteurs de documentation, testeurs, trieurs de bogues, etc. En général, l’amont se charge seulement de livrer le code source sous forme d’archive.

En aval : c’est le groupe responsable de la distribution du logiciel aux utilisateurs. Tout comme en amont, les contributeurs ont une gamme de profils très variée et travaillent à la traduction, la documentation, les tests, le triage de bogues, etc. Il y a cependant un profil qui, jusqu’à présent, est spécifique au travail en aval : le packager, qui prépare le logiciel afin de le rendre disponible sous forme de paquet, un format mieux adapté à un usage facile que le seul code source.

Chose intéressante, les utilisateurs ont plutôt bien l’intuition de cette séparation également, bien que nous n’en soyons pas conscients : nous supposons souvent que les développeurs de logiciels sont inaccessibles et nous envoyons plutôt nos retours et demandes d’aide aux distributeurs.

Pour éclairer cette séparation entre amont et aval, une analogie parlante et classique est celle du circuit des biens de consommation, avec les magasins de détail (« l’aval ») qui distribuent des produits manufacturés (« l’amont ») et jouent un rôle important pour les clients (« les utilisateurs »).

Un regard plus attentif sur l’aval

Si je devais résumer le rôle de l’aval en une phrase, voici comment je le décrirais :

L’aval est le pont entre les utilisateurs et l’amont.

Lorsque j’ai sorti ma première archive en amont, je supposais que, pour l’aval, le travail consisterait principalement à compiler la source pour construire un paquet avec, et rien d’autre. Construire un paquet est effectivement la première étape. Mais c’est seulement le début du voyage vers l’aval : différentes tâches viennent ensuite. Certaines sont purement techniques tandis que d’autres sont sociales. Je vais me contenter de décrire très brièvement ce voyage ici, de manière non-exhaustive, puisque ça pourrait faire l’objet d’un chapitre entier de ce livre (1).

La construction du paquet proprement dit peut se révéler moins triviale que prévu. Il n’est pas rare qu’un packager rencontre des problèmes qui étaient inconnus de l’amont. Comme lorsqu’une nouvelle version du compilateur est utilisée (avec de nouvelles erreurs), qu’une bibliothèque spécifique a d’abord besoin d’être mise à jour (parce que l’archive utilise de nouvelles interfaces de programmation) ou bien que le système de compilation de l’archive est conçu pour une certaine façon de fonctionner (qui ne suit pas les directives de la distribution cible). Ce qui est encore plus méconnu par beaucoup est le fait que tous ces problèmes peuvent également se produire après que l’archive a déjà été empaquetée, comme lors de la migration d’une distribution entière vers un nouveau compilateur ou bien une nouvelle chaîne de compilation. Aucun de ces problèmes techniques n’est vraiment compliqué à résoudre en lui-même, et l’amont est souvent content de contribuer à la solution. Mais sans l’aval, ces problèmes pourraient ne pas être remarqués par l’amont avant un long moment.

Ce qui selon moi est plus important que ces défis techniques, c’est que l’aval est généralement en contact avec davantage d’utilisateurs que l’amont. Cela se traduit par des rapports de bogue, des demandes de support, des requêtes de changement de la configuration par défaut ou bien d’autres choses encore. C’est là que la foule en aval donne la mesure éclatante de sa force : au lieu de simplement transférer ça en amont, l’aval va travailler sur les retours des utilisateurs afin de ne renvoyer que des synthèses qui seront utilisables en amont. Bien souvent, les rapports de bogue sont soumis avec trop peu d’informations sur le problème (auquel cas l’aval demandera plus de détails). Souvent, les demandes de support sont issues d’une incompréhension du côté de l’utilisateur (ce que l’aval peut, parfois, traduire par une suggestion visant à modifier le programme afin d’éviter cette incompréhension). Souvent, de nouveaux paramètres par défaut sont suggérés sans réflexion suffisante (l’aval travaillant alors avec les utilisateurs pour voir si le raisonnement est valide). À partir de cette énorme quantité de données, l’aval produira un ensemble d’informations plus compact que l’amont sera en mesure de digérer facilement. Ce qui amènera à des améliorations sur le logiciel.

Il existe généralement deux récompenses pour les contributeurs en aval : les contributions directes et indirectes vers le projet en amont grâce aux efforts effectués par l’aval sont suffisantes pour beaucoup. Mais plus important encore, le contact direct avec davantage d’utilisateurs amène à recueillir la satisfaction qu’ils expriment. Et une situation aussi gratifiante rend facilement heureux beaucoup de gens.

Une petite note au passage : lorsqu’on considère la quantité de travail fournie en aval, je ne serais pas surpris qu’au bout du compte, beaucoup de contributeurs en amont soient bien contents d’avoir des gens agissant comme intermédiaires : cela diminue significativement la quantité de retours tout en améliorant leur qualité (en évitant les commentaires en double, les problèmes non documentés, etc.). Cela permet à ceux qui travaillent en amont de rester focalisés sur le développement lui-même, au lieu de les obliger à soit trier les retours, soit les ignorer.

Rien qu’en regardant mon expérience en amont, je ne compte plus le nombre de correctifs que j’ai reçus de l’aval pour résoudre des problèmes de compilation. Je me rappelle aussi d’innombrables discussions que j’ai eues à propos des bogues qui affectaient le plus les utilisateurs et qui m’ont permis de prioriser mon travail. De fait, depuis que j’ai rejoint les équipes en aval, j’ai commencé à faire remonter des correctifs proches de ceux liés à des problèmes de compilation à l’amont et à discuter avec ma base en aval pour transmettre des retours d’expérience d’utilisateurs. Une telle collaboration amont-aval participe à l’amélioration de la qualité générale de notre écosystème du logiciel libre et je la considère comme essentielle à notre bonne santé.

Remonter de l’aval vers l’amont !

Je crois fermement que, pour qu’un projet réussisse, il faut qu’il y ait une forte collaboration amont-aval. Je doute que beaucoup désapprouvent. Cependant, par « aval », les gens pensent généralement au travail fait dans les distributions. Mais, particulièrement pour les applications, il devient de plus en plus viable de pousser ce travail fait en aval en dehors des distributions et de tirer parti d’un tel mouvement vers l’amont.

Des outils comme l’Open Build Service (NdT : distribution open source dédiée à la compilation de paquets pour diverses distributions GNU/Linux) permettent plus facilement d’avoir des personnes qui compilent et distribuent des paquets d’une application pour plusieurs distributions. Cela présente des avantages à la fois pour les utilisateurs (qui peuvent profiter plus rapidement et plus facilement des mises à jour de leurs applications préférées) et pour l’amont (qui peut aider à construire une relation plus forte avec sa base d’utilisateurs). Le seul défi qu’un tel mouvement représente est le besoin perpétuel d’avoir quelqu’un qui s’occupe de l’empaquetage, mais aussi qui gère des retours plus nombreux des utilisateurs. Dans les faits, il y a toujours besoin de quelqu’un pour faire le travail de l’aval, sauf qu’il serait fait au sein de la branche amont.

Pour moi, cela semble une perspective excitante et j’irais même plus loin en suggérant que nous, la communauté du logiciel libre, devrions migrer lentement le travail d’aval fait sur les distributions vers un travail d’aval fait directement, aussi souvent que possible, en amont. C’est souvent possible, au moins pour les applications. Cela requiert évidemment de penser différemment. Mais ça permettrait de partager un travail qui, actuellement, est le plus souvent dupliqué sur toutes les différentes branches en aval.

Pour ceux qui souhaitent actuellement commencer à contribuer aux applications qu’ils apprécient, ce travail sur les paquets en amont est une toute nouvelle approche qui pourrait vraiment être une réussite !

J’ai essayé, je suis resté. Pourquoi pas vous ?

L’aval a toujours été essentiel à ma vie en tant qu’utilisateur de logiciels libres — après tout, seules quelques personnes installent manuellement leur système à partir de zéro et je n’en fais pas partie. Cependant, c’est aussi devenu un atout pour moi en tant que développeur en amont, étant donné que j’ai commencé à prendre plus de temps pour discuter avec des personnes en aval afin d’obtenir plus de retours sur les bogues, les fonctionnalités, la qualité générale et même les directions futures du logiciel sur lequel je travaillais.

C’est seulement lorsque j’ai commencé à être moi-même en aval que j’ai compris que cette position est en effet privilégiée afin de conseiller en amont, grâce au contact direct avec les utilisateurs et la perspective différente que l’on retient de cette position différente.

Sans l’aval, nous ne serions pas là où nous sommes aujourd’hui. Si vous souhaitez avoir un impact significatif, soyez persuadé qu’en participant en aval et en discutant avec l’amont, vous réussirez.

Et vous y prendrez du plaisir.

(1) Note de l’auteur : Il est bon de mentionner que je ne crois pas que l’aval devrait modifier significativement le logiciel mis à disposition par l’amont. Certains, en aval, le font tout de même et cela s’ajoute à leur charge de travail.

Préparer un logiciel à sa diffusion (Libres conseils 29/42)

dimanche 3 mars 2013 à 07:05

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

Traduction Framalang : merlin8282, Sphinx, Julius22, goofy, lerouge, lamessen, Asta, peupleLà, okram

Packager : la voie royale du logiciel libre

Thorn May

Thom May est développeur Debian et membre émérite de la fondation Apache. Il a été parmi les premiers à être engagés chez Canonical, l’entreprise mère d’Ubuntu. Il vit aujourd’hui à Londres et dirige l’unité de développement chez MacMillan Digital Science.

Introduction

Ça fait plus de dix ans que j’ai débuté dans le monde du logiciel libre. J’avais utilisé Debian pendant quelques années à l’université et décidé que je voulais donner quelque chose en retour. J’ai donc commencé un long voyage à travers les étapes permettant de devenir un « nouveau responsable Debian » sans avoir jamais vraiment contribué au logiciel libre auparavant et inquiet qu’un manque d’expérience en C pourrait se révéler être un gros problème.

Il s’avéra que cette inquiétude était largement infondée. En commençant à travailler avec des paquets que j’utilisais régulièrement, j’ai pu contribuer efficacement. En même temps que mon expérience avec la myriade d’outils et de systèmes que Debian fournit à ses mainteneurs s’accroissait, je devenais plus efficace pour gérer mon temps et j’étais capable de travailler sur un ensemble de paquets plus étendu.

M’occuper de davantage de paquets m’amena à travailler avec un ensemble plus important de systèmes de compilation, de langages de programmation et de boîtes à outils. Cela m’aida également à m’intégrer à la communauté Debian. Aussi rugueuse et dogmatique soit-elle, le fait que la communauté Debian repose sur des mainteneurs doués et expérimentés est l’une des raisons principales pour lesquelles Debian a maintenu son excellence technique sur une si longue période.

À peu près à ce moment, le projet Apache httpd approchait enfin des premières versions bêta de httpd 2.0 qui était restée des années en chantier et était sur le point de subir une mise à jour majeure. L’équipe Apache de Debian avait été plutôt inactive depuis quelques temps — les paquets de la version 1.3 étaient stables et changeaient peu — et n’avait pas prévu d’empaqueter la version 2.0. J’avais un intérêt majeur à garantir que les paquets httpd étaient bien maintenus. Je travaillais comme administrateur système en charge de nombreux serveurs web Apache, il tombait donc sous le sens que je devais relever le défi de la production de paquets pour la nouvelle version.

Avec un ami, nous avons commencé le travail sur les paquets et nous avons rapidement découvert que, alors que le code approchait le niveau de qualité d’une bêta toute fraîche, l’outillage autour de la compilation et de la personnalisation de httpd était hélas manquants, ce qui est assez représentatif de bien des projets logiciels complexes.

Au cours de la majeure partie de l’année — alors que les développeurs en amont stabilisaient leur code et qu’un nombre croissant d’utilisateurs précoces commençaient à tester et à déployer la nouvelle version — nous avons travaillé dur pour garantir que le système de compilation soit suffisamment flexible et robuste pour satisfaire aux rigoureux prérequis de la politique de Debian. Nous devions non seulement garantir que nos paquets étaient techniquement corrects, mais également nous assurer que notre relation avec les développeurs en amont nous permettait de leur faire remonter des correctifs dès que possible, de les avertir dès que des problèmes de sécurité faisaient surface et de leur transmettre les tests préliminaires des versions candidates.

Mes interactions avec Apache pendant l’empaquetage et la maintenance de httpd 2.0 m’ont amené à m’engager en amont du projet, ce qui signifiait que je pouvais directement contribuer au code. C’est, en général, la dernière étape avant de passer de l’empaquetage d’un logiciel à son développement actif à destination d’un public plus large que celui de votre distribution. À titre personnel, cette reconnaissance m’a donné la confiance pour contribuer à bien plus de projets libres puisque je savais que mon code était de qualité suffisante pour être bien accueilli.

L’évolution, du packager au développeur

Comment est-ce arrivé ? La création de paquets, dans sa forme la plus simple, permet d’assurer qu’un projet logiciel donné se conforme à la politique de la distribution ; dans mon cas, Debian. De manière générale, cela signifie configurer le logiciel au moment de la compilation afin qu’il soit installé dans les répertoires idoines spécifiés par le Filesystem Hierarchy Standard, ou FHS (NdT : Norme de la hiérarchie des systèmes de fichiers), que les dépendances aux autres paquets soient correctement spécifiées et que les logiciels fonctionnent normalement sur la distribution.

La création de paquets complexes peut nécessiter la division d’un projet en amont en de multiples paquets. Par exemple, les bibliothèques et les fichiers d’en-tête permettant à l’utilisateur de compiler le logiciel avec leur bibliothèque sont fournis dans des paquets distincts, et des fichiers dépendant de la plate-forme peuvent être fournis séparément de ceux qui en sont indépendants. S’assurer que le logiciel en amont se déploie correctement dans ces situations nécessitera souvent des changements dans le code. Ces changements sont la première étape vers un travail actif sur un projet, plutôt que le travail parfois passif de création de paquet.

Une fois que votre paquet est disponible dans la distribution, il est exposé à des millions d’utilisateurs potentiels. Ces utilisateurs vont sans aucun doute exécuter votre logiciel selon des pratiques que ni vous, en tant que packager, ni vos développeurs en amont n’aviez prévues. Sans surprise, avoir de nombreux utilisateurs implique l’arrivée de nombreux rapports de bogue. Debian, comme la plupart des distributions, encourage ses utilisateurs à lui soumettre directement les rapports de bogue plutôt qu’à chacun des projets individuels en amont. Ceci permet aux mainteneurs de trier les rapports de bogue et d’assurer que les modifications effectuées lors du processus de création de paquet ne sont pas la cause du problème rapporté. Souvent, il peut y avoir un grand nombre d’interactions entre le rapporteur du problème et le mainteneur du paquet avant que les développeurs en amont ne soient impliqués.

Au fur et à mesure que le mainteneur du paquet accroît sa connaissance du projet, il sera en mesure de résoudre directement la plupart des problèmes. Le mainteneur publiera souvent des correctifs de bogue directement dans Debian tout en les faisant remonter en amont, permettant ainsi à la fois une résolution rapide des problèmes et de nombreux tests de correctifs. Une fois qu’un correctif est validé, le mainteneur travaillera alors avec le projet amont pour s’assurer que les changements requis y ont bien lieu, de manière à ce qu’ils soient disponibles aux autres utilisateurs du logiciel.

Fournir des correctifs de bogue réussis pour des distributions telles que Debian relève souvent d’une forme complexe d’art. Debian fonctionne sur de nombreuses plates-formes, allant des gros serveurs IBM aux smartphones, et la gamme ainsi que la largeur de ces plates-formes révèlent rapidement les approximations dans le code. L’empaqueteur a, la plupart du temps, un accès plus aisé à une gamme de plates-formes plus étendue que les développeurs en amont et constitue, de ce fait, le premier point d’appel quand un problème épineux de portage apparaît. On apprend rapidement à reconnaître les symptômes d’une approximation de la taille d’un pointeur, les problèmes avec les endianness et bien d’autres problèmes ésotériques ; cette expérience permet de devenir un programmeur à la fois plus polyvalent et plus prudent.

Lorsqu’un paquet reçoit des corrections de bogues et des améliorations, il est essentiel que ces changements remontent en amont. Trop souvent, la différence entre un paquet et le logiciel définitif en amont peut s’accroître énormément, avec pour conséquence que les deux bases de code deviennent presque entièrement distinctes. Non seulement, cela alourdit la tâche de la maintenance des deux côtés, mais cela peut aussi créer une immense frustration et faire perdre beaucoup de temps en amont dans le cas où un utilisateur de votre paquet rapporte un bogue lié à l’un des changements dans la version empaquetée en amont. Il est en conséquence vital que s’établissent une relation de travail étroite avec la branche amont et une compréhension de la meilleure façon de collaborer entre les deux parties.

La collaboration entre les développeurs et le packager peut prendre bien des formes. Que ce soit trouver la bonne voie pour communiquer les rapports de bogue, s’assurer de l’utilisation du bon style de codage, du même usage du système de contrôle de version ou des interactions qui provoquent le moins de frictions possible. Tout ceci amène une bien meilleure relation avec l’amont et accroît grandement la probabilité que ceux qui y travaillent prendront le temps de vous aider quand vous en aurez besoin.

Une fois que la relation de travail entre l’amont et vous est établie, il devient facile de contribuer plus directement en amont. Ceci peut également se faire de bien des façons différentes. Les premières étapes, simples, peuvent impliquer la synchronisation de n’importe quel rapport de bogue en amont avec ceux de votre distribution, afin d’être sûr que ce double effort impacte la cause primaire et résolve des bogues. Une implication plus directe consiste à développer des fonctionnalités et à changer plus largement que ce qui serait acceptable dans le cadre d’une version empaquetée.

Conclusion

Je pense que les deux choses essentielles que j’aurais aimé connaître lorsque j’ai commencé sont le sens de la communauté que le logiciel libre fait naître et la merveilleuse voie que le packaging de logiciel libre ouvre vers le plus vaste monde du logiciel libre

La communauté est essentielle au succès du logiciel libre. Elle se présente sous différentes formes, de la multitude d’utilisateurs souhaitant investir du temps dans l’amélioration de votre logiciel, jusqu’aux pairs d’une distribution ou d’un projet logiciel, qui investissent leur temps et leur énergie à affûter vos compétences et à s’assurer que vos contributions sont aussi bonnes que possible.

La voie qui part du packaging pour aller vers le développement est l’une des plus empruntées. Elle présente une courbe d’apprentissage moins raide qu’aborder directement le développement et permet d’acquérir des compétences à un rythme moins soutenu qu’en suivant d’autres chemins.

Dialogue Pouhiou Calimaq sur le domaine public et plus parce qu'affinités

vendredi 1 mars 2013 à 16:51

Pouhiou est notre joyeux et émérite premier romancier chez Framabook. À l’occasion de la sortie prochaine du livre II du cycle des NoéNautes, il a lancé une originale campagne de crowdfunding sur Ulule qui a fait réagir le blogueur influent (parce que brillant) Calimaq.

Ce dernier s’est en effet aventuré à parier que si cette campagne aboutissait alors il élèverait lui aussi son blog dans le domaine public via la licence Creative Commons CC-0. Bien mal lui en a pris puisque la campagne vient déjà de dépasser la barre escomptée (Pouhiou vous en remercie en vidéo ici) et se poursuit d’ailleurs…

Chose promise, chose due donc, et prétexte surtout à un passionnant entretien dialogue entre deux personnalités fortes du « Libre » francophone.

Je cède la parole à Pouhiou, et ça tombe bien car il adore la prendre ;)


monorchide-chaton02-ulule.jpg


En lançant le blog de mon roman feuilleton, j’ai eu d’instinct l’envie que cette histoire appartienne à ses lecteurs. Qu’ils s’en emparent. C’était une certitude que je ne savais pas comment appliquer dans les faits. M’intéressant au livre et au droit d’auteur, je suivais déjà le blog S.I.Lex écrit par un certain Calimaq. Ce mec, passionné et passionnant, arrive à transformer un sujet à priori lourd et chiant (la propriété intellectuelle) en une épopée rocambolesque. A force d’exemples, de décryptages, de coups de sang et de coup de cœur, il nous plonge dans les eaux du copy-right-left-up&down, on baigne en Absurdie et l’on ressort de son blog plus juriste qu’on y est rentré… sans même s’en apercevoir.

Un de ses billets m’a fait prendre conscience que la place de mes œuvres était dans le domaine public. J’ai donc passé tous mes écrits sous la licence CC0 et l’ai chaudement remercié dans cet article.

Il est né de cet échange une amitié intellectuelle. Calimaq s’est mis à défendre et mon œuvre, et la démarche qui l’accompagnait. Je me suis engagé dans SavoirsCom1, un collectif qu’il a co-fondé pour la défense des biens communs informationnels. Je ne compte plus les fois où l’on s’est dit « merci », tant chacun semble admirer et être complice de ce que fait l’autre. C’est ce genre d’émulation où la réflexion de l’autre nourrit la tienne, et te mène un poil plus vite, un poil plus loin que là où tu te serais rendu tout seul.

Quand, avec Framasoft, on a initié ce crowdfunding fou (toujours en cours sur Ulule) pour que le lancement de #MonOrchide (livre II des NoéNautes) puisse financer la distribution gratuite d’exemplaires de #Smartarded (le livre I), Calimaq a répondu présent. Il a fait un bel article pour promouvoir cette expérience . Mais, chose inattendue, il a ajouté ce post-scriptum explosif :

PS : allez, moi aussi, je mets quelque chose dans la balance. Si Pouhiou réussit son pari, je passe S.I.lex en CC0. Ceci n’est pas une parole en l’air !

Le pari est réussi. En 22 jours, on a atteint les 2200 € qui nous permettront de distribuer au moins 32 exemplaires de #Smartarded. Grâce à une mobilisation peu commune il ne nous a fallu que la moitié des 45 jours prévus (ce qui veut dire qu’il reste trois semaines pour battre tous les records et accroître le nombre de livres à distribuer !)

Le pari est réussi, et S.I.Lex devient un dommage collatéral : Calimaq tient sa part du contrat, élevant son blog dans le Domaine Public Vivant. Je sais que, le connaissant, ce n’est pas un geste anodin. Une belle occasion de discuter avec lui de licences, d’écriture, et de qu’est-ce que ça veut bien dire, toutes ces choses-là…

2012-12-08_19.23.44.JPG

Pouhiou : Tu m’as fait un super article sur ton blog S.I.Lex, qui a été repris par ActuaLitté. Cela m’a beaucoup aidé à faire connaitre le projet. C’était déjà énorme (merci ^^). Pourquoi avoir en plus ajouté la licence de ton blog dans la balance ?

Calimaq : Cela fait un moment que je m’intéresse à ce que tu fais autour du cycle des Noenautes et d’après ce que tu as écrit sur ton blog, un des billets que j’avais écrit sur S.I.Lex t’avait influencé dans ta décision d’adopter la licence CC0 pour ton premier roman #Smartarded.

Quand j’ai vu que tu lançais cette opération de crowdfunding, j’ai voulu la soutenir et la faire connaître, parce que je trouve qu’elle bouscule la manière dont nous avons l’habitude d’appréhender des notions fondamentales, comme celles du gratuit et du payant. Avec la licence CC0, tu as renoncé à tes droits d’auteur pour que tes œuvres soient complètement libres, tout en réussissant à faire paraître ton roman chez Framabook. C’est déjà en soi assez perturbant pour les schémas habituels. Mais tu ne t’es pas arrêté là et par le financement collaboratif, tu as cherché à faire en sorte qu’un maximum de livres en papier deviennent gratuits afin de pouvoir les offrir.

Le plus intéressant dans ta démarche, je trouve, c’est que derrière ces décisions, il y a un modèle économique bien pensé, qui utilise le crowdfunding pour raccourcir la chaîne de l’auteur au lecteur, dans le but de diminuer les coûts. Tu démontres de manière paradoxale que la gratuité a toujours un coût. C’est typiquement le genre d’approches alternatives qui retiennent mon attention, parce que je trouve qu’elles font avancer la réflexion. Dans le contexte actuel de crispations autour des questions de droit d’auteur, qui sont particulièrement vives dans le secteur du livre, je pense que des initiatives comme les tiennes sont importantes. J’ai aussi beaucoup apprécié la lecture de ton premier roman #Smartarded et j’ai commencé à lire la suite #MonOrchide par petites touches sur ton blog. Tout cela a fait que j’ai voulu te soutenir en écrivant un billet sur S.I.lex et je me réjouis de ta réussite.



Merci ! Mais là tu parles plus de moi que de toi, hein… J’ai bien saisi que ce billet a été un élément déclencheur, mais est-ce qu’il s’agit d’un coup de tête ou est-ce que ça fait partie d’une réflexion personnelle plus… ancienne ?



Au-delà du billet, pourquoi avoir promis de changer la licence de mon blog si ton pari réussissait ? Peut-être d’abord un peu par superstition, pour porter chance à ton projet, en engageant quelque chose qui me tenait vraiment à cœur. Par ailleurs, je me posais des questions à propos de la licence de S.I.Lex depuis un certain temps. À vrai dire depuis le moment où j’ai écrit le billet Rien n’est à nous : grandeur et misère du domaine public volontaire. J’y montrais comment un certain nombre de créateurs dans le passé avaient choisi pour diverses raisons de renoncer aux droits sur leurs œuvres pour se placer en dehors de la logique de la propriété intellectuelle : Léon Tolstoï, Romain Rolland, Jean Giono, les affichistes de mai 68, les situationnistes, le musicien folk Woodie Guthrie.

Le domaine public est une notion qui a un grande importance pour moi et pour laquelle j’essaie de me battre. Il m’a semblé que le moment était venu de franchir le pas et de placer ma propre création, S.I.Lex, dans le domaine public volontaire.

Ton blog était en licence CC-BY (la seule condition de partage est de citer l’auteur). Là tu le passes en CC0. C’est quoi, au fond, la différence ?

Juridiquement dans le cadre du droit français, il n’y a pas tellement de différences. En effet, le Code de Propriété Intellectuelle ne permet pas dans notre pays de renoncer valablement à son droit moral, ce qui signifie qu’on doit théoriquement interpréter la CC0 comme une CC-BY. Je n’ai pas la possibilité légale de renoncer à mon droit à la paternité. Ce caractère inaliénable du droit moral a été voulu pour protéger l’auteur dans le cadre des contrats d’édition. Même dans le cas des « nègres » (ou, plus joliment dit, Ghostwriters en anglais), il reste possible pour eux de réclamer devant un juge la paternité d’un texte écrit pour quelqu’un d’autre, quand bien même ils se seraient engagés par contrat à ne pas révéler leur identité (on a des jurisprudences intéressantes à ce sujet dès le 19ème siècle, notamment dans l’affaire qui opposa Alexandre Dumas à l’un de ses collaborateurs, Auguste Maquet.

Le problème, c’est que l’application trop rigide de ce principe aujourd’hui peut conduire à « protéger » l’auteur contre lui-même, alors qu’il manifeste clairement la volonté de renoncer à ses droits. La licence CC0 a d’ailleurs été obligée de prendre en compte cet état de fait, en précisant que l’auteur renonce à ces droits « dans la mesure permise par la loi ». Cela veut dire que l’effet de la CC0 varie selon les pays : aux États-Unis, où le droit moral n’existe pas vraiment, il est total ; en France, il reste juridiquement incomplet, puisque le droit moral persiste. Le seul pays à l’heure actuelle qui reconnaisse explicitement la possibilité de verser ses œuvres dans le domaine public volontaire, c’est le Chili.

Donc passer de CC-BY (licence déjà très ouverte) à CC0 n’a pas beaucoup d’effets pratiques… tant que la propriété intellectuelle n’est pas réformée en France. Malgré tout, je ne t’imagine pas homme à manier ces licences à la légère. Si passer de la CC-BY au Domaine Public Vivant n’est pas un choix pratique, il est de quel ordre ?

Cette décision revêt à mes yeux une valeur symbolique et psychologique importante, en tant qu’auteur. Je ne suis pas comme toi auteur de littérature ou de théâtre, mais j’ai un rapport profond avec l’écriture. J’écris sur S.I.Lex par besoin viscéral d’écrire et quand je décroche de l’écriture, je périclite littéralement. Pour moi, l’écriture a aussi une importance comme trace que l’on laisse de soi au-delà de son existence. Du coup, le BY - la paternité - gardait une vraie importance à mes yeux, comme une sorte de « cordon ombilical » ou de minimum minimorum du droit d’auteur, dont il était difficile de se détourner. Couper ce cordon en adoptant la CC0 n’était pas anodin et il m’a fallu un certain temps - et un coup de pouce de ta part - pour lâcher prise !



Quel est l’intérêt, pour toi, de mettre de son vivant des textes dans le domaine public ?

Pour moi, l’intérêt principal, c’est de sortir en dehors du cadre du droit d’auteur. Avec les licences libres, on passe de la logique du copyright à celle du copyleft, mais on reste encore dans le système du droit d’auteur. Les licences libres ne sont pas une négation du droit d’auteur, mais une autre manière de le faire fonctionner. Avec la licence CC0, on n’est plus dans le copyright, ni même dans le copyleft, mais littéralement dans le copy-out. On décide sciemment que son œuvre n’est plus saisie par le droit d’auteur et ne doit plus être comprise à travers ce filtre. Je ne prétends pas que cette voie doive être suivie par tous les auteurs. Mais au stade où j’en suis, c’est cohérent avec ma démarche.

Tu dis de ton côté que tu n’as pas l’impression que tes textes ne t’appartiennent pas, mais que tu “digères” des éléments extérieurs que tu restitues par tes écrits. De mon côté, j’ai très tôt été sensible aux effets d’intelligence collective sur la Toile, avec le sentiment que je me devais de rendre à l’intelligence collective ce qu’elle me donne. Il n’y a pas un seul de mes billets qui n’ait été déclenché par les conversations et les échanges dans les flux. Dès lors, le meilleur moyen d’être cohérent avec moi-même, c’est d’opter pour le domaine public volontaire.

Par ailleurs, je pense important de montrer que le domaine public n’est pas seulement une chose du passé, mais qu’il peut être vivant aujourd’hui. En tant qu’auteur de son vivant, contribuer à alimenter le domaine public, c’est la meilleure manière de s’en faire l’ambassadeur et d’agrandir le cercle des biens communs de la connaissance.

OK : on a tous les deux ce souci de cohérence. C’est bien beau d’utiliser une licence parce qu’elle te met en adéquation avec ce que tu ressens de ta production intellectuelle… Mais il y a forcément des pragmatiques qui vont nous traiter d’utopistes ! Ils vont nous rappeler qu’on vit dans un monde où les enjeux commerciaux prévalent et où — selon eux — les circonstances font qu’il vaudrait mieux armer et protéger ses œuvres… D’un point de vue pratique, la clause non commerciale (NC) est un outil redoutable quand la CC0 est une passoire ! Du coup, une licence, c’est la conséquence d’un ressenti théorique ou la résultante d’un besoin pratique d’outil légal ?

C’est sans doute assez souvent le résultat d’un compromis entre les deux. Il faut considérer la situation des auteurs dans leur diversité et de multiples stratégies sont envisageables avec les licences. Les choses peuvent varier également selon les domaines de la création. Quand on voit un Cory Doctorow ou un Lawrence Lessig publier leurs ouvrages chez des éditeurs traditionnels et placer les versions numériques sous CC-BY-NC, je trouve que c’est une stratégie compréhensible et qu’ils ont par ce biais contribué à faire avancer la cause, en diffusant leurs idées dans un large cercle.

Beaucoup de créateurs en revanche ne cherchent pas un retour financier pour les œuvres qu’ils produisent. C’est le cas pour la plupart des amateurs qui créent des contenus sur Internet. Dans ce genre de situation, la réservation de l’usage commercial n’est généralement pas justifiée et choisir cette clause impose des contraintes sans réelle nécessité. Mais dans certaines situations, la clause NC peut constituer un élément intéressant pour permettre la circulation des œuvres tout en mettant en place un modèle économique. Il y a un débat assez vif en ce moment sur la légitimité de la clause NC, notamment telle qu’elle figure dans les licences Creative Commons. Je ne fais pas partie de ceux qui condamnent cette clause de manière systématique et j’ai déjà essayé de montrer que ce serait une erreur selon moi de la supprimer.

Malgré cela, tu n’as jamais mis de clause NC sur ton blog S.I.Lex...

Dans mon propre cas, je n’en vois absolument pas l’intérêt… Mon objectif en écrivant de cette manière est d’être lu par un maximum de personnes. Si certains de mes billets sont repris sur d’autres sites, y compris des sites se livrant à des activités commerciales, cela ne peut qu’augmenter l’exposition de mes écrits. J’ai d’ailleurs toujours fonctionné depuis le lancement de S.I.Lex dans un « écosystème » de sites. Très vite, j’ai eu la chance de voir certains de mes billets repris par le regretté OWNI. Cela a grandement contribué à faire connaître S.I.Lex et à développer mon lectorat. D’autres sites me reprennent régulièrement, comme Actualitté ou plus récemment Slate.fr. J’ai toujours considéré que S.I.lex était une sorte de plateforme de tir, où je posais des écrits qui pouvaient ensuite aller faire leur vie ailleurs. Avec une licence NC, les choses auraient été beaucoup plus compliquées.

La licence CC0 est peut-être une passoire, mais dans les conditions particulières qui sont les miennes comme auteur, elle conviendra parfaitement à ce que je veux faire de mes créations. Même si un éditeur vient publier certains de mes billets sous forme de livre dans un recueil, cela ne fera que contribuer encore à leur diffusion.

Du coup, tu n’exiges plus que l’on te cite comme source de tes écrits… de manière légale, c’est ça ? C’est un peu comme moi en fait : tu ne brandis pas d’arme juridique. Plutôt que de les craindre, tu donnes ta confiance aux personnes qui s’inspireront de (ou diffuseront) tes écrits. Confiance en le fait qu’elles soient assez respectueuses pour citer leur source.

La question qui peut se poser est celle du plagiat, quelqu’un qui viendrait s’approprier certains de mes textes en les publiant sous son nom. C’est une chose qui m’est déjà arrivée une fois et j’avoue que cela m’avait laissé une sensation assez désagréable.

Mais une personne comme l’artiste Nina Paley dit des choses très intéressantes sur les rapports entre le copyright et le plagiat. Elle considère en effet que le droit d’auteur paradoxalement favorise davantage le plagiat qu’il ne l’empêche. Elle explique également que le fait de créditer l’auteur relève en fait d’un système de régulation sociale qui n’a pas nécessairement besoin du droit pour fonctionner. Il s’agit en fait davantage de règles éthiques que des communautés se donnent. Nina Paley place d’ailleurs ses créations dans le domaine public volontaire en utilisant la non-licence Copyheart ou la CC0. Elle dit vouloir en cela faire œuvre de « non-violence légale » et je trouve que c’est un discours inspirant.

Un des pivots du libre, c’est sa viralité. On m’affirme que des processus du type la clause SA ont permis au libre de se développer tel qu’il est aujourd’hui. Pour mon compte, la SA est trop paradoxale. Je dis toujours que la première des libertés c’est de ne pas me lire. Dans la même veine, obliger les gens qui adapteront/traduiront/réécriront/diffuseront mes romans à mettre leur production sous licence libre, ça me semble créer de l’enclosure. Ce serait un peu comme forcer les gens à se vacciner au lieu de leur montrer comme on est mieux une fois bien portant… Et du coup j’aperçois que ton blog S.I.Lex n’était même pas sous clause SA ? Pourquoi ?

C’est une question intéressante et là aussi, je m’étais longuement posé la question lorsque j’avais choisi ma licence.

La clause de partage à l’identique est très importante dans beaucoup de domaines, comme celui du logiciel libre qui est fondé sur cette idée qu’il ne doit pas y avoir de possibilité de supprimer les libertés conférées à tous par la licence. Contrairement à ce que tu dis, je soutiendrais que le SA garantit au contraire qu’il ne puisse jamais y avoir d’enclosure sur une œuvre. Personne ne peut plus s’approprier de manière définitive un contenu placé sous Share-Alike. C’est pourquoi il me semble que c’est un type de licence adapté pour les biens communs que des communautés veulent protéger des risques d’enclosure. Si l’on prend le cas de Wikipédia, la licence CC-BY-SA est parfaitement adaptée, à la fois au travail collaboratif et aux réutilisations des contenus. Elle garantit que cela puisse se faire, même à titre commercial, mais sans réappropriation.

Cependant, je peux comprendre que tu ne veuilles pas placer tes écrits sous le régime du partage à l’identique, et c’est aussi la conclusion à laquelle j’étais arrivé pour S.I.Lex. Si je prends le cas des billets que reprenait OWNI par exemple, les choses auraient été trop compliquées avec une CC-BY-SA. En effet, OWNI reprenait mes billets, mais en les modifiant légèrement. Les journalistes de la plate-forme changeaient généralement le titre, ajoutaient des intertitres, inséraient des illustrations, des vidéos et parfois même des infographies. Il arrivait également que certains de mes billets soient traduits en anglais pour alimenter OWNI.eu. Tout cet apport éditorial était à mes yeux excellents, mais d’un point de vue juridique, il s’agissait d’adaptations de mes créations, ce qui aurait déclenché la clause de partage à l’identique, si j’avais choisi une CC-BY-SA. Or OWNI était sous CC-BY-NC-SA et il n’aurait pas été simple pour eux d’intégrer mes billets si je n’avais pas laissé une grande ouverture avec la CC-BY.

De plus, la CC-BY-SA n’est pas toujours simple à appliquer, comme l’avait prouvé l’affaire qui avait opposé Michel Houellebecq à Wikimedia, lorsque qu’il avait intégré dans son roman La Carte et le Territoire des extraits d’articles de Wikipédia sans mention de la source, ni crédits des auteurs.

Le domaine public et le libre ne sont pas exactement superposables. Le propre du domaine public, c’est de constituer un réservoir complètement ouvert dans lequel on peut venir puiser pour alimenter sa création sans contraintes. Les deux approches sont importantes et complémentaires.

Mais attends, de nous jours, entre les CopyrightMadness, les guerres de brevets, ceux qui s’approprient mon grain de maïs ou ton rectangle à bords arrondis… Avec tous ces abus du côté de la propriété intellectuelle et des biens communs… Y’a pas plus important ou plus urgent que de s’occuper du domaine public ?

Oui, c’est certain qu’il existe des sujets alarmants sur lesquels il devient urgent d’agir. Je ne suis pas seulement engagé pour la défense du domaine public, mais plus globalement pour la promotion des biens communs de la connaissance, ce que je fais au sein du collectif SavoirsCom1. Je milite également aux côtés de la Quadrature du Net pour la légalisation des échanges non-marchands et la mise en place de solutions de financement mutualisées pour la création, comme la contribution créative ou le revenu de base.

Néanmoins, je pense que le domaine public peut constituer un bon angle d’attaque pour s’engager dans une réforme positive de la propriété intellectuelle. On a un peu l’impression d’être aujourd’hui face à une forteresse imprenable et on n’arrive pas à sortir des débats autour de la répression du partage des œuvres, qui continuent à monopoliser l’attention du législateur comme on le voit bien avec les travaux de la mission Lescure. C’est pourquoi il me paraît intéressant d’ouvrir de nouveaux fronts qui permettront de défendre l’idée que nous possédons des droits positifs sur la culture. Le domaine public peut être une piste en ce sens et j’ai fait des propositions de réforme législative pour consacrer et renforcer cette notion dans le Code de Propriété Intellectuelle.

Par ailleurs, tu évoques le Copyright Madness, mais le domaine public pourrait aussi être un moyen de lutter contre les pires dérapages de la propriété intellectuelle. On a vu par exemple récemment des laboratoires pharmaceutiques déposer valablement des brevets en Australie sur les gènes responsables du cancer du sein, ce qui est absolument terrifiant puisque cela signifie que tout chercheur qui voudra mettre au point un remède devra leur verser des royalties. Aux États-Unis, Monsanto a relancé une offensive en justice pour empêcher des agriculteurs de replanter des semences de variétés brevetées et l’entreprise semble en passe de l’emporter. Cela peut avoir des conséquences dramatiques au niveau mondial.

Ces dérives ont un lien avec le domaine public, parce que celui-ci ne contient pas seulement les œuvres anciennes, mais aussi tout ce qui ne devrait pas pouvoir faire l’objet d’une appropriation exclusive. Cela vaut pour certains éléments de la Culture, mais aussi pour des choses aussi essentielles que le génome humain ou les semences.

Le domaine public devrait être le bouclier qui protège tous ces éléments fondamentaux de la folie de l’appropriation, mais c’est à nous de le promouvoir et de le faire vivre pour qu’il puisse remplir ce rôle.

Je crois qu’on ne peut pas trouver de meilleure conclusion ! Merci à toi, Calimaq.

2012-12-08_19.24.39.JPG