Les services en ligne ne sont ni libres ni privateurs ; ils posent d'autres problèmes

par Richard Stallman

Pour les programmes, nous établissons une distinction entre libre et non libre (privateur, ou propriétaire). Plus précisément, cette distinction s'applique à un programme dont vous avez une copie : soit vous disposez des quatre libertés, soit vous n'en disposez pas. Dans le deuxième cas, vous êtes victime d'une injustice particulière du fait que le programme est non libre.

Les détenteurs du copyright sur un programme non libre peuvent réparer cette injustice d'une manière simple et claire : en publiant son code source sous une licence de logiciel libre. Il peut être très difficile de les convaincre de le faire, mais cette action est en soi très facile à effectuer.

Une activité (un service, par exemple) n'existe pas sous forme de copies. Il n'est donc pas possible pour un utilisateur d'en posséder une, a fortiori d'en faire d'autres. Il ne peut pas non plus faire de modification puisqu'il n'a pas de copie à modifier. Ainsi, les quatre libertés qui définissent le logiciel libre n'ont pas de sens pour les services. Il est donc absurde de dire qu'un service est « non libre », ou bien qu'il est « libre ». Cette distinction n'a aucun sens pour les services.

Cela ne veut pas dire que le service traite les utilisateurs avec équité. Au contraire, de nombreux services nuisent à leurs utilisateurs, c'est pourquoi nous les appelons « dé-services ». Mais il n'y a pas dans ce cas de remède simple et universel, comparable à ce qui existe pour un programme non libre (à savoir, le publier en tant que logiciel libre pour que les utilisateurs puissent exécuter leur propre copie et leur propre version du logiciel, et ainsi en avoir le contrôle.

Pour utiliser une analogie culinaire, même si j'ai appris à cuisiner en vous regardant, ma façon de cuisiner ne peut pas être une copie de la vôtre. Il se peut que j'aie une copie de la recette que vous utilisez pour cuisiner et que je m'en serve, car les recettes sont, comme les programmes, des œuvres qui peuvent exister en plusieurs exemplaires. Mais la recette et la manière de cuisiner sont deux choses différentes (et les plats obtenus en sont une troisième).

Avec la technologie actuelle, les services sont souvent implémentés en faisant tourner des programmes sur des ordinateurs mais ce n'est pas le seul moyen (en fait, il existe des services en ligne qui sont implémentés en demandant à des êtres humains en chair et en os de saisir des réponses à des questions). Dans tous les cas, l'implémentation n'est pas visible par les utilisateurs du service, donc cela n'a aucun impact sur eux.

Un service en ligne peut poser aux utilisateurs le problème du recours à un logiciel libre ou non libre, par le biais du client requis pour l'utiliser. Si le service nécessite l'utilisation d'un programme client non libre, y recourir suppose que vous cédiez votre liberté à ce programme. Pour beaucoup de services web, ce logiciel non libre est du code JavaScript, installé discrètement dans le navigateur de l'utilisateur. Le programme GNU LibreJS permet de refuser facilement d'exécuter ce code JavaScript non libre. Mais le problème du logiciel client est selon toute logique distinct de celui du service lui-même.

Il existe un cas où un service est directement comparable à un programme : celui où l'utilisation de ce service revient à avoir une copie d'un programme hypothétique et à l'exécuter soi-même. On appelle cela « service se substituant au logiciel », ou SaaSS (nous avons inventé cette expression parce qu'elle est moins vague et moins générale que « logiciel en tant que service »), et c'est toujours une mauvaise opération. Les tâches qu'effectue ce service appartiennent en propre aux utilisateurs, ces derniers devraient donc en avoir le contrôle total. Pour les utilisateurs, le seul moyen d'être aux commandes de leur informatique est d'effectuer leurs travaux avec leurs propres copies de programmes libres. Les faire avec le serveur de quelqu'un d'autre implique d'en perdre le contrôle.

Recourir au SaaSS revient à utiliser un programme non libre avec des fonctionnalités de surveillance et une porte dérobée [backdoor] universelle. Donc vous devez le refuser, et le remplacer par un logiciel libre qui fait la même chose.

