Fin du logiciel libre gratuit chez Bitwarden

 (github.com/bitwarden)
1 points par GN⁺ 2024-10-21 | 2 commentaires | Partager sur WhatsApp
  • Le build Bitwarden Desktop 2024.10.0 requiert désormais la dépendance @bitwarden/sdk-internal, et une controverse a été soulevée car la licence de ce SDK le limite en indiquant qu’il ne peut pas être utilisé pour développer des applications pour des logiciels autres que Bitwarden ni d’autres SDK, ce qui contreviendrait aux critères du logiciel libre
  • L’auteur du signalement estime que cette restriction viole la freedom 0 du GNU et indique que sans supprimer cette dépendance, il est impossible de compiler desktop-v2024.10.0 ainsi que probablement la branche master actuelle
  • Comme cas de reproduction, en supprimant le répertoire bitwarden_license puis en nettoyant node_modules avant le build, l’étape build:preload échoue avec 6 erreurs TS2307 indiquant que @bitwarden/sdk-internal et le module WASM sont introuvables
  • Certains commentaires ont fait remarquer que le SDK est utilisé via des feature flags non seulement dans Desktop mais aussi dans les browser, CLI, web clients ; Bitwarden a répondu que le SDK et les clients sont des programmes distincts et qu’au regard de la GPLv3, communiquer via des protocoles standards n’en fait pas un seul programme
  • Bitwarden a ensuite ajusté l’organisation du code et le packaging du SDK pour permettre des builds incluant uniquement des licences GPL/OSI, puis a déplacé les références client à sdk-internal vers un nouveau dépôt sdk-internal, avant de marquer l’issue comme résolue

Problème soulevé : build Desktop 2024.10.0 et licence du SDK

  • L’issue a été ouverte pour signaler que Bitwarden Desktop 2024.10.0 ne serait plus un logiciel libre
  • Le changement central est que la Pull request #10974 a introduit la dépendance @bitwarden/sdk-internal dans le build du client desktop
  • La licence de cette dépendance contient la restriction suivante
    • « Ce SDK ne peut pas être utilisé pour développer des applications pour des logiciels autres que Bitwarden, y compris des implémentations incompatibles avec Bitwarden, ni pour développer d’autres SDK »
  • L’auteur du signalement considère que cette clause viole la freedom 0 de la définition GNU du logiciel libre
  • Il précise également qu’il n’est pas possible de compiler desktop-v2024.10.0, et probablement la branche master actuelle, sans retirer cette dépendance

Échec de build reproduit

  • L’auteur du signalement a tenté un build comme auparavant, en supprimant le répertoire bitwarden_license et avec des node_modules nettoyés
  • Le build échoue à l’étape build:preload de apps/desktop
  • L’erreur est un TS2307 indiquant dans plusieurs fichiers que le module @bitwarden/sdk-internal ou ses déclarations de type sont introuvables
    • libs/common/src/platform/abstractions/sdk/sdk.service.ts
    • libs/common/src/platform/abstractions/sdk/sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/default-sdk.service.ts
    • libs/common/src/platform/services/sdk/default-sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/noop-sdk-client-factory.ts
  • Une erreur signale aussi que le chemin WASM @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm est introuvable
  • Au final, webpack 5.94.0 échoue à compiler avec 6 erreurs, et npm run build:preload se termine avec le code 1

Réactions de la communauté et inquiétudes élargies

  • Un commentaire cite comme issue liée bitwarden/sdk-sm#898 et exprime l’inquiétude que Bitwarden, tout en se présentant comme open source, soit en train de basculer vers un logiciel propriétaire
  • Un autre utilisateur indique avoir signalé un problème similaire sur la release NPM du client CLI dans #10648 deux mois plus tôt, sans recevoir de réponse
  • Certains utilisateurs ont mentionné comme alternatives un fork d’une version précédente, Vaultwarden, ou encore une application desktop Tauri enveloppant l’interface web de Vaultwarden
  • Un commentaire souligne que, compte tenu de la nature du produit qui gère des mots de passe, migrer vers « n’importe quelle alternative » doit se faire avec prudence, et qu’un simple fork du client ne résout pas la dépendance au service serveur ou au logiciel serveur
  • Un autre commentaire affirme que le SDK est utilisé via des feature flags non seulement dans la release Desktop mais aussi dans les browser, CLI, web clients, et que toutes les versions de Bitwarden 2024.10.0 utilisent le SDK

