La science est quelque chose de bien trop sérieux et précieux pour être laissée aux seuls scientifiques professionnels. Amateurs, de 7 à 77 ans, tout le monde peut et doit y prendre part, facilités en cela par Internet et sa philosophie d’ouverture.

Un article de Rayna Stamboliyska initialement publié sur Al Jazeera.

Remarque : nous avons choisi tout du long de traduire « hacker » par « bidouiller ».

Jeu et partage des connaissances, ou pourquoi nous avons besoin de bidouiller la science

Tinkering knowledge sharing, or why we need to hack science

Rayna Stamboliyska – 25 mars 2013 – AlJazeera.com
(Traduction : Sphinx, Rayna, M0tty, Minitte, goofy, Oumph, Asta , lizuka, Penguin, Moosh, Baptiste, Oli_Ph)

Les citoyens activement engagés dans la production scientifique fournissent le meilleur effort de compréhension de la science, et ce à tout âge.

Traditionnellement, les chercheurs sont des universitaires employés par les institutions. Le stéréotype de l’expert érudit entouré de livres poussiéreux gribouillant frénétiquement des écrits obscurs vient également à l’esprit. Quel(le) qu’il (elle) soit, le chercheur produit de la connaissance et que vous soyez profondément de gauche ou légèrement de droite, vous respectez tous la science et la connaissance. Ce sont des sujets d’importance, autant pour la droite que pour la gauche et pour toutes les idéologies entre les deux et au-delà. De fait, bidouiller (NdT : ou hacker) sort des chemins battus lorsque l’on considère la science et la connaissance.

« Un scientifique, un artiste, un citoyen n’est en rien un enfant qui aurait besoin d’une méthodologie paternaliste et d’une rationalité maternante lui donnant sécurité et direction. Il peut prendre soin de lui-même. Il n’est pas seulement l’inventeur des lois, des théories, des images, pièces de théâtre, styles de musique, interactions sociales, des institutions, il est aussi l’inventeur d’une nouvelle vision du monde, il est l’inventeur d’une nouvelle forme d’appréciation ». Cette citation vient d’un épistémologue, malheureusement oublié, Paul K. Feyerabend et date de 1978 quand son livre « Science dans une société libre » fût publié. Utilisons cette citation comme fil rouge de cette discussion à propos de la démocratisation de la science.

Bidouiller la science, c’est génial… Euh, quoi ?

Vous avez raison, une telle affirmation peut être trompeuse. Je souhaiterais davantage parler de « bidouiller le faisage de la science ». Le cliché de l’intellectuel solitaire, à l’apparence maladive et au comportement associal, est répandu aujourd’hui encore, mais sa généralisation faiblit au fur et à mesure que les technologies de communication progressent. Ce qui reste vrai, en revanche, c’est le côté conservateur et rigide des organismes de recherche. La science est construite à partir de données collectées, analysées, critiquées et réutilisées. Cependant, la méthodologie ordinaire de la science, imposée par les organismes de recherche, requiert le secret et nécessite donc de travailler contre cette maximisation de la dissémination du savoir. Avant que quiconque ne crie à la paranoïa, pensez aux publications à accès payant, bloquant ainsi leur diffusion, au format PDF ou, pire, en image.

Les réticences à publier les données et à ouvertement partager le savoir ont cependant commencé à attirer l’attention des gens. Un mouvement général vers l’ouverture que l’on appelle plus communément la « science ouverte » a émergé, inspiré par l’esprit du mouvement du Logiciel Libre (Free and Open Source Software, FOSS). Similaire à l’éthique du Libre qui promeut l’ouverture d’un code source accessible, réutilisable et modifiable par tout le monde, le thème principal de la sciences ouvertes est d’expliquer clairement les méthodes, les données générées et les résultats obtenus, permettant ainsi une collaboration massive qui accélère la vitesse à laquelle la science se fait.

Un concept très puissant – la « science citoyenne » – a naturellement émergé parallèlement à la science ouverte. Les blogs de chercheurs professionnels qui parlent de leurs travaux et discutent en ligne des résultats obtenus par leurs pairs sont innombrables. De tels débats permettent à de non-professionnels de participer aussi. La poussée du mouvement hacker/maker/do-it-yourself a énormément contribué à l’engagement dans la science de scientifiques non-professionnels.

De nos jours, il y a des centaines de projets dans le monde entier au sein desquels chercheurs professionnels et non-professionnels prennent part à de véritables études scientifiques. Un glissement clair et visible s’est opéré ces dernières années : au début, les citoyens aidaient simplement à collecter des données alors que désormais les citoyens les analysent vraiment, produisent des résultats valables et les interprètent allant même jusqu’à proposer de nouvelles hypothèses.

La « démocratisation de la science » défendue par Feyerabend est en train de se réaliser. La méthode de la science est encore trop souvent faussement imaginée comme étant l’exploration de théories en perpétuelle expansion sur les complexités de l’univers et uniquement réservée à une élite d’individus extraordinairement intelligents, échevelés et quelque peu sociopathes. La méthode scientifique est en fait à la portée de tous ceux capables de poser une question, de réunir des informations, de les analyser de manière critique, de (peut-être) trouver une réponse et d’agir en fonction du résultat.

Cela vous semble idéaliste ? Vous avez le droit d’avoir tort. Vous aimez les maths ? Peut-être que non. Cependant, prenez par exemple l’expérience Polymath. En 2009, Tim Growers, lauréat de la médaille Fields, écrivait un article sur son blog parlant des « mathématiques massivement collaboratives ». Il écrivait : « Une idée serait que quiconque ayant quelque chose à dire sur le problème puisse y ajouter son grain de sel… vous contribueriez ainsi à des idées, même si elles sont peu développées ou peut-être fausses. »

Qu’est-ce qui en a découlé ? Des centaines de commentaires et la naissance du projet Polymath. En réalité, les gens collaborent massivement à la résolution de problèmes en mathématiques. Des chercheurs, professionnels et non-professionnels, ont également contribué à l’identification de médicaments anti-paludisme, à la cartographie des accidents de la route ou la pollution sonore, ainsi qu’à la documentation des déversements de pétrole dans la côte du Golfe avec des ballons, ou encore à l’étude de l’impact du changement climatique sur les oiseaux, etc.

Un tel engagement social et citoyen dans la pratique scientifique est crucial. Les gens doivent revendiquer le droit d’être informé et éduqué. Le pouvoir réside là où est l’information, de cette manière, y avoir accès est un moyen d’auto-gouvernance et contribue à résorber la corruption, les privilèges et l’injustice. J’ai déjà débattu du besoin frappant de telles initiatives dans le monde arabe. Bien que la science soit un domaine émergent dans cette région où les financements suffisent rarement à sécuriser les équipements basiques pour la recherche, l’intérêt sur ce sujet, lui, existe. Entrer en contact avec des scientifiques non-professionnels devrait être aujourd’hui considéré par les professionnels comme partie inhérente de leur travail quotidien.

L’influence politique sur la façon dont la science fonctionne et est communiquée est un souci croissant au sein du monde arabe et partout ailleurs. Les projets de science citoyenne ne sont pas seulement indépendants, ils aident aussi à faire des choses avec un petit budget ou diminuer les coûts inhérents de la recherche ; ainsi, selon un rapport : « Au cours d’une seule année, des observateurs volontaires pour la surveillance de la biodiversité au Royaume-Uni ont vu leur contribution en temps estimée à plus de 20 millions de livres (NdT : environ 23,5 millions d’euros) ». La science citoyenne fournit aussi des données fiables et des outils qui peuvent être utilisés par tous les domaines scientifiques, des études environnementales aux sciences humaines. Un accès libre aux avancées scientifiques les plus récentes permet aux citoyens de remettre en question des hypothèses historiques. Résoudre des problèmes à rayonnement local, ou juste participer par curiosité, ramène la science à ses racines.

Bidouiller l’école

Je dis du bien du bidouillage de la science et je dirai encore davantage de bien du bidouillage de l’école. Avez-vous déjà réfléchi à l’origine de notre désir de savoir comment les choses fonctionnent ? Je dirais qu’elle se situe dans l’enfance. Quand on est enfant, on se demande pourquoi le ciel est bleu ou comment on fait les bébés. Nous posons des questions, découpons des limaces pour voir jusqu’où elles peuvent aller avec des morceaux en moins et décidons qu’elles ne peuvent pas aller bien loin une fois qu’elles sont en tranches. Un chercheur émet une hypothèse, décide des informations à collecter pour y répondre, les analyse ensuite et en tire des conclusions pour valider ou non l’hypothèse de départ. En fait, cela ressemble à ce que les enfants font naturellement.

Mon idée est que les enfants apprennent par la recherche. Là où ça coince, c’est quand les adultes pensent que pour être un grand, il faut connaître la réponse. Nous tendons ainsi à inculquer aux élèves des informations déjà disponibles et nous appelons cela l’éducation. Le problème n’est pas la transmission du savoir à la jeune génération, mais le fait que nous le faisons en étant persuadés que l’aventure dans l’incertitude des réponses inconnues est délétère.

Que se passerait-il si, au lieu de verrouiller nos pensées et de castrer l’attitude interrogatrice des enfants, nous décidions de construire une culture de curiosité ? Autrefois, au XVème siècle, l’imprimerie encouragea de nouveaux moyens de transmission de l’information : des effets similaires peuvent être espérés avec Internet mais sur une échelle de temps beaucoup plus rapide. À travers les médias actuels, les élèves et étudiants ont accès à une quantité incroyable d’information. L’institution « école » a donc encore moins le monopole du savoir ; quel devient donc son but ?

L’« avalanche » d’articles scientifiques contribue à la reformulation de concepts. Ce que nos enfants ont besoin d’apprendre est à la fois comment apprendre et comment désapprendre. L’enseignant ne devrait pas être celui qui transmet des faits mais plutôt la personne qui enseigne comment les comprendre, les critiquer et les valider. Plutôt que d’essayer de savoir tout ce qui est produit, l’enseignant doit accepter ce qui est, pour chacun d’entre nous, une petite révolution culturelle car il sait mieux que les élèves comment analyser l’information. Il/Elle doit dès lors être un spécialiste de la découverte de la connaissance.

La liberté de jouer

Je parie que beaucoup d’entre vous pensent que ceci est noble mais ont du mal à voir comment le réaliser. La recette miracle n’existe pas mais il y a un beaucoup d’approches possibles. Avez-vous entendu parler des jeux éducatifs et de recherche ? Oui, je viens d’évoquer la gamification (ou encore, « ludification ») qui correspond à l’intégration de méthodes pensées pour les jeux dans des applications « sérieuses » afin de les rendre plus amusantes et engageantes. Ce n’est pas une idée nouvelle : le concept que jouer génère et modèle notre culture a été exposé dans Homo Ludens (1938). Le typage sanguin, la biochimie ainsi que beaucoup d’autres jeux scientifiques ont aidé à démontrer l’importance de l’implémentation de la motivation dans l’apprentissage et l’exercice de la science.

Jouer en ligne à des jeux éducatifs et scientifiques pourrait ainsi être un des défis majeurs pour nos écoles. Nous espérons que nos enfants apprennent des choses « sérieuses » et on pourrait peut-être y bien parvenir en leur donnant la liberté de jouer. J’ai beaucoup aimé ce que le Digital Youth Project (Projet pour la Jeunesse Numérique) décrit dans un rapport sur les activités en ligne des enfants : celles-ci couvrent le fait de « traîner » (fréquenter des gens), de « mettre en désordre » (bricoler, même au point de devenir un expert local sur une technologie ou un média), de « faire son geek » (être curieux de ce qui est lié à Internet).

Imaginez ensuite une autre « école », où à la place de maîtres d’école il y aurait des professeurs de travaux pratiques, chacun ayant une responsabilité différente. En aucun cas, une telle responsabilité ne devrait se limiter à noter les enfants sur leur compétence. Ainsi, le but premier de l’éducation ne serait pas de préparer à un métier spécifique ou à une carrière mais constituerait plutôt un processus guidant l’enfant vers une participation à la vie publique. De cette manière, les adultes que nous appelons professeurs co-créeraient le savoir avec les enfants.

À la fois la possibilité pour les non-professionnels de s’engager dans l’exercice de la science et la nécessité de transformer les enseignants en des co-createurs de savoir. Alors, si les enfants peuvent avoir une nouvelle espèce de dinosaure portant leur nom ou créer un réacteur nucléaire chez eux, pourquoi ne pas les laisser faire de la recherche avec leurs ainés amateurs de science ? Dès lors, une question légitime se pose : « pourquoi ne pas créer un parcours d’apprentissage par la recherche à l’école ? ».

