Gratuité, ouverture et liberté des programmes

La pensée du commun comme horizon existentiel nous expose de fait au processus d’une ouverture. Comment ce que formule Jean-Luc Nancy à propos de « l’être-en-commun » peut-il être travaillé au sein des programmes ? Pour répondre à cette question, nous devons nous demander ce qui sépare « l’open source » du « logiciel libre ». Avec l’apparition des programmes numériques, comme l’indique Annick Lantenois, le savoir-faire se double du « savoir-comprendre » et du « savoir-maîtriser⁷⁰⁷ ». L’enjeu de l’époque serait alors de développer une culture technique qui reposerait sur une compréhension partagée des aspects techniques habituellement laissés sous silence. La compréhension du fonctionnement interne d’un programme passe par une représentation transmissible de ses fonctions et de son fonctionnement. L’objet de cette réflexion est donc d’étudier des modes d’ouverture efficients des programmes.

Le champ des logiciels dits libres travaille un certain nombre d’attitudes permettant de penser en design une matière avec laquelle il est possible de s’exercer. Il importe donc tout d’abord de comprendre en quoi consiste ce mouvement. Inventeur du projet gnu⁷⁰⁸ et de la licence libre gpl⁷⁰⁹, Richard Stallman opère une distinction importante entre « open source » et « libre » à propos des « free softwares ». On entend cette opposition en français dans le double sens du mot « free » : gratuit et libre. La gratuité, nous dit Richard Stallman, n’est pas forcément synonyme de liberté :

Quand on dit qu’un logiciel est « libre », on entend par là qu’il respecte les libertés essentielles de l’utilisateur : la liberté de l’utiliser, de l’étudier et de le modifier, et de redistribuer des copies avec ou sans modification. C’est une question de liberté, pas de prix, pensez donc à « liberté d’expression » et pas à « entrée libre⁷¹⁰ ».

C’est donc la liberté de « l’utilisateur » et de la « communauté » qui est au centre des logiciels libres. Le logiciel n’est pas libre en soi, ni d’ailleurs libérateur. Il ne se situe pas du côté de la privation :

Quand les utilisateurs ne contrôlent pas le programme, c’est le programme qui les contrôle. Le développeur contrôle le programme, et par ce biais contrôle les utilisateurs. Ce programme non libre, ou « privateur », devient donc l’instrument d’un pouvoir injuste⁷¹¹.

Le terme d’open source désigne, au sens propre, le fait de pouvoir accéder techniquement aux codes sources. On peut très bien faire l’apologie de l’open source pour des raisons économiques, la plupart des programmes sous licence gpl étant gratuits. Stallman explique que l’open source s’est constitué comme mouvement autonome une quinzaine d’années après la pensée du logiciel libre. Bien que les deux expressions puissent sembler proches, elles peuvent, dit Stallman, recouper des philosophies complètement différentes : « L’open source est une méthodologie de développement ; le logiciel libre est un mouvement social⁷¹². » L’open source n’envisage les programmes que sous l’angle de la performance. Ils ne sont considérés comme pertinents que s’ils sont plus efficaces que leurs équivalents « propriétaires ». En mettant de côté la dimension éthique du logiciel libre, le discours de l’open source a pu se faire accepter du monde traditionnel de l’entreprise (économie de moyens) et d’utilisateurs soucieux d’améliorations constantes. C’est pourquoi nous dit Stallman, l’open source est une notion beaucoup plus faible que le logiciel libre. Pour beaucoup de gens, explique-t-il, l’open source se réduit à l’accès au code des programmes, le fait que n’importe qui puisse regarder leurs sources. Or, un logiciel « privateur » peut très bien permettre cela, et donner accès à des « pré-versions » (beta) du programme.

Plus encore, un « logiciel [open source ] puissant et fiable peut être mauvais⁷¹³ ». Stallman donne l’exemple des drm, qui sont des mesures visant à restreindre la consultation de contenus protégés par des droits d’auteurs. En l’occurrence, il existe des « drm open source », qui permettent de chiffrer (et donc de limiter) de façon plus efficace l’accès à des médias. Bien qu’un tel programme, nous dit Stallman, utilise des méthodologies open source, il ne respecte en rien la philosophie visant à préserver la liberté des utilisateurs. Un logiciel open source peut donc être plus « privateur » que son équivalent propriétaire. Dans le même esprit, Stallman donne comme exemples des dispositifs embarquant des programmes exécutables qui correspondent à du code source libre, mais qui ne permettent pas d’installer des versions modifiées de ces programmes. Seule la société à l’origine de ces systèmes a le pouvoir de les changer. Il en est ainsi du système d’exploitation Google Android à destination de terminaux mobiles, ou des enregistreurs vidéo TiVo. Selon Stallman, « ces exécutables ne sont pas des logiciels libres bien que leur code source soit libre⁷¹⁴ ».

