Bitwarden Abandonou o Open Source? O Que a Licença Dupla Muda pra Você

Você abre o Bitwarden todo dia, provavelmente nem pensa nisso. Preenche senha aqui, gera uma lá, sincroniza entre o celular e o notebook. Tudo funciona. Até que, no dia 9 de outubro de 2026, um post discreto no fórum oficial da Bitwarden acendeu um alerta vermelho na comunidade open source.

A partir da próxima versão, os apps publicados nas lojas (Google Play, App Store, Microsoft Store) serão builds com licença comercial, não mais GPLv3. A versão open source continua existindo no GitHub. Mas o app que você baixa? Esse agora é comercial.

E a pergunta que todo mundo está fazendo: isso é o começo do fim do Bitwarden como software livre?

O que mudou, na prática

Vamos separar o que é fato do que é especulação.

Fato: a Bitwarden anunciou um modelo de licença dupla (dual license). Isso significa que o código-fonte continua disponível no GitHub sob GPLv3. Você pode clonar, compilar, rodar, forkar. Isso não mudou.

Fato: os binários distribuídos pelas lojas oficiais agora carregam uma licença comercial. Quem baixa o Bitwarden pela App Store está aceitando termos comerciais, não a GPL.

Fato: a empresa disse que “todas as funcionalidades atuais estão disponíveis em ambas as versões”. A palavra-chave aqui é atuais.

O detalhe que preocupa: novas funcionalidades serão avaliadas “caso a caso” para decidir em qual licença entram. Traduzindo: features futuras podem existir apenas na versão comercial, sem equivalente na versão open source.

É exatamente esse ponto que fez a comunidade pirar.

Por que a Bitwarden fez isso?

A resposta oficial é vaga: “proteção legal adicional para funcionalidades selecionadas”. Na prática, quem acompanha o mercado de software livre sabe que isso é linguagem corporativa para “queremos controlar quem redistribui nosso software”.

O alvo declarado são empresas que reempacotam e revendem o Bitwarden. Pense em consultorias que pegam o código GPL, colocam a logo delas e vendem como “solução própria de gestão de senhas”. A licença comercial impede isso.

Parece razoável, certo? Até é. Mas o problema é que a mesma licença comercial se aplica a todo mundo que baixa pela loja, não só a revendedores.

Existe um contexto de mercado importante aqui. O setor de gerenciadores de senhas está em transformação. Passkeys estão avançando rápido, o iOS e o Android já têm gerenciadores nativos razoáveis, e o mercado B2C (consumidor final) está encolhendo. Tanto a Bitwarden quanto a 1Password estão pivotando para B2B, vendendo para empresas. E no B2B, licença comercial é o padrão.

Um usuário do Privacy Guides resumiu bem: “isso cheira a enshittification”, a degradação gradual de um serviço que começa gratuito e aberto, depois vai fechando aos poucos conforme a pressão por receita aumenta.

A história se repete

Se você acompanha o ecossistema open source, já viu esse filme antes. Várias vezes.

O padrão é sempre o mesmo: empresa cresce com contribuições da comunidade, atrai investidores, depois muda a licença quando precisa proteger receita. A justificativa oficial varia (“cloud providers parasitas”, “proteção legal”, “sustentabilidade”), mas o resultado é igual: menos liberdade para o usuário.

A diferença com a Bitwarden é que ela não está mudando a licença do código-fonte. O código continua GPL no GitHub. O que muda é o canal de distribuição. E isso é mais sutil, mais difícil de perceber, e por isso mesmo mais perigoso.

O que significa “dual license” na prática

Dual licensing não é novidade. O MySQL faz isso desde os anos 2000 (GPL + licença comercial). O Qt usa o mesmo modelo. A ideia é simples: o código é livre, mas se você quer usar em contextos que a GPL não permite (software proprietário, por exemplo), você paga pela licença comercial.

No caso da Bitwarden, o modelo é um pouco diferente. Não é “escolha a licença que quiser”. É “o código no GitHub é GPL, mas o app da loja é comercial”. Você, como usuário final, não escolhe. A escolha já foi feita por você.

