Les efforts de MongoDB pour décrocher l’acceptation de l’Open source décision en vue d’une licence, SSPL, plus adaptée aux entreprises ont raté. La société a donc choisi de faire sans, et cela pourrait bien accorder lieu à un moment charnière dans l’histoire de l’open source.

Après tout le bruit fait auprès de l’amélioration de licence de MongoDB de l’Affero General Public License (AGPL) vers la Server Side Public License (SSPL), l’éditeur de bases de données a déterminé d’arrêter ses efforts. S’il maintient son choix de passer sur la SSPL, il ne cherche plus à obtenir la bénédiction de l’Open Source Initiative pour qu’elle soit admise comme licence open source. Cette fin pourrait exposer que les points de vue traditionalistes sur l’open source n’ont plus autant d’importance qu’auparavant.

Ce qui se passe actuellement est captivant. Jamais l’open source n’a été aussi omniprésent dans les logiciels, et pourtant il n’a jamais été aussi mouvant qu’il n’y paraît maintenant. Face à des géants du cloud comme Amazon Web Services, virtuellement capables de les écraser purement et simplement, les sociétés qui gèrent des projets open source, comme MongoDB et Elasticsearch, ont cherché des moyens de se défendre tout en incitant les entreprises à payer.

Le problème de la licence open source

A en trancher par leurs résultats financiers, la menace AWS a semble-t-il été doucement amplifiée. Mais il est compréhensible que MongoDB et consorts cherchent des moyens de protéger leurs investissements. Eliot Horowitz, directeur technique de MongoDB, a dernièrement  déclarer que sa société avait dépensé plus de 300 millions de dollars pour développer sa base de données, qu’elle a ensuite mis gratuitement à la disposition de tous, en open source. Mais le fait qu’AWS ou un autre fournisseur de services dans le cloud puisse s’emparer de ce code sans rien donner en retour pose un vrai problème.

D’où l’utilisation de la licence SSPL, qui dit principalement : « Si vous mettez MongoDB à disposition en tant que service, vous devez participer au code de ce service ». Cela va peut-être un peu loin, mais on peut comprendre pourquoi MongoDB a choisi pour ce système. Il n’est pas difficile non plus de comprendre pourquoi l’éditeur vient de décider de renoncer à obtenir la bénédiction de l’Open Source Initiative sur la SSPL.

MongoDB change de stratégie

Le tollé levé contre la SSPL par quelques membres de la communauté open source a été vif et soutenu. Encore que les efforts de bonne foi de MongoDB pour changer la SSPL afin de répondre aux objections, l’entreprise a finalement décidé de jeter l’éponge, comme l’a expliqué Eliot Horowitz : « Nous poursuivons à croire que la SSPL est conforme à la résolution de l’open source et aux quatre libertés logicielles essentielles. Toutefois, compte tenu de sa réception par l’ensemble de la communauté, les consentements nécessaires pour soutenir l’approbation de l’OSI ne semble pas exister actuellement. Par conséquent, nous enlevons par la présente la SSPL de l’attention du conseil d’administration de l’OSI. »

Le CEO de MongoDB a détaillé ce qu’il comptait faire pour nettoyer la licence et travailler avec d’autres acteurs du secteur pour essayer d’apercevoir un moyen de se défendre face à la intimidation imminente du cloud. Dans l’espace, son entreprise poursuivra à proposer son édition communautaire sous SSPL comme s’il était open source en admettant aux utilisateurs « d’examiner, de modifier et de distribuer le logiciel ou de redistribuer les modifications faites sur le logiciel en conformité avec la licence ». Ce n’est pas open source en soi, mais cela permet à la plupart des utilisateurs d’avoir une liberté semblable à celle que procure l’open source. Et c’est là que ça devient captivant.

Le type de licence n’intéresse plus les développeurs

Bien que MongoDB n’ait pas accès aux attributions Linux open source comme Red Hat’s Enterprise Linux ou Fedora, il n’est pas certain qu’il en souffre pour autant. Sa plateforme employait le quatrième rang de l’organisation de popularité des bases de données de DB-Engines. Elle a pris du retard sur PostgreSQL, mais dans le même temps, le chiffre d’affaires de l’entreprise a poursuivi de progresser. Le battage autour de MongoDB y a peut-être contribué mais il n’a jamais été aussi pertinent. Le fait qu’AWS ait choisi de construire un service de base de données avec une API de compatibilité pour les anciennes versions de MongoDB sans licence SSPL est un indicateur clair de l’importance de l’éditeur. Le passage à SSPL va-t-il modifier cela ? Peut-être, peut-être pas. Peu de développeurs apportent des changements au niveau du code source de MongoDB. Il est presque certain que la plupart de ceux qui choisissent la base de données se charment beaucoup plus à l’accès gratuit pour les tests et le développement qu’à la licence distinctive qui la régit.

En fait, ces mêmes développeurs partisans de GitHub semblent se soucier de moins en moins des licences. Durant des années, jusqu’à 85 % des référentiels GitHub n’avaient pas de licence du tout, open source ou pas, malgré les efforts du site pour éduquer ses consommateurs sur leur importance. Pour cette population, l’accès au code est la principale inquiétude, pas la façon dont il est régulé. Cette génération va-t-elle s’inquiéter de savoir si MongoDB est sous licence AGPL ou SSPL ? Possiblement pas. On peut supporter qu’il s’agit d’une grande erreur, car la définition de l’open source est importante, tout comme l’approbation d’une licence par l’OSI. Mais les polémiques sur ce dont les développeurs devraient se soucier semblent moins écoutées qu’auparavant. Ainsi, MongoDB pourrait présenter une licence propriétaire assez « open source » pour les développeurs. Comme dans le cas de la sélection par les développeurs d’AWS et d’autres services pratiques mais fermés, le terme « ouvert » pourrait modifier de définition selon celui qui développe.