Pour le mouvement du logiciel libre, les programmes ne sont pas immédiatement des « solutions », mais des prises de conscience d’une liberté fondamentale. Les logiciels « privateurs » sont susceptibles de nous priver de quelque chose. Comme nous le montrent le développement problématique des app stores et le « devenir applicatif » des logiciels (Stallman parle de « menottes numériques »), il est de plus en plus difficile de développer un programme sans demander au préalable une autorisation et une validation. L’importance accordée au terme de « libre » pose d’emblée une vision éthique du design : celle d’une société fondée sur le partage, la mise en commun et la redistribution sans condition préalable. Précisons que Richard Stallman ne discute le concept de « libre » que dans le champ des programmes numériques :

Le terme « open source » a été étendu à d’autres champs d’activités, tels que l’administration publique, l’éducation et la science, où la notion de code source n’a pas de sens, et où les critères des licences de logiciel ne sont tout simplement pas pertinents. La seule chose que ces activités ont en commun est qu’elles invitent toutes à leur manière la participation du public. Elles détournent ce terme pour lui donner la signification de « participatif » ou « transparent », ou encore moins, jusqu’à en faire une expression à la mode vide de sens⁷¹⁵.

Pour Richard Stallman, il existe donc une éthique des programmes. La préservation de la fondamentale liberté humaine recoupe l’idée que l’humanité n’existe qu’à condition de pouvoir se diriger elle-même. Refuser d’être contrôlé par des programmes engage donc une responsabilité et des choix. Les logiciels « privateurs » restreignent nos facultés à décider ce qui est bon pour nous. Richard Stallman les envisage comment des coureurs sportifs qui en viendraient aux mains au lieu de « parcourir une certaine distance⁷¹⁶ ». Pour lui, la compétition n’a pas lieu d’être dans le domaine des programmes. Invoquant la « règle d’or » de la morale du devoir de Kant disant « ne fais pas à autrui ce que tu ne voudrais pas qu’il te fasse », Stallman explique qu’il lui est impossible de ne pas partager un programme avec d’autres utilisateurs. Sa conception des programmes repose sur quatre libertés fondamentales :

– La liberté d’utiliser un programme comme on le souhaite ;
– La liberté de modifier et d’étudier le code source du programme ;
– La liberté de redistribuer des copies d’un programme ;
– La liberté de faire bénéficier les versions modifiées d’un programme.

Si, comme le pense Stallman, il faut toujours préférer la liberté à la « commodité⁷¹⁷ », il nous faut également nous demander comment cette liberté est effective au sein des programmes. Il nous semble ainsi nécessaire de ne pas abandonner la notion d’ouverture, sans laquelle aucune liberté ou conduite technique n’est possible. Ma liberté n’est exerçable que si j’ai devant moi « l’infinité ouverte des champs de présence révolus ou possibles⁷¹⁸ ». Le logiciel devient alors l’endroit d’une double ouverture, celle qui laisse possible l’exercice d’un choix, et celle qui consiste à choisir, parmi ces choix, ceux qui préserveront cette fondamentale liberté. Certains logiciels libres, au-delà de leur fiabilité et de leur puissance, semblent ainsi pousser plus avant que d’autres cette liberté. Autrement dit : quelles sont les pratiques pouvant favoriser au sein des programmes la conscience et l’exercice d’une liberté ?

