HashiCorp adopta la Business Source License
(hashicorp.com)- HashiCorp cambiará la licencia del código fuente de los futuros lanzamientos de sus productos de MPL 2.0 a Business Source License v1.1 para seguir invirtiendo en la comunidad y en sus productos
- Considera que el modelo previo de código abierto creó un gran ecosistema, pero que también creció el problema de algunos vendors que aprovechan comercialmente el trabajo de la comunidad sin hacer contribuciones sustanciales
- La BSL 1.1 es una licencia de código fuente disponible que permite copiar, modificar, redistribuir y usar con fines no comerciales, así como cierto uso comercial bajo condiciones; la API, los SDK y la mayoría de las bibliotecas seguirán bajo MPL 2.0
- Los usuarios finales, socios, clientes empresariales y clientes de productos administrados en la nube podrán en general seguir usando todo como hasta ahora, excepto para ofrecer productos que compitan con HashiCorp
- A los vendors que ofrezcan servicios competidores sobre productos comunitarios de HashiCorp les resultará más difícil integrar futuros lanzamientos, correcciones de errores y parches de seguridad
Alcance del cambio de licencia
- La licencia del código fuente de todos los futuros lanzamientos de productos de HashiCorp cambiará de Mozilla Public License v2.0 (MPL 2.0) a Business Source License (BSL o BUSL) v1.1
- La API de HashiCorp, los SDK y casi todas las demás bibliotecas mantendrán MPL 2.0
- El código fuente del producto y sus actualizaciones seguirán publicándose en los repositorios de GitHub y canales de distribución de HashiCorp
- HashiCorp busca una forma de compartir ampliamente su código fuente y permitir su uso gratuito, minimizando al mismo tiempo el impacto para la comunidad, los socios y los clientes
El modelo open source y la carga de la comercialización
- Cuando HashiCorp se fundó, publicó sus productos como open source por tres razones
- Los profesionales debían poder descargar y revisar libremente el código fuente, y resolver problemas por sí mismos
- Era necesario crear un ecosistema y una comunidad alrededor del producto para permitir integraciones amplias
- La transparencia era importante para los usuarios
- Durante más de 10 años ofreció nuevos productos y funciones bajo licencias open source gratuitas, formando una gran comunidad de usuarios, contribuidores, socios y clientes
- Invierte decenas de millones de dólares al año en investigación y desarrollo de productos open source, y este modelo ha sido posible gracias a clientes comerciales que trabajan con HashiCorp en infraestructura de misión crítica
- Ha colaborado estrechamente con proveedores de nube para ofrecer integraciones a usuarios y clientes conjuntos, y también ha trabajado con cientos de socios tecnológicos
Cómo se aplicará la BSL 1.1
- BSL 1.1 es una licencia de código fuente disponible que permite copiar, modificar, redistribuir, usar con fines no comerciales y ciertos usos comerciales bajo condiciones específicas
- En los últimos años, Couchbase, Cockroach Labs, Sentry y MariaDB también han seguido un camino similar; MariaDB desarrolló esta licencia en 2013
- También se mencionan casos como Confluent, MongoDB, Elastic y Redis Labs, que adoptaron licencias alternativas con restricciones al uso comercial
- La implementación de la BSL por parte de HashiCorp incluye permisos de uso adicionales que permiten un uso amplio y permisivo del código fuente
- Durante el desarrollo de la licencia, buscó asesoría de expertos en licencias OSS y de actores de la industria para alinearse con las prácticas del sector
Impacto en usuarios, socios y clientes
- Los usuarios finales podrán seguir copiando, modificando y redistribuyendo el código para todos los usos no comerciales y comerciales, excepto cuando se trate de ofrecer productos que compitan con HashiCorp
- Los socios podrán seguir construyendo integraciones para clientes en común
- Planea seguir colaborando estrechamente con proveedores de servicios en la nube para mantener un soporte profundo sobre tecnologías compartidas
- No hay cambios para clientes empresariales ni para clientes de productos administrados en la nube de HashiCorp
- Los vendors que ofrezcan servicios que compitan con HashiCorp basados en productos comunitarios ya no podrán integrar en sus productos futuros lanzamientos, correcciones de errores y parches de seguridad de HashiCorp
Información adicional
- HashiCorp afirma que su compromiso con la comunidad, los socios y los clientes no ha cambiado
- Para preguntas adicionales, ofrece frequently asked questions
1 comentarios
Opiniones de Hacker News
La única conclusión que saco de esto es que HashiCorp ya no es una empresa de open source
Que existan “proveedores que usan el modelo OSS puro y el trabajo de la comunidad para objetivos comerciales sin devolver aportes reales” es 100% coherente con el espíritu del open source
Si eso es un problema, entonces adopten una licencia open source que obligue a los desarrolladores a publicar el código, como AGPL
Esto no es más que una forma de que HashiCorp pueda comercializar en exclusiva sus antiguos proyectos open source, y eso en sí está bien, pero entonces deberían pasarse directamente al código cerrado y reconocerlo, no intentar quedarse con ambos lados
La publicación del blog no es honesta. Intentamos varias veces contribuir correcciones upstream a proveedores de Terraform, pero HashiCorp nunca las aceptó, así que tuvimos que mantener forks
HashiCorp perdió su ADN OSS hace mucho tiempo, y esta medida es el último clavo en el ataúd
Por suerte, con el tiempo delegaron gran parte de la responsabilidad de la mayoría de los proveedores de Terraform en sus partners, así que espero que el ecosistema de proveedores pueda seguir activo y abierto
Creo profundamente en el open source. Mi último proyecto en Microsoft también fue hacer que .NET fuera open source y multiplataforma; nuestro CTO participó en la creación de TypeScript, y Pulumi también es un proyecto open source Apache. HashiCorp ya no parece serlo
En términos generales, los tiempos cambiaron, y creo que publicar el código fuente no debería ser “si no entregas todo gratis, no es auténtico”, sino una relación de beneficio mutuo entre quienes lo crean y quienes lo usan
Los usuarios deben poder entender y extender desde el código fuente lo que están ejecutando, y quienes administran, mantienen y poseen el proyecto deben poder seguir haciéndolo
Esto no es un punto de equilibrio al que se llega, sino un equilibrio que hay que mantener en tensión
Revisé Wikipedia y dice que HashiCorp fijó las condiciones de su IPO el 29 de noviembre de 2021
Cada vez me parece más que esta hipótesis es correcta. Se agradecen datos anecdóticos, ya sean contraejemplos o casos que la respalden
Que no sea open source no significa que haya que impedir ver el código fuente, ni que haya que eliminar todas las características de una licencia aprobada por la OSI
Claro que habría sido mejor si fuera software libre, pero eso equivale a decir que sería mejor si todo el software fuera software libre
El problema surge cuando se intenta hacer pasar por open source una licencia que no puede obtener aprobación de la OSI. HashiCorp ya no afirma que siga siendo open source y ahora lo llama “source-available”
Bastante decepcionante. Personalmente no usé mucho más que Vault, y aunque probé Terraform, no lo disfruté ni construí nada sobre él, pero esto va exactamente en contra de lo que más valoraba de los productos de HashiCorp
Incluso contribuí a gestión de certificados, una parte del código que más uso en Vault, y ahora tengo que reconsiderar si en el futuro podré recomendarles a mis clientes que usen ese servicio, o si volveré a contribuir
Con la era en la que se seca el financiamiento de VC, se siente como si se estuviera revelando el peor futuro de las licencias que no son del estilo GPL
Es lamentable para quienes aprendieron de forma intencional OSS y su operación con el sueño de algún día usar ese conocimiento para crear un servicio, ser sus propios jefes y seguir devolviéndole a ese OSS que los trajo hasta aquí
Tengo mucha experiencia implementando y operando Vault Enterprise para la gestión de secretos de aplicaciones en toda la infraestructura de empresas
Durante los años en que adoptamos Vault y negociamos contratos, vi a ingenieros de ventas hacer afirmaciones inexactas o engañosas sobre funcionalidades “necesarias” para nuestros casos de uso, y prometer a largo plazo funciones que no podían cumplir
También recomendaban formas de integración que podían hacer que migrar fuera de Vault fuera prácticamente imposible o riesgoso, y siguieron quitando funciones que creíamos que serían gratuitas para siempre. El inicio de sesión con Okta/MFA fue el mayor ejemplo, y parece que HashiCorp se dio cuenta de que sin eso es difícil pasar auditorías serias de compliance, por lo que los equipos que dependen mucho de Vault terminarían pagando por esa función
En general, se veía como un fuerte vendor lock-in, y cada año terminábamos pagando más por las mismas funciones o por menos funciones. La política de precios, que ni siquiera los ingenieros podían explicar, también cambiaba de forma arbitraria constantemente
Considero que Vault en sí es un software excelente, pero como perdí la confianza en HashiCorp, personalmente no creo que vaya a depender de él para cosas importantes
Si se toma literalmente, nada cambió, y no es algo decepcionante sino una decisión inteligente. Se están protegiendo de los proveedores de nube que han abusado repetidamente de la buena voluntad de la comunidad open source
No se debe confiar en proyectos OSS que exigen a los colaboradores ceder el copyright, y para empezar no deberían aceptar contribuciones de buena fe
De lo contrario, aunque hoy sea Apache 2.0, mañana puede volverse comercial sin pedir permiso a nadie. Porque el mantenedor posee el 100% del código
Suele ser raro que un proyecto OSS respaldado por una entidad comercial reciba una cantidad significativa de contribuciones externas, pero aun así es un detalle importante a considerar en OSS
Decir algo como que “el modelo open source comercial debe evolucionar para que el ecosistema pueda seguir ofreciendo software abierto y de libre uso”, insinuando que licencias que no son open source, como BUSL, forman parte de la evolución del modelo open source, es una confusión grave o una desinformación intencional.
¿Alguien de un tamaño significativo ha usado alguna vez productos de HashiCorp para competir sustancialmente con HashiCorp?
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
Pulumi puede convertir cualquier Terraform Provider para que se pueda usar en Pulumi, lo que permite administrar con programas de Pulumi toda la infraestructura soportada por el ecosistema de Terraform Providers.
Las empresas toman medidas como esta porque compañías como Amazon aprovechan las licencias libres y open source para montar versiones autohospedadas de proyectos open source.
ctrl+f, se ve en qué punto dejan de usar esa expresión.HashiCorp explica este cambio no como una forma de seguir siendo “open source”, sino como una forma de mantener productos abiertos y de libre uso.
Creo que son más honestos que otros en el sentido de que no dicen que seguirán siendo “open source” después de cambiar la licencia. Está claro que saben la reacción que recibirían si lo llamaran así.
Es interesante que @mitchellh no participe en la conversación. En el pasado interactuaba directamente en HN, y supongo que habría tenido influencia final en esta decisión.
En general, parece una jugada de perdedor. Basta ver qué pasó con Elasticsearch. Para mí y para la mayoría de la gente, ES ya no existe. Nos pasamos contentos a OpenSearch y no miramos atrás al pobre kimchi. Por sus propias acciones, Elasticsearch dejó de ser relevante.
¿Este movimiento de HashiCorp detonará un esfuerzo similar por hacer forks de la última versión con licencia open source de Terraform y otras herramientas? Si los creadores se vuelven mezquinos e inseguros, y se ponen hostiles con la comunidad open source que ayudó a construirlas, ¿qué otra opción queda?
Estoy extremadamente decepcionado con el liderazgo de HashiCorp. MitchellH y Armon Dadgar debieron haber tratado mucho mejor a la comunidad.
En 2016 me entrevisté en HashiCorp y al final rechacé entrar; alguna vez me arrepentí un poco de esa decisión. Ahora que mostraron su verdadera cara, estoy seguro de que fue la elección correcta.
Ya existe ese dicho sobre la confianza: tarda años en construirse, segundos en romperse y una eternidad en recuperarse.
Me sorprende que personas que consideraba inteligentes puedan ser tan tontas.
No hace falta insultar a alguien que ha logrado muchas cosas.
Su software era open source, y lo bueno se va a bifurcar, así que no hace falta odiar a HashiCorp.
Tampoco estoy de acuerdo con la frase “la confianza tarda años en construirse, segundos en romperse y una eternidad en recuperarse”. Es demasiado agresiva.
HashiCorp creó cosas excelentes e intentó un negocio basado en open source. No rompió ningún contrato ni hizo algo inmoral; esta es su decisión.
Parece el desenlace inevitable de todas las empresas open source después de que se acaba el dinero gratis. Lo molesto es que la redacción es bastante ambigua.
HashiCorp define los productos competidores como “productos o servicios ofrecidos a usuarios o clientes externos a la organización que se superponen sustancialmente con la funcionalidad de los productos o servicios comerciales de HashiCorp”.
Por ejemplo, supongamos que no había un servicio de estimación de costos, creaste algo y se volvió popular: https://github.com/infracost/infracost
¿Qué pasa si dos años después Terraform Cloud incorpora algo parecido? ¿Tienes que cerrar el negocio?
Pero en productos críticos de negocio más grandes, como bases de datos, se ven giros mucho más raros, como dificultar el autohosting o restringir funciones esenciales.
Es mejor que el código cerrado, pero no es ideal. Desde hace un tiempo pienso que probablemente las licencias sean una salida práctica, pero tienen que ser ampliamente entendidas, justas y claras.
La frase “productos o servicios ofrecidos a usuarios o clientes externos a la organización y cuya funcionalidad se superpone sustancialmente” duele. Tal como está redactada, (1) no es clara y (2) la autoridad sobre esa ambigüedad queda inclinada hacia la empresa, abriendo la puerta a una aplicación selectiva.
En una situación donde estás firmando un documento legal, “no te preocupes, no vamos a perseguir a nadie” no convence. En un contrato, acumular facultades que hoy parecen suaves o que se pueden ejercer en el futuro me parece una gran señal de alerta.
Me da curiosidad qué opinan otros sobre esta licencia en sí.
Lo de “dos años después Terraform Cloud incorpora algo parecido” es un punto realmente bueno. El alcance de una empresa cambia.
Según https://www.couchbase.com/blog/couchbase-adopts-bsl-license/, la BSL normalmente establece una fecha de cambio de entre 1 y 4 años, momento en el que la licencia BSL pasa a una licencia de cambio de código abierto, como GPL, AGPL, Apache, etc.
Así que la pregunta más importante es cuál es la licencia de cambio y cuánto tarda.
Si pasa a MPL 2.0 después de 1 año, está bien. Pero si es mucho más largo y restrictivo, es un cambio total de postura, y la versión open source quedará demasiado lejos de la versión más reciente como para ser útil en la práctica.
Corrección: es MPL 2.0 después de 4 años.
https://www.hashicorp.com/license-faq#What's-the-difference-...
Cuando la seguridad está involucrada, 4 años son básicamente solo “interés histórico”.
4 años, MPL 2.0.
No sé otras empresas, pero siempre me pregunto dónde estarían estas compañías si su software hubiera tenido desde el principio una licencia no libre.
Esto es hostil no solo para las grandes empresas que quieren “robar” el código y ofrecerlo como servicio, sino también para los usuarios finales, individuos y empresas pequeñas.
Si operas y usas con éxito software de HashiCorp y luego te consideran competidor, HashiCorp puede decidir bloquearte.
Por ejemplo: https://github.com/hashicorp/vault/blob/main/go.mod#L25
Si hubieran empezado con BSL desde el principio, no creo que hubieran logrado una adopción tan amplia.
La página de CLA de HashiCorp de hace dos meses: https://web.archive.org/web/20230610041432/https://www.hashi...
Decía que “para permitir que HashiCorp construya un negocio sostenible y, al mismo tiempo, mantener los proyectos bajo licencias libres y de código abierto como MPL2, exigimos a los colaboradores externos que firmen un Acuerdo de Licencia de Colaborador (CLA)”.
También decía que “HashiCorp se compromete a aplicar licencias de software verdaderamente libres y de código abierto (FOSS) al software no comercial. El CLA permite que HashiCorp comercialice sus productos de forma segura, mientras los usuarios conservan todos los derechos que otorgan las licencias FOSS estándar, como el derecho a usarlos en sus propios proyectos o negocios, redistribuir código fuente modificado y hacer forks completos”.
Es decepcionante que el lenguaje no legal de la página insinuara repetidamente que firmar el CLA ayudaba a mantener los proyectos de HashiCorp como open source, pero el texto contractual real no ofrecía esa garantía.
Alguien debería impugnarlo ahora que cambió la premisa del CLA, es decir, la situación en la que las contribuciones se relicencian como no FOSS.
La mayoría de los CLA son muy secos, pero HashiCorp incluyó varias declaraciones en el suyo, así que podría meterse en problemas.
La única razón para exigir algo así es relicenciar, y si ya es FOSS, la única razón para querer relicenciar es pasar a software propietario.
Linux no exige un CLA para contribuir. Solo lo exigen estos payasos que fingen ser open source.
Nuestra empresa OSS está bajo Apache 2.0 y fue construida con Nomad como núcleo.
Le agregamos algunos servicios alrededor para ofrecer orquestación de servidores de juegos, lo que HashiCorp podría malinterpretar como “ofrecer un producto competidor”.
Como la licencia es deliberadamente ambigua, vamos a congelar la versión de Nomad en la última versión MPL.
También usamos CockroachDB, y eso es BSL, pero no ofrecemos ningún producto que compita con ellos.
Es probable que siga recomendando a quienes me pidan consejo los productos de HashiCorp —Nomad, Consul, Terraform, Packer—, pero este cambio suena decepcionante.
Para quienes tengan curiosidad, mantenemos un SBOM sencillo: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
Soy el líder de ingeniería de Nomad. La licencia está fuera de mi control, pero hay muchos usuarios preocupados por si algún día podrían ser interpretados como competencia.
No puedo prometer nada, pero haré todo lo posible para darte la confianza de que Nomad sigue siendo la herramienta adecuada para tu trabajo.
Personalmente, no lo veo como un problema. Si el objetivo final es convertirse en una plataforma SaaS, me gustaría que más proyectos open source empezaran desde el principio con la Business Source License
He visto una y otra vez cómo las grandes empresas abusan del espíritu del open source para su propio beneficio económico, no devuelven nada y actúan de mala fe
No consideran malicioso usar algo que se hizo público y disponible, y están dispuestos a compartirlo gratis
Si no es así, no es open source. Claro que no todo el software tiene que ser open source, y eso también está bien
Quien abusa del espíritu del open source es quien crea reglas arbitrarias sobre su uso
Aun así, es mejor dejarlo claro desde el principio