Connexion Premium

Microsoft place DocumentDB sous l’égide de la Linux Foundation

Humongous DB

Microsoft place DocumentDB sous l’égide de la Linux Foundation

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

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.

Commentaires (21)

votre avatar
MIT est surtout une famille de licences qui ne protège pas la nature libre du code et de ses dérivés et permet de réintégrer tout ou partie du code dans une offre ni libre ni opensource. Si Linux avait été distribué sous cette licence, on ne parlerait sans-doutes pas de "Linux Foundation"...
votre avatar
Encore un qui veut imposer sa vision de ce que doit être un logiciel libre !

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.
votre avatar
Non, je n'impose pas, je dis juste ce qui est. Le mouvement du logiciel libre vise à donner les quatre libertés aux utilisateurs finaux, et la licence MIT est très mauvaise dans cette optique car elle permet à un intermédiaire de transformer le logiciel libre en non-libre.

"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.
votre avatar
N'est-ce pas aussi / surtout un choix qui vise à préserver une forme de paix des braves avec MongoDB ?
votre avatar
Bah, si, tu imposes ta vision et celle de la FSF comme la seule valable.

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.
votre avatar
Surtout que, pour aller dans ton sens (car je partage ton avis) les licences libres sont parfois incompatibles entre elles. L'avantage de la MIT (et des autres licences si "permissives"), c'est justement qu'elles empêches ce genre de situation.

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.
votre avatar
C'est à la fois sa force et sa faiblesse. D'où ma préférence pour les logiciels libres avec un copyleft faible. La MPL v2 a justement été conçu pour être un pont entre la licence Apache 2.0 et la LGPL v3.
votre avatar
Il est clair que la licence MIT a des bons côtés, si par exemple la finalité du code est plus d'inciter l'opérabilité et la compatibilité entre plusieurs environnements propriétaires et non-propriétaires, la licence MIT peut être un quick-win, par contre la licence MIT ne protégera absolument pas la technologie contre de l'embrace & extend propriétaire, ce qui nuit aux libertés des utilisateurs.
votre avatar
La FSF étant l'organe principal et à l'origine du mouvement logiciel libre, je ne pense pas qu'il y ait de problème à considérer sa vision comme faisant autorité en la matière, sauf à vouloir vider le mouvement de sa substance.

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.
votre avatar
C'est oublier la licence BSD qui est de la même année que la GPL et qui a permis en particulier la diffusion large de la pile réseau BSD et donc le succès de TCP/IP.
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.
votre avatar
Mais en gros, tu es juste en train de refaire le débat entre licence libre et licence open-source ;)
votre avatar
Même pas, les licences BSD, Apache ou MIT sont des licences libres.
votre avatar
Je parlais de la différence philosophique qui existe entre les deux notions. Dans leur expression, elles sont équivalentes (ou quasiment). C'est dans leur intentionnalité que cela diffère.
votre avatar
Non, copyleft contre non-copyleft dans un contexte de prédation tel que l'acteur principal du domaine a abandonné le libre/opensource.
votre avatar
Cf. ma réponse à fred42.

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 !).
dans un contexte de prédation tel que l'acteur principal du domaine a abandonné le libre/opensource.
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.
votre avatar
Je suis plutôt d'accord. Quand je conseille une licence pour un logiciel libre : "Si vous voulez que votre code puisse être utiliser uniquement pour un logiciel libre, choisissez la CeCILL v2 ou (A)GPL v3. Mais si vous voulez que votre code puisse être utiliser dans un logiciel propriétaire, choisissez la MPL v2 ou la LGPL v3."

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.
votre avatar
mmm... pas d'accord : les licences type GPL protègent la liberté des UTILISATEURS, leur garantissant une liberté infinie, au prix d'une restriction pour les développeurs. Les licences type MIT protègent la liberté des DÉVELOPPEURS, qui peuvent faire ce qu'ils veulent de leur produit, au prix d'une restriction pour les utilisateurs (qui peuvent voir une version être "refermée")
Les deux sont aussi libres et contraignantes, juste pas pour les mêmes personnes !
votre avatar
Nope. Les deux types de licences s'adressent aux mêmes personnes : à celles qui reçoivent le logiciel (et uniquement à elles). Elles peuvent ensuite en faire ce qu'elles veulent (MIT) ou presque ce qu'elles veulent (GPL).
au prix d'une restriction pour les utilisateurs (qui peuvent voir une version être "refermée")
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 !
votre avatar
Le principe fondamental du logiciel libre est de donner des libertés par de permettre à un intermédiaire de les reprendre. Il n'est pas dans l'intérêt du mouvement logiciel libre d'alimenter avec du code gratuit des usines à logiciel propriétaire, d'où la critique sur l'emploi de licences insuffisantes pour protéger les utilisateurs finaux.

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.
votre avatar
En fait, DocumentDB sert de socle à la base de données CosmosDB de Microsoft disponible sur le cloud Azure de Microsoft.
votre avatar
Les amateurs du libre cherchent honnêteté et stabilité.
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.

Microsoft place DocumentDB sous l’égide de la Linux Foundation

  • Alliance autour d'un possible futur standard NoSQL

  • Comment réagira MongoDB ?

Fermer