Fim do software livre no Bitwarden

 (github.com/bitwarden)
1 pontos por GN⁺ 2024-10-21 | 2 comentários | Compartilhar no WhatsApp
  • O build do Bitwarden Desktop 2024.10.0 passou a exigir a dependência @bitwarden/sdk-internal, e surgiu a questão de que os termos de licença desse SDK, ao restringirem que ele “não pode ser usado para desenvolver aplicativos para software que não seja o Bitwarden ou para desenvolver outros SDKs”, violariam os requisitos de software livre
  • O autor da questão afirma que essa restrição viola a liberdade 0 da GNU e que, se essa dependência for removida, não é possível compilar o desktop-v2024.10.0 nem o master atual
  • Como caso reproduzido, ao remover o diretório bitwarden_license e compilar com node_modules limpo, o build:preload falha com 6 erros TS2307 por não encontrar @bitwarden/sdk-internal nem os módulos WASM
  • Alguns comentários apontaram que o SDK é usado com feature flags não só no Desktop, mas também em browser, CLI e web clients, e a Bitwarden respondeu que o SDK e os clientes são programas separados e que, do ponto de vista da GPLv3, comunicar-se apenas por protocolo padrão não os torna um único programa
  • Depois, a Bitwarden ajustou a estrutura e o empacotamento do código do SDK para permitir builds contendo apenas licenças GPL/OSI, moveu as referências a sdk-internal dos clientes para um novo repositório sdk-internal e encerrou a issue

Problema levantado: build do Desktop 2024.10.0 e licença do SDK

  • A issue foi aberta alegando que o Bitwarden Desktop 2024.10.0 não é mais software livre
  • A mudança central é que o Pull request #10974 introduziu a dependência @bitwarden/sdk-internal no build do cliente desktop
  • A licença dessa dependência inclui a seguinte restrição
    • “Este SDK não pode ser usado para desenvolver aplicativos para software que não seja o Bitwarden, incluindo software com implementações incompatíveis com o Bitwarden, e também não pode ser usado para desenvolver outros SDKs”
  • O autor da questão entende que essa cláusula viola a liberdade 0 da definição de software livre da GNU
  • Também afirma que, sem remover essa dependência, não é possível compilar o desktop-v2024.10.0 e provavelmente também o master atual

Falha de build reproduzida

  • O autor tentou compilar removendo o diretório bitwarden_license e usando node_modules limpo, como fazia antes
  • O build falha na etapa build:preload de apps/desktop
  • O erro é TS2307, indicando em vários arquivos que o módulo @bitwarden/sdk-internal ou suas declarações de tipo não podem ser encontrados
    • 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
  • Também ocorre erro informando que o caminho WASM @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm não pode ser encontrado
  • Como resultado, o webpack 5.94.0 falha na compilação com 6 erros, e npm run build:preload termina com código 1

Reação da comunidade e preocupações ampliadas

  • Um comentário cita a issue relacionada bitwarden/sdk-sm#898 e levanta a preocupação de que a Bitwarden estaria se anunciando como open source enquanto migra para software proprietário
  • Outro usuário afirma que já havia reportado problema parecido no release NPM do cliente CLI em #10648 dois meses antes, mas não recebeu resposta
  • Alguns usuários mencionaram como alternativas um fork de versão anterior, o Vaultwarden e apps desktop em Tauri que encapsulam a interface web do Vaultwarden
  • Um comentário observa que, por se tratar de um produto que lida com senhas, é preciso cautela antes de migrar para “qualquer alternativa”, e que um fork apenas do cliente ainda deixa dependências em relação ao serviço ou ao software de servidor
  • Outro comentário afirma que o SDK é usado com feature flags não apenas no Desktop, mas também em browser, CLI e web clients, e que todas as versões do Bitwarden 2024.10.0 usam o SDK

