Notre énergie, enthousiasme et optimisme ne doivent pas nous faire oublier les deux principaux écueils qui menacent en permanence ce blog, et peut-être aussi par extension toute la dite « Communauté du Libre ».

Le premier est la tentation d’enjoliver la situation et d’alimenter ainsi une mythologie, voire même une idéologie. Du côté open source, on n’aura de cesse de venter la qualité des logiciels libres, les vertus d’une organisation en mode « bazar et les formidables opportunités économiques offertes par le service autour du logiciel libre. Tandis que du côté free software, on mettra l’accent sur une éthique et un ensemble de valeurs, ainsi synthétisés non sans emphase par Richard Stallman en ouverture de ses conférences : « Je puis résumer le logiciel libre en trois mots : liberté, égalité, fraternité ».

Le second écueil consiste à croire, ou feindre de croire, que le modèle proposé par les logiciels libres est reproductible en dehors de la sphère informatique, l’exemple emblématique étant la « culture libre », dont nous serions bien en peine d’en proposer une définition exacte. Certains vont même jusqu’à voir dans ce modèle une possible alternative globale pour nos sociétés, qualifiées, peut-être trop vite d’ailleurs, de sociétés de l’information.

C’est pourquoi nous avons lu avec beaucoup d’intérêt le long mais passionnant article de Sébastien Broca « Du logiciel libre aux théories de l’intelligence collective » (paru initialement dans la Revue tic&société – Société de l’information ? Vol. 2, N° 2, 2008). Article que nous avons reproduit ci-dessous d’abord parce qu’il n’a peut-être pas eu toute l’attention qu’il méritait mais aussi telle une invitation à débattre ensemble des arguments avancés dans les commentaires.

Sébastien Broca est allocataire de recherche au Cetcopra (Univerisité Paris 1) où il réalise un doctorat de sociologie. Il résume ainsi son propos :

Cet article interroge la manière dont le mouvement du logiciel libre se trouve constitué dans de nombreux discours en modèle d‘avant-garde de transformations sociales globales. Je montre ainsi comment l’on passe d’une pratique singulière, mise en œuvre par les communautés du libre, à des théories sociologiques, économiques ou philosophiques, qui s’en inspirent largement. Je m’appuie pour ce faire sur les ouvrages récents de Pekka Himanen, Yann Moulier Boutang, Antonio Negri et Michael Hardt. J’essaie ensuite de mettre en lumière certaines difficultés relatives aux démarches de ces auteurs : généralisation abusive à partir de l’exemple du logiciel libre, et oubli des spécificités des divers domaines de la vie sociale.

Le frontispice du Framablog est orné de la citation suivante : « …mais ce serait l’une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d’autre que du code »^[1]. C’est une question ouverte dont nous sentons bien, même confusément, l’extraordinaire potentiel. Encore faudrait-il être capable de l’affiner régulièrement avec lucidité et ne pas emprunter certaines postures peut-être parfois trop simplistes eu égard à la complexité du monde bien réel qui nous entoure…

PS : Pour un meilleur confort vous pouvez également lire ou imprimer la version PDF de l’article.

Du logiciel libre aux théories de l’intelligence collective

URL d’origine du document

Sébastien Broca – Revue tic&société – Société de l’information ? Vol. 2, N° 2, 2008
Mis à jour le 7 mai 2009 – Licence Creative Commons By-Nc-Nd

Introduction

Depuis une quinzaine d’années, le mouvement du logiciel libre a connu un développement fulgurant, mettant fortement en question la prééminence des logiciels propriétaires développés par les grandes entreprises du secteur informatique. Dans le même temps, certains intellectuels ont érigé ces bouleversements en symboles de transformations sociales plus générales, attendues ou espérées. En témoignent les occurrences nombreuses des références à la « démocratie open source », à « l’économie open source », voire à la « société open source ». Cette tendance à faire du mouvement du logiciel libre un des laboratoires où se préparerait la société du futur semble devoir nous interpeller à plus d’un titre. Elle incite d’une part à s’interroger sur le bien-fondé d’une démarche intellectuelle prenant appui sur une pratique spécifique, pour fonder un discours théorique à valeur générale et/ou prospective. Elle invite d’autre part à mener une réflexion critique sur les nouvelles grilles d’analyse, censées rendre compte des spécificités de notre époque.

Nous commencerons ainsi par retracer brièvement l’histoire du mouvement du logiciel libre, et par en rappeler les enjeux. Nous essaierons ensuite de montrer comment, sous l’effet d’un double mouvement d’idéalisation des pratiques et de généralisation de leur portée, les communautés du libre se trouvent présentées, dans un certain nombre de discours contemporains, comme porteuses d’un véritable modèle social d’avant-garde. Nous nous efforcerons aussi d’interroger les limites de ces discours, qui tendent à observer notre époque à travers le prisme unique du développement de pratiques de collaboration horizontales médiatisées par Internet.

1. Histoire et enjeux du mouvement du logiciel libre

1.1. Une brève histoire du libre

Le mouvement du logiciel libre se comprend comme une réaction aux changements intervenus dans l’industrie informatique au tournant des années 1970-1980, au moment où apparaît l’ordinateur personnel. Jusqu’à cette date, les utilisateurs et les programmeurs sont souvent les mêmes personnes, et à quelques exceptions près, ils peuvent librement modifier les logiciels, quand bien même ceux-ci sont soumis au copyright. Comme l’explique Eben Moglen,

dans la pratique, les logiciels pour supercalculateurs étaient développés de manière coopérative par le constructeur de matériel dominant et par ses utilisateurs techniquement compétents … (Moglen, 2001, p. 160).

La situation évolue au début des années 1980. De nombreuses sociétés informatiques décident alors d’imposer des logiciels propriétaires, de privatiser du code auparavant libre, et de soumettre leurs informaticiens à des clauses de confidentialité^[2].

Pour mesurer ces bouleversements, il faut savoir qu’un logiciel se présente sous deux formes. La première, dite version exécutable ou compilée, est écrite en « binaire ». C’est celle qui est lue par l’ordinateur, et elle n’est pas compréhensible pour un humain. La deuxième en revanche – appelée code source – n’est pas fonctionnelle, mais peut être appréhendée comme du « commentaire ». Écrite dans un langage de programmation compréhensible, elle explique aux développeurs comment fonctionne le programme. L’accès au code source est donc indispensable à qui veut opérer des modifications sur un logiciel. Or, c’est précisément cet accès qui se trouve fortement restreint par le mouvement de privatisation survenu au début des années 1980, qui empêche donc la communauté des informaticiens de collaborer pour améliorer les programmes.

C’est dans ce contexte que Richard Stallman, alors informaticien au laboratoire d’intelligence artificielle du MIT (Massachusetts Institute of Technology), décide en 1983 d’entreprendre la programmation d’un système d’exploitation entièrement « libre ». Il nomme celui-ci GNU (GNU is Not Unix), marquant ainsi sa volonté de se démarquer des nouvelles pratiques de l’informatique commerciale et de retrouver l’esprit coopératif d’antan. En 1985, il crée la Free Software Foundation pour faciliter le financement et le développement du projet. Les principes du logiciel libre sont formalisés en janvier 1989 dans la licence publique générale (GPL – General Public License). Celle-ci garantit aux utilisateurs quatre « libertés » : liberté d’utiliser le logiciel, liberté de le copier, liberté de le modifier (ce qui implique l’accès au code source), et liberté de le distribuer (y compris dans des versions modifiées). Tout logiciel respectant l’ensemble de ces « libertés » peut dès lors être considéré comme un « logiciel libre »^[3].

Au début des années 1990, le projet GNU a abouti à l’écriture d’un système d’exploitation presque complet. Presque, car le noyau du système^[4] fait encore défaut. Intervient alors la deuxième grande figure de l’histoire du logiciel libre : Linus Torvalds. À cette époque, cet étudiant finlandais de l’université d’Helsinki cherche à écrire un noyau, selon la légende pour pouvoir utiliser sur son ordinateur personnel les programmes sur lesquels il travaille dans le cadre de ses études. Il a alors l’idée brillante de rendre disponible sur Internet son travail inachevé, et d’inciter les informaticiens qui le souhaitent à le compléter. Grâce aux listes de diffusion et aux forums électroniques, des centaines puis des milliers de programmeurs en viennent à unir leurs efforts pour développer ce noyau, entre-temps nommé Linux. Bientôt, la combinaison des logiciels GNU et du noyau Linux donne naissance à un système d’exploitation complet : GNU/Linux, plus couramment appelé Linux.

Celui-ci a aujourd’hui acquis une solide réputation de fiabilité, et est devenu le concurrent principal de Windows. Il est emblématique de la réussite du logiciel libre, dont témoignent également Firefox, Apache, Open Office, et bien d’autres. Au fil des ans, ces succès ont éveillé l’intérêt des géants du secteur informatique, et ont favorisé une pénétration croissante des logiques économiques dans le monde du libre. Un exemple significatif est celui d’IBM. Alors que l’entreprise est en difficulté, ses dirigeants décident en 1999 de rendre libres de grandes quantités de lignes de code propriétaires, et de mettre en place des équipes pour travailler sur les projets Apache et Linux. Ce soutien à des projets libres est une réussite, et il s’amplifie à partir de 2002. Les bénéfices qu’en retire IBM sont en effet multiples : économies substantielles^[5], réorientation de son activité vers de nouvelles offres de service^[6], amélioration de son image…

1.2. L’idéologie du Libre

L’influence croissante des grands groupes informatiques a suscité d’importantes réserves et révélé quelques fractures parmi les défenseurs du logiciel libre. En témoigne notamment la controverse ayant éclaté à la fin des années 1990, suite au lancement de l’Open Source Initiative. Cette organisation est créée en 1998 pour promouvoir un label dissident (OSI approved), censé être moins contraignant que la licence GPL, et donc plus attractif pour le monde des affaires. L’initiative est condamnée par Richard Stallman et la Free Software Foundation, bien que dans les faits,la différence entre les deux labels devienne assez rapidement de pure forme^[7]. Le débat – parfois virulent – entre les deux parties met en lumière la coexistence au sein du monde du libre de deux « philosophies » assez nettement opposées. Pour les partisans de l’open source, les logiciels libres doivent êtres défendus pour l’unique raison qu’ils sont meilleurs que les logiciels propriétaires ! À l’inverse, pour les défenseurs du free software et son fondateur Richard Stallman, la performance technologique est une préoccupation secondaire par rapport au mouvement social que représente le logiciel libre, et aux principes qu’il défend.

Par-delà son contenu, la controverse entre open source et free software révèle l’importance des discours de positionnement idéologique dans le milieu du libre. Le mouvement du logiciel libre est ainsi indissociable des discours produits par ses acteurs pour légitimer et promouvoir leur pratique de la programmation informatique. Ce trait est particulièrement marquant, s’agissant de la question de l’organisation des communautés de développeurs. Celles-ci sont souvent opposées aux structures pyramidales dominantes dans les sphères économiques et politiques (grandes entreprises, partis politiques, etc.). Elles sont décrites comme mettant en œuvre une organisation horizontale, reposant sur le partage de l’information et la coopération directe entre participants. Seuls les individus affectueusement nommés « dictateurs bienveillants » sont censés y tenir un rôle hiérarchique. Il s’agit d’une ou plusieurs personnes qui, en fonction du mérite qui leur est reconnu par la communauté, assurent pour chaque projet une fonction de direction, de coordination, et de sélection des contributions. Au sein du projet Linux, Linus Torvalds dirige ainsi la cellule chargée de choisir et d’assembler les modifications apportées au noyau du code source. À cette restriction près, l’idéal véhiculé par les partisans du logiciel libre est bien celui d’une communauté d’égaux, reposant sur le partage, la collaboration, et le jugement par les pairs.

Cette image est toutefois un peu trop parfaite pour ne pas fournir un reflet quelque peu déformé de la réalité. Il faut ainsi prendre garde à ce que le discours des défenseurs du logiciel libre peut avoir de militant, voire d’idéologique. Certaines études de terrain semblent ainsi démontrer que les structures hiérarchiques sont souvent plus fortes que ce que les acteurs eux-mêmes veulent bien admettre. Dans un travail réalisé en 2004, Thomas Basset montre ainsi, en étudiant le développement de la suite logiciels VideoLAN^[8], qu’il existe un décalage important entre le discours des participants au projet et la réalité des pratiques. Bien que les développeurs mettent en avant l’idéal d’un « libre échange du savoir entre personnes égales (…) hors de toute structure hiérarchique » (Basset, 2003, p. 28), l’observation du chercheur met en lumière l’existence d’une forte hiérarchie informelle. Au moment de l’étude, le projet VideoLAN repose ainsi sur une distribution du travail très inégalitaire, encore renforcée par des « manœuvres volontaires de rétention de l’information » (Basset, 2003, p. 52) en contradiction flagrante avec les discours tenus.

