- Redis deja de distribuirse bajo BSD 3-Clause a partir de Redis 7.4 y, en adelante, ofrecerá Redis bajo RSALv2 o SSPLv1, cambiando de forma importante los límites de su licencia
- El código fuente seguirá disponible gratis como Redis Community Edition, pero las nuevas licencias no califican como open source según la definición de la OSI
- Redis planea integrar Core y Stack para agrupar búsqueda, JSON, vectores, estructuras de datos probabilísticas y modelos de datos de series temporales en un solo paquete gratuito
- Los usos internos o personales, las bibliotecas cliente, los socios de integración y los clientes actuales de Redis Enterprise no se verán afectados, pero los servicios administrados competitivos no podrán usar gratis el nuevo código fuente de Redis
- A partir de Redis 8, las funciones de Redis Stack se incluirán en Redis mismo, y después avanzará el fin de vida de las compilaciones separadas de Redis Stack
Alcance del cambio de licencia de Redis
- Todas las futuras versiones de Redis se distribuirán bajo una licencia de código fuente disponible
- Desde Redis 7.4, el software Redis Core podrá usarse bajo Redis Source Available License v2 o Server Side Public License v1
- Ya no se distribuirá bajo la licencia BSD 3-Clause
- El código fuente de Redis seguirá disponible gratis como Redis Community Edition a través del repositorio de Redis en GitHub
- Tanto RSALv2 como SSPLv1 no son licencias aprobadas por la OSI y cada una tiene restricciones de uso
Integración de Redis Stack y cambios en la oferta de productos
- Las futuras versiones con licencia de código fuente disponible integrarán Redis Core y Redis Stack
- La integración incluirá búsqueda, JSON, vectores, estructuras de datos probabilísticas y modelos de datos de series temporales
- Se ofrecerá como un solo paquete gratuito de descarga, y Redis podrá usarse como:
- almacén clave/valor de alto rendimiento
- almacén de documentos
- motor de consultas
- base de datos vectorial de baja latencia para aplicaciones de IA generativa
- A partir de Redis 8, se planea incluir por defecto los nuevos tipos de datos y motores de procesamiento que en el actual Redis Stack se ofrecían bajo RSALv2 o SSPLv1
- Después de la llegada de Redis 8, ya no serán necesarias compilaciones separadas de Redis Stack y avanzará el fin de vida de Redis Stack
Motivos del cambio y postura de Redis
- Redis afirma que ya venía aplicando licenciamiento dual a módulos avanzados de Redis en la distribución Redis Stack, y que desde Redis 6 más del 50% de las descargas desde redis.io correspondieron a Redis Stack
- Considera que mantener varias distribuciones al mismo tiempo entra en conflicto con su impulso de desarrollo futuro:
- distribución open source
- distribución con código fuente disponible
- software comercial optimizado para entornos on-premise y plataformas en la nube
- Redis considera que los principales proveedores de servicios en la nube comercializan las inversiones de Redis y la comunidad open source
- Este cambio busca gestionar el uso comercial para seguir invirtiendo en software gratuito con muchas funciones y en productos empresariales
- Con este cambio, Redis ya no es open source según la definición de la OSI
Impacto para usuarios y socios
- Los usuarios finales que usen versiones open source existentes de Redis o las nuevas versiones con licencia dual para uso interno o personal no se verán afectados
- Tampoco hay cambios para los socios que crean bibliotecas cliente u otras integraciones con Redis
- Todas las bibliotecas cliente de Redis mantenidas por Redis seguirán bajo licencias open source
- Los clientes actuales de Redis Enterprise no se verán afectados, ya que reciben la tecnología bajo condiciones de licencia negociadas por separado
- Los socios de integración y servicios administrados que utilicen Redis Community Edition o Enterprise de forma no competitiva podrán seguir construyendo, operando y ofreciendo soluciones mediante su asociación con Redis
- El Partner Program ofrecerá acceso exclusivo a futuras tecnologías, funciones y versiones de Redis
Restricciones para servicios en la nube y productos competitivos
- Bajo las nuevas licencias, los proveedores de servicios en la nube que ofrezcan Redis como servicio hospedado no podrán usar gratis el código fuente de Redis
- Por ejemplo, un proveedor de servicios en la nube solo podrá ofrecer Redis 7.4 después de acordar condiciones de licencia con Redis, mantenedor del código
- Una “oferta competitiva” según Redis significa un producto derivado del codebase de Redis, con una superposición importante con las funciones de los productos comerciales de Redis y vendido a terceros
- también incluye ventas mediante contratos de soporte pagado
- un ejemplo es hospedar o integrar Redis dentro de soluciones vendidas en competencia con Redis Enterprise Software o Redis Cloud
- No habrá impacto para soluciones que usen Redis pero no compitan específicamente con Redis mismo
- Las consultas sobre casos de uso específicos pueden dirigirse a redis_licensing@redis.com
Condiciones de RSALv2 y SSPLv1
- RSALv2 es una licencia permisiva de carácter no copyleft que permite usar, copiar, distribuir, poner a disposición y preparar obras derivadas del software
- RSALv2 tiene dos restricciones principales:
- no se puede comercializar el software ni ofrecerlo como servicio administrado a otras personas
- no se pueden eliminar ni ocultar la licencia, el copyright ni otros avisos
- SSPLv1 se basa en AGPL y exige publicar bajo SSPL el código fuente de todo el servicio cuando se ofrece como servicio
- esto incluye software de administración, interfaces de usuario, API, software de automatización, monitoreo, respaldo, almacenamiento y hosting
- MongoDB es el emisor de esta licencia
- Las versiones modificadas de software licenciado bajo SSPL no pueden redistribuirse bajo otra licencia
- Si en el esquema dual se elige RSALv2, se permite modificar y redistribuir dentro de los límites de RSALv2, como no ofrecer la funcionalidad como servicio a terceros
Versiones BSD existentes y parches de seguridad
- El cambio de licencia no se aplica retroactivamente
- Todo el código fuente y los lanzamientos anteriores al cambio permanecen bajo la licencia BSD 3-Clause
- Los usuarios podrán seguir usando indefinidamente las versiones BSD existentes, siempre que cumplan con los términos de esa licencia
- Redis planea seguir proporcionando actualizaciones de seguridad y correcciones de fallas críticas para esas versiones conforme a su política de seguridad, mientras Redis Community Edition siga disponible
- Los backports de parches de seguridad críticos para las versiones existentes bajo BSD 3-Clause estarán disponibles hasta antes del lanzamiento de Redis Community Edition 9.0; después de eso, los parches se ofrecerán bajo la nueva licencia dual
Nombre, contribuciones y condiciones de mezcla de código
- Redis 7.2 y versiones anteriores seguirán llamándose Redis OSS
- Desde Redis 7.4, la versión pública y gratuita se llamará Redis Community Edition
- Ya no se podrá usar “Redis” ni “for Redis” en nombres de productos, pero sí podrá indicarse en la descripción del producto que es compatible con Redis o que está basado en legacy-Redis
- Se seguirán aceptando contribuciones de la comunidad, pero para revisar contribuciones será necesario aceptar el Contributor License Agreement
- El código bajo RSALv2 o SSPLv1 y el código bajo otras licencias podrán usarse juntos siempre que cada componente mantenga su propia licencia y no se mezcle con código de copyleft fuerte como GPL
- Se permite hospedar Redis como servicio dentro de una organización, y una organización incluye afiliadas y subsidiarias
1 comentarios
Opiniones de Hacker News
Esto probablemente termine perjudicando a Redis Labs, igual que Hashicorp parece estar perdiendo terreno y buscando comprador, y tampoco creo que impida que otros intenten copiar a Redis Labs.
Los verdaderos perjudicados son las startups pequeñas que quieren usar la caché de Redis sin dolores de cabeza legales. AWS puede hacer un fork de Redis y, si además publica ese fork con una licencia permisiva, Redis Labs podría convertirse en una opción peor desde el punto de vista de licenciamiento.
Es una decisión difícil, pero creo que es mejor mantener el código propietario o apegarse a Apache o MIT. Cambiar la licencia a mitad del camino es pésimo y parece destinado a salir contraproducente.
El open source consiste en permitir que los usuarios sean dueños del software. Si intentas esquivar eso con trucos legales para ganar dinero, quienes salen lastimados no son los equipos de las grandes empresas, sino los usuarios. Redis siempre fue un proyecto open source permisivo, y justamente por eso tuvo éxito. Si cambias esas condiciones, también cambia el cálculo a futuro, y eso presagia malos resultados para todos los involucrados.
Hay que ver con más claridad la diferencia entre el software propiedad de una fundación, como PostgreSQL, y el open source propiedad de una empresa. Cuando el foco está en “maximizar el valor para los accionistas”, el objetivo de proteger la libertad de los usuarios inevitablemente termina quedando relegado.
Para la comunidad de Redis, habría sido mucho mejor que Antirez separara la relación laboral de la propiedad del proyecto y la dejara en manos de una organización sin fines de lucro. Algo como Apache Redis habría sido mejor para la comunidad, y Redis Labs también podría haber construido a su alrededor extensiones propietarias y un negocio en la nube.
Hemos visto una y otra vez que, cuando una empresa publica su software principal con una licencia permisiva, aparece un competidor más grande y vende una solución que redistribuye ese software.
Si el objetivo central de la empresa es el lucro, eso es una amenaza existencial. En cambio, si el objetivo de la empresa es actuar como administradora sin fines de lucro para que el software siga existiendo, entonces es un gran éxito.
Esta lógica no aplica al software auxiliar que no es el producto principal; por ejemplo, herramientas útiles creadas durante el desarrollo pero que no son aquello que se vende directamente para generar ingresos.
Este cambio de licencia apunta justamente a ese problema: evitar que los hiperescaladores de la nube se suban gratis.
A mí me suena como una AGPL mejor. No me interesan los matices filosóficos ni la lista de aprobaciones de la OSI; al final, es mucho menos restrictiva que la AGPL. Hay código fuente, se puede ejecutar localmente, y puedo usarlo de la misma manera en mis proyectos, en proyectos comerciales, en el trabajo, en bare metal, VM, Docker, k8s y Azure.
Que Microsoft tenga que compartir una parte del premium que ya está cobrando no tiene nada que ver conmigo. Más bien, encontrar un modelo de negocio sostenible merece aplausos.
Los desarrolladores de OSS conservan los derechos de autor. Salvo en el dominio público, solo el autor puede cambiar la licencia y las condiciones. Los usuarios reciben una licencia para hacer varias cosas con el software y el código; no obtienen la propiedad.
Totalmente de acuerdo, y se siente como otro caso que se suma al argumento de Cory Doctorow.
Para estas alturas probablemente ya haya un fork en marcha. Es un poco triste ver a una empresa aislarse por voluntad propia de su comunidad de desarrolladores.
Entiendo por qué lo hacen, pero no creo que funcione a largo plazo.
La mayoría de los usuarios de Redis nunca le pagó ni un centavo a la empresa detrás, y yo tampoco. Entiendo que hagan esto para ganar dinero, pero mi comportamiento no va a cambiar. Simplemente usaré un fork. Lo mismo hará la gran mayoría de los usuarios de Redis, los contribuidores externos y todos los proveedores cloud que ofrecían Redis comercialmente; con el tiempo, incluso una buena cantidad de los empleados actuales de Redis podría pasarse a ese lado.
Como hay muchos usuarios comerciales y proveedores cloud, no creo que tarden mucho en organizarse. De hecho, dado que ya hay muchos usuarios que pagan, prácticamente no les queda otra.
Ya existen precedentes parecidos con Terraform, Elasticsearch, Red Hat, etc. Hacer que una parte importante de tus usuarios objetivo y clientes potenciales dependa de un fork open source parece una mala dirección como estrategia de negocio.
Cuando Oracle se quedó con los proyectos open source de Sun, como mysql, hudson y openoffice, también perdió rápidamente la mayor parte del control. Sus intentos de convencer a la gente de usar los productos cerrados de Oracle no dieron muchos frutos. Incluso con Java terminaron retrocediendo en cierta medida, y hoy el centro es openjdk. Salvo algunos bancos, casi nadie usa Oracle JDK. No hace falta, y Oracle hace mucho dejó de fingir que tuviera ventajas. Todo el desarrollo ocurre en OpenJDK, y hay varias empresas que ofrecen builds certificados.
Personalmente hago consultoría en Elasticsearch y Opensearch, y la mayoría de mis clientes recientes toman Opensearch como opción predeterminada. Simplemente las cosas van por ahí. Todos eligen la alternativa gratuita y open source.
La conclusión es una sola: se creará un fork de Redis que terminará usando la gran mayoría de los usuarios actuales de Redis.
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
Desde el punto de vista de una empresa, puede aceptar aumentos de precio para no migrar por completo, o mientras migra en el corto plazo.
Para evitar una salida en el corto plazo, el proveedor también podría “comprar tiempo” manteniendo precios bajos y luego subirlos cuando el proyecto ya se haya diferenciado lo suficiente del fork como para que migrar sea mucho más difícil.
En cualquier caso, a largo plazo podría ganar mucho dinero con unas pocas empresas, en vez de seguir dando soporte a muchas compañías de distintos tamaños. No me gusta, pero parece que podría funcionar.
Con solo fragmentar la comunidad de MySQL, desalentar el uso y el desarrollo externo, y ralentizar todo el proyecto, quizá ya obtuvo un buen retorno de inversión.
El gran motor de estos proyectos sigue siendo el ingreso por hosting, y por eso ocurren los cambios de licencia.
Mirando la tendencia, parece que el open source que le conviene a la empresa dueña del proyecto son solo las bibliotecas. Si es un programa, por ejemplo software de servidor como una base de datos, entonces debería ser de código disponible o estar bajo una fundación. Es difícil y no sé cuál es la respuesta.
Me gustaría ver un modelo que haga volver las licencias open source permisivas también para programas complejos, pero todavía no veo una forma viable. Quizá sea una combinación de hacer valer la marca registrada, código open source y ofrecer solo builds licenciados.
En cualquier caso, seguiremos viendo el ascenso y caída del software open source popular, o cambios de licencia. Las ventajas para desarrolladores y empresas de empezar como open source son demasiado grandes, y la presión para cambiar después también es demasiado grande.
Como mínimo, quiero reconocer que el valor que Redis le dio al mundo fue mucho mayor que el valor que capturó. La diferencia es realmente abrumadora.
Será interesante ver qué tan rápido aparece y tiene éxito el fork, y cómo será la curva de crecimiento de ingresos de la empresa Redis dentro de 5 años.
No conozco bien las licencias, pero empatizo mucho con la situación en la que empresas pequeñas y medianas que crearon la tecnología base son comoditizadas por gigantes cloud oligopólicos y revendidas a precios altos. Más bien me sorprende que haya tardado tanto.
Si asumimos que tanto las empresas como el open source quieren un ecosistema sano, me pregunto qué alternativas habría además de cambiar la licencia.
Hay muchos casos en los que una sola empresa decidió salirse de facto mediante un “fork” fuera de la fundación, y la comunidad terminó enfrentando el mismo resultado.
https://spdx.org/licenses/AGPL-3.0-or-later.html
Quienes crean herramientas de trabajo también tienen cuentas que pagar.
En cierto sentido, los propios desarrolladores también tienen responsabilidad en el fracaso del sueño FOSS.
Lentamente estamos volviendo a los tiempos del dominio público y el shareware.
La gente siempre decía que el modelo para ganar dinero con el open source eran los servicios de soporte. Por ejemplo, si una empresa usa Postgres, un experto la ayuda con una configuración on-premises y le resuelve incidentes.
Pero en la era de la “nube”, las empresas simplemente usan servicios administrados ofrecidos por Amazon, Microsoft, Google, etc., y las oportunidades financieras para los mantenedores del proyecto y la gente a su alrededor prácticamente desaparecen. Nadie quiere matarse trabajando en OSS para luego ver a AWS ganar millones de dólares sin devolver nada.
Madelyn Olson, estando empleada por AWS, hizo durante años el trabajo duro, se ganó la confianza de otros desarrolladores core de Redis y se convirtió en mantenedora principal. Ella y otros desarrolladores de AWS contribuyeron mucho al motor core de Redis. También se puede decir que trabajaron duro por la comunidad de Redis.
Se puede leer más sobre esas contribuciones aquí: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
Más proyectos open source deberían adoptar SSPL o experimentar con enfoques como el de Llama 2, que pone límites al tamaño de las empresas que pueden usarlo gratis. Por ejemplo, que sea open source, pero no para hiperescaladores cloud de miles de millones de dólares.
Cuando los desarrolladores individuales contribuyeron, no lo hicieron para habilitar el free riding de AWS.
La principal razón por la que los proyectos se están moviendo hacia licencias más restrictivas es AWS. Lo correcto que AWS debió haber hecho era respetar el trabajo de los autores o empresas originales y fortalecer los productos respaldados por los desarrolladores originales. En cambio, cuando AWS ve que un producto OSS tiene éxito, crea un producto competidor. Por sus integraciones más estrechas y su fuerza de marketing, los proveedores externos no tienen oportunidad.
Además, Amazon y AWS son grandes beneficiarios del open source, quizá los mayores, y aun así devuelven muy poco. Google, Microsoft e incluso Oracle contribuyen más al open source que Amazon.
Nunca he contribuido a proyectos con CLA, y no pienso hacerlo en el futuro a menos que mi empleador me pague por ello.
Pero para la viabilidad de FOSS a largo plazo, quizá necesitemos restricciones para protegernos de las grandes empresas que en la práctica explotan a los desarrolladores FOSS.
Redis, Mongo, ES, la familia de productos de HashiCorp y todo el ecosistema de big data se dieron a conocer más ampliamente gracias a las ofertas de AWS. También hay muchas bases de datos poco conocidas, desarrolladas durante años, que la gente todavía no conoce porque AWS u otros grandes proveedores cloud no las impulsaron.
Además, gracias a las licencias libres, al aumentar el uso y la popularidad, muchos proyectos reciben contribuciones como reportes de bugs, PRs y parches. No me dan muchas ganas de contribuir a cosas con licencias tipo SSPL o BSL, porque no quiero desperdiciar tiempo en algo que después no podré usar libremente.
Si Redis hubiera salido con restricciones similares a Llama 2, habría fracasado desde el inicio. Sus principales consumidores son empresas, y la razón principal por la que Llama 2 se volvió popular fue que ofreció temprano un LLM de alta calidad que las personas podían usar para fines personales.
Un almacén clave-valor compatible con RESP no es algo particularmente extraordinario. Microsoft acaba de lanzar garnet, su propia implementación, bajo licencia MIT. El valor de Redis siempre fue ser gratis y open source, y la comunidad que lo sostuvo. Ahora se está abandonando la principal razón para usar Redis.
Pero, que yo sepa, ese es prácticamente el único caso; en casi todos los demás, como MongoDB, Redis, Memcached, MySQL, PgSQL, etc., no es así.
Redis Inc. está moviendo el proyecto https://github.com/redis/redis/ de la licencia BSD de 3 cláusulas a una licencia dual con dos licencias no aprobadas por la OSI.
Antes había dicho que “Redis core license está licenciada bajo 3-Clause-BSD y siempre lo estará”. (https://redis.com/blog/redis-labs-modules-license-changes/)
Si te preocupa el fin del soporte, Redis 7.4 será el primer lanzamiento bajo la nueva licencia y 7.2 será el último bajo la licencia anterior.
Redis da soporte a dos lanzamientos adicionales en un momento dado: latest major.(minor-1), (major-1).(last-minor)
A grandes rasgos, eso significa que cuando salga 8.0 terminará el soporte de 6.2, y cuando salga 7.6 u 8.0 terminará el soporte de 7.2.
Viendo los lanzamientos anteriores, se espera que 8.0 salga alrededor de marzo a mayo de 2025. Por lo tanto, si dependes de Redis bajo la licencia 3BSD, deberías planificar en consecuencia.
Ubuntu empaqueta redis en el repositorio
universe, por lo que las actualizaciones de seguridad solo se ofrecen a clientes de Ubuntu Pro. Por lo tanto, en Ubuntu 20.04 las actualizaciones de redis se detendrán en abril de 2024, excepto para usuarios de ESM de Ubuntu Pro.Debian 11/12 sigue Redis 6.0/7.0, por lo que tiene la responsabilidad de hacer backport de los parches de 7.2. No está claro qué pasará si 7.2 deja de recibir actualizaciones de seguridad y estas solo se ofrecen en la rama 7.4.
Aunque tu forma de uso directo sea compatible con la nueva licencia, podrías verte afectado indirectamente. Como es probable que las distribuciones excluyan redis de sus repositorios oficiales en el próximo lanzamiento, habrá que tenerlo en cuenta en el siguiente ciclo de actualización de la distribución.
(Mantengo https://endoflife.date/redis, así que si alguien sabe con claridad qué impacto habrá en el fin de soporte y el soporte, puedo fusionar un PR.)
Es muy probable que la nueva licencia, SSPL, no sea open source al menos por su restricción de campo de uso: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
https://opensource.org/definition-annotated#6
Este es precisamente el núcleo del open source y, en cierto sentido, del software libre. Las licencias copyleft tienen restricciones, pero si cumples esas restricciones puedes hacer lo que quieras con el software. Las licencias SSPL, FSL y BUSL bloquean por completo ciertos tipos de competencia comercial.
Que la mayoría de los modelos de negocio no quieran cumplir con el copyleft no significa que no sea open source. Simplemente no encaja con ese modelo de negocio.
Nuevas licencias como SSPL, BSL y FSL están ganando cada vez más popularidad, y por buenos motivos. Hace 20 años no existía una situación en la que AWS revendiera FOSS al mundo entero, así que las condiciones eran muy distintas a las de ahora.
Por sus restricciones no son “open source”, pero el término más cercano, “source-available”, tampoco refleja bien la realidad. Suena más a que el código fuente técnicamente existe en algún lado.
ElasticSearch, Sentry y otros siguen desarrollándose públicamente; personas ajenas al proyecto pueden enviar PR, y cualquiera puede hacer lo que quiera siempre que no esté intentando competir públicamente con la empresa detrás del proyecto.
Al mismo tiempo, Microsoft publicó Garnet: https://github.com/microsoft/garnet
Buen timing.
Su lógica era que MS pondría el anzuelo y luego cambiaría la licencia cuando lo necesitara, por lo que Redis, que siempre mantendría una licencia open source, era una mejor opción. Tremenda predicción.
Los fundadores técnicos de Redis y Hashicorp, cada uno por su lado, se retiraron antes de que sus empresas se alejaran del FOSS y enfrentaran una gran tormenta. Eso suponiendo que las fechas no estén mal.
Me pregunto si sabían esto de antemano y se oponían, o si lo sabían pero querían evitar el golpe reputacional. Estés de acuerdo o no con este movimiento, hay daño reputacional. O quizá el cambio pudo impulsarse precisamente porque ellos se fueron.
Es pura especulación, pero llama la atención que parece repetirse en Redis lo que vimos en Hashi.
A mí tampoco se me escapó la similitud con Hashi.