El conflicto entre AWS y Elastic en torno a Elasticsearch
(blog.opsnow.com)Tras ver recientemente artículos sobre el abandono del código abierto por parte de Elasticsearch, la declaración de SSPL y la decisión de AWS de hacer un fork por separado para mantener una comunidad de código abierto bajo la licencia Apache License 2.0, hice un resumen del conflicto que se ha venido desarrollando entre ambas partes desde hace tiempo.
Si encuentran partes incompletas o incorrectas aquí y allá, dejen comentarios y se reflejarán.
10 comentarios
Personalmente, no entiendo bien por qué la OSI canceló el registro de la SSPL como licencia de código abierto. Entiendo que es una licencia que concreta un poco más la AGPL, y que exige a los proveedores de SaaS publicar todo el código, pero no termino de entender por qué la OSI interpreta eso como una "restricción" al SaaS.
Incluso viendo el comunicado de la OSI 1, se enfoca en cuestionar la intención de Elastic al adoptar la SSPL, pero no explica qué cláusula de la SSPL estaría "restringiendo" su uso. Leyendo el contenido, no me queda claro si realmente impone más "restricciones" que la AGPL. Tal vez soy yo quien está interpretando mal la licencia...
Quien retiró la licencia fue MongoDB. No fue que la OSI la rechazara. Claro, en la OSI también hubo reacciones de que, por los puntos controvertidos, era difícil reconocerla como open source, pero MongoDB detectó esa situación de antemano y terminó retirando la solicitud.
Gracias por la corrección. Mi redacción fue un poco imprecisa. Aun así, sí es cierto que MongoDB fue el primero en retirarla, pero incluso viendo la publicación de la OSI que aparece en el enlace, la OSI deja claro que no tiene intención de aceptar la versión actual de la SSPL... así que no parece que el orden de los hechos sea tan importante.
Estoy de acuerdo. ^^
Yo también tenía algunas dudas y estaba buscando sobre el tema; dejo este enlace porque encontré este material.
https://ceart.kr/component/file/…
Extracto
Primero, la diferencia entre la SSPL y la AGPL es la siguiente. La AGPL anterior, al igual que la GPL, exigía que incluso cuando un software no se distribuía y se ejecutaba del lado del servidor, el proveedor del servicio debía publicar todo el código fuente correspondiente a las modificaciones y añadidos realizados sobre ese software; sin embargo, esto se limitaba al propio servidor.
En cambio, la SSPL establece como condición que se publique no solo ese código, sino también el código de todo el software que un usuario de As-a-Service ejecuta para ofrecerlo en esa modalidad, como software de administración, interfaz de usuario, API, software de automatización, software de monitoreo, software de respaldo y almacenamiento, entre otros. Es decir, cuando los proveedores de nube ofrecen MongoDB como servicio, la condición es que también deben publicar todo el código fuente de cualquier software que hayan creado para mantener la ventaja competitiva de su servicio.
También había pensado investigar sobre MongoDB y Redis... ¡pero aquí ya estaba bien explicado!
Además, si revisan el PDF, también se explica qué partes no cumplen con la OSI. Al parecer, se trata de restricciones a la libertad y limitaciones sobre obras separadas.
Oh... en general es un PDF excelentemente bien escrito. Gracias por el enlace.
Visto así, puedo entender la diferencia con AGPL y la razón por la que no se permite SSPL, pero también me hace pensar que quizá la OSI está algo inclinada hacia lo permisivo.
La historia completa está muy bien organizada, así que fue una lectura muy cómoda. ¡Gracias!
Ver también
https://es.news.hada.io/topic?id=3620 - AWS anuncia un fork de código abierto de Elasticsearch y Kibana
https://es.news.hada.io/topic?id=3606 - Elastic cambia la licencia para impedir que AWS lo use