La science transforme notre perception du monde et de nous-mêmes, particulièrement chez les enfants. L’exercice de la science requiert un attrait pour l’inconnu et une ouverture sur les possibles. Tout comme les moments durant lesquels on s’amusent, la science permet la découverte et la création de relations et de schémas mentaux. Rajoutez des règles à suivre à l’amusement et vous obtenez un jeu. Rien n’est plus naturel pour les enfants que d’accueillir l’inconnu et faire des erreurs, les deux ouvrant la voie de la découverte.

Ainsi, le processus du questionnement et de la recherche de la résolution de problèmes devient plus intuitif. Cette approche contraste avec des méthodes d’apprentissage plus classiques où le but est de trouver des solutions, non pas des questions. La créativité joue un rôle majeur ici. La créativité a cependant besoin d’être désacralisée : tout le monde peut trouver de nouvelles solutions et porter de nouveaux regards. La créativité est un processus ouvert, interactif et contraignant ; être créatif signifie que la critique constructive est nécessaire pour l’avancement.

Une science citoyenne pour les enfants

À quoi pourrait ressembler un parcours d’apprentissage par la recherche ? L’interdisciplinarité y est incontournable. L’inclusion de l’alphabétisation numérique dans le parcours de formation est décisif, quant à l’initiation à la programmation pour les enfants, cela existe déjà. Des écoliers du primaire au Royaume-Uni ont déjà publié un papier scientifique sur la reconnaissance des fleurs par les abeilles, et dans une banlieue de Paris, dans une école primaire des élèves de CM1/CM2 apprennent de la science en étudiant les fourmis. La classe envoie des tweets sur ses observations et recueille des hypothèses venant d’autres classes et de chercheurs adultes.

Twitter n’est pas la seule voie que peuvent choisir les enfants pour collecter et échanger des connaissances. Les adultes ont Wikipédia, mais c’est un peu complexe pour les enfants qui bien souvent n’y trouvent pas de réponses à leurs questions. Essayez par exemple de chercher pourquoi le ciel est bleu dans la page « lumière ». Si vous survivez au jargon scientifique assez hermétique et lisez la totalité de la page, vous vous rendrez compte que l’explication n’y est pas. Des projets tels que Simple Wikipédia sont donc apparus, qui visent à expliquer les choses complexes en un langage simple. Vikidia en France (une sorte de Wikipédia pour les enfants mais écrit par les adultes), Wikikids aux Pays-Bas, avec son équivalent français Wikimini (Wikipédia pour et par les enfants), ont commencé à construire une passerelle entre la création collaborative de connaissances et son partage généralisé.

En participant à la vraie science, nous nous impliquons tous activement dans le processus qui consiste à lui donner du sens. Les enfants non seulement deviennent des scientifiques, mais ils développent aussi leur créativité et se rendent compte des choix qu’ils opèrent. Ainsi, chacun prend activement conscience de la façon dont notre environnement et notre imagination nous façonnent en tant qu’individus et en tant que société.

Rayna Stamboliyska est chercheuse associée au Centre de Recherche pluridisplinaire de l’Université de Paris 5 Descartes, où elle développe la partie biologie synthètique au sein du projet Cyberlab citoyen. Elle contribue également à l’organisation de la « Nuit de la Science 2013 ». Elle tient un blog sur Scilogs.com intitulé Beyond the Lab, qui observe les pratiques scientifiques émergentes ; elle participe aussi à FutureChallenges.org et à Jadaliyya. Rayna est membre du conseil d’administration de la branche française de l’Open Knowledge Foundation et ainsi contribue au développement de la science citoyenne en France.

Crédit photo : Krystian Olszanski (Creative Commons By)

Voici traduit en français le dernier épisode du recueil de conseils OpenAdvice, Notre expérience collaborative sur le pads de traduction s’est avérée un marathon (presque 42 kilomètres aussi) parcouru quelquefois au grand galop par une quasi-centaine de relayeurs. Merci à tous ceux qui sont passés parfois pour risquer un mot ou une phrase, parfois pour dévorer des paragraphes entiers, voire pour devenir des habitués indispensables d’une séance à l’autre.

L’aventure toutefois n’est pas terminée, des membres de Framalang vont maintenant réviser l’ensemble des traductions réunies sur la plateforme Booktype, et préparer un .PDF qui sera lui-même révisé avant le Framabook qui devrait paraître… quand il sera prêt.

Il est un peu tôt pour annoncer les dates avec certitude, mais Paris en mai et Bruxelles en juillet auront la primeur de la publication. Restez tunés !

* * * * *

Traduction Framalang : Ouve, Julius22, Sphinx, AC!63, jcr83, goofy, peupleLà, merlin8282, Sinma, tcit, SaSha_01, lamessen, Sky, jpierre03

Lancer des ponts

Shane Coughlan

Shane Coughlan est un expert en méthodes de communication et en développement d’affaires. Il est surtout connu pour créer des passerelles entre les différentes parties, commerciales et non commerciales, dans le secteur des technologies. Au plan professionnel il a œuvré avec succès pour la création d’un département juridique pour la Free Software Foundation Europe (FSFE), la principale organisation non gouvernementale pour la promotion du logiciel libre en Europe. Il a également contribué à l’établissement d’un réseau professionnel de plus de 270 experts juridiques et techniques à travers 27 pays, à la fondation d’un projet d’outil de conformité de code binaire. Il a travaillé à rapprocher intérêts privés et communautaires pour le lancement du premier examen critique d’une loi dédiée au logiciel libre et open source. Shane a une connaissance étendue des technologies de l’Internet, des bonnes pratiques de gestion, de la construction de communautés et du logiciel libre et open source.

Lorsque j’ai commencé à travailler dans le logiciel libre, j’ai été frappé par ce qui était perçu comme une différence entre les parties prenantes « communautaires » et « commerciales » dans ce domaine. Selon l’opinion largement admise à l’époque, les développeurs s’intéressaient au bidouillage du code  et les commerciaux utilisaient leur travail de manière contestable s’ils n’étaient pas surveillés de près. C’était une supposition relativement infondée et presque entièrement défendue par des gens qui s’identifiaient à la communauté plutôt qu’à ceux qui se préoccupaient davantage des intérêts commerciaux. Mais elle était très répandue.

Bien que je sois principalement associé à la partie communautaire des choses, j’ai résisté à l’idée selon laquelle il y aurait deux camps intrinsèquement ennemis se faisant face à propos de l’avenir du logiciel libre. Cela semblait trop simple pour décrire les dynamiques de contribution, d’utilisation et de support comme une interaction entre les nobles créateurs et les sournois téléchargeurs de gratuit. Cela semblait en effet plus être une situation dans laquelle la complexité, les changements et l’incertitude avaient conduit à la création de récits simplistes destinés à rassurer un peu ceux qui sortaient de leur position confortable. Je pouvais ressentir la tension ambiante, entendre les querelles autour des stands lors des rencontres et les commentaires acerbes ou bien les montées en pression dans les conférences. Mais que signifiait tout cela ?

Que nous parlions de contribution à des projets de logiciels libres, de gestion de projet ou de respect des licences, les relations entre les parties prenantes s’accompagnaient souvent de préjugés, d’un manque de communication et d’émotions négatives. Ceci conduisait ensuite à une plus grande complexité, à une augmentation proportionnelle de la difficulté à prendre des décisions unifiées ainsi qu’à résoudre les problèmes. Je savais que l’un des plus grands défis était de jeter des ponts entre les individus, les projets et les entreprises. C’est une étape nécessaire pour assurer une compréhension commune et une communication croisée des règles, des normes et des raisons qui sous-tendent les licences et autres mesures officielles qui régissent ce domaine. Mais le savoir ne suffit pas à trouver le moyen de s’attaquer efficacement au problème.

C’était la période charnière où la GPLv3 était en cours de rédaction. Les technologies fondées sur Linux commençaient à apparaître dans toutes sortes de produits électroniques grand public et le logiciel libre était sur le point de se démocratiser. Il y avait du changement dans l’air et les investissements commerciaux autour des principaux projets de logiciel libre atteignaient des sommets. Tout à coup, on voyait des employés de grandes entreprises s’atteler à des tâches complexes, on avait des fonds importants pour les événements. De nombreux logiciels cessaient d’être une simple question de plaisir et commençaient à connaître les jalons, les livrables, l’assurance qualité et l’ergonomie.

Ce fut probablement un sérieux bouleversement pour ceux qui réalisaient du logiciel libre depuis longtemps : la majeure partie de l’évolution du logiciel libre ne concernait pas seulement l’exploration et la perfection technique, mais aussi l’interaction sociale. C’était un bon moyen pour des gens intelligents bien que parfois bizarres de partager un intérêt commun, de se lancer des défis et de coopérer au sein de projets bien définis et prévisibles. Tout comme collectionner des timbres, compter les trains ou connaître (par coeur) l’univers de Star Trek, c’était quelque chose qui fédérait des gens avec des centres d’intérêt bien particuliers en leur offrant de surcroît le bénéfice d’une agréable socialisation. Les premiers contributeurs ne s’attendaient sûrement pas à rencontrer là des cadres moyens et un développement orienté vers le volume de production. Pas étonnant que certains s’y soient cassé le nez.

Et pourtant… Tout s’est bien passé. Le logiciel libre est partout et sa position paraît être inexpugnable en tant que composant majeur de l’industrie des technologies de l’information. Des projets comme le noyau Linux ou le serveur Web Apache ont continué à se développer, à innover et à attirer de nouvelles parties prenantes, tant commerciales que non commerciales. L’équilibre des pouvoirs entre les individus, les projets et les entreprises a changé, parfois avec des conflits et des perturbations, mais jamais au détriment d’une coopération sur le long terme, ni en portant préjudice aux valeurs fondamentales du logiciel libre.

De mon point de vue, dans le domaine juridique — qui n’est après tout qu’un langage formel qui fournit un contexte pour l’interaction au travers de règles mutuellement comprises et applicables — la tension dans le logiciel libre ne s’est pas formée avec l’introduction d’une activité commerciale accrue, ni avec la participation grandissante d’employés dans des projets, ni avec le changement lui-même. Le vrai problème réside dans l’écart entre une élite précédente en perte de vitesse et de nouveaux venus parfois très différents.

Le défi était de créer un terrain de jeu équitable où les différents intérêts pourraient coexister dans un respect mutuel. Le logiciel libre devait devenir un point de rencontre où n’importe qui pouvait à tout moment obtenir des informations comme les compétences appropriées, les obligations d’une licence ou les pré-requis pour la soumission de code à un projet. La subjectivité et l’imprécision devaient être mises de côté pour permettre l’émergence de transactions plus formelles, ce qui agit alors comme le précurseur essentiel d’une forte activité économique, en particulier dans le contexte d’une communauté internationale voire mondiale.

Ce qui a fonctionné dans les premiers jours — qu’il s’agisse de la confiance de quelques-uns ou de l’entente mutuelle d’un groupe homogène ayant des intérêts communs — ne pouvait plus agir en tant que facteur social ou économique pour l’avenir du domaine. Parfois, il semblait que c’était une barrière insurmontable et que les tensions entre les contributeurs de longue date au logiciel libre et les nouveaux acteurs devaient conduire à un effondrement de la coopération et, peut-être, à celui des progrès accomplis. Mais un résultat aussi sombre supposait des conditions qui n’existaient tout simplement pas.

Le logiciel libre a apporté beaucoup de choses à des tas de personnes et d’organisations, en se fondant sur quelques concepts très simples comme la liberté d’utiliser, de modifier, d’améliorer et de partager la technologie. Ces concepts ont permis beaucoup de flexibilité. Et tant que les gens reconnaissaient leur valeur et continuaient à les respecter, les conflits portants sur des points secondaires comme la gouvernance ou les zones d’ombre des licences étaient plutôt sans importance — à long terme. Le reste est principalement du bruit. Les communications habituelles sont dérangées par tous ces pièges dramatiques qui arrivent inévitablement lorsqu’un groupe social est rejoint par un autre. Cela s’applique à toutes les discussions, que l’on parle d’un coin de pêche, d’un pays accueillant (ou non) les immigrants ou de deux entreprises fusionnant.

Les changements au sein du logiciel libre semblaient tous un peu confus à l’époque, mais ils se décomposent principalement en trois leçons utiles qui seront familières aux étudiants d’histoire ou de sciences politiques. Premièrement, chaque fois qu’il existe une élite, elle cherchera à préserver son statut et parlera du conflit perçu comme une évolution négative dans le but de l’ébranler. Deuxièmement, malgré la tendance inhérente de chaque base de pouvoir à être conservatrice, la participation statique dans un domaine en évolution aura pour seul effet de déplacer la possibilité d’une amélioration des parties existantes vers de tierces parties. Enfin, si quelque chose a de la valeur, alors les difficultés rencontrées en matière de gouvernance sont peu susceptibles de porter atteinte à cette valeur, mais fourniront au contraire une méthode pour redéfinir à la fois les mécanismes de gouvernance et les personnes en mesure de les appliquer.

