Redis adopte une double licence source available
(redis.com)- À partir de Redis 7.4, Redis abandonne la distribution sous BSD 3-Clause et modifie fortement les frontières de licence en proposant désormais Redis sous RSALv2 ou SSPLv1
- Le code source reste disponible gratuitement en tant que Redis Community Edition, mais les nouvelles licences ne relèvent pas de l’open source au sens de l’OSI
- Redis prévoit d’unifier Core et Stack afin de regrouper dans un seul package gratuit la recherche, JSON, les vecteurs, les structures de données probabilistes et les modèles de données de séries temporelles
- L’usage interne ou personnel, les bibliothèques clientes, les partenaires d’intégration et les clients Redis Enterprise existants ne sont pas affectés, mais les services managés concurrents ne peuvent pas utiliser gratuitement le nouveau code source de Redis
- À partir de Redis 8, les fonctionnalités de Redis Stack seront intégrées à Redis lui-même, puis les builds Redis Stack séparés arriveront en fin de vie
Portée du changement de licence de Redis
- Toutes les futures versions de Redis seront distribuées sous une licence source available
- À partir de Redis 7.4, le logiciel Redis Core pourra être utilisé soit sous Redis Source Available License v2, soit sous Server Side Public License v1
- Il ne sera plus distribué sous licence BSD 3-Clause
- Le code source de Redis restera disponible gratuitement via le dépôt GitHub de Redis, sous forme de Redis Community Edition
- RSALv2 et SSPLv1 ne sont pas des licences approuvées par l’OSI et comportent chacune des restrictions d’utilisation
Intégration de Redis Stack et évolution de l’offre produit
- Les prochaines versions source available unifieront Redis Core et Redis Stack
- L’intégration couvre la recherche, JSON, les vecteurs, les structures de données probabilistes et les modèles de données de séries temporelles
- Le tout sera proposé dans un seul package gratuit à télécharger, et Redis pourra être utilisé comme :
- stockage clé/valeur haute performance
- stockage de documents
- moteur de requêtes
- base de données vectorielle à faible latence pour les applications d’IA générative
- À partir de Redis 8, les nouveaux types de données et moteurs de traitement auparavant fournis dans Redis Stack sous RSALv2 ou SSPLv1 devraient être inclus par défaut
- Après la disponibilité de Redis 8, les builds Redis Stack séparés ne seront plus nécessaires et Redis Stack entrera en fin de vie
Contexte du changement et position de Redis
- Redis indique avoir déjà appliqué une double licence aux modules Redis avancés de la distribution Redis Stack, et que plus de 50 % des téléchargements depuis redis.io depuis Redis 6 provenaient de Redis Stack
- Redis estime que maintenir simultanément plusieurs distributions entre en conflit avec ses futurs efforts de développement
- distribution open source
- distribution source available
- logiciel commercial optimisé pour les plateformes on-premise et cloud
- Redis considère que de grands fournisseurs de services cloud marchandisent ses investissements et la communauté open source
- Ce changement vise à encadrer les usages commerciaux afin de continuer à investir dans un logiciel gratuit riche en fonctionnalités et dans ses produits d’entreprise
- Avec ce changement, Redis n’est plus open source au sens de la définition de l’OSI
Impact pour les utilisateurs et partenaires
- Les utilisateurs finaux qui utilisent les versions open source existantes de Redis ou les nouvelles versions à double licence à des fins internes ou personnelles ne sont pas affectés
- Les partenaires qui créent des bibliothèques clientes ou d’autres intégrations avec Redis ne sont pas non plus concernés par ce changement
- Toutes les bibliothèques clientes Redis dont Redis est responsable conserveront une licence open source
- Les clients Redis Enterprise existants ne sont pas affectés, car ils reçoivent la technologie selon des conditions de licence négociées séparément
- Les partenaires d’intégration et de services managés qui utilisent Redis Community Edition ou Enterprise dans un cadre non concurrentiel pourront continuer à concevoir, exploiter et fournir des solutions via leur partenariat avec Redis
- Le Partner Program donnera à l’avenir un accès exclusif aux technologies, fonctionnalités et versions de Redis
Restrictions pour les services cloud et offres concurrentes
- Avec les nouvelles licences, les fournisseurs de services cloud proposant des services d’hébergement Redis ne peuvent pas utiliser gratuitement le code source de Redis
- Par exemple, un fournisseur de services cloud ne pourra proposer Redis 7.4 qu’après s’être mis d’accord sur les conditions de licence avec Redis, mainteneur du code Redis
- Une « offre concurrente » de Redis désigne un produit dérivé de la base de code Redis, dont les fonctionnalités recoupent largement celles des produits commerciaux Redis, et vendu à des tiers
- Cela inclut la vente via des contrats de support payants
- Par exemple, l’hébergement ou l’intégration de Redis dans une solution vendue en concurrence avec Redis Enterprise Software ou Redis Cloud
- Les solutions qui utilisent Redis sans concurrencer spécifiquement Redis lui-même ne sont pas affectées
- Les questions sur des cas d’usage particuliers sont renvoyées vers redis_licensing@redis.com
Conditions de RSALv2 et SSPLv1
- RSALv2 est une licence permissive de type non-copyleft, qui autorise l’utilisation, la copie, la distribution, la mise à disposition et la préparation d’œuvres dérivées du logiciel
- Les principales restrictions de RSALv2 sont au nombre de deux
- Il est interdit de commercialiser le logiciel ou de le fournir à d’autres personnes sous forme de service managé
- Il est interdit de supprimer ou de masquer la licence, les mentions de droit d’auteur et les autres avis
- SSPLv1 est basée sur l’AGPL et impose, si le logiciel est fourni sous forme de service, de publier sous SSPL le code source de l’ensemble du service
- Cela inclut les logiciels de gestion, les interfaces utilisateur, les API, les logiciels d’automatisation, la supervision, les sauvegardes, le stockage et les logiciels d’hébergement
- MongoDB est l’éditeur de cette licence
- Une version modifiée d’un logiciel sous licence SSPL ne peut pas être redistribuée sous une autre licence
- Dans le cadre de la double licence, choisir RSALv2 permet de modifier et de redistribuer le logiciel dans la mesure où les restrictions de RSALv2 sont respectées, notamment le fait de ne pas fournir ses fonctionnalités à des tiers sous forme de service
Versions BSD existantes et correctifs de sécurité
- Le changement de licence n’est pas rétroactif
- Tout le code source et toutes les versions antérieurs au changement restent sous licence BSD 3-Clause
- Les utilisateurs peuvent continuer à utiliser indéfiniment les versions BSD existantes tant qu’ils respectent les conditions de cette licence
- Redis prévoit de continuer à fournir, conformément à sa politique de sécurité actuelle, les mises à jour de sécurité et les correctifs de défauts critiques pour ces versions jusqu’à la disponibilité de Redis Community Edition
- Les rétroportages de correctifs de sécurité critiques pour les versions BSD 3-Clause existantes seront fournis jusqu’à la sortie de Redis Community Edition 9.0 ; ensuite, les correctifs seront fournis sous la nouvelle double licence
Nom, contributions et conditions de mélange du code
- Redis 7.2 et les versions antérieures continueront d’être appelées Redis OSS
- À partir de Redis 7.4, la version publique et gratuite s’appellera Redis Community Edition
- Les noms de produits ne pourront plus utiliser « Redis » ni « for Redis », mais les descriptions de produits pourront indiquer une compatibilité avec Redis ou une base legacy-Redis
- Les contributions de la communauté continueront d’être acceptées, mais l’acceptation du Contributor License Agreement sera nécessaire pour l’examen des contributions
- Le code sous RSALv2 ou SSPLv1 peut être utilisé avec du code sous d’autres licences, à condition que chaque composant conserve sa propre licence et qu’il ne soit pas mélangé avec du code à copyleft fort comme la GPL
- L’hébergement de Redis sous forme de service au sein d’une organisation est autorisé, l’organisation incluant ses sociétés affiliées et filiales
1 commentaires
Commentaires sur Hacker News
Cela risque fort de nuire à Redis Labs, comme Hashicorp qui perd du terrain et cherche un acquéreur, sans pour autant empêcher ceux qui voudraient copier Redis Labs
Ceux qui vont vraiment en pâtir, ce sont les petites startups qui veulent utiliser le cache Redis sans casse-tête juridique. AWS peut forker Redis, et si ce fork sort ensuite sous une licence permissive, Redis Labs pourrait devenir l’option la moins attractive du point de vue de la licence
C’est un choix difficile, mais il vaudrait mieux soit garder le code propriétaire, soit rester sur Apache ou MIT. Changer de licence en cours de route est vraiment une mauvaise idée, et cela semble voué à se retourner contre eux
L’open source, c’est permettre aux utilisateurs de s’approprier le logiciel. Quand on essaie de contourner cela par des artifices juridiques pour gagner de l’argent, ce ne sont pas les équipes des grandes entreprises qui souffrent, mais les utilisateurs. Redis a toujours été un projet open source permissif, et c’est précisément pour cela qu’il a réussi. Si on change cette base, tous les calculs pour l’avenir changent aussi, avec de mauvaises conséquences pour tout le monde
Il faut voir plus clairement la différence entre un logiciel détenu par une fondation, comme PostgreSQL, et un open source détenu par une entreprise. Quand on se concentre sur la « maximisation de la valeur actionnariale », l’objectif de préserver la liberté des utilisateurs finit inévitablement au second plan
Du point de vue de la communauté Redis, il aurait bien mieux valu qu’Antirez sépare la relation d’emploi de la propriété du projet et le confie à une structure à but non lucratif. Une forme de type Apache Redis aurait été meilleure pour la communauté, et Redis Labs aurait toujours pu bâtir autour de cela des extensions propriétaires et une activité cloud
On a vu encore et encore qu’une fois qu’une entreprise publie son logiciel cœur sous licence permissive, un concurrent plus grand arrive et vend une solution qui redistribue ce logiciel
Si l’objectif central de l’entreprise est le profit, c’est une menace existentielle. En revanche, si son objectif est d’assurer, comme gestionnaire à but non lucratif, la pérennité du logiciel, alors c’est une réussite totale
Cette logique ne s’applique pas aux logiciels secondaires qui ne sont pas le produit principal, par exemple des outils utiles développés en interne mais qui ne sont pas vendus directement
Ce changement de licence vise précisément ce problème : empêcher les hyperscalers du cloud de profiter du travail sans contrepartie
Pour moi, cela ressemble à un meilleur AGPL. Je me moque des nuances philosophiques ou du fait que ce soit approuvé par l’OSI ou non ; au final, c’est bien moins restrictif que l’AGPL. Le code source est là, on peut l’exécuter en local, et l’utiliser de la même façon dans mon projet, dans des projets commerciaux, au travail, sur bare metal, en VM, avec Docker, k8s ou sur Azure
Le fait que Microsoft doive partager une partie de la prime qu’il capte déjà ne me concerne pas. Au contraire, il faut saluer le fait d’avoir trouvé un modèle économique durable
Les développeurs OSS conservent le copyright. En dehors du domaine public, seuls les auteurs peuvent modifier la licence et ses conditions. Les utilisateurs reçoivent une licence leur permettant de faire diverses choses avec le logiciel et son code, mais ils n’en deviennent pas propriétaires
Je suis entièrement d’accord, et j’ai l’impression que cela ajoute un exemple de plus à la thèse de Cory Doctorow
À l’heure qu’il est, un fork est probablement déjà en cours. C’est un peu triste de voir une entreprise se couper elle-même de sa communauté de développeurs
Je comprends pourquoi ils font ça, mais je ne pense pas que ce soit viable à long terme
La plupart des utilisateurs de Redis n’ont jamais versé un centime à l’entreprise derrière, et moi non plus. Je comprends qu’ils fassent ça pour gagner de l’argent, mais cela ne changera pas mon comportement. J’utiliserai simplement le fork. La plupart des autres utilisateurs de Redis, les contributeurs externes et tous les fournisseurs cloud qui proposaient Redis commercialement feront sans doute la même chose, et avec le temps, pas mal d’employés actuels de Redis pourraient aussi les rejoindre
Comme il y a beaucoup d’utilisateurs commerciaux et de fournisseurs cloud, je doute qu’il leur faille longtemps pour s’organiser. Il y a déjà beaucoup d’utilisateurs payants, donc c’est pratiquement inévitable
Il existe déjà des précédents similaires avec Terraform, Elasticsearch, Red Hat, etc. Faire en sorte qu’une grande partie de ses utilisateurs cibles et clients potentiels dépende d’un fork open source semble être une mauvaise direction sur le plan stratégique
Quand Oracle a repris les projets open source de Sun, comme mysql, hudson et openoffice, il a aussi rapidement perdu l’essentiel du contrôle. Les tentatives pour convaincre les gens d’utiliser les produits fermés d’Oracle n’ont pas vraiment donné de résultats. Même Java a fini par reculer dans une certaine mesure, et aujourd’hui le centre de gravité est openjdk. En dehors de quelques banques, presque personne n’utilise Oracle JDK de nos jours. Il n’y en a pas besoin, et Oracle a cessé depuis longtemps de prétendre qu’il y avait un avantage. Tout le développement se fait sur OpenJDK, et plusieurs entreprises proposent des builds certifiés
Je fais personnellement du conseil sur Elasticsearch et Opensearch, et récemment, la plupart des clients prennent Opensearch comme choix par défaut. C’est simplement l’évolution naturelle des choses. Tout le monde choisit l’option gratuite et open source
Il n’y a qu’une seule conclusion. Un fork de Redis sera créé, et c’est lui que la majorité des utilisateurs actuels de Redis finira par utiliser
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
Du point de vue de l’entreprise, ils peuvent accepter des hausses de prix pour éviter une migration complète, ou pendant qu’ils migrent à court terme
Pour éviter une fuite rapide, le fournisseur peut aussi “acheter du temps” en maintenant des prix bas, puis les augmenter une fois que le projet a suffisamment divergé du fork et qu’une migration devient bien plus difficile
Dans tous les cas, à long terme, il peut être plus rentable de gagner beaucoup d’argent avec quelques entreprises que de continuer à soutenir beaucoup d’entreprises de tailles variées. Je n’aime pas ça, mais ça me semble pouvoir fonctionner
Rien qu’en fragmentant la communauté MySQL, en freinant l’usage et le développement externe, et en ralentissant l’ensemble du projet, ils ont peut-être déjà obtenu un très bon retour sur investissement
Le grand moteur de ces projets reste les revenus d’hébergement, et c’est pour cela qu’on voit ces changements de licence
À voir la tendance, on dirait que le seul open source compatible avec une entreprise propriétaire du projet, ce sont les bibliothèques. Pour les programmes, par exemple les logiciels serveur comme les bases de données, il faut soit un modèle source-available, soit une gouvernance sous fondation. C’est difficile, et je ne sais pas quelle est la bonne réponse
J’aimerais voir émerger un modèle qui ramène des licences open source permissives pour les programmes complexes, mais pour l’instant je ne vois pas de solution viable. Cela pourrait passer par l’application stricte des marques, du code open source, et la fourniture de builds sous licence uniquement
Quoi qu’il en soit, on continuera sans doute à voir l’essor et le déclin des logiciels open source populaires, ou leurs changements de licence. Les avantages pour les développeurs et les entreprises à démarrer en open source sont trop importants au début, et la pression pour changer plus tard est trop forte
Je veux au moins reconnaître que Redis a apporté au monde bien plus de valeur qu’il n’en a capté. Et de très, très loin
Il sera intéressant de voir à quelle vitesse le fork sortira et réussira, et à quoi ressemblera la courbe de croissance du chiffre d’affaires de l’entreprise Redis dans 5 ans
Je ne connais pas bien les licences, mais je compatis fortement avec ces entreprises de taille petite ou moyenne qui créent la technologie de base et se retrouvent commoditisées puis revendues plus cher par des géants du cloud en situation d’oligopole. Je suis plutôt surpris que cela ait pris aussi longtemps
Si l’on veut un écosystème sain à la fois pour les entreprises et pour l’open source, je me demande quelles alternatives existent en dehors du changement de licence
Il y a beaucoup de cas où une seule entreprise a effectivement “forké” hors de la fondation, et la communauté s’est finalement retrouvée avec le même résultat
https://spdx.org/licenses/AGPL-3.0-or-later.html
Ceux qui fabriquent les outils de travail doivent aussi payer leurs factures
D’une certaine manière, les développeurs portent eux aussi une part de responsabilité dans l’échec du rêve du FOSS
On revient lentement à l’époque du domaine public et du shareware
On a toujours dit que le modèle pour gagner de l’argent avec l’open source, c’était les services de support. Par exemple, quand une entreprise utilise Postgres, des experts peuvent l’aider sur une configuration on-premise et intervenir en cas d’incident.
Mais à l’ère du « cloud », les entreprises se contentent d’utiliser les services managés proposés par Amazon, Microsoft, Google, etc., et les opportunités financières pour les mainteneurs du projet et leur entourage disparaissent pratiquement. Personne n’a envie de travailler d’arrache-pied sur un OSS pour voir ensuite AWS gagner des millions de dollars sans rien rendre en retour.
Madelyn Olson a fait ce travail difficile pendant des années alors qu’elle était employée par AWS, ce qui lui a valu la confiance des autres développeurs principaux de Redis, puis le statut de mainteneuse principale. Elle et d’autres développeurs AWS ont beaucoup contribué au moteur principal de Redis. On peut aussi dire qu’eux aussi ont travaillé dur pour la communauté Redis.
Vous pouvez en lire davantage sur ces contributions ici : https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
Davantage de projets open source devraient expérimenter l’adoption de la SSPL, ou une approche comme Llama 2 qui limite la gratuité d’usage selon la taille de l’entreprise. Par exemple, open source, mais pas pour les hyperscalers du cloud pesant des dizaines ou des centaines de milliards de dollars.
Quand des développeurs individuels contribuaient, ce n’était pas pour permettre à AWS de voyager gratuitement.
La principale raison pour laquelle les projets se tournent vers des licences plus restrictives, c’est AWS. La bonne chose à faire pour AWS aurait été de respecter le travail de l’auteur ou de l’entreprise d’origine, et de renforcer le produit soutenu par le développeur initial. À la place, AWS voit un produit OSS réussir et fabrique un concurrent. Avec une intégration plus poussée et une puissance marketing supérieure, les éditeurs tiers n’ont aucune chance.
En plus, Amazon et AWS sont parmi les grands, voire les plus grands bénéficiaires de l’open source, tout en rendant très peu en retour. Google, Microsoft, et même Oracle contribuent davantage à l’open source qu’Amazon.
Je n’ai jamais contribué à un projet avec CLA, et sauf si mon employeur me paie pour le faire, je ne compte pas commencer.
Mais pour la viabilité à long terme du FOSS, il peut être nécessaire d’avoir des restrictions pour nous protéger des grandes entreprises qui exploitent de fait les développeurs FOSS.
Redis, Mongo, ES, la gamme de produits HashiCorp, et tout l’écosystème big data ont gagné en notoriété grâce à leur présence sur AWS. Il existe aussi beaucoup de bases de données peu connues, développées depuis des années, dont personne n’a encore entendu parler parce qu’AWS ou d’autres grands fournisseurs cloud ne les ont pas mises en avant.
En outre, la popularité et l’usage accrus permis par une licence permissive apportent à de nombreux projets des contributions sous forme de rapports de bugs, PR et correctifs. Je n’ai pas vraiment envie de contribuer à des projets sous licences de type SSPL ou BSL. Je n’ai pas envie de perdre du temps sur quelque chose qui ne pourra pas être utilisé librement plus tard.
Si Redis était sorti avec des restrictions comparables à celles de Llama 2, il aurait échoué dès le départ. Les principaux consommateurs sont les entreprises, et si Llama 2 a gagné en popularité, c’est surtout parce qu’il a fourni très tôt un LLM de haute qualité que les particuliers pouvaient utiliser pour un usage personnel.
Un magasin clé-valeur compatible RESP n’a rien d’exceptionnel. Microsoft vient d’ailleurs de publier sa propre implémentation, garnet, sous licence MIT. La valeur de Redis a toujours été d’être gratuit et open source, ainsi que la communauté qui le soutenait. Maintenant, Redis a abandonné la principale raison de l’utiliser.
Mais c’est pratiquement le seul exemple que je connaisse ; pour MongoDB, Redis, Memcached, MySQL, PgSQL et presque tous les autres cas, ce n’est pas le cas.
Redis Inc. fait passer le projet https://github.com/redis/redis/ de la licence BSD à 3 clauses à une double licence composée de deux licences non approuvées par l’OSI.
Ils avaient pourtant déclaré auparavant que « Redis core license est sous licence 3-Clause-BSD et le restera toujours ». (https://redis.com/blog/redis-labs-modules-license-changes/)
Si l’arrêt du support vous inquiète, Redis 7.4 sera la première release sous la nouvelle licence, et 7.2 la dernière sous l’ancienne licence
Redis prend en charge deux releases supplémentaires à un moment donné : latest major.(minor-1), (major-1).(last-minor)
En gros, cela signifie que lorsque 8.0 sortira, le support de 6.2 prendra fin, et que lorsque 7.6 ou 8.0 sortira, le support de 7.2 prendra fin
En regardant les releases passées, on peut estimer que 8.0 sortira vers mars à mai 2025. Donc, si vous dépendez de Redis sous licence 3BSD, il faut planifier en conséquence
Ubuntu empaquette redis dans le dépôt
universe, donc les mises à niveau de sécurité ne sont fournies qu’aux clients Ubuntu Pro. Par conséquent, sur Ubuntu 20.04, les mises à jour de redis s’arrêtent en avril 2024, sauf pour les utilisateurs ESM d’Ubuntu ProDebian 11/12 suit Redis 6.0/7.0 et a donc la responsabilité de backporter les correctifs de 7.2. Si 7.2 ne reçoit pas de mises à jour de sécurité et qu’elles ne sont fournies que sur la branche 7.4, on ne sait pas clairement comment cela se passera
Même si votre mode d’utilisation direct est compatible avec la nouvelle licence, vous pouvez être affecté indirectement. Il est probable que des distributions retirent redis de leurs dépôts officiels dans une prochaine release, il faut donc en tenir compte lors du prochain cycle de mise à niveau de votre distribution
(Je maintiens https://endoflife.date/redis, donc si quelqu’un sait clairement quel sera l’impact sur la fin de support et le support, je peux fusionner une PR)
La nouvelle licence SSPL n’est très probablement pas open source, au moins à cause de la restriction des usages : https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
https://opensource.org/definition-annotated#6
C’est précisément le cœur de l’open source, et à certains égards du logiciel libre. Les licences copyleft imposent des contraintes, mais si vous les respectez, vous pouvez faire ce que vous voulez avec ce logiciel. Les licences SSPL, FSL et BUSL empêchent purement et simplement certaines formes de concurrence commerciale
Ce n’est pas parce que la plupart des business models ne veulent pas se conformer au copyleft que ce n’est pas open source. C’est simplement que cela ne convient pas à leur business model
De nouvelles licences comme la SSPL, la BSL et la FSL deviennent de plus en plus populaires, et il y a des raisons à cela. Il y a 20 ans, AWS ne revendait pas du FOSS au monde entier, donc les conditions étaient très différentes d’aujourd’hui
À cause de ces restrictions, ce n’est pas de l’« open source », mais le terme le plus proche ensuite, « source disponible », ne reflète pas bien la réalité non plus. Cela sonne plutôt comme si le code source existait techniquement quelque part
ElasticSearch, Sentry, etc. sont toujours développés publiquement, des personnes extérieures au projet peuvent toujours envoyer des PR, et tant qu’on n’essaie pas de concurrencer publiquement l’entreprise derrière le projet, chacun peut faire ce qu’il veut
En parallèle, Microsoft a publié Garnet : https://github.com/microsoft/garnet
Le timing est bon
Son raisonnement était que MS attirerait les gens puis changerait la licence quand cela l’arrangerait, et que Redis, lui, garderait donc toujours une licence open source. Quelle prédiction remarquable
Les fondateurs techniques de Redis et de Hashicorp semblent chacun être partis avant que leur entreprise ne s’éloigne du FOSS et ne déclenche une grosse tempête. Si le calendrier est bon, bien sûr
Je me demande s’ils savaient à l’avance que cela allait arriver et s’y opposaient, ou s’ils le savaient mais voulaient éviter l’atteinte à leur réputation. Qu’on soit d’accord ou non avec ce mouvement, il y a un coût réputationnel. Ou bien est-ce que leur départ a justement permis de faire passer ce changement ?
Ce n’est que de la spéculation, mais c’est frappant de voir dans Redis quelque chose qui ressemble à ce qui s’est passé chez Hashi
Moi non plus, je n’ai pas raté la similarité avec Hashi