Para a maioria dos usuários isso é irrelevante. Você vai continuar usando o Bitwarden normalmente, as senhas vão continuar sincronizando, nada muda no dia a dia. Mas para quem se importa com software livre, para quem escolheu Bitwarden porque era open source, essa mudança é simbólica.

Porque a promessa implícita sempre foi: “somos diferentes, somos open source de verdade”. E agora a pergunta é: até quando?

O elefante na sala: funcionalidades futuras

Aqui está o ponto que realmente importa. A Bitwarden disse que features futuras serão avaliadas “caso a caso”. Isso significa que, em algum momento, uma funcionalidade nova vai aparecer no app da loja e não vai existir na versão GPL.

Quando isso acontecer, a versão open source do Bitwarden se torna uma versão “lite”, um software de segunda classe que existe mais como vitrine do que como produto completo. E aí o argumento “mas o código continua aberto” perde força, porque o código aberto não tem paridade com o produto que as pessoas realmente usam.

Isso já aconteceu antes. O Bitwarden tem um histórico complicado com licenciamento. Em 2024, a comunidade levantou preocupações quando o SDK interno do Bitwarden foi publicado com licença proprietária, proibindo explicitamente o uso do SDK para “desenvolver aplicações para uso com software que não seja Bitwarden”. A empresa recuou parcialmente, reorganizou o repositório e colocou o sdk-internal sob GPL. Mas o precedente ficou.

O impacto para quem faz self-hosting

Um dos argumentos mais fortes da Bitwarden sempre foi o self-hosting. Diferente da 1Password, que é 100% SaaS, o Bitwarden permite que você rode seu próprio servidor. Muita gente escolheu a ferramenta por isso.

A empresa garante que “o self-hosting não será afetado”. Mas essa garantia se aplica ao cenário atual. Se features futuras forem exclusivas da licença comercial, o servidor self-hosted (compilado a partir do código GPL) pode ficar defasado.

Imagine que a Bitwarden lance um recurso de compartilhamento avançado para equipes, ou integração com SSO empresarial, e esse recurso só exista na versão comercial. Quem faz self-hosting vai ter que escolher: aceitar a licença comercial ou ficar sem a feature.

Não é que isso vai acontecer amanhã. Mas a porta foi aberta. E em software, portas abertas tendem a ser atravessadas.

Vaultwarden: o fork que já existia antes da crise

Se você é dev e roda infraestrutura própria, provavelmente já conhece o Vaultwarden. É uma implementação alternativa do servidor Bitwarden, escrita em Rust, com mais de 35.000 stars no GitHub.

O Vaultwarden não usa o código do Bitwarden server. Ele implementa a API do Bitwarden do zero, é muito mais leve (roda tranquilo num Raspberry Pi) e é compatível com todos os clientes oficiais do Bitwarden.

Com a mudança de licença, o Vaultwarden se torna ainda mais relevante. Se a versão GPL do Bitwarden server começar a perder features, o Vaultwarden pode se tornar a referência da comunidade para self-hosting.

Outras alternativas que valem a pena conhecer:

KeePassXC: totalmente local, sem servidor, sem sincronização nativa. Você controla tudo. Combina bem com Syncthing ou Nextcloud para sync entre dispositivos. É a opção mais “purista” em termos de software livre.

Passbolt: focado em times. Se você precisa compartilhar senhas em equipe com auditoria e controle de acesso, o Passbolt é provavelmente a melhor opção open source. Roda self-hosted com Docker.

Proton Pass: não é open source no servidor, mas os clientes são. Faz parte do ecossistema Proton (ProtonMail, ProtonVPN). Se você já usa Proton, faz sentido considerar.

Como compilar o Bitwarden GPL do zero

Se a mudança de licença te incomoda o suficiente para agir, você ainda pode compilar o Bitwarden a partir do código-fonte GPL. Não é trivial, mas também não é impossível.

Para o cliente web/desktop (Electron):

git clone https://github.com/bitwarden/clients.git
cd clients
npm ci
# Build do cliente web
cd apps/web
npm run build

# Build do desktop (Electron)
cd ../desktop
npm run build

Para o servidor (se não quiser usar Vaultwarden):