De façon générale, il faut avoir en tête que le mouvement du logiciel libre a non seulement produit des réalisations de tout premier ordre (Linux, Apache, etc.), mais aussi – et c’est là presque aussi important – un ensemble de discours mettant en avant certaines valeurs et certains modes de fonctionnement. Or, ces discours fonctionnent parfois comme une véritable idéologie, contribuant à voiler la réalité des pratiques. Par ailleurs, s’il est vrai que cette idéologie du libre n’est pas parfaitement homogène et cohérente (c’est ce qui apparaît notamment à travers la controverse entre free software et open source mentionnée plus haut), il s’en dégage néanmoins certaines constantes : méfiance envers la hiérarchie, valorisation du mérite individuel, promotion d’une éthique de la collaboration. On insistera ainsi sur le fait que la valorisation simultanée du mérite individuel et de la collaboration n’est contradictoire que superficiellement. Le mode d’organisation des communautés du libre est précisément censé permettre à chacun de concilier une grande autonomie dans son travail avec une inscription dans un projet collectif. En effet, une organisation horizontale apparaît par définition peu susceptible de soumettre les individus au groupe, en ce qu’elle refuse toute forme de hiérarchie et de contrôle centralisé. Dans le même temps, elle permet à un grand nombre de relations de coopération de se nouer, dans la mesure où tout le monde peut potentiellement être en contact avec tout le monde. Si l’on suit l’idéologie du libre, il faut donc dire que la communauté, pour autant qu’en soient bannies les rigidités hiérarchiques et qu’y soit favorisée la collaboration, se présente comme le terrain le plus propice à révéler le mérite individuel. Que les choses soient plus compliquées en pratique est une évidence qu’il faut garder en tête. Néanmoins, il n’est pas exagéré d’affirmer que le mouvement du logiciel libre véhicule in fine une certaine idée des structures les plus aptes à assurer le plein épanouissement de l’individu et de la collectivité, dans le domaine de la programmation informatique voire au-delà.

2. Le logiciel libre comme modèle social d’avant-garde

Je voudrais désormais pousser le raisonnement plus loin, et examiner la manière dont certains intellectuels n’étant pas directement impliqués dans le milieu du logiciel libre, se sont emparés de cette thématique pour fonder leurs analyses d’un certain nombre de transformations sociales en cours. Autrement dit, je voudrais considérer des discours qui vont au-delà de ce que j’ai nommé l’idéologie du logiciel libre, dans la mesure où ils se présentent comme porteurs d’une analyse de portée générale sur l’évolution de nos sociétés. Ces discours tendent ainsi à reprendre l’idéalisation du logiciel libre véhiculée par ses acteurs, tout en étendant la portée du modèle à d’autres activités sociales. Le logiciel libre devient de la sorte un socle sur lequel se trouve bâtie toute une construction intellectuelle. Je développerai trois exemples pour appuyer ce propos.

2.1. Pekka Himanen : la propagation de « l’éthique hacker »

Le philosophe finlandais Pekka Himanen a consacré à « l’éthique hacker » un ouvrage au retentissement important, paru en France en 2001 : L’Éthique hacker et l’esprit de l’ère de l’information^[9]. Il y soutient queles pratiques et les valeurs du monde du logiciel libre ont donné naissance à « une nouvelle éthique du travail qui s’oppose à l’éthique protestante du travail telle que l’a définie Max Weber » (Himanen, 2001, p. 10). Cette nouvelle éthique se caractériserait par une relation au travail fondée sur la passion et l’intérêt personnel, et non sur le devoir moral et l’intérêt financier. Pour les hackers, le travail ne serait ainsi ni posé comme fin en soi indépendamment de son contenu, ni considéré comme simple moyen d’assurer sa subsistance ou sa richesse. L’important serait au contraire la satisfaction personnelle éprouvée dans la réalisation d’une tâche, devant être vécue comme intrinsèquement intéressante et gratifiante : « Les hackers font de la programmation parce que les défis qu’elle génère ont un intérêt intrinsèque pour eux » écrit ainsi P. Himanen (Ibid., p. 23). Il cite également Linus Torvalds, qui affirme que pour lui « Linux a largement été un hobby (mais un sérieux, le meilleur de tous) » (Ibid., p. 34).

Ce nouveau rapport au travail, qui repose sur une logique de développement de soi (Selbstentfaltung^[10]), irait de pair avec un nouveau rapport au temps. Ainsi, pour les hackers, la distinction entre temps de travail et temps de loisir se trouverait brouillée, au profit d’un temps flexible où travail, hobbies, familles, collègues et amis se trouveraient sans cesse mélangés.

À la lumière de ces éléments, on peut mettre en doute la radicale nouveauté de cette « éthique hacker ». P. Himanen reconnaît du reste lui-même que les universitaires ou – d’une manière différente – les artistes, entretiennent depuis longtemps ce même rapport passionné à leur travail, et valorisent eux aussi une organisation relativement « libre » de leur temps. La véritable nouveauté résiderait en fait dans la manière dont ce rapport au travail serait en train de se répandre dans la société, à partir des milieux hacker.

(…) l’éthique hacker du travail se propage doucement vers d’autres secteurs, à l’image de l’éthique protestante qui, selon Weber, a fait son chemin en partant des entreprises créées par des Protestants pour finir par dominer l’esprit du capitalisme (Ibid., pp. 66-67).

Autrement dit, à la faveur du passage de la société industrielle à la « société en réseaux » (Castells, 1998)^[11], le rapport au travail des hackers deviendrait viable pour de larges pans de la main d’œuvre. Leur éthique se substituerait ainsi progressivement à l’éthique protestante traditionnelle (ou à sa déclinaison contemporaine, érigeant l’argent en valeur suprême). Les hackers seraient finalement une sorte de groupe social d’avant-garde, et le mouvement du logiciel libre la matrice dont émergerait une nouvelle société. « Le modèle hacker ouvert pourrait se transformer en un modèle social » écrit P. Himanen (2001,p. 86).

Cette thèse n’est pas sans poser certaines difficultés. En effet, la possibilité de généraliser la relation au travail des hackers à d’autres groupes sociaux, et à d’autres secteurs économiques, est loin d’être évidente. Pekka Himanen s’expose ainsi au reproche d’ethnocentrisme, dans la mesure où tous les types d’emplois ne semblent pas susceptibles d’engendrer un rapport passionné au travail. Ne se rend-il pas coupable de généraliser une attitude, qui est en fait un privilège réservé à une partie infime de la population ? N’oublie-t-il pas un peu vite la très grande spécificité des hackers en tant que catégorie socioprofessionnelle, lorsqu’il affirme que leur éthique a une valeur quasi « universelle » (Ibid.,p. 26) ?

La thèse d’Himanen d’une propagation de l’éthique hacker dans l’ensemble du corps social apparaît relativement difficile à maintenir telle quelle. On peut alors choisir de la tirer du côté de l’utopie, c’est-à-dire d’un état idéal du social dans lequel le travail ne serait plus aliénation mais autodéploiement. Mais tel n’est certainement pas le propos de l’auteur, qui adopte dans son ouvrage une posture plutôt « sociologique ». Peut-être faut-il alors se résoudre à tirer de son ouvrage – et à l’encontre de ce qu’il écrit lui-même – une thèse plus « faible ». La mise en pratique de l’éthique hacker ne serait finalement possible que dans des secteurs très spécifiques, pour les professionnels de l’information, les artistes, ou les chercheurs. La généralisation à l’ensemble de la société de l’attitude au travail propre au milieu du logiciel libre apparaît en effet assez peu vraisemblable.

2.2 Yann Moulier Boutang : le logiciel libre comme modèle productif d’un nouveau capitalisme

L’exemple du logiciel libre est également tout à fait central dans la démarche de Yann Moulier Boutang, économiste et directeur de la revue Multitudes. Celui-ci a entrepris depuis quelques années, en collaboration étroite avec d’autres chercheurs (Antonella Corsani, Carlo Vercellone, Bernard Paulré…), de renouveler les cadres d’analyse de la science économique pour saisir les mutations contemporaines du capitalisme. Ce projet a donné naissance à l’hypothèse du « capitalisme cognitif ». Selon Yann Moulier Boutang, nous serions ainsi en train de sortir du capitalisme industriel pour entrer dans un nouveau type d’économie, « fondé sur l’accumulation du capital immatériel, la diffusion du savoir et le rôle moteur de l’économie de la connaissance » (Moulier Boutang, 2007, p. 85). Le capitalisme ne se nourrirait plus « du muscle consommé dans les machines marchant à la dissipation de l’énergie "carbo-fossile" » (Ibid., p. 65), mais de la « force cognitive collective » (Ibid., p. 65), ou encore de « l’intelligence collective » (Ibid., pp. 61-67). La source de la richesse résiderait donc aujourd’hui dans le travail social de communication et d’invention, ou encore dans la manipulation et la création de connaissances.

À mesure que les formes du travail et les sources de la richesse se modifieraient, le mode de production propre au capitalisme industriel entrerait en crise. Certes bien loin de disparaître complètement, il serait néanmoins délaissé dans les secteurs « avancés » de l’économie. En effet, l’adaptabilité, la flexibilité et la créativité permises par l’organisation en réseau, se révèleraient plus propres à révéler l’intelligence collective, que la rigidité de la one best way propre au taylorisme.

La thèse de Yann Moulier Boutang est ainsi qu’un nouveau mode de production émerge, qu’il définit comme « le travail de coopération des cerveaux réunis en réseau au moyen d’ordinateurs » (Ibid., p. 95). Point n’est besoin de trop de perspicacité pour s’apercevoir que cette description correspond parfaitement au modèle de fonctionnement des communautés du logiciel libre. Et pour cause ! Selon Yann Moulier Boutang, ces communautés sont l’exemple paradigmatique de ce nouveau mode de production propre au capitalisme cognitif. Ainsi, « le phénomène social et économique du libre » fournirait

un véritable modèle productif. Et ceci, tant sur le plan des forces sociales nouvelles que l’on peut repérer, sur celui de la division sociale du travail, que sur celui de la rationalité des agents économiques qui se trouve ainsi inventée, promue, des formes d’identité non pas au travail mais à un travail qui a changé fortement de contenu (Ibid., p. 125).

Yann Moulier Boutang accorde ainsi au logiciel libre une valeur d’exemplarité : ce qu’ont réussi à mettre en place quelques milliers de passionnés à travers le monde dans le domaine de la production informatique, serait un avant-goût d’un bouleversement global de l’organisation du travail. Suivant la voie tracée par les hackers, les forces productives deviendraient progressivement comparables à « l’activité collective cérébrale mobilisée en réseaux numériques interconnectés » (Ibid., p. 93).

Dans le même temps, le capitalisme cognitif deviendrait de plus en plus assimilable à une économie open source. En effet, dès lors que la richesse résiderait désormais dans l’ensemble du travail social de communication et d’invention, l’entreprise n’en serait plus l’unique productrice. Elle se devrait au contraire de capter une richesse antérieure, c’est-à-dire de valoriser ce qui émerge spontanément de l’ensemble des échanges sociaux.

L’intelligence entrepreneuriale consiste désormais à convertir la richesse déjà là dans l’espace virtuel du numérique en valeur économique (Ibid., p. 167).

Les entreprises auraient ainsi un intérêt profond à laisser se développer sans entraves la coopération en réseau, car celle-ci leur offrirait in fine les meilleures occasions de profit, en leur permettant de tirer profit d’une grande quantité de travail gratuit.

L’activité humaine innovante de la coopération des cerveaux à l’ère numérique produit dans la science, dans l’art, dans les formes collectives du lien social des gisements nouveaux et impressionnants d’externalités positives pour les entreprises, c’est-à-dire de travail gratuit incorporable dans de nouveaux dispositifs de captation et de mise en forme(Ibid., p. 122).

Comme l’aura déjà remarqué le lecteur attentif, ce nouveau business model correspond en tout point aux stratégies mises en œuvre par certaines grandes multinationales du secteur informatique pour tirer parti du logiciel libre. Ainsi, quand IBM profite du travail gratuit des communautés Linux ou Apache, et réoriente ainsi son activité vers une nouvelle offre de services (cf. supra), l’entreprise opère précisément ce que Yann Moulier Boutang décrit comme une captation de l’intelligence collective.

Le logiciel libre constitue donc pour Yann Moulier Boutang le phénomène économique et social, permettant d’analyser le capitalisme cognitif dans ses multiples facettes. Les communautés de développeurs du libre auraient ainsi « inventé » le mode de production caractéristique de ce nouveau régime économique, tandis que les entreprises ayant investi dans l’open source auraient développé son business model. La démarche théorique de Yann Moulier Boutang apparaît donc finalement très proche de celle de Pekka Himanen, dans la mesure où elle procède par généralisation à partir de l’exemple des communautés du logiciel libre, en tendant à faire de celles-ci des sortes d’avant-gardes. Elle s’expose de ce fait au même type de critique. Emporté par son admiration pour « la révolution californienne du capitalisme » (Ibid., p. 25), Moulier Boutang semble sous-estimer la spécificité du logiciel libre, et la difficulté à exporter ce modèle vers d’autres secteurs économiques. Fabien Granjon a ainsi noté que « les nouveaux aspects de production » sur lesquels les tenants de la thèse du « capitalisme cognitif » fondent leur théorie, « ne constituent que des sphères relativement restreintes de l’activité économique : ainsi en est-il du domaine du logiciel libre » (Granjon, 2008, p. 63). De manière analogue, Michel Husson a pointé la tendance de ceux qu’ils nomment les « cognitivistes » à « extrapoler des tendances partielles sans comprendre qu’elles ne peuvent se généraliser » (Husson, 2007, p. 139).