Le développement du logiciel libre en tant que technologie démocratisée a connu une professionnalisation croissante parmi les développeurs comme dans la gestion de projets. Nous avons aussi vu s’accroître le respect envers les licences de la part des individus, des projets et des entreprises. Ce ne fut pas une mauvaise chose, et malgré quelques moments houleux le long du chemin — que l’on peut choisir parmi les querelles inter-communautaires, les entreprises qui ne tiennent pas compte des termes des licences ou l’agacement causé par un éloignement de l’esprit décontracté habituel — notre position en est consolidée, plus cohérente et de plus grande valeur.

* Aujourd’hui 28 mars, dernière séance de traduction collaborative sur ce projet avec l’épisode n°42 !

Traduction Framalang : tcit, Julius22, Sphinx, goofy, peupleLà, merlin8282, lamessen, BAud, Jej, Alpha

Modèles économiques basés sur le libre et l’open source

Carlo Daffara

Carlo Daffara est chercheur dans le domaine des modèles économiques basés sur l’open source, le développement collaboratif d’objets numériques et l’utilisation de logiciels open source dans les entreprises. Il fait partie du comité éditorial de relecture du journal international des logiciels et processus open source (International Journal of Open Source Software & Processes : IJOSSP), est membre du comité technique de deux centres régionaux de compétences open source et est également membre du réseau juridique européen FSFE (fondation européenne pour le logiciel libre). Il a pris part aux comités SC34 et JTC1 pour la branche italienne de l’ISO, UNINFO et a travaillé au sein du groupe de travail de la société Internet du logiciel public (Internet Society Public Software) ainsi que pour beaucoup d’autres initiatives liées à la normalisation.

Auparavant, Carlo Daffara était le représentant italien dans le groupe de travail européen sur le logiciel libre, la première initiative de l’Union européenne afin de soutenir l’open source et le logiciel libre. Il a présidé le groupe de travail SME du groupe d’étude de l’UE sur la compétitivité et le groupe de travail IEEE des intergiciels open source du comité technique sur le calcul évolutif. Il a travaillé en tant qu’examinateur du projet pour la commission Européenne dans le domaine de la coopération internationale, l’ingénierie logicielle, l’open source et les systèmes distribués et a été directeur de recherche dans plusieurs projets de recherche de l’Union européenne.

Introduction

« Comment gagner de l’argent avec le logiciel libre ? » était une question très courante, il y a encore seulement quelques années. Désormais, cette question s’est transformée en « Quelles sont les stratégies commerciales pouvant être mises en œuvre en se basant sur le logiciel libre et open source ? ». Cette question n’est pas aussi gratuite qu’elle peut paraître, puisque de nombreux chercheurs universitaires écrivent encore ce genre de textes : « le logiciel open source est délibérément développé hors de tout mécanisme de marché… il échoue à contribuer à la création de valeur aux développements, contrairement au marché du logiciel commercial… il ne génère pas de profit, de revenus, d’emplois ou de taxes…

Les licences open source sur les logiciels visent à supprimer les droits d’auteurs sur le logiciel et empêchent d’établir un prix pour le logiciel. Au final, les logiciels développés ne peuvent être utilisés pour générer des profits. » [Koot 03] ou [Eng 10] indiquent que « des économistes ont montré que les collaborations open source dans le monde réel s’appuient sur plusieurs incitations différentes telles qu’enseigner, se démarquer et se créer une réputation » (sans parler des incitations économiques). Cette vue purement « sociale » du logiciel libre et open source est partiale et fausse. Et nous démontrerons qu’il y a des raisons économiques liées au succès des métiers du libre et de l’open source qui vont au-delà des collaborations purement bénévoles.

Le logiciel libre et open source face aux réalités économiques

Dans la plupart des domaines, l’utilisation d’un logiciel libre et open source apporte un avantage économique substantiel, grâce aux développements partagés et aux coûts de maintenance, déjà décrits par des chercheurs comme Gosh, qui a estimé une réduction de coût de 36 % en R&D (« Recherche et Développement », NdT). La vaste part de marché des déploiements « internes » de logiciels libres et open source explique pourquoi certains des bénéfices économiques ne sont pas directement visibles sur le marché des services commerciaux.

L’étude FLOSSIMPACT a montré, en 2006, que les entreprises qui contribuent au code de projets de logiciels libres et open source ont, au total, au moins 570 000 employés et un chiffre d’affaires annuel de 263 milliards d’euros [Gosh 06], faisant ainsi du logiciel libre et open source l’un des phénomènes les plus importants des NTIC. Il est important aussi de reconnaître qu’un pourcentage non négligeable de cette valeur économique n’est pas directement perceptible du marché, vu que la majorité du logiciel n’est pas développée dans l’intention de le vendre (le soi-disant logiciel « prêt à l’emploi ») mais uniquement à usage interne. Comme le réseau thématique FISTERA EU l’a identifié, en réalité, la majorité du logiciel est développée seulement pour un usage interne.

Il est clair que ce qui est appelé « le marché logiciel » est en réalité bien plus réduit que le vrai marché du logiciel et des services et que 80 % restent invisibles. Nous verrons que le FLOSS tient une place économique importante de ce marché, directement grâce à ce modèle de développement interne.

Modèles économiques et proposition de valorisation

L’idée de base d’un modèle économique est assez simple : j’ai quelque chose ou je peux faire quelque chose (la « proposition de valeur ») et c’est plus rentable de me payer ou d’obtenir ce quelque chose plutôt que de le faire soi-même (il est même parfois impossible de trouver des alternatives, comme dans le cas de monopoles naturels ou créés par l’homme, et l’idée même de le produire par soi-même n’est pas envisageable). Il y a deux sources possibles de valeur : une propriété (quelque chose qui peut être échangé) et l’efficacité (quelque chose propre à ce que fait une entreprise et la manière dont elle le fait).

Avec l’open source, la « propriété » est généralement non exclusive (à l’exception de ce qui est nommé « cœur ouvert », où une partie du code n’est pas libre du tout et cela sera abordé plus loin dans cet article). D’autres exemples de propriété concernent le droit des marques, les brevets, les licences… tout ce qui peut être transféré à une autre entité par contrat ou par une transaction légale. L’efficacité est la capacité à effectuer une action avec un coût moindre (qu’il soit tangible ou intangible) et cela correspond à la spécialisation dans un domaine d’application ou apparaît grâce à une nouvelle technologie.

Pour le premier cas, les exemples sont simplement la réduction du temps nécessaire pour réaliser une action quand vous augmentez votre expertise concernant ce sujet. La première fois que vous installez un système complexe, cela peut demander beaucoup d’efforts et cet effort diminue d’autant plus que vous connaissez les tâches nécessaires pour réaliser l’installation elle-même. Pour le second, cela peut être l’apparition d’outils qui simplifient le processus (par exemple, avec le clonage d’images) et introduisent une importante rupture, un « saut » dans la courbe efficacité-temps.

Ces deux aspects sont la base de tout modèle économique que nous avons analysé par le passé ; il est possible de montrer que tout ceux-ci échouent afin de garantir une continuité entre les propriétés et l’efficacité.

Parmi les résultats de notre précédent projet de recherche, nous avons trouvé que les projets basés sur un modèle propriétaire ont tendance à obtenir moins de contributions extérieures car cela nécessite une opération juridique pour faire partie des propriétés de l’entreprise, pensez par exemple aux licences doubles : afin que son code fasse partie du code du produit, un contributeur extérieur doit signer l’abandon des droits sur son code afin que l’entreprise puisse vendre la version commerciale ainsi que la version open source.

D’un autre côté, les modèles totalement orientés sur l’efficacité ont tendance à avoir plus de contributions et de visibilité mais des résultats financiers plus faibles. Je l’ai écrit plusieurs fois : il n’y a pas de modèle économique idéal mais un éventail de modèles possibles et les entreprises devraient s’adapter elles-mêmes pour changer les conditions du marché et aussi adapter leur modèle. Certaines entreprises débutent par des modèles entièrement axés sur l’efficacité puis construisent, avec le temps, une propriété en interne, d’autres ont commencé avec un modèle orienté vers la propriété et ont évolué différemment pour augmenter les contributions et réduire les efforts d’ingénierie (ou développer la base d’utilisateurs afin de créer d’autres moyens d’avoir un retour financier grâce aux utilisateurs).

Une typologie des modèles économiques

L’étude EU FLOSSMETRICS des modèles économiques basés sur le logiciel libre a identifié, après analyse de plus de 200 entreprises, une taxonomie des principaux modèles économiques utilisés par les entreprises open source ; les principaux modèles identifiés sur le marché sont :