Resposta inicial da Bitwarden

  • Um membro da Bitwarden respondeu que o uso do SDK nos clientes vem sendo ampliado, mas que o objetivo é manter a compatibilidade com a GPL no uso do SDK
  • A Bitwarden apresentou três fundamentos
    • O SDK e os clientes são programas separados
    • O código de cada programa está em repositórios separados
    • O simples fato de os dois programas se comunicarem por protocolo padrão não faz deles um único programa para fins da GPLv3
  • Também afirmou que a impossibilidade de compilar o app da forma tentada pelo usuário é um bug que pretendiam corrigir
  • Depois disso, a conversa foi bloqueada pela Bitwarden e restrita a colaboradores

Ajuste final e encerramento

  • A Bitwarden informou que ajustou a estrutura do código e a forma de empacotamento do SDK para permitir compilar e executar o app incluindo apenas licenças GPL/OSI
  • As referências dos clientes ao pacote sdk-internal foram alteradas para apontar para o novo repositório sdk-internal
  • A empresa explicou que o novo repositório sdk-internal segue o modelo de licença que a Bitwarden já vinha usando nos clientes existentes, e apontou como referência o LICENSE_FAQ.md
  • Atualmente, a referência a sdk-internal usa apenas licença GPL
  • A Bitwarden disse que, se no futuro essa referência passar a incluir código sob Bitwarden License, fornecerá uma forma de criar múltiplas variantes de build, de modo semelhante ao build do cliente web vault
  • O antigo repositório sdk será renomeado para sdk-secrets e manterá a estrutura de licença Bitwarden SDK License existente para o produto empresarial Secrets Manager
  • Como o código e os pacotes do repositório sdk-secrets não são usados pelos apps cliente, eles deixam de ser referenciados pelos apps cliente
  • A issue foi encerrada como completed em 25 de outubro de 2024

Leituras relacionadas

2 comentários

 
tribela 2024-10-21

Eu gosto muito do KeePass, mas como o pessoal só fala de Bitwarden, pensei em experimentar uma vez. No fim, vou continuar com o KeePass. Como não é um sistema baseado em servidor e basta guardar bem o arquivo, a disponibilidade é muito maior, então o KeePass combina mais com o que eu procuro.
 
