Microsoft place DocumentDB sous l’égide de la Linux Foundation
Humongous DB
Microsoft, qui avait déjà rendu sa base de données documentaire DocumentDB open source en début d'année, annonce en confier les rênes à la Linux Foundation. L'éditeur justifie ce changement de gouvernance par la volonté affichée de faire émerger un nouveau standard sur le marché tout en garantissant la compatibilité avec MongoDB.
Le 26 août 2025 à 16h30
4 min
Logiciel
Logiciel
Microsoft avait déjà frappé un premier coup en début d'année, avec la publication des sources de DocumentDB sous licence MIT, considérée comme l'une des plus permissives du monde libre. En cette fin d'été, l'éditeur de Redmond enfonce le clou : il transfère la gouvernance de DocumentDB à la Linux Foundation, qui en présidera donc désormais la destinée, avec l'objectif affiché d'en faire un nouveau standard de marché.
Alliance autour d'un possible futur standard NoSQL
« DocumentDB comble une lacune critique dans l'écosystème des bases de données documentaires, attirant contributeurs, utilisateurs et défenseurs. Plus intéressant encore, il offre un standard ouvert pour les applications documentaires, à l'instar de SQL pour les bases de données relationnelles », salue Jim Zemlin, directeur de la Linux Foundation. L'organisation, qui fédère pour mémoire de nombreux projets open source, s'engage à poursuivre le développement de DocumentDB sous la forme d'un outil indépendant, toujours pensé comme une extension de PostgreSQL et toujours pleinement compatible avec les outils et pilotes MongoDB.
« Ce qui a commencé comme une paire d'extensions Postgres a rapidement évolué vers une base de données de documents complète et conviviale pour les développeurs », fait de son côté valoir Microsoft, qui se félicite que son mouvement d'ouverture, initié en début d'année, ait déjà permis au projet d'enregistrer de nombreux forks et près de 2 000 étoiles sur GitHub.
Outre Microsoft, qui reste bien sûr impliqué dans le projet, la fondation indique avoir reçu le soutien de nombreux acteurs du logiciel, à commencer par celui d'Amazon Web Services (AWS), qui s'engage à participer au futur comité de pilotage technique, sans pour autant mettre en pause son propre projet, Amazon DocumentDB.
« Bien que le projet DocumentDB, piloté par la Fondation Linux, porte un nom similaire à celui d'Amazon DocumentDB, ils s'appuient sur des logiciels différents. Amazon DocumentDB est une base de données documentaire compatible avec l'API MongoDB et développée par AWS. Le projet, piloté par la Fondation Linux, lui aussi compatible avec MongoDB, utilise un moteur open source développé comme une extension de PostgreSQL », clarifie à ce niveau Rashim Gupta, chef produit d'Amazon DocumentDB chez AWS.
Outre ces deux géants, le projet recueille également le soutien actif annoncé de Google et d'acteurs plus spécialisés comme Cockroach Labs, Rippling, SingleStore, Snowflake, Supabase, Ubicloud et Yugabyte.
Comment réagira MongoDB ?
FerretDB ne figure en revanche pas au rang des membres de ce comité de pilotage, alors que l'entreprise s'est précisément fixé pour mission de construire une alternative open source à MongoDB basée sur Postgres et DocumentDB. L'éditeur était par ailleurs explicitement mentionné comme un partenaire par Microsoft en janvier dernier. Il a en outre rebondi, le 25 août, à l'annonce de ce changement de gouvernance en annonçant le lancement de la déclinaison cloud de son offre.
Son CEO, Peter Farkas, réagit sur LinkedIn à cette actualité de façon ambivalente. S'il se félicite, bien sûr, de cette nouvelle gouvernance pour DocumentDB, il regrette aussi que FerretDB ne reçoive aucun crédit pour sa participation au développement de ce futur standard potentiel, ni aucun soutien dans l'action en justice intentée par MongoDB à son encontre (PDF). « Notre mission est plus grande que nous. Il s'agit d'éviter la dépendance vis-à-vis d'un fournisseur et d'ouvrir le marché à l'innovation, et c'est précisément ce qui se passe », salue-t-il tout de même.
Cette nouvelle dimension collaborative permettra-t-elle à DocumentDB de s'imposer comme une alternative de choix aux solutions de MongoDB ? Ajoutée à la licence MIT, elle confère au projet une caution véritablement open source dont l'éditeur américain peut plus difficilement se targuer depuis 2018 et sa décision de basculer le code de MongoDB Server vers une licence spécialement créé pour l'occasion, la Server Side Public License (SSPL). La volte-face opérée par Elastic autour de la licence d'Elasticsearch et Kibana a prouvé que la question avait son importance.
Microsoft place DocumentDB sous l’égide de la Linux Foundation
-
Alliance autour d'un possible futur standard NoSQL
-
Comment réagira MongoDB ?
Commentaires (21)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 27/08/2025 à 08h34
Le 27/08/2025 à 09h37
Laisse donc aux auteurs de logiciel la liberté de choisir ce qui se passe avec les dérivés de leur code.
Quant à ton affirmation sur Linux et sa fondation, j'en doute fort. L'Apache Software Foundation existe bien et est partie du logiciel Apache qui a une licence comparable à celle du MIT pour le point que tu soulèves. Elle soutint elles aussi un nombre significatif de projets.
C'est la qualité d'un logiciel libre qui fait son succès, pas sa licence. Par contre, celle-ci peut être un frein à son adoption comme par exemple la GPL V3.
Modifié le 27/08/2025 à 10h59
"Laisse donc aux auteurs de logiciel la liberté de choisir ce qui se passe avec les dérivés de leur code." => c'est ce que font tout les auteurs le logiciels, libre ou non. Le choix de la licence conditionne le niveau de contrôle qu'on veut garder pour sois et de libertés qu'on veut octroyer aux utilisateurs.
C'est les libertés données aux utilisateurs qui font le succès d'un logiciel libre. Sans les libertés, il peut avoir du succès sans être un logiciel libre.
Dans le contexte actuel avec des géants du cloud qui se sont illustrées par leur capacité à contourner les libertés des licences classiques pour refourguer dans du SAAS des versions propriétaires, il est évident que publier une "Document DB" sous licence MIT est une approche visant surtout à donner une technologie aux GAFAM plutôt qu'à la communauté du libre.
Le 27/08/2025 à 11h01
Le 27/08/2025 à 11h19
En plus, la licence MIT donne les 4 libertés.
Ce sont les éventuels dérivés propriétaires d'un logiciel sous licence MIT qui ne les respectent pas, mais ça tombe bien, ces logiciels ne sont plus des logiciels libres.
Répète après moi : les logiciels sous licence MIT sont des logiciels libres.
Le 27/08/2025 à 11h32
Donc critiquer la réappropriation des projets sous MIT par les "méchants acteurs privateurs", c'est aussi oublier que la MIT permet à toute une frange de logiciels libres de réutiliser ces-dits projets, ce qui ne serait pas possible autrement pour cause de licences incompatibles, la plus connu étant la famille des GPL.
Modifié le 27/08/2025 à 11h49
Le 27/08/2025 à 11h47
Le 27/08/2025 à 11h39
Pour le reste MIT donne certes les 4 libertés, mais n'importe qui peut les reprendre en cours de chemin. C'est du code qui n'est garanti libre que pour un niveau de transmission entre l'émetteur initial et le premier récepteur.
Derrière le choix d'une licence, il y a toujours une intention, et dans ce contexte, l'intention de liberté vise plus les Gafam que les utilisateurs finaux.
Le 27/08/2025 à 12h03
Même Microsoft a utilisé cette pile assez longtemps dans Windows.
Une licence moins permis permissive n'aurait peut-être pas permis à TCP/IP de s'imposer sur les protocoles propriétaires de l'époque.
Le 27/08/2025 à 12h11
Le 27/08/2025 à 13h05
Le 27/08/2025 à 13h32
Le 27/08/2025 à 13h09
Le 27/08/2025 à 13h51
Le caractère copyleft ou non dépend principalement de la vision (libre ou open-source) que l'on défend. Les licences "open-sources" sont plus souvent non-copyleft, les licences "libres" copyleft. J'ai bien mis les "libres" et "open-source" entre guillemet, car la philosophie d'une licence est rarement inscrite dedans ou explicitée (sauf peut être pour la famille des GPL ^^) et qu'une licence libre est open-source et qu'une licence open-source est quasiment tout le temps libre.
Deux visions différentes, qui ont déjà amené de nombreux débats depuis des décennies (et encore de nos jours !).
Je pense qu'il faut arrêter aussi cette vision très manichéenne du bien contre le mal. On peut être libre et avoir une politique de merde (coucou Automattic) et être une entreprise sans pour autant faire de la prédation (pour reprendre tes termes).
Il y a toute une panoplie d'utilisations, et avant même la réutilisation par des acteurs privés, je pense que la communauté libre/open-source a bien plus à gagner avec ces licences très permissives que sans, car, je le rappelle encore une fois, des licences libres non compatible, ça existe (et ça peut bien foutre la merde alors que pourtant, le tout est libre).
Il y aura toujours des acteurs qui voudront tirer bénéfices du travail des autres. Mais ça, ce n'est pas propre au développement logiciel.
D'ailleurs, au passage, il est aussi rigolo de constater le tollé que provoque le passage à une licence non libre comme la SSPL (introduite par... MongoDB) alors qu'elle est très proche du libre, avec juste des contraintes pour éviter la prédation de gros providers du cloud et qu'ils ne fassent des centaines de millions de $ ou € sans rétribuer un minimum le projet initial.
Mais la question de la licence et de leur (absence de) philosophie est un sujet assez clivant. Cela l'est depuis les débuts, je doute que cela ne change à l'avenir.
Modifié le 27/08/2025 à 11h06
Pour moi, les licences permissives (MIT, BSD, Apache...) souffrent d'un défaut est qu'un fork n'est pas obligé d'être sous la même licence que la logiciel original, ce qui peut être interprété par certains comme du pillage de code. Le logiciel B (GPL par exemple), fork du logiciel A (licence MIT par exemple) peut utiliser autant de fois qu'il veut dans le code du logiciel A mais l'inverse n'est pas possible.
Le 27/08/2025 à 17h27
Les deux sont aussi libres et contraignantes, juste pas pour les mêmes personnes !
Le 27/08/2025 à 18h27
Toujours pas. Les utilisateurs sont ceux qui reçoivent le logiciel. Ils peuvent faire ce qu'ils veulent. C'est au contraire la GPL qui restreint de ce point de vue !
Non, la grosse différence, c'est que les potentiels utilisateurs futurs auront les mêmes droits que l'utilisateur actuel. C'est fondamentalement différent.
Du coup, on a d'un côté, une licence qui protège les droits des utilisateurs directs, de l'autre, une licence qui protège les droits des utilisateurs de tous les logiciels dérivés.
Les deux ont des avantages et des inconvénients. Et je pense même que la coexistence des deux est saine, car, comme je l'ai déjà rappelé dans d'autres commentaires sur cette article, les licences type GPL viennent avec des incompatibilités qui peuvent être très pénible à gérer, quand bien même le projet serait un projet libre !
Le 27/08/2025 à 18h37
Le concept de la "liberté des développeurs" est déjà suffisamment représenté dans le monde du logiciel propriétaire, il n'y a pas besoin de le protéger d'avantage, il est déjà soutenu par un large écosystème.
Le 27/08/2025 à 11h21
Modifié le 31/08/2025 à 13h48
Personne n'est dupe chez eux quand la question des sources ouverte est trahie ou récupérée.
Les "volte-faces" ou les changements de licences opportunistes sont à observer avec un regard méfiant.
Les sources ouvertes ne trouvent dans les licences qu'une garantie légale, et encore… il faudrait alors se parler des moyens à disposition pour les faire respecter.
Aujourd'hui, d'innombrables composants aux sources ouvertes (bibliothèques) sont utilisées de manière cachée dans des produits non-ouverts, violant ainsi les-dites licences. Qui se bat légalement contre cela ? Aucune entité.
La question de la licence est surtout intéressante dans un combat contre les entreprises, rarement avec, comme on peut le constater avec la récupération du sujet par M$ et ses gesticulations.
La signification de la source ouvert est une question de fond, voire fondamentale, au temps long et au signal faible.
Qu'un outil n'y naisse pas mais rejoigne une licence aux sources ouvertes pourrait simplement indiquer qu'une entité ne souhaite pas réaliser sa maintenance et laisse une "communauté" de travailleurs non-rémunérés s'en occuper.
Qu'un standard passe sous une telle licence peut être vu comme une simple pollution : une manière pour un éditeur d'utiliser la licence comme du marketing dans ses communications.
Il faut donc être méfiant, car tout changement de type de licence peut être suspect.
Quant au passage, brutal, d'une licence ouverte à une plus restrictive, Elastic a goûté aux conséquences. Hashicorp aussi.
Revenir en arrière ne produit pas grand chose, car le temps long est brisé, et un retour en arrière signifie un second changement dans un court laps de temps : un second accroc dans la ligne de temps.
On ne change pas de technologie comme de paire de chaussettes, car à tout vouloir adopter, on n'adopte rien.
Il faut du temps pour en apprivoiser une, reconnaitre fondamentalement ses qualités et ses faiblesses, maitriser de correctes utilisations et sortir la technologie de pétrins bizarres sans aide trouvable, en se retrouvant à discuter directement avec les mainteneurs.
Créer des accrocs de licence, c'est volontairement briser cette continuité pour d’innombrables, silencieuses, personnes.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?