Fin del software libre en Bitwarden

 (github.com/bitwarden)
1 puntos por GN⁺ 2024-10-21 | 2 comentarios | Compartir por WhatsApp
  • La compilación de Bitwarden Desktop 2024.10.0 pasó a requerir la dependencia @bitwarden/sdk-internal, y se planteó el problema de que los términos de licencia de ese SDK lo restringen al indicar que “no puede usarse para desarrollar aplicaciones para software distinto de Bitwarden ni otros SDK”, lo que rompería los requisitos de software libre
  • Quien abrió el reporte señaló que esta restricción viola la libertad 0 de GNU, y que si se elimina esa dependencia no se pueden compilar desktop-v2024.10.0 ni la rama master actual
  • Como caso reproducible, al eliminar el directorio bitwarden_license y limpiar node_modules, la compilación falla con 6 errores TS2307 en build:preload por no encontrar @bitwarden/sdk-internal ni el módulo WASM
  • Algunos comentarios señalaron que el SDK se usa con feature flags no solo en Desktop, sino también en browser, CLI y web clients; Bitwarden respondió que el SDK y los clientes son programas separados y que, desde la perspectiva de GPLv3, comunicarse por protocolos estándar no los convierte en un solo programa
  • Posteriormente, Bitwarden ajustó la organización del código y el empaquetado del SDK para permitir compilaciones que incluyan solo licencias GPL/OSI, y cerró el issue después de mover las referencias del cliente a sdk-internal hacia un nuevo repositorio sdk-internal

Problema planteado: compilación de Desktop 2024.10.0 y licencia del SDK

  • El issue se abrió para denunciar que Bitwarden Desktop 2024.10.0 ya no sería software libre
  • El cambio central fue que el Pull request #10974 introdujo la dependencia @bitwarden/sdk-internal en la compilación del cliente de escritorio
  • La licencia de esa dependencia incluye la siguiente restricción
    • “No se puede usar este SDK para desarrollar aplicaciones para software distinto de Bitwarden, incluido software con implementaciones no compatibles con Bitwarden, ni para desarrollar otros SDK”
  • Quien reportó el problema considera que esta cláusula viola la libertad 0 de la definición de software libre de GNU
  • También indicó que sin eliminar esa dependencia no se puede compilar desktop-v2024.10.0, y probablemente tampoco la rama master actual

Fallo de compilación reproducido

  • Quien abrió el issue intentó compilar como antes, eliminando el directorio bitwarden_license y usando node_modules ya limpio
  • La compilación falla en la etapa build:preload de apps/desktop
  • El error es TS2307, indicando en varios archivos que no se puede encontrar el módulo @bitwarden/sdk-internal o sus declaraciones de tipos
    • 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
  • También aparece un error porque no se puede encontrar la ruta WASM @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm
  • Como resultado, webpack 5.94.0 no logra compilar por 6 errores, y npm run build:preload termina con código 1

Reacción de la comunidad y preocupación ampliada

  • Un comentario mencionó como issue relacionado bitwarden/sdk-sm#898 y expresó preocupación de que Bitwarden, mientras se promociona como open source, estaría pasando a software propietario
  • Otro usuario dijo que ya había reportado un problema similar hace dos meses en la publicación NPM del cliente CLI como #10648, pero no recibió respuesta
  • Algunas personas mencionaron como alternativas forks de versiones anteriores, Vaultwarden y apps de escritorio en Tauri que envuelven la interfaz web de Vaultwarden
  • Un comentario advirtió que, por tratarse de un producto que maneja contraseñas, conviene ser cauteloso antes de cambiarse a “cualquier alternativa”, y que un fork del cliente por sí solo no resuelve las dependencias del servicio o del software del servidor
  • Otro comentario sostuvo que el SDK se usa con feature flags no solo en la versión Desktop, sino también en browser, CLI y web clients, y afirmó que todas las versiones de Bitwarden 2024.10.0 usan el SDK