GN⁺ 2024-10-21
Opiniões no Hacker News

  • Paguei porque esperava apoiar open source, e foi por isso que migrei do LastPass para o Bitwarden.
    Isso parece uma faca enfiada nas costas sendo torcida. Como o CEO Michael Crandell parece ter chegado a um ponto de inflexão financeira parecido com quando vendeu a RightScale, deve estar preparando uma aquisição: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • Mesmo no material de 2022 dessa página, em “O que muda?”, estava escrito que o Bitwarden continuaria preservando sua arquitetura open source.
      Parece que agora não mais. Uma jogada perigosa. Open source tem muitas qualidades boas, mas o que importa aqui é segurança. Sempre me surpreende ver empresas apresentarem blocos opacos de binários como seguros. O Intel Management Engine é assim, e agora o Bitwarden entra na mesma turma do IME e dos switches Juniper.
      Ir para código fechado é uma escolha de alto risco. Por muito tempo eu não paguei pelo software em si, mas posso pagar por segurança, e de fato pago. Pago ao Bitwarden porque ele armazena aquilo que considero minhas informações mais valiosas e privadas. Mas, no fim, é apenas software, e não importa de onde vêm os bytes chamados “bitwarden”. Qualquer um pode fazer um fork e fornecer os mesmos bytes. Se alguém operar um espelho do Bitwarden usando apenas software open source, meu dinheiro vai para lá. Melhor ainda se houver instruções de build que permitam reproduzir de forma idêntica o binário em execução e os binários que baixo em vários dispositivos. Não considero minhas senhas seguras a menos que sejam gerenciadas por software open source.

  • Esse movimento não é tão surpreendente. Nos últimos anos, o Bitwarden migrou fortemente para vendas corporativas e, nesse processo, deixou o consumidor de lado.
    Só recentemente trocou o app iOS baseado em MAUI por um app nativo, e o aplicativo antigo destoava demais em vários aspectos. O cliente iOS atual ainda tem pontos a recuperar.
    Depois de receber investimento de venture capital, parece ter se inclinado mais para receita e lucro. Essa escolha em si não é errada, mas empurra a empresa para uma direção bem diferente de como ela começou e cresceu.
    O Proton Pass também é um pouco interessante, mas, como outros serviços da Proton, o modelo de preços sempre é um pouco caro. Estou testando o Proton Pass gratuito há algum tempo e vou ver se vale migrar para uma alternativa, já que o Bitwarden não melhorou na direção que eu esperava há vários anos.
    O gerenciador de senhas integrado do iOS também é bom o suficiente, mas é apenas para senhas e não oferece recursos para armazenar, buscar e preencher automaticamente outros tipos de dados.

    • Irônico. Algumas empresas talvez estivessem usando o Bitwarden justamente porque ele era aberto e não exigia passar por uma ligação de vendas corporativas para usar algo muito útil.
      Se você torna o produto difícil de usar, perde clientes e oportunidades de venda. Isso me lembra as ligações horríveis que tive recentemente com a Postman. A essa altura, o Hoppscotch parece muito melhor do que fazer mais uma ligação.
    • Por que venture capital quase sempre acaba estragando tudo?

  • A resposta do CTO diz que eles vinham ampliando o escopo de uso do SDK para mais casos de clientes, mas que o objetivo é que o SDK seja usado de uma forma que mantenha a compatibilidade com a GPL.
    Ele entende que o SDK e o cliente são programas separados, que o código de cada programa está em repositórios separados, e que o simples fato de os dois programas se comunicarem por protocolos padrão não os torna um único programa sob a GPLv3. Diz também que o problema de conseguir compilar o app da forma tentada ali será corrigido como um bug simples.

    • Esse tipo de resposta é realmente frustrante. Ela evita a pergunta real de uma forma que parece entender de propósito o escopo da pergunta de maneira errada.
      O que eu gostaria de perguntar ao CTO é mais ou menos isto. Ele respondeu a “os advogados de vocês acham que conseguem escapar legalmente disso?”, mas não respondeu à pergunta central que preocupa as pessoas. A equipe do Bitwarden acha que não há problema ético em privatizar um projeto que muita gente apoiou e para o qual contribuiu explicitamente por ser open source? Gerenciamento de senhas é, por natureza, um negócio que exige muita confiança; como vocês pretendem lidar com a quebra de confiança, os forks e a saída de usuários causados por esse rug pull de open source para código fechado? Se a empresa está em uma situação desesperadora a ponto de considerar uma decisão dessas, não há uma forma de a comunidade ajudar a atravessar isso sem privatização?
      Entendo que, como CTO, agora o trabalho dele é fingir preocupação, especialmente em fóruns onde não dá para encerrar a conversa, mas a abordagem atual basicamente confirma o pior medo: “acreditamos que isso é legalmente possível e não vemos problema no que estamos fazendo”. É exatamente o clima errado para uma empresa cuja receita depende de os usuários confiarem no código e nas pessoas que o atualizam.
    • Em outras palavras, bitwarden/clients é GPLv3, o cliente Bitwarden como um todo funcional é software proprietário, o CTO não vê problema nisso, e a issue foi trancada.
    • A questão central não é necessariamente se é “um único programa”. O problema é esta parte:
      “O ‘Código-Fonte Correspondente’ de uma obra em forma de código objeto inclui todo o código-fonte necessário para gerar, instalar e executar o código objeto e para modificar a obra, bem como os scripts para controlar essas atividades.”
      Entendo que ganhar dinheiro como empresa open source é muito difícil. Por isso eu também sou um dos clientes pagos.
      A exceção anexada ao SDK parece muito parecida com o software de controle de versão BitKeeper, que foi usado no kernel Linux por um tempo. Basta ver como aquilo terminou.

  • Eu gostava, pagava e até recomendava para amigos, que também gostavam.
    Agora pretendo migrar para o KeePassXC. Qual é a forma recomendada de sincronizar o banco de dados com Android? Tenho apenas um servidor Raspberry Pi rodando cloudflared.

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 o SyncThing para distribuir o cofre do KeePass exatamente só nos dispositivos necessários. Para mim funciona muito bem. Pode variar conforme a necessidade

  • Eu realmente queria usar o KeePass e seu ecossistema, mas o compartilhamento de senhas não é muito bom. Minha esposa e eu temos muitas senhas compartilhadas, e o Bitwarden funciona muito bem nessa parte. Não sei qual seria uma alternativa prática para nós

  • O Keepass2Android pode sincronizar de várias formas, como ssh(sftp), Nextcloud etc. Você deve conseguir encontrar um método que sirva

  • A combinação de KeePassXC com o cliente Nextcloud para Android é perfeita para mim. Uso há anos sem problemas

  • Eles bloquearam a issue no GitHub para impedir novas discussões. Uma alternativa possível parece ser o Vaultwarden
    https://github.com/dani-garcia/vaultwarden
    É muito triste ver esse tipo de coisa continuar acontecendo em projetos open source quando entra gente com dinheiro

    • O Vaultwarden é um substituto de servidor; pelo que entendi, o problema aqui é a licença do cliente desktop
    • García começou recentemente a trabalhar na Bitwarden. Seria interessante ouvir o que ele pensa
    • O Vaultwarden oferece suporte a passkeys?

  • Nunca examinei em detalhes, mas, pelo marketing, achava que o Bitwarden era totalmente software livre. Só que, desde por volta de 2020, parece que começaram a entrar elementos proprietários estranhos

  • Eu esperava um dia migrar para o Bitwarden, mas, se não encontrar um ecossistema aberto saudável, acho que agora não vou mais. Vou continuar acompanhando para ver como isso se desenrola

    • Passei um ano fazendo uma migração completa para o Bitwarden com o backend Vaultwarden, mas a experiência ficou muito abaixo da que eu tinha com o 1Password
      Um dos critérios de avaliação era: “toda a minha família usa o 1Password e está satisfeita; será que isso é bom o bastante para convencê-los a migrar?”. A decisão final de migração poderia ser minha, mas, para fazer meus pais idosos adotarem algo novo, a experiência de usuário é muito importante
      No fim, a resposta foi não. Além de a UX em geral não ser boa, os clientes do Bitwarden eram muito mais lentos em Linux, Mac, Windows e iOS, em tudo, da busca ao login. Também tinham menos recursos, faltavam coisas perceptíveis como ordenação de senhas, favoritos e boas ferramentas de organização, e o preenchimento automático era bem menos confiável
      Ao longo dos anos, tive muitas reclamações sobre o modelo de negócios e o atendimento ao cliente do 1Password. Mesmo assim, um gerenciador de senhas — hoje quase mais um gerenciador de segredos que guarda mais do que senhas — é tão central no dia a dia que senti que precisava usar o que causasse menos sofrimento possível; infelizmente acabei voltando
      Eu não usei o Bitwarden por ser de código aberto; estava tentando usar o melhor gerenciador de senhas possível. Ainda assim, gostei do fato de ser aberto, e o Vaultwarden é uma joia. Eu realmente gostaria de ter tempo e habilidade para criar um frontend melhor

  • “No momento, não temos planos de ajustar a licença do SDK. Continuaremos publicando em nosso próprio repositório F-Droid https://mobileapp.bitwarden.com/fdroid/repo/.”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Esse problema já havia sido levantado em julho no repositório do SDK, e esse SDK tem essa licença há mais de um ano

  • Uso o Bitwarden no iOS, PC e Mac. Agora preciso procurar uma alternativa. É um dia realmente triste
    Eu também sou assinante premium de US$ 10 por ano. Vira receita perdida por causa de práticas suspeitas
    Existe alguma forma de exportar e migrar para outra alternativa?

  • Era um projeto que eu vinha acompanhando pensando que talvez pudesse ser uma alternativa melhor ao Keepass(X,XC), mas agora acho que no fim não vou migrar