En la década de 2000, hablábamos mucho sobre el código abierto, tal vez demasiado. Discutimos sobre si importaba más la libertad de código (GPL) o la libertad de desarrollador (Apache/BSD). Nos preguntamos cuándo llegará finalmente el año del escritorio Linux. (TL; DR nunca. O tal vez sea ya pasó. O… lo que sea.) Reprendimos a las empresas por “lavado abierto” (anticipando los años de lavado de la nube y la IA que vendrán). Debatimos”núcleo abierto“Modelos de negocio.
En la década de 2010, el código abierto pasó a un segundo plano y se convirtió en una infraestructura esencial para todos los desarrolladores y empresas del planeta, lo supieran o no. Claro, tuvimos erupciones esporádicas de puños agitados hacia los gigantes de las nubes durante minería a cielo abierto fuente abierta, y la gente hizo fervientes peticiones por una fuente abierta sostenible (aun cuando demostraba no hay signos de agotarse), pero sobre todo dejamos el código abierto en un segundo plano de nuestras mentes, incluso cuando se volvió fundamental para casi todo lo que hacemos.
Hasta ahora. El código abierto vuelve a ser una prioridad, dada su aparente importancia para garantizar que la IA no sea controlada por unas pocas empresas, sin mencionar La reciente decisión de Redis para cambiar su licencia. El problema es que el código abierto no se ha mantenido al día con las tendencias tecnológicas. Hay no existe nada parecido a la “IA de código abierto” por ejemplo, por mucho que algunos pretendan lo contrario. Y todavía no existe una buena licencia de código abierto para la nube. Necesitamos aprovechar este momento de código abierto para asegurarnos de que sea adecuado para el futuro, pero ¿cómo podemos hacerlo de manera justa?
Quedando atrás
He escrito bastante recientemente sobre estos temas, motivado inicialmente por la dificultad de aplicar licencias que cumplan con la definición de código abierto a la inteligencia artificial. Como Mike Linksvayer, jefe de política de desarrolladores en GitHub, dice: «No existe una definición establecida de qué es la IA de código abierto». Cada vez que escuchamos a alguien proclamar con confianza que un modelo de lenguaje grande es o no de código abierto, vale la pena preguntarse cómo pueden estar tan seguros cuando incluso el director ejecutivo de la Open Source Initiative (OSI), Stefano Maffulli, reconoce que el código abierto para la IA de ninguna manera está resuelto: «Definitivamente tenemos que repensar las licencias de una manera que aborde las limitaciones reales de los derechos de autor y los permisos en los modelos de IA, manteniendo al mismo tiempo muchos de los principios de la comunidad de código abierto».
La OSI espera tener orientación para octubre, pero hasta entonces, cualquiera que pretenda tener una certeza absoluta sobre qué es o no código abierto en IA está haciendo precisamente eso: fingir.
Para ser claros, no creo que OSI cambie radicalmente el OSD para la IA (o la nube). No veremos de repente luz verde a la discriminación en los ámbitos de actividad, por ejemplo. Espero que el carácter esencial del software de código abierto se mantenga, incluso cuando adquiramos claridad sobre cómo aplicar el OSD a cosas como números de punto flotante, datos de entrenamiento y pesos.
Espero que también veamos a OSI volver a visitar la nube, ya que creo que su fracaso en aplicar el OSD a la distribución de software en la nube es la razón principal por la que hemos visto a tantas empresas recurrir a licencias de fuente disponible. Veamos por qué es así.
La extraña ironía del copyleft
Cuando Richard Stallman creó la Licencia Pública General GNU (GPL), lo hizo para proteger la libertad del código y garantizar que el código siguiera siendo gratuito para los usuarios de software. Podías realizar cambios en el código, pero si lo hacías, tenías que ponerlos a disposición. No se podía bloquear el código detrás de las licencias propietarias. Más tarde, para hacer que el software libre fuera más aceptable para las corporaciones, un grupo acuñó “código abierto” y nació una nueva clase de licencia que decía, esencialmente, “Haz lo que quieras con este código”.
Pero había una extraña ironía en todo esto. En 2004, escribí: “Estamos sentados en el modelo de negocios de TI más emocionante que el capitalismo haya visto jamás, todo gracias a la GPL”. Unos años despues Dupliqué ese sentimiento y escribí, «La mayoría de las empresas de código abierto exitosas… utilizan la GPL». Como concluí, «la GPL, contrariamente a la creencia popular, facilita el negocio de software comercial».
¿Stalman pretendía esto? No. Pero eso no importa. Lo que importa es el texto de la licencia y su poder para proteger el código y la libertad del usuario (ah, y generar dinero en efectivo).
Curiosamente, la licencia que trabajó más duro para proteger el código y la libertad del usuario también resultó ser la licencia que más permitió a las empresas construir negocios exitosos, desde Red Hat hasta MySQL. Sin embargo, una vez que llegó la nube, la GPL perdió toda potencia y el hack de Affero GPL hizo poco para sostenerla. Fue un compromiso pobre que no logró proteger el código/la libertad del usuario y no logró dar a las corporaciones la confianza de que podrían usarlo. (Sin embargo, permitió a las empresas de la nube ganar miles de millones monetizando un suministro constante de software gratuito y de código abierto al que contribuyen poco o nada. ¡Qué ganga!)
En este punto, algunos lectores gritan: “¡Pero a esas llamadas empresas de código abierto no les importa la libertad del código! ¡¡Solo les importa el dinero!!
Más código libre, más bueno
¿Eso importa? ¿Importa aunque sea un poquito? No es asi. Si el código es gratuito, el usuario intermedio puede tomarlo, usarlo, modificarlo y distribuirlo, siempre que mantenga el código libre y abierto. Como dice la licencia, “Debe hacer que cualquier trabajo que distribuya o publique, que en su totalidad o en parte contenga o se derive del Programa o cualquier parte del mismo, sea licenciado en su totalidad sin costo alguno para todos los terceros bajo el términos de esta Licencia”. ¿Por qué a alguien le importarían las motivaciones detrás del uso de la licencia, siempre y cuando el resultado final (libertad de código) permanezca?
Estoy convencido de que si una empresa hoy escribiera la GPL exactamente como Stallman la escribió hace décadas (palabra por palabra idéntica), sería rechazada por la OSI. ¿Por qué? Porque la gente diría (probablemente correctamente) que la intención detrás de las palabras era diferente. ¿Pero eso debería importar? ¿No debería ser el estándar el texto de la licencia (que persiste mucho después de que las intenciones hayan cambiado)? ¿No deberíamos estar agradecidos por el software libre, sin importar por qué se le concedió la licencia como tal?
En 2007, Charlie Babcock escribió, “Una de las grandes ironías de la GPL, 17 años después de su creación, es que se ha convertido en una creadora descarada de empresas que compiten eficazmente”. Podemos retorcernos las manos sobre si empresas como MySQL (en su día) utilizaron la GPL con fines amantes de la libertad o si sirvió para un fin corporativo, pero en 2024 agradezcamos que 30 años después de que comenzara el desarrollo de MySQL, todavía podamos Úselo como software gratuito, gracias a la GPL.
Necesitamos volver a hacer real el copyleft, actualizando o creando una nueva licencia aprobada por OSI para la nube. Esto satisfará las necesidades de aquellos en el campo de Stallman que quieren libertad de código, así como también de las personas corporativas que quieren un negocio fuerte (lo que, a su vez, impulsa el desarrollo de más código). Ah, también satisface las necesidades de aquellas personas a las que les gusta la libertad de códigos y también les gusta pagar el alquiler. De cualquier manera, todos ganamos porque tendremos más software gratuito y de código abierto.
Copyright © 2024 IDG Communications, Inc.