Respuesta inicial de Bitwarden

  • Un integrante de Bitwarden respondió que han ido ampliando el uso del SDK en los clientes, pero que el objetivo es que ese uso mantenga la compatibilidad con GPL
  • Bitwarden presentó tres fundamentos
    • El SDK y los clientes son programas separados
    • El código de cada programa está en repositorios separados
    • El solo hecho de que ambos programas se comuniquen mediante protocolos estándar no los convierte en un solo programa para los fines de GPLv3
  • También indicó que el problema de no poder compilar la app con el método que intentó el usuario era un bug que pensaban corregir
  • Después, la conversación fue bloqueada por Bitwarden y quedó limitada a colaboradores

Ajuste final y cierre

  • Bitwarden indicó que ajustó la organización del código y la forma de empaquetar el SDK para permitir compilar y ejecutar la app en un estado que incluye solo licencias GPL/OSI
  • Las referencias del cliente al paquete sdk-internal se cambiaron para que apunten al nuevo repositorio sdk-internal
  • Explicó que el nuevo repositorio sdk-internal sigue el mismo modelo de licencias que Bitwarden ha usado en sus clientes, y remitió como información relacionada a LICENSE_FAQ.md
  • Actualmente, la referencia sdk-internal usa únicamente licencia GPL
  • Señaló que si en el futuro esa referencia llega a incluir código bajo Bitwarden License, ofrecerán una forma de crear múltiples variantes de compilación, similar a la compilación del cliente web vault
  • El repositorio sdk existente pasará a llamarse sdk-secrets y mantendrá la estructura de licencia Bitwarden SDK License para el producto empresarial Secrets Manager
  • Como el repositorio y los paquetes sdk-secrets contienen código que no se usa en las apps cliente, ya no se referencian desde las apps cliente
  • El issue se cerró el 25 de octubre de 2024 con estado completed

Lecturas relacionadas

2 comentarios

 
tribela 2024-10-21

Uso mucho KeePass, pero como la gente no deja de hablar de Bitwarden, pensé en probarlo; al final mejor me quedo con KeePass. Como no funciona con un servidor y solo hay que guardar bien el archivo, tiene mucha más disponibilidad, así que para mis gustos KeePass me queda mejor.
 