Il est intéressant de noter que Yann Moulier Boutang est conscient de s’exposer à de telles objections. Il tente d’y répondre, en proposant une analogie entre sa démarche et celle de Marx à l’aube de l’ère industrielle :

On s’intéresse en général à des observations empiriques sélectionnées dans un fatras rhapsodique d’informations multiples parce qu’on cherche les variables pertinentes qui commandent la tonalité d’ensemble ou permettent de prévoir des trajectoires d’évolution. Le grand trait de génie de Marx et Engels n’est pas d’avoir étudié la population laborieuse la plus nombreuse en Angleterre, (c’étaient les domestiques qui se comptaient par millions) mais les quelques 250 000 ouvriers des usines de Manchester (Moulier Boutang, 2007, p. 99).

L’argument est malicieux, et non dénué de pertinence. Toutefois, il ne suffit pas à effacer l’impression que la généralisation opérée par Moulier Boutang à partir du logiciel libre repose sur un pari. Celui d’affirmer que nos économies post-industrielles vont effectivement suivre la voie tracée par les expériences pionnières du logiciel libre. Or, s’il y a là un avenir possible, ce n’est certainement pas le seul ! La période actuelle paraît en effet trop incertaine, pour qu’on puisse écarter, par exemple, l’hypothèse du développement d’un « capitalisme gestionnaire d’effets de réseaux et de verrouillage » (Aigrain, 2007, p. 252), capitalisme qui serait bien entendu totalement contraire au modèle promu par les tenants du libre. Yann Moulier Boutang ne semble certes pas considérer ce scénario comme crédible, mais c’est là une position qui relève davantage de l’acte de foi que de la démonstration irréfutable. Ou, pour le dire de façon plus clémente : Yann Moulier Boutang assume les risques et les faiblesses de tout discours sur le social ne se contentant pas d’être descriptif, mais ayant une double visée de synthèse et de prospective. Sa démarche visant à faire du logiciel libre le modèle d’un nouveau capitalisme en gestation est donc nécessairement très perméable à la critique.

2.3. Michael Hardt et Antonio Negri : la démocratie comme « société open source ».

Ayant bénéficié d’un important succès commercial, les ouvrages Empire et Multitudes de Michael Hardt et Antonio Negri se présentent comme une tentative de rénover la philosophie politique critique, à l’heure de la mondialisation et des nouvelles technologies de l’information et de la communication. Ils sont notamment consacrés à la construction d’une théorie originale de la démocratie, inspirée en partie par le mouvement du logiciel libre. Avant d’aborder celle-ci en tant que telle, il faut préciser que les auteurs ancrent leur réflexion dans une analyse des transformations économiques contemporaines ; analyse tout à fait semblable à celle de Yann Moulier Boutang. Ils insistent ainsi sur la progression de la part du travail immatériel, et sur l’importance nouvelle de la coopération en réseau sur le modèle du logiciel libre.

L’originalité de leur propos se situe dans la thèse selon laquelle ces transformations économiques rejailliraient sur toutes les dimensions de la vie en société. C’est ce qu’ils appellent, en reprenant un terme forgé par Michel Foucault, la dimension biopolitique de la production.

Dans le cadre de ce travail immatériel, la production déborde hors des frontières traditionnelles de l’économie et se déverse directement dans le domaine culturel, social et politique. Elle crée non seulement des biens matériels, mais des relations sociales concrètes et des formes de vie. Nous appelons « biopolitique » cette forme de production, afin de souligner le caractère générique de ses produits et le fait qu’elle a directement prise sur l’ensemble de la vie sociale (Hardt et Negri, 2004, p. 121).

Ce caractère biopolitique de la production est, selon les auteurs, à l’origine d’une isomorphie croissante entre les structures économiques et les autres structures sociales, y compris politiques. Autrement dit, le développement de la forme réseau dans le cadre de la production immatérielle aurait pour corrélat la progression de cette même forme dans toutes les dimensions de la vie sociale. Ainsi Michael Hardt et Antonio Negri écrivent-ils notamment que

les institutions de la démocratie doivent aujourd’hui coïncider avec les réseaux communicatifs et collaboratifs qui ne cessent de produire et reproduire la vie sociale (Ibid., p. 400).

C’est dans ce cadre conceptuel qu’il faut comprendre le lien établi par les auteurs entre le mouvement du logiciel libre et la redéfinition de la démocratie qu’ils appellent de leurs voeux. On peut ainsi – moyennant une simplification acceptable – donner à leur raisonnement la forme d’un syllogisme : Structures économiques et structures politiques tendent à devenir semblables. Or, le logiciel libre est emblématique des nouvelles structures économiques. Donc, le logiciel libre devient emblématique des nouvelles structures politiques ! Michael Hardt et Antonio Negri écrivent ainsi :

On peut donc voir la démocratie de la multitude comme une société open source, c’est-à-dire une société dont le code source est révélé, permettant à tous de collaborer à la résolution de ses problèmes et de créer des programmes sociaux plus performants (Ibid., p. 385).

À travers l’expression de « société open source », Michael Hardt et Antonio Negri poussent la généralisation à partir du mouvement du logiciel libre à l’extrême. Ils accordent à celui-ci une place centrale dans la construction d’un nouveau modèle de société, susceptible de fournir une alternative crédible au libéralisme débridé et aux « vieilles » démocraties parlementaires. Hardt et Negri font ainsi du projet du logiciel libre l’horizon d’une certaine gauche radicale : la « société open source » et la « démocratie de la multitude » sont fondues en un seul et même objectif politique.

Évidemment, c’est là prêter énormément au mouvement du logiciel libre (ici confondu avec l’open source), et faire peu de cas des ambiguïtés politiques qu’il recèle. On remarquera ainsi que les grands principes du libre (libre partage de l’information, organisation horizontale, autonomie laissée à chacun) dessinent en fait un projet politique relativement modeste. Comme le remarque Patrice Riemens, nous sommes « très en deçà des exigences de justice, d’équité, d’égalité, d’émancipation » (Riemens, 2002, p. 185), qui animent la plupart des grands projets politiques de gauche. De surcroît, il paraît délicat – plus en tous les cas que Negri et Hardt ne le laissent supposer – de faire du libre un projet politique global. En effet, l’engagement social d’une majorité de hackers semble se limiter à un attachement à la disponibilité du code au sein du monde informatique. Il a d’ailleurs été remarqué que

l’étendue du spectre des opinions politiques entretenues par les hackers individuels (…) est surprenante, et totalement inimaginable dans quelque autre « mouvement social » (Ibid., p. 185).

Il semble donc que Michael Hardt et Antonio Negri accordent au logiciel libre une portée sociale et politique légèrement excessive. Ils participent en cela d’un mouvement plus général, qui a vu plusieurs intellectuels de gauche s’enthousiasmer pour le libre au cours des années 2000^[12]. Il est toutefois possible de faire une lecture légèrement différente de la référence à l’open source chez Hardt et Negri. On émettra ainsi l’hypothèse que leur intérêt se situe à un niveau plus abstrait. Autrement dit, la portée politique effective du mouvement du logiciel libre les intéresse peut-être moins, que le fait qu’il fournisse un modèle inédit pour penser une nouvelle forme et un nouveau contenude la démocratie^[13]. C’est donc à ce niveau, disons plus « théorique », que je voudrais situer ma dernière critique.

Pour l’énoncer succinctement, celle-ci consiste à dire que la mise en avant du modèle du libre pour (re)penser la question démocratique est porteuse d’une négation de la spécificité de la politique. Ainsi, si l’on prend au sérieux la référence à l’open source, la « démocratie de la multitude » aurait pour objet la production collaborative d’une forme d’expertise collective. Elle aurait à mettre en œuvre des processus d’agrégation de savoirs locaux. Elle se présenterait comme une sorte de gigantesque entreprise de débogage, ou comme un problem solving à grande échelle.

De telles idées ont certes des aspects séduisants, d’une part parce qu’elles semblent promettre une gestion politique plus efficace^[14], d’autre part parce qu’elles renouent avec l’idéal d’une démocratie qui reposerait véritablement sur la participation effective de tous et bannirait le secret. Toutefois, l’analogie entre l’open source et la démocratie pose des difficultés majeures. Ainsi, dans le cas du logiciel libre, la finalité de la collaboration ne prête pas à discussion, puisqu’il s’agit tout simplement de produire le meilleur logiciel possible. Corrélativement, la réussite (ou l’échec) des diverses modifications souffre assez peu de contestation. Elle s’évalue aisément, puisqu’il suffit d’exécuter le code pour observer si la nouvelle mouture est plus rapide et plus complète que l’ancienne, si elle contient des bugs, etc. En matière de démocratie, les choses sont nettement plus compliquées. Ainsi, il y a rarement unanimité sur l’identification et la hiérarchisation des « problèmes » auxquels la collectivité se trouve confrontée. On peut même dire que la discussion sur les fins de l’action politique est inéliminable : celles-ci sont toujours objets de litige. Le fonctionnement démocratique ne peut par conséquent être réduit à la recherche collective des moyens les plus efficaces de résoudre des problèmes, qui seraient eux soustraits à toute forme de mise en question.

Tout régime politique ouvert ne cesse ainsi d’être confronté à des questions, que l’acquisition d’un savoir, quel qu’il soit, ne peut suffire à trancher. La démocratie ne saurait la plupart du temps se contenter d’une somme de connaissances objectives pour déterminer sa pratique. Elle vit au contraire de la confrontation d’une diversité d’engagements argumentés, mettant en jeu une pluralité de valeurs, d’intérêts ou de « choix de société ». Elle est indissociable d’un régime de rationalité particulier : l’échange d’opinions conclu par le vote à la majorité, et non pas la production collaborative de connaissances dont dériveraient mécaniquement les décisions.

La référence à une hypothétique « démocratie open source » importe donc indûment dans le champ politique la rationalité technique et scientifique, au détriment de la rationalité proprement politique. Autrement dit, elle néglige le rapport de la politique à l’opinion, considérée en tant que catégorie épistémologique. Ainsi, dans le recouvrement de la doxa par l’épistèmê,et dans le remplacement du débat contradictoire par la collaboration en réseau, ce serait bien l’essence des enjeux et des procédures démocratiques qui serait perdue.

Conclusion

Au terme de ce parcours, il apparaît que les pratiques mises en place par les communautés du logiciel libre sont sujettes à une double distorsion. Elles se trouvent tout d’abord fréquemment idéalisées par les acteurs du libre eux-mêmes, dont le discours militant a souvent pour effet de recouvrir les difficultés posées par la mise en application du modèle qu’ils défendent. Une deuxième distorsion est imputable à certains intellectuels qui, en conférant aux expériences du logiciel libre une portée social générale, minimisent la spécificité d’un mouvement dont les enjeux sont – avant tout, bien que non exclusivement – internes au secteur informatique^[15].

Ces théories « inspirées » du logiciel libre présentent des similitudes frappantes. Par-delà leurs champs d’application privilégiés, elles s’accordent pour voir la spécificité de notre période dans le développement de nouvelles formes de collaboration « intelligentes » médiatisées par Internet. À les suivre, les changements que connaît notre époque – qu’il s’agisse des mutations des formes de socialité, des bouleversements économiques, ou encore des nouvelles formes de l’engagement politique – seraient directement imputables à la nouvelle configuration sociotechnique, permettant de « mettre en réseau les cerveaux ». Ces changements seraient révélateurs d’une période de transition, entre une société industrielle mourante, et une société de « l’intelligence collective » propulsée par les nouvelles formes d’échange et de production de connaissances.

Si ces théories saisissent indéniablement un trait marquant de notre époque, elles semblent néanmoins pêcher par un certain réductionnisme. Elles présentent en effet une tendance à ramener des phénomènes hétérogènes à une grille d’explication unique, faisant fi des spécificités des différents domaines de la vie sociale. Elles tendent parfois aussi à occulter des traits particulièrement frappants de notre époque : montée inouïe des inégalités, déséquilibres écologiques, etc. On pourra ainsi regretter que le discours sur le partage de l’information ne s’accompagne que trop rarement d’un discours sur le partage des richesses, ou des ressources naturelles.

Bibliographie