• la double licence : le même code source logiciel distribué sous GPL et sous une licence propriétaire. Ce modèle est principalement utilisé par les producteurs de logiciel et outils pour développeurs et fonctionne grâce à une forte association de la GPL, qui requiert que les travaux dérivés et logiciels liés directement soient distribués sous la même licence. Les entreprises ne souhaitant pas distribuer leur propre logiciel sous GPL peuvent obtenir une licence propriétaire leur octroyant une exemption des conditions de la GPL, ce qui semble souhaitable à certains. L’inconvénient de cette licence double est que les contributeurs externes doivent accepter des conditions similaires et cela a révélé des réductions de contributions externes, se limitant à des corrections de bogues et des ajouts mineurs ;
• le modèle « cœur ouvert » (précédemment appelé « valeur ajoutée propriétaire » ou « séparation entre libre et propriétaire » \* ? *\) : ce modèle se distingue entre un logiciel libre basique et une version propriétaire, basée sur la version libre mais avec l’ajout de greffons propriétaires. La plupart des entreprises qui suivent un tel modèle adoptent la Mozilla Public Licence, car elle permet explicitement cette forme de mélange et permet une plus grande participation des contributions externes sans les mêmes contraintes de consolidation du droit d’auteur comme dans l’usage de doubles licences. Ce modèle a l’inconvénient intrinsèque que le logiciel libre doit être de grande valeur pour être attractif pour les utilisateurs, i.e. il ne doit pas être réduit à une version aux possibilités limitées, tout comme, dans le même temps, il ne doit pas « cannibaliser » le produit propriétaire. Cet équilibre est difficile à atteindre et à maintenir dans la durée ; en outre, si le logiciel est de grand intérêt, les développeurs peuvent essayer d’apporter les fonctionnalités manquantes dans le logiciel libre, réduisant ainsi l’intérêt de la version propriétaire et donnant potentiellement naissance à un logiciel concurrent entièrement libre qui ne souffrira pas des mêmes limitations ;
• les experts produits : des entreprises qui ont créé ou maintiennent un projet logiciel spécifique et utilisent une licence libre pour le distribuer. Les principaux revenus viennent du service, comme la formation ou l’expertise, et suivent la classification EUWG d’origine « le meilleur code vient d’ici » et « les meilleures compétences sont ici » [DB 00]. Cela conforte l’impression, courante, que les experts les plus compétents sur un logiciel sont ceux qui l’ont développé et qu’ils peuvent ainsi fournir des services au prix d’un démarchage minimal, s’appuyant sur la fourniture gratuite du code. L’inconvénient de ce modèle est que le coût d’entrée pour des concurrents potentiels est faible, vu que le seul investissement nécessaire est l’acquisition des compétences sur le logiciel lui-même ;
• les fournisseurs de plateforme :des entreprises qui apportent un ensemble de services, avec support et intégration de certains projets, constituant une plateforme cohérente et testée. En ce sens, même les distributions GNU/Linux sont classées en tant que plateforme ; une observation intéressante est que ces distributions sont distribuées en grande partie sous licence libre pour maximiser les contributions externes et s’appuyer sur la protection du droit d’auteur pour empêcher la copie sauvage sans empêcher les « déclinaisons » (suppression des particularités soumises à droit d’auteur comme les logos ou droit des marques, pour créer un nouveau produit). Des exemples de clones de Red Hat sont CentOS et Oracle Linux. La valeur ajoutée provient d’une qualité garantie, de la stabilité et de la fiabilité ainsi que d’une garantie de support pour les applications métier critiques ;
• les entreprises de conseil et de recrutement : les entreprises de cette catégorie ne font pas vraiment de développement mais fournissent des conseils de sélection et des services d’évaluation pour un large éventail de projets, d’une manière qui est proche du rôle de l’analyste. Ces entreprises ont tendance à avoir un impact très limité sur les communautés car les résultats de l’évaluation et du processus d’évaluation sont généralement des données propriétaires ;
• les fournisseurs de support global : des entreprises qui proposent un support centralisé pour un ensemble de produits de logiciel libre, généralement en employant directement les développeurs ou en remontant les demandes de support ;
• la validation juridique et l’expertise : ces entreprises n’apportent pas de développements de code source mais fournissent une aide à la vérification de conformité aux licences, parfois en apportant une garantie et une assurance contre les attaques juridiques ; certaines entreprises utilisent des outils pour assurer que le code n’est pas réutilisé ;
• la formation et la documentation : des entreprises qui proposent de la formation, en ligne et en présentiel, des documentations et des manuels supplémentaires. Cela est généralement fourni dans le cadre d’un contrat de support, mais, récemment, quelques réseaux de centres de formation ont lancé des cours orientés spécifiquement vers le logiciel libre ;
• le partage des coûts de R&D : une entreprise ou une société peut avoir besoin d’une nouvelle version ou d’une amélioration d’un paquet logiciel et financer un consultant ou un développeur pour réaliser le travail. Plus tard, le logiciel développé est redistribué en open source pour bénéficier de l’ensemble des développeurs expérimentés pouvant le déboguer et l’améliorer. Un bon exemple est la plateforme Maemo, utilisée par Nokia pour ses smartphones (comme le N810) ; au sein de Maemo, seul 7,5 % du code est propriétaire, apportant une réduction des coûts estimée à 228 millions de dollars (et une réduction du temps de mise sur le marché d’un an). Un autre exemple est l’écosystème Eclipse, un environnement de développement intégré (EDI) distribué à l’origine par IBM comme logiciel libre puis ensuite géré par la fondation Eclipse. De nombreuses entreprises ont choisi Eclipse comme socle pour leur produit et ont ainsi réduit le coût global pour la création d’un logiciel fournissant une fonctionnalité pour les développeurs. Il y a un grand nombre d’entreprises, d’universités et de personnes qui participent à l’écosystème Eclipse. Comme récemment constaté, IBM contribue aux alentours de 46 % au projet, les contributeurs à titre personnel représentant 25 % et un grand nombre d’entreprises comme Oracle, Borland, Actuate et de nombreuses autres ayant des participations allant de 1 à 7 %. Ceci est semblable aux résultats obtenus grâce à l’analyse du noyau Linux et qui montre que, lorsqu’il y a un écosystème sain et de grande taille, le partage des tâches réduit de manière significative les coûts de maintenance, dans [Gosh 06], on estime qu’il est possible de faire des économies de l’ordre de 36 % dans la recherche et la conception logicielle grâce à l’utilisation du logiciel libre, ces économies constituent en elles-mêmes le plus gros « marché » réel pour le logiciel libre, ce qui est démontré par le fait qu’au moins une partie du code des développeurs est basé sur du logiciel libre (56,2 % comme mentionné dans [ED 05]). Un autre excellent exemple de « coopétition » inter-entreprises est le projet WebKit, le moteur de rendu HTML à la base du navigateur Google Chrome ainsi que d’Apple Safari et qui est utilisé dans la majorité des appareils mobiles. Dans ce projet, après un délai initial d’un an, le nombre de contributions externes a commencé à devenir significatif et, après un an et demi, il surpasse largement les contributions d’Apple — réduisant de fait les coûts de maintenance et d’ingénierie grâce à la répartition des tâches entre les co-développeurs ;
• les revenus indirects : une entreprise peut choisir de financer des projets de logiciel libre si ces projets peuvent créer une source de revenus importante pour des produits dérivés, non liés directement au code source ou au logiciel. L’un des cas les plus courants correspond à l’écriture de logiciel nécessaire au fonctionnement de matériel, par exemple, les pilotes d’un système d’exploitation pour un matériel spécifique. En fait, de nombreux fabricants de matériel distribuent déjà gratuitement leurs pilotes logiciels. Certains d’entre eux distribuent déjà certains de leurs pilotes (surtout ceux pour le noyau Linux) sous une licence libre. Le modèle du produit d’appel est une stratégie commerciale traditionnelle, répandue même à l’extérieur du monde du logiciel : dans ce modèle, les efforts sont consacrés à un projet de logiciel libre et open source afin de créer ou d’étendre un autre marché dans des conditions différentes. Par exemple, les fournisseurs de composants matériels investissent dans le développement de pilotes logiciels pour des systèmes d’exploitation open source (comme GNU/Linux) pour s’étendre sur le marché spécifique des composants. D’autres modèles de revenus auxiliaires sont ceux, par exemple, de la fondation Mozilla qui réunit une somme d’argent non négligeable grâce à un partenariat avec Google sur le moteur de recherche (estimé à 72 millions de dollars en 2006), tandis que SourceForge/OSTG est financé en majorité par les recettes des ventes en ligne du site partenaire ThinkGeek.

Certaines entreprises ont plus d’un modèle principal et sont, par conséquent, comptées en double ; notamment, la plupart des entreprises pratiquant une licence double vendent aussi du service de support. En outre, les experts d’un produit ne sont comptés que s’ils ont une partie visible de leur entreprise qui contribue au projet en tant que « commiter principal ». Autrement, le nombre d’experts serait bien plus élevé, du fait que certains projets sont au cœur du support commercial de nombreuses entreprises (de bons exemples sont OpenBravo et Zope).

Il faut aussi tenir compte du fait que les fournisseurs de plateforme, même s’ils sont limités en nombre, tendent à avoir des taux de facturation plus élevés que les experts ou que les entreprises à cœur ouvert. De nombreux chercheurs essaient d’identifier s’il y a un modèle plus « efficace » parmi ceux pris en compte ; ce que nous avons trouvé est que le futur le plus probable sera l’évolution d’un modèle à l’autre, avec une consolidation sur le long terme des consortiums de développement (comme les fondations Eclipse et Apache) qui fournissent une forte infrastructure légale et des avantages de développement ainsi que des spécialistes apportant des offres verticales pour des marchés spécifiques.

Conclusion

Le logiciel libre et open source permet non seulement une présence pérenne, et même très large, sur le marché (Red Hat est déjà proche du milliard de dollars de revenus annuels), mais aussi plusieurs modèles différents qui sont totalement impossibles avec le logiciel propriétaire. Le fait que le logiciel libre et open source est un bien non concurrent facilite aussi la coopération entre entreprises, tant pour accroître sa présence mondiale et pour signer des contrats à grande échelle pouvant demander des compétences multiples que sur le plan géographique (même produit ou service, région géographique différente) ; « verticalité » (entre produits) ou « horizontalité » (des domaines d’application). Cet adjuvant à créer de nouveaux écosystèmes est l’une des raisons expliquant que le logiciel libre et open source fait partie intégrante de la plupart des infrastructures informatiques dans le monde, enrichissant et aidant les entreprises et administrations publiques à réduire leurs coûts et à collaborer pour de meilleurs logiciels.

Bibliographie

• [DB00] Daffara, C.Barahona, J.B. Free Software/Open Source: Information Society Opportunities for Europe working paper,http://eu.conecta.it paper, OSSEMP workshop, Third international conference on open source. Limerick 2007
• [ED05] Evans Data, Open Source Vision report, 2005
• [Eng10] Engelhardt S. Maurer S. The New (Commercial) Open Source: Does it Really Improve Social Welfare Goldman School of Public Policy Working Paper No.GSPP10-001, 2010
• [Gar06] Gartner Group, Open source going mainstream. Gartner report, 2006
• [Gosh06] Gosh, et al. Economic impact of FLOSS on innovation and competitiveness of the EU ICT sector. http://bit.ly/cNwUzû
• [Koot03] Kooths, S.Langenfurth, M.Kaiwey,N.Open-Source Software: An Economic Assessment Technical report, Muenster Institute for Computational Economics (MICE), University of Muenster

Bientôt la dernière séance… rejoignez-nous jeudi prochain sur le framapad de traduction

Traduction Framalang : Ouve, tcit, Julius22, goofy, merlin8282, lamessen, Jej, Alpha

Sous-estimer la valeur d’un modèle économique pour le logiciel libre

Frank Karlitschek

Frank Karlitschek est né en 1973 à Reutlingen, en Allemagne, et a commencé à écrire des logiciels à l’âge de 11 ans. Il a étudié l’informatique à l’université de Tübingen et s’est impliqué dans le logiciel libre et les technologies de l’internet dans le milieu des années 1990. En 2001, il a commencé à contribuer à KDE en lançant KDE-Look.org, un site communautaire d’œuvres qui deviendrait plus tard le réseau openDesktop.org. Frank a initié plusieurs projets et initiatives open source comme Social Desktop, Open Collaboration Services, Open-PC et ownCloud. En 2007, il a fondé une société appelée hive01 qui offrait des services et des produits autour de l’open source et des technologies de l’internet. Aujourd’hui, Frank est membre du conseil et vice-président de KDE e.V. et c’est un intervenant habitué des conférences internationales.

Introduction

Il y a dix ans, j’ai sous-estimé la valeur d’un modèle économique. Logiciel libre et modèle économique ? Deux concepts incompatibles. Du moins, c’est ce que je pensais lorsque j’ai commencé à contribuer à KDE en 2001. Le logiciel libre, c’est pour le plaisir et pas pour l’argent. N’est-ce pas ? Les libristes veulent un monde où chacun peut écrire du logiciel et où les grandes entreprises, telles que Microsoft ou Google, sont superflues. Tout logiciel devrait être libre et tous ceux qui souhaitent développer du logiciel devraient en avoir la possibilité — même les développeurs du dimanche. Donc, gagner de l’argent importe peu. N’est-ce pas ? Aujourd’hui, j’ai une opinion différente. Les développeurs devraient parfois être rémunérés pour leurs efforts.

Les raisons d’être du logiciel libre

La plupart des développeurs de logiciels libres ont deux principales motivations pour travailler sur le logiciel libre. La première motivation est le facteur plaisir. C’est une expérience fantastique de travailler avec d’autres personnes très talentueuses du monde entier et de créer des technologies exceptionnelles. KDE, par exemple, est une des communautés les plus accueillantes que je connaisse. C’est tellement amusant de travailler avec des milliers de contributeurs du monde entier pour créer des logiciels qui seront utilisés par des millions de personnes. Pour faire simple, tout le monde est expert dans un ou plusieurs domaines et nous collaborons pour créer une vision partagée. Pour moi, c’est toujours génial de rencontrer d’autres contributeurs de KDE, d’échanger des idées ou de travailler sur nos logiciels ensemble, que nous nous rencontrions en ligne ou dans la vie réelle à une des nombreuses conférences ou événements. Et il s’agit aussi d’amitié. Au fil des années, je me suis fait beaucoup de bons amis au sein de KDE.

Mais les contributeurs de KDE ne sont pas uniquement motivés par le plaisir de rejoindre KDE. Il y a aussi l’idée que chacun de nous peut rendre le monde meilleur par nos contributions. Le logiciel libre est essentiel si vous vous souciez de l’accès à la technologie et à l’informatique pour les pays en voie de développement. Cela permet aux personnes pauvres d’avoir leur place dans l’ère de l’information sans acheter des licences coûteuses pour des logiciels propriétaires. Il est essentiel pour les personnes qui se soucient de la confidentialité et de la sécurité, parce que le logiciel libre est le seul et unique moyen de savoir exactement ce que votre ordinateur fait avec vos données privées. Le logiciel libre est important pour un écosystème informatique sain, parce qu’il permet à tout le monde de bâtir à partir du travail des autres et de vraiment innover. Sans le logiciel libre, il n’aurait pas été possible à Google ou Facebook de lancer leurs entreprises. Il n’est pas possible d’innover et de créer la nouvelle technologie marquante si vous dépendez de logiciels propriétaires et que vous n’avez pas accès à toutes les parties du logiciel.

Le logiciel libre est aussi indispensable pour l’éducation, parce que tout le monde peut voir les entrailles du logiciel et étudier son fonctionnement. C’est comme cela que le logiciel libre contribue à faire du monde un endroit meilleur et c’est pourquoi je participe à des projets de logiciel libre comme KDE.

La nécessité d’un écosystème

Voilà les principales raisons pour lesquelles je veux que le logiciel libre et particulièrement le bureau libre soient largement répandus. Pour y parvenir, il nous faut bien plus de contributeurs qu’aujourd’hui. Par contributeurs, j’entends des gens qui écrivent les infrastructures centrales, le bureau et les grandes applications. Nous avons besoin de gens qui travaillent sur l’utilisabilité, sur les illustrations, sur la promotion et sur bien d’autres aspects importants. KDE est déjà une grande communauté avec des milliers de membres. Mais nous avons besoin de davantage de gens pour aider à rivaliser de manière sérieuse avec le logiciel propriétaire.

