Les efforts de MongoDB pour obtenir l’approbation de l’Open source initiative en vue d’une licence, SSPL, plus favorable aux entreprises ont échoué. L’entreprise a donc choisi de faire sans, et cela pourrait bien donner lieu à un moment charnière dans l’histoire de l’open source.
Eliot Horowitz, directeur technique de MongoDB, a décidé de ne plus attendre l’aval de l’Open source initiative sur la licence (SPPL) choisie pour sa base de données. (Crédit : MongoDB)
Après tout le bruit fait autour du changement 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écidé de stopper 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 acceptée comme licence open source. Cette décision pourrait montrer que les points de vue traditionalistes sur l’open source n’ont plus autant d’importance qu’auparavant.
Ce qui se passe en ce moment est intéressant. 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 entreprises qui gèrent des projets open source, comme MongoDB et Elasticsearch, ont cherché des moyens de se défendre tout en encourageant les entreprises à payer.
Le problème de la licence open source
A en juger par leurs résultats financiers, la menace AWS a semble-t-il été légèrement surestimé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 récemment affirmé que son entreprise 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 essentiellement : « Si vous mettez MongoDB à disposition en tant que service, vous devez contribuer au code de ce service ». Cela va peut-être un peu loin, mais on peut comprendre pourquoi MongoDB a opté 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é soulevé contre la SSPL par certains membres de la communauté open source a été vif et soutenu. Malgré les efforts de bonne foi de MongoDB pour modifier 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 continuons à croire que la SSPL est conforme à la définition de l’open source et aux quatre libertés logicielles essentielles. Toutefois, compte tenu de sa réception par l’ensemble de la communauté, le consensus nécessaire pour soutenir l’approbation de l’OSI ne semble pas exister actuellement. Par conséquent, nous retirons par la présente la SSPL de la considération du conseil d’administration de l’OSI. »
Le CEO de MongoDB a détaillé ce qu’il comptait faire pour affiner la licence et travailler avec d’autres acteurs du secteur pour tenter de trouver un moyen de se défendre face à la menace imminente du cloud. Dans l’intervalle, son entreprise continuera à proposer son édition communautaire sous SSPL comme s’il était open source en permettant 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 intéressant.
Le type de licence n’intéresse plus les développeurs
Bien que MongoDB n’ait pas accès aux distributions Linux open source comme Red Hat’s Enterprise Linux ou Fedora, il n’est pas certain qu’il en souffre pour autant. Sa plateforme occupait le quatrième rang du classement 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 continué 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 changer cela ? Peut-être, peut-être pas. Peu de développeurs apportent des modifications au niveau du code source de MongoDB. Il est presque certain que la plupart de ceux qui adoptent la base de données s’intéressent beaucoup plus à l’accès gratuit pour les tests et le développement qu’à la licence particulière qui la régit.
En fait, ces mêmes développeurs adeptes de GitHub semblent se soucier de moins en moins des licences. Pendant 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 utilisateurs sur leur importance. Pour cette population, l’accès au code est la principale préoccupation, 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 ? Probablement pas. On peut soutenir 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 discussions sur ce dont les développeurs devraient se soucier semblent moins écoutées qu’auparavant. Ainsi, MongoDB pourrait proposer une licence propriétaire suffisamment « open source » pour les développeurs. Comme dans le cas de l’adoption par les développeurs d’AWS et d’autres services pratiques mais fermés, le terme « ouvert » pourrait changer de définition selon celui qui développe.