Cloud public et Open Source : pourquoi et comment les licences Open Source ont évolué
(2022/12/09)
- Reference: 2022-12-09T07_51_23Z
- News link: https://www.toolinux.com/?cloud-public-et-open-source-pourquoi-et-comment-les-licences-open-source-ont
- Source link:
Cloud public et Open Source : pourquoi et comment les licences Open Source ont évolué
vendredi 9 décembre 2022
Les éditeurs de services Cloud publics ont considérablement enrichi leurs offres de service en réutilisant des composants open source. Quel est l’impact sur l’évolution des licences de la concentration des services cloud basés sur l’Open Source ? C’est ce que nous allons vous expliquer.
Nous avons déjà [1]abordé le cas particulier de la licence COSS (Commercial Open Source Software). Depuis un peu plus de quatre ans, les grands acteurs du Cloud américain que sont Google, Amazon, et Microsoft ont exploité de nombreux composants open source :
Au niveau de l’infastructure logicielle par l’utilisation extensive de solutions open source
Au niveau des fonctionnalités proposées qui sont celles de solutions open source en SaaS, ou bien des API identiques à celles de solutions open source permettant d’accéder à des fonctionnalités identiques à celles de composants open source... sans que ces solutions soient elles-mêmes open source.
Concentration des services cloud basés sur l’Open Source
Cette concentration des données dans le Cloud a parfois provoqué des réactions adverses de la part d’acteurs et de clients de fournisseurs d’IaaS ou [2]de PaaS .
Deux exemples.
DocumentDB
DocumentDB est un SGBD NoSQL développé par Amazon pour le cloud AWS, et dont les API sont strictement iso-fonctionnelles par rapport à celles de la solution MongoDB. Cette iso-fonctionnalité permet à Amazon de proposer à ses clients de migrer de manière indolore leurs solutions reposant sur le SGBD MongoDB vers la solution DocumentDB propriétaire mais hébergée sur AWS.
Corretto
En août 2018, Oracle a annoncé l’arrêt de son support long-terme pour le kit de développement Java ouvert OpenJDK après janvier 2019. Cependant, Java (et OpenJDK) sont les socles technologiques de l’essentiel des services d’Amazon qui en sont totalement dépendants.
À la suite de cette annonce, Amazon a créé Corretto comme fork d’OpenJDK, avec des optimisations spécifiques pour un usage infonuagique (cloud) d’applications Java. Ce fork est sous la même licence qu’OpenJDK, à savoir la licence GNU General Public License v2.
Pour le moment Corretto est relativement neutre technologiquement, il est à prévoir qu’Amazon y ajoute des optimisations et comportements spécifiques pour AWS. Il existe donc un risque technologique d’une dépendance au seul cloud Amazon en cas d’adoption de Corretto pour remplacer OpenJDK.
Réaction : l’évolution des licences
En réaction à l’exploitation systématique de composants communautaires par ces acteurs du Cloud non nécessairement suivie d’un reversement à la communauté, un grand nombre de sociétés comme Confluent, Elastic, MongoDB, Noe4J et Redis Labs, se sont tournées vers de nouveaux modes de licences open source .
En voici quelques exemples.
Licence Business Source 1.1 (MariaDB MaxScale)
MariaDB est un fork du SGBD MySQL, et comprend un module de proxy haute disponibilité appelé MaxScale. Dans sa version 2.0, ce module MaxScale qui jusqu’ici était sous licence GNU GPL v2 tout comme le serveur MariaDB a été publié sous une licence appelée Business Source.
Cette licence Business Source est une licence à copyleft faible mais seulement pour une utilisation hors production. MariaDB propose des licences supplémentaires payantes pour une utilisation en production. Son mécanisme original est qu’au bout d’une certaine durée (plusieurs années, précisées dans le nom de la licence : BSL-10, BSL-15, etc.), la licence change automatiquement pour une licence libre et open source pré-définie.
En pratique, l’utilisation en production du proxy de base de données haute disponibilité MaxScale implique nécessairement de passer par un modèle économique propriétaire totalement contradictoire avec l’intérêt de sélectionner un SGBD libre et open source tel que MariaDB.
En réaction, les membres de la communauté des développeurs ont d’ores et déjà lancé un p rojet de fork intitulé [3]GPLScale , et régi par la licence GNU GPL v2.
Licence Fair source (fair.io)
Cette licence inventée par la startup Sourcegraph se comporte comme une licence à copyleft faible, gratuite, mais incluant un seuil d’usage au-delà duquel la licence devient propriétaire et payante .
Cependant, la notion d’usage est laissée délibérément très vague (et elle inclut l’interaction via un réseau par des utilisateurs tiers avec le logiciel) ce qui introduit une incertitude quant au déclenchement du seuil.
Cette licence ni libre, ni open source, n’est compatible avec aucune licence libre à copyleft fort, et n’est pas compatible avec certaines licences propriétaires interdisant toute intégration avec des composants dont les licences impliquent un copyleft.
MongoDB et la Serverside License
MongoDB a mis à jour sa licence le 6 octobre 2018, de la GNU Affero GPL v3 vers la Server-Side Public License (SSPL), dérivée de la première. Cette licence SSPL a été conçue pour obliger les fournisseurs de services cloud à reverser toutes leurs altérations et améliorations à la pile d’infrastructure logicielle utilisant MongoDB.
« Nous pensons que dans le monde actuel, les liens ont été remplacés par la fourniture de programmes en tant que services » – Eliot Horowitz, CTO de MongoDB
Selon les mécanismes de la SSPL, le copyleft est étendu à la totalité des logiciels utilisés directement ou indirectement pour fournir le service à l’utilisateur distant, ce qui constitue une obligation de réciprocité particulièrement plus exigeante que celle de la licence GNU Affero GPL.
Licence Elastic 2.0
La pile Elastic (Elastic Stack) était soumise à des licences libres permissives (essentiellement Apache v2.0, avec quelques composants copyleft avec exceptions). L’éditeur d’Elasticsearch avait "ouvert" le module X-Pack (un pack d’extensions / plugins pour elasticsearch) avec la version 6.3 en avril 2018.
Cette « ouverture » était simplement la publication du code source sous licence Elastic, à savoir une licence propriétaire qui limite fortement l’usage du code objet, et qui confère des droits un peu plus étendus pour l’exploitation du code source. Ce plugin X-Pack était tout simplement un composant propriétaire réintroduisant un modèle de verrouillage et de dépendance technologique à un éditeur.
Évolution vers l’open core
Elastic a fait à nouveau évoluer son modèle de licence en 2021, pour passer à un modèle open core : désormais, la pile Elastic est pour l’essentiel sous double licence SSPL et licence « Elastic v2 », tandis que ce qui était jusqu’ici le X-Pack n’est plus fourni que sous la seule licence Elastic v.
Cette licence Elastic v2 ressemble à une licence libre car elle accorde les droits d’utilisation, copie, distribution et création d’œuvres dérivées.
Cependant, cette licence n’est pas une licence libre car elle implique des contraintes pour son bénéficiaire qui sont totalement contradictoires avec la liberté logicielle :
Elle interdit de fournir les produits en Saa S
Elle interdit de modifier le logiciel de manière à supprimer des fonctionnalités protégées par
des clés de licence
Les choix possibles
Les utilisateurs d’Elastic ont donc trois choix :
Disposer du logiciel Elastic sous licence SSPL très contraignante pour un usage en SaaS, sans les fonctionnalités propriétaires Elastic (anciennement X-Pack)
Disposer du logiciel Elastic sous licence propriétaire Elastic v2 , sans les fonctionnalités propriétaires Elastic (anciennement X-Pack)
Disposer du logiciel Elastic sous licence propriétaire Elastic v2, avec les fonctionnalités propriétaires Elastic (anciennement X-Pack) également sous licence propriétaire Elastic v2 .
La licence CDDL (Common Development and Distribution License)
La licence CDDL est une licence très ancienne à l’échelle de l’âge des licences libres. Elle a par le passé été très utilisée par la société Sun Microsystems - et la plupart des composants sous CDDL actuellement rencontrés sont des composants qui ont été développés à l’origine par cette société.
Toutefois, les particularités des mécanismes juridiques de cette licence doivent désormais être réévalués à l’aune des évolutions récentes des pratiques de programmation . La licence CDDL permet une gestion différenciée des droits d’exploitation pour les composants qu’elle régit selon que ceux-ci sont distribués sous forme de code source ou de code binaire.
En effet, les versions source de ces artefacts sont bien sous une licence libre avec un copyleft faible, mais les versions binaires peuvent être distribués selon des conditions plus limitées telles qu’une licence propriétaire - avec, théoriquement, l’obligation de ce que le code source soit toujours disponible sous licence CDDL.
Contraintes juridiques
Dès lors qu’un développeur souhaite réutiliser un composant sous licence CDDL, les contraintes juridiques auxquelles il est soumis diffèrent ainsi selon qu’il a compilé lui-même la version binaire du composant à partir du code source sous licence CDDL ou bien selon qu’il a directement récu- péré le composant binaire sans le compiler lui-même.
Dans le premier cas, le développeur ayant compilé lui-même le code source reçu sous licence CDDL, le binaire obtenu l’est sous les termes libres de cette licence (bien que le développeur puisse choisir une autre licence d’exploitation pour son binaire compilé). Dans le second cas, le binaire précompilé par un tiers peut être soumis à une autre licence déterminée par ledit tiers, voire non soumis à une quelconque licence ce qui en fait alors un composant propriétaire.
Évolution des pratiques de programmation et conséquences
Cette double mécanique, dans un écosystème où la plupart des composants réutilisés et intégrés dans des ensembles plus larges étaient habituellement recompilés à partir de leurs sources par les développeurs dans le cadre de leur inclusion, ne posait que auparavant que peu de difficultés. Toutefois, les pratiques de programmation ont considérablement évolué depuis le temps de la création de la licence CDDL.
En effet, les développeurs se reposent fréquemment désormais sur des environnements de programmation incluant des gestionnaires de dépendances tels que NPM, Yarn, Bower, Gradle, Maven, ou encore Composer. Ces logiciels permettent aux développeurs d’automatiser la recherche et le téléchargement des dépendances de compilation des logiciels qu’ils conçoivent.
Or, ces gestionnaires de dépendances ne téléchargent la plupart du temps que des binaires précompilés, souvent regroupés sur des forges centralisant ces artefacts telles que, par exemple mvnrepository.com. Cependant, cette centralisation des artefacts binaires précompilés sur les plates-formes de téléchargement de dépendances ne s’accompagne pas toujours de la mise à disposition des sources ayant permis d’obtenir les binaires correspondants, et parfois même ces sources, venant originellement d’autres projets désormais obsolètes ou abandonnés, n’existent même plus.
Les difficultés
Bien que la disparition de sources de composants binaires, par négligence ou oubli, soit regrettable puisqu’empêchant l’amélioration de nouvelles versions de ces composants, ceci pose en général pas de réelles difficultés dans le cadre de la plupart des licences open source.
En revanche, la licence CDDL régissant selon des contraintes variables le code binaire et le code source d’un même composant, le téléchargement d’artefacts précompilés sous licence CDDL via des gestionnaires de dépendances revient à introduire, dans la solution logicielle en cours de développement, des composants sous licence propriétaire.
Cette situation est d’autant plus problématique que certains composants sous CDDL sont extensivement réutilisés dans d’autres programmes. Il est donc désormais nécessaire, dans les travaux de programmation, de prêter une attention soutenue aux artefacts soumis à cette licence, et de s’assurer de les recompiler systématiquement à partir de leurs sources.
Avec le concours de l’OSSA ( [4]Open Source Software Assurance ). Cette entité accompagne les DSI dans la gouvernance de leur catalogue de logiciels libres
[5]
[1] https://www.toolinux.com/?coss-c-est-quoi-un-commercial-open-source-software
[2] https://www.solutions-numeriques.com/le-cern-quitte-la-plateforme-workplace-de-facebook-craignant-pour-ses- donnees/
[3] https://github.com/cbegin/GPLScale
[4] https://www.linagora.com/fr/ossa-et-support/open-source-software-assurance/
[5] https://www.toolinux.com/?cloud-public-et-open-source-pourquoi-et-comment-les-licences-open-source-ont#forum
vendredi 9 décembre 2022
Les éditeurs de services Cloud publics ont considérablement enrichi leurs offres de service en réutilisant des composants open source. Quel est l’impact sur l’évolution des licences de la concentration des services cloud basés sur l’Open Source ? C’est ce que nous allons vous expliquer.
Nous avons déjà [1]abordé le cas particulier de la licence COSS (Commercial Open Source Software). Depuis un peu plus de quatre ans, les grands acteurs du Cloud américain que sont Google, Amazon, et Microsoft ont exploité de nombreux composants open source :
Au niveau de l’infastructure logicielle par l’utilisation extensive de solutions open source
Au niveau des fonctionnalités proposées qui sont celles de solutions open source en SaaS, ou bien des API identiques à celles de solutions open source permettant d’accéder à des fonctionnalités identiques à celles de composants open source... sans que ces solutions soient elles-mêmes open source.
Concentration des services cloud basés sur l’Open Source
Cette concentration des données dans le Cloud a parfois provoqué des réactions adverses de la part d’acteurs et de clients de fournisseurs d’IaaS ou [2]de PaaS .
Deux exemples.
DocumentDB
DocumentDB est un SGBD NoSQL développé par Amazon pour le cloud AWS, et dont les API sont strictement iso-fonctionnelles par rapport à celles de la solution MongoDB. Cette iso-fonctionnalité permet à Amazon de proposer à ses clients de migrer de manière indolore leurs solutions reposant sur le SGBD MongoDB vers la solution DocumentDB propriétaire mais hébergée sur AWS.
Corretto
En août 2018, Oracle a annoncé l’arrêt de son support long-terme pour le kit de développement Java ouvert OpenJDK après janvier 2019. Cependant, Java (et OpenJDK) sont les socles technologiques de l’essentiel des services d’Amazon qui en sont totalement dépendants.
À la suite de cette annonce, Amazon a créé Corretto comme fork d’OpenJDK, avec des optimisations spécifiques pour un usage infonuagique (cloud) d’applications Java. Ce fork est sous la même licence qu’OpenJDK, à savoir la licence GNU General Public License v2.
Pour le moment Corretto est relativement neutre technologiquement, il est à prévoir qu’Amazon y ajoute des optimisations et comportements spécifiques pour AWS. Il existe donc un risque technologique d’une dépendance au seul cloud Amazon en cas d’adoption de Corretto pour remplacer OpenJDK.
Réaction : l’évolution des licences
En réaction à l’exploitation systématique de composants communautaires par ces acteurs du Cloud non nécessairement suivie d’un reversement à la communauté, un grand nombre de sociétés comme Confluent, Elastic, MongoDB, Noe4J et Redis Labs, se sont tournées vers de nouveaux modes de licences open source .
En voici quelques exemples.
Licence Business Source 1.1 (MariaDB MaxScale)
MariaDB est un fork du SGBD MySQL, et comprend un module de proxy haute disponibilité appelé MaxScale. Dans sa version 2.0, ce module MaxScale qui jusqu’ici était sous licence GNU GPL v2 tout comme le serveur MariaDB a été publié sous une licence appelée Business Source.
Cette licence Business Source est une licence à copyleft faible mais seulement pour une utilisation hors production. MariaDB propose des licences supplémentaires payantes pour une utilisation en production. Son mécanisme original est qu’au bout d’une certaine durée (plusieurs années, précisées dans le nom de la licence : BSL-10, BSL-15, etc.), la licence change automatiquement pour une licence libre et open source pré-définie.
En pratique, l’utilisation en production du proxy de base de données haute disponibilité MaxScale implique nécessairement de passer par un modèle économique propriétaire totalement contradictoire avec l’intérêt de sélectionner un SGBD libre et open source tel que MariaDB.
En réaction, les membres de la communauté des développeurs ont d’ores et déjà lancé un p rojet de fork intitulé [3]GPLScale , et régi par la licence GNU GPL v2.
Licence Fair source (fair.io)
Cette licence inventée par la startup Sourcegraph se comporte comme une licence à copyleft faible, gratuite, mais incluant un seuil d’usage au-delà duquel la licence devient propriétaire et payante .
Cependant, la notion d’usage est laissée délibérément très vague (et elle inclut l’interaction via un réseau par des utilisateurs tiers avec le logiciel) ce qui introduit une incertitude quant au déclenchement du seuil.
Cette licence ni libre, ni open source, n’est compatible avec aucune licence libre à copyleft fort, et n’est pas compatible avec certaines licences propriétaires interdisant toute intégration avec des composants dont les licences impliquent un copyleft.
MongoDB et la Serverside License
MongoDB a mis à jour sa licence le 6 octobre 2018, de la GNU Affero GPL v3 vers la Server-Side Public License (SSPL), dérivée de la première. Cette licence SSPL a été conçue pour obliger les fournisseurs de services cloud à reverser toutes leurs altérations et améliorations à la pile d’infrastructure logicielle utilisant MongoDB.
« Nous pensons que dans le monde actuel, les liens ont été remplacés par la fourniture de programmes en tant que services » – Eliot Horowitz, CTO de MongoDB
Selon les mécanismes de la SSPL, le copyleft est étendu à la totalité des logiciels utilisés directement ou indirectement pour fournir le service à l’utilisateur distant, ce qui constitue une obligation de réciprocité particulièrement plus exigeante que celle de la licence GNU Affero GPL.
Licence Elastic 2.0
La pile Elastic (Elastic Stack) était soumise à des licences libres permissives (essentiellement Apache v2.0, avec quelques composants copyleft avec exceptions). L’éditeur d’Elasticsearch avait "ouvert" le module X-Pack (un pack d’extensions / plugins pour elasticsearch) avec la version 6.3 en avril 2018.
Cette « ouverture » était simplement la publication du code source sous licence Elastic, à savoir une licence propriétaire qui limite fortement l’usage du code objet, et qui confère des droits un peu plus étendus pour l’exploitation du code source. Ce plugin X-Pack était tout simplement un composant propriétaire réintroduisant un modèle de verrouillage et de dépendance technologique à un éditeur.
Évolution vers l’open core
Elastic a fait à nouveau évoluer son modèle de licence en 2021, pour passer à un modèle open core : désormais, la pile Elastic est pour l’essentiel sous double licence SSPL et licence « Elastic v2 », tandis que ce qui était jusqu’ici le X-Pack n’est plus fourni que sous la seule licence Elastic v.
Cette licence Elastic v2 ressemble à une licence libre car elle accorde les droits d’utilisation, copie, distribution et création d’œuvres dérivées.
Cependant, cette licence n’est pas une licence libre car elle implique des contraintes pour son bénéficiaire qui sont totalement contradictoires avec la liberté logicielle :
Elle interdit de fournir les produits en Saa S
Elle interdit de modifier le logiciel de manière à supprimer des fonctionnalités protégées par
des clés de licence
Les choix possibles
Les utilisateurs d’Elastic ont donc trois choix :
Disposer du logiciel Elastic sous licence SSPL très contraignante pour un usage en SaaS, sans les fonctionnalités propriétaires Elastic (anciennement X-Pack)
Disposer du logiciel Elastic sous licence propriétaire Elastic v2 , sans les fonctionnalités propriétaires Elastic (anciennement X-Pack)
Disposer du logiciel Elastic sous licence propriétaire Elastic v2, avec les fonctionnalités propriétaires Elastic (anciennement X-Pack) également sous licence propriétaire Elastic v2 .
La licence CDDL (Common Development and Distribution License)
La licence CDDL est une licence très ancienne à l’échelle de l’âge des licences libres. Elle a par le passé été très utilisée par la société Sun Microsystems - et la plupart des composants sous CDDL actuellement rencontrés sont des composants qui ont été développés à l’origine par cette société.
Toutefois, les particularités des mécanismes juridiques de cette licence doivent désormais être réévalués à l’aune des évolutions récentes des pratiques de programmation . La licence CDDL permet une gestion différenciée des droits d’exploitation pour les composants qu’elle régit selon que ceux-ci sont distribués sous forme de code source ou de code binaire.
En effet, les versions source de ces artefacts sont bien sous une licence libre avec un copyleft faible, mais les versions binaires peuvent être distribués selon des conditions plus limitées telles qu’une licence propriétaire - avec, théoriquement, l’obligation de ce que le code source soit toujours disponible sous licence CDDL.
Contraintes juridiques
Dès lors qu’un développeur souhaite réutiliser un composant sous licence CDDL, les contraintes juridiques auxquelles il est soumis diffèrent ainsi selon qu’il a compilé lui-même la version binaire du composant à partir du code source sous licence CDDL ou bien selon qu’il a directement récu- péré le composant binaire sans le compiler lui-même.
Dans le premier cas, le développeur ayant compilé lui-même le code source reçu sous licence CDDL, le binaire obtenu l’est sous les termes libres de cette licence (bien que le développeur puisse choisir une autre licence d’exploitation pour son binaire compilé). Dans le second cas, le binaire précompilé par un tiers peut être soumis à une autre licence déterminée par ledit tiers, voire non soumis à une quelconque licence ce qui en fait alors un composant propriétaire.
Évolution des pratiques de programmation et conséquences
Cette double mécanique, dans un écosystème où la plupart des composants réutilisés et intégrés dans des ensembles plus larges étaient habituellement recompilés à partir de leurs sources par les développeurs dans le cadre de leur inclusion, ne posait que auparavant que peu de difficultés. Toutefois, les pratiques de programmation ont considérablement évolué depuis le temps de la création de la licence CDDL.
En effet, les développeurs se reposent fréquemment désormais sur des environnements de programmation incluant des gestionnaires de dépendances tels que NPM, Yarn, Bower, Gradle, Maven, ou encore Composer. Ces logiciels permettent aux développeurs d’automatiser la recherche et le téléchargement des dépendances de compilation des logiciels qu’ils conçoivent.
Or, ces gestionnaires de dépendances ne téléchargent la plupart du temps que des binaires précompilés, souvent regroupés sur des forges centralisant ces artefacts telles que, par exemple mvnrepository.com. Cependant, cette centralisation des artefacts binaires précompilés sur les plates-formes de téléchargement de dépendances ne s’accompagne pas toujours de la mise à disposition des sources ayant permis d’obtenir les binaires correspondants, et parfois même ces sources, venant originellement d’autres projets désormais obsolètes ou abandonnés, n’existent même plus.
Les difficultés
Bien que la disparition de sources de composants binaires, par négligence ou oubli, soit regrettable puisqu’empêchant l’amélioration de nouvelles versions de ces composants, ceci pose en général pas de réelles difficultés dans le cadre de la plupart des licences open source.
En revanche, la licence CDDL régissant selon des contraintes variables le code binaire et le code source d’un même composant, le téléchargement d’artefacts précompilés sous licence CDDL via des gestionnaires de dépendances revient à introduire, dans la solution logicielle en cours de développement, des composants sous licence propriétaire.
Cette situation est d’autant plus problématique que certains composants sous CDDL sont extensivement réutilisés dans d’autres programmes. Il est donc désormais nécessaire, dans les travaux de programmation, de prêter une attention soutenue aux artefacts soumis à cette licence, et de s’assurer de les recompiler systématiquement à partir de leurs sources.
Avec le concours de l’OSSA ( [4]Open Source Software Assurance ). Cette entité accompagne les DSI dans la gouvernance de leur catalogue de logiciels libres
[5]
[1] https://www.toolinux.com/?coss-c-est-quoi-un-commercial-open-source-software
[2] https://www.solutions-numeriques.com/le-cern-quitte-la-plateforme-workplace-de-facebook-craignant-pour-ses- donnees/
[3] https://github.com/cbegin/GPLScale
[4] https://www.linagora.com/fr/ossa-et-support/open-source-software-assurance/
[5] https://www.toolinux.com/?cloud-public-et-open-source-pourquoi-et-comment-les-licences-open-source-ont#forum