git clone https://github.com/bitwarden/server.git
cd server
# Requer .NET SDK 8+
dotnet restore
dotnet build

O ponto importante: isso compila a versão GPL, sem as funcionalidades que eventualmente fiquem exclusivas da licença comercial. Hoje, ambas as versões são idênticas. Amanhã, talvez não.

A questão de confiança

Eu já vi esse argumento centenas de vezes em discussões sobre software: “a empresa prometeu que o plano gratuito é permanente”. E é verdade, a Bitwarden disse exatamente isso no anúncio.

Mas promessas corporativas não são contratos. Um CEO novo, uma rodada de investimento, uma aquisição, qualquer um desses eventos pode mudar a direção da empresa da noite pro dia. Quem confiava no Redis Labs? No HashiCorp? Na Elastic?

Isso não quer dizer que a Bitwarden vai necessariamente seguir o mesmo caminho. Mas quer dizer que a estrutura de incentivos mudou. Antes, a GPL nos binários distribuídos era uma garantia estrutural: qualquer pessoa podia pegar aquele binário e redistribuir. Agora, com licença comercial, essa garantia não existe mais.

A confiança em software livre nunca foi sobre confiar em pessoas. Foi sobre confiar em licenças. E quando a licença muda, a base da confiança muda junto.

O que fazer agora?

Se você é usuário casual do Bitwarden: nada. Sério. O app vai continuar funcionando igual. Suas senhas estão seguras. Não precisa migrar pra lugar nenhum por causa disso.

Se você é um defensor de software livre e escolheu Bitwarden por princípios:

1. Considere Vaultwarden para self-hosting. É mais leve, mais rápido, e não depende da boa vontade da Bitwarden Inc.
2. Exporte suas senhas regularmente. Bitwarden permite exportar em .json ou .csv. Faça isso como hábito, independente de qualquer drama de licença.
3. Acompanhe o repositório no GitHub. Se features começarem a aparecer só na versão comercial, a comunidade vai perceber. E vai fazer barulho.
4. Avalie KeePassXC se você não precisa de sincronização na nuvem. É a opção mais segura e mais livre que existe.

Para exportar suas senhas agora:

# Via Bitwarden CLI
npm install -g @bitwarden/cli
bw login
bw export --format json --output ~/bitwarden-backup.json

Se quiser automatizar o backup, um cron simples resolve:

# Backup semanal das senhas (adicione ao crontab)
0 3 * * 0 bw export --format json --output ~/backups/bitwarden-$(date +\%Y\%m\%d).json

O importante aqui não é sair do Bitwarden. É não ficar refém. Qualquer gerenciador de senhas que não te deixa exportar facilmente já é um red flag. Pelo menos nisso, a Bitwarden ainda joga limpo.

O open source não está morrendo, está mutando

A real é que o modelo “empresa VC-backed mantém software GPL” nunca funcionou muito bem. As empresas precisam de receita, os investidores querem retorno, e a GPL permite que qualquer um pegue o código e concorra sem pagar nada. Era questão de tempo até o modelo entrar em conflito.

O que está surgindo no lugar são modelos híbridos: source-available (código visível mas não livre), dual licensing (o caso da Bitwarden), e licenças copyleft fortes como a AGPL que tentam forçar contribuições de volta.

Nenhum desses modelos é perfeito. Mas a ideia de que open source significa “faça o que quiser, de graça, para sempre” era uma ilusão bonita que o mercado está corrigindo com força.

O Bitwarden pelo menos manteve o código no GitHub sob GPL. Isso é mais do que o Redis, o HashiCorp e a Elastic fizeram. Então, por enquanto, o copo está meio cheio.

O cenário mais provável? A Bitwarden vai adicionar features premium na versão comercial aos poucos, tão devagar que ninguém vai perceber o momento exato em que a versão GPL virou irrelevante. É assim que funciona. Não é um golpe, é erosão.

Se você depende do Bitwarden no dia a dia, continue usando. Mas tenha um plano B. Exporte suas senhas, conheça as alternativas, e preste atenção nos changelogs. Quando a primeira feature exclusiva aparecer na versão comercial, você já vai saber o que fazer.

—

Fonte de inspiração: Bitwarden Dual License Model, Hacker News