- El proyecto Bear cambió de la licencia MIT a Elastic License
- La licencia MIT anterior permitía el uso libre del código y los forks, pero la nueva licencia restringe su oferta como servicio alojado
- Varios proyectos de código abierto también están adoptando cambios de licencia similares para evitar la competencia gratuita
- En la era de la inteligencia artificial, copiar código y convertirlo en servicio se ha vuelto muy fácil
- La apertura del código es importante, pero el núcleo de Bear está en la comunidad de usuarios y la voluntad de mantenerlo de forma sostenida
Contexto del cambio de licencia de código abierto público de Bear
- En sus inicios, el proyecto Bear publicó su código bajo la licencia MIT, con el objetivo de permitir el aprendizaje y la auditoría, además de ofrecer a los usuarios confianza en la privacidad y la seguridad
- Sin embargo, con el tiempo aparecieron casos de servicios competidores basados en el código del proyecto Bear
- Aunque el software fue desarrollado con cariño, surgieron sentimientos de pérdida y de riesgo económico al ver que el código se copiaba fácilmente y regresaba como competencia
- Aunque se creía en el valor del código abierto, la situación se volvió difícil en la práctica
Decisión de cambiar la licencia
- A raíz de un incidente reciente, se decidió cambiar la licencia de MIT a Elastic License (un enfoque de copyleft introducido por Elastic Search)
- Elastic License es similar a MIT, pero prohíbe ofrecer el software como servicio alojado o administrado
- Los términos específicos de la licencia pueden consultarse en este enlace de GitHub
Tendencias en el ecosistema de código abierto
- Según la investigación, muchos proyectos de código abierto han estado restringiendo sus licencias en los últimos años para impedir la “competencia de free riders”
- Ejemplos: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry y otros proyectos han tomado decisiones similares
La era de la inteligencia artificial y la intensificación de la competencia
- Con la llegada de las herramientas de programación con IA, ahora es posible hacer copias rápidas y convertirlas en servicio, como en “haz un fork de este repositorio, cámbiale el nombre y despliegalo en EC2”
- Este cambio en el entorno impone una mayor carga y riesgo para el autor original
El valor especial de Bear
- El verdadero valor de la plataforma Bear no está simplemente en el código fuente, sino en la comunidad que la usa y en el sentido de responsabilidad a largo plazo del operador
- Aunque en adelante pueda haber algunas restricciones a nivel de código, expresó su intención de seguir manteniendo la plataforma con dedicación
3 comentarios
Parece que GPLv3 y AGPL no se usan según la intención original de quienes crearon esas licencias.
Como la mayoría permite doble licenciamiento, al final he visto demasiados casos en los que se usan como un mecanismo para forzar el uso comercial.
En ese sentido, creo que Apache y MIT son de las pocas licencias de código abierto que funcionan según su intención inicial.
(Aunque tampoco creo que exista una licencia de código abierto completamente perfecta.)
Comentarios en Hacker News
Según entiendo, el bando de "Open Source" sostiene que, si Amazon no puede ofrecerlo como un servicio de AWS, entonces no es verdadero open source, y se molestan muchísimo si alguien dice lo contrario.
Ojalá más gente reconociera el fenómeno de la "competencia parasitaria" del que habla este autor. Lo que está haciendo Herman beneficia a todos, así que estaría bien tener un término nuevo, más cálido que "source-available" y que represente mejor lo que es un proyecto comunitario.
Lo agrego porque en los comentarios de abajo alguien resumió muy bien lo que pienso:
La estructura natural de concentración del mercado no ayuda a la misión del software libre y de código abierto (FOSS). Si no se impide que las grandes empresas obtengan ganancias de esta forma, en realidad se termina perjudicando gravemente la misión del open source. Y en ese proceso se empuja a los usuarios a una trampa que combina software privativo monopolístico de grandes corporaciones con FOSS
La postura original del movimiento open source era usar licencias como GPL → GPLv3 → AGPL, apoyando formas de bloquear claramente este tipo de problemas
El hecho de que se hayan extendido licencias permisivas como MIT/BSD/Apache parece parte de una corriente intencional, alineada con intereses corporativos, para debilitar la ideología del software libre
A la mayoría de la gente tampoco le molesta mucho el software que no es open source
El problema es que proyectos como Terraform ganaron popularidad y crecieron porque eran open source, y luego su responsable cambió a una licencia cerrada, eliminando la base de ese éxito original
Y cuando además los contribuidores firmaron un CLA (Contributor License Agreement) para que luego incluso su código pudiera relicenciarse de forma cerrada, resulta el doble de decepcionante
Si no te importa el open source, simplemente no lo uses; hasta ahora open source tenía un significado claro y consistente
Cada quien puede hacer software libremente y elegir usarlo según los valores en los que cree; no hace falta convertirlo en un problema
Cualquiera puede usar la licencia que quiera, pero vale la pena pensar por qué la mayoría de los desarrolladores open source eligen licencias permisivas como MIT
En la práctica hay mucho buen software open source en el mercado, así que hay muchas opciones; si pones restricciones de licencia, la gente simplemente elige otra alternativa
Por eso, con licencias tipo GPL es más difícil que un proyecto logre adopción masiva. Claro, hay excepciones como Linux o WordPress, que fueron muy exitosos, pero no es lo normal
Monetizar ya es difícil incluso con una licencia permisiva como MIT, pero si primero pierdes usuarios, es todavía peor
Se puede debatir si eso está bien o mal, pero en la práctica parece que todos están actuando racionalmente. En esencia, el software no es tan escaso
¿No se creó AGPL justamente para este tipo de caso?
AGPL es una licencia open source reconocida por la OSI que impone restricciones cuando el software se ofrece como servicio en red
Me pregunto si el mantenedor revisó Fair Source fair.io
Creo que Fair Source es mejor que "source-available", y además ofrece un camino para convertirse en open source completo bajo DOSP(opensource.org/dosp), así que beneficia tanto a usuarios gratuitos como de pago, y es un modelo ideal especialmente para una plataforma de blogs como Bear
La Fair Source License FCL(fcl.dev) también va bastante en la línea de la licencia de Bear Blog y encaja bien con el manifiesto de Bear(herman.bearblog.dev/manifesto/)
Incluso si Bear PTY LTD desapareciera, se podría crear una estructura en la que Bear como tal siguiera existiendo (algo que podría definirse mediante DOSP)
Yo participé también en la redacción de Fair Source
Aun así, el término "fair source" suena bastante bien
¿Se puede entender que software que se vuelve open source con el tiempo, como con Apache o MIT, entra en la categoría de fair source, o hay criterios más complejos?
Me parece que alguien fue moderadamente ingenuo. Si eliges la licencia MIT, cualquiera puede usar tu código como quiera. Y luego, cuando quieres ganar dinero, intentas resolverlo cambiando a una licencia extraña
Al final, las opciones son MIT/BSD, GPL, LGPL y AGPL; cualquier otra licencia solo crea problemas innecesarios de compatibilidad
También estoy de acuerdo con esa postura. Si de verdad te gusta publicar el código "sin condiciones", eliges MIT
En este caso, da la impresión de que no lo eligió claramente pensando así, sino que quería mantenerse en una zona ambigua entre "hacerse el bueno" y "hacerse el empresario"
También creo que MPL (Mozilla Public License) es una licencia bastante útil e injustamente subestimada
Es claramente menos contagiosa que las GPL, pero más restrictiva que MIT/BSD (las modificaciones deben publicarse al distribuirse)
MIT y BSD no garantizan derechos de patente, así que esa es una buena razón para irse por Apache License
Guy (el creador) parece simplemente haber hecho su propio proyecto y haberle dado valor a publicar el código fuente
No creo que hubiera una intención estratégica especial detrás
También es ingenuo el usuario que cree que un proyecto open source va a seguir siéndolo para siempre
Los autores tienen derecho a cambiar la licencia, y sorprenderse por eso, o creer que hacer negocio con open source sería fácil, son en ambos casos actitudes ingenuas
Si quieres bloquear por completo el uso competitivo, normalmente se hace así. Y también es correcto dejar de usar el término open source
Pero en la mayoría de los casos creo que AGPL es una mejor alternativa. Con AGPL, las grandes empresas muchas veces no pueden usar el código por sus políticas internas, lo que sirve para bloquear la entrada de operadores grandes
Va en contra del sentido original del open source
"Lo abrí con MIT, y ahora alguien está ganando dinero usando mi código en un negocio. Me sorprende que no hubiera previsto ese resultado"
¿Por qué esto sigue repitiéndose? Me pregunto por qué tantos desarrolladores no ven venir una consecuencia tan obvia
MIT era básicamente la opción por defecto de baja fricción que se seleccionaba del menú desplegable al crear un proyecto nuevo en GitHub
Cuando el proyecto apenas empieza y no sabes cómo va a evolucionar, es difícil imaginar que crecerá tanto como para que después tengas que preocuparte por la licencia
La licencia MIT originalmente permite que el proyecto se relicencie de nuevo en cualquier momento
El mantenedor de Bear eligió primero una licencia permisiva y luego, al cambiar la situación, pasó a una licencia más estricta
A mí me parece una decisión completamente razonable
Creo que es así porque hace 15~20 años el bando BSD ganó la guerra cultural del open source
Me pregunto cómo sería hoy el ecosistema si el bando de las licencias GNU hubiera ganado esa guerra
Yo apoyaba a Bear porque era open source, pero si ya no lo es, no tengo más razones para seguir apoyándolo, así que cancelé mi suscripción
Si esto volviera a AGPL, realmente sería deseable
Bear tiene libertad para usar la licencia que quiera, y yo puedo decidir si lo uso o no
El objetivo de una licencia open source es, en esencia, compartir, no obtener ganancias económicas
También entiendo perfectamente apoyar solo proyectos open source
Cuando llega el momento de generar ingresos, una licencia open source puede dejar de ser adecuada
Algunos desarrolladores malinterpretan el open source creyendo que protegerá sus ingresos, y algunos usuarios se equivocan pensando que el proyecto seguirá siendo open source para siempre
Modelos como source-available o shipped-with-source también son una forma de licencia privativa; no tienen por qué ser open source
“Los usuarios no pueden alojarlo como un servicio que proporcione las funciones principales del software ni ofrecerlo como servicio administrado”
No soy abogado, pero me pregunto si esta restricción también impide instalar y operar Bear directamente para uso interno en una empresa o para uso personal
De hecho, si eso tampoco se permite, no entiendo por qué alguna vez usó licencia MIT
Texto original de la licencia de Bear Blog
Lo que no puede hacer es ofrecerlo como servicio para otras personas o empresas
Referencia: Elastic License FAQ
Entiendo la sensación de decepción, pero la nueva licencia es algo ambigua
Cuando dice "no se puede ofrecer funcionalidad mediante hosting/servicio administrado", ¿eso también restringe a un proveedor de VPS común donde se instala con un gestor de paquetes?
Si hay scripts de configuración tipo 1-click install, ¿qué pasa entonces? Es ambiguo si basta con no guiar ese proceso dentro del servicio para que sea válido
Se siente como una especie de "teatro" donde un tercero puede dar el script de instalación y, mientras no lo menciones en la etapa del servicio, entonces todo vale
O sea, no puedes ofrecer el software a otras personas como servicio (gratis o de pago), pero sí puedes usarlo tú mismo
La clave es que debe entenderse que lo que está prohibido es proporcionar cuentas
También está prohibido ofrecer hosting llave en mano, pero el problema no es quien da el hosting, sino quien vende cuentas de usuario sobre esa instancia hospedada
Esa redacción busca impedir que grandes empresas como Amazon ofrezcan una instancia de base de datos al público y luego solo emitan cuentas encima de ella
En cambio, simplemente instalarlo en una VM con un gestor de paquetes está bien
Aun así, este tipo de licencias son muy confusas y poco claras
Si de verdad se quisiera mantener como open source y hacer que mucha gente lo use, pero sin querer que otros lo alojen, entonces ni siquiera haría falta compartir el código: bastaría con dejarlo en "All rights reserved"
Entiendo la motivación y la intención de publicar el código, pero si la preocupación era la competencia, me pregunto por qué no consideró AGPL en vez de MIT
¿Pero AGPL no permite igual que otra persona revenda comercialmente el código tal cual, sin modificarlo?
AGPL solo obliga a publicar el código fuente de las modificaciones
Aquí parece que el problema es más bien que alguien ofrezca Bearblog comercialmente casi sin cambios, o apenas cambiándole el nombre
Probablemente al principio no pensó que la competencia sería un problema, y después, a medida que sí lo fue, cambió la licencia
Personalmente, creo que este enfoque (código publicado + restricción de hosting, etc.) es el mejor modelo de licencia
Me permite revisar y modificar el código a mi gusto, mientras el proyecto y su mantenedor pueden proteger su base sin cargar con una presión competitiva excesiva
Si se empieza así desde el principio, también se evita que después haya un cambio repentino que genere polémica, o que un fork termine superando al original
Aunque tampoco creo que Bear fuera el tipo de proyecto que fuera a causar tanto impacto
Yo también uso a veces mataroa.blog, y espero que el mantenedor de Bear siga sintiéndose realizado con su proyecto
En realidad, los proyectos open source dependen casi únicamente del interés y las contribuciones de los usuarios como recurso.
Si todavía no están completamente consolidados, cualquiera —en especial una gran empresa— puede hacer un fork y acaparar toda la atención, y al final uno termina haciendo el trabajo para beneficio ajeno.
Desde el principio, estas licencias fueron pensadas para la libertad de los usuarios, no para los desarrolladores.
¿Sabían que
winget, el gestor de paquetes CLI de Windows, salió porque Microsoft hizo un fork tal cual del proyecto de otra persona y solo le cambió el nombre?También hay un texto escrito por el autor del proyecto original,
appget.The Day AppGet Died.
Si no quieren simplemente trabajar para beneficio ajeno (especialmente en favor de grandes empresas o de gente muy buena para viralizar cosas) y valoran su propio tiempo, vale la pena reconsiderar adoptar una licencia open source.
Incluso si ambas cosas son trabajo voluntario, hay una gran diferencia entre recibir respeto por tus contribuciones y ser completamente ignorado.
Revisen alternativas como las que mencionaron en los comentarios de Hacker News.