La lucha por las licencias de código abierto
A principios de este año, Elastic reavivó la discusión sobre licencias de código abierto cuando lo hizo Anunciado cambiaría su modelo de licencias para proteger mejor su código fuente abierto. En los últimos años, varias empresas, incluidas Redis Labs, MongoDB, Cockroach Labs y Confluent, han cambiado sus licencias de código abierto para evitar lo que hacen. Llamada “El gran robo de código” en el que los proveedores de la nube como Amazon se hacen cargo de su exitoso proyecto de código abierto como un servicio en la nube y se benefician de él sin devolver nada a la comunidad.
«Los proveedores de la nube no se preocupan por la monetización de los proyectos de software libre, quieren ejecutar más cargas de trabajo en su infraestructura y, por lo tanto, ser el objetivo preferido para tales cargas de trabajo», dijo Sacha Labourey, cofundador y director de estrategia de CloudBees.
Confluent creó una nueva licencia comunitaria y MongoDB anunció su Licencia pública del lado del servidor (SSPL) para luchar contra los proveedores de la nube. En enero, Elastic anunció que cambiaría sus proyectos de código abierto Kibana y Elasticsearch a una licencia dual bajo Elastic License v2 y SSPL.
CONTENIDO RELACIONADO: Open Source es una comunidad, no una marca
Sin embargo, estas nuevas licencias a las que están migrando las empresas no se consideran de código abierto según el estándar de la Iniciativa de código abierto, por lo que muchos en la industria se preguntan dónde están ahora estas empresas con el código abierto.
“Estas nuevas licencias de ‘fuente disponible’ contienen restricciones para evitar que los proveedores de infraestructura en la nube creen un servicio a partir de su código. Los primeros esfuerzos, como la cláusula de los comunes, restringieron en gran medida el «uso comercial» y los usuarios encontraron que el lenguaje de las licencias «causaba cierta confusión e incertidumbre». Los esfuerzos recientes de Elastic y otros son más quirúrgicos. Simplemente intentan evitar que los usuarios proporcionen el software como un servicio por sí mismos. El objetivo de estas nuevas licencias es continuar beneficiándose de la disponibilidad generalizada del software y su código fuente para atraer a futuros clientes y, al mismo tiempo, eliminar los servicios SaaS de la competencia basados en el mismo código ”, dijo Justin Colannino, Director de Política y Asesoría para Desarrolladores de GitHub. , escribió en un correo.
Según Stephen O’Grady, analista principal y cofundador de la firma analista de desarrolladores RedMonkAunque puede ser molesto, los proveedores de la nube realmente no abusan de los proyectos de código abierto si todavía se adhieren a las reglas de la licencia de código abierto. «Si los propietarios de proyectos no quieren que ciertas partes puedan usar su software, no deberían usar licencias de fuente abierta», dijo.
MongoDB argumenta que bajo SPPL, los desarrolladores aún pueden acceder, usar, modificar y distribuir su código. “Introdujimos la licencia SSPL para proteger nuestro derecho a construir una empresa innovadora en la era de la nube. Queríamos contrarrestar la amenaza de los proveedores de nube de hiperescala que toman nuestro producto gratuito y lo ofrecen como un servicio sin devolver nada ”, dijo Dev Ittycheria, CEO y presidente de MongoDB.
Tomer Levy, director ejecutivo de Logz.io, un proveedor de plataformas de observabilidad en la nube, argumenta que el cambio de licencias sacude toda la base de la filosofía de código abierto y muestra que quienes tienen el control de proyectos populares tienen la capacidad de acceder a esos proyectos desde la comunidad en cualquier momento. “Nos decepcionó la decisión de Elastic de cambiar a una licencia que no era realmente de código abierto. Esta es una bofetada a los ingenieros que ayudaron a construir la comunidad y hacer del software de código abierto el elemento básico que es hoy ”, dijo.
O’Grady agregó que cambios como este tienen el potencial de difuminar la definición de lo que es y lo que no es de código abierto y crear más incertidumbre en la sala. «Si estas empresas realmente quisieran proteger el código abierto, mantendrían activa y agresivamente una clara distinción entre sus fuentes disponibles, licencias propietarias y alternativas reales de código abierto», dijo.
Elastic ha decidido no llamar más a Elasticsearch o Kibana de código abierto, sino llamar a los proyectos libres y abiertos. “Aunque decidimos evitar confusiones al no usar el término fuente abierta para estos productos, continuaremos usando las palabras ‘abierto’ y ‘libre y abierto’. Estas son formas sencillas de describir el hecho de que el producto es de uso gratuito, el código fuente está disponible y también se aplica a nuestro modelo de participación abierta y colaborativa en GitHub. Seguimos comprometidos con los principios de código abierto: transparencia, cooperación y comunidad ”, explicó la compañía en un correo.
Haff de Red Hat cree que si un proyecto tiene éxito y es tan popular que un importante proveedor de nube pública intenta competir con él, puede ser algo bueno. «Hay un dicho en el código abierto que dice que tu mayor desafío no es competir con él, pero que nadie sabe ni le importa lo que estás haciendo», dijo.
Otra forma de combatir a los proveedores de la nube además de cambiar su modelo de licencia de software es formar asociaciones de innovación con el proveedor de la nube para que haya una ventana en la que no puedan simplemente robar su funcionalidad de la amenaza.
Bryon de Drupal cree que la creación de algún tipo de creative commons para el código abierto podría ayudar a categorizar los proyectos de código abierto en proyectos que son de uso gratuito, proyectos que requieren atribución, etc. Expresaría lo que estos diferentes proyectos están tratando de hacer, pero a través del lente único de esta organización que ha demostrado su importancia y credibilidad dentro de ”la comunidad”, dijo.
También sugirió ejercer presión social sobre estas empresas para que mejoren. El recién llegado a WSO2 cree que Amazon ya está reaccionando y cambiando. En respuesta a Elastic, la compañía desarrolló OpenSearch, una bifurcación de código abierto de Elasticsearch y Kibana, y está trabajando con la industria para brindar soporte y mantenimiento a largo plazo para el proyecto. Además, New Relic llevó recientemente Pixie, el proyecto de código abierto para la observabilidad nativa de Kubernetes, a la Cloud Native Computing Foundation y amplió su relación con Amazon para ejecutar Pixie en AWS.
Amazon “es actualmente líder en este mercado. Tienen la capacidad de asumir fácilmente una posición de liderazgo en la resolución de nuevos problemas a través de la colaboración y el código abierto ”, dijo Newcomer. “Lo que necesitamos son formas más estándar de interactuar con ellos, plataformas estándar que todos los proveedores de nube deberían implementar para resolver los problemas de las personas para que no terminen en esta situación de tener que elegir lo que es todo difícil”.
