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

Facebook est-il « libre » ? Gmail est-il « libre » ? Le nébuleux « cloud computing » est-il « libre » ?

Lorsqu’il s’agit de services en ligne la question est mal posée et mérite d’être précisée, nous affirme ici Richard Stallman en passant en revue les différents et complexes cas de figure^[1].

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

URL d’origine du document (GNU.org)

Richard Stallman - version du 15 mai 2012 - Gnu.org - Creative Commons By-Nd
(Traduction : Céline Libéral, Mathieu Adoutte, Caner et Goofy, pour Framalang)

Les programmes et les services sont deux choses différentes. Un programme est une œuvre que vous pouvez exécuter, un service est une activité avec laquelle vous pouvez interagir.

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.

Une activité (telle qu’un service) n’existe pas sous forme de copies. Il n’est donc pas possible d’en avoir une ni d’en faire. Ainsi, les quatre libertés qui définissent un logiciel libre n’ont pas de sens pour les services.

Pour utiliser une analogie culinaire, même si j’ai appris à cuisiner en vous regardant, ma cuisine 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, comme les programmes, sont 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, recourir à ce service suppose que vous abandonniez 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ù le service revient à avoir une copie d’un programme donné et à l’exécuter vous-même. On appelle cela SaaS, ou « logiciel en tant que service », et un tel service constitue toujours une régression au plan éthique. Si vous disposiez du programme équivalent, vous auriez le contrôle sur votre informatique, à supposer que le programme soit libre. Mais lorsque vous utilisez le service de quelqu’un d’autre pour faire la même chose, vous ne contrôlez plus rien.

Recourir au SaaS revient à utiliser un programme non libre avec des fonctionnalités de surveillance et une porte dérobée (backdoor) universelle. Donc vous devriez 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 en commun avec un logiciel que vous exécuteriez vous-même, ce ne sont donc pas du SaaS. 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, n’est pas suffisant en lui-même pour communiquer avec d’autres personnes.

Les services non SaaS peuvent nuire à leurs utilisateurs d’autres manières. Les problèmes qui leur sont liés peuvent être aussi bien la mauvaise utilisation des données que vous leur avez envoyées, que la collecte d’autres données (surveillance). Le Franklin Street Statement^[2] a tenté d’aborder cette question, mais nous n’avons pas de position bien établie 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, ce n’est pas une bonne action, c’est tout simplement dans son intérêt. Nous n’allons pas l’encenser, ni le remercier, simplement nous le félicitons d’avoir fait le choix le plus avisé. S’il publie certains de ses logiciels libres, contribuant ainsi à faire avancer la communauté, là nous avons une raison de le remercier. Nous lui suggérons de diffuser ces programmes sous la GNU Affero GPL (Licence publique générale Affero de GNU), puisqu’ils sont destinés à des serveurs.

Pourquoi la GPL Affero ?

Ainsi, nous n’avons pas de règle qui dise que des systèmes libres ne devraient pas utiliser (ou s’appuyer sur) des services (ou des sites) fournis par le biais de logiciels non libres. Cependant, ils ne devraient pas dépendre de services de type SaaS, ni inciter à les utiliser. Les Saas doivent être remplacés par des logiciels libres. 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.