En revanche, les fonctions principales de la plupart des services sont de communiquer et de publier des informations. Ils n'ont rien de commun avec l'exécution locale d'un quelconque programme et ne constituent donc pas du SaaSS. Ils ne peuvent pas non plus être remplacés par votre copie d'un programme, car un programme s'exécutant sur vos propres ordinateurs, utilisé uniquement par vous et isolé des autres, ne communique pas avec quiconque.

Un service non SaaSS peut nuire à ses utilisateurs en faisant quelquechose de particulier qui soit injuste pour l'utilisateur. Par exemple, il peut faire un mauvais usage des données qu'on lui envoie, ou collecter trop de données (surveillance). Il peut être conçu pour induire en erreur ou tromper l'utilisateur (par exemple au moyen d'interfaces truquées [dark patterns]). Il peut imposer des conditions d'utilisation antisociales ou injustes. Le Franklin Street Statement¹ a tenté d'aborder cette question, mais nous n'en avons pas une compréhension complète pour le moment. Ce qui est clair, c'est que les problèmes liés aux services sont différents de ceux qui concernent les programmes. Ainsi, par souci de clarté, il est préférable de ne pas appliquer les termes « libre » et « non libre » à un service.

Supposons qu'un service soit fourni par le biais d'un logiciel : l'opérateur du serveur a des copies de nombreux programmes et les exécute pour fournir le service. Ces copies peuvent être des logiciels libres, ou non. Si c'est l'opérateur qui a développé les programmes et qu'il les utilise sans en distribuer de copie, alors ils sont libres (sans que cela signifie grand-chose) puisque tout utilisateur (il n'y en a qu'un) détient les quatre libertés.

Si certains programmes ne sont pas libres, cela n'affectera pas directement les utilisateurs du service. Ce ne sont pas eux qui exécutent ces programmes, c'est l'opérateur. Dans certaines situations bien particulières, ces programmes peuvent indirectement affecter les utilisateurs : si le service détient des informations confidentielles, ses utilisateurs peuvent s'inquiéter de la présence de portes dérobées dans les programmes non libres, permettant à d'autres d'accéder à leurs données. En fait, les programmes non libres du serveur obligent les utilisateurs à faire confiance à leurs développeurs ainsi qu'à l'opérateur du service. Le risque concret dépend de chaque cas particulier, et notamment de ce que font ces programmes non libres.

Cependant, il y a une personne qui est certainement affectée par les programmes non libres qui fournissent le service, c'est l'opérateur du serveur lui-même. Nous ne lui reprochons pas d'être à la merci de logiciels non libres, et nous n'allons certainement pas le boycotter pour ça. Au contraire, nous nous faisons du souci pour sa liberté, comme pour celle de tout utilisateur de logiciel non libre. Quand nous en avons l'occasion, nous essayons de lui expliquer qu'il met en péril sa liberté, en espérant qu'il bascule vers le logiciel libre.

Inversement, si un opérateur de service utilise GNU/Linux ou d'autres logiciels libres, vous n'êtes pas concerné par sa bonne action, c'est lui qui y trouve avantage. Nous n'allons pas l'encenser ni le remercier, simplement nous le félicitons d'avoir fait le choix le plus avisé.

S'il développe des logiciels pour son service et les publie en tant que logiciels libres, là nous avons une raison de le remercier. Nous lui suggérons de diffuser ces programmes sous la GNU AGPL (licence publique générale GNU Affero), puisqu'à l'évidence ils sont utiles sur des serveurs.

Pourquoi la GPL Affero ?

Ainsi, nous n'avons pas de règle disant que des systèmes libres ne doivent pas utiliser (ou s'appuyer sur) des services (ou des sites) mis en œuvre au moyen de logiciel non libre. Cependant, ils ne doivent pas dépendre de services de type SaaSS, ni inciter à les utiliser. Il faut remplacer l'utilisation de SaaSS par l'utilisation de logiciel libre. Et, toutes choses égales par ailleurs, il est préférable de privilégier les fournisseurs de service qui apportent leur contribution à la communauté en publiant des logiciels libres utiles. Il est également souhaitable de privilégier les architectures pair-à-pair plutôt que les communications centralisées reposant sur un serveur, pour les activités qui, par nature, ne nécessitent pas de plateforme centrale.