La communauté du logiciel libre est minuscule comparée au monde du logiciel propriétaire. D’un côté, ce n’est pas un problème car le modèle de développement logiciel distribué du monde du logiciel libre est bien plus performant que la façon d’écrire du logiciel à sources fermées. Un grand avantage est, par exemple, la possibilité de mieux réutiliser du code. Mais même avec ces avantages, nous avons besoin de bien plus de contributeurs qu’aujourd’hui si nous voulons réellement conquérir le marché de l’ordinateur de bureau et celui du mobile.

Nous avons aussi besoin d’entreprises pour nous aider à apporter notre travail sur le marché de masse. Bref, nous avons besoin d’un grand écosystème en forme permettant de vivre en travaillant sur le logiciel libre.

La situation actuelle

J’ai commencé à contribuer à KDE il y a plus de 10 ans et, depuis, j’ai vu d’innombrables volontaires très motivés et talentueux rejoindre KDE. C’est vraiment génial. Le problème, c’est que j’ai aussi vu beaucoup de contributeurs expérimentés abandonner KDE. C’est vraiment triste. Parfois, c’est simplement la marche normale du monde : les priorités changent et les gens se concentrent sur autre chose. Le problème, c’est que beaucoup abandonnent aussi à cause de l’argent. Il arrive un moment où les gens décrochent leur diplôme et veulent bouger de leur chambre d’étudiant.

Plus tard, ils veulent se marier et avoir des enfants. À partir de là, ils doivent trouver du travail. Il y a quelques entreprises dans l’écosystème de KDE qui proposent des postes liés à KDE. Mais cela ne représente qu’une petite part des emplois disponibles dans le secteur informatique. Du coup, beaucoup de membres chevronnés de KDE doivent travailler dans des entreprises où ils doivent utiliser des logiciels propriétaires qui n’ont rien à voir avec KDE ou le logiciel libre. Tôt ou tard, la plupart de ces développeurs abandonnent KDE. J’ai sous-estimé cette tendance il y a 10 ans, mais je pense que c’est un problème pour KDE sur le long terme, parce que nous perdons nos membres les plus expérimentés au profit des entreprises de logiciel propriétaire.

Le monde de mes rêves

Dans le monde idéal que j’imagine, les gens peuvent payer leur loyer en travaillant sur les logiciels libres et ils peuvent le faire de telle sorte que ça n’entre pas en conflit avec nos valeurs. Ceux qui contribuent à KDE devraient avoir tout le temps qu’ils veulent pour contribuer à KDE et au monde libre en général. Ils devraient gagner de l’argent en aidant KDE. Leur passe-temps deviendrait leur travail. Cela permettrait à KDE de se développer de manière spectaculaire, parce que ce serait super de contribuer et de fournir en même temps de bonnes perspectives d’emploi stables et à long terme.

Quelles possibilités avons-nous ?

Du coup, quelles sont les solutions possibles ? Que pouvons-nous faire pour que ça arrive ? Y a-t-il des moyens pour que les développeurs paient leur loyer tout en travaillant sur du logiciel libre ? Je voudrais exposer ici quelques idées que j’ai rassemblées au cours de plusieurs discussions avec des contributeurs au logiciel libre. Certaines d’entre elles sont probablement polémiques, parce qu’elles introduisent des idées complètement neuves au sein du monde du logiciel libre. Mais je pense qu’il est essentiel pour nous de voir au-delà de notre monde actuel si nous voulons mener à bien notre mission.

Du développement sponsorisé

Aujourd’hui, de plus en plus d’entreprises apprécient l’importance du logiciel libre et contribuent à des projets de logiciels libres, ou sortent même leurs propres projets de logiciel libre. C’est une chance pour les développeurs de logiciels libres. Nous devrions parler à davantage d’entreprises et les convaincre de s’associer au monde du logiciel libre.

Des dons de la part des utilisateurs

Il devrait y avoir une manière facile pour les utilisateurs de donner de l’argent directement aux développeurs. Si un utilisateur d’une application populaire veut soutenir le développeur et promouvoir ses développements à venir pour cette application, donner de l’argent devrait ne tenir qu’à un clic de souris. Le système de dons peut être construit au sein même de l’application pour rendre le don d’argent aussi facile que possible.

Des primes

L’idée derrière les primes est qu’un ou plusieurs utilisateurs d’une application peuvent payer pour le développement d’une fonctionnalité particulière. Un utilisateur peut soumettre la liste de ses demandes de nouvelles fonctionnalités sur un site web et annoncer combien il est prêt à payer pour cela. D’autres utilisateurs qui apprécient ces propositions pourraient ajouter de l’argent à la demande de fonctionnalité. Au bout d’un moment, le développeur commence à mettre au point la fonctionnalité et récupère l’argent des utilisateurs. Cette possibilité de primes n’est pas facile à introduire dans le processus. Des gens ont déjà essayé de mettre en place quelque chose de similaire, sans succès. Mais je pense que ça peut marcher si on s’y prend bien.

Du support

L’idée est que le développeur d’une application vende directement du support aux utilisateurs de l’application. Par exemple, les utilisateurs d’une application achètent du support pour, supposons, 5 € par mois et obtiennent le droit d’appeler directement le développeur à des plages horaires spécifiques de la journée, ils peuvent poser des questions à une adresse de courriel spécifique, ou le développeur peut  même aider les utilisateurs par le biais d’un bureau à distance. J’ai bien conscience que beaucoup de développeurs n’aimeront pas l’idée que les utilisateurs puissent les appeler et leur poser des questions bizarres. Mais si cela signifie qu’ils gagnent suffisamment avec le système de support pour travailler à plein temps sur leurs applications, alors c’est certainement une bonne chose.

Des soutiens

L’idée c’est que les utilisateurs finaux puissent devenir les soutiens d’une application. Le bouton « Soutenez ce projet » pourrait être intégré directement dans l’application. L’utilisateur devient alors un soutien par un paiement mensuel de, par exemple, 5 € qui vont directement au développeur. Tous les soutiens sont listés dans la fenêtre « À propos de l’application » avec leurs photos et leurs noms réels. Une fois par an, tous les soutiens sont aussi invités à une fête spéciale avec les développeurs. Il est possible qu’un développeur puisse devenir capable de travailler à plein temps sur une application, si assez d’utilisateurs deviennent des soutiens.

Des programmes de fidélité

Certaines applications ont intégré des services web, et certains de ces services Web exécutent des programmes affiliés. Par exemple, un lecteur multimédia peut être intégré à la boutique en ligne de MP3 Amazon ou un lecteur PDF peut être intégré à une boutique en ligne de livres numériques. À chaque fois qu’un utilisateur achète du contenu via cette application, le développeur obtient un peu d’argent.

Des magasins d’applications sous forme de binaires

Beaucoup de gens ne savent pas qu’il est possible de vendre des binaires de logiciels libres. La licence GPL exige simplement de fournir également le code source. Il est donc parfaitement légal de vendre des binaires bien empaquetés de notre logiciel. En réalité, les sociétés comme Red Hat et Novell vendent déjà notre logiciel dans leurs distributions commerciales. Mais les développeurs n’en bénéficient pas directement. Tous les revenus vont aux sociétés et rien ne va aux développeurs. On devrait donc permettre aux développeurs de logiciels libres de vendre à l’utilisateur final des applications bien empaquetées, optimisées et testées. Cela pourrait particulièrement bien fonctionner pour Mac ou Windows. Je suis sûr qu’un tas de gens seraient prêts à payer quelque chose pour des binaires d’Amarok pour Windows ou de digiKam pour Mac, si tout l’argent allait directement au développeur.

Conclusion

La plupart de ces idées ne sont pas faciles à mettre en œuvre. Cela nécessite de modifier notre logiciel, nos méthodes de travail et même nos utilisateurs, qu’il faut encourager à montrer qu’ils apprécient le logiciel que nous créons, en nous aidant à financer son développement. 

Cependant, les bénéfices potentiels sont énormes. Si nous pouvons assurer des sources de revenus pour notre logiciel, nous pouvons conserver nos meilleurs contributeurs et peut-être en attirer de nouveaux. Nos utilisateurs auront une meilleure expérience avec un développement logiciel plus rapide, la possibilité d’influencer directement le développement par le biais de primes et un meilleur support.

Le logiciel libre n’est plus seulement un loisir sur votre temps libre. Il est temps d’en faire un business.

Bientôt la dernière séance de traduction ! Jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction framalang : tcit, Julius22, Sky, lamessen, goofy, peupleLà, merlin8282, lamessen, Jej, Alpha

Le Logiciel Libre dans le secteur public

Till Adam

Issu du milieu de la musique et des sciences humaines, Till Adam a passé pas loin des dix dernières années dans le monde de la programmation. Il travaille au sein de KDAB où il dirige plusieurs services, dont celui qui est en charge des logiciels libres. Till officie aussi au sein du conseil d’administration de Kolab Systems AG, une entreprise dont le modèle économique repose entièrement sur les logiciels libres. Il vit avec sa femme et sa fille à Berlin.

Introduction

J’imagine que comme de nombreux autres auteurs de cette compilation d’articles, j’ai commencé à contribuer au logiciel libre lorsque j’étais étudiant. J’avais décidé relativement tard dans ma vie de poursuivre un cursus en informatique (ayant échoué à devenir riche et célèbre en tant que musicien). Je m’attendais donc à être légèrement plus âgé que mes pairs en obtenant mon diplôme. J’ai donc pensé qu’il serait bénéfique d’apprendre par moi-même la programmation, qui ne m’était pas trop enseignée à l’école, afin de d’avoir plus d’atouts aux yeux de futurs employeurs, en dépit de mon âge. Après quelques incursions dans diverses petites communautés, j’ai finalement trouvé ma voie dans le projet KDE et j’ai commencé à travailler sur l’application de courriel.

Grâce aux personnes extrêmement serviables et douées techniquement que j’y ai rencontrées, j’ai pu apprendre rapidement et contribuer de façon significative au code, ce qui m’a entraîné de plus en plus dans leur réseau social, mais aussi vers le domaine fascinant des problèmes techniques liés à la gestion de données personnelles.

Lorsque KDAB, une entreprise remplie de gens qui utilisaient KDE, m’a demandé si, dans le cadre d’un stage étudiant, je voulais les aider sur la partie commerciale d’un projet en cours, j’ai bien sûr été ravi de pouvoir gagner ma vie et bidouiller le logiciel KDE en même temps. Au fil des ans, j’ai été témoin de l’adoption et de l’utilisation des architectures de gestion des données personnelles de KDE par le secteur public, particulièrement en Allemagne, où j’ai pu y assister personnellement à la croissance économique de KDAB dans ce secteur géographique. Alors que j’évoluais vers des postes plus orientés sur le management, vendre et livrer des services issus du logiciel libre comprenant des produits de KDE à de grandes organisations, en particulier dans le secteur public, a finalement fait partie de mon travail.

Il faut noter que la plupart du travail sur le projet qui a inspiré ce texte était généralement fait en collaboration avec d’autres entreprises du logiciel libre, à savoir glOcode, un spécialiste de la cryptographie qui se charge du maintien de GNUPG, et Intevation, une entreprise de conseil qui se concentre exclusivement sur le logiciel libre ainsi que ses défis stratégiques et opportunités. Mention spéciale à Bernhard Reiter, l’un des fondateurs d’Intevation, qui a joué un rôle clé lors de la vente et de la conduite de bon nombre de ces projets. Les quelques fragments de sagesse contenus dans ce texte sont probablement issus de son analyse et des nombreuses conversations que j’ai pu avoir avec lui au fil des ans.

Donc, si Bernhard et moi pouvions revenir dans le temps, quelles pourraient donc bien être les idées que nous partagerions avec nos « nous »  plus jeunes et plus naïfs ? Eh bien, il s’avère qu’elles commencent toutes par la lettre P.

Personnes

Telles que sont les choses aujourd’hui, il est toujours plus difficile pour les gens de terrain des technologies de l’information et pour les décideurs d’utiliser du logiciel libre que ça ne l’est d’utiliser les alternatives propriétaires. Même en Allemagne, où le logiciel libre a un soutien politique relativement fort, il est plus facile et plus sûr de suggérer l’utilisation de quelque chose qui est perçu comme un « standard de l’industrie » ou comme « ce que tous les autres font » ; en d’autres termes, des solutions propriétaires.

Celui qui propose une solution en logiciel libre fera probablement face à de l’opposition de la part de collègues moins aventureux (ou ayant moins de vision), à un examen minutieux des supérieurs, à de plus grandes attentes par rapport aux résultats et à une pression budgétaire irréaliste. Il faut donc un type particulier de personnes souhaitant prendre des risques personnels, potentiellement compromettre l’avancée de leur carrière et combattre dans une bataille presque perdue d’avance. Ceci est bien sûr vrai dans n’importe quelle organisation. Mais, dans une administration publique, une ténacité particulière est requise car les choses bougent généralement plus lentement. Et une hiérarchie organisationnelle inflexible ajoutée à des options de carrière limitées amplifient le problème.