Si n’importe quel programme peut diverger de ce qu’il est, nous pensons que les programmeurs et les designers peuvent travailler ces modalités d’espacement. On pourrait ainsi envisager la réussite d’un projet dit libre à sa faculté à s’écarter de ce qui était prévu au départ. Ce sont les détours par rapport à un donné qui nous importent. Sans en faire des remèdes absolus à l’ignorance, les logiciels libres favorisent une compréhension de leur structure interne pouvant permettre une expansion de ce qu’ils sont. Ils comprennent davantage que des façons de faire : des façons de faire avec et de faire autrement. En abordant le projet comme une entité toujours développable, des pratiques comme le développement contributif (comme GitHub⁷¹⁹), la documentation des codes sources ou l’entraide sur des sites web comme Stack Overflow⁷²⁰ [ Fig. 238 ], Fig. 238 vont dans ce sens. À l’inverse, on pourrait considérer qu’un logiciel libre au code source confus et trop complexe basculerait dans un type de technique non transmissible, réservé aux schèmes d’une communauté trop tournée vers elle-même, devenue incapable de s’adresser aux autres. Ils nous semble donc que la liberté des logiciels libres est à la fois fonction de langages communs et de modalités de traduction. Un programme « idiolecte » ne pourra être développé par d’autres.

Critiquant la vision normative du logiciel libre, Eric Raymond est l’un des fondateurs du mouvement open source. Il précise cette opposition dans son article « Le cathédrale et le bazar⁷²¹ ». Au contraire de Richard Stallman, Eric Raymond envisage les programmes sous l’angle de leur faculté à se développer. Son analyse va donc consister à analyser les facteurs de réussite ou d’échec d’une conduite de projet collaborative d’un programme numérique. Le début de l’article expose la thèse principale d’Eric Raymond. Il y a deux façons de programmer un logiciel, une de l’ordre de la « cathédrale », et une autre de l’ordre du « bazar ». La métaphore de la cathédrale renvoie à la volonté de planifier chaque élément du programme, et de les coder au sein d’un environnement parfaitement fermé et contrôlé. La vue d’ensemble est donnée d’avance, il n’y a qu’à l’exécuter. Cette image (fausse historiquement⁷²²) permet à Eric Raymond de poser une deuxième façon de faire, celle du « bazar⁷²³ ». Elle consiste à laisser les utilisateurs se débrouiller entre eux pour améliorer et porter plus loin le programme. L’expansion d’Internet, explique Eric Raymond, a directement permis de coordonner le travail autour de Linux. S’appuyant sur ce modèle d’un nouveau genre, Eric Raymond donne un certain nombre de règles susceptibles de favoriser le succès d’un logiciel ouvert. L’auteur organise son article autour du récit du développement du programme fetchmail, dédié au traitement des courriers électroniques. Il explique comment il est parti d’une base existante, qu’il a tellement modifiée qu’elle est devenue un projet autonome. La réussite de fetchmail tient dans la compréhension des mécanismes sociaux de projets à plusieurs. L’article déroule ainsi un certain nombre d’assertions empiriques, parmi lesquelles :

– Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.
– Les grands programmeurs savent quoi réécrire (et réutiliser).
– Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent.
– Un plus grand nombre d’utilisateurs trouve un plus grand nombre de bogues.
– Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d’avoir de bonnes idées vous-même.
– Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise⁷²⁴.

Eric Raymond est pris dans les contradictions d’une pensée collective et d’une pensée individuelle. Telle qu’il la décrit, la « méthode bazar » n’est efficace qu’à mesure de l’intéressement personnel que les utilisateurs pourront y trouver⁷²⁵. De Richard Stallman à Eric Raymond, on passe bien d’une pensée de la liberté à celle de l’efficacité :

Peut-être qu’à terme, la culture du logiciel dont le code source est ouvert triomphera, non pas parce qu’il est moralement bon de coopérer, non pas parce qu’il est moralement mal de « clôturer » le logiciel […], mais simplement parce que le monde dont le code source est fermé ne peut pas gagner une course aux armements évolutive contre des communautés de logiciel libre, qui peuvent mettre sur le problème un temps humain cumulé plus important de plusieurs ordres de grandeurs⁷²⁶.