• AIGRAIN P., 2007, « Capitalisme cognitif et politiques qualitatives après la révolution informationnelle » in MOULIER BOUTANG Y., 2007, Le capitalisme cognitif, Paris, Éditions Amsterdam.
• BASSET T., 2003, Monographie d’un logiciel libre : VideoLAN, Mémoire de DEA, Institut d’Études Politiques de Paris, en ligne : http://www.framasoft.net/IMG/videolan.pdf (consulté le 19 novembre 2008).
• CASTELLS M., 1998, L’ère de l’information, vol. 1 : La société en réseaux, Paris, Fayard.
• GORZ A., 2003, L’immatériel, Paris, Galilée.
• GRANJON F., 2008, « Les nouveaux résistants à l’ère du numérique. Entre utopie sociale et déterminisme technique », in PROULX S.et alii, 2008, L’action communautaire québecoise à l’ère du numérique, Montréal, Presses de l’Université du Québec, pp. 59-76.
• HARDT M. et NEGRI A., 2004, Multitudes, Paris, La Découverte.
• HIMANEN P., 2001, L’éthique hacker et l’esprit de l’ère de l’information, Paris, Exils.
• HUSSON M., 2007, « Notes critiques sur le capitalisme cognitif », ContreTemps, n°18, pp. 138-141, en ligne : http://hussonet.free.fr/cognict.pdf (consulté le 10 novembre 2008).
• MERTEN S., 2002, « Logiciel libre et éthique du développement de soi : entretien avec Joanne Richardson », Multitudes, n°8, pp. 188-199, en ligne : http://multitudes.samizdat.net/Logiciel-libre-et-ethique-du (consulté le 19 novembre 2008).
• MOGLEN E., 2001, « L’anarchisme triomphant : le logiciel libre et la mort du copyright », Multitudes, n° 5, pp. 146-183, en ligne : http://multitudes.samizdat.net/L-anarchisme-triomphant (consulté le 19 novembre 2008).
• MOULIER BOUTANG Y., 2007, Le capitalisme cognitif, Paris, Éditions Amsterdam.
• RIEMENS P., 2002, « Quelques réflexions sur le concept de “culture hacker” », Multitudes, n° 8, pp. 181-187, en ligne : http://multitudes.samizdat.net/Quelques-reflexions-sur-le-concept (consulté le 19 novembre 2008).
• TAPSCOTT D. et WILLIAMS A. D., 2007, Wikinomics, Paris, Pearson Education France.

En programmation, les commentaires sont des portions du code source ignorées par le compilateur ou l’interpréteur, car ils ne sont pas nécessaires à l’exécution du programme, nous dit Wikipédia.

De fait ils sont le plus souvent utilisés pour expliquer le code, et contrairement à ce dernier qui nécessite un langage de programmation, les commentaires se font dans une langue humaine, généralement en anglais.

C’est une opération indispensable et une partie intégrante du travail du développeur, afin qu’un autre puisse comprendre et éventuellement modifier le code initial (quitte à ce que cet autre soit l’auteur même des commentaires, reprenant son code quelques temps plus tard).

De par le fait que sa nature en autorise l’accès et le ré-appropriation, on comprendra que ces commentaires soient encore plus importants dans le cas d’un logiciel libre.

Il se trouve cependant que, par paresse, manque de temps ou mépris pour ce qui ne serait pas de la programmation stricto sensu, ils sont parfois quelque peu négligés par les développeurs.

Or l’hypothèse défendue ici est qu’il y aurait une corrélation directe en la qualité des commentaires et la qualité du code.

Affirmer ainsi péremptoirement que l’un n’irait pas sans l’autre est somme toute assez osé. Mais cela a le mérite d’évoquer cette « face cachée » de la programmation qui fait aussi partie des compétences attendues d’un bon développeur^[1].

Si les commentaires sont moches, le code est moche

If the comments are ugly, the code is ugly

Esther Schindler – 15 novembre 2009 – IT World
(Traduction Framalang : Goofy)

C’est un peu dur, je sais, mais finalement je crois que c’est vrai.

Le développeur de Plone Martin Aspeli m’a signalé un billet assez judicieux dans lequel un programmeur en C faisait part de trois règles apprises à ses dépens. Celle qui a particulièrement attiré l’attention de Martin (et la mienne) est la suivante :

Les bons programmes ne comportent aucune faute d’orthographe ni de faute de grammaire. Je pense que cela vient probablement d’une attention soutenue aux moindres détails ; dans les programmes excellents tout est correct à tous les niveaux, jusqu’aux points qui terminent les phrases de commentaires.

« Allez, tu charries ou quoi ? ». Vous pourriez croire que pinailler à ce point est indigne de vous, « Et bien je m’en vais commencer à vous signaler les erreurs dans votre code lui-même ». J’ai été bien embarrassé les deux ou trois fois où ça m’est arrivé.

La programmation, que vous la pratiquiez en enthousiaste de l’open source ou parce que vous êtes au service du patron, est un exercice qui exige de l’attention aux détails. Quiconque écrit un logiciel doit être pointilleux, sinon le code ne fonctionnera pas. Je suis sûre que je n’ai pas besoin de vous citer la série des célèbres bogues de programmation dont s’est rendu coupable un programmeur qui a utilisé une virgule et non un point, ou des plantages aléatoires provoqués par deux lignes de code placées au mauvais endroit ?

Il est possible que mon jugement soit faussé par mes fonctions d’écrivain et d’éditrice, mais je crois fermement que si vous ne pouvez pas trouver le temps d’apprendre les règles de syntaxe de la langue (y compris la différence entre « c’est » et « ces », ou encore « m’a » et « ma »), je ne crois pas que vous puissiez être beaucoup plus consciencieux pour écrire du code en respectant les bonnes pratiques. Si vos commentaires sont négligés, je m’attends à trouver du code négligé.

Mon postulat vient de ce que m’a enseigné un éditeur très brillant, il y a dix ans (Laton McCartney, si tu lis ça : merci !). Si tu peux écrire le chapeau, disait-il, tu peux écrire l’article très facilement. Si tu ne peux pas écrire le chapeau, c’est que tu ne comprends pas encore ce que tu veux dire, et tu ne devrais pas commencer à écrire (le « chapeau » est le petit paragraphe d’accroche qui suit le grand titre, qui dit en un mot de quoi il est question et invite gentiment le lecteur à en savoir plus). De filandreuses « explications » du code dans les commentaires de l’application (c’est-à dire, ceux qui se lisent comme de bonnes excuses) indiquent que le développeur ne savait probablement pas ce qu’il faisait au juste. Ce qui signifie que son code est éligible au titre de nid à bugs.

Se plaindre de la mauvaise documentation interne est un vieux refrain, mais il existe une raison pour laquelle il est important de la faire bien. Vos commentaires sont la seule façon dont vous disposez pour communiquer avec la prochaine personne qui regardera votre logiciel (il se peut même que ce soit vous) en profondeur, et pas juste une ligne ou deux. À quoi pensiez-vous en écrivant ce code ? D’accord, du code « auto-documenté » c’est l’idéal, mais c’est un peu arrogant de prétendre que vous l’avez atteint, et ça l’est tout autant de ma part si je prétends que mes phrases n’ont pas besoin d’être révisées (elles en ont besoin, je suis bien contente d’avoir un correcteur).

Un autre problème habituel dans la médiocrité des commentaires apparaît lorsque les développeurs mettent à jour le code sans mettre à jour les commentaires ; comme l’a expliqué un consultant, les commentaires ne sont pas testés. Mais est-ce qu’il ne s’agit pas là encore d’un manque d’attention aux détails ? À chaque fois que vous n’êtes pas totalement attentif, vous êtes prédisposé à laisser tomber un petit bout de logique.

Vous voulez quelques exemples ?

En voici un tiré d’une explication à propos d’un choix de conception. (« oui, je devine que c’était probablement intentionnel », a écrit le programmeur qui m’a montré cet exemple. « mais c’est bien là le problème : il faut que je devine ».)

 «... des questions prévues pour injustifier un débat...» 

Voici maintenant une authentique ligne de code avec un commentaire. Notez que le commentaire met l’accent sur la faute d’orthographe. Sans compter que le commentaire vous indique que le programmeur n’avait pas la moindre idée de ce qu’il faisait au départ. Particulièrement parce qu’il n’aurait pas dû écrire « finished » (NdT : fini) dans ce bout de code, mais qu’il aurait dû essayer « complete » (NdT : terminé).

 if item.getState() == 'finsihed': #est-ce correct? 

Bon, je vous accorde quelques exceptions. Si l’anglais n’est pas votre langue maternelle, il est possible que les commentaires que vous laissez dans votre code montrent que vous n’êtes pas à l’aise pour écrire en anglais. Cependant, en ce qui me concerne je n’ai pas trouvé que c’était le cas. Comme beaucoup d’Américains s’en sont rendu compte, les capacités en anglais des « étrangers » sont généralement bien meilleures que les nôtres. Parmi les développeurs que je connais, ceux qui ont des lacunes dans leur maîtrise de la langue anglaise en sont conscients et font tout leur possible pour qu’un anglophone passe en revue leur documentation.

Je ne me lancerai pas dans des considérations sur l’indentation du code et des commentaires, c’est une guerre de religions. Mais j’ai rencontré des développeurs qui réagissaient aussi violemment devant un formatage de code « moche » que moi devant une grammaire moche.

Les environnements de développement modernes procurent la discutable possibilité aux développeurs d’être négligents sans effets pervers ; une interface glisser-déposer vous permet de créer une application vite fait bien fait (ou plutôt mal fait, j’en ai peur) avec bien moins d’horribles dommages collatéraux qu’à l’époque où les logiciels étaient généralement écrits en assembleur. Pourtant, d’une certaine façon, j’ai du mal à considérer le « je peux être négligent » comme un avantage réel.

La règle du commentaire « moche » vaut autant pour les applications propriétaires que pour les logiciels open source. Mais les développeurs de FOSS (NdT : Free and Open Source Software, les logiciels libres et open source) doivent faire beaucoup plus attention encore pour deux raisons. La première, c’est qu’au bureau, vous avez de grandes chances de croiser le développeur du code mal fichu et de pouvoir lui poser des questions (ou de lui en coller une, si c’était vraiment horrible). De plus, dans la communauté open source, davantage de gens regardent dans le code et ont besoin de le comprendre.

Toutefois, lorsque j’ai suggéré à des développeurs que « si les commentaires sont moches, le code est moche », beaucoup n’étaient pas d’accord. Et vous non plus peut-être. J’aimerais savoir pourquoi, et je vous invite donc à laisser un… commentaire.

La semaine dernière Microsoft a dû retirer de ses serveurs un logiciel qui permet d’installer Windows 7 à partir d’une image ISO, après qu’un bloggeur a découvert que le logiciel était une modification dissimulée d’un logiciel libre sous licence GPL dont Microsoft hébergeait lui-même les sources.

On attendait une réaction publique et officielle, la voici sous la plume de Peter Galli, rien moins que le « Open Source Community Manager for Microsoft’s Platform Strategy Group »^[1].

Mise à jour de l’outil USB/DVD de Windows 7

Update on the Windows 7 USB/DVD Tool

Peter Galli – 13 novembre 2009 – Port 25
(Traduction Framalang : Gilles)

Comme vous avez pu le lire, et tel que cela a été indiqué ici, nous avons mené une enquête concernant l’outil de d’installation de Windows 7 depuis une clé USB, qui pouvait contenir du code sous licence GPL V2. le WUDT (NDT : Windows 7 USB/DVD Download Tool) est un outil gratuit, offert par le Microsoft Store, qui permettait à nos clients de créer une clé USB amorçable ou un DVD de sauvegarde à partir de l’édition électronique de Windows 7, disponible sous forme d’image ISO.

Après avoir analysé le code en question, nous sommes désormais en mesure de confirmer que tel était bien le cas, bien que cela n’ait pas été fait de manière délibérée. Bien que nous ayons confié cet outil à un développeur externe, nous partageons la responsabilité de cette situation; ce code est passé au travers des mailles de notre processus de revue de code. Nous avons également procédé à une revue d’autres portions de code disponibles dans le Microsoft Store, et il s’agit du seul incident que nous avons pu y découvrir.

Lorsqu’il est porté à notre attention qu’un composant de Microsoft contient du code développé par un tiers, notre objectif est de respecter les termes contractuels selon lesquels ce code est partagé. En conséquence, nous publierons le code source, ainsi que les fichiers binaires, de cet outil dès la semaine prochaine, sous les termes de la licence General Public Licence V2 (GPL V2), et prenons également des mesures pour améliorer nos futures revues de code, grâce à cette expérience

Nous nous excusons auprès de nos clients pour tout désagrément que cela a pu leur causer.

Voici une traduction intéressante à plus d’un titre.

D’abord parce qu’elle donne la parole à un développeur de logiciel libre (dont nous n’oublions pas ce que nous leur devons, c’est-à-dire tout). En l’occurrence il s’agit de Zed Shaw, bien connu dans la communauté Python et RoR (Ruby on Rails).

