URL: https://linuxfr.org/news/virevoltantes-valses-de-licences-libres-et-non-libres-dans-les-bases-de-donnees Title: Virevoltantes valses de licences libres et non libres dans les bases de données Authors: Benoît Sibaud bubar et Ysabeau Date: 2021-02-02T16:06:58+01:00 License: CC By-SA Tags: sspl, elasticsearch, elastic, kibana, mariadb, redis et mongodb Score: 3 Sur les cinq dernières années, nous avons assisté un ballet impressionnant de changements de licences dans les « bases de données » (au sens large ici) libres (SQL ou NoSQL) : on parle ici de MariaDB (base relationnelle), Elasticsearch (moteur de recherche)/Kibana (visualisation de données), MongoDB (base orientée documents), Redis (base clé valeur), Confluent (gestion d’événements), CockroachDB (SQL distribué), Graylog (gestion de journaux système), et j’en oublie peut-être. # La trame Les entreprises qui éditent ces bases se voient attaquer dans leur modèle (double licence libre et payante, _open core_, service, etc.). Selon ces entreprises, d’autres acteurs leur taillent des croupières, leur piquent leur chiffre d’affaires, se placent en intermédiaires captant la valeur, souvent avec une approche « base de données à la demande » de type opérateur d’infrastructure de cloud (mais ça pourrait aussi être un simple intégrateur de solution), et le tout sans contribuer. Et souvent la solution retenue pour stopper ce qui est perçu comme une dérive est un changement de licence, vers une licence non-libre, respectant généralement les critères suivant : - le code est visible / disponible (on part quand même d’une solution libre/open source, si le code n’était pas visible le changement serait brutal) - « ça change rien pour toi utilisateur final » (soit tu ne payais pas et c’est encore le cas, soit tu payais déjà (pour le service, le support, etc.) et ça va continuer identiquement) - il est interdit de faire du « à la demande » ---- [Are open source databases dead?](https://www.zdnet.com/article/are-open-source-databases-dead/) [La bataille entre vrai open source et faux open source s'intensifie](https://www.zdnet.fr/actualites/la-bataille-entre-vrai-open-source-et-faux-open-source-s-intensifie-39881007.htm) ---- # Chronologie Accrochez-vous, il y a des antépisodes/_prequels_, plein de personnages, différentes saisons, des rebondissements, etc. - septembre 2016 : MariaDB [commence à utiliser](https://mariadb.org/mariadb-true-open-source-project/) la [Business Source License (BSL)](https://mariadb.com/bsl11/) pour certains de ses projets. D’abord la version 1.0, puis [plus tard](https://mariadb.com/projects-using-bsl-11/) la version 1.1 [revue par Bruce Perens](https://perens.com/2017/02/14/bsl-1-1/) (fondateur de l’Open Source Initiative, c’est important parce que tous les acteurs qui suivent vont vous le rappeler chaque fois qu’ils parlent de la BSL). - février 2018 : Elastic annonce l’ouverture (voir le _nota bene_ plus loin) de son composant de sécurité X-Pack [Doubling Down on Open](https://www.elastic.co/blog/doubling-down-on-open) (« on double la mise sur l’ouverture/l’open(source) » : « _As we look to the future, we saw an opportunity to double down on our belief in openness in even more fundamental ways, while introducing a new, more efficient model for building a successful, sustainable business around Open Source._ » en résumé Elastic se lance dans un modèle économique pérenne et à succès autour du l’Open Source. Nb: concernant X-Pack, on parle d’ouverture en termes de code visible, pas sous licence libre. Ce qu’Elastic précise clairement : « _As of 6.3, the X-Pack code is open under the Elastic License. However, it will not be 'open source' as it will not be covered by an OSI approved license._ » [dépêche Elastic inclura X-Pack dans sa distribution](https://linuxfr.org/news/elastic-inclura-x-pack-dans-sa-distribution) - avril 2018 : Elastic proclame « OSSFL: open source software for life » « We believe in open source, and our investment in it will continue unchanged. […] We're not taking away any Apache 2.0 code — we're doubling down on open. » ([source](https://www.elastic.co/what-is/open-x-pack)). Traductions possibles : « OSSFL: logiciel open source pour la vie » « Nous croyons à l’open source et notre investissement dedans restera inchangé. […] Nous ne retirons pas de code Apache 2.0 – nous redoublons (d’effort) dans l’ouvert/open » - 16 octobre 2018 : MongoDB Inc. [annonce sa Server Side Public License (SSPL)](https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server), en raison de la concurrence de « certaines organisations » qui ne « joueraient pas le jeu ». Journal LinuxFr.org [SSPL: All your service are belong to us](https://linuxfr.org/users/spack/journaux/sspl-all-your-service-are-belong-to-us). Il y a beaucoup de discussions dans les communautés. MongoDb Inc. va soumettre sa licence à l’Open Source Initiative, puis retirera sa demande en 2019. On en déduit que la licence n’est pas _Open Source_ (et ce point sera [explicitement précisé](https://opensource.org/node/1099) par l’OSI en janvier 2021, suite à l’annonce d’Elastic, avec un « _The SSPL is Not an Open Source License_ » et en parlant de « fauxpen source ») - octobre 2018 : Redis passe ses modules sous Common Clause : voir les articles de presse [Redis Labs and Common Clause attacked where it hurts: With open-source code](https://www.zdnet.com/article/redis-labs-and-common-clause-attacked-where-it-hurts-with-open-source-code/), [Why Redis Labs made a huge mistake when it changed its open source licensing strategy](https://www.techrepublic.com/article/why-redis-labs-made-a-huge-mistake-when-it-changed-its-open-source-licensing-strategy/) - décembre 2018 : Confluent Platform [passe](https://www.confluent.io/blog/license-changes-confluent-platform/) de l’Apache Public License (APL) v2 à la non-libre Confluent Community License - MongoDB se fait virer des distributions : janvier 2019 [pas de MongoDB dans Debian et RedHat](https://linuxfr.org/users/computingfroggy/liens/pas-de-mongodb-dans-debian-et-redhat), avril 2019 [Fedora 30 bêta sans MongoDB](https://linuxfr.org/news/fedora-30-beta-est-la), juillet 2020 [perl sans pilote officiel MongoDB](https://linuxfr.org/news/sortie-de-perl-5-32-0), etc. - février 2019 : finalement Redis passe ses modules sous [Redis Source Available License (RSAL)](https://www.zdnet.com/article/redis-labs-drops-commons-clause-for-a-new-license/) - février 2019 : journal [Elasticsearch préforké](https://linuxfr.org/users/devnewton/liens/elastic-search-preforke) : Amazon annonce OpenDistro un fork (plutôt) hostile d’ElasticSearch dans sa version sous licence Apache-2 - 12 mars 2019 : réaction d’Elastic [On “Open” Distros, Open Source, and Building a Company](https://www.elastic.co/blog/on-open-distros-open-source-and-building-a-company) « We believe in open source, and the power it brings. » « Our level of investment in open source since then has only increased » évidemment très mécontent d’Amazon, mais affirmant son investissement dans l’_open source_ - juin 2019 : CockroachDB [annonce](https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/) son changement de licence, passant de l’APLv2 à la non-libre Business Source License (BSL) et après 3 ans plus tard le code finit en APLv2 - 16 novembre 2020 : [Graylog v4.0 et suivante seront sous SSPL](https://www.graylog.org/post/graylog-v4-0-licensing-sspl) (précédemment sous GPL) - 14 janvier 2021: [Coup double en matière d’ouverture, partie 2](https://www.elastic.co/fr/blog/licensing-change), évoqué dans ce [journal LinuxFr.org](https://linuxfr.org/users/oumph/liens/elasticsearch-et-kibana-passent-de-aplv2-a-sspl-a-partir-de-la-7-11) : Elastic annonce qu’à partir de la version 7.11, Elasticsearch et Kibana passeront sous _Server Side Public License (SSPL)_ (disparition de la Apache Public License (APL) v2) et leur licence propriétaire pré-existante Elastic License. La raison évoquée est la concurrence de gros fournisseurs de _cloud_ à leur offre d’Elasticsearch/Kibana à la demande, qui ne génère pas suffisamment de retombées financières, ou en code, pour Elastic. Elastic annonce faire comme MongoDB. - réaction des utilisateurs, suite à l’annonce de la disparition de la licence libre / _open source_ APLv2, ou en général pour leur modèle économique - 19 janvier 2021 : prévisions ajoutées par Elastic [Explications sur le changement de licence](https://www.elastic.co/fr/blog/license-change-clarification) sur les différentes licences (avec une discussion annexe autour d’une autre licence « Business Source License »). Et [Amazon : INACCEPTABLE - pourquoi nous avons dû changer de licence pour Elastic](https://www.elastic.co/fr/blog/why-license-change-AWS), le concurrent est nommé (on le savait déjà, le différend date depuis des années) - 21 janvier 2021 : [Stepping up for a truly open source Elasticsearch](https://aws.amazon.com/fr/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/) : Amazon relance sur son fork d’Elasticsearch. ([AWS fork Elastic Search qui n’est plus sous licence Apache](https://linuxfr.org/users/linkdd/liens/aws-fork-elastic-search-qui-n-est-plus-sous-licence-apache) - 25 janvier 2021 : [Open source : AWS riposte face à Elastic et crée un fork d’Elasticsearch ](https://www.zdnet.fr/actualites/open-source-aws-riposte-face-a-elastic-et-cree-un-fork-d-elasticsearch-39916773.htm) revient sur le sujet, mais annonce aussi que d’autres veulent faire pareil : la « société de surveillance du cloud, Logz.io, et certains partenaires » voudraient une « distribution open source pour Elasticsearch et Kibana » sous pilotage ASF (Apache Software Foundation) ou CNCF(Cloud Native Computing Foundation) par exemple. - 2 février 2021 : nouvelle annonce [Introducing Elastic License v2, simplified and more permissive; SSPL remains an option](https://www.elastic.co/fr/blog/elastic-license-v2) - (à suivre) # Exemple : le modèle de licence d’Elasticsearch / Kibana Depuis la version 6.3.0 d’Elasticsearch et de Kibana (et a priori jusqu’à la version 7.11.0), des paquets _elasticsearch-oss_ et _kibana-oss_ dit Open Source sont fournis, dans des dépôts séparés. On y trouve les versions sous licence APLv2. Il existe par ailleurs des paquets _elasticsearch_ et _kibana_, qui sont sous licence non-libre Elastic, et que l’on peut utiliser soit gratuitement (fonctionnalités étiquetées _Basic_) ou en payant (l’ensemble des fonctionnalités, le choix dit _Gold+_). Avec la 7.11, on devrait avoir, suivant l’annonce du 14 janvier : SSPL pour l’ancienne partie sous APLv2, et toujours _Basic_ et _Gold+_ sous licence Elastic. Et plus tard, suivant l’annonce du 2 février : SSPL pour l’ancienne partie sous APLv2 et _Basic_, et Elastic v2 pour la partie _Gold+_. # « En quoi ça me concerne ? » « En quoi ça me concerne ? » peut-on se demander. Tout dépend (prenons le cas Elastic) : - vous êtes un libriste convaincu, alors ces deux logiciels ne seront plus sous une licence libre (chez Elastic). À vous de voir si vous voulez bifurquer/_forker_ depuis la dernière version libre. Ou même si vous aurez des problèmes en tant que simple utilisateur, si jamais ces logiciels sont retirés des distributions ou des bibliothèques standards des langages (cf MongoDB) ; - vous vous fichez de tout ça, vous voulez juste un logiciel qui fait toujours le job à court terme : en dehors du retrait éventuel des distributions et des langages, a priori, ça ne devrait rien changer pour vous. Au pire vous allez utiliser les dépôts des éditeurs pour vous fournir en paquets (c’est déjà le cas chez Elastic par exemple). Et à court terme rien ne devrait changer. Je serais plus inquiet pour la suite, mais c’est sûrement parce que je m’intéresse aux questions politiques ou techniques à plus long terme ; - vous attendez de voir ? Ça bouge tellement visiblement, si ça se trouve le problème sera réglé dans un mois (en plus la première version sous SSPL n’est même pas encore sortie). C’est une option. Sans garantie ; - vous êtes une entreprise qui utilise une ou plusieurs de ces bases : alors comme pour tous les logiciels, vous vous posez des questions sur leur pérennité, votre dépendance à un éditeur, les fonctionnalités, la sécurité, le coût, etc. Déjà vous avez gagné le droit de tout réévaluer (super), et ensuite la réponse va dépendre de vos critères (ça vous avance pas beaucoup comme réponse). Bref à vous de voir si vous partez à la recherche d’une autre solution (concurrent, fork, etc.) ; - aucune licence existante ou modèle économique existant ne marche, et vous avez LA solution, une nouvelle licence ou un nouveau modèle. Je serais tenté de vous dire de vous abstenir… Mais bon sait-on jamais ; - vous n’utilisez pas ses bases. OK mais c’est un bon sujet de débat pour les communautés techniques, pour les communautés FLOSS, pour les décideurs et les fans d’économique et d’entrepreneuriat aussi (et si vous lisez LinuxFr.org, au moins un de ces thèmes doit vous intéresser un minimum) ; - votre business c’est de vendre de la base à la demande ? Ah, vous êtes directement concerné alors. Vous pouvez vous plonger dans une profonde introspection pour savoir si vous êtes un bon contributeur du monde du logiciel libre (ne rigolez pas), ou forker de façon hostile de façon soit pérenne soit tant que ça dure (vous n’avez peut-être pas vraiment les compétences pour faire évoluer le produit en fait) ; - vous écrivez des dépêches pour couvrir le sujet ? Vous pourriez avoir besoin d’une base de données pour suivre tout cela tellement il y a d’annonces. Et il vous faudra bien par exemple un MariaDB et un Redis pour faire tourner un LinuxFr.org. ; - probablement d’autres situations que j’ai oubliées, et qui seront évoquées et débattues dans les commentaires. # Conclusion Justement non, il ne semble pas y avoir de conclusions, juste une longue succession d’événements, suivis de commentaires divers et variés. Bataille d’acteurs, guerre de mots, affrontements des modèles économiques : il suffit de lire les titres des articles de presse (liés à cette dépêche) pour comprendre les turbulences traversées « Are open source databases dead? » et « La bataille entre vrai open source et faux open source s’intensifie », et en les parcourant, on trouvera bien des commentaires tranchés. J’aurais dû titrer « pandémie de licences et de commentaires : on cherche encore un vaccin ».