- Liquibase cambió de su licencia previa de código abierto a la Functional Source License (FSL)
- Aunque la FSL no es una licencia oficial de código abierto según los criterios de la Open Source Initiative (OSI), se cuestiona que en el README y otros lugares todavía se presente como un proyecto open source
- En la comunidad se han planteado posturas opuestas: una sostiene que la FSL viola los criterios formales de open source, mientras que otra afirma que la FSL sí cumple con los requisitos de código abierto
- Dentro del proyecto, ya se está trabajando en corregir las menciones a open source en el README
- También se señala que la FSL, por cláusulas como la restricción al uso competitivo, entra en conflicto con partes de la Open Source Definition de la OSI
Resumen del problema
- La licencia del proyecto Liquibase cambió recientemente a la Functional Source License (FSL)
- Sin embargo, en documentación oficial como
README.md todavía se presenta a Liquibase como un proyecto open source, lo que ha generado confusión y desacuerdos dentro de la comunidad
Reporte y controversia
- La persona que abrió el issue señala como problema que Liquibase siga indicando que es open source incluso después de haber migrado a la FSL
- El propio Liquibase ya había mencionado que la FSL no es una licencia open source
- Se pide corregir el README y otros documentos para que el término open source deje de usarse en la documentación del proyecto
Opiniones de la comunidad y personas relacionadas
- Algunos participantes sostienen que la FSL cumple con los criterios de una licencia open source aprobada por la OSI, y que no habría problema si, tras una revisión formal, la FSL llegara a obtener esa aprobación
- En cambio, otros participantes subrayan que, por cláusulas como la de “uso permitido” dentro de la FSL, se incumplen varios puntos de la Open Source Definition de la OSI (1, 3, 5 y 6)
- También hay quienes enfatizan la diferencia entre “Fair Source” y “open source real”, y opinan que la FSL debe clasificarse como Fair Source
Proceso de resolución y cambios en la documentación
- Una persona contribuidora del proyecto respondió al señalamiento modificando
README.md y eliminando gradualmente las referencias a open source
- Sin embargo, todavía quedan algunas expresiones como ‘open source’ y ‘oss’ en varias partes del repositorio, por lo que se prevé una revisión y limpieza adicionales
La definición de open source y el problema de la FSL (Functional Source License)
- Figuras destacadas del ecosistema open source, como Richard Fontana, han dejado claro que la FSL viola la Open Source Definition de la OSI por cláusulas como la prohibición del uso competitivo
- La definición de open source incluye disposiciones como la “no discriminación contra personas, grupos o áreas de actividad”, por lo que prohibiciones sobre usos competitivos entrarían en conflicto con ella
- La FSL está prevista para convertirse en MIT o Apache License después de 2 años, momento en el que pasaría a ser completamente open source, pero hasta entonces siguen existiendo condiciones restrictivas
Conclusión y situación actual
- Este issue ha impulsado el debate sobre la transparencia y sobre la naturaleza del open source en el contexto del ajuste de la forma en que Liquibase se describe
- Ya comenzó la corrección de documentos oficiales como el README, y la distinción entre Fair Source y open source se está discutiendo a partir de un caso concreto
- Independientemente de si la OSI la aprueba o no, las condiciones reales de la licencia tienen un peso importante dentro de la comunidad internacional de open source
1 comentarios
Opinión de Hacker News
Empecé a buscar alternativas por si ya no podemos seguir usando la versión 4.x
Entiendo que alguien quiera ganar dinero con software útil al pasar de una licencia OSS a un modelo de pago
Pero cambiar la licencia de un proyecto de código abierto me parece una especie de táctica de bait-and-switch
Este tipo de decisiones destruye la confianza de inmediato, y también hace que pierdan una base de usuarios que quizá no sea fácil de monetizar hoy, pero sí tenga potencial a largo plazo
Esperaba que ya hubieran aprendido lecciones importantes de los casos de Elastic y TerraForm
Siento que incluso Flyway pierde confiabilidad, porque podría tomar un camino parecido en cualquier momento
Si no aparece un fork, incluso estamos considerando crear directamente nuestra propia librería de migraciones adaptada a nuestro uso real
Usábamos Liquibase solo porque era conveniente, no porque fuera irremplazable
También creo que EventstoreDB (ahora KurrentDB) y NATS generan dudas en cuanto a la confiabilidad del servicio
EventstoreDB ya cambió su licencia, y NATS solo dio marcha atrás por la reacción de los usuarios
Da la impresión de que este tipo de movimientos ya se volvió una estrategia de negocio
La mayor ventaja del código abierto es que siempre puedes hacer fork de una versión anterior y seguir usándola
Me parece una transición que, en esencia, no es tan diferente de subir el precio de un producto
Aunque es solo para Postgres, también existe un proyecto llamado pgroll que lleva la automatización un paso más allá
Además de Flyway (licencia Apache), todavía hay licencias realmente abiertas de sobra, como Atlas (Apache) y Sqitch (MIT)
Me pregunto si el cambio de licencia de Elastic realmente fue un fracaso desde su punto de vista
La acción cayó por un tiempo, pero la empresa en sí sigue firme
Todos los desarrolladores de búsqueda y RAG que conozco siguen usando únicamente Elasticsearch ofrecido por Elastic NV (nada de forks open source ni alternativas)
Sobre todo si ves al segmento de clientes más importante para Elastic, es decir, los clientes de pago, parece que en vez de destruir confianza hasta les terminó beneficiando
De hecho, sus ingresos se duplicaron frente a 2020
Aunque todavía hay quienes dicen que sigue siendo open source, en Liquibase aclaran directamente que FSL no es una licencia open source
Ver anuncio oficial en el blog de Liquibase
Es una lástima que últimamente haya tantos proyectos que solo publican el código y se venden como si fueran open source
Si Liquibase eligió Apache en vez de un copyleft fuerte (por ejemplo GNU AGPL), entonces debió asumir desde el principio que otras empresas podían crear derivados cerrados
Al final fue una decisión de Liquibase, así que también la responsabilidad recae en Liquibase
Parece que tiene una estructura donde, después de cierto tiempo, cambia automáticamente a Apache
No estoy seguro de si eso es mejor o no
En realidad, las empresas pueden cumplir sus objetivos perfectamente incluso con licencias como AGPL
Redis también hizo la transición y la reacción de la comunidad fue positiva
No creo que los usuarios se molestaran si Liquibase adoptara un modelo de doble licencia con AGPL
Creo que habría que llamarlo "open source con retraso de 2 años" o "open source después de 2 años"
En la práctica, me parece más bien "open source cuando ya no sirve"
Siento que lo esencial de este modelo es proyectar una imagen de respeto por la libertad cuando en realidad no es así
Tampoco es tan común que una versión vieja se vuelva inútil tan rápido
No veo esto como una falta de respeto hacia mi libertad
La idea es imponer ciertas restricciones a empresas, no a personas
En el mundo enterprise, creo que lo esencial del open source no es tanto la "libertad" sino la confianza y la transparencia
Con solo publicar el código ya puedes aprovechar las ventajas del FOSS sin problemas legales o de monetización
En internet suele haber una confianza casi ciega y excesiva en el modelo open source
También me parece razonable una política mixta de 2 años, y si no quieres la nueva licencia siempre puedes usar una versión anterior
Código abierto diferido, como el inglés
late, con doble sentido#source-washing
Si no conocías esta nueva licencia, revisa este enlace con detalles sobre FSL
Más contexto sobre FSL: la creó Sentry, y en su blog explican por qué hacía falta esta licencia y qué problema intentaba resolver
Personalmente, la única licencia de código cerrado que me parece medianamente aceptable es la BuSL,
Business Source LicenseDespués de 4 años se convierte obligatoriamente en open source, y mientras tanto el código sigue siendo visible
Además evita la proliferación innecesaria de licencias
También puede servir como referencia la wiki de Business Source License
Me pregunto si 2 años no es un plazo demasiado corto
Desde la perspectiva de una empresa grande, software de hace 5 años todavía se usa sin problema, y a mí incluso Redis 2012 o Postgres 2020 me siguen pareciendo perfectamente válidos
Ya había recopilado el historial de este tipo de casos y una lista de empresas
Lo dejé en esta publicación del blog, así que si conocen más ejemplos, compártanlos
Las funciones Pro rompen una y otra vez la sintaxis de la versión community, así que no siento que haya transparencia alguna
Claro que el trabajo merece una compensación justa, pero eso de "éramos open source y de pronto dejamos de serlo" se está volviendo demasiado común
Estas transiciones siempre parecen hacerse en silencio, como esperando que nadie se dé cuenta
Tengo curiosidad por saber cuál sería el daño real o el problema principal
De hecho, me gusta la distinción entre usos competitivos y no competitivos
El tono de los comentarios me parece un poco raro
La mayoría ve "base" y recomienda servicios que no tienen nada que ver, o insiste en que si el código está publicado entonces ya es open source
No sabía que Liquibase había cambiado la licencia
En realidad casi todos los frameworks web tienen alternativas, y también hay opciones independientes del framework como Alembic y Flyway
A estas alturas se ve un poco extraño
Este tema también podría causar problemas en proyectos OSS como Keycloak
Según la política de la CNCF, no se pueden usar licencias que no sean open source, así que Keycloak no puede usar Liquibase
Como Debian, Fedora y otras también exigen licencias OSS, me pregunto si podrán incluir proyectos que dependan de Liquibase en ese tipo de distribuciones
Enlace al issue de Keycloak
Pero sí podría incluirse en repositorios individuales o personalizados, como rpm fusion non-free