Ensuite parce qu’elle évoque la classique opposition à l’intérieur même des licences libres entre celles de type GPL et celle de type BSD. C’est toute la question du copyleft et de la viralité de la licence. Le copyleft est une apparente restriction, puisqu’il impose de diffuser le code modifié sous la même licence. Mais peut-être que cette contrainte est paradoxalement une garantie supplémentaire de liberté pour l’utilisateur ?

Enfin parce qu’elle aborde de nombreuses problématiques liées à l’open source et au monde de l’entreprise. Le fait de cacher à ses clients que l’on a utilisé du logiciel libre dans les solutions que l’on propose est une attitude malheureusement très fréquente (permettant de faire croire à moindre frais que l’on est hyper-compétent et que l’on a travaillé dur sur le projet). Il y a aussi toute la logique des startups, dont on attend un retour sur investissement presque immédiat, et qui du coup font de la rétention de code pourtant libre au départ.

Et puis il y a la question morale de la reconnaissance et celle très concrète du gagne-pain du développeur, frustré d’être ainsi ignoré et constatant non sans une certaine irritation que d’autres en profitent à sa place.

Voilà donc, entres autres arguments, pourquoi l’article ci-dessous mérite attention. Fatigué qu’une énième personne vienne lui demander pourquoi son code n’est pas sous licence BSD, Zed Shaw a décidé de réagir avec ce plaidoyer pugnace pour la licence GPL.

« Je veux que les gens apprécient le travail que j’ai fait et la valeur de ce que j’ai réalisé. Pas qu’ils passent en criant « pigeon » au volant de leurs voitures de luxe. »

Remarque : L’auteur concentre dans son titre les trois licences de la famille : la GNU/GPL, la LGPL et l’AGPL^[1].

Pourquoi je (A/L)GPLise

Why I (A/L)GPL

Copyright Zed A. Shaw – 13 juillet 2009 – Blog personnel
Avec l’aimable autorisation de l’auteur
(Traduction Framalang : Poupoul2 et Cheval boiteux – Remerciements à Léviathan)

Dans le monde de Python, la GPL est fréquemment critiquée, la plupart préférant utiliser une licence plus permissive telle que BSD, MIT ou Python. Il est donc compréhensible que des gens soient en colère parce que j’ai placé Lamson (NdT : Serveur SMTP développé en Python) sous licence GPL. Nombreux sont ceux qui détestent cette licence, pensant qu’elle contrevient à l’esprit de Python.

J’aimerais cependant expliquer pourquoi moi j’utilise la GPL, après des décennies d’écriture de logiciels open source et quelques projets reconnus. Ce sont mes raisons de l’utiliser, elles ne s’appliquent qu’à moi et à ce que je souhaite faire de mon logiciel dorénavant. Vous êtes libres de vos opinions et choix, et j’espère que vous respecterez les miens.

C’est le droit de l’auteur

Je crois que ce qu’un auteur souhaite faire avec son travail est son droit le plus strict. Il l’a écrit, alors que tout le monde lui expliquait que ça ne fonctionnerait pas. Il s’est enchaîné à ce travail plutôt que de sortir avec des amis. Il en a corrigé les bogues, écrit sa documentation de façon à ce que tout le monde puisse l’utiliser. Il a peut-être même passé du temps à en assurer la promotion et à aider les gens. Tout cela gratuitement, et pour des raisons qui lui appartiennent.

Lorsque vous dénigrez un projet ou une personne pour son choix de licence, vous êtes un gigantesque abruti. L’auteur a travaillé sur ce projet, pas vous. Au minimum, vous insultez les croyances de cette personne dans le logiciel libre et open source, mais aussi son sentiment que le logiciel libre et open source fait progresser notre culture.

Au pire, vous êtes un gros et ingrat malotru, parce que quelqu’un vous donne un logiciel, alors que vous insultez son travail non pas sur des critères techniques, mais sur une licence que vous désapprouvez.

Je me fiche totalement de la licence que les autres utilisent pour leurs logiciels, c’est leur logiciel et râler à cause de la licence qu’ils ont choisi est injurieux. Ils l’ont écrit, y ont sué sang et eau, et vous devriez être reconnaissant d’avoir le privilège de simplement y avoir accès.

Voici la première raison pour laquelle j’utilise la GPL :

Parce que c’est mon choix, et si vous n’êtes pas d’accord avec ça, n’utilisez pas mon logiciel. C’est aussi simple que ça.

Je ne veux plus être ignoré

J’ai écrit Mongrel (NdT : Serveur et librairie HTTP pour Ruby on Rails) et puis je l’ai donné, avec l’espoir que ça en aiderait d’autres et que le donner me rapporterait d’une manière ou d’une autre. Peut-être un boulot, ou un peu de respect, ou encore ma propre entreprise créant d’autres logiciels tels que celui-ci.

Mongrel a eu un grand succès, et de très nombreuses entreprises gagnent beaucoup d’argent avec. Non seulement permet-il à Rails de fonctionner, mais également à quasiment tous les frameworks Web Ruby, tel que les serveurs web Ruby, et a même été porté dans d’autres langages. Mongrel est et a été un super projet et j’en suis réellement fier.

Laissez moi vous expliquer à quel point Mongrel est avancé. Vous rappelez vous de la nouvelle attaque récemment publiée sur Apache appelée Slowloris (NdT : attaques par Déni de Service via des requêtes HTTP partielles) ? J’avais en fait prévu cette attaque, et écrit Mongrel de manière à ce qu’il y soit résistant (autant que Ruby me l’ait permis). Je l’avais appelé la « trickle attack » (NdT : attaque par écoulement), et j’en avais même fait la démonstration. C’était en 2004. Il y a cinq ans. Je l’avais même ajouté comme attaque à RFuzz en 2005.

Malheureusement, le succès de Mongrel ne m’est pas revenu. Bien que tout le monde utilise mon logiciel, la grande majorité des entreprises utilisatrices étaient des startups, et la dernière chose que les startups admettent c’est qu’elles ne possèdent pas leur propriété intellectuelle. Elles souhaitent que tout le monde, et particulièrement les sociétés de capital risque et les investisseurs, croit qu’elles sont des génies qui ont « innové » dans tout ce qu’elles font fonctionner.

Lorsque je regardais autour de moi, les entreprises n’avaient aucun problème à admettre qu’elles utilisaient Ruby on Rails, mais elles n’en disaient pas plus, ce qui signifiait que lorsque j’essayais de trouver du travail, il m’était impossible d’expliquer l’ampleur de l’impact de Mongrel. Pour elles, il ne s’agissait que d’un simple serveur Web que leur administrateur système devait utiliser, Ruby on Rails était le véritable pourvoyeur d’argent.

Voici la seconde raison pour laquelle j’utilise la GPL :

À cause de l’expérience Mongrel, j’ai presque besoin que les entreprises soient obligées d’admettre qu’elles utilisent mon logiciel. Je préfèrerais à la limite que personne n’utilise mon logiciel, plutôt que de me trouver dans une situation où tout le monde l’utilise et personne ne l’admet.

Pire, tout le monde l’utilise, et en même temps me dit que je ne sais pas développer.

Le capital risque a changé l’industrie

L’industrie du logiciel a changé depuis l’an 2000. Je mettrais en fait le curseur à l’entrée en bourse de Google, mais je ne peux pas dire exactement à quel moment. Ce que je peux dire, c’est que les méthodes actuelles de progression des entreprises technologiques induisent l’exploitation du code source plutôt que la contribution.

Je ne peux pas réellement en vouloir à ces startups, elles sont conçues ainsi. Une entreprise adossée à un capital-risqueur aura presque toujours un objectif de gain à court terme, dans l’espoir d’apporter plus tard un joli retour sur investissement. Pour un capital-risqueur, un retour sur 20 ans n’est pas acceptable, particulièrement si vous prévoyez de faire cela sans offre et des stocks options disponibles pour tout le monde.

Pour une entreprise financée par un capital-risqueur, il ne s’agit toujours que d’augmenter des revenus pour donner l’illusion de la croissance, afin que les actionnaires investissent et mènent le prix de l’action aussi haut que possible. Il n’est pas dans leur intérêt de ne pas faire d’offre. Ils veulent de l’argent maintenant, autant que possible, et ne sont pas intéressés par l’investissement technologique ou humain.

Ce qu’elles veulent, ce sont des tonnes de technologie gratuite qu’elles peuvent cacher aux investisseurs. Elles sont ravis que cette technologie soit maintenue par des gens qui ne l’ont pas écrite, pour que les employés ne puissent pas réclamer leur dû plus tard.

Cette gestion à courte vue, combinée au financement limité de départ, signifie que ces entreprises exploitent l’open source. Elles l’utiliseront, gagneront leur argent, et partiront lorsque ceci sera fait. Ce qui, en fait, est parfaitement logique, parce que ainsi vont les choses, et honnêtement, si vous êtes une entreprise qui cherche à gagner de l’argent de cette manière, c’est ce que je vous suggèrerais de faire.

Pourtant, le contrat tacite entre les entreprises et les développeurs open source est désormais révolu. Je n’ai aucune raison de leur offrir un usage sans restriction de mon logiciel, puisqu’ils ne sont intéressés que par la transformation de mon logiciel en offre alléchante de mise sur le marché à court terme, à deux ou cinq ans.

Voici la troisième raison pour laquelle j’utilise la GPL :

Les entreprises du secteur technologique sont désormais conçues pour être créées et détruites rapidement au bénéfice de gros capital-risqueur, tout en maintenant des coûts très bas. Cela signifie qu’elles n’ont aucune prime économique à donner, aussi n’ai-je aucune prime sociale à leur « donner » mon logiciel.

Les développeurs sont des plagiaires

Ne nous voilons pas la face, tout le monde a besoin de manger et de payer son loyer. Pour beaucoup de gens, leurs besoins en argent sont modestes, et si vous travaillez sur quelque chose, vous espérez en retirer quelque chose qui vous aidera à satisfaire ces besoins. Il se peut que ce ne soit pas de l’argent. Peut-être est ce que ce sera du respect, ou des honneurs, mais vous espérez réellement quelque chose de votre travail.

Nous sommes d’accord. Aussi je trouve étrange un message twitter tel que celui-ci :

ericholscher @zedshaw Ce serait chouette si l’interface/code était sous licence BSD. Très utile au travail. L’interface REST marche aussi très bien.

Éric est un garçon très sympathique, aussi je ne vais pas m’acharner sur lui, mais si je traduis le message, ça pourrait donner ça : « Hey ! Ton logiciel est fantastique ! Je peux l’avoir gratuitement, pour pouvoir l’utiliser au boulot, plaire à mon patron et me faire de l’argent ? »

Honnêtement, combien d’administrateurs disent à leur patron que ce qu’ils utilisent provient du logiciel libre ? Combien d’entre vous disent aux investisseurs que toute votre infrastructure logicielle est basée sur un truc qu’un autre gars a écrit en plusieurs mois ? Combien d’entre vous vont voir leur dirigeants en disant : « Vous savez, il y a ce gars, Zed, qui a écrit le logiciel que nous utilisons, pourquoi ne pas l’embaucher comme consultant ? »

Vous ne le faites pas. Aucun d’entre vous. Vous prenez le logiciel, et vous l’utilisez tel Excalibur terrassant le dragon, et vous en ramassez ensuite tous les lauriers. Vous ne rendez rien, et en fait, j’ai croisé une grande majorité d’entre vous qui assènent constamment que je ne sais pas développer, histoire de plus encore protéger son cul.

Il n’est désormais plus pardonnable et acceptable que vous tous plagiez le travail que vous utilisez. Comme vos employeurs ont besoin de l’illusion de « l’innovation », vous avez besoin de l’illusion d’être intelligent. Ce qui vous amène à mentir, et à voler tout ce qui vous tombe sous la main, comme si cela vous appartenait.

Ok, mais cela signifie que vous avez cassé le contrat tacite avec les développeurs et défenseurs de logiciels libres et open source. Aussi longtemps que vous me rendez ma paternité et que vous assurez la promotion de mon travail, je vous donnerai mon logiciel. Puisqu’aucun d’entre vous ne le fait, je n’ai aucune motivation à vous donner mon logiciel, de la même manière que je n’ai pas besoin de me conformer au contrat passé avec l’entreprise nourrie au capital-risque.

Voici la quatrième raison pour laquelle j’utilise la GPL :

J’utilise la GPL pour que vous restiez honnête. Vous devez désormais dire à vos patrons que vous utilisez mon boulot. Et ils s’en pisseront dessus de trouille. Parfait. Parce que j’ai aussi une solution pour ça.

Si c’est bien, payez pour l’avoir

J’aime travailler sur Lamson, parce que faire des application de messagerie est tellement plus drôle que des applications Web. Lorsque je m’assois pour construire une application de courriel, ça ne nécessite qu’un ensemble de technologies et c’est terminé. Si j’ai besoin de faire une application Web, cela implique du design, des templates, du javascript, des bases de données, et plein d’autres machins.

