Bitwarden beendet freie Software

 (github.com/bitwarden)
1 Punkte von GN⁺ 2024-10-21 | 2 Kommentare | Auf WhatsApp teilen
  • Beim Build von Bitwarden Desktop 2024.10.0 wurde eine Abhängigkeit von @bitwarden/sdk-internal erforderlich. Es wurde kritisiert, dass die Lizenzbedingungen dieses SDKs die Anforderungen an freie Software verletzen, da sie die Nutzung „nicht für die Entwicklung von Apps für Software außerhalb von Bitwarden oder für andere SDKs“ erlauben
  • Der Melder des Problems erklärte, diese Einschränkung verstoße gegen Freedom 0 der GNU-Definition; entferne man die Abhängigkeit, ließen sich desktop-v2024.10.0 und der aktuelle master nicht bauen
  • Als Reproduktion wurde beschrieben: Entfernt man das Verzeichnis bitwarden_license und bereinigt node_modules, schlägt der Build bei build:preload mit sechs TS2307-Fehlern fehl, weil @bitwarden/sdk-internal und das WASM-Modul nicht gefunden werden
  • Einige Kommentare wiesen darauf hin, dass das SDK nicht nur in Desktop, sondern auch in browser, CLI, web clients per Feature-Flag verwendet werde. Bitwarden antwortete, SDK und Clients seien getrennte Programme und würden aus GPLv3-Sicht nicht allein durch Kommunikation über Standardprotokolle zu einem einzigen Programm
  • Bitwarden passte später Struktur und Packaging des SDK-Codes so an, dass Builds nur mit GPL/OSI-Lizenzen möglich wurden, verschob die sdk-internal-Referenzen der Clients in ein neues sdk-internal-Repository und schloss das Issue als erledigt

Das vorgebrachte Problem: Desktop-2024.10.0-Build und SDK-Lizenz

  • Das Issue wurde mit dem Vorwurf eröffnet, Bitwarden Desktop 2024.10.0 sei nicht mehr freie Software
  • Die zentrale Änderung war, dass Pull Request #10974 eine Abhängigkeit von @bitwarden/sdk-internal in den Build des Desktop-Clients einführte
  • Die Lizenz dieser Abhängigkeit enthält folgende Einschränkung
    • „Dieses SDK darf nicht zur Entwicklung von Anwendungen für Software außerhalb von Bitwarden, einschließlich mit Bitwarden inkompatibler Implementierungen, und auch nicht zur Entwicklung anderer SDKs verwendet werden“
  • Der Melder sah darin einen Verstoß gegen Freedom 0 der GNU-Definition freier Software
  • Außerdem erklärte er, dass sich desktop-v2024.10.0 und wahrscheinlich auch der aktuelle master ohne Entfernen dieser Abhängigkeit nicht bauen ließen

Reproduzierter Build-Fehler

  • Der Melder versuchte, wie bisher das Verzeichnis bitwarden_license zu entfernen und mit bereinigtem node_modules zu bauen
  • Der Build scheiterte in apps/desktop beim Schritt build:preload
  • Bei den Fehlern handelte es sich um TS2307, weil in mehreren Dateien das Modul @bitwarden/sdk-internal oder dessen Typdeklarationen nicht gefunden wurden
    • 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
  • Auch der WASM-Pfad @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm konnte nicht gefunden werden
  • In der Folge schlug die Kompilierung mit webpack 5.94.0 wegen sechs Fehlern fehl, und npm run build:preload endete mit Code 1

Reaktionen der Community und weitergehende Bedenken

  • Ein Kommentar verwies auf das verwandte Issue bitwarden/sdk-sm#898 und äußerte die Sorge, Bitwarden werbe mit Open Source, bewege sich aber in Richtung proprietärer Software
  • Ein anderer Nutzer sagte, er habe ein ähnliches Problem bei den NPM-Releases des CLI-Clients bereits zwei Monate zuvor unter #10648 gemeldet, aber keine Antwort erhalten
  • Einige Nutzer nannten als Alternativen Forks älterer Versionen, Vaultwarden sowie eine Tauri-Desktop-App, die das Vaultwarden-Webinterface einbettet
  • Ein Kommentar wies darauf hin, dass man wegen der Natur eines Passwortprodukts vorsichtig sein müsse, nicht zu „irgendeiner Alternative“ zu wechseln; ein reiner Client-Fork löse außerdem nicht die Abhängigkeit von Serverdienst oder Serversoftware
  • Ein weiterer Kommentar behauptete, das SDK werde nicht nur in Desktop-Releases, sondern auch in browser, CLI, web clients per Feature-Flag verwendet, und schrieb, alle Versionen von Bitwarden 2024.10.0 nutzten das SDK