Sans allié à l’intérieur, faire envisager de façon sérieuse les options du logiciel libre peut s’avérer quasiment impossible. Si de telles personnes existent, il est important de les soutenir autant que possible dans leurs luttes internes. Ceci signifie leur fournir des informations opportunes, fiables et vérifiables sur ce qui se passe dans la communauté avec laquelle l’organisation entend interagir. Ces informations doivent contenir suffisamment de détails pour fournir une image complète tout en atténuant la complexité de la communication et du chaos de planification faisant parfois partie de la façon de travailler dans le monde du logiciel libre, de façon à ce que ça devienne plus gérable et moins effrayant. L’honnêteté et le sérieux aident à construire des relations fortes avec ces personnes-clés, qui sont la base du succès à plus long terme. Elles se reposent sur vous, en tant qu’intermédiaire avec le monde merveilleux et quelque peu effrayant des communautés du logiciel libre, pour trouver des chemins qui les mèneront elles et leurs organisations à leurs objectifs. Elles prennent également des décisions en se basant largement sur la confiance personnelle. Cette confiance doit être acquise et conservée.

Afin d’y parvenir, il est important de ne pas se concentrer uniquement sur les résultats techniques des projets, mais de garder en tête les objectifs plus larges, personnels et organisationnels que l’on doit atteindre lorsqu’on travaille sur ces projets. Le succès ou l’échec du projet en cours ne dépendra peut-être pas du fait qu’un responsable de projet au sein d’une agence soit capable de ne vanter que des fonctionnalités auxiliaires à ses supérieurs à des moments plus ou moins aléatoires du calendrier. Mais cela impactera peut-être le fait que le projet suivant se fasse ou ne se fasse pas. Lorsque vous avez peu d’amis, les aider à réussir est un bon investissement.

Priorités

En tant que technophiles, les gens du logiciel libre ont tendance à se concentrer sur ce qui est nouveau, excitant et qui paraît important au niveau technologique. En conséquence de quoi, nous mettons moins l’accent sur les choses qui sont plus importantes dans le contexte d’une administration publique (souvent vaste). Mais considérez quelqu’un désireux de changer tout un ensemble de technologies dans une structure qui a plutôt tendance à rester sur les mêmes technologies pendant une longue durée. Étant donné qu’un changement brusque est difficile et coûteux, il est de loin bien plus important d’avoir de la documentation sur les choses qui ne fonctionneront pas, de façon à pouvoir les éviter ou les contourner, que de savoir qu’une version à venir fonctionnera beaucoup mieux. Il est peu probable que cette nouvelle version soit jamais disponible pour les utilisateurs dpnt nous parlons ici. Et il est bien plus simple d’avoir affaire à des problèmes connus et anticipés plutôt que d’être forcé de faire face à des surprises. Le bogue documenté d’aujourd’hui est paradoxalement préférable à sa résolution de demain avec ses effets de bord imprévisibles.

Dans une grande organisation qui utilise des logiciels pendant une longue durée, le coût d’acquisition du logiciel, que ce soit par le biais de licences ou dans le cadre de développement sur mesure de logiciels libres par contrat, a peu d’importance en comparaison du coût de maintenance et de support. Cela mène à penser que moins de fonctionnalités, plus stables, ce qui induit une moindre charge pour le  l’organisme de support, auxquelles on peut faire plus confiance et qui ont moins besoin de maintenance intensive sont meilleures que de séduisantes nouveautés, complexes et sans doute moins matures.

Alors que ces deux sentiments vont à l’encontre des instincts des développeurs de logiciels libres, ce sont ces mêmes aspects qui rendent attractif pour le secteur public le fait de payer pour le développement de logiciels libres, plutôt que de dépenser de l’argent pour des licences de produits pris au hasard. En partant d’une large palette de logiciels gratuitement disponibles, l’organisation peut investir son budget dans le perfectionnement des parties précises qui sont pertinentes pour ses propres opérations. Elle n’a ainsi pas à payer (via les coûts de licences) pour le développement de fonctionnalités clinquantes et guidées par le marché dont elle n’a pas besoin. En soumettant tout ce travail à la communauté en retour, la maintenance à long terme de ces améliorations et du logiciel de base est partagée par un grand nombre de personnes. De plus, grâce au fait que ces améliorations deviennent publiques, d’autres organisations aux besoins similaires peuvent bénéficier de celles-ci sans coût supplémentaire. Cela maximise donc l’utilité de l’argent du contribuable, ce que toute administration publique souhaite (ou devrait souhaiter).

Politique d’approvisionnement

Si les budgets informatiques des agences gouvernementales sont clairement mieux utilisés dans l’amélioration du logiciel libre et dans son adaptation à leurs besoins, pourquoi est-ce si rarement ce que l’on fait ? L’équivalence des fonctionnalités pour les types de logiciels les plus utilisés a depuis longtemps été atteinte, la convivialité est la même, la robustesse et le coût total de possession aussi. La notoriété et la connaissance sont bien sûr toujours des problèmes, mais le véritable obstacle à l’acquisition de services en logiciel libre réside dans les conditions légales et administratives sous lesquelles cela doit se produire. Changer ces conditions nécessite du travail, au niveau de la politique et du lobbying. C’est rarement possible dans le contexte d’un projet individuel. Heureusement, des organisations telles que la Free Software Foundation Europe et sa sœur aux États-Unis font du lobbying en notre nom et font lentement changer les choses. Jetons un coup d’œil à deux problèmes centraux d’ordre structurel.

Des licences, pas des services

Beaucoup de budgets informatiques sont structurés de telle façon qu’une partie de l’argent est mise de côté pour l’achat d’un nouveau logiciel ou pour le paiement continu de l’utilisation d’un logiciel sous forme de licences. Comme il était inimaginable pour ceux qui ont construit ces budgets qu’un logiciel puisse être autre chose qu’un bien achetable, représenté par une licence propriétaire, il est souvent difficile ou impossible pour les décideurs informatiques de dépenser cette même somme d’argent pour des services. La comptabilité de gestion n’en entendra simplement pas parler. Cela peut mener à la situation malheureuse où une organisation a la volonté et l’argent pour améliorer un morceau de logiciel libre afin qu’il convienne parfaitement à ses besoins, pour le déployer et pour le faire tourner pendant des années et envoyer ses contributions à la communauté, en retour, mais où cela ne peut se faire tant que toute l’affaire n’est pas enveloppée dans une vente et un achat artificiels et non nécessaires d’un produit imaginaire basé sur une licence libre.

Pièges légaux

Les cadres légaux pour les fournisseurs de logiciels supposent souvent que quiconque signant la production d’un logiciel exerce le plein contrôle des copyrights, marques déposées et brevets afférents. L’organisation cliente attend une garantie contre des risques variés de la part du fournisseur. Dans le cas où une société ou une personne produit une solution ou un service basé sur du logiciel libre, cela est souvent impossible car il y a d’autres titulaires de droits qui ne peuvent pas être raisonnablement impliqués dans l’arrangement contractuel. Ce problème apparaît plus ostensiblement dans le contexte des brevets logiciels. Il est pratiquement impossible pour un fournisseur de services de s’assurer contre les risques de contentieux de brevets, ce qui rend très risqué pour lui d’endosser la pleine responsabilité.

Prix

Historiquement, l’argument le plus vendeur du logiciel libre donné au grand public a été son potentiel pour d’économie d’argent. Le logiciel libre a en effet permis des économies à grande échelle pour beaucoup d’organisations depuis de nombreuses années. Le système d’exploitation GNU/Linux a été le fer de lance de ce développement. Ceci en raison de sa libre disponibilité au téléchargement qui a été perçue en opposition frappante avec les licences onéreuses de son principal concurrent, Microsoft Windows.

Pour quelque chose d’aussi utilisé et utile qu’un système d’exploitation, il est indéniable que le bénéfice des coûts structurels vient des coûts de développement qui sont répartis sur de nombreuses parties. Malheureusement, l’espoir que ceci reste vrai pour tous les logiciels libres a mené à la pensée irréaliste que les coûts seront toujours réduits, largement et immédiatement. D’après notre expérience, ce n’est pas vrai. Comme nous l’avons vu dans les sections précédentes de cet ouvrage, il est très logique de tirer le meilleur parti de l’argent dépensé dans l’utilisation de logiciels libres et il est probable qu’au fil du temps et pour de nombreuses organisations de l’argent puisse être économisé. Mais pour une agence isolée qui cherche seulement à déployer un logiciel libre, il devra y avoir un investissement initial et un coût nécessaire associé pour obtenir le niveau de maturité et de robustesse nécessaire.

Alors que cela semble largement raisonnable aux professionnels des opérations informatiques, il est souvent plus difficile de convaincre de cette vérité leurs supérieurs avec le bilan financier. Surtout lorsque la potentielle économie de moyens financiers a initialement été utilisée comme un argument pour faire entrer le logiciel libre, il peut s’avérer très difficile de gérer efficacement les attentes futures. Plus vite les décideurs sauront exactement de façon claire combien et dans quoi ils investissent, mieux ils accepteront de le faire sur le long terme

Le meilleur rapport qualité-prix est toujours attirant et un fournisseur de services informatiques qui cessera d’être disponible à cause de la pression des prix et n’obtiendra pas suffisamment de réussite économique est aussi peu attractif dans le logiciel libre que dans les modèles économiques basés sur des licences propriétaires. Il est donc aussi dans l’intérêt des clients que les estimations de coûts soient réalistes et que les conditions économiques dans lesquelles le travail est effectué soient durables.

Conclusion

Notre expérience montre qu’il est possible de convaincre des organismes du secteur public de dépenser de l’argent dans des services basés sur des logiciels libres. C’est une proposition intéressante qui offre une plus-value et qui a un sens politique. Malheureusement, il existe encore des barrières structurelles. Mais avec l’aide de pionniers dans le secteur public, elles peuvent être contournées. Avec un soutien suffisant de notre part à tous, ceux qui travaillent pour le logiciel libre au niveau politique finiront par les surmonter. Une communication claire et honnête sur les réalités économiques et techniques peut favoriser des partenariats efficaces qui amènent des bénéfices à la communauté du logiciel libre, aux administrations publiques utilisant ces logiciels et à ceux qui les fournissent avec les services nécessaires dans un cadre viable et durable.

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

Traduction Framalang : Ouve, Julius22, Sphinx, CoudCoud, grosfar, lum’, goofy, peupleLà, lamessen

Nous ne sommes pas fous… Nous organisons des conférences !

Gareth J. Greenaway

Gareth J. Greenaway s’est impliqué activement dans la communauté du logiciel libre et open source depuis 1997 après avoir découvert Linux. Sa contribution majeure a consisté à regrouper des gens ayant la même opinion pour apprendre et expérimenter de nouveaux éléments de logiciel libre et open source. Cette implication a débuté avec un petit groupe d’utilisateurs de Linux (un « GUL ») et s’est développée avec l’organisation de la « Southern California Linux Expo », aussi connue sous le nom de SCALE. En tant que membre fondateur de cet évènement, Gareth remplit actuellement deux fonctions importantes au sein de l’organisation. La première est la gestion des conférences et la seconde concerne les relations avec la communauté.

J’ai commencé à écrire cette section avec ce que je pensais être les besoins et les étapes pour organiser une conférence sur le libre et l’open source. Cependant, une grande partie de ce que je trouvais à dire avait déjà été abordé par Dave Neary, expert en gestion de communautés. Donc, pour éviter de répéter et de recouper ce que Dave voulait expliquer, j’ai décidé de partager différentes histoires de l’organisation de SCALE et les leçons que j’en ai tiré pendant ces années.

Trop d’énergie !

SCALE a commencé il y a maintenant neuf ans avec des membres de trois groupes locaux d’utilisateurs de Linux, ce n’était à l’origine qu’un modeste évènement régional organisé par l’un de ces groupes. La première expérience fut vraiment enrichissante. Beaucoup de leçons en ont été tirées. On courait un peu partout et l’évènement semblait se dérouler à une vitesse folle. Étant donné qu’aucun de nous n’avait encore organisé d’évènement où il fallait se soucier des risques de surtension ou de consommation électrique, nous n’y avons pas pensé, et, du coup, nous avons dû ré-enclencher les disjoncteurs de la salle plusieurs fois pendant l’évènement.

Ça va marcher… c’est sans fil !

Le deuxième SCALE a pris en compte un grand nombre de leçons apprises l’année précédente mais un nouveau lieu de rencontre allait donner de nouvelles leçons. Le centre de conférences de Los Angeles est le lieu où s’est tenu SCALE 2, il fournissait un espace bien plus grand pour installer l’évènement. Le nouveau lieu nous a aussi permis d’apprendre notre première leçon sur les contrats avec un grand organisme pour gérer les choses telles que l’équipement audio et vidéo, l’accès à Internet et le matériel d’exposition.