L’autre raison pour laquelle j’aime écrire des logiciels de courriels est que personne d’autre ne le fait. Vous tous êtes de grosses buses, parce que même avec un projet tel que Lamson, vous êtes encore tous effrayés par le gros monstre SMTP. Le jour où j’ai dit que je pourrais faire du Mail over REST, vous avez presque fait dans votre slip. Oui, parce que ça aurait été tellement plus simple.

Et j’aime donner Lamson, parce que c’est une partie de moi-même. C’est ce parfait mélange de camelote, bidouillages techniques, marketing et écriture que j’aime, et dans lequel j’excelle. Même si j’en arrive à faire des montagnes d’argent en construisant des choses avec Lamson, Lamson restera libre pour que je puisse rester honnête.

Mais j’écris aussi mes propres logiciels et projets avec Lamson. Je l’utiliserai pour créer autant d’incroyables services de courriel que je pourrais. Certains gratuits, certains payés par la pub, certains payants, mais tous utiliseront Lamson pour botter des culs avec du courriel.

Maintenant, compte tenu du fait qu’il n’y a aucune motivation pour une entreprise à admettre qu’elle utilise mon travail, et qu’il n’y a aucune motivation pour un développeur à me rendre mon travail, posez vous cette simple question :

Pourquoi diable est ce que je ne facturerais pas des gens qui ne sont pas capables d’utiliser correctement la GPL ?

Je sais, je sais, les conservateurs du logiciel libre pensent que cela fait de moi un traître, mais réfléchissez-y. Vous avez le logiciel, sous licence GPL, et aussi longtemps que vous êtes un projet open source taillé dans la pierre qui publie son code, vous êtes libre de l’utiliser et d’en faire ce que vous voulez.

J’aime l’open source, mais qu’en est-il des entreprises qui l’utilisent ? Les entreprises vont devoir payer à présent. C’est ainsi que fonctionne l’économie. Si c’est assez bon pour que vous l’utilisiez, alors c’est assez bon pour que vous le payiez.

Voici la cinquième raison pour laquelle j’utilise la GPL :

Je serai toujours un développeur open source, mais très franchement, nous crevons parce que des entreprises qui utilisent nos logiciels ne rendent rien. L’ironie de la situation est que pour pouvoir accroître ma motivation à faire de l’open source, j’ai besoin de me faire payer.

Je ne demanderai évidemment jamais rien à un projet open source puisqu’ils honorent le contrat tacite : si je donne, vous donnez.

Mais les jours des entreprises-minutes et des développeurs ingrats qui gagnent de l’argent sur mon dos avec mon logiciel sont terminés. Ma nouvelle devise est :

L’open source à l’open source, le business au business.

Si vous faites de l’open source, vous êtes mon héros et je vous soutiens. Mais si vous êtes une entreprise, alors parlons affaires.

Finalement, la valeur

Au final, je voudrais également donner une petite raison pour laquelle j’utilise la GPL : La valeur perçue. Lorsque les gens peuvent obtenir quelque chose gratuitement sans même avoir besoin d’y penser, ils lui donnent même moins de valeur que quelque chose pour lequel ils paient même pour une somme dérisoire. C’est juste la manière d’être des gens, et il n’y a pas grand chose à faire contre ça.

Ma dernière raison d’utiliser la GPL est que je crois que mes projets ont de la valeur, et je veux que les gens qui les utilisent perçoivent cette valeur. Ils ont même tellement de valeur que je veux les associer à un document légal complexe et totalement non testé comme preuve de leur utilité. Si je voulais faire simple, je les placerais simplement sous licence BSD et tout le monde les utiliseraient.

Je veux que les gens apprécient le travail que j’ai fait et la valeur de ce que j’ai réalisé.

Pas qu’ils passent en criant « pigeon » au volant de leurs voitures de luxe.

Et si le plus grand danger qui guettait désormais le logiciel libre n’était pas exogène mais endogène ?

Si, comme le pensent certains, ce n’était plus le logiciel propriétaire qui menace, mais une dilution des valeurs et de la culture du logiciel libre dans une soupe open source de… confusion et d’opacité, au grand dam de l’utilisateur qui ne serait plus alors acteur potentiel d’une communauté ?

On aurait même inventé une expression pour caractériser ces logiciels aux processus de développement privés et fermés qui, et je caricature à dessein^[1], finissent par n’avoir d’open source que la licence : les « fauxpen source ».

Personnellement j’aime beaucoup ce néologisme. Il a été inventé par Phil Marsosudiro le 2 mai 2009 au cours d’une soirée (arrosée ?) quelque part en Caroline du Nord. Comment le sais-je ? Parce que je me suis rendu sur le site, ou plutôt la page, fauxpensource.org pardi !

Et il est repris ici par Matt Asay^[2] dont je ne partage pas forcément l’optimisme (et les contradictions) mais qui évoque une problématique dont nous n’avons pas fini d’entendre parler.

Quand l’open source ne l’est pas assez (open)

When open source isn’t (open enough)

Matt Asay – 10 novembre 2009 – CNET News (The Open Road)
(Traduction Framalang : Yonnel et Cheval boiteux)

Certains logiciels open source ne sont peut-être pas assez ouverts. Alors que « open source » fait référence à la licence sous-jacente au logiciel et à son adhésion à la définition de l’open source, on trouve de nombreux exemples de projets open source qui offrent une licence ouverte mais un processus de développement relativement fermé.

On a appelé cela « fauxpen source », ou pire encore, mais nous devons peut-être nous y habituer. Cela semble être la nouvelle norme du développement open source. Seules les fondations open source comme Eclipse, Apache Software Foundation et Mozilla semblent en mesure d’y échapper totalement.

Java est souvent cité comme exemple emblématique de « fauxpen source ». Lundi, le directeur technique de SAP, Vishal Sikka, a appelé de ses vœux un processus plus ouvert pour le développement de Java, mettant en avant que Sun exerce un contrôle trop strict sur le développement de Java. C’est un reproche qui mine la communauté Java depuis des années.

Et Java n’est pas le seul. Si Google s’attire les compliments pour ses investissements dans l’open source, certains n’hésitent pas à prétendre que Google garde une communauté Android fermée. Le même genre de plaintes a vu le jour à propos de la gestion de Chrome et de Chrome OS.

Même Red Hat, la quintessence des entreprises open source, est d’abord connue pour ce qu’elle distribue, pas pour ce qu’elle développe. Red Hat, bien sûr, travaille aux côtés d’IBM et d’autres développeurs salariés ou indépendants à l’écriture du noyau Linux, et publie scrupuleusement ses logciels sous licences open source. Mais lorsqu’il s’agit du développement de sa distribution Red Hat Enterprise Linux, de son middleware JBoss ou d’autres technologies (par ex. KVM), bonne chance si vous voulez trouver des contributions externes significatives.

MySQL ? C’est grosso modo la même chose. L’entreprise (maintenant Sun Microsystems) fait virtuellement tous ses développements en interne, ce qui est vrai pour chaque entreprise privée open source qui me vient en tête. C’est une des raisons pour lesquelles Richard Stallman n’a pas à rougir de s’inquiéter de l’avenir de MySQL, même si c’est sa licence GPL préférée qui est utilisée.

La source est peut-être open, mais le processus pas nécessairement.

Il y a de très bonnes raisons pour que Google, Red Hat, MySQL et d’autres agissent de la sorte sur leurs efforts de développement open source. Ils sont responsables, fiscalement et légalement, devant leurs clients, et doivent être en capacité de garantir qualité et sécurité. On peut comprendre qu’ils exercent un certain contrôle pour s’assurer que les produits qu’ils distribuent protègent l’intégrité de leur marque.

Toutefois ceci témoigne d’un réel fossé entre « l’open source » en tant que licence et « l’open source » en tant que mode de développement et de distribution de logiciels complètement transparent. Le premier modèle est simple à mettre en place, le second beaucoup moins et demande une réelle volonté de la part de l’éditeur.

Les entreprises qui semblent mieux réussir sont celles qui ne comptent pas sur un retour sur investissement direct avec les logiciels libres. En d’autres termes, si vous ne vendez pas de l’open source, il est plus facile d’être ouvert. Doc Searls exprime cela de manière tout à fait pertinente quand il dit que « vous gagnez de l’argent grâce à (l’open source), pas de l’open source ».

Les exemples ne manquent pas. IBM en est un, Google également, bien que je sois d’accord avec ceux qui le critiquent car il peut assurément mieux faire. On peut également citer Facebook, Oracle et quelques autres.

À l’avenir, je pense que nous allons voir cette « fauxpen source » décliner, les entreprises séparant clairement leurs efforts dans l’open source et leurs modèles de ventes. L’open source peut offrir une plate-forme directe de gains, mais ce n’est pas le meilleur moyen pour véritablement générer de l’argent. Pas pour la plupart des entreprises en tout cas.

Est-ce uniquement par leur licence qu’un noyau Linux et une encyclopédie Wikipédia sont identifiés comme étant libres ?

Juridiquement parlant oui, mais s’en tenir là serait passer à côté du modèle collaboratif particulier que ce sont donnés ces deux fleurons de la culture libre pour développer leur projet.

Conséquence de la licence, c’est aussi voire surtout la puissance de ce modèle qui caractérise le Libre. Et ce modèle commence à se diffuser un peu partout dans la société…

Les mathématiques sont « libres » depuis la nuit des temps (enfin depuis que les pythagoriciens ont cessé de se cacher, pour être plus précis)^[1]. Chacun est libre des les étudier, les copier et les améliorer en étant fortement encouragé à rendre évidemment publiques ces améliorations, dans la plus pure tradition universitaire.

C’est absurde, mais si il fallait a posteriori leur accoler une licence issue de la culture libre, ce pourrait être la plus simple des Creative Commons, la CC-By, puisque cette notion de paternité est très importante dans un monde scientifique avant tout motivé par la reconnaissance des pairs et la place laissée dans l’Histoire de leur champ disciplinaire.

On retrouve d’ailleurs souvent les crédits et les hommages dans les noms que l’on donne aux résultats. On parlera ainsi de la preuve selon Euclide du théorème de Thalès.

Les mathématiques seraient donc « libres », les professeurs également (enfin surtout en France dans le secondaire avec Sésamath), mais quid des mathématiciens eux-même et de leurs pratiques ? Et si ils s’organisaient à la manière d’un projet de développement d’un logiciel libre pour chercher et éventuellement trouver ensemble des résultats importants ?

Entendons-nous bien. Les mathématiciens ne vivent bien entendu pas dans une tour d’ivoire. Ils sont habitués à travailler et échanger ensemble au sein d’un laboratoire, lors d’un séminaire… et évidemment sur Internet. Mais l’aventure intellectuelle et collective du « Projet Polymath » que nous avons choisi de vous narrer ci-dessous est un peu différente, en ce sens que ses auteurs eux-mêmes la définissent comme une expérience « open source ».

Ne vous arrêtez surtout pas à la complexité mathématique de ce qu’ils cherchent à accomplir (à savoir une « meilleure » preuve d’un théorème déjà démontré !), c’est totalement secondaire ici. Ce qui nous intéresse en revanche c’est comment ils y sont arrivés (désolé d’avoir vendu la mèche) et les enseignements qu’ils en tirent pour l’avenir.

Parce qu’il se pourrait que cet mode opératoire, original et efficient, fasse rapidement des émules, et ce bien au delà des mathématiques.

Remarque : C’est le terme « open source » qui a été choisi tout du long par les auteurs et non « free software ». Contrairement au domaine logiciel, il ne s’agit pas d’un choix ou d’un parti pris mais tout simplement d’une question de sens : « open source mathematics » étant largement plus signifiant que « free software mathematics » !

Mathématiques massivement collaboratives

Massively collaborative mathematics

Timothy Gowers^[2] et Michael Nielsen^[3] – 24 octobre 2009 – Nature.com (Opinion)
(Traduction Framalang : Olivier et Goofy)

Le « Projet Polymath » est la preuve que l’union de nombreux cerveaux peut résoudre des problèmes mathématiques complexes. Timothy Gowers et Michael Nielsen nous livrent leurs réflexions sur ce qu’ils ont appris des sciences open source.

Le 27 janvier 2009, l’un d’entre nous, Gowers, a lancé une expérience inhabituelle par l’intermédiaire de son blog (NdT : avec ce billet Is massively collaborative mathematics possible?). Le Projet Polymath s’était fixé un but scientifique conventionnel : s’attaquer à un problème mathématique irrésolu. Mais son but plus ambitieux était d’innover dans la recherche en mathématiques. Reprenant l’idée des communauté open source comme Linux et Wikipédia, le projet s’appuyait sur des blogs et des wikis pour canaliser une collaboration complètement ouverte. Libre à tout un chacun d’en suivre la progression et s’il le désire d’apporter sa contribution. Les blogs et wikis étaient en quelque sorte une mémoire à court terme collective, un brainstorming ouvert à grande échelle dédié à l’amélioration des idées.

Le résultat de la collaboration dépassa de loin les espérances de Gowers, offrant une belle illustration de ce que nous pensons être une dynamique formidable pour les découvertes scientifiques : la collaboration de nombreux cerveaux connectés par Internet.