Erste Antwort von Bitwarden

  • Ein Bitwarden-Mitglied antwortete, man habe den Einsatz des SDK in den Clients ausgeweitet, das Ziel sei aber, die Nutzung des SDK GPL-kompatibel zu halten
  • Bitwarden nannte dafür drei Gründe
    • SDK und Clients sind getrennte Programme
    • Der Code der einzelnen Programme liegt in getrennten Repositories
    • Dass zwei Programme über Standardprotokolle kommunizieren, macht sie für Zwecke der GPLv3 nicht zu einem einzigen Programm
  • Das Problem, dass sich die App mit der vom Nutzer versuchten Methode nicht bauen lässt, sei ein zu behebender Bug
  • Anschließend wurde die Diskussion von Bitwarden gesperrt und auf Collaborator beschränkt

Abschließende Anpassungen und Schließung

  • Bitwarden erklärte, Struktur und Packaging des SDK-Codes angepasst zu haben, sodass die App ausschließlich mit GPL/OSI-Lizenzen gebaut und ausgeführt werden könne
  • Die Referenz der Clients auf das Paket sdk-internal wurde so geändert, dass sie aus dem neuen sdk-internal repository kommt
  • Das neue sdk-internal-Repository folge dem Lizenzmodell, das Bitwarden bisher für die bestehenden Clients verwendet habe; als weiterführende Information wurde LICENSE_FAQ.md genannt
  • Die aktuelle sdk-internal-Referenz verwendet nur die GPL-Lizenz
  • Sollte diese Referenz künftig Code unter der Bitwarden License enthalten, wolle man eine Möglichkeit bereitstellen, mehrere Build-Varianten zu erstellen, ähnlich wie beim Build des Web-Vault-Clients
  • Das bisherige sdk repository wird in sdk-secrets umbenannt und behält die bisherige Struktur der Bitwarden SDK License für das Business-Produkt Secrets Manager bei
  • Das sdk-secrets-Repository und die Pakete enthalten Code, der in den Client-Apps nicht verwendet wird, und werden daher von den Client-Apps nicht mehr referenziert
  • Das Issue wurde am 25. Oktober 2024 als completed geschlossen

Verwandte Beiträge

2 Kommentare

 
tribela 2024-10-21

Ich nutze KeePass sehr gern, aber weil alle ständig nur von Bitwarden reden, dachte ich, ich probiere es vielleicht mal aus. Jetzt werde ich wohl einfach bei KeePass bleiben. Da es kein serverbasiertes System ist, sondern man nur die Datei gut aufbewahren muss, ist die Verfügbarkeit deutlich höher, und für meinen Geschmack passt KeePass besser.
 
