Bitwarden cambia a licencia dual: qué pierde el open source

Qué cambia exactamente en Bitwarden

Bitwarden confirmó que, a partir de su próxima release, las apps que se publican en las distintas tiendas serán las builds con licencia comercial. El cambio no requiere ninguna acción por parte de los usuarios: según la compañía, las aplicaciones funcionarán exactamente igual que hoy.

El movimiento no elimina el código abierto. La versión con licencia GPLv3 sigue actualizándose y publicándose en GitHub, y todas las funciones actuales están disponibles en ambas versiones. La diferencia aparece hacia adelante: algunos componentes futuros se publicarán bajo licencia comercial y existirán solo en esa build, y cada nueva función se evaluará caso por caso para decidir qué licencia le aplica.

Por qué Bitwarden dice que no es un rugpull

La respuesta oficial en el foro de la comunidad es directa: Bitwarden continúa desarrollando código abierto bajo GPLv3, y el código bajo licencia comercial es igual de visible y transparente en GitHub. La empresa sostiene que este modelo de licencia dual le da protección legal adicional para funciones selectas.

Ese es el argumento central: no hay código cerrado, hay dos licencias sobre un repositorio que sigue siendo visible. Para una empresa que monetiza un gestor de contraseñas, la licencia comercial permite imponer condiciones a terceros que reempaquetan o revenden el producto.

La comunidad no compró el argumento de inmediato. Varios usuarios del foro señalaron que el patrón —open source, luego semi-open source, luego descontinuación— ya se vio en otros proyectos, y citaron MinIO como precedente. Otro usuario trajo el caso de ColdCard de Coinkite: software publicado de forma abierta pero sin licencia FOSS, lo que a su criterio desincentivó el fork, la auditoría y la revisión comunitaria. Son argumentos planteados por usuarios del hilo, no hechos que Bitwarden haya confirmado.

Qué pasa con el self-hosting y con Vaultwarden

Bitwarden fue explícito en un punto: para los servidores comunitarios de terceros no hay cambios, y pueden seguir eligiendo qué funciones soportar y desarrollar en su propio servidor. Eso cubre, en principio, a proyectos como Vaultwarden.

Pero la respuesta dejó abierta la pregunta que más preocupa a los self-hosters: si todas las funciones futuras seguirán disponibles para quien aloja su propia instancia. Un usuario lo planteó sin rodeos: su requisito no es self-hostear hoy, sino tener la opción de hacerlo como estrategia de salida si algo sale mal. Con componentes futuros que podrían existir solo en la build comercial, esa garantía deja de ser obvia.

Quedaron también sin respuesta preguntas concretas sobre qué versión recibe el canal Flatpak de Linux y si un addon de navegador comercial seguirá siendo compatible con un cliente open source.

¿Qué significa esto para tu startup?

Para un equipo que usa Bitwarden como gestor de contraseñas corporativo, el impacto inmediato es cero: mismas apps, mismas funciones, sin migración. El riesgo no está hoy, está en la trayectoria.

El punto de fondo es de dependencia. Cuando una herramienta crítica para tu operación —gestión de credenciales, base de datos, cola de mensajes, observabilidad— cambia su licencia, lo que cambia no es solo el precio: cambia tu capacidad de salir. Si el código que necesitas deja de estar bajo una licencia que te permite forkearlo o autoalojarlo, tu plan B se debilita justo cuando más lo necesitas.

Para un founder hispanohablante esto pesa distinto según el mercado. Un equipo en LATAM con presupuesto ajustado suele apoyarse en self-hosting para controlar costos; uno en España, con clientes europeos, suma requisitos de residencia de datos. En ambos casos, la licencia es parte de la infraestructura, no un detalle legal.

Cómo evaluar el riesgo de licencia en tus herramientas críticas

• Inventaría tus dependencias críticas y su licencia. Anota, para cada una, si es permisiva (MIT, Apache), copyleft (GPL, AGPL) o dual. Marca las que sostienen autenticación, datos y despliegue.
• Define tu estrategia de salida antes de necesitarla. Para cada herramienta crítica responde: ¿puedo exportar mis datos? ¿existe un fork activo? ¿puedo autoalojar la versión que ya uso? Si la respuesta es no, tienes un riesgo abierto.
• Fija la versión que confías. Si dependes de una build concreta, mantén un pin de versión y evalúa los cambios de licencia antes de actualizar, no después.
• Sigue el repositorio, no el comunicado. En modelos de licencia dual, lo que importa es qué se publica bajo qué licencia en cada release.

Conclusión

Bitwarden no cerró su código: mantiene la versión GPLv3 en GitHub y afirma que las funciones actuales siguen en ambas builds. El cambio es de gobernanza hacia adelante, y la propia empresa admite que algunas funciones futuras vivirán solo en la build comercial.

Para un founder, la lección no es sobre Bitwarden en particular, sino sobre cómo se gestionan las dependencias críticas. La pregunta útil no es si una herramienta es open source, sino qué pasa si mañana cambia: ¿puedes irte con tus datos y tu código? Las respuestas que quedaron abiertas en el foro —Flatpak, compatibilidad de addons, garantías a futuro— son exactamente el tipo de cláusula que conviene tener resuelta antes de que haga falta.

Nota de verificación: las búsquedas realizadas para esta nota no devolvieron cobertura periodística adicional verificable sobre el cambio de licencia, por lo que el artículo se apoya en el anuncio y el hilo oficial de la comunidad de Bitwarden.

Fuentes

• Bitwarden Community - Published version update in app stores (fuente original)