Le Projet Polymath visait à trouver une preuve élémentaire d’un cas particulier du théorème de Hales-Jewett sur la densité (NdT : DHJ pour Density Hales-Jewett), théorème central de l’analyse combinatoire, une branche des mathématiques qui étudie les structures discrètes (voir Morpion à plusieurs dimensions). Ce théorème avait déjà été démontré, mais les mathématiciens ne se contentent pas toujours d’un seul chemin. De nouvelles preuves peuvent déterminantes pour une meilleure compréhension du théorème. Trouver une nouvelle démonstration du théorème DHJ était important pour deux raisons. Tout d’abord il fait partie d’un ensemble de résultats fondamentaux possédant plusieurs démonstrations, alors que le théorème DHJ n’en avait jusqu’alors connu qu’une seule, longue, complexe, et très technique. Seul un élan de nouvelles idées pouvait amener à une preuve plus simple, s’appuyant sur des concepts de base plutôt que sur des techniques compliquées. Ensuite, du théorème DHJ découle un autre théorème important, le théorème de Szemerédi. La découverte de nouvelles preuves de ce théorème a conduit à de grandes avancées au cours de la dernière décennie, on pouvait donc raisonnablement s’attendre à ce qu’un même phénomène accompagne la découverte d’une nouvelle démonstration du théorème DHJ.

À l’origine du projet on retrouve Gowers. Il publia une description du problème, indiqua quelques ressources et établit une liste préliminaire de règles régissant la collaboration. Grâce à ces règles, les échanges sont restés polis et respectueux, elles encourageaient les participants à proposer une et une seule idée par commentaire, même sans la développer complètement. Ces règles stimulaient ainsi les contributions et aidaient à conserver le caractère informel de la discussion.

Mettre le projet sur les bons rails

La discussion collaborative a vraiment commencé le 1er février, doucement : il a fallu attendre plus de 7 heures avant que Jozsef Solymosi, un mathématicien de l’Université de la Colombie Britannique à Vancouver, fasse le premier commentaire. Quinze minutes après, un nouveau commentaire était posté par Jason Dyer, enseignant dans un lycée de l’Arizona. Trois minutes après, c’est Terence Tao (lauréat de la médaille Fields, la plus haute distinction en mathématiques), de l’Université de California à Los Angeles, qui écrivit son commentaire.

Au cours des 37 jours qui suivirent, ce sont pas moins de 27 personnes qui ont apporté leur contribution au travers d’environ 800 messages, pour un total de 170 000 mots. Personne n’a été spécialement invité à participer : la discussion était ouverte à tout le monde, des doctorants aux experts mathématiciens. Nielsen a mis en place un wiki pour mettre en avant les contributions importantes apparues dans les commentaires du blog. Au moins 16 autres blogs ont parlé du projet, il s’est hissé à la première page de l’agrégateur Slashdot technology et a donné naissance à un projet assez proche sur le blog de Tao.

Tout s’est déroulé sans accroc : pas de « trolls » (ces adeptes des posts non constructifs, voire malveillants), ni de commentaires bien intentionnés mais complètement inutiles (on peut malgré tout signaler que le wiki a été spammé). Le rôle de modérateur pris par Gowers se résumait essentiellement à corriger les fautes.

Le projet progressa bien plus rapidement qu’attendu. Le 10 mars, Gowers annonça qu’il était assez sûr que les participants au projet Polymath avaient découvert une preuve élémentaire d’un cas particulier du théorème DHJ et, qu’étonnamment (compte tenu des expériences avec des problèmes similaires), cette preuve pouvait être généralisée assez facilement pour prouver le théorème entier. La rédaction d’un article décrivant cette preuve est entreprise, ainsi que celle d’un second papier décrivant des résultats liés. De plus, alors que le projet était encore actif, Tim Austin, doctorant à l’Université de Californie, Los Angeles, publia une autre preuve (non élémentaire celle-ci) du théorème DHJ en s’appuyant largement sur les idées développées dans le projet Polymath.

Les archives du projet Polymath constituent une ressource exceptionnelle pour les étudiants en mathématiques, les historiens et autres philosophes des sciences. Pour la première fois, on peut suivre le cheminement intellectuel complet à l’origine d’un résultat mathématique sérieux. On y voit les idées naître, grandir, changer, s’améliorer ou être abandonnées, et on y découvre que la progression de la compréhension ne se fait pas nécessairement par un unique pas de géant, mais plutôt par le regroupement et le raffinement de plusieurs petites idées.

C’est un témoignage direct de la persévérance dont il faut faire preuve pour résoudre un problème complexe, pour progresser malgré les incertitudes et on réalise que même les meilleurs mathématiciens peuvent faire des erreurs simples et s’entêter à creuser une idée vouée à l’échec. Il y a des hauts et des bas et on ressent une vraie tension à mesure que les participants s’approchent d’une solution. Les archives d’un projet mathématique peuvent se lire comme un thriller, qui l’eût cru ?

Des implications plus larges

Le projet Polymath ne ressemble pas aux collaborations à grande échelle traditionnelles, comme on peut en trouver dans l’industrie ou dans les sciences. En général, ces organisations sont divisées hiérarchiquement. Le projet Polymath était complètement ouvert, chacun était libre d’apporter sa pierre à l’édifice… n’importe quelle pierre. La variété des points de vue a parfois apporté des résultats inattendus.

Se pose alors la question de la paternité : difficile de décréter une règle de paternité stricte sans heurt ou sans décourager des contributeurs potentiels. Quel crédit accorder aux contributeurs apportant uniquement une idée perspicace, ou à un contributeur très actif mais peu perspicace ? Le projet a adopté une solution provisoire : il signe ses articles du pseudonyme « DHJ Polymath » suivi d’un lien vers les archives (NdT : cf cette première publication ainsi signée A new proof of the density Hales-Jewett theorem). Grâce à la collaboration ouverte privilégiée par le projet Polymath, on sait exactement qui a fait quoi. Au besoin, une lettre de recommandation peut isoler les contributions d’un membre du projet en particulier, comme c’est déjà le cas en physique des particules où il est courant de voir des articles avec des centaines d’auteurs.

Se pose aussi le problème de la conservation. Les archives principales du projet Polymath sont dispersées sur deux blogs (1 et 2) et un wiki, le rendant très dépendant de la disponibilité de ces sites. En 2007, la bibliothèque du Congrès américain a initié un programme de conservation des blogs tenus par les professionnels du droit. De la même manière, mais à plus grande échelle, un programme similaire est nécessaire pour conserver les blogs et wikis de recherche.

D’autres projets, ayant vu le jour depuis, permettront d’en apprendre plus sur le fonctionnement des mathématiques collaboratives. Il est en particulier crucial de savoir si ce genre de projet peut être élargi à plus de contributeurs. Bien qu’il ait rassemblé plus de participants qu’une collaboration classique en mathématiques, le projet Polymath n’est pas devenu la collaboration massive que ses créateurs espéraient. Ceux qui y ont participé s’accordent sur le fait que pour grandir, il faudrait que le projet adapte sa manière de procéder. La narration linéaire du blog posait, entre autre, problème aux nouveaux arrivants. Difficile pour eux, parmi la masse d’informations déjà publiées, d’identifier où leur aide serait la plus précieuse. Il y avait également le risque qu’ils aient loupé un « épisode » et que leur apport soit redondant.

Les projets de logiciels libres utilisent des logiciels de suivi de version pour organiser le développement autour des « problèmes », des rapports de bogues ou des demandes de fonctionnalités en général. Ainsi, les nouveaux arrivants ont une vision claire de l’état du projet, ils peuvent concentrer leurs efforts sur un « problème » particulier. De même, la discussion est séparée en modules. Les futurs projets Polymath pourraient s’en inspirer.

Bientôt, les sciences ouvertes

L’idée derrière le projet Polymath est potentiellement applicable à tous les défis scientifiques, mêmes les plus importants comme ceux pour lesquels le Clay Mathematics Institute de Cambridge, Massachussets offre un prix d’un million de dollars. Même si certaines personnes souhaiteront toujours garder tout le mérite pour elles-mêmes et être pour ainsi dire refroidies par l’aspect collaboratif, d’autres au contraire pourraient y voir une excellente opportunité d’être associés à la résolution de l’un de ces problèmes.

Dans d’autres disciplines, l’approche open source ne gagne que très lentement du terrain. Un domaine s’y est ouvert avec succès : la biologie synthétique. Les informations ADN d’organismes vivants sont enregistrées numériquement et envoyées à un dépôt en ligne, comme celui du MIT Registry of Standard Biological Parts. D’autres groupes peuvent utiliser ces informations dans leur laboratoire et, s’ils le souhaitent, reverser leurs améliorations au dépôt. qui compte actuellement plus de 3 200 contributions, apportées par plus de 100 entités différentes. Les découvertes qui en découlent ont fait l’objet de nombreux articles comme par exemple Targeted Development of Registries of Biological Parts. La biologie open source et les mathématiques open source montrent comment la science peut progresser grâce aux diverses contributions apportées par des gens aux compétences variées.

On pourrait, de la même manière, employer ces techniques open source dans d’autres domaines, telle la physique et l’informatique théoriques, où les données brutes contiennent de nombreuses informations et peuvent être partagées librement en ligne. Appliquer les techniques open source aux travaux pratiques est plus délicat, les conditions expérimentales étant difficilement reproductibles. Quoiqu’il en soit, le partage libre des données expérimentales permet néanmoins leur analyse libre. Adopter ces techniques open source à grande échelle ne sera possible que grâce à un changement profond des mentalités en science et au développement de nouveaux outils en ligne. Nous croyons à un fort développement de la collaboration de masse dans de nombreux domaine des sciences, et que cette collaboration massive repoussera les limites de nos capacités à résoudre des problèmes.

On le sait, Microsoft n’a pas vu venir le Web et ne porte pas le logiciel libre dans sa culture (c’est le moins que l’on puisse dire).

À partir de là comment s’étonner qu’un Google lui fasse aujourd’hui concurrence et menace demain d’attaquer frontalement ses deux plus beaux fleurons (et source colossale de revenus) que sont le système d’exploitation Windows et la suite bureautique MS Office.

Un Google qui a massivement investi dans le cloud computing, l’informatique dans les nuages, Un Google qui non seulement ne méprise pas le logiciel libre mais sait très bien l’utiliser quand ça l’arrange, par exemple pour faire s’y reposer son navigateur Chrome ou son prochain et très attendu Google OS (histore de boucler la boucle)^[1].

À propos de Google OS, un petit coup de Wikipédia : « Google Chrome OS est un projet de système d’exploitation qui sera fondé sur son navigateur Web Chrome et un noyau Linux. À destination des netbooks dans un premier temps, il serait capable, à terme, de faire tourner des ordinateurs de bureau traditionnels. Google laisse à penser que son OS fonctionnerait en ligne sur tout ou partie, comme ses applications (Google Documents, Gmail, etc.). Après sa suite gratuite Google Documents concurrent de la suite payante Microsoft Office, puis Android face à Windows Mobile, ce nouveau système d’exploitation gratuit attaque le cœur du business Microsoft. »

La fin d’un cycle, si ce n’est d’une époque ?

Google est en compétition pour le futur; Microsoft, pour le passé

Google competes for the future; Microsoft, the past

Matt Asay – 23 octobre 2009 – CNET News
(Traduction Framalang : Poupoul2 et Goofy)

Google est né sur le Web, et provoque de plus en plus de quintes de toux chez Microsoft en contraignant le géant séculaire du logiciel à se battre en utilisant les règles de Google. Comme avec l’open source. Comme avec l’informatique dans les nuages.

Microsoft pourrait se reposer sur ses lauriers dans l’immédiat grâce au lancement réussi de Windows 7. Mais à long terme son plus grand succès que représentent ses vieux logiciels de bureautique menace de céder le marché à Google.

Ce n’est pas très équitable pour Microsoft. Microsoft est victime de son propre succès, en ayant besoin de s’adresser à sa clientèle existante à chaque nouvelle version, coincé qu’il est par le « dilemme de l’innovateur ». Microsoft continue de remplir ses caisses, mais ses deux derniers trimestres ont vu ses forces traditionnelles telles que le système d’exploitation Windows devenir un frein pour ses revenus, tandis que les entreprises dépensent toujours plus d’argent auprès de Google, Red Hat et quelques autres.

L’absence d’héritage de Google lui permet d’innover rapidement à large échelle, comme le suggère Todd Pierce, directeur technique de Genentech et client de Google :

Le rythme d’innovation de Google…, enfin bon, le cycle de production d’Oracle, SAP et Microsoft est de cinq ans, celui de Google est de cinq jours. C’est incrémental. En cinq jours, vous ne pouvez pas supprimer toutes vos licences de Microsoft Office, mais d’ici cinq ans, vous n’aurez plus de Microsoft Office.

