Fuente abierta El pionero Bruce Perens acierta en una cosa y en la mayoría de las cosas se equivoca. entrevista reciente sobre el futuro del código abierto. Tiene toda la razón en que “nuestro [open source] las licencias ya no funcionan”, incluso si se equivoca en cuanto al motivo. (Dice que “las empresas han encontrado todas las lagunas jurídicas”).
No, el problema es que el código abierto nunca ha sido más importante, pero menos relevante para las tendencias tecnológicas más importantes de nuestro tiempo: computación en la nube y inteligencia artificial. En 2024, necesitaremos código abierto para ponernos al día con estas tecnologías.
Las nubes se acumulan sobre el código abierto
En algunos sectores está de moda culpar a empresas como MongoDB (divulgación: trabajo para MongoDB), Neo4j, Elastic, HashiCorp, etc., por supuestamente contaminar el código abierto con licencias como Business Source License, Commons Clause y Server Side Public License ( SSPL). Pero el problema no son tanto estas empresas como el hecho de que intentaron distribuir servicios en la nube bajo licencias de código abierto que simplemente no funcionan para la nube.
¿No me crees? Pregúntele a Stefano Maffulli, director ejecutivo de Open Source Initiative (OSI), que dirige la Definición de código abierto (OSD). En una entrevista, Maffulli me dijo: «El código abierto se perdió la evolución de la forma en que se distribuye y ejecuta el software». Todas las licencias de código abierto se concibieron en una era anterior a la nube y suponen un método obsoleto para distribuir software. Con la Licencia Pública General Affero (AGPL), la OSI adoptó un truco que no era nativo de la nube. Por ello, continúa Maffulli: «Realmente no prestamos atención a lo que estaba pasando y eso generó mucha tensión en el negocio de la nube».
Parte de esa tensión se desarrolló mientras trabajaba en AWS. Mi empleador actual, MongoDB, intentó que la OSI aprobara el SSPL como una licencia oficial de código abierto. Finalmente, la empresa se retiró del proceso, lo cual fue desafortunado. Si le gusta la GPL, le gustará la SSPL, ya que es básicamente una GPL en la nube. A diferencia de la Licencia de origen comercial y las licencias más recientes, la SSPL no discrimina ciertos tipos de uso del software (es decir, no hay restricciones para ejecutar el software en producción con fines comerciales o competitivos). Simplemente dice que si distribuye el software como un servicio, debe poner a disposición todo el resto del software utilizado para ejecutarlo, porque ¿de qué sirve la libertad para inspeccionar, modificar y ejecutar software si la infraestructura de software esencial para alimentarlo está completamente cerrada? ? (Puedes ver las diferencias entre AGPL y SSPL claramente delineadas aquí.)
En 2024, la OSI debe tomarse en serio la actualización de su definición de código abierto para que sea relevante para la nube. No es necesario que sea el SSPL, pero sí debe reflejar el hecho de que la mayor parte del software no se distribuye de la misma manera que contempla el “código abierto” del OSD. Todavía estamos usando definiciones de código abierto para tratar de capturar los autos eléctricos y los cohetes de nuestra realidad moderna.
Hacer que el código abierto pierda sentido en la era de la IA
Por mucho que la nube haya superado al código abierto, la IA la ha dejado completamente sin sentido. He discutido esto extensamente (ver aquí y aquí), pero todo se reduce a una pregunta fundamental: ¿Cuál es el “código” que el código abierto esperaría preservar?
en un conversación Con el director ejecutivo de Aryn, Mehul Shah, analizamos este problema del «código». Citando ese artículo en detalle:
La primera es pensar en los datos de capacitación seleccionados como el código fuente de los programas de software. Si comenzamos por ahí, entonces el entrenamiento (descenso de gradiente) es como la compilación del código fuente y la arquitectura de red neuronal profunda de los modelos de transformadores o [large language models] Es como el hardware virtual o físico en el que se ejecuta el programa compilado. En esta lectura, los pesos son el programa compilado.
Esto parece razonable, pero inmediatamente plantea preguntas clave. En primer lugar, los datos seleccionados suelen ser propiedad de otra persona. En segundo lugar, aunque las licencias están hoy en día en las ponderaciones, es posible que esto no funcione bien porque esas ponderaciones son sólo números de punto flotante. ¿Es esto diferente de decir que está otorgando una licencia, que es solo un montón de 1 y 0? ¿La licencia debería ser sobre arquitectura? Probablemente no, ya que la misma arquitectura con diferentes pesos puede brindarte una IA completamente diferente. ¿Debería entonces la licencia referirse a los pesos y la arquitectura? Quizás, pero es posible modificar el comportamiento del programa sin acceso al código fuente mediante ajustes finos y ajustes de instrucciones. Luego está la realidad de que los desarrolladores a menudo distribuyen deltas o diferencias con respecto a los pesos originales. ¿Los deltas están sujetos a la misma licencia que el modelo original? ¿Pueden tener licencias completamente diferentes?
En resumen, no podemos simplemente decir una modelo de lenguaje grande es de código abierto, porque aún no podemos decidir qué debería ser abierto exactamente. Esto es similar al problema que SSPL intentaba resolver, pero es aún más complicado. «No existe una definición establecida de qué es la IA de código abierto» argumenta Mike Linksvayer, jefe de política de desarrolladores de GitHub. No estamos ni cerca de resolver ese dilema.
Afortunadamente, esta vez, el OSI no está dormido al volante del OSD y está trabajando activamente en lo que debería ser el OSD para la IA. Sin embargo, subraya Maffulli, “es un escenario extremadamente complejo”. Mi deseo de Año Nuevo para nuestra industria es que OSI asuma la responsabilidad de actualizar el OSD tanto para la nube como para la IA. Hemos pasado los últimos años castigando a las empresas por no cumplir con los principios de código abierto que la OSI no logró hacer relevantes para las tendencias más importantes en software. Este año, eso debe terminar.
Copyright © 2024 IDG Communications, Inc.
