La « Commons Clause » de Redis : une mauvaise réponse à de vraies questions ?
– S.I.Lex – - calimaq, 26/08/2018
La semaine dernière a été marquée par une polémique qui a traversé la communauté de l’Open Source. Elle a pour origine la décision de la société américaine Redis Labs, spécialisée dans les solutions de gestion de bases de données, de modifier la licence sous laquelle elle propose certains des logiciels qu’elle développe. Utilisant jusqu’alors une licence très ouverte (BSD), elle a opté pour une autre licence libre (Apache), mais – et c’est ce qui a fait débat – en lui adjoignant une clause supplémentaire dite « Commons Clause », destinée à protéger ses intérêts commerciaux.
Voici une traduction en français de ce mécanisme :
Le Logiciel vous est fourni par le Concédant en vertu de la Licence, telle que définie ci-dessous, sous réserve de la condition suivante.
Sans restreindre les autres conditions de la Licence, l’octroi de droits en vertu de la Licence n’inclura pas, et la Licence ne vous accorde pas, le droit de vendre le Logiciel.
Aux fins de ce qui précède, « Vendre » signifie exercer tout ou partie des droits qui vous sont accordés en vertu de la Licence pour fournir à des tiers, contre rémunération ou autre contrepartie (y compris, sans limitation, les frais d’hébergement ou de services de support/conseil liés au Logiciel), un produit ou un service dont la valeur dérive, entièrement ou substantiellement, de la fonctionnalité du Logiciel.
Et voilà comment Redis Labs justifie ce changement sur son site :
Les logiciels modernes d’infrastructure Open Source ont créé plus de valeur au cours de la dernière décennie que nous n’aurions pu l’imaginer. Les bases de données, les orchestrateurs, les systèmes distribués et autres technologies logicielles alimentent désormais presque toutes les entreprises de la planète ; tout cela grâce à la philosophie collaborative et partagée de la communauté Open Source.
Cependant, les fournisseurs de cloud d’aujourd’hui ont à maintes reprises violé cette éthique en tirant parti de projets Open Source emblématiques et en les reconditionnant en offres de services concurrents et propriétaires. Ces fournisseurs de cloud contribuent très peu (voire pas du tout) à ces projets Open Source. Au lieu de cela, ils utilisent leur position monopolistique pour en tirer des centaines de millions de dollars de revenus. Déjà, ce comportement a endommagé les communautés Open Source et mis hors service certaines des entreprises qui les soutiennent.
Redis constitue un exemple de ce paradigme. Aujourd’hui, la plupart des fournisseurs de cloud computing offrent Redis en tant que service géré sur leur infrastructure et profitent d’énormes revenus provenant de logiciels qu’ils n’ont pas développés. Redis Labs mène et finance le développement de Redis Open Source et mérite de bénéficier des fruits de ces efforts. Redis est et restera toujours sous licence BSD Open Source, mais nous avons décidé d’empêcher les fournisseurs de cloud de créer des services gérés à partir de certains add-ons sur Redis (par exemple RediSearch, Redis Graph, ReJSON, Redis-ML, Rebloom). Ces derniers sont sous licence Apache 2.0 modifiée avec la « Commons Clause ».
Malaise dans l’Open Source…
En réalité, Redis Labs fait partie de ces nombreuses sociétés spécialisées dans l’Open Source qui ne commercialisent par des logiciels, mais des services associés. Elle offre sous licence libre un système de gestion de base de données que d’autres entreprises peuvent très bien reprendre, à condition de disposer de leur propre infrastructure d’hébergement. Mais pour celles qui n’ont pas ces facilités, elle propose un service payant d’hébergement basé sur cette solution, qui lui permet de réaliser son chiffre d’affaire.
Ce que critique Redis Labs, c’est que d’autres entreprises se comportent comme des « passagers clandestins » en récupérant le logiciel sans contribuer en retour à son développement, mais en fournissant des services payants qui lui font une concurrence directe. D’où la décision de garder le coeur du logiciel sous licence Open Source, mais d’ajouter une clause pour certains modules qui va empêcher dorénavant la commercialisation de services basés sur ce système. Il restera toujours possible pour d’autres entreprises de récupérer le logiciel pour leurs besoins internes, si elles sont en mesure de supporter par elles-mêmes les coûts de déploiement et d’infrastructure, mais la formule en B to B deviendra dorénavant une exclusivité de Redis Labs.
Ce changement de licence a été fraîchement accueilli par une partie de la communauté Open Source, qui lui reproche de contrevenir à ses principes fondateurs. C’est le cas par exemple du développeur Drew DeVault, qui a écrit un intéressant billet à ce sujet sur son blog, intitulé «La Commons Clause va détruire l’Open Source». Il rappelle que la première des quatre libertés du logiciel libre implique que l’on puisse faire usage du programme à n’importe quelle fin et cela implique de ne pas discriminer les utilisations commerciales. C’est ce que l’on peut lire sur le site du projet GNU, qui a historiquement défini les règles du logiciel libre :
« Logiciel libre » ne signifie pas « non commercial ». Un programme gratuit doit être disponible pour l’utilisation commerciale, le développement commercial et la distribution commerciale. Le développement commercial du logiciel libre n’est plus inhabituel ; il joue même un rôle très important. Il se peut que vous ayez payé pour obtenir des copies de logiciels libres, ou que vous ayez obtenu des copies sans frais. Mais quelle que soit la façon dont vous avez obtenu vos copies, vous avez toujours la liberté de copier et de modifier le logiciel, voire de vendre des copies.
Drew DeVault reconnaît bien que la « concurrence déloyale » exercée par les passagers clandestins dénoncés par Redis Labs constitue un problème pouvant affecter la capacité des projets Open Source à s’auto-financer et il raconte en avoir lui-même subi les frais. Mais à ses yeux, remettre en cause les principes des licences libres n’est pas une solution acceptable et il recommande plutôt de se tourner vers le financement participatif, notamment sous la forme de dons récurrents versés par le public tous les mois à un projet, qui permettent selon lui d’obtenir une certaine stabilité.
J’avoue pour ma part me sentir mal à l’aise aussi bien avec la stratégie de Redis Labs qu’avec les arguments de ses détracteurs. Les deux points de vue me paraissent en réalité refléter les contradictions qui affectent le mouvement du Libre et de l’Open Source à propos des questions économiques, et j’avais d’ailleurs déjà eu l’occasion de pointer ces difficultés dans un billet publié en juin dernier sur ce blog : « Les Communs numériques sont-ils condamnés à devenir des Communs du Capital ? »
De la difficulté à penser les logiciels comme Commun(s)
Drew Devault estime que si cette clause se répandait en étant adoptée par de nombreux projets, cela reviendrait à « détruire l’Open Source » car elle aurait pour effet de transformer les logiciels libres en « logiciels propriétaires ». On ne peut pas lui donner tort sur ce point, car cette Commons Clause ressemble en effet à la clause « Non-Commercial » des licences Creative Commons (elle a néanmoins une portée moins grande, car la Commons Clause n’interdit que la vente de la ressource, alors que le NC des Creative Commons interdit tout usage ayant pour but « la recherche d’un avantage commercial », ce qui empêcherait par exemple que des entreprises réutilisent simplement le logiciel en interne). J’ai déjà eu l’occasion de dire, il y a quelques temps, que je n’étais pas opposé à l’emploi de la clause NC des Creative Commons, notamment pour les oeuvres culturelles, lorsque c’est un moyen pour les créateurs de mettre en place un modèle économique viable. Mais en matière de logiciels, les choses sont relativement différentes, car il existe à présent un écosystème économique robuste, avec des formules diversifiées ayant fait leurs preuves sans passer par le NC. A ce titre la Commons Clause marque bien un retour en arrière et c’est une résurgence problématique de la logique propriétaire. Elle revient finalement à s’appuyer sur le droit de propriété pour rétablir une exclusivité commerciale au profit d’une entreprise.
De ce point de vue, je trouve dommageable que Redis Labs ait choisi d’appeler ce mécanisme « Commons Clause », faisant par là référence à la théorie des Communs. Certes ce courant s’inscrivant dans la lignée des travaux d’Elinor Ostrom prend en compte le problème des « passagers clandestins » contre lesquels il convient de lutter pour assurer la pérennité des ressources mises en partage. Mais cette pensée est aussi basée sur une critique de l’exclusivisme propriétaire qui fait ici un retour assez brutal avec la clause ajoutée par Redis Labs. Drew Devault va jusqu’à dire que les développeurs qui ont contribué aux modules du projet Redis ont été floués et que la société leur a « volé leur travail », puisqu’elle va à présent l’enfermer dans un logiciel propriétaire. On voit donc que cette intention de lutter contre les passagers clandestins finit par déboucher sur une forme d’enclosure du Commun, ce qui est contradictoire.
D’un autre côté, la réaction des tenants de la tradition de l’Open Source ne me paraît pas non plus satisfaisante, notamment leur manière de s’accrocher au dogme de la non-discrimination des usages commerciaux. C’est d’ailleurs un problème affectant de manière bien plus large la sphère des logiciels libres et Open Source, qui ont dans leur grande majorité soit du mal à dégager par eux-mêmes les moyens nécessaires pour s’auto-financer, soit des liens de dépendance économique avec des firmes capitalistes sans lesquels ils ne pourraient assurer leur pérennité. Si l’on reprend le cas de Redis, il faudrait idéalement que les entreprises de cloud computing consacrent des moyens pour contribuer en retour au développement de son logiciel, ce qui est par exemple la situation de Linux. Mais cette configuration soulève elle aussi des questions dans la mesure où elle transforme les logiciels libres en des « Communs du Capital », placés dans la dépendance d’entreprises dont le comportement peut par ailleurs poser question. On peut par exemple se féliciter qu’IBM, Google, Facebook ou même Microsoft soient devenus des contributeurs importants à Linux, mais ces acteurs constituent aussi des incarnations du « capitalisme de surveillance » que les libristes dénoncent et combattent par ailleurs…
Il en résulte une contradiction extrêmement problématique, qui ne pourra à mon sens être levée qu’en se donnant la capacité de discriminer certains usages commerciaux parmi d’autres. On pouvait difficilement s’attendre à ce que Redis Labs procède ainsi, car cette société constitue elle-même une entreprise capitaliste tout ce qu’il y a de plus classique, dont le financement a été assuré en mode startup par des levées de fonds auprès de pourvoyeurs de capital-risque. Il était donc assez logique qu’ils choisissent de protéger leurs intérêts commerciaux en retombant dans la logique propriétaire. Mais il existe d’autres propositions de licences, qui envisagent autrement cette fameuse « Commons Clause » et dans un sens – à mon avis – bien plus compatible avec la philosophie des Communs.
Sortir de l’agnosticisme économique
C’est le cas des licences à réciprocité renforcée, dont j’ai eu l’occasion de parler à maintes reprises sur ce blog. La plus connue est la Peer Production Licence, élaborée par l’allemand Dmitry Kleiner en modifiant une licence Creative Commons CC-BY-NC-SA. Le résultat pourrait paraître à première vue assez proche de la formule « Licence Apache + Commons Clause » de Redis Labs, sauf que Kleiner n’avait pas pour but d’interdire tous les usages commerciaux, mais seulement ceux d’entreprises non-structurées sous la forme de coopératives. Son intention était de créer un pont entre la sphère du Libre et celle de l’Economie Sociale et Solidaire (ESS) pour protéger les ressources des comportements des acteurs obéissant à une logique « extractiviste ». L’idée consiste à faire en sorte que la valeur générée par les Communs ne soit pas aspirée en dehors du cercle des acteurs contribuant à leur développement pour participer à l’accumulation du capital. On voit donc que le problème n’est pas en lui-même la commercialité ou le fait d’opérer sur le marché, mais certains types de comportements économiques découlant de la nature même des acteurs.
L’enjeu pour les Communs n’est pas – comme veut le faire Redis Labs – de préserver le modèle économique d’une entreprise déterminée, mais de constituer au niveau global une « Economie des Communs » qui puisse garantir le développement et la pérennité des ressources partagées, en coupant les liens de dépendance avec les entreprises capitalistiques classiques. Le problème du « capitalisme de surveillance » réside autant dans la surveillance que dans le capitalisme lui-même, or le mouvement du Libre et de l’Open Source s’est interdit d’attaquer le fond du problème à cause de « l’agnosticisme économique » inhérent à la manière dont les quatre libertés du logiciel libre ont été formulées.
La Peer Production Licence a eu le mérite de montrer la possibilité d’une autre voie, mais il en a résulté un prototype encore imparfait. D’autres tentatives de formulation de licences à réciprocité sont actuellement en cours. La Coop des Communs propose par exemple un « Coopyright » articulé autour de l’idée de non-lucrativité ou de lucrativité limitée, qui permet d’atteindre un résultat assez similaire à la Peer Production Licence, mais en embrassant l’ensemble des structures ESS et pas seulement les coopératives. Une autre piste à surveiller est celle du projet CoopCycle qui va bientôt proposer une licence à réciprocité adaptée au logiciel. Visant à lutter contre l’ubérisation en proposant une alternative éthique à des sociétés comme Deliveroo, CoopCycle doit nécessairement se donner les moyens de discriminer entre les acteurs commerciaux comme ils l’expliquent dans ce billet (« Comment protéger les logiciels libres contre la prédation capitalistique ?« ) :
Si Wikipedia prouve que les licences libres sont tout à fait compatibles avec la gestion en Commun, l’objectif politique ne l’est pas. En effet, vous conviendrez qu’il serait paradoxal de développer un logiciel dans le but d’offrir une alternative aux géants de la foodtech, plus responsable socialement, et dans le même temps de laisser se développer des entreprises beaucoup moins scrupuleuses quant au statut et à la protection sociale de leurs livreurs sur la base de ce même logiciel. C’est pourquoi aujourd’hui, toute la problématique à laquelle nous cherchons à répondre est celle de la licence adéquate pour concilier les grands idéaux du mouvement libriste avec cette exigence de responsabilité sociale.
***
Voilà précisément ce qu’il manque à la Commons Clause de Redis Labs pour mériter réellement son nom : un lien assumé avec la transformation sociale et la responsabilité sociale, associé à une vision économique claire capable de distinguer chez un acteur marchand un comportement prédateur d’un comportement génératif. On peut donc dire au final que la Commons Clause constitue une mauvaise réponse à de bonnes questions. L’erreur de Redis Labs est de prétendre faire du Commun en ne prenant en compte que la protection de son propre modèle économique, sans voir que l’enjeu véritable n’est pas microéconomique mais macroéconomique. Il consiste à mettre fin aux liens de dépendance qui font encore trop souvent des Communs numériques de simples pseudopodes du Capital participants à sa reproduction, là où l’urgence absolue consiste à se donner les moyens d’en sortir.