Compte tenu de la situation de l’évènement à l’intérieur du centre de conférences, nous avons dû positionner les comptoirs d’enregistrement dans une zone qui, tout en étant visible des participants qui arrivaient, se trouvait à une certaine distance du reste du salon. Nos possibilités pour fournir un accès réseau à la zone d’enregistrement étaient limitées car les règles de protection anti-incendie proscrivaient l’utilisation de câbles ; le sans-fil était donc l’unique option.

Tout a été mis en place très tôt le jour du salon et fonctionnait parfaitement bien, jusqu’à ce que cela cesse mystérieusement de marcher. La connexion sans fil, fournissant l’accès au réseau indispensable au comptoir d’enregistrement, a tout simplement disparu. Nous avons alors vécu beaucoup de tentatives de dépannages, beaucoup de déplacements d’équipements et d’antennes et beaucoup de frustration. « Ça devrait fonctionner. » était la seule conclusion à laquelle tout le monde pouvait parvenir, sans trop savoir pourquoi cela ne fonctionnait pas.

Soudain, un des membres de l’équipe, qui s’était tenu à l’écart de la séance de dépannage, a appelé tout le monde à venir à l’endroit où il se trouvait. En face d’une grande fenêtre qui surplombait un grand hall de réunion, nous avons tout à coup tous vu ce qu’il désirait nous faire voir. En-dessous de nous il y avait des dizaines de lumières clignotantes, tournantes et pulsantes qui nous regardaient. Des centaines d’appareils électroniques avec des lumières clignotantes, des sirènes et des panneaux à LED (diodes électro-luminescentes), interférant narquoisement avec les signaux sans fil de nos pauvres points d’accès. Nous avons soudain réalisé que nos heures de travail à tenter de résoudre ce problème de sans-fil avaient été vaines. Finalement, nous avons déroulé un câble Ethernet, l’avons scotché de la manière la plus sécurisée que nous avons pu, et nous avons dit une petite prière pour que le chef des pompiers ne fasse pas d’inspection surprise.

Soirées de gala, tireurs d’élite et disparition mystérieuse de mallette IBM

L’une des anecdotes les plus célèbres dans l’histoire de SCALE est sans doute celle des incidents et péripéties qui sont survenus pendant SCALE 3. Ces aventures sont bien connues, et si vous assistiez à SCALE cette année-là, vous n’avez pas pu y échapper.

Le troisième SCALE devait se dérouler encore une fois au centre de conférences de Los Angeles au L.A. Convention Center. Tout le travail de planification et d’organisation avait été mené en amont pendant de nombreux mois et tout s’annonçait bien. Trois semaines environ avant l’évènement, nous avons reçu des informations à propos de plusieurs routes qui seraient fermées autour du centre de conférences à cause d’une soirée de gala qui devait avoir lieu. À cause de ces fermetures de routes, il n’y avait plus qu’une voie d’accès pour accéder au centre et en repartir, ce qui est loin d’être idéal. Fort heureusement, nous avons eu le temps d’avertir tous ceux qui venaient à l’évènement et de leur indiquer les routes fermées à la circulation et les itinéraires alternatifs. Cette année-là, c’était aussi la première fois que SCALE devait se dérouler sur deux jours, dans l’espoir de répartir un peu les choses pour ne pas être autant dans la précipitation et la frénésie.

L’un des plus anciens sponsors et exposants de SCALE est IBM. Ils ont toujours été une plus-value appréciée, mais, malheureusement, leur participation s’est généralement accompagnée de quelques difficultés. La veille de l’évènement, comme d’habitude, avait été réservée à la mise en place pour permettre à l’équipe de SCALE de tout installer et aux exposants de préparer leurs stands. C’est également le jour de réception de tous les paquets envoyés par les exposants. IBM avait prévu de présenter une nouvelle ligne de serveurs sur le salon et avait fait expédier un de ces serveurs au centre de conférences ; malheureusement, il n’avait pas été livré sur leur stand et personne dans le centre de conférences ne savait où pouvait bien se trouver le colis. Malgré de nombreuses heures à chercher dans tous les endroits possibles à l’intérieur du centre de conférences, nous n’avions pas la moindre piste.

Il se trouve que le gala qui devait avoir lieu quelques jours plus tard avait loué un certain nombre de pièces pour en faire des bureaux et des espaces de stockage. Dans un éclair de génie, le coordinateur de l’évènement qui aidait à la recherche suggéra que nous pourrions chercher dans un de leurs espaces de stockage en espérant que la mallette d’IBM ait été livrée là par accident. La pièce en question était un petit placard de rangement dans lequel nous nous sommes trouvés face à des montagnes de boîtes, du sol jusqu’au plafond, remplies de tickets pour la soirée de gala à venir. Derrière ces boîtes, dans un coin, il y avait une grande mallette bleue avec le logo IBM bien visible. Crise évitée !

Le reste de l’évènement se déroula sans heurts et pratiquement sans incidents. Alors que l’évènement se finissait, une petite foule commença à se former près de grandes fenêtres donnant sur la rue. Alors que je passais à cet endroit, je pris conscience de ce que tout le monde était en train de regarder. Plusieurs silhouettes, toutes vêtues de noir, se déplaçaient sur les toits des bâtiments le long de la rue. Toutes ces silhouettes portaient des fusils de précision et étaient des membres de l’équipe du SWAT de la police de Los Angeles qui se préparaient pour la soirée de gala qui allait avoir lieu plus tard. Ce fut sans conteste une sortie mémorable du centre de conférences.

Pas de chambre à l’hôtel

Le quatrième SCALE a occasionné un nouveau changement de lieu. Cette fois-ci, nous sommes passés à un hôtel à la place d’un centre de conférences. Comme avec les années de plus en plus de personnes voyageaient pour assister à SCALE et séjournaient dans des hôtels proches, nous avons décidé d’étudier la possibilité que SCALE ait lieu dans un hôtel. Nous avons parcouru la région et avons fini par consulter un organisateur d’évènements pour trouver le bon endroit pour le nôtre. En nous installant dans un hôtel proche de l’aéroport de Los Angeles, la planification commença. Tenir l’évènement dans un hôtel nous a rapidement confrontés à de nouvelles problématiques propres aux hôtels. Une des plus importantes leçons que nous avons alors apprises a été de s’assurer que tous les contrats comportaient une clause convenue d’annulation.

À peu près cinq semaines avant l’évènement, nous avons reçu un appel des responsables du lieu qui nous informaient que leur entreprise annulait notre évènement pour attribuer le lieu à une autre manifestation. Cela a évidemment été un choc pour nous et nous a plongé dans la plus grande confusion. Le contrat avec l’hôtel ne comprenait pas une ligne sur les cas de résiliation pour changement de lieu, mais précisait seulement qu’ils pouvaient annuler la manifestation sans aucun motif.

Après un grand nombre de coups de téléphone et de tractations avec les responsables du lieu initial, ils ont fini par accepter de nous indemniser pour nous aider à migrer vers un lieu de remplacement. Lequel nous a consenti les mêmes conditions pour tout ce qui concernait l’électricité, l’accès à Internet et l’équipement audio et vidéo. Tout s’est bien passé et l’équipe de SCALE en a tiré une précieuse leçon sur la façon de négocier ses futurs contrats.

Rappel !

Tout compte fait, organiser une conférence est une entreprise gratifiante et un excellent moyen de rendre à la communauté ce qu’elle nous a apporté. Les conférences constituent un moment privilégié car elles permettent des échanges en personne dans un monde qui repose couramment sur des moyens de communication virtuels.

Voici les conseils que je donnerais à des organisateurs de conférences :

• commencez modestement, ne vous lancez pas dans un gigantesque évènement dès la première année ;
• saisissez les occasions, faites des erreurs, n’ayez pas peur de l’échec ;
• tout est dans la communication !

Vous venez de crever et vous vous retrouvez malencontreusement sur le bord de la route pour changer votre pneu. Tout d’un coup un policier arrive et vous verbalise parce que vous enfreignez je ne sais quel copyright de la marque de votre véhicule stipulant que vous n’avez pas le droit d’y changer quoi que ce soit. C’est surréaliste et pourtant c’est bien la situation actuelle des téléphones portables.

Quid d’un monde sous contrôle où les objets ne nous appartiennent plus faute d’avoir le droit de les bidouiller ?

Oubliez la bataille du téléphone portable – Nous devrions pouvoir déverrouiller tout ce qui nous appartient

Forget the Cellphone Fight — We Should Be Allowed to Unlock Everything We Own

Kyle Wiens – 18 mars 2013 – Wired Opinion
(Traduction : Alpha, Sphinx, aKa, marc, lgodard, M0tty, jtanguy, Moosh, Floréal, K4ngoo, Texmix + anonymes)

Alors que le Congrès des Etats-Unis travaille sur une loi visant à ré-autoriser le déverrouillage des téléphones portables, regardons le vrai problème en face : les lois issues du copyright qui ont d’abord fait que le déverrouillage devienne illégal. À qui appartiennent les objets que nous possédons ? La réponse avait pour habitude d’être évidente. Dorénavant, avec l’électronique, omniprésente dans tous les objets que nous achetons, la réponse a changé.

Nous vivons dans une ère numérique, et même les produits matériels que nous achetons sont complexes. Le copyright impacte plus de monde qu’auparavant car la frontière entre logiciel et matériel, ente monde physique et numérique, s’amenuise.

Le problème ne se réduit pas seulement au déverrouillage des téléphones portables ; quand on achète un objet, n’importe lequel, nous devrions le posséder. Nous devrions être en mesure de soulever le capot, l’ouvrir, le modifier, le réparer, etc… sans demander la permission au fabriquant.

Sauf que nous ne possédons pas vraiment nos objets (enfin pas dans la totalité), les fabricants sont les vrais propriétaires. Parce que la modification d’un objet moderne requiert un accès à de l’information : du code, des documents de conception, des codes d’erreur, des outils de diagnostic… Les voitures modernes sont des mécaniques puissantes mais également des ordinateurs sophistiqués. Les fours à micro-ondes sont une combinaison de plastique et de microcode. Le silicium imprègne et alimente presque tout ce que nous possédons.

C’est un problème de droits de propriété, et les lois actuelles sur le copyright prennent ce problème à l’envers, transformant les gens ordinaires, comme les étudiants, les chercheurs et les patrons de petites entreprises, en délinquants. Par exemple l’entreprise de télécoms Avaya, qui fait partie du top 500 de Fortune, est connue pour poursuivre des entreprises de services en justice, les accusant de violer le copyright simplement parce qu’elles utilsent un mot de passe pour se connecter à leurs systèmes téléphoniques. Vous avez bien lu : rentrer un mot de passe est considéré comme : une « reproduction de matériel soumis au copyright ».

Les fabricants ont systématiquement utilisé le copyright en ce sens ces 20 dernières années pour limiter notre accès à l’information. La technologie a avancé trop vite par rapport aux lois sur le copyright, les sociétés ont exploité cette latence pour créer des monopoles de l’information à nos dépens et à leur bénéfice. Après des années d’expansion et de soi-disantes améliorations, le copyright a transformé Mickey Mouse en un monstre immortel.

Cela n’a pas toujours été ainsi. Les lois sur le copyright ont été créés à l’origine pour protéger la créativité et promouvoir l’innovation. Mais maintenant, elles font exactement le contraire. Elles sont utilisées pour empêcher les entreprises indépendantes de réparer les nouvelles voitures. Elles rendent presque impossible aux agriculteurs de réparer leur matériel. Et, comme nous l’avons vu ces dernières semaines, elles empêchent les particuliers de déverrouiller leurs propres téléphones portables.

Ce n’est pas juste un problème qui affecte seulement les spécialistes en informatique ; les fermiers sont également touchés. Kerry Adams, un agriculteur dans une ferme familiale de Santa Maria en Californie, a récemment acheté deux machines de transplantation pour la modique somme de 100000$ pièce. Elles sont tombées en panne juste après, et il a dû faire venir un technicien de l’usine pour les faire réparer.

Comme les constructeurs ont mis un copyright sur les notices techniques, les techniciens locaux ne peuvent pas réparer les appareils récents. De plus, les appareils actuels, remplis de capteurs et d’électronique, sont trop complexes pour être réparés sans la notice technique. C’est un problème pour les agriculteurs qui n’ont pas les moyens de payer les frais d’entretien élevés pour de l’outillage qui se détériore assez vite.

