Le SDK de Bitwarden relicencié de propriétaire à GPLv3

 (github.com/bitwarden)
3 points par GN⁺ 2024-10-25 | 2 commentaires | Partager sur WhatsApp
  • Le commit db648d7 de sdk-internal chez Bitwarden est une modification qui clarifie le libellé de licence du SDK, et sur HN il a été présenté comme un cas de relicenciation de propriétaire vers GPLv3
  • Le LICENSE à la racine a été largement remplacé, avec 295 lignes supprimées et 20 lignes ajoutées, et les nouveaux LICENSE_GPL.txt et LICENSE_SDK.txt deviennent le cœur de la structure de licence
  • Le workspace Rust inclut bitwarden_license/* parmi ses membres, et le chemin de dépendance de bitwarden-sm a été déplacé vers bitwarden_license/bitwarden-sm
  • Pour le crate bitwarden-sm, le principal changement est le déplacement de répertoire, et plusieurs fichiers src sont traités comme des renommages sans modification de contenu
  • bitwarden-sm/Cargo.toml ne s'appuie plus sur la valeur commune du workspace et pointe directement vers ../../LICENSE_SDK.txt pour indiquer le fichier de licence de ce crate

Ce qui a changé dans le commit

  • Le titre du commit de bitwarden/sdk-internal est « Improve licensing language »
  • Le titre HN présente ce changement comme « Le SDK de Bitwarden relicencié de propriétaire à GPLv3 »
  • Le diff GitHub inclut à la fois le remplacement de fichiers de licence et des modifications dans la configuration du workspace Rust

Réorganisation des fichiers de licence

  • Le fichier LICENSE à la racine est affiché avec 20 lignes ajoutées et 295 lignes supprimées
    • GitHub ne rend pas par défaut les grands diff, donc le contenu complet n'apparaît pas dans le corps
  • Un nouveau fichier LICENSE_GPL.txt a été ajouté
    • L'ampleur du changement est de 674 lignes ajoutées, 0 supprimée
  • Un nouveau fichier LICENSE_SDK.txt a aussi été ajouté
    • L'ampleur du changement est de 295 lignes ajoutées, 0 supprimée
  • La liste des éléments modifiés inclut aussi des LICENSE_GPL.txt côté Kotlin et Swift
    • languages/kotlin/sdk/src/main/resources/META-INF/LICENSE_GPL.txt
    • languages/swift/LICENSE_GPL.txt

Changement de chemins dans le workspace Rust

  • Les membres du workspace dans le Cargo.toml racine ont été étendus
    • Avant : members = ["crates/*"]
    • Après : members = ["crates/*", "bitwarden_license/*"]
  • Le chemin de bitwarden-sm dans les dépendances du workspace a lui aussi changé
    • Avant : crates/bitwarden-sm
    • Après : bitwarden_license/bitwarden-sm
  • Ainsi, bitwarden-sm n'est plus référencé sous crates, mais sous bitwarden_license

Déplacement de bitwarden-sm et indication de licence

  • crates/bitwarden-sm/Cargo.toml a été renommé en bitwarden_license/bitwarden-sm/Cargo.toml
  • La manière d'indiquer la licence dans bitwarden-sm/Cargo.toml a changé
    • Avant : license-file.workspace = true
    • Après : license-file = "../../LICENSE_SDK.txt"
  • Ce crate désigne donc directement LICENSE_SDK.txt au lieu d'utiliser le réglage commun du workspace pour le fichier de licence

Un diff plus proche d'une réorganisation de chemins que de changements de code

  • Plusieurs fichiers source Rust de bitwarden-sm ont été déplacés sans modification de contenu
    • client_projects.rs
    • client_secrets.rs
    • lib.rs
    • projects/create.rs
    • projects/delete.rs
  • Dans l'arborescence, les modules liés aux projets et aux secrets apparaissent eux aussi comme déplacés sous bitwarden_license/bitwarden-sm/src
  • Les éléments renommés visibles dans le corps montrent que l'accent est mis non sur des modifications de code, mais sur la réorganisation des chemins et de la structure de licence

À lire aussi

2 commentaires

 
unsure4000 2024-10-25

Immunité ++ ;
 
GN⁺ 2024-10-25
Avis sur Hacker News

  • Soulagé. L’entreprise aurait peut-être survécu d’une manière ou d’une autre, mais elle aurait eu beaucoup de mal à rester une entreprise appréciée des développeurs, et le prix à payer aurait été élevé.
    J’espère que Bitwarden a compris que le fait d’être un logiciel libre/open source (FOSS) est son avantage concurrentiel, et que c’est ce qui lui vaut une grande bienveillance. C’est d’ailleurs la raison pour laquelle j’utilise un produit qui n’est pas, à mes yeux, absolument le meilleur.
    Quand c’était du FOSS, l’affirmation audacieuse de « gestionnaire de mots de passe le plus fiable » se justifiait dans une certaine mesure ; mais si ce n’est pas du FOSS, même en mettant KeePass de côté, ce n’est plus du tout le cas.
    Je ne sais toujours pas exactement quoi penser de cette entreprise. J’ai retrouvé une certaine confiance dans le fait que les apps resteront des logiciels libres, mais ma confiance dans l’entreprise elle-même a un peu diminué, et je n’ai pas encore vu de communication officielle.
    Je ne vois pas en quoi lever 100 millions de dollars pourrait être bénéfique aux utilisateurs à long terme. Le résultat le plus probable me semble être une inflation fonctionnelle ou une dégradation du service.
    Bitwarden ne semble pas facile à forker. C’est un système complexe en C#, et l’existence de Vaultwarden aide beaucoup, mais les applications clientes sont encore un autre sujet.
    Comme garde-fou contre les comportements hostiles aux utilisateurs, la possibilité de forker est ce qu’il y a de plus important après l’open source lui-même. J’espère tout de même que ça se passera bien. J’ai commencé à utiliser Bitwarden récemment, et jusqu’ici l’expérience utilisateur est bien meilleure que celle de KeePass.

    • Je suis prudemment optimiste, mais la direction à long terme reste préoccupante.
    • Ce n’est pas aussi bien que de ne jamais avoir laissé planer de doute sur le caractère open source dès le départ, mais cela montre aussi qu’ils sont prêts à écouter les retours et à réexaminer les choses si les clients se mobilisent. C’est aussi une vieille histoire.
    • Il y a eu de la communication sur GitHub et sur les canaux officiels. Il semble clairement que le problème de dépendances ait été exagéré.

  • Merci à Bitwarden d’avoir remis cette partie sous une licence libre/open source.
    Cela dit, je ne recommande plus Bitwarden aux utilisateurs grand public, parce que le gestionnaire de mots de passe intégré à Firefox est devenu suffisamment bon.
    En revanche, je recommande toujours Bitwarden aux personnes qui ont besoin de fonctions plus avancées, ou qui ne font pas confiance au gestionnaire de mots de passe intégré à leur navigateur. Ajouter de la synchronisation à KeePassXC est trop compliqué pour les utilisateurs grand public.

    • Même les utilisateurs grand public ont souvent besoin d’un gestionnaire d’informations secrètes plus large qu’un simple outil qui stocke des URL de sites web et des mots de passe.
      Par exemple, ils ont besoin d’un endroit où mettre, dans un coffre chiffré, des secrets qui ne sont pas liés à des sites web : réponses aux questions de sécurité, alias e-mail associés, PIN du téléphone du conjoint, etc.
      Le gestionnaire de mots de passe de Firefox est trop basique, avec seulement deux champs, « nom d’utilisateur » et « mot de passe ». Pour les utilisateurs grand public, une meilleure expérience consiste à rassembler tous les secrets dans une seule application, plutôt que d’en stocker certains dans Firefox et le reste dans une autre app.
    • J’ai toujours eu l’impression que les gestionnaires de mots de passe intégrés aux navigateurs apportaient assez peu de valeur à la plupart des gens.
      Ils sont pénibles à utiliser sur mobile, dépendants de la plateforme, et il est facile de perdre des données locales non synchronisées. Les utiliser sur plusieurs appareils est aussi plus compliqué, surtout dans un contexte professionnel.
      À l’inverse, les gens comprennent généralement bien le modèle où ils installent une app sur chaque appareil et la laissent s’en charger.
    • Si Mozilla sortait une application de mots de passe séparée permettant de gérer et d’accéder aux mots de passe en dehors de Firefox, la comparaison avec Bitwarden serait plus pertinente.
      Les mots de passe deviendraient alors une partie du compte Mozilla, et non une simple fonctionnalité de Firefox. C’est un point sur lequel Bitwarden excelle, et c’est un peu le modèle à battre.
      Mozilla aurait l’avantage d’une intégration au navigateur quasiment fournie par défaut comme fonctionnalité de premier plan, mais si l’on n’utilise pas exclusivement Firefox, il est difficile de considérer qu’un seul navigateur est l’endroit approprié pour gérer ses mots de passe.
      J’apprécie le fait que Bitwarden permette de garder l’accès aux mots de passe « verrouillé » même quand le navigateur est ouvert. La dernière fois que j’ai regardé, Firefox demandait de saisir le mot de passe maître au lancement même quand on n’avait pas besoin de mots de passe, et le simple fait que le déverrouillage du coffre soit lié au lancement du navigateur suffisait à me faire renoncer.
    • Je suis content que Bitwarden ait réglé ça rapidement. En tout cas, pour moi, le gestionnaire de mots de passe de Firefox n’est pas une alternative.
      Bitwarden est approuvé dans mon entreprise, permet l’auto-hébergement, et prend en charge une multitude de connexions à des apps sur navigateur et appareils mobiles.
      Que ce soit dans des apps mobiles, des sites mobiles ou des sites dans le navigateur, ça fonctionne généralement bien. Il permet aussi de stocker des informations arbitraires comme des cartes bancaires, des notes sécurisées, la casse des réponses aux questions de sécurité, des informations de récupération de compte et des identifiants de connexion, ce qui est très pratique.
    • J’utilise à la fois Bitwarden et Firefox, mais je déconseillerais vivement d’utiliser le gestionnaire de mots de passe de Firefox.
      Savez-vous que la synchronisation des onglets de Firefox entre appareils est cassée ? Elle est en panne depuis le 24 août et n’est toujours pas corrigée : https://bugzilla.mozilla.org/show_bug.cgi?id=1913795
      S’ils n’arrivent même pas à synchroniser les onglets entre appareils, j’ai du mal à faire confiance à la synchronisation de mes mots de passe.

  • C’est bien de voir Bitwarden corriger le tir ici. Comme je n’avais pas vraiment envie de migrer vers un autre gestionnaire de mots de passe, j’en suis plutôt satisfait.

    • Pareil pour moi. Je suis abonné à Bitwarden, mais avec cette histoire de licence, je regardais récemment les alternatives.
      Changer de gestionnaire de mots de passe est pénible, donc je suis content de ne plus avoir l’impression de devoir absolument migrer.

  • Bitwarden reste excellent, mais il faudra surveiller les prochaines années. Il faut se rappeler que Bitwarden a justement commencé comme une alternative pour éviter les dérives bizarres de LastPass.

    • Les dérives bizarres de LastPass datent de longtemps et, franchement, elles étaient graves.
      En revanche, je ne comprends pas pourquoi ce commit Git a été lié. J’aurais plutôt aimé voir la discussion pertinente : https://github.com/bitwarden/clients/issues/11611
    • Je considère toujours que c’est une telle alternative. Honnêtement, c’est même devenu meilleur.
      Pour preuve, Bitwarden est le gestionnaire de mots de passe que les YouTubeurs sponsorisés ne recommandent pas, mais que les YouTubeurs non sponsorisés recommandent toujours.
    • 1Password est un logiciel propriétaire, et pourtant, à ma connaissance, il n’a pas encore eu de dérive bizarre. J’ai été tenté plusieurs fois de passer à une solution open source, mais je pense que je vais rester là encore quelques années.

  • Merci à Bitwarden d’avoir écouté. Ce genre de chose donne aussi de l’espoir pour les modèles économiques open source.

  • Liens associés : https://github.com/bitwarden/clients/issues/11611#issuecomme...
    Discussion précédente : https://news.ycombinator.com/item?id=41893994

    • Merci. J’avais raté cette info et je galérais à reconstituer le contexte en lisant plusieurs commentaires

  • Je trouve qu’ils ont géré ça de manière assez efficace et conforme à l’esprit open source. Content que ça se soit réglé sans combines bizarres, et que ça m’évite la corvée de migrer depuis Bitwarden

  • Ce n’est pas encore totalement réglé. Certaines parties ont été relicenciées, mais d’autres restent sous l’ancienne licence SDK de logiciel non libre
    Exemple : https://github.com/bitwarden/sdk-internal/commit/db648d7ea85...

    • Les parties qui ne sont pas en GPLv3 semblent destinées à Secrets Manager, qui est un produit distinct. Il ne semble pas être présenté comme open source
      Bitwarden a toujours été open core, pas entièrement sous GPLv3, et c’est compréhensible. Au final, il faut bien quelque chose à vendre

  • On peut leur reconnaître qu’ils vont dans la bonne direction. Pendant quelques jours, on ne savait vraiment pas du tout ce que Bitwarden allait faire

    • Si l’on continue à soupçonner d’emblée les entreprises de cette façon, la suivante n’essaiera même pas
      C’est l’une des rares entreprises à publier son produit en open source. Pour l’instant, ce n’est vraiment pas le moment de rester dans le soupçon et de faire la leçon

  • C’est un changement bienvenu. Cela dit, il reste l’impression qu’ils cherchent à être un peu trop malins avec les licences. En particulier, la façon de combiner du code GPL et du code sous licence propriétaire semble être la cause profonde de cette affaire
    Le modèle open core convient mieux aux services hébergés qui ne distribuent pas d’artefact combinant GPL et code propriétaire. Faire de l’open core côté code client me paraît trop propice aux malentendus et à la confusion
    J’espère quand même que ça se passera bien. C’est un bon produit