Las guerras de licencias de código abierto: cómo HashiCorp, Redis y Elastic cambiaron las reglas
El patrón que se repite
Tres de los proyectos de software de infraestructura más utilizados en el mundo cambiaron sus licencias en un lapso de pocos años. HashiCorp cambió Terraform de la Licencia Pública de Mozilla 2.0 a la Licencia de Código Fuente Comercial (BSL) en agosto de 2023. Redis cambió de BSD a la Licencia Pública del Lado del Servidor (SSPL) en marzo de 2024. Elastic ya había movido Elasticsearch y Kibana a SSPL en 2021. Las tres empresas dieron explicaciones similares: los proveedores de nube estaban usando su software para construir servicios gestionados competidores sin contribuir de vuelta.
Las tres enfrentaron bifurcaciones comunitarias inmediatas. OpenTofu (Terraform) apareció semanas después del anuncio de HashiCorp, respaldado por la Fundación Linux. Valkey (Redis) se lanzó en marzo de 2024, también bajo la Fundación Linux, con contribuciones de ingenieros de AWS, Google, Oracle y Alibaba. OpenSearch (Elasticsearch) ya se había lanzado en 2021, liderado por AWS. El patrón es lo suficientemente consistente como para constituir un manual de jugadas, para ambos lados.
Lo que realmente hacen los cambios de licencia
La Licencia de Código Fuente Comercial (BSL), desarrollada por MariaDB y adoptada por HashiCorp, permite el uso gratuito para la mayoría de los propósitos, pero prohíbe usar el software en un producto comercial competidor sin una licencia comercial. Críticamente, el software con licencia BSL se convierte en una licencia de código abierto (generalmente Apache 2.0) después de cuatro años. HashiCorp estableció una ventana de conversión de cuatro años: Terraform 1.6 lanzado en agosto de 2023 se convertiría en Apache 2.0 en agosto de 2027.
SSPL, creada por MongoDB, es más agresiva: requiere que cualquiera que ofrezca el software como un servicio gestionado deba abrir el código fuente de toda la pila utilizada para ofrecer ese servicio, incluyendo orquestación, monitoreo e infraestructura de soporte. Debido a que esto es esencialmente imposible de cumplir para un proveedor de nube con infraestructura propietaria, SSPL funciona como una prohibición práctica de ofrecer servicios gestionados. La Iniciativa de Código Abierto no reconoce SSPL como una licencia de código abierto. Tampoco lo hace la Fundación de Software Libre. Tanto Redis como Elasticsearch bajo SSPL son, según las definiciones que más importan en la industria, software propietario que publica su código fuente.
HashiCorp: la adquisición que siguió
El desarrollo más significativo desde el punto de vista comercial en esta historia es lo que le sucedió a HashiCorp después del cambio de licencia. IBM adquirió HashiCorp en abril de 2024 por $6.4 mil millones, una de las mayores adquisiciones en software de infraestructura empresarial. IBM opera Red Hat, que está construido casi por completo sobre software de código abierto y es la empresa de Linux empresarial más grande del mundo. La adquisición de HashiCorp trae Terraform, Vault, Consul y Nomad a la cartera de IBM junto con OpenShift y Ansible de Red Hat.
La bifurcación OpenTofu, mientras tanto, alcanzó la versión 1.7 en mayo de 2024, implementando características que Terraform aún no había lanzado. El respaldo de la Fundación Linux significa que OpenTofu tiene apoyo institucional y es poco probable que colapse por agotamiento de los mantenedores, el destino de muchas bifurcaciones comunitarias. OpenTofu es ahora una alternativa creíble a largo plazo a Terraform para organizaciones incómodas con las restricciones de BSL o la propiedad de IBM.
La pregunta práctica para los equipos que actualmente usan Terraform es directa: si no estás ofreciendo Terraform como servicio comercialmente y no estás en un proveedor de nube, BSL no te restringe. La mayoría de los usuarios empresariales no se ven afectados. El cambio de licencia importa más a las empresas que quieren construir servicios gestionados de Terraform, y para ellas, OpenTofu es el camino obvio.
Redis: la bifurcación que se movió más rápido
El cambio de licencia de Redis fue el más dramático en términos de velocidad y amplitud de respuesta. Dentro de una semana del anuncio de marzo de 2024, AWS, Google Cloud, Oracle y Alibaba Cloud habían comprometido recursos de ingeniería a Valkey, una bifurcación de Redis 7.2.4 bajo la Fundación Linux, la última versión bajo la antigua licencia BSD. El repositorio de GitHub de Valkey tuvo más contribuyentes en su primer mes que la mayoría de los proyectos de código abierto acumulan en años.
Redis Ltd. (la empresa, distinta del proyecto Redis) ha mantenido que Redis nunca fue realmente "código abierto comunitario" de la misma manera que Linux o PostgreSQL; siempre fue controlado por la empresa. Esto es técnicamente cierto: Redis Ltd. poseía los derechos de autor, requería un CLA para las contribuciones y tomaba todas las decisiones arquitectónicas importantes. La licencia BSD fue una elección comercial, no un principio fundacional. Cuando el cálculo comercial cambió, específicamente cuando AWS ElastiCache y otros servicios gestionados de Redis crecieron lo suficiente como para reducir significativamente el mercado direccionable de Redis Ltd., la licencia cambió.
Valkey 7.2 es ahora la oferta predeterminada compatible con Redis en múltiples plataformas de nube importantes. Para nuevos proyectos que comienzan hoy, la elección práctica es entre Valkey (Fundación Linux, Apache 2.0, soporte nativo en la nube) y Redis 7.4+ (SSPL, Redis Ltd., licencias comerciales para servicios gestionados). Ambos son maduros, ambos tienen buen rendimiento y la API es casi idéntica. El ecosistema se está dividiendo.
Elastic: el caso más antiguo que ahora parece la plantilla
El cambio de licencia de Elastic en 2021 fue el más temprano y, en cierto modo, el caso más claro. Elastic movió Elasticsearch y Kibana a SSPL en respuesta directa a que Amazon ofreciera un servicio gestionado de Elasticsearch, Amazon Elasticsearch Service, sin contribuciones sustanciales de vuelta al proyecto. La respuesta de Amazon fue bifurcar Elasticsearch 7.10 (la última versión bajo Apache 2.0) y crear OpenSearch, que ahora mantiene y ha contribuido a la Fundación Linux.
Cuatro años después, OpenSearch se ha desviado significativamente de Elasticsearch. AWS envía características en OpenSearch que no tienen equivalente en Elastic, y Elastic ha enviado características en Elasticsearch que no están en OpenSearch. Los dos ya no son intercambiables para casos de uso avanzados. Los equipos que eligen entre ellos hoy están efectivamente eligiendo entre dos productos diferentes que comparten un ancestro común, no entre "la cosa real" y "una bifurcación".
El modelo de núcleo abierto y sus límites
Las empresas que han evitado esta dinámica con más éxito son aquellas que construyeron modelos de núcleo abierto desde el principio, en lugar de depender de licencias permisivas para productos populares que esperaban monetizar más tarde. GitLab, Grafana y el propio Vault de HashiCorp son ejemplos donde el producto central es de código abierto, pero las características empresariales sustanciales (SSO, auditoría de registros, RBAC avanzado, herramientas de cumplimiento) son solo comerciales. Esto crea una captura de valor clara sin restringir el uso comunitario que impulsa la adopción.
El camino del cambio de licencia, lanzar bajo una licencia permisiva, construir una adopción masiva y luego cambiar a una licencia más restrictiva una vez que un proveedor de nube está compitiendo, se ve cada vez más como una puerta de un solo sentido. Una vez que existe una bifurcación comunitaria con respaldo institucional, el proyecto original ha perdido la buena voluntad comunitaria que la licencia permisiva estaba generando. Se queda con el negocio comercial, pero sin el posicionamiento de "proyecto de código abierto que todos usan" que lo impulsó.
Para desarrolladores y equipos de infraestructura, la conclusión práctica es: trata cualquier proyecto de código abierto controlado por una sola empresa con un requisito de CLA como potencialmente propietario. La licencia que ves hoy puede no ser la licencia que gobierne el software en tres años. El software de código abierto más seguro, desde una perspectiva de riesgo de licencia, es propiedad de una fundación (Fundación Linux, Fundación de Software Apache, CNCF) o tiene una gobernanza genuinamente distribuida en lugar de control de una sola empresa.
Lo que viene después
Las guerras de licencias no han terminado. Varios otros proyectos de infraestructura ampliamente utilizados, mantenidos por empresas bien financiadas con competencia de proveedores de nube, enfrentan dinámicas similares. Las empresas han observado lo que sucedió con HashiCorp, Redis y Elastic y están tomando decisiones de licencia en consecuencia.
Un modelo emergente: licencia dual desde el primer día, donde el software está disponible tanto bajo una licencia de código abierto para uso comunitario como bajo una licencia comercial para uso empresarial en producción, con límites claros que no cambian retroactivamente. Otro: propiedad de la fundación desde el inicio, sin que una sola empresa controle la licencia. Ningún modelo resuelve perfectamente la tensión fundamental entre las dinámicas de adopción del código abierto y la monetización del software comercial, pero ambos evitan el daño a la confianza que proviene de cambiar las licencias después de que la comunidad ya ha construido sobre tu software.