Adams a abandonné l’idée de faire réparer ses repiqueurs, c’était tout simplement trop cher de faire venir les techniciens en déplacement jusqu’à son exploitation. À présent, les deux repiqueurs sont à l’arrêt et il ne peut pas s’en servir pour subvenir aux besoins de son exploitation et de sa famille.

Dieu a peut-être donné vie à un fermier, mais les lois sur le copyright ne lui permettent plus de gagner sa vie.

Dans le proche domaine de la mécanique automobile, le copyright est aussi vu comme un étau, restreignant leur capacité à résoudre des problèmes. Les erreurs de code dans votre voiture ? Protégés. Les outils de diagnostic pour y accéder ? Des logiciels propriétaires.

Les nouvelles voitures se sophistiquent année après année, et les mécaniciens ont besoin d’un accès aux informations systèmes pour rester dans la course. Sous la protection du copyright, les constructeurs automobiles ont empêché l’accès des garagistes indépendants aux outils de diagnostic et aux schémas de fonctionnement dont ils ont besoin.

Les mécaniciens n’abandonnent pas pour autant. En septembre dernier, le Massachusetts a acté une loi sur le Droit à Réparer destinée à niveler le champ d’action entre les concessions et les garagistes indépendants. Sous le cri de ralliement de « C’est votre voiture, vous devriez avoir la possibilité de la réparer où vous le souhaitez », la loi a été adoptée à une très large majorité de 86%. Cette loi contourne le copyright, forçant les constructeurs à publier toutes les informations techniques aux propriétaires de véhicules du Massachusetts et aux techniciens système. L’agitation populaire se propage : les législateurs du Maine viennent de mettre en place une législation similaire.

Pendant ce temps, des progrès sont faits vers la légalisation du déverrouillage des téléphones portables. Avec des groupes locaux menant le combat, l’administration Obama a annoncé son soutien à l’annulation de cette interdiction la semaine dernière. Les membres du Congrès ont depuis rédigé pas moins de quatre projets de loi pour légaliser le déverrouillage.

C’est un pas dans la bonne direction mais ce n’est pas assez. Que les choses soient claires : réparer nos voitures, tracteurs, et téléphones portables ne devrait rien avoir à faire avec le copyright.

Tant que le Congrès se concentre simplement sur le déverrouillage des mobiles, il passera à côté du vrai problème. Les sénateurs peuvent adopter cents projets de loi sur le déverrouillage ; dans cinq ans, les grandes entreprises trouveront d’autres revendications de copyright pour limiter le choix des consommateurs. Pour vraiment résoudre le problème, le Congrès doit promulguer une réforme du copyright qui soit significative. Les bénéfices économiques potentiels sont significatifs, étant donné que l’information libre crée des emplois. Les informations techniques sont accessibles librement sur internet pour de nombreux smartphones sur iFixit (mon organisation) et d’autres sites. Ce n’est pas par hasard que des milliers d’entreprises de réparation de mobiles ont fleuri ces dernières années, exploitant les connaissances techniques pour éloigner les téléphones portables cassés des décharges.

Tant que nous serons limités dans notre faculté à modifier et réparer les choses, le copyright, pour tous les objets, entravera la créativité. Il nous en coûtera de l’argent. Il nous en coûtera des emplois. Et cela nous coûte déjà notre liberté.

Crédit photo : Håkan Dahlström (Creative Commons By)

La guerre des formats vidéos sur le Web bat son plein, sans que nous puissions à priori faire grand-chose (c’est dans la cour des grands que cela se passe, avec un Google qui est ici du bon côté de la Force).

Et une fois de plus les brevets sont pointés du doigt…

Codecs vidéo : les sales affaires derrière les belles images

Video codecs: The ugly business behind pretty pictures

Simon Phipps – 15 mars 2013 – InfoWorld.com
(Traduction : audionuma, goofy, KoS + anonymes)

Lorsque Google a annoncé la semaine dernière qu’il avait fait la paix avec le gestionnaire de brevets MPEG-LA à propos de son codec VP8, certains ont déclaré que l’entreprise avait cédé et rejoint le cirque des brevets logiciels. Il n’en est rien.

La vérité est bien plus complexe et pourrait annoncer de grands changements dans la lutte pour le contrôle de nos habitudes de visionnage et d’écoute en ligne. En conséquence, de puissants intérêts sont rapidement intervenus pour tenter de museler les canons du VP8 avant qu’ils ne tonnent.

Le contexte des codecs

Le secteur des codecs vidéo est complexe et truffé d’acronymes et de manœuvres politiques depuis des dizaines d’années. Même ceux qui sont les plus impliqués dans cette situation sont en désaccord, tant sur la réalité que sur l’histoire de cette situation. Voici un résumé :

Lorsque vous téléchargez ou visionnez une vidéo, vous pouvez la considérer comme du QuickTime, du Flash ou même de l’Ogg, mais ce ne sont que des mécanismes de distribution. La vidéo représente une énorme quantité de données, et vous la faire parvenir requiert de la compression de données. Le contenu d’une vidéo est encodé dans un format obtenu par un logiciel de compression de données, et est ensuite affiché sur votre écran après que ce contenu ai été décodé par un logiciel de décodage.

Le codec est le logiciel qui réalise ce processus. Les travaux théoriques sur les codecs sont exceptionnellement complexes, et il y a toujours un compromis entre la compression maximale, le temps nécessaire à compresser les données, et la qualité optimale. C’est ainsi qu’il existe une grande variété de codecs, et le savoir-faire concernant leur implémentation est un bien précieux.

Dès 1993, il devint évident qu’une standardisation des formats de données pris en charge par les codecs était nécessaire. Les institutions internationales de standardisation ISO et IEC constituèrent un groupe d’experts appelé le Motion Picture Expert Group (groupe des experts de l’image animée, MPEG) qui a depuis produit une série de standards destinés à divers usages.

Le secteur est truffé de techniques brevetées. La standardisation des codecs est basée sur le modèle du secteur des télécommunications, dans lequel il est commun de permettre à des techniques brevetées de devenir des standards pour ensuite en dériver des paiements de licences pour chaque implémentation. Pour faciliter la collecte des royalties, une société appelée MPEG-LA, LLC (qui, pour rajouter à la confusion, n’a aucun lien avec avec MPEG) a été constituée pour gérer un portefeuille de brevets au nom de la plupart des détenteurs de brevets qui contribuent aux standards MPEG.

Ce dispositif fonctionnait correctement dans l’ancien monde basé sur des points de passages obligés où les sociétés étaient les créateurs de logiciels. Mais la nouvelle société basée sur le réseau et les techniques qu’il utilise (tel que l’open source) ne fonctionne pas correctement dans un modèle où chaque nouvelle utilisation nécessite d’abord de demander la permission. Les éléments qui nécessitent une autorisation a priori — les points de passage obligés — sont des insultes à Internet. Ils sont considérés comme des nuisances, et les experts cherchent des solutions pour les éviter.

La naissance des codecs ouverts

Lorsqu’il fut clair que le Web ouvert avait besoin de codecs ouverts pour traiter des formats de médias ouverts, de brillants esprits commencèrent à travailler au contournement de ces problèmes. La sciences des codecs est bien documentée, mais l’utilisation de n’importe laquelle des techniques bien connues risquait d’enfreindre des brevets logiciels contrôlés par MPEG-LA. Il ne suffisait pas de simplement modifier un standard dérivé de MPEG pour contourner les brevets. Ces standards avaient créé un tel maquis de brevets que n’importe quel nouveau projet utilisant les mêmes calculs mathématiques était quasiment certain d’enfreindre un portefeuille de brevets quelque part.

La création de codecs ouverts réclamait une nouvelle réflexion. Heureusement, certains intérêts commerciaux travaillaient sur des idées de codecs alternatifs. Une entreprise nommée On2, notamment, avait créé une famille de codecs basée sur des idées hors du champ des brevets MPEG et avait déposé ses propres brevets pour éviter de se faire marcher sur les pieds. En 2001, elle publia une technologie de codecs appellée VP3 en open source, technologie protégée par ses propres brevets. Cette technologie constituait la base de ce qui devint Theora. On2 continua à travailler pour produire une série de codecs dédiés à des niches jusqu’à son acquisition par Google en 2010.

Le VP8 était le codec de On2 à la pointe de la technologie, offrant à la fois une excellente qualité d’image et une bonne compression des données. Peu après l’acquisition de On2 par Google, ce dernier rendit libre l’utilisation de VP8, créant un engagement d’ouverture pour tous les brevets lui étant liés, et déclara que le nouveau projet WebM offrirait un format totalement libre et ouvert pour la lecture de vidéos.

Évidemment, MPEG-LA a senti la menace et a rapidement décidé de contre-attaquer. Il a presque immédiatement annoncé la constitution d’un portefeuille de brevets pour vendre des licences sur des brevets qu’il était certain que WebM et VP8 violaient, et a invité les détenteurs habituels de brevets à lui communiquer toutes informations sur ces brevets.

Une lueur d’espoir

Et puis … plus rien. Il semble que les coups d’épée de MPEG-LA étaient plutôt des bruits de fourreau. L’accord avec MPEG-LA que Google a annoncé était formulé avec beaucoup de soins pour ne pas froisser les parties prenantes, mais il semble indiquer que MPEG-LA avait les mains vides :

Aujourd’hui, Google Inc. et MPEG-LA, LLC ont annoncé qu’ils ont conclu un compromis qui accorde à Google une licence sur les techniques, quelles qu’elles soient, qui pourraient être essentielles à VP8. De plus, MPEG-LA a accepté de mettre fin à ses efforts pour constituer un portefeuille de brevets autour de VP8.

Vous pouvez constater qu’il n’y pas grand-chose de valeur qui soit licencié dans ce cas, puisque Google est apparemment autorisé à :

…rétrocéder les licences à n’importe quel utilisateur de VP8, que l’implémentation de VP8 soit celle de Google ou d’une autre entité : cela signifie que les utilisateurs peuvent développer des implémentations de VP8 indépendantes et bénéficier de la protection accordée par la rétrocession de licence.

Le communiqué continue avec deux déclarations importantes. Premièrement, Google a le projet de soumettre VP8 à MPEG pour standardisation. Cela constituerait un profond changement d’orientation, qui pourrait orienter les futurs efforts hors du maquis des brevets et vers des territoires plus ouverts. Deuxièmement, Google a l’intention de proposer VP8 comme codec « obligatoire à implémenter » dans le groupe RTCWEB de l’IETF qui définit les protocoles permettant les communications en temps-réel dans les navigateurs Web : WebRTC.

Si tout cela réussissait, cela ouvrirait de grandes opportunités pour les logiciels open source et le web ouvert. Libérés de la course à la rente des détenteurs de brevets, les développeurs open source seraient enfin libres d’innover dans le domaine des applications audio et vidéo sans avoir en permanence à surveiller leurs arrières ou à demander la permission.

Naturellement, de puissants groupes d’intérêts continuent à essayer de ralentir, voire interrompre, cette révolution. À peine Google avait-il publié son communiqué à propos de VP8, de l’accord avec MPEG-LA et de son intention de standardiser, que deux messages furent postés sur la liste de discussion de l’IETF-RTCWEB. Le premier, envoyé par le collaborateur de Microsoft Skype Matthew Kaufmann, essayait de ralentir les progrès vers la standardisation et invoquait les règles et le débat pour tenir VP8 hors des prochaines discussions de standardisation. Le deuxième, envoyé par l’ancien spécialiste des brevets de Nokia Stephan Wenger, invoquait aussi les règles mais plus inquiétant, sous-entendait que MPEG-LA n’était pas seul à pouvoir jouer ce jeu là. Cette crainte prit bientôt corps dans un message du collaborateur de Nokia Markus Isomaki annoncant que Nokia — qui n’est pas membre de MPEG-LA — avait l’intention de démontrer que VP8 enfreint un de ses brevets.

C’est la vie de tous les jours dans le monde des codecs et c’est riche d’enseignements sur les dangers des brevets logiciels. Une fois acceptés et institutionnalisés comme processus normaux et légaux, ils contrôlent tout le reste. Bien que VP8 vienne d’un héritage technologique différent, ayant prudemment évité la masse des brevets déposés lors des premiers travaux sur le MPEG, et ayant ainsi été scrupuleusement ouvert par Google (il devait se corriger lors du processus, ce qu’il fit admirablement), le monde oppressant des brevets tente de le faire tomber dans ses griffes et de le contrôler, afin de le soumettre à la taxation sur l’innovation imposée par les vainqueurs de la première course technologique.

Nous ne pouvons pas faire grand-chose à part observer avec anxiété l’initiative de Google pour le Web ouvert. Dans cette histoire, il apparaît plus clairement que jamais que la réforme du système des brevets pour aboutir à une société plus juste et harmonisée se fera encore attendre.

Crédit photo : Seth Anderson (Creative Commons By-Sa)