- Liquibase est passé de sa licence open source historique à la Functional Source License (FSL)
- Bien que la FSL ne soit pas une licence open source officielle selon les critères de l’Open Source Initiative (OSI), le projet continue d’être présenté comme open source dans le README et d’autres documents, ce qui soulève des critiques
- Dans la communauté, certains estiment que la FSL contrevient aux critères officiels de l’open source, tandis que d’autres soutiennent qu’elle remplit les conditions requises
- Au sein du projet, une correction des mentions open source dans le README est en cours
- Il est reproché à la FSL, notamment à cause de clauses limitant l’usage concurrentiel, d’entrer en conflit avec certaines dispositions de l’OSI Open Source Definition
Aperçu du problème
- La licence du projet Liquibase a récemment été changée pour la Functional Source License (FSL)
- Cependant, dans README.md et d’autres documents officiels, Liquibase continue d’être présenté comme un projet open source, ce qui provoque confusion et désaccords dans la communauté
Contenu du signalement et controverse
- L’auteur du ticket souligne qu’il est problématique que Liquibase continue d’indiquer qu’il est open source malgré le passage à la FSL
- Liquibase lui-même a déjà indiqué que la FSL n’est pas une licence open source
- Il est demandé de modifier le README et les autres documents pour que le terme open source n’y soit plus utilisé
Avis de la communauté et des personnes concernées
- Certains participants affirment que la FSL satisfait aux critères des licences open source approuvées par l’OSI et considèrent qu’il n’y aurait plus de problème si elle devenait une licence approuvée par l’OSI après un examen formel
- À l’inverse, d’autres participants insistent sur le fait qu’en raison de clauses comme celle sur les « usages autorisés », la FSL viole plusieurs articles de l’Open Source Definition de l’OSI (1, 3, 5 et 6)
- D’autres encore soulignent la distinction entre « Fair Source » et le « véritable open source », estimant que la FSL doit être classée dans la catégorie Fair Source
Résolution du problème et mise à jour des documents
- Un contributeur du projet a réagi au signalement en modifiant README.md et en supprimant progressivement les mentions open source
- Cependant, quelques occurrences de « open source » et « oss » subsistent encore dans le dépôt, et un examen complémentaire ainsi qu’un nettoyage supplémentaire sont prévus
Définition de l’open source et problème posé par la FSL (Functional Source License)
- Des figures du mouvement open source, dont Richard Fontana, ont clairement indiqué que la FSL enfreint l’Open Source Definition de l’OSI en raison de clauses comme l’interdiction d’un usage concurrentiel
- L’Open Source Definition comporte des principes tels que l’« absence de discrimination envers des personnes, des groupes ou des domaines d’activité », auxquels s’opposent des restrictions comme l’interdiction d’usages concurrents
- La FSL est censée basculer vers la licence MIT ou Apache au bout de deux ans, devenant alors pleinement open source, mais des restrictions restent en place jusque-là
Conclusion et situation actuelle
- Cette affaire alimente les discussions sur la correction de la qualification open source de Liquibase, ainsi que sur les exigences de transparence de la communauté et la nature même de l’open source
- La mise à jour des documents officiels, dont le README, a commencé, et les critères de distinction entre Fair Source et open source sont discutés à travers ce cas concret
- Indépendamment d’une éventuelle approbation par l’OSI, les conditions réelles de la licence ont une importance considérable pour la communauté open source internationale
1 commentaires
Avis Hacker News
Nous avons commencé à chercher des alternatives au cas où nous ne pourrions plus utiliser la version 4.x
Je comprends qu’on veuille monétiser un logiciel utile en passant d’une licence OSS à une offre payante
Mais changer la licence d’un projet open source me semble relever d’une forme de tactique d’appât-et-substitution
Ce genre de décision détruit immédiatement la confiance et fait aussi perdre une base d’utilisateurs qui ne se monétise pas facilement à court terme, mais qui a un potentiel sur le long terme
J’espérais qu’on avait déjà retenu des leçons importantes des cas Elastic et TerraForm
J’ai aussi moins confiance en Flyway, qui pourrait suivre une trajectoire similaire à tout moment
S’il n’y a pas de fork, nous envisageons même de créer nous-mêmes une bibliothèque de migration adaptée à notre usage réel
Nous utilisions Liquibase parce que c’était pratique, pas parce que c’était irremplaçable
Je pense qu’EventstoreDB (désormais KurrentDB) et NATS sont eux aussi vus avec suspicion sur le plan de la fiabilité du service
EventstoreDB a déjà changé de licence, et NATS a finalement abandonné son projet à cause de la réaction des utilisateurs
J’ai l’impression que ce type de démarche est désormais devenu une stratégie commerciale à part entière
Le plus grand avantage de l’open source, c’est qu’on peut toujours forker et utiliser une ancienne version
À mes yeux, cette transition ne diffère pas fondamentalement d’une hausse du prix du produit
C’est réservé à Postgres, mais il existe aussi un projet nommé pgroll qui pousse l’automatisation un cran plus loin
En plus de Flyway (licence Apache), il existe encore largement des alternatives sous licence open source comme Atlas (Apache) ou Sqitch (MIT)
Je me demande si, du point de vue d’Elastic, leur changement de licence a vraiment été un échec
Le cours de l’action a baissé pendant un temps, mais l’entreprise elle-même reste solide
Tous les développeurs que je connais dans la recherche et le RAG utilisent toujours l’Elasticsearch fourni par Elastic NV (et ni un fork open source, ni une alternative)
Surtout si l’on regarde les principaux segments de clientèle qu’Elastic considère comme stratégiques, c’est-à-dire les clients payants, cela semble avoir produit l’effet inverse plutôt qu’une destruction de confiance
Le chiffre d’affaires réel a aussi doublé par rapport à 2020
Certains soutiennent encore que c’est de l’open source, mais Liquibase indique lui-même que la FSL n’est pas une licence open source
Voir l’annonce officielle sur le blog de Liquibase
C’est regrettable de voir autant de projets récents faire du branding en se donnant une image open source alors qu’ils ne font que publier le code source
Si Liquibase ne voulait pas d’un copyleft fort (par exemple la GNU AGPL) et a choisi Apache, il aurait naturellement dû s’attendre à ce que d’autres entreprises créent des dérivés propriétaires
Au final, c’est un choix fait par Liquibase lui-même, et j’estime donc que la responsabilité lui incombe aussi
Il semble que la structure prévoie une conversion automatique vers Apache après un certain délai
Je ne sais pas si c’est mieux ou non
En réalité, les entreprises peuvent tout à fait atteindre leurs objectifs avec des licences comme l’AGPL
Redis a aussi effectué cette transition, et la réaction de la communauté a été positive
Je ne pense pas que les utilisateurs se plaindraient si Liquibase adoptait une double licence AGPL
J’ai l’impression qu’il faudrait appeler cela « open source avec 2 ans de décalage » ou « open source au bout de 2 ans »
En pratique, j’ai plutôt l’impression que c’est « open source quand ça ne sert plus à rien »
À mes yeux, le fond du problème est qu’on donne une image de respect de la vraie liberté sans que ce soit réellement le cas
Il est rare qu’une ancienne version devienne inutile aussi vite
Je n’y vois pas un manque de respect envers ma liberté
Le but est d’imposer certaines restrictions aux entreprises (pas aux personnes)
Dans l’univers enterprise, l’essentiel de l’open source est moins la « liberté » que la confiance et la transparence
Le simple fait de publier le code permet déjà de profiter des avantages du FOSS sans les problèmes juridiques ou de monétisation
En ligne, on observe souvent une confiance presque aveugle dans le modèle open source
Je trouve qu’une politique hybride sur 2 ans est tout à fait raisonnable, et si l’on ne veut pas de la nouvelle licence, il suffit d’utiliser l’ancienne version
Open source différé, avec une ambiguïté comparable à l’anglais
late#source-washing
Si vous ne connaissez pas encore bien cette nouvelle licence, voir ce lien d’explication détaillée sur la FSL
Contexte supplémentaire sur la FSL : elle a été créée par Sentry ; vous pouvez voir sur le blog de Sentry pourquoi cette licence était jugée nécessaire et quels problèmes elle cherchait à résoudre
Personnellement, la seule licence propriétaire que je serais prêt à accepter est la BuSL, la « Business Source License »
Au bout de 4 ans, elle devient obligatoirement open source, tout en laissant le code visible avant cela
Cela évite aussi la prolifération inutile des licences
Le wiki sur la Business Source License peut aussi être utile
Je me demande si une période de 2 ans n’est pas trop courte
Du point de vue d’une grande entreprise, on utilise très bien des logiciels vieux de 5 ans, et personnellement une version 2012 de Redis ou une version 2020 de Postgres me conviennent tout à fait
J’ai déjà compilé l’historique de ce type de cas ainsi qu’une liste d’entreprises
Tout est regroupé dans ce billet de blog connexe ; si vous connaissez d’autres exemples, n’hésitez pas à les partager
Les fonctionnalités pro cassaient sans cesse la syntaxe de la version communautaire, donc je n’y voyais absolument aucune transparence
Bien sûr, il faut une juste rémunération du travail, mais le schéma du « nous étions open source puis nous ne le sommes discrètement plus » devient beaucoup trop courant
Ces transitions semblent toujours se faire en silence, comme si l’on espérait que personne ne s’en aperçoive
Je me demande quel est exactement le préjudice concret ou le principal problème
Au contraire, j’aime bien la distinction entre usages concurrents et non concurrents
L’ambiance des commentaires me paraît un peu étrange
La plupart semblent voir simplement « base » et recommander des services sans rapport, ou affirmer que si le code est publié, alors c’est de l’open source
Je ne savais pas que Liquibase avait changé de licence
En réalité, il existe des alternatives à presque tous les frameworks web, ainsi que des alternatives indépendantes du framework comme Alembic et Flyway
À ce stade, cela paraît un peu bizarre
Cette question pourrait aussi poser problème à des projets OSS comme Keycloak
Selon les règles de la CNCF, les licences non open source ne peuvent pas être utilisées ; Keycloak ne peut donc pas utiliser Liquibase
Comme Debian, Fedora et d’autres imposent aussi des critères de licence OSS, je me demande si des projets dépendant de Liquibase pourront être inclus dans ce type de distribution
Lien détaillé vers l’issue Keycloak
En revanche, il peut être proposé via des dépôts individuels ou des dépôts personnalisés comme rpm fusion non-free