agsandrew - Fotolia
Confluent bride à son tour la licence open source de sa plateforme Kafka
Comme Redis Labs et MongoDB, Confluent ne souhaite pas que ses développements autour de Kafka soient intégrés dans des services cloud potentiellement concurrents.
« Une étape nécessaire. » C’est ainsi que Confluent, entité commerciale derrière le projet open source Kafka, a qualifié sa décision d’encadrer la déclinaison communautaire de sa plateforme de gestion de flux de données d’une licence plus restrictive. D’une licence Apache 2.0, celle-ci passe désormais sous une licence Confluent Community Licence, conçue par l’éditeur. Objectif : empêcher les fournisseurs de cloud de proposer sous la forme SaaS les composants issus de la plateforme même de Confluent.
Confluent rejoint ainsi Redis Labs et MongoDB qui eux-aussi ont pris la décision de modifier les licences qui régissaient leur plateforme open source. Redis Labs a préféré s’appuyer sur les Commons Clauses tandis que MongoDB a opté pour le développement d’une nouvelle licence Server Side Public Licence (SSPL).
La Confluent Community Licence ajoute une clause d’exclusion « Excluded Purpose » qui définit les cas de réutilisation prohibés, indique une FAQ sur le site de Confluent. Les connecteurs développés par Confluent, Confluent Shema Registry, REST Proxy et surtout KSQL, un moteur de requêtes SQL pour Kafka (qui fait partie des ajouts de la dernière version de la plateforme Confluent) sont couverts par cette clause. Confluent ne souhaite donc pas qu’un fournisseur de cloud s’approprie KSQL en le transformant en un service payant sous un modèle KSQL-as-a-Service, résume Jay Kreps, co-fondateur et CEO de Confluent dans un billet de blog. Et alors même que Confluent monétise lui-aussi son propre service cloud.
Ces modifications n’auront aucun effet sur la version Apache de Kafka, qui reste régie par une gouvernance de la fondation Apache. Le CEO garantit également que les contributions de Confluent au projet Kafka restent inchangées.
« Nous pensons que la bonne façon pour développer des couches d'infrastructure fondamentales est de le faire avec du code ouvert. Avec la migration vers le cloud, nous avons besoin d'un mécanisme qui préserve cette liberté tout en permettant un cycle d'investissement, et c'est notre motivation pour le changement de licence », écrit-il encore. Rappelant ainsi les forts investissements en R&D consentis par Confluent pour assurer la pérennité de son modèle économique d’éditeur Open Core.
Plus nuancé que Redis Labs dans ses propos, Jay Kreps évoque des rapports fluctuants avec les fournisseurs de cloud. « Certaines de ces sociétés s'associent aux sociétés open source qui proposent des versions hébergées de leur système en tant que service. D'autres prennent le code source, l'intègrent dans un service cloud et investissent tout dans des offres propriétaires pour se différencier », explique-t-il. « Ces entreprises suivent simplement leurs intérêts commerciaux et agissent dans les limites de ce que permet la licence », ajoute-t-il toutefois.
AWS avance timidement vers l’open source
AWS avait par exemple été mentionné par Redis Labs. Interrogé sur son implication dans les communautés open source, AWS avait confirmé à la rédaction participer à plusieurs projets et contribuer directement avec du code. Le géant du cloud est par exemple membre de la Cloud Native Computing Foundation, rappelle Deepak Singh, Directeur des activités Compute Services chez AWS, rencontré lors de la conférence AWS ReInvent en novembre 2018.
A cette occasion, AWS avait présenté Firecracker, un projet de micro-VM imaginé initialement par le groupe pour motoriser son service Fargate (gestion des containers). Ce projet, qui ressemble fortement aux Kata Containers de l’Open Stack Foundation, a été versé dans l’open source pour y trouver sa communauté, a expliqué l’expert. « Nous l’avons développé pour un usage particulier, mais en le plaçant à l’open source nous le livrons à la communauté des utilisateurs comme les Kata Containers. »
Le responsable s’attend également à ce que la communauté développe des connecteurs vers d’autres technologies, et des fonctions doivent y être ajoutées. « La communauté décidera », lance-t-il.
« Il faut s’attendre à voir davantage AWS dans l’open source », précise-t-il. « Firecracker est un bon point de départ. »