GN⁺ 2024-10-21
Meinungen auf Hacker News

  • Bezahlt habe ich in der Erwartung, Open Source zu unterstützen, und deshalb bin ich von LastPass zu Bitwarden gewechselt.
    Das hier fühlt sich an, als würde jemand das Messer im Rücken noch umdrehen. CEO Michael Crandell scheint an einem ähnlichen finanziellen Wendepunkt angekommen zu sein wie damals, als er RightScale verkaufte, also bereiten sie wohl eine Übernahme vor: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • Auch in dem Material von 2022 auf dieser Seite stand unter „Was ändert sich?“, dass Bitwarden weiter an einer Open-Source-Architektur festhalten werde.
      Sieht jetzt nicht mehr so aus. Ein riskanter Schritt. Open Source hat viele gute Eigenschaften, aber hier geht es vor allem um Sicherheit. Es überrascht mich immer wieder, wenn Unternehmen intransparente Binärklumpen als sicher hinstellen. Intel Management Engine ist so ein Fall, und jetzt reiht sich Bitwarden offenbar bei IME und Juniper-Switches ein.
      Der Weg zu Closed Source ist eine Hochrisikoentscheidung. Ich habe lange nicht für die Software selbst bezahlt, aber für Sicherheit kann ich bezahlen, und das tue ich auch. Ich bezahle für Bitwarden, weil es das speichert, was ich für meine wertvollsten und privatesten Informationen halte. Am Ende ist es aber nur Software, und es ist egal, woher die Bytes kommen, die man „bitwarden“ nennt. Jeder kann forken und dieselben Bytes bereitstellen. Wenn jemand einen Bitwarden-Mirror betreibt, der ausschließlich Open-Source-Software verwendet, geht mein Geld dorthin. Noch besser wäre es, wenn es Build-Anweisungen gäbe, mit denen sich das laufende Binary und die Binaries, die ich auf mehrere Geräte herunterlade, identisch reproduzieren lassen. Ich halte meine Passwörter nicht für sicher, solange sie nicht von Open-Source-Software verwaltet werden.

  • Dieser Schritt überrascht mich nicht besonders. Bitwarden hat sich in den letzten Jahren stark in Richtung Enterprise Sales bewegt und dabei die Consumer-Seite vernachlässigt.
    Erst kürzlich wurde von der früheren MAUI-basierten App auf eine native iOS-App gewechselt; die alte App fiel in vielerlei Hinsicht negativ auf. Auch der aktuelle iOS-Client hat noch Nachholbedarf.
    Nach der Aufnahme von Venture-Kapital scheint sich der Fokus stärker auf Umsatz und Gewinn verschoben zu haben. Diese Entscheidung ist an sich nicht falsch, aber sie treibt das Unternehmen in eine Richtung, die ziemlich anders ist als die, mit der es gestartet und gewachsen ist.
    Proton Pass ist ebenfalls etwas interessant, aber wie bei anderen Proton-Diensten ist das Preismodell immer ein wenig hoch angesetzt. Ich nutze seit einiger Zeit den kostenlosen Proton Pass und werde prüfen, ob sich ein Wechsel als Alternative lohnt, da Bitwarden sich nicht in die Richtung verbessert hat, auf die ich seit Jahren gewartet habe.
    Der eingebaute Passwortmanager von iOS ist auch durchaus okay, aber er ist ausschließlich für Passwörter gedacht und unterstützt nicht das Speichern, Suchen und automatische Ausfüllen anderer Datentypen.

    • Ironisch. Manche Unternehmen haben Bitwarden vielleicht gerade deshalb genutzt, weil es offen war und man nicht erst durch ein Enterprise-Sales-Gespräch musste, um etwas sehr Nützliches einzusetzen.
      Wenn man ein Produkt schwerer nutzbar macht, verliert man Kunden und Verkaufschancen. Das erinnert mich an die schrecklichen Gespräche, die ich kürzlich mit Postman hatte. Statt noch einmal so ein Gespräch zu führen, sieht Hoppscotch inzwischen deutlich besser aus.
    • Warum macht Venture-Kapital fast immer alles kaputt?

  • Die Antwort des CTO lautet, man habe den Einsatzbereich des SDK auf mehr Client-Szenarien ausgeweitet, Ziel sei aber, dass das SDK so verwendet werde, dass es GPL-kompatibel bleibt.
    SDK und Client seien getrennte Programme, der Code der jeweiligen Programme liege in separaten Repositories, und allein die Tatsache, dass zwei Programme über Standardprotokolle kommunizieren, mache sie unter GPLv3 nicht zu einem einzigen Programm. Dass die App auf die hier versuchte Weise gebaut werden können müsse, sei ein einfacher Bug, den man beheben werde.

    • Solche Antworten sind wirklich frustrierend. Sie weichen der eigentlichen Frage aus, indem sie den Umfang der Frage scheinbar absichtlich missverstehen.
      Was ich den CTO fragen möchte, ist ungefähr Folgendes: Auf „Glauben eure Anwälte, dass ihr damit rechtlich durchkommt?“ hat er geantwortet, aber die Kernfrage, um die sich die Leute sorgen, hat er nicht beantwortet. Sieht das Bitwarden-Team kein ethisches Problem darin, ein Projekt zu privatisieren, das viele Menschen ausdrücklich unterstützt und zu dem sie beigetragen haben, weil es Open Source war? Passwortverwaltung ist von Natur aus ein Geschäft, das hohes Vertrauen erfordert; wie will man den Vertrauensbruch, die Forks und die Abwanderung bewältigen, die durch einen Rug Pull von Open Source zu Closed Source entstehen? Wenn das Unternehmen so verzweifelt ist, dass es eine solche Entscheidung erwägt, gibt es dann keinen Weg, wie die Community gemeinsam helfen kann, ohne zu privatisieren?
      Ich verstehe, dass es als CTO gerade seine Aufgabe ist, so zu tun, als sei er besorgt, besonders in Foren, in denen man die Diskussion nicht einfach schließen kann. Aber der aktuelle Ansatz bestätigt im Grunde die schlimmste Befürchtung: „Wir glauben, dass es rechtlich möglich ist, und sehen kein Problem in unserem Verhalten.“ Das ist genau die falsche Stimmung für ein Unternehmen, dessen Einnahmen davon abhängen, dass Nutzer dem Code und den Menschen vertrauen, die ihn aktualisieren.
    • Anders gesagt: bitwarden/clients ist GPLv3, der Bitwarden-Client als funktionsfähiges Ganzes ist proprietäre Software, der CTO sieht darin kein Problem, und das Issue wurde gesperrt.
    • Ob es zwingend „ein Programm“ ist, ist nicht der entscheidende Punkt. Das Problem ist dieser Teil:
      „Der ‚korrespondierende Quellcode‘ eines Werks in Objektcodeform umfasst den gesamten Quellcode, der erforderlich ist, um den Objektcode zu erzeugen, zu installieren und auszuführen sowie das Werk zu verändern, einschließlich der Skripte zur Steuerung dieser Aktivitäten.“
      Ich verstehe wirklich, dass es schwierig ist, als Open-Source-Unternehmen Geld zu verdienen. Deshalb bin ich auch einer der zahlenden Kunden.
      Die Ausschlussbedingung, die sie an das SDK gehängt haben, sieht der BitKeeper-Versionsverwaltungssoftware sehr ähnlich, die eine Zeit lang für den Linux-Kernel verwendet wurde. Man kann nachsehen, wie das ausgegangen ist.

  • Ich mochte es, habe dafür bezahlt, es Freunden empfohlen, und sie mochten es ebenfalls.
    Jetzt will ich zu KeePassXC wechseln. Was ist die empfohlene Methode, um die Datenbank mit Android zu synchronisieren? Ich habe nur einen Raspberry-Pi-Server, auf dem cloudflared läuft.

    • Wenn du Cloud-Komfort behalten willst, ohne wieder bei Synchronisierungskonflikten durch das Verschieben von Dateien zu landen: Proton Pass ist GPLv3. Wie die Self-Hosting-Situation aussieht, falls es später einen Rug Pull gibt, weiß ich persönlich allerdings nicht.
      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>;)

  • Ich verteile meinen KeePass-Tresor mit SyncThing genau nur auf die Geräte, auf denen ich ihn brauche. Funktioniert für mich sehr gut. Je nach Bedarf kann das anders sein.

  • Ich würde KeePass und sein Ökosystem wirklich gern nutzen, aber Passwort-Sharing ist nicht besonders gut. Meine Frau und ich haben viele gemeinsame Passwörter, und bei Bitwarden funktioniert dieser Teil sehr gut. Ich weiß nicht, was für uns eine praktische Alternative wäre.

  • Keepass2Android kann auf verschiedene Arten synchronisieren, etwa per ssh (sftp), Nextcloud usw. Da sollte sich eine passende Methode finden lassen.

  • Die Kombination aus KeePassXC und dem Nextcloud-Client für Android ist für mich perfekt. Ich nutze sie seit Jahren ohne Probleme.

  • Die GitHub-Issue wurde gesperrt, sodass nicht weiter darüber diskutiert werden kann. Eine mögliche Alternative scheint Vaultwarden zu sein
    https://github.com/dani-garcia/vaultwarden
    Es ist wirklich schade, dass so etwas in Open-Source-Projekten immer wieder passiert, sobald Leute mit Geld dazukommen.

    • Vaultwarden ist ein Server-Ersatz, und hier ist das Problem, soweit ich es verstehe, die Lizenz des Desktop-Clients.
    • García hat kürzlich angefangen, bei Bitwarden zu arbeiten. Es wäre interessant, seine Einschätzung dazu zu hören.
    • Unterstützt Vaultwarden Passkeys?

  • Ich habe es mir nie genauer angesehen, aber nach dem Marketing dachte ich, Bitwarden sei vollständig freie Software. Offenbar sind aber seit etwa 2020 seltsame proprietäre Elemente hineingekommen.

  • Ich hatte gehofft, irgendwann zu Bitwarden zu wechseln, aber wenn ich kein gesundes offenes Ökosystem finde, werde ich das jetzt wohl nicht tun. Ich werde weiter beobachten, wie sich das entwickelt.

    • Ich habe ein Jahr lang versucht, vollständig auf Bitwarden mit einem Vaultwarden-Backend umzusteigen, aber im Vergleich zu meinem vorherigen 1Password war die Erfahrung deutlich schlechter.
      Eines meiner Bewertungskriterien war: „Alle in der Familie nutzen 1Password und sind zufrieden; ist das gut genug, um sie zum Wechsel zu überreden?“ Die endgültige Entscheidung für den Wechsel kann ich treffen, aber wenn ich ältere Eltern dazu bringen will, etwas Neues zu verwenden, ist die User Experience sehr wichtig.
      Am Ende war die Antwort nein. Neben der insgesamt schlechten UX waren die Bitwarden-Clients unter Linux, Mac, Windows und iOS alle deutlich langsamer, von der Suche bis zum Login und eigentlich bei allem. Es gab auch weniger Funktionen; auffällige Dinge wie Passwortsortierung, Favoriten und gute Organisationswerkzeuge fehlten, und AutoFill war deutlich weniger zuverlässig.
      Mit der Geschäftspraxis und dem Umgang mit Kunden bei 1Password war ich über die Jahre sehr unzufrieden. Trotzdem ist ein Passwortmanager – inzwischen eher ein Secret-Manager für mehr als nur Passwörter – so zentral für den Alltag, dass ich das Tool nutzen sollte, das möglichst wenig Schmerz verursacht. Deshalb bin ich leider wieder zurückgegangen.
      Ich habe Bitwarden nicht genutzt, weil es Open Source war, sondern weil ich den bestmöglichen Passwortmanager verwenden wollte. Trotzdem gefiel mir der offene Aspekt, und Vaultwarden ist ein Juwel. Ich wünschte wirklich, ich hätte die Zeit und die Fähigkeiten, ein besseres Frontend zu bauen.

  • „Derzeit haben wir keine Pläne, die SDK-Lizenz anzupassen. Wir werden weiterhin in unserem eigenen F-Droid-Repository https://mobileapp.bitwarden.com/fdroid/repo/ veröffentlichen.“
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Dieses Problem wurde bereits im Juli im SDK-Repository angesprochen, und dieses SDK hat diese Lizenz seit über einem Jahr.

  • Ich nutze Bitwarden auf iOS, PC und Mac. Jetzt muss ich nach einer Alternative suchen. Ein wirklich trauriger Tag.
    Ich bin ebenfalls Premium-Mitglied für 10 Dollar pro Jahr. Das ist nun verlorener Umsatz wegen fragwürdiger Praktiken.
    Gibt es eine Möglichkeit, zu exportieren und zu einer anderen Alternative umzuziehen?

  • Ich hatte dieses Projekt im Blick, weil es vielleicht eine bessere Alternative zu Keepass (X, XC) für mich sein könnte, aber jetzt werde ich am Ende wohl doch nicht wechseln.