Algunas empresas emergentes están optando por el “código justo” para evitar los problemas de las licencias de código abierto
Como es poco probable que las tensiones perennes entre el software propietario y el de código abierto (OSS) terminen pronto, una startup de 3 mil millones de dólares está apostando por un nuevo paradigma de licencias, diseñado para unir los mundos abierto y propietario, repleto de nuevas definiciones, terminología y modelo de gobernanza.
La empresa de software para desarrolladores Sentry introdujo recientemente una nueva categoría de licencia denominada “código justo”. Sentry es uno de los primeros en adoptarla, al igual que media docena de otras empresas, incluida GitButler, una empresa de herramientas para desarrolladores de uno de los fundadores de GitHub.
El concepto de código fuente justo está diseñado para ayudar a las empresas a alinearse con la esfera de desarrollo de software “abierto”, sin invadir los paisajes de licencias existentes, ya sean de código abierto, núcleo abierto o código fuente disponible, y evitando al mismo tiempo cualquier asociación negativa que exista con lo “propietario”.
Sin embargo, el código abierto también es una respuesta a la creciente sensación de que el código abierto no está funcionando comercialmente.
“El código abierto no es un modelo de negocio; es un modelo de distribución, es un modelo de desarrollo de software, principalmente”, dijo a TechCrunch Chad Whitacre, director de código abierto de Sentry. “Y, de hecho, impone límites severos a los modelos de negocio disponibles, debido a los términos de la licencia”.
Por supuesto, hay proyectos de código abierto que han tenido mucho éxito, pero generalmente son componentes de productos propietarios más grandes. Las empresas que han enarbolado la bandera del código abierto en su mayoría se han retirado para proteger su arduo trabajo, pasando de una licencia totalmente permisiva a una licencia “copyleft” más restrictiva, como hicieron Element el año pasado y Grafana antes, o abandonando por completo el código abierto, como hizo HashiCorp con Terraform.
“La mayor parte del software del mundo todavía es de código cerrado”, añadió Whitacre. “Kubernetes es de código abierto, pero Google Search es cerrado. React es de código abierto, pero Facebook Newsfeed es cerrado. Con el código fuente justo, estamos creando un espacio para que las empresas compartan de forma segura no solo estos componentes de infraestructura de nivel inferior, sino que también compartan el acceso a su producto principal”.
Juego limpio
Sentry, una plataforma de monitoreo del rendimiento de aplicaciones que ayuda a empresas como Microsoft y Disney a detectar y diagnosticar software con errores, inicialmente estaba disponible bajo una licencia de código abierto BSD de 3 cláusulas. Pero en 2019, el producto pasó a una licencia de código abierto comercial (BUSL), una licencia de código abierto más restrictiva creada inicialmente por MariaDB. Esta medida fue para contrarrestar lo que el cofundador y director de tecnología David Cramer llamó “empresas financiadas que plagian o copian nuestro trabajo para competir directamente con Sentry”.
Avanzamos hasta agosto del año pasado y Sentry anunció que estaba haciendo que una herramienta para desarrolladores recientemente adquirida llamada Codecov fuera “de código abierto”. Esto fue para disgusto de muchos, que se preguntaban si la compañía realmente podía llamarla “de código abierto” dado que se estaba lanzando bajo BUSL, una licencia que no es compatible con la definición de “código abierto” de la Iniciativa de Código Abierto (OSI).
Cramer se apresuró a emitir una especie de disculpa, explicando que, si bien había utilizado erróneamente el descriptor, la licencia BUSL se adhiere al espíritu de muchas licencias de código abierto: los usuarios pueden alojar y modificar el código sin pagarle un centavo al creador. Simplemente no pueden comercializar el producto como un servicio de la competencia.
Pero el hecho es que BUSL no es de código abierto.
“En cierto modo metimos la pata y provocamos un escándalo”, dijo Whitacre. “Pero fue durante el debate que siguió cuando nos dimos cuenta de que necesitábamos un nuevo término. Porque no somos propietarios y, claramente, la comunidad no acepta que seamos de código abierto. Y tampoco somos de núcleo abierto”.
Quienes siguen el mundo del código abierto saben que la terminología lo es todo, y Sentry está lejos de ser la primera empresa que comete un (mal) uso de la nomenclatura establecida. No obstante, el episodio impulsó a Adam Jacob, CEO y cofundador de la startup de DevOps System Initiative, a desafiar a alguien a desarrollar una marca y un manifiesto que cubriera el tipo de licencias con las que Sentry quería alinearse, de forma similar a lo que la OSI ha estado haciendo durante el último cuarto de siglo con el código abierto, pero con un gradiente comercialmente más atractivo.
Y eso fue lo que llevó a Sentry a una fuente justa.
Por ahora, la principal licencia de código fuente recomendada es la Functional Source License (FSL), que Sentry lanzó el año pasado como una alternativa más simple a BUSL. Sin embargo, ahora también se ha designado a BUSL como código fuente justo, al igual que otra nueva licencia creada por Sentry llamada Fair Core License (FCL), ambas incluidas para satisfacer las necesidades de diferentes proyectos.
Las empresas pueden presentar su propia licencia para su consideración, aunque todas las licencias de código fuente justo deben tener tres estipulaciones básicas: Debe estar disponible públicamente para su lectura; permitir que terceros lo utilicen, modifiquen y redistribuyan con “restricciones mínimas“; y tienen una estipulación de publicación de código abierto retrasada (DOSP), lo que significa que se convierte en una verdadera licencia de código abierto después de un período de tiempo predefinido. Con la licencia FSL de Sentry, ese período es de dos años; para BUSL, el período predeterminado es de cuatro años.
El concepto de “retrasar” la publicación del código fuente bajo una verdadera licencia de código abierto es un elemento clave que define una licencia de código fuente justa, y la distingue de otros modelos como el de código abierto. La DOSP protege los intereses comerciales de una empresa a corto plazo, antes de que el código se vuelva completamente de código abierto.
Sin embargo, una definición que utilice subjetivos vagos como “restricciones mínimas” seguramente puede causar problemas. ¿Qué significa eso exactamente y qué tipos de restricciones son aceptables?
“Lanzamos esto hace apenas un mes, es un proyecto de largo plazo”, dijo Whitacre. “El código abierto (la definición de OSI) existe desde hace más de 25 años, por lo que parte de esto está abierto a discusión; queremos ver qué surge y concretarlo con el tiempo”.
La licencia de código fuente justo sigue un camino similar al de las licencias de “código fuente disponible” que la precedieron, en la medida en que incluye cláusulas de no competencia que prohíben el uso comercial en productos competidores. Esto incluye cualquier producto que ofrezca “la misma funcionalidad o sustancialmente similar” que el software original. Y este es uno de los problemas centrales de dichas licencias, según Thierry Carrez, director general de la Open Infrastructure Foundation y miembro del consejo de la Open Source Initiative: mucho está abierto a la interpretación y puede ser “legalmente confuso”.
“Las licencias de código justo no son licencias de código abierto porque las libertades que otorgan no se aplican a todos; discriminan en función de reglas de no competencia legalmente imprecisas”, dijo Carrez. “Por lo tanto, la adopción generalizada de esas licencias no solo crearía incertidumbre legal, sino que también reduciría significativamente la innovación futura”.
Además, Carrez agregó que no hay nada que impida que los términos de las licencias de fuente justa cambien en el futuro, destacando el problema de una licencia controlada por una sola entidad.
“Hay dos enfoques para el desarrollo de software: se puede tener un enfoque propietario, con una sola entidad que produce el software y lo monetiza; o se puede tener un enfoque de bienes comunes, donde un ecosistema abierto se reúne para producir software y compartir los beneficios que éste genera”, dijo Carrez. “En el enfoque propietario, nada impide que el único titular de los derechos de autor cambie los términos del acuerdo en el futuro. Por lo tanto, los términos exactos de la licencia que utilicen actualmente no importan tanto como la confianza que deposite en esas empresas para que no los cambien”.
En muchos sentidos, el código fuente justo es simplemente un ejercicio de desarrollo de marca que permite a las empresas seleccionar partes de un espíritu de código abierto establecido que aprecian, al tiempo que evitan llamarse “propietarias” o alguna otra variante.
Amanda Brock, directora ejecutiva de OpenUK, un organismo de defensa del código abierto del Reino Unido, dijo que si bien “es fantástico ver a la gente siendo honesta en cuanto a que (su software) no es de código abierto”, sugirió que esta nueva categoría de licencia podría complicar las cosas, en particular porque ya existen nombres bien establecidos para este tipo de software.
“Debemos cambiar nuestra manera de pensar y considerar tres categorías de software, no dos. OpenUK lleva tiempo defendiendo que lo hagamos”, dijo Brock a TechCrunch. “Dentro del código abierto, llamamos a la categoría que es propietaria y cuyo código fuente es público ‘código fuente disponible’ o ‘código fuente público’. Es cualquier código que hace que el código fuente esté disponible y que se distribuye con una licencia que no cumple con la definición de código fuente abierto”.
Confirmación de Git
Scott Chacon, quien afirma ser uno de los cuatro fundadores de GitHub y se desempeñó como su director de información antes de su partida en 2016, lanzó una nueva startup enfocada en Git llamada GitButler a principios de 2023. Pasó por toda una gama de consideraciones de licencia, incluida la de ser totalmente propietario, antes de decidirse por FSL y proclamar públicamente su apoyo al movimiento de código fuente justo.
“Todavía no estamos muy seguros de cuál será exactamente nuestro modelo de negocio final y queremos conservar nuestras opciones”, dijo Chacon a TechCrunch. “Sabemos que si una empresa lanza un software con una licencia OSS y luego necesita renovarla con una licencia más restrictiva para que su negocio funcione, es comprensible que haya un clamor por parte de la comunidad”.
Y eso nos lleva al quid de la cuestión para muchas empresas hoy en día. Claro, a todo el mundo le encanta el código abierto, pero con tanto retroceso, las empresas emergentes hoy dudan en lanzarse de lleno y luego arriesgarse a la ira de la comunidad global por tener que cambiar de rumbo.
“Nos gustó el hecho de que (la licencia estilo BUSL/FSL) sea en última instancia de código abierto, bajo una licencia MIT, pero nos da cierta protección mientras estamos invirtiendo tanto en ella”, dijo Chacon. “Queremos poder proteger a nuestros empleados y a nuestros inversores y, al mismo tiempo, brindarles a nuestros usuarios el mayor acceso y la mayor libertad posibles”.
GitHub es, en realidad, un buen punto de partida para debatir el movimiento de código abierto. La plataforma de alojamiento de código propiedad de Microsoft es fundamental para el software de código abierto, y GitHub ha abierto el código de varias de sus propias herramientas internas a lo largo de los años. Sin embargo, GitHub en sí no es de código abierto. El exdirector ejecutivo de GitHub, Tom Preston-Werner, escribió sobre este mismo asunto en 2011, elogiando las virtudes del código abierto y describiendo cosas que deberían mantenerse ocultas. “No abra el código de nada que represente un valor empresarial fundamental”, escribió.
Y es este enfoque el que Chacón está adoptando en su última aventura.
“Mi filosofía es abrir el código fuente de todo aquello que no te importe o que incluso prefieras que utilicen tus competidores”, afirmó. “Creo que si hace 15 años existiera el código fuente justo, entonces podríamos haber hecho público el código fuente de GitHub con una licencia como esa”.
Otras empresas que se han sumado al fervor inicial por el código fuente justo incluyen a CodeCrafters, exalumno de YC; PowerSync; Ptah.sh; y Keygen, cuyo fundador Zeke Gabrielse se está asociando con Whitacre para manejar la gobernanza en torno a las nuevas aplicaciones de código fuente justo.
“Nuestra gobernanza en este momento está ajustada al tamaño de la iniciativa, por lo que somos Zeke y yo, nuestra toma de decisiones es pública en GitHub y cualquiera es libre de participar”, dijo Whitacre, y agregó que podría haber margen para establecer una supervisión independiente en el futuro, aunque no es una prioridad en este momento.
“En realidad, solo estamos plantando la semilla y viendo qué sucede”, dijo Whitacre. “Es un proceso largo, por lo que desarrollaremos la estructura a medida que avance el movimiento”.