Por qué los cambios de licencia le afectan incluso en self-hosting
Un cambio de licencia se aplica a las nuevas versiones del software, no de forma retroactiva a lo que usted ya ha desplegado. Pero quedarse en una versión antigua significa renunciar a los parches de seguridad. El riesgo real no es, por tanto, la demanda inmediata: es la deuda técnica que se acumula mientras espera una aclaración jurídica.
Incluso un uso puramente interno puede verse afectado si su organización factura servicios a terceros o expone la herramienta a través de una API externa. Y el límite entre «uso interno» y «servicio expuesto» es precisamente donde SSPL y BSL divergen.
Desde 2021, cuatro oleadas de relicenciamiento han afectado a componentes presentes en miles de stacks de producción: Elasticsearch (enero 2021 → SSPL), Redis (marzo 2024 → RSALv2+SSPL, luego mayo 2025 → AGPLv3 disponible), Terraform (agosto 2023 → BSL), MariaDB MaxScale (enero 2025 → propietario puro).
Los cuatro casos en los que la licencia crea una restricción real
- Reventa de un servicio cloud competidor — la BSL prohíbe explícitamente ofrecer a terceros un servicio comercial que compita con el producto de origen. Alojar Terraform para sus propias infraestructuras sigue estando permitido; ofrecerlo como plataforma gestionada a sus clientes no lo ha estado desde la versión 1.6 (agosto 2023).
- Exposición de un servicio a terceros bajo SSPL — si construye un servicio que consumen usuarios externos y que se apoya en un componente SSPL, está obligado a publicar la totalidad de su pila de software. MongoDB aplica la SSPL desde octubre de 2018; la obligación solo se activa cuando ofrece MongoDB «como servicio» a otros.
- Integración en un SaaS bajo AGPLv3 — todo editor que integre una librería AGPLv3 en una aplicación accesible a través de la red debe distribuir el código fuente completo de esa aplicación. Desde agosto de 2024, Elasticsearch ofrece de nuevo AGPLv3, lo que lo distingue de la SSPL que abandonó en 2021.
- Actualización a una versión con nueva licencia — pasar de Redis 7.2 (BSD) a Redis 7.4+ (RSALv2+SSPL) o de Terraform 1.5 (MPL-2.0) a 1.6+ (BSL) cambia sus derechos sin que su pipeline de actualización automática lo detecte. Redis 8.0 (2025) introduce una tercera opción AGPLv3 — pero el paquete por defecto en Ubuntu 24.04 es ahora Valkey (BSD-3-Clause).
Cronología de los grandes relicenciamientos (2021–2025)
Entender el contexto de cada decisión ayuda a anticipar las siguientes. Esta es la secuencia que reconfiguró el ecosistema open source de infraestructura:
Enero 2021 — Elasticsearch y Kibana (Elastic). Elastic pasa de Apache 2.0 a una doble licencia SSPL / Elastic License 2.0 a partir de la versión 7.11. AWS responde forkeando Elasticsearch 7.10.2 (última versión Apache 2.0) para crear OpenSearch, lanzado en abril de 2021 bajo Apache 2.0 y transferido a la Linux Foundation en septiembre de 2024. En agosto de 2024, Elastic da marcha atrás parcial y añade AGPLv3 como opción de licencia.
Octubre 2018 / marzo 2024 — MongoDB y Redis (SSPL). MongoDB fue el primero en adoptar la SSPL en 2018, sentando un precedente que Redis siguió el 20 de marzo de 2024 pasando de BSD-3-Clause a RSALv2+SSPL a partir de la versión 7.4. La Linux Foundation lanza Valkey el 28 de marzo de 2024 — cuatro días después del anuncio de Redis — como fork de Redis 7.2.4 bajo BSD-3-Clause. Ubuntu 24.04, lanzado en abril de 2024, adopta Valkey como paquete por defecto. En mayo de 2025, Redis añade AGPLv3 a su portfolio de licencias, impulsado por el retorno del creador original Salvatore Sanfilippo (antirez), que se había unido a Redis Inc. en noviembre de 2024.
Agosto 2023 — Terraform y HashiCorp (BSL). El 10 de agosto de 2023, HashiCorp cambia Terraform de MPL-2.0 a BSL 1.1 a partir de la versión 1.6. El manifiesto OpenTF aparece el 15 de agosto, recibe 32.000 estrellas en GitHub en diez días, y OpenTofu es aceptado por la Linux Foundation el 20 de septiembre de 2023. OpenTofu 1.6.0 sale en enero de 2024 bajo MPL-2.0.
Enero 2025 — MariaDB MaxScale (propietario puro). MariaDB va un paso más allá: MaxScale 25.01 pasa de BSL a licencia totalmente propietaria que requiere una suscripción activa. Las versiones anteriores (24.02, 23.08) permanecen bajo BSL y convertirán a GPL según la cláusula de conversión temporal.
BSL, SSPL y AGPLv3: qué autoriza y qué prohíbe cada modelo
La BSL (Business Source License) es una licencia temporal: el código es source-available hoy y pasará a ser open source — a menudo Apache 2.0 o GPL — tras un plazo fijado de antemano (cuatro años en el caso de HashiCorp). La cláusula de restricción apunta a un «uso adicional permitido» definido por el editor: en HashiCorp, es la prestación de un servicio gestionado competidor. El uso interno, incluso comercial, sigue siendo libre.
La SSPL (Server Side Public License, versión 1) va más lejos: exponer la herramienta como servicio a terceros activa una obligación de publicación total de la pila — software de gestión, interfaces de usuario, APIs, herramientas de automatización, monitorización, backup y hosting. MongoDB publica una FAQ que aclara que la obligación solo se activa cuando se ofrece MongoDB «como servicio»; usar MongoDB como base de datos en su propio SaaS no la activa. La SSPL no está reconocida por la OSI como licencia open source.
La AGPLv3, la única de las tres aprobada por la OSI, es un copyleft de red: no restringe el uso comercial, pero obliga a abrir el código fuente de cualquier aplicación que integre un componente AGPLv3 en cuanto esta da servicio a usuarios a través de la red. Para un self-hoster interno la restricción es casi nula; para un editor SaaS que integra una librería AGPLv3 en un producto cerrado, la restricción es existencial.
Las licencias BSD / MIT / Apache 2.0 permanecen sin ninguna obligación de publicación en todos los casos de uso. Por eso los forks comunitarios (Valkey, OpenTofu, OpenSearch) eligen BSD-3-Clause o Apache 2.0.
BSL vs SSPL vs AGPLv3 vs BSD de un vistazo
Desplace la tabla
| Licencia | Self-hosting interno | Uso SaaS (reventa) |
|---|---|---|
| BSL | Permitido sin condiciones | Prohibido si el servicio compite con el editor de origen |
| SSPL | Permitido sin condiciones | Permitido si publica toda su pila de software |
| AGPLv3 | Permitido sin condiciones | Permitido si distribuye el código fuente de su aplicación |
| BSD / MIT / Apache 2.0 | Permitido sin condiciones | Permitido sin obligación de publicación |
Por herramienta: qué cambia en la práctica el relicenciamiento
Redis → Valkey o Redis 8 AGPLv3.
Redis 7.2.x (BSD-3-Clause) sigue siendo de uso libre tal cual. A partir de Redis 7.4, está bajo RSALv2+SSPL: si su uso es interno, no hay obligación inmediata, pero ya no puede redistribuirlo bajo BSD. La elección práctica: migrar a Valkey (fork BSD, compatible API con Redis 7.2, paquete por defecto en Ubuntu 24.04 y Debian 13, mantenido por AWS, Google y Oracle) o, si desea quedarse en la codebase oficial, elegir la variante AGPLv3 de Redis 8 (disponible desde mayo de 2025). La migración a Valkey no es destructiva: el protocolo RESP y los comandos son idénticos, y los clientes Redis existentes (redis-py, ioredis, Jedis) funcionan sin modificación.
Elasticsearch → OpenSearch o Elasticsearch AGPLv3.
OpenSearch 1.0 (fork de Elasticsearch 7.10.2, Apache 2.0) está en producción desde julio de 2021. Si permanece en Elasticsearch 7.x sin migrar, está en una versión sin parches de seguridad desde mediados de 2023. La variante AGPLv3 de Elasticsearch 8.x (desde agosto de 2024) es la opción más limpia para un self-hoster interno.
Terraform → OpenTofu.
OpenTofu 1.6+ es la continuidad directa de Terraform 1.5 bajo MPL-2.0. La sintaxis HCL es idéntica y los providers del Terraform Registry son compatibles.
MongoDB → uso interno libre, servicio gestionado a verificar.
Para un self-hoster que usa MongoDB como base de datos de una aplicación interna, la SSPL no se activa. Si planea ofrecer «MongoDB como servicio» a terceros, o abre su pila completa (SSPL) o toma una licencia comercial MongoDB Enterprise.
MariaDB MaxScale 25.01 → versión 24.02 BSL o alternativa.
MaxScale 24.02 permanece bajo BSL y convertirá a GPL. ProxySQL (GPL-2.0) y HAProxy con el módulo MySQL son alternativas consolidadas para el enrutamiento de tráfico MySQL/MariaDB.
Redis añadió la AGPLv3 a sus opciones de licencia en mayo de 2025, uniéndose a Elastic, que había hecho lo mismo en agosto de 2024. Para un self-hoster que no expone su aplicación a terceros, elegir la variante AGPLv3 de Redis 8 ya es posible sin pasar por el fork Valkey — aunque Valkey sigue en BSD-3-Clause y constituye el paquete por defecto en Ubuntu 24.04 y Debian 13. El criterio de elección: si necesita las nuevas funcionalidades de Redis 8 (Vector Sets, RESP3 mejorado), quédese en Redis AGPLv3; si quiere la licencia más permisiva sin ninguna restricción de red, Valkey es el camino sin fricción.
Matriz de decisión: qué fork para qué caso de uso
Antes de elegir entre la herramienta original y su fork, plantéese tres preguntas en orden:
1. ¿Cuál es mi uso real? Solo interno (ningún tercero consume el servicio) → BSL y SSPL no crean obligaciones inmediatas, pero pierde la libertad de redistribución. Servicio expuesto a socios o clientes → compruebe si su caso cae bajo la definición de «servicio competidor» (BSL) o «prestación del servicio a terceros» (SSPL).
2. ¿Existe un fork mantenido activamente? Para Terraform → OpenTofu (Linux Foundation). Para Redis → Valkey (Linux Foundation, AWS + Google + Oracle). Para Elasticsearch → OpenSearch (Linux Foundation desde septiembre de 2024). Estos tres proyectos tienen SLA de parches de seguridad y ciclos de release publicados.
3. ¿Es el fork compatible con la API? Valkey y Redis 7.2: compatible al 100% (protocolo RESP, mismos comandos). OpenTofu y Terraform 1.5: HCL compatible, providers idénticos. OpenSearch y Elasticsearch 7.10: compatible para la mayoría de queries DSL, pero los plugins de Elasticsearch 8.x no son portables.
Si existe un fork mantenido, compatible con la API y que sigue una cadencia de seguridad: cámbiese a él. El coste de una migración preventiva es medible; el coste de la conformidad bajo presión — especialmente si una cláusula SSPL se activa por un cambio de uso — no lo es.
Los reflejos que conviene adoptar antes de integrar una herramienta en su stack
Compruebe la licencia antes de añadir una dependencia. La licencia se lee en el archivo LICENSE en la raíz del repositorio y en el changelog de las últimas versiones mayores. Una herramienta que estaba bajo MIT hace dos años puede estar bajo BSL hoy — actualizar su docker-compose.yml no lo indicará.
Suscríbase a las releases de GitHub. El botón «Watch → Custom → Releases» en el repositorio de un componente crítico le envía un correo por cada nueva versión. Es el único canal que garantiza que verá un cambio de licencia antes de que se embarque en su próximo apt upgrade o helm upgrade.
Distinga su caso de uso real de lo que apunta la licencia. La BSL de HashiCorp apuntaba a AWS, Azure y Google — no a los equipos que automatizan su propia infraestructura. La SSPL de MongoDB apuntaba a los cloud providers — no a los desarrolladores que usan MongoDB como base de datos de un producto SaaS. Leer la FAQ oficial de cada licencia evita tomar decisiones conservadoras innecesarias.
Evalúe el fork de forma preventiva, no bajo presión. Valkey, OpenTofu y OpenSearch existen precisamente para que un equipo pueda migrar sin urgencia. Probar la compatibilidad en un entorno de desarrollo lleva pocas horas; migrar en producción en una semana tras un anuncio de relicenciamiento es otra historia.
Documente la licencia de cada dependencia en su inventario. Una tabla sencilla — herramienta, versión en producción, licencia, fecha del último control, fork disponible — convierte una auditoría puntual en mantenimiento continuo. Actualícela en cada bump de versión mayor.