Réponse initiale de Bitwarden

  • Un membre de Bitwarden a répondu que l’usage du SDK dans les clients s’était étendu, mais que l’objectif restait de conserver la compatibilité GPL de cet usage
  • Bitwarden a avancé les trois arguments suivants
    • Le SDK et les clients sont des programmes distincts
    • Le code de chaque programme se trouve dans un dépôt séparé
    • Le simple fait que les deux programmes communiquent via des protocoles standards n’en fait pas un seul programme au regard de la GPLv3
  • Bitwarden a indiqué que l’impossibilité de compiler l’application selon la méthode utilisée par l’auteur relevait d’un bug qu’ils prévoyaient de corriger
  • La discussion a ensuite été verrouillée par Bitwarden et limitée aux collaborateurs

Ajustements finaux et clôture

  • Bitwarden a indiqué avoir ajusté l’organisation du code du SDK et sa méthode de packaging afin de permettre de compiler et d’exécuter l’application en n’incluant que des licences GPL/OSI
  • Les références du client au package sdk-internal ont été modifiées pour pointer vers le nouveau dépôt sdk-internal
  • Bitwarden explique que ce nouveau dépôt sdk-internal suit le modèle de licence déjà utilisé auparavant pour les clients existants, et renvoie pour cela à LICENSE_FAQ.md
  • Actuellement, la référence sdk-internal n’utilise qu’une licence GPL
  • Si du code sous Bitwarden License devait à l’avenir être inclus dans cette référence, Bitwarden dit qu’une méthode permettant de créer plusieurs variantes de build serait fournie, à l’image du build du client web vault
  • L’ancien dépôt sdk est renommé sdk-secrets et conserve la structure de licence Bitwarden SDK License existante pour le produit professionnel Secrets Manager
  • Comme le dépôt et les packages sdk-secrets correspondent à du code non utilisé par les applications clientes, ils ne sont désormais plus référencés par celles-ci
  • L’issue a été clôturée le 25 octobre 2024 avec le statut completed

À lire aussi

2 commentaires

 
tribela 2024-10-21

J’utilise assidûment KeePass, et comme tout le monde ne parle que de Bitwarden, je me disais que j’allais peut-être l’essayer, mais je vais finalement rester sur KeePass. Comme ce n’est pas un système basé sur serveur et qu’il suffit simplement de bien conserver le fichier, sa disponibilité est bien meilleure ; KeePass correspond donc davantage à mes préférences.
 
