El fundador de Elastic explica por qué regresaron al código abierto 4 años después de volverse propietarios

Los problemas de licencias han sido durante mucho tiempo una faceta definitoria del espacio comercial de código abierto. Algunos de los proveedores más importantes han cambiado a una licencia “copyleft” más restrictiva, como lo hicieron Grafana y Element, o se han vuelto totalmente patentadas, como lo hizo HashiCorp el año pasado con Terraform.

Pero una empresa de 8.000 millones de dólares ha tomado el camino opuesto.

Elastic, el creador del motor de búsqueda y recuperación de datos empresariales Elasticsearch y el panel de visualización de Kibana, lanzó una bola curva sorpresa el mes pasado cuando reveló que volvería a ser de código abierto, casi cuatro años después de cambiar a un par de licencias propietarias de “fuente disponible”. . La medida va en contra de una corriente que ha visto a innumerables empresas abandonar por completo el código abierto. Algunos incluso están creando un paradigma de concesión de licencias completamente nuevo, como estamos viendo con el “fuente justo”, que ha sido adoptado por varias empresas emergentes.

“Simplemente estaba tardando demasiado”

En 2021, Elastic pasó a licencias de código cerrado después de varios años de conflicto con AWS, la filial en la nube de Amazon, que vendía su propia versión administrada de Elasticsearch. Si bien AWS estaba en todo su derecho de hacerlo dada la naturaleza permisiva de la licencia Apache 2.0, Elastic se ofendió por la forma que AWS estaba comercializando su encarnación, utilizando marcas como “Amazon Elasticsearch”. Elastic creía que esto estaba causando demasiada confusión, ya que los clientes y usuarios finales no siempre prestan demasiada atención a las complejidades de los proyectos de código abierto y los servicios comerciales asociados.

“La gente a veces piensa que cambiamos la licencia porque estábamos molestos con Amazon por tomar nuestro proyecto de código abierto y brindarlo ‘como un servicio'”, dijo a TechCrunch el cofundador y director de tecnología de Elastic, Shay Banon, en una entrevista esta semana. “Para ser honesto, siempre estuve de acuerdo con eso, porque está en la licencia que se les permite hacer eso. Lo que siempre tuvimos que afrontar fue la violación de la marca registrada”.

Elastic buscó vías legales para lograr que Amazon se retirara de la marca Elasticsearch, un escenario que recuerda al actual alboroto de WordPress que hemos visto la semana pasada. Y aunque más tarde Elastic resolvió su disputa de marcas con AWS, esas disputas legales consumen muchos recursos, cuando lo único que la empresa quería hacer era salvaguardar su marca.

“Cuando analizamos la vía legal, sentimos que teníamos un caso realmente bueno y, de hecho, terminamos ganando, pero eso ya no era realmente relevante debido al cambio que habíamos realizado (en la solución Elasticsearch). licencia)”, dijo Banon. “Pero estaba tomando demasiado tiempo: puedes pasar cuatro años ganando un caso legal y para entonces ya habrás perdido el mercado debido a la confusión”.

Regreso al futuro

El cambio siempre fue un punto delicado internamente, ya que la empresa se vio obligada a utilizar un lenguaje como “gratuito y abierto” en lugar de “código abierto”. Pero el cambio funcionó como esperaba Elastic, lo que obligó a AWS a bifurcar Elasticsearch y crear una variante denominada OpenSearch, que el gigante de la nube transfirió a la Fundación Linux apenas este mes.

Habiendo pasado suficiente tiempo y OpenSearch ahora firmemente establecido, Banon y compañía decidieron revertir el rumbo y hacer que Elasticsearch sea de código abierto una vez más.

“Sabíamos que Amazon bifurcaría Elasticsearch, pero no es que hubiera un gran plan maestro aquí; sin embargo, esperaba que si pasaba suficiente tiempo con la bifurcación, tal vez pudiéramos volver al código abierto”, dijo Banon. “Y para ser honesto, es por una razón muy egoísta: me encanta el código abierto”.

Sin embargo, Elastic no ha completado el círculo. En lugar de volver a adoptar su permisiva licencia Apache 2.0 de antaño, la compañía optó por AGPL, que tiene mayores restricciones: requiere que cualquier software derivado se publique bajo la misma licencia AGPL.

Durante los últimos cuatro años, Elastic les ha dado a los clientes la posibilidad de elegir entre su licencia Elastic patentada o la SSPL (licencia pública del lado del servidor), que fue creada por MongoDB y posteriormente no logró ser aprobada como “código abierto” por la Iniciativa de Código Abierto (OSI). ), los administradores de la definición oficial de código abierto. Si bien SSPL ya ofrece algunos de los beneficios de una licencia de código abierto, como la capacidad de ver y modificar código, con la adición de AGPL, Elastic vuelve a llamarse a sí mismo código abierto: la licencia es reconocida como tal por OSI.

“Las licencias de Elastic (y SSPL) ya eran muy permisivas y permitían usar Elasticsearch de forma gratuita; simplemente no tenían el sello de ‘código abierto’”, afirmó Banon. “Sabemos mucho sobre este espacio, pero la mayoría de los usuarios no: simplemente buscan en Google ‘base de datos de vectores de código abierto’, ven una lista y eligen entre ellas porque les importa el código abierto. Y es por eso que me importa estar en esa lista”.

En el futuro, Elastic dice que espera trabajar con OSI para crear una nueva licencia, o al menos tener una discusión sobre qué licencias se clasifican y no como código abierto. La licencia perfecta, según Banon, es aquella que se sitúa “en algún lugar entre AGPL y SSPL”, aunque admite que la AGPL por sí sola puede ser suficiente en su mayor parte.

Pero por ahora, Banon dice que simplemente poder volver a llamarse “código abierto” es suficiente.

“Sigue siendo mágico decir ‘código abierto’: ‘búsqueda de código abierto’, ‘monitoreo de infraestructura de código abierto’, ‘seguridad de código abierto’”, dijo Banon. “Encapsula mucho en dos palabras: encapsula el código abierto y todos los aspectos de la comunidad. Encapsula un conjunto de libertades que a los desarrolladores nos encanta tener”.