GN⁺ 2024-10-21
Opiniones en Hacker News

  • Pagué con la expectativa de apoyar el código abierto, y por eso me pasé de LastPass a Bitwarden.
    Esto se siente como si me estuvieran retorciendo un cuchillo clavado en la espalda. Parece que llegaron a un punto de inflexión financiero similar al de cuando el CEO Michael Crandell vendió RightScale, así que tal vez se estén preparando para una adquisición: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • Incluso en el material de 2022 de esa página, bajo “¿Qué cambia?”, decía que Bitwarden seguiría manteniendo una arquitectura de código abierto.
      Parece que ya no. Es una jugada peligrosa. El código abierto tiene muchas buenas cualidades, pero aquí lo importante es la seguridad. Siempre me sorprende que las empresas presenten como seguros unos bloques binarios opacos. Lo mismo con Intel Management Engine, y ahora Bitwarden se suma a las filas de IME y los switches de Juniper.
      Pasarse a código cerrado es una decisión de alto riesgo. Durante mucho tiempo no pagué por el software en sí, pero sí puedo pagar por seguridad, y de hecho lo hago. Pago por Bitwarden porque almacena lo que considero mi información más valiosa y privada. Pero al final no deja de ser software, y no importa de dónde vengan los bytes llamados “bitwarden”. Cualquiera puede hacer un fork y ofrecer los mismos bytes. Si alguien opera un espejo de Bitwarden que use solo software de código abierto, mi dinero irá para allá. Mejor aún si incluye instrucciones de compilación que permitan reproducir de forma idéntica el binario en ejecución y los binarios que descargo en mis distintos dispositivos. No considero que mis contraseñas estén seguras a menos que las gestione software de código abierto.

  • Este movimiento no me sorprende demasiado. En los últimos años Bitwarden se ha movido con fuerza hacia las ventas empresariales, y mientras tanto dejó bastante abandonado el lado de consumidores.
    Recién hace poco pasó de la app anterior basada en MAUI a una app nativa para iOS, pero la app vieja desentonaba demasiado en muchos aspectos. El cliente actual de iOS todavía tiene cosas por mejorar.
    Después de recibir inversión de venture capital, parece haberse inclinado más hacia ingresos y ganancias. Esa decisión en sí no está mal, pero empuja a la empresa en una dirección bastante distinta de la forma en que empezó y creció.
    Proton Pass también me parece algo interesante, aunque como otros servicios de Proton, su modelo de precios siempre resulta un poco alto. He estado probando Proton Pass gratis por un tiempo y, como Bitwarden no ha mejorado en la dirección que esperaba desde hace años, voy a ver si vale la pena mudarme a una alternativa.
    El gestor de contraseñas integrado de iOS también es bastante decente, pero es solo para contraseñas y no admite guardar, buscar ni autocompletar otros tipos de datos.

    • Es irónico. Algunas empresas quizá usaban Bitwarden precisamente porque era abierto y porque no hacía falta pasar por una llamada de ventas empresariales para usar algo muy útil.
      Si haces que el producto sea difícil de usar, pierdes clientes y oportunidades de venta. Me vienen a la mente unas llamadas horribles que tuve recientemente con Postman. Antes que tener otra llamada, ahora Hoppscotch me parece una opción mucho mejor.
    • ¿Por qué casi siempre el venture capital termina arruinándolo todo?

  • La respuesta del CTO dice que han ido ampliando el alcance de uso del SDK a más casos de clientes, pero que el objetivo es que el SDK se use de una forma que mantenga la compatibilidad con la GPL.
    Considera que el SDK y el cliente son programas separados, que el código de cada programa está en repositorios separados, y que el mero hecho de que dos programas se comuniquen mediante un protocolo estándar no los convierte en un solo programa bajo la GPLv3. Dice que el problema de que la app deba poder compilarse de la forma intentada aquí es un simple bug que van a resolver.

    • Este tipo de respuestas es realmente frustrante. Evitan la pregunta real de una forma que parece malinterpretar deliberadamente el alcance de la pregunta.
      Lo que quisiera preguntarle al CTO es más o menos esto: respondieron a “¿sus abogados creen que pueden salirse con la suya legalmente con esto?”, pero no respondieron la pregunta central que preocupa a la gente. ¿El equipo de Bitwarden cree que no hay ningún problema ético en privatizar un proyecto que mucha gente apoyó y al que contribuyó explícitamente porque era de código abierto? La gestión de contraseñas es por naturaleza un negocio que requiere mucha confianza: ¿cómo piensan manejar la ruptura de confianza, los forks y la fuga de usuarios que puede provocar un rug pull de código abierto a código cerrado? Si la empresa está en una situación tan desesperada como para considerar una decisión así, ¿no hay alguna forma de que la comunidad ayude a superarla sin privatizar el proyecto?
      Entiendo que, como CTO, en este momento su trabajo es aparentar preocupación, sobre todo en foros donde no se puede cerrar la conversación, pero el enfoque actual básicamente confirma el peor temor: “creemos que es legalmente posible y no vemos nada malo en lo que hacemos”. Es exactamente el tono equivocado para una empresa que gana dinero solo si los usuarios confían en el código y en quienes lo actualizan.
    • Dicho de otro modo, bitwarden/clients es GPLv3, el cliente de Bitwarden como conjunto funcional es software propietario, el CTO no ve problema en eso, y el issue quedó bloqueado.
    • Que sea o no “un solo programa” no es necesariamente el punto central. El problema está en esta parte:
      “El ‘código fuente correspondiente’ de una obra en forma de código objeto incluye todo el código fuente necesario para generar, instalar y ejecutar el código objeto y para modificar la obra, así como los scripts para controlar esas actividades”.
      Entiendo que ganar dinero como empresa de código abierto es realmente difícil. Por eso yo también soy uno de los clientes de pago.
      La exclusión que pusieron al SDK se parece mucho al software de control de versiones BitKeeper que durante un tiempo se usó para el kernel de Linux. Basta ver cómo terminó eso.

  • Me gustaba, pagaba por él e incluso se lo recomendé a mis amigos, y a ellos también les gustó.
    Ahora estoy pensando en pasarme a KeePassXC. ¿Cuál es la forma recomendada de sincronizar la base de datos con Android? Solo tengo un servidor Raspberry Pi corriendo cloudflared.

    • Si quieres mantener la comodidad de la nube sin volver a los conflictos de sincronización que aparecen al mover archivos, Proton Pass es GPLv3. Eso sí, personalmente no sé cómo sería la situación de autohospedaje si más adelante hacen 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>;)

  • Uso SyncThing para distribuir la bóveda de KeePass exactamente solo a los dispositivos que necesito. A mí me funciona muy bien. Puede variar según la necesidad

  • Realmente quiero usar KeePass y su ecosistema, pero compartir contraseñas no es muy bueno. Mi esposa y yo tenemos muchas contraseñas compartidas, y Bitwarden funciona muy bien en ese aspecto. No sé cuál sería una alternativa práctica para nosotros

  • Keepass2Android puede sincronizarse de varias formas, como ssh(sftp), Nextcloud, etc. Seguro se puede encontrar el método adecuado

  • La combinación de KeePassXC y el cliente de Nextcloud para Android es perfecta para mí. La uso desde hace años sin problemas

  • Bloquearon el issue de GitHub para que ya no se pueda discutir. Una de las alternativas posibles parece ser Vaultwarden
    https://github.com/dani-garcia/vaultwarden
    Es una verdadera lástima que este tipo de cosas sigan pasando en proyectos open source cuando entra gente con dinero

    • Vaultwarden es un reemplazo del servidor, y el problema aquí, según entiendo, es la licencia del cliente de escritorio
    • García empezó a trabajar hace poco en Bitwarden. Sería interesante escuchar qué piensa
    • ¿Vaultwarden soporta passkeys?

  • Nunca lo revisé en detalle, pero por el marketing pensé que Bitwarden era completamente software libre. Sin embargo, parece que desde alrededor de 2020 se le fueron metiendo elementos propietarios raros

  • Esperaba mudarme algún día a Bitwarden, pero si no encuentro un ecosistema abierto sano, ahora creo que no lo haré. Seguiré viendo cómo evoluciona

    • Probé hacer una transición completa a Bitwarden durante un año usando el backend de Vaultwarden, pero comparado con 1Password, que usaba antes, la experiencia fue bastante peor
      Uno de mis criterios de evaluación era: “Toda mi familia usa 1Password y está satisfecha; ¿esto es lo suficientemente bueno como para convencerlos de cambiarse?”. La decisión final de migrar la podía tomar yo, pero si quiero hacer que mis padres mayores usen algo nuevo, la experiencia de usuario es muy importante
      Al final, no lo fue. Además de que la UX en general no era buena, los clientes de Bitwarden eran mucho más lentos en Linux, Mac, Windows e iOS, en todo, desde la búsqueda hasta el inicio de sesión. También tenía menos funciones, faltaban cosas visibles como ordenamiento de contraseñas, favoritos y buenas herramientas de organización, y el autocompletado era mucho menos confiable
      Durante años tuve muchas quejas sobre la forma en que 1Password hace negocios y trata a sus clientes. Aun así, un gestor de contraseñas —ahora más bien una herramienta para gestionar secretos que guarda más que contraseñas— es algo central en la vida diaria, así que sentí que debía usar lo menos doloroso posible y, lamentablemente, volví
      No usaba Bitwarden porque fuera de código abierto, sino porque intentaba usar el mejor gestor de contraseñas posible. Aun así, me gustaba que fuera abierto, y Vaultwarden es una joya. De verdad quisiera tener el tiempo y la habilidad para crear un frontend mejor

  • “Por ahora no tenemos planes de ajustar la licencia del SDK. Seguiremos publicándolo en nuestro propio repositorio de F-Droid https://mobileapp.bitwarden.com/fdroid/repo/.”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Este problema ya se había planteado en julio en el repositorio del SDK, y ese SDK lleva más de un año con esta licencia

  • Uso Bitwarden en iOS, PC y Mac. Ahora tengo que buscar alternativas. Es un día realmente triste
    Yo también soy miembro premium de 10 dólares al año. Terminará siendo ingresos perdidos por prácticas sospechosas
    ¿Hay alguna forma de exportar y pasarme a otra alternativa?

  • Era un proyecto que venía siguiendo porque pensé que podría convertirse en una mejor alternativa a Keepass(X,XC), pero ahora creo que al final no me voy a cambiar