GN⁺ 2024-10-21
Réactions sur Hacker News

  • J’ai payé parce que je m’attendais à soutenir l’open source, et c’est pour ça que j’ai quitté LastPass pour Bitwarden
    Cette histoire donne l’impression de tourner le couteau dans la plaie. Le CEO Michael Crandell semble avoir atteint un point d’inflexion financier similaire à celui de la vente de RightScale, donc on dirait qu’ils se préparent à une acquisition : https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • Même dans ce document de 2022, sous « Qu’est-ce qui change ? », Bitwarden disait qu’il continuerait à respecter une architecture open source
      On dirait que ce n’est plus le cas. C’est une évolution risquée. L’open source a beaucoup de qualités, mais ici l’essentiel, c’est la sécurité. Ça m’étonnera toujours de voir des entreprises affirmer qu’un bloc binaire opaque est sûr. C’était déjà le cas avec Intel Management Engine, et maintenant Bitwarden rejoint en quelque sorte IME et les switchs Juniper
      Passer en code source fermé est un choix à haut risque. Pendant longtemps, je n’ai pas payé pour le logiciel lui-même, mais je peux payer pour la sécurité, et c’est ce que je fais. Si je paie Bitwarden, c’est parce qu’il stocke ce que je considère comme mes informations les plus précieuses et les plus privées. Mais au fond, ce n’est qu’un logiciel, et peu importe d’où viennent les octets qu’on appelle « bitwarden ». N’importe qui peut forker et fournir les mêmes octets. Si quelqu’un exploitait un miroir Bitwarden n’utilisant que des logiciels open source, c’est là que partirait mon argent. Avec, idéalement, des instructions de build permettant de reproduire à l’identique les binaires en cours d’exécution et ceux que je télécharge sur plusieurs appareils. Je ne considère pas mes mots de passe comme sûrs tant qu’ils ne sont pas gérés par un logiciel open source

  • Ce virage n’est pas vraiment surprenant. Bitwarden s’est fortement déplacé vers la vente aux entreprises ces dernières années, tout en délaissant le grand public
    Ce n’est que récemment qu’ils sont passés de l’ancien socle MAUI à une app iOS native, et l’ancienne application était trop étrange à bien des égards. Le client iOS actuel a encore du retard à rattraper
    Depuis l’arrivée du capital-risque, ils semblent davantage guidés par le chiffre d’affaires et le profit. Ce n’est pas forcément un mauvais choix en soi, mais cela pousse l’entreprise dans une direction assez différente de celle avec laquelle elle a démarré et grandi
    Proton Pass est aussi un peu intéressant, mais comme les autres services Proton, leur modèle tarifaire paraît toujours légèrement trop élevé. J’utilise la version gratuite de Proton Pass depuis quelque temps, et comme Bitwarden ne s’est pas amélioré dans la direction que j’attendais depuis des années, je vais voir si ça vaut le coup de migrer vers une alternative
    Le gestionnaire de mots de passe intégré à iOS est tout à fait correct, mais il est limité aux mots de passe et ne prend pas en charge le stockage, la recherche et l’auto-remplissage d’autres types de données

    • C’est ironique. Certaines entreprises utilisaient peut-être justement Bitwarden parce qu’il était ouvert, et parce qu’on pouvait utiliser quelque chose de très utile sans devoir passer par un appel commercial enterprise
      Si vous rendez le produit plus difficile à utiliser, vous perdez des clients et des opportunités commerciales. Ça me rappelle les appels atroces que j’ai eus récemment avec Postman. À ce stade, Hoppscotch paraît bien meilleur plutôt que de devoir encore passer un appel
    • Pourquoi est-ce que le capital-risque finit presque toujours par tout gâcher

  • La réponse du CTO dit qu’ils ont étendu le périmètre d’usage du SDK à davantage de cas côté client, mais que l’objectif est que le SDK soit utilisé d’une manière qui préserve la compatibilité GPL
    Le SDK et les clients sont des programmes distincts, le code de chaque programme est dans un dépôt séparé, et le simple fait que les deux programmes communiquent via un protocole standard n’en fait pas un seul programme au regard de la GPLv3. Le problème qui empêche de builder l’app de la manière tentée ici serait un simple bug qu’ils comptent corriger

    • Ce genre de réponse est vraiment frustrant, parce qu’elle esquive la vraie question en en déformant délibérément le cadre
      En gros, ce que j’aimerais demander au CTO, c’est : vous avez répondu à « vos avocats pensent-ils que vous pouvez vous en sortir légalement ? », mais pas à la vraie question qui inquiète les gens. L’équipe Bitwarden considère-t-elle qu’il n’y a aucun problème éthique à privatiser un projet que beaucoup ont soutenu et auquel ils ont contribué explicitement parce qu’il était open source ? La gestion de mots de passe est une activité qui repose par nature sur un très haut niveau de confiance : comment comptez-vous gérer la rupture de confiance, les forks et les départs qu’un rug pull de l’open source vers le fermé va provoquer ? Si l’entreprise est dans une situation assez désespérée pour envisager ce type de décision, n’y a-t-il pas un moyen pour la communauté d’aider à traverser ça sans privatisation ?
      Je comprends qu’en tant que CTO, votre rôle en ce moment est de faire semblant de vous inquiéter, surtout sur un forum où vous ne pouvez pas verrouiller la discussion, mais l’approche actuelle confirme pratiquement la pire crainte possible : « nous pensons que c’est légalement faisable, et nous ne voyons aucun problème dans notre comportement ». C’est exactement le mauvais signal à envoyer pour une entreprise qui gagne de l’argent parce que les utilisateurs doivent faire confiance au code et à ceux qui le mettent à jour
    • Autrement dit, bitwarden/clients est sous GPLv3, mais le client Bitwarden dans son ensemble fonctionnel est un logiciel propriétaire, et le CTO considère que cela ne pose aucun problème, après quoi l’issue a été verrouillée
    • La question n’est pas forcément de savoir si c’est « un seul programme ». Le problème, c’est ce passage
      « Le “code source correspondant” d’une œuvre sous forme de code objet désigne tout le code source nécessaire pour générer, installer, faire fonctionner le code objet et modifier l’œuvre, y compris les scripts servant à contrôler ces activités. »
      Je comprends qu’il est vraiment difficile de gagner de l’argent en tant qu’entreprise open source. C’est d’ailleurs pour ça que je suis moi-même client payant
      L’exception ajoutée au SDK ressemble énormément au logiciel de gestion de versions BitKeeper, qui a été utilisé pendant un temps avec le noyau Linux. Il suffit de voir comment cela s’est terminé

  • J’aimais le produit, j’ai payé, je l’ai recommandé à des amis, et eux aussi l’ont aimé
    Maintenant, je vais passer à KeePassXC. Quelle est la méthode recommandée pour synchroniser la base de données avec Android ? Je n’ai qu’un serveur Raspberry Pi qui fait tourner cloudflared

    • Si vous voulez conserver la commodité du cloud sans retomber dans des conflits de synchronisation liés au déplacement de fichiers, Proton Pass est sous GPLv3. En revanche, je ne sais pas personnellement ce qu’il en est de l’auto-hébergement s’ils décident un jour de faire un rug pull
      https://github.com/ProtonMail/WebClients/tree/proton-pass%40...