Les intuitions formulées par Eric Raymond en 1997 se sont révélées historiquement exactes. Même si des systèmes « clôturés » (Eric Raymond n’emploie pas le terme de « privateur ») existent toujours, et que certains sont très puissants (qu’on songe à Facebook, Adobe ou Windows), l’open source a pris une ampleur très importante⁷²⁷. La fin de l’article évoquait l’ouverture du code source du navigateur web Netscape, en se demandant ce qu’il en deviendrait. Plus de quinze ans après, la Fondation Mozilla se donne comme mission de faire perdurer l’ouverture constitutive du Web avec (entre autres) son navigateur web Firefox, développé pour contester l’hégémonie léthargique d’Internet Explorer. L’apparition en 2008 du navigateur concurrentiel Chrome se fera sous couvert d’idéologie open source⁷²⁸ et d’efficacité. Ce dernier occupe en 2013 la troisième place des navigateurs, tout prêt de Firefox. L’efficacité est en passe de l’emporter sur la liberté. Ce que dénonçait Stallman est donc plus que jamais d’actualité : l’ouverture des code sources ne peut justifier à elle seule un design des programmes soutenable. Il est fondamental de prendre en compte le dessein des programmes, ce qu’il font à notre insu. L’ouverture, condition nécessaire d’une possible liberté, n’est en rien synonyme de franchise ou de modification possible du programme. Autrement dit : dissocier le design des programmes de la recherche d’un rendement nous permet de d’envisager un type de projet travaillant et manifestant ses visées et conditions d’effectuation. Vers la fin de son article, Eric Raymond esquisse une idée qui nous semble importante à discuter :

Tout outil doit être utile par rapport aux utilisations qu’il a été prévu d’en faire. Mais on reconnaît un outil vraiment excellent au fait qu’il se prête à des usages totalement insoupçonnés⁷²⁹.

Au vu de nos analyses précédentes, nous pouvons comprendre ce qui pose problème dans cette formulation. Les programmes ne sont pas des « outils », mais des systèmes pouvant disposer des utilisateurs, même s’ils s’exposent d’une façon a priori transparente et ouverte. Tout comme Stallman nous mettait en garde à propos du fait d’appliquer trop vite le vocabulaire du champ informatique à d’autres domaines, il nous semble peu pertinent d’opérer le mouvement inverse. Les environnements numériques posent des questions qui leur sont propres. La pensée d’outils neutres qu’il s’agirait d’utiliser correctement est contestée par tout ce que ces objets charrient de survivances historiques et de normes sociales. Pour reprendre des termes de Simondon, le designer peut avoir comme rôle de découvrir le « centre actif de l’opération technique ». La pensée de la forme n’est pas séparable de sa dimension technique. La connexion entre la matière et la forme doit porter attention, nous dit Simondon à la « condition d’exécution » de la forme, à « la prise de forme en tant qu’opération » :

Quand l’homme n’intervient plus comme porteur d’outils, il ne peut laisser dans l’obscurité le centre de l’opération ; c’est en effet ce centre qui doit être produit par l’objet technique, qui ne pense pas, qui ne sent pas, qui ne contracte pas d’habitudes. Pour construire l’objet technique, l’homme a besoin de se représenter le fonctionnement qui coïncide avec l’opération technique, qui l’accomplit⁷³⁰.

L’accès aux sources d’un programme n’est pas synonyme de leur compréhension effective. Il reste un travail à opérer, et nous pensons qu’il peut s’agir d’une responsabilité du designer. Au « bazar » autorégulateur d’Eric Raymond, nous pouvons opposer ce que disait Ted Nelson à propos de sa vision prospective des environnements numériques :

J’espère que, dans nos futurs archives et centres de stockages, nous n’autoriserons pas la propension régulatrice et classificatrice des techos à se superposer au grouillant et fantastique désordre de l’existence humaine⁷³¹.

Richard Stallman nous permet de penser une façon de faire du numérique qui est d’emblée de l’ordre du contournement. Ces types de programme ne sont, littéralement, pas attendus. Personne n’attendait Linux, Firefox ou Wikipedia. Plus encore, leurs « utilisations » ne sont pas systématiquement prévues en amont. Ces exemples de projet montrent que la liberté d’un projet peut passer avant la notion d’utilité. Nous pouvons donc reconsidérer la formuler d’Eric Raymond suivant laquelle « on reconnaît un outil vraiment excellent au fait qu’il se prête à des usages totalement insoupçonnés⁷³² ». En dépassant la primauté habituellement accordée à la notion d’usage, nous pouvons comprendre que ce qui est pertinent dans le design n’est pas uniquement ce qui contourne une norme, ce qui déjoue un attendu ou un donné. Autrement dit : nous intéressent des situations d’exercice dans lesquelles il est compliqué de ne pas faire de choix, des situations faisant place au « fantastique désordre de l’existence humaine⁷³³ ».