El pionero del código abierto Bruce Perens acierta en una cosa y en la mayoría de las cosas mal en una 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”). 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: la computación en la nube y la inteligencia artificial. En 2024, necesitamos el 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. fuente con licencias como la licencia de fuente comercial, la cláusula común y la licencia pública del lado del servidor (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 creen? Pregúntele a Stefano Maffulli, director ejecutivo de la Open Source Initiative (OSI), que guía 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. Como tal, Maffulli continúa: «Realmente no prestamos atención a lo que estaba sucediendo 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 lamentable. 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? ? (Puede 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 carezca de sentido en la era de la IA Por mucho que la nube haya superado al código abierto, la IA le 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 espera preservar? En una conversación con el CEO de Aryn, Mehul Shah, analizamos esto problema del “código”. Citando extensamente ese artículo: La primera es pensar en datos de capacitación seleccionados como el código fuente de 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 decir simplemente que un modelo de lenguaje grande es de código abierto, porque ni siquiera podemos decidir todavía 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.

Source link