https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...

[https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE](<https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE>;)

  • J’utilise SyncThing pour distribuer précisément le coffre KeePass uniquement aux appareils nécessaires. Chez moi, ça fonctionne très bien. Cela peut varier selon les besoins

  • J’aimerais vraiment utiliser KeePass et tout son écosystème, mais le partage de mots de passe n’est pas terrible. Ma femme et moi avons beaucoup de mots de passe partagés, et Bitwarden gère cet aspect extrêmement bien. Je ne sais pas quelle serait une alternative pratique pour nous

  • Keepass2Android peut se synchroniser de plusieurs façons, comme ssh(sftp), Nextcloud, etc. Il devrait être possible de trouver une méthode adaptée

  • La combinaison KeePassXC + client Nextcloud pour Android est parfaite pour moi. Je l’utilise depuis des années sans aucun problème

  • Ils ont verrouillé l’issue GitHub pour empêcher toute poursuite de la discussion. L’une des alternatives possibles semble être Vaultwarden
    https://github.com/dani-garcia/vaultwarden
    C’est vraiment triste de voir ce genre de chose continuer à arriver dans les projets open source dès que des gens fortunés entrent dans la danse

    • Vaultwarden est un remplacement côté serveur, et ici le problème est, si j’ai bien compris, la licence du client desktop
    • García a récemment commencé à travailler chez Bitwarden. Ce serait intéressant d’avoir son point de vue
    • Vaultwarden prend-il en charge les passkeys ?

  • Je n’avais jamais regardé ça de près, mais à force de marketing j’avais l’impression que Bitwarden était entièrement un logiciel libre. Or il semble qu’autour de 2020, des éléments propriétaires étranges aient commencé à s’y glisser

  • J’espérais migrer vers Bitwarden un jour, mais si je n’y trouve pas un écosystème ouvert sain, je pense que je ne le ferai plus. Je vais quand même continuer à suivre l’évolution de la situation

    • J’ai essayé une migration complète vers Bitwarden pendant un an avec un backend Vaultwarden, et par rapport à 1Password que j’utilisais auparavant, l’expérience était nettement inférieure
      L’un de mes critères d’évaluation était : « toute la famille utilise 1Password et en est satisfaite, est-ce que c’est assez bien pour que je puisse les convaincre de migrer ? » Je peux décider seul de la migration finale, mais pour amener mes parents âgés à adopter quelque chose de nouveau, l’expérience utilisateur est absolument cruciale
      Et au final, la réponse a été non. En dehors d’une UX globalement médiocre, les clients Bitwarden étaient bien plus lents sur Linux, Mac, Windows et iOS, de la recherche à la connexion en passant par tout le reste. Il y avait aussi moins de fonctionnalités, avec l’absence d’éléments visibles comme le tri des mots de passe, les favoris et de bons outils d’organisation, et le remplissage automatique était aussi beaucoup moins fiable
      J’ai eu de gros reproches pendant des années sur la manière dont 1Password fait du business et traite ses clients. Malgré cela, j’ai fini par revenir en arrière à contrecœur, parce que je considère qu’un gestionnaire de mots de passe — désormais presque un gestionnaire de secrets contenant bien plus que des mots de passe — est au centre de la vie quotidienne, et qu’il faut donc utiliser l’option la moins pénible possible
      Je n’utilisais pas Bitwarden parce que le code était ouvert, mais parce que j’essayais d’utiliser le meilleur gestionnaire de mots de passe possible. Cela dit, le fait qu’il soit ouvert me plaisait, et Vaultwarden est une pépite. J’aimerais vraiment avoir le temps et les compétences pour créer un meilleur frontend

  • « Pour le moment, nous n’avons pas prévu de modifier la licence du SDK. Nous continuerons à publier sur notre dépôt F-Droid dédié https://mobileapp.bitwarden.com/fdroid/repo/ ».
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Ce problème avait déjà été soulevé en juillet dans le dépôt du SDK, et ce SDK utilisait cette licence depuis plus d’un an

  • J’utilise Bitwarden sur iOS, PC et Mac. Il va maintenant falloir que je cherche une alternative. C’est vraiment une triste journée
    Moi aussi, je suis abonné premium à 10 dollars par an. Cela fera donc du chiffre d’affaires perdu à cause de pratiques douteuses
    Existe-t-il un moyen d’exporter puis de migrer vers une autre alternative ?

  • C’était un projet que je suivais en me demandant s’il pourrait constituer une meilleure alternative à Keepass(X,XC) pour moi, mais maintenant j’ai l’impression que je ne migrerai finalement pas