Redis adopta una licencia dual de código fuente disponible

Artículo original ↗ Discusión en Hacker News ↗

Qué cambió Redis

  • El núcleo de Redis pasó de BSD de 3 cláusulas a una doble licencia:
    • SSPLv1 para el código fuente (copyleft, no aprobada por la OSI).
    • RSALv2 para uso de “código fuente disponible”, restringiendo las “ofertas competitivas” (por ejemplo, Redis como servicio).
  • El blog y las FAQ enfatizan:
    • El uso autohospedado / interno sigue siendo gratuito.
    • Los proveedores de servicios gestionados deben cumplir SSPL (abrir toda su pila de servicios) o firmar acuerdos comerciales.

Impacto en usuarios y distribuciones

  • La mayoría de los comentaristas piensa:
    • Los desarrolladores de aplicaciones típicas que usan Redis como dependencia no se ven afectados legalmente.
    • Los productos SaaS/DBaaS que ofrecen servicios similares a Redis enfrentan un riesgo legal y operativo importante.
  • Muchos esperan:
    • Que las distribuciones Linux (Debian, Fedora, etc.) eliminen Redis o lo muevan a repositorios no libres, como con MongoDB.
    • Que los usuarios instalen cada vez más mediante imágenes/contenedores del proveedor o cambien a forks/alternativas.
  • Algunos se preocupan por las actualizaciones de seguridad a largo plazo de las últimas versiones con licencia BSD y sus backports.

Confianza, gobernanza y reacciones de los colaboradores

  • Varios ven esto como un “bait-and-switch”:
    • Las garantías públicas anteriores de que el núcleo seguiría siendo BSD y de una gobernanza “liderada por la comunidad” se contraponen con un relicenciamiento repentino y la eliminación de la página de gobernanza.
    • La nueva CLA obligatoria permite a Redis relicenciar contribuciones futuras; algunos colaboradores dicen que dejarán de contribuir.
  • Otros argumentan:
    • BSD lo permitía explícitamente; los colaboradores debieron haber entendido el riesgo.
    • El proyecto siempre estuvo muy moldeado por la empresa que compró la marca.

Forks y alternativas

  • Se discuten múltiples forks y alternativas:
    • Fork BSD congelado en el commit anterior al cambio.
    • Un fork comunitario en curso (“redict”) en Codeberg.
    • Opciones compatibles como sustituto o con compatibilidad de protocolo: KeyDB (historial MIT/BSL), Dragonfly (BSL), Microsoft Garnet (MIT), Memcached, varios backends de protocolo Redis (por ejemplo, kvrocks).
  • Muchos esperan que un fork fuerte (respaldado por proveedores cloud y exdesarrolladores del núcleo) se convierta en el “Redis abierto” de facto, citando precedentes como MariaDB, OpenSearch y OpenTofu; otros señalan que no todos los forks triunfan.

Proveedores cloud y equidad

  • Un bando:
    • Ve SSPL/RSAL como una defensa justificada contra “mega-corp cloud leeches” que revenden Redis con poco o ningún apoyo financiero.
    • Sostiene que los negocios sostenibles de OSS necesitan capturar parte de los ingresos de hosting.
  • Otro bando:
    • Replica que las grandes nubes sí aportan código e ingenieros, y operan dentro de las libertades que BSD concedía.
    • Sostiene que el verdadero fracaso son los modelos respaldados por capital de riesgo de “vender soporte/hosting”, no el OSS en sí.

Filosofía de licencias y debate OSI

  • Hay un acuerdo general en que Redis ya no es open source según la definición de la OSI; es “source available”.
  • Disputas:
    • Algunos llaman a SSPL “copyleft más auténtico” y alineado con los objetivos del software libre (obligando a abrir servicios completos).
    • Otros dicen que SSPL impone obligaciones imposibles (por ejemplo, todo el “software de hosting”) y es una restricción de uso de facto.
  • El hilo destaca la confusión entre:
    • “Permisivo” vs “copyleft”.
    • “Open source” vs “source-available”.
    • “Free as in beer” vs “free as in freedom”.

Sostenibilidad de los negocios FOSS

  • Temas recurrentes:
    • El open core y los servicios alojados a menudo han fracasado ante la competencia cloud; el endurecimiento de licencias (Redis, HashiCorp, Elastic, MongoDB) se ve como un “rights ratchet”.
    • Las fundaciones no son una panacea, pero se citan (Postgres, Kubernetes, Linux) como administradores a largo plazo más estables que las empresas respaldadas por VC.
  • Alternativas sugeridas:
    • Usar AGPL desde el primer día.
    • Poner el núcleo bajo una fundación neutral; monetizar extensiones propietarias o capas SaaS.
    • Normalizar la financiación directa y los colaboradores internos de los grandes usuarios.
  • Las opiniones divergen sobre el futuro:
    • Algunos predicen una retirada de FOSS hacia software propietario/shareware.
    • Otros creen que este episodio fomentará forks más tempranos y elecciones de licencia más cuidadosas, en lugar de acabar con el open source a gran escala.