Redis change de licence : le point sur la situation

Dans l’écosystème NoSQL, à qui le tour de changer de licence ?

MongoDB l’avait fait en 2018. Il avait abandonné AGPL pour son édition Community Server, au profit d’une licence créée par ses soins : SSPL.
En 2021, ce fut au tour d’Elasticsearch, passé d’Apache 2.0 à un système « à la carte » associant SSPL et une licence maison.

Redis a choisi la même approche qu’Elastic. Elle s’applique à partir de la version 7.4, publiée il y a quelques semaines. Exit la licence BSD 3 clauses. Place au duo SSPL–RSALv2 (Redis Source Available License). Ni l’une ni l’autre ne sont open source au sens de l’OSI.

Deux licences, une cible

Permissive, la licence BSD autorise, dans les grandes lignes, à utiliser Redis sans payer.

RSALv2 permet aussi la copie, la distribution, la création de dérivés et la mise à disposition de tiers, mais interdit toute commercialisation ou fourniture en tant que service managé.

SSPL lève cette barrière, mais impose à quiconque propose à des tiers un programme en tant que service d’ouvrir gratuitement le code source de son implémentation. L’obligation d’ouverture ne se limite donc pas audit service. Elle englobe tous les éléments sur lequel il repose : interfaces de gestion, automatisations, stockage, hébergement, etc. Assez pour qu’un utilisateur puisse exécuter sa propre instance.

Cette clause différencie SSPL de sa « licence mère », à savoir AGPL.
Cette dernière avait elle-même étendu les dispositions de la licence GPL en imposant la fourniture du code source à quiconque communique le code exécutable d’un programme par voie de réseau. Grafana Labs l’avait adoptée en 2021 pour l’essentiel du code de Grafana, Loki et Tempo. Dans sa ligne de mire comme dans celle de Redis*, les cloud providers.

Le système de double licence n’est pas nouveau chez Redis. Il s’appliquait déjà à certains modules, notamment ceux livrés dans le cadre du package Redis Stack.
Ce  package est amené à fusionner avec le cœur de Redis, puisque celui-ci passe sous le même régime de licence. Cela interviendra avec la publication de Redis 8.

Redis change sa politique de marque

Les bibliothèques clientes et les providers placés sous la responsabilité de Redis resteront open source. L’éditeur s’engage par ailleurs à rétroporter les correctifs de sécurité critiques jusqu’à la sortie de Redis 9.0 (la double licence s’appliquera ensuite).

Les CSP hébergeant des offres fondées sur Redis 7.4 ou toute version ultérieure doivent désormais négocier une licence commerciale.
Pour les contributeurs au projet, les choses changent aussi : il faut maintenant signer un CLA.

En parallèle, les conditions d’utilisation de la marque Redis évoluent : interdit de l’exploiter dans le nom d’un produit. On ne peut l’intégrer que dans les descriptions ou bien spécifier qu’un produit est « compatible Redis » ou « basé sur Redis legacy » (sous-entendu, open source).

La double licence n’est pas rétroactive. Y compris pour qui proposerait un produit que Redis viendrait ultérieurement concurrencer. En tout cas aussi longtemps que le produit en question utilise une version publiée avant l’offre de Redis.

On surveillera l’émergence d’éventuels forks, à l’instar de KeyDB (made in Snap : licence BSD). On se préparera aussi à une possible éviction de Redis sur les dépôts des distributions Linux. Le sujet est sur la table dans les communautés Fedora et openSUSE, par exemple.

* HashiCorp a aussi changé de braquet. En 2023, il a abandonné la licence MFL pour Terraform, au profit de BSL, déjà adopté entre autres par Couchbase et Cockroach Labs. Conséquence : l’interdiction d’embarquer ou d’héberger l’édition communautaire de l’outil dans le cadre de toute offre concurrente destinée à un usage en production.

Illustration © agsandrew – Shutterstock