Microsoft, de son côté, est tellement préoccupé par la compatibilité ascendante, « Ce produit ou cette fonctionnalité sont-ils compatibles avec notre capacité à monétiser notre monopole sur la bureautique des années 80 ? », qu’ils continuent à se battre pour comprendre le Web. Dave Rosenberg, blogueur sur CNET, note que Windows 7 aurait dû être la tête de pont de Microsoft sur l’informatique dans les nuages, mais qu’il n’en a rien été.

Il y a beaucoup de « aurait dû être » chez Microsoft, lorsqu’on parle du Web.

Dans l’intervalle, personne ne ralentit pour attendre Microsoft. Arrêtons-nous un instant sur l’informatique dans les nuages. VMware domine la virtualisation, et a de grandes ambitions dans l’informatique dans les nuages, alors que les rivaux open source Eucalyptus et VMops menacent de contester la suprématie de VMware et Microsoft, en cherchant à dominer l’informatique dans les nuages.

Et arrive alors Google, qui fournit une gamme de services d’informatique dans les nuages toujours plus large aux entreprises qui cherchent à se détacher de l’ordinateur de bureau. Dans une interview donnée à CNET News, Eric Schmidt, PDG de Google, soutient que le navigateur peut être à la fois orienté entreprise et consommateur. L’architecture est dirigée par le navigateur. C’est toute l’histoire de l’informatique d’entreprise actuelle.

En d’autres termes, le bureau est simplement un moyen pour l’utilisateur de lancer son navigateur. C’est une passerelle. Il n’y a plus de valeur dans le bureau. Elle se trouve dans le navigateur, qui devient le nouveau bureau, en termes de fonctionnalités réelles disponibles

La meilleure opportunité pour Microsoft de contrecarrer la menace de Google et des autres s’appelle SharePoint. Le PDG de Microsoft, Steve Ballmer, l’a décrit comme le nouveau système d’exploitation de Microsoft, mais ce n’est que dans un entretien récent avec Forrester qu’il lui a donné tout son sens :

Dans mon esprit, je compare SharePoint au PC, le PC est venu à la vie comme machine à tableau, puis est devenu une machine à développer, une machine à traiter du texte, SharePoint est une infrastructure à objectif global qui connectera les gens aux gens, et les gens à l’information…

Je crois que SharePoint est considéré par les administrateurs informatiques et les développeurs comme une plateforme de développement très sérieuse pour les développement rapide d’application (NdT : RAD, Rapid Application Development).

SharePoint est la meilleure tentative de Microsoft pour connecter les applications de bureau telles qu’Office, avec des outils collaboratifs et de stockage centralisé ou dans les nuages. Bien sûr, Microsoft a d’autres initiatives telles qu’Office en ligne, mais aucune ne marie aussi bien ses centres de profits historiques et l’innovation future.

SharePoint pourrait alors être le meilleur espoir de Microsoft pour marier son héritage à la future informatique en ligne.

Microsoft a besoin de cela. Ils perdent dans le marché des mobiles, et pas uniquement face à Apple. Android, le système dédié de Google, est déjà efficient et opérationnel, avec par exemple ses données AdMob qui situent aujourd’hui la pénétration des smartphones Android à 10 % au Royaume Uni.

Si nous prenons l’hypothèse que le mobile sera de plus en plus une plateforme de choix pour le client, alors nous voyons Google harceler Microsoft par le haut (les nuages de services) et par le bas (le client).

Dans les deux cas, l’open source est une arme de choix pour Google, et c’en est une que Microsoft va devoir comprendre rapidement s’ils veulent devenir un acteur de poids sur le Web. Le Web est trop grand pour que Microsoft le contrôle, et le Web est incroyablement open source, tel que le remarque Mitch Kapor, fondateur de Lotus :

La victoire de l’open source est qu’il constitue le fondement du Web, la partie invisible, celle que vous ne voyez pas en tant qu’utilisateur.

Les majorité des serveurs utilisent Linux comme système d’exploitation avec Apache comme serveur Web sur lequel tout le reste est construit. Les principaux langages sur lesquels les applications Web sont construites, qu’il s’agisse de Perl, de Python, de PHP ou de n’importe quel autre langage, sont tous open source. Donc l’infrastructure du Web est open source. Le Web tel que nous le connaissons est totalement dépendant de l’open source.

Kapor suggère que la guerre que Microsoft livre à l’open source est terminée, ou devrait l’être : l’open source a gagné. Il s’agit désormais d’une infrastructure essentielle, et quelque chose que Microsoft doit arriver à comprendre, plutôt que de le combattre. Il ne s’agit pas de « religion open source », il ne s’agit que de pragmatisme. Un pragmatisme que Microsoft peut s’approprier aussi bien que n’importe qui d’autre.

Google utilise le futur (l’open source, les nuages) pour se battre pour l’avenir, et ses tactiques menacent de frapper Microsoft au cœur de ses vaches à lait tels que Windows.

Microsoft, cependant, semble être embourbé dans son passé. Windows 7 a l’air d’une mise à jour sérieuse de son prédécesseur Vista, mais dans dix ans, cela aura-t-il une importance pour nous ? Peut-être aurons-nous changé, oubliant ces jours pittoresques où nous nous soucions du système d’exploitation et des applications telles qu’Office ?

Le concept de logiciel libre n’étant pas toujours très simple à expliquer, la tentation est alors forte de lui trouver quelques comparaisons plus parlantes et signifiantes aux yeux du grand public.

La plus cèlèbre d’entre elles est la comparaison dite de la recette de cuisine. Selon le principe du libre, vous avez obtenu légalement cette recette par différentes sources (des revues, le bouche à oreille…), vous avez le droit de préparer cette recette à qui vous voulez et vous pouvez la modifier puis la redistribuer comme il vous plaît. Selon le principe du logiciel non libre, vous n’avez pas accès à la recette, mais uniquement au plat déjà fait, vous ne pouvez manger le plat que dans une seule cuisine, et personne d’autre que vous ne peut en manger. Quand bien même la recette serait fournie avec le plat, toute copie ou modification serait interdite^[1]

Nous vous proposons aujourd’hui une comparaison avec l’achat et l’utilisation d’une voiture^[2], que nous devons à Tal Schechter de la Free Software Foundation. Comparaison d’autant plus pertinente que, dans le monde automobile, l’électronique a pris désormais le pas sur la mécanique avec toutes les conséquences que cela implique sur la réparation, la garantie et le contrôle de la marque.

La comparaison avec une voiture

The car analogy

Tal Schechter – 13 octobre 2009 – FSF.org
(Traduction Framalang : Kovalsky et Goofy)

Et si nous comparions l’achat d’une nouvelle nouvelle voiture avec l’utilisation de logiciels non libres ? Même si l’exemple suivant peut sembler quelque peu tiré par les cheveux, c’est une très bonne analogie pour comprendre l’importance de la liberté des utilisateurs dans les logiciels.

Imaginez que vous voilà parti pour acheter une nouvelle voiture. Après avoir choisi une marque, vous allez chez le concessionnaire et commencez à regarder ce qu’on peut vous proposer. Vous vous décidez pour un modèle qui vous plaît, et le vendeur essaie de vous vendre toutes sortes de choses dont vous n’avez pas besoin, et d’autres qui vous laissent sceptique. Une sous-couche de peinture ? Est-ce bien nécessaire ? Après avoir signé un contrat avec le vendeur, vous avez vos clés en mains.

Vous avez refusé de payer pour l’usage du coffre. Comme il y a un coffre intégré, ils ont essayé de vous vendre l’option d’avoir une copie de la clé, « Je n’ai pas réellement besoin d’un coffre », pensez-vous. « Je l’ajouterai plus tard si j’en ai besoin »

En ouvrant la porte, vous trouvez une énorme pile de papiers attachés par une pince au siège avant. La première page dit « Merci d’avoir acheté cette nouvelle voiture PaLibre. Nous espérons que vous l’apprécierez pendant de nombreuses années à venir. En déverrouillant et en ouvrant la porte, vous avez implicitement accepté les termes de ce contrat. Merci de prendre le temps de lire la notice d’utilisation ». Outré, vous retournez au bureau du vendeur. « Qu’est ce que ça veut dire, que j’ai implicitement accepté les termes du contrat ? Ne suis-je pas supposé lire le contrat avant de le signer ? ». Il vous répond que tout le monde trouve que le contrat est très ennuyeux, et que pour satisfaire pleinement la clientèle, on le signe à votre place. Satisfait de cette réponse, vous ramenez votre voiture flambant neuve à la maison.

Quelques mois passent sans aucun problème, et vous appréciez généralement votre voiture. Un jour, en conduisant, vous faites un saut sur l’autoroute. Vous aimez le son que fait votre voiture lorsque vous poussez un peu le moteur. Attendez une minute, vous ne semblez pas pouvoir aller à plus de 90 kms/heure ! Vous entendez une voix de synthèse qui vous dit : « À cause d’une mise à jour de sécurité du constructeur, vous ne pouvez pas dépasser 90 kms/heure. Bonne conduite ». Vous haussez les épaules et pensez, « Bon d’accord, c’est pour la sécurité. Ça pourrait être pire ». Vous prenez la sortie et rentrez chez vous.

Le matin suivant en allant au boulot, vous remarquez de drôles de bruits venant de sous le capot. Vous avez une amie qui s’y connaît en voiture, donc vous lui demandez si elle peut passer après le travail. Quand elle voit votre voiture, elle vous dit « Non. Je ne peux rien faire pour toi. C’est une de ces voitures PaLibres. Je ne peux même pas ouvrir le capot ».

Donc vous l’amenez chez votre garagiste, et il ne prend même pas la peine de vous faire payer un devis. « Désolé Monsieur. C’est une voiture PaLibre. Même si j’avais les bon outils, je ne pourrais pas déverrouiller le capot, et encore moins voir ce qui ne va pas. C’est contre la loi ». Estomaqué, vous retournez chez le concessionnaire pour demander « Quel est le problème? »

Après avoir attendu une éternité, finalement une employée du service après-vente appelle votre nom. Vous expliquez le bruit que fait la voiture et toutes les étapes que vous avez franchies pour essayer de la faire réparer. Elle explique que pour préserver la bonne image de PaLibre, ils ne laissent pas n’importe qui s’occuper de leurs voitures. Vous devez avoir une formation et une accréditation. Vous demandez à voir le contrat que vous avez signé. Une des clauses précise que tout ajout de pièce détachée non-homologuée annulera la garantie. Vous demandez à l’employée à quoi cela s’applique, et elle vous explique que même repeindre votre voiture avec une couleur non approuvée par le concessionnaire supprimerait la garantie.

Votre voiture va au garage du concessionnaire. Ils vous font payer un devis, ainsi qu’une « surtaxe de licence de réparation homologuée ». Ils vous appellent pour que vous alliez récupérer votre voiture, et ils vous disent qu’il n’ont rien trouvé. Vous récupérez votre voiture, et elle continue à faire ce bruit désagréable. Vous demandez au garagiste qui vous répond « Oh, parfois les voitures PaLibres font ce bruit. Il n’y a pas à s’inquiéter».

Même si l’histoire peut sembler ridicule, c’est exactement ce qu’il se passe lorsqu’une personne choisit d’utiliser un logiciel non libre. Vous choisissez le logiciel qui correspond le mieux à vos besoins, et parfois un vendeur vous aide. Vous acceptez un contrat que vous n’avez probablement pas lu, et parfois vous acceptez implicitement les termes d’utilisation du programme. Vous utilisez le logiciel. Cependant, vous pouvez utiliser le logiciel uniquement comme l’éditeur l’a autorisé (conduire dans notre comparaison). Quand le logiciel dysfonctionne, ou même lorsque vous voulez améliorez quelque chose, vous ne pouvez aller nulle part ailleurs que chez l’éditeur. Vous ne pouvez pas aller chez un ami qui s’y connaît en informatique. Vous ne pouvez pas demander à une autre entreprise de vous régler ça. Vous devez aller chez les développeurs. Lorsque vous leur expliquez votre problème, ils vous répondent peut-être « Nous ne pouvons pas faire ça pour vous ». Ils peuvent dire « On y pensera pour la prochaine version ». Il est plus probable encore qu’ils disent « C’est une fonctionnalité, il n’y a rien à réparer ».

Les logiciels libres, de leur côté, proclament les libertés des utilisateurs. Les logiciels libres sont définis ainsi : des logiciels que vous pouvez utiliser dans n’importe quel but (pour conduire, servir de presse-papier, d’objet d’art, etc.) ; des logiciels que vous avez la liberté d’étudier et de modifier si vous voulez, avec l’accès au code source (ouvrir le capot et regarder ce qu’il y a à l’intérieur, réparer et modifier de la façon dont vous l’entendez) ; des logiciels qui peuvent être redistribués ; des logiciels auxquels vous pouvez apporter des améliorations que vous pouvez publier (ajouter un évent sur le capot et un turbocompresseur, et mettre les plans de ce que vous avez fait sur votre site favori).

Nous n’acceptons pas les violations de nos libertés lorsque nous achetons une voiture, donc pourquoi devrions-nous le faire avec les logiciels ?