La IA open source casi nunca es open source
A comienzos de agosto, Meta publicó los pesos de Muse Glimmer 30B bajo una licencia Apache 2.0 genuina, abandonando el formato de licencia comunitaria que la OSI había rechazado para la familia Llama. En el mismo repositorio hay un archivo aparte: USAGE_POLICY.md. Stefano Maffulli, que condujo a la OSI durante la definición de la IA de código abierto, preguntó en público qué es jurídicamente ese documento. «Lawyers?», escribió. Este texto es, entre otras cosas, una respuesta a esa pregunta.
Es probablemente el término más manoseado de los últimos tres años en tecnología. Empresas que jamás liberarían una línea de su código anuncian modelos open source con la solemnidad de quien dona una biblioteca. Conviene aplicarle a la etiqueta el mismo rigor que esta serie le ha aplicado a todo lo demás. El resultado no sobrevive al análisis.
Empecemos por la distinción técnica que ordena todo: publicar los pesos de un modelo equivale a distribuir el binario, no el código fuente. La definición clásica de código fuente, que Rosen repite en cada licencia que analiza, es la forma preferida de la obra para hacerle modificaciones. Para un modelo de IA, esa forma preferida no son los pesos: son los datos de entrenamiento (o información suficientemente detallada sobre ellos), el código de entrenamiento y la receta completa (hiperparámetros, procesamiento de datos, decisiones de filtrado). Con los pesos puedes ejecutar el modelo y afinarlo; no puedes reproducirlo, auditarlo a fondo ni estudiar por qué hace lo que hace. Es exactamente la posición del usuario de software propietario con un ejecutable gratuito: útil, pero no es libertad.
La Open Source Initiative, custodia de la definición desde 1998, publicó en octubre de 2024 su definición de IA open source (la OSAID 1.0) tras dos años de proceso público. La estructura replica las cuatro libertades clásicas (usar, estudiar, modificar y compartir el sistema, para cualquier propósito y sin pedir permiso), con la precondición de siempre: acceso a la forma preferida para hacer modificaciones. Exige tres componentes, cada uno bajo términos aprobados por la propia OSI. Información de datos: la descripción completa de todos los datos de entrenamiento, incluidos los que no pueden compartirse, con su procedencia, forma de obtención y selección, etiquetado, procesamiento y filtrado, más el listado de los datos disponibles pública o comercialmente y dónde obtenerlos. Código: el de entrenamiento, procesamiento de datos e inferencia, completo. Y parámetros: los pesos y configuraciones. El criterio rector es la reproducibilidad: que una persona competente pueda construir un sistema sustancialmente equivalente. Dos detalles del texto valen oro para quien siguió esta serie: la definición admite expresamente que estos componentes se licencien con condiciones de reciprocidad (el copyleft sobrevive al salto a la IA), y aclara que hablar de modelos o pesos open source exige acompañarlos de los datos y el código que los produjeron. Los pesos solos no pueden llevar el nombre. Es un estándar exigente y fue inmediatamente controvertido: la Free Software Foundation y la Software Freedom Conservancy objetaron públicamente el compromiso de permitir describir los datos en lugar de publicarlos, un debate que sigue abierto y que es sano que lo esté. Pero fija una vara, y las varas sirven para medir.
La OSI ya no está sola en esto. La Linux Foundation mantiene el Model Openness Framework, que clasifica los lanzamientos por grados verificables de apertura; su clase superior, Open Science, exige el código, los datos (o una documentación auditable de ellos) y las herramientas completas, no solo los pesos. Stanford HAI adoptó esa vara como estándar institucional, con una formulación de James Landay que resume el problema mejor que cualquier tecnicismo: los pesos abiertos responden la pregunta de si puedo ejecutar esto; el open source responde si puedo confiar en esto, mejorarlo y construir lo que viene encima. Publicar pesos, dice Landay, no es un modelo abierto: es distribución abierta. Y casi todos los laboratorios, estadounidenses y chinos por igual, responden hoy la primera pregunta y están lejos de la segunda.
Que existan dos varas ya dice algo; que existan tres lo confirma: en enero de 2025 la Open Source Alliance publicó su propia Open Weight Definition, un enfoque desagregado que evalúa por separado datos, pesos y modelo, respaldado por voces como OpenUK y criticado desde la OSI por duplicar lo que el MOF ya cubría. Y hay una cuarta pieza que juega otro juego: el marco del Columbia Convening (Camille François y coautores, publicado en Communications of the ACM), que describe la apertura como un gradiente por componentes a lo largo de todo el stack, del dato al despliegue, y se niega deliberadamente a fijar requisitos. Conviven así tres filosofías de definición: la línea binaria de la OSAID sirve para certificar y eximir; los niveles del MOF, para comparar; las dimensiones de Columbia, para analizar. El mapa analítico y la frontera legal no son lo mismo, y confundirlos es el error típico del regulador apurado. La conclusión estructural importa más que el marcador del partido: la autoridad para definir qué cuenta como abierto es, en sí misma, una disputa de gobernanza, y la definición que prevalezca determinará exenciones regulatorias y ventajas de mercado. De eso trata la entrega 9.
Midamos el caso más publicitado. La licencia de los modelos Llama de Meta contiene una cláusula que niega la licencia a empresas con más de 700 millones de usuarios activos mensuales (discriminación por identidad del licenciatario), una política de usos aceptables que prohíbe campos enteros de aplicación (discriminación por campo de actividad) y restricciones sobre el uso de las salidas para entrenar otros modelos. Cada una de esas cláusulas viola frontalmente los principios que Rosen enumera en su primer capítulo y que la definición open source consagra: sin discriminación contra personas o grupos, sin discriminación contra campos de actividad, uso libre para cualquier propósito. La licencia de Llama es una licencia comercial inusualmente generosa. No es open source, y llamarla así tiene un nombre: openwashing. El término no es una ocurrencia mía: la propia OSI declara que combatir el openwashing es una de las tres razones de existir de la definición. Y el ejercicio de validación que acompañó a la OSAID puso nombres sobre la mesa, con resultados que conviene citar completos porque muestran que el problema excede a Meta. No pasan: Llama 2, Grok de X, Phi-2 de Microsoft y Mixtral de Mistral, por componentes faltantes o términos legales incompatibles con los principios. Pasan: Pythia (EleutherAI), OLMo (Allen Institute), Amber y CrystalCoder (LLM360) y T5 (Google). Y pasarían con solo corregir sus términos legales: BLOOM, Starcoder2 y Falcon. La OSI advierte que son aprendizajes del proceso de definición y no certificaciones, pero el mapa queda dibujado: los modelos que cumplen existen, y su relativa oscuridad frente a los que no cumplen demuestra que la etiqueta se disputa por marketing, no por precisión.
Y la presión funciona, aunque con letra chica nueva. Volvamos al repositorio de Muse Glimmer: la licencia es Apache 2.0 genuina, sin topes de usuarios ni restricciones de campo. Es una victoria de la batalla definicional, y conviene reconocerla como tal. Pero la frontera del problema se movió: junto a la licencia estándar viaja un documento separado de política de uso (no dañes, cumple la ley, no menores de 18). Jurídicamente todo depende de la incorporación. Si la licencia no condiciona la concesión al cumplimiento de la política, el documento es una declaración de deseos sin efecto vinculante, incapaz de recortar derechos ya concedidos; si la condicionara, dejaría de ser Apache 2.0 en sustancia, porque las restricciones de uso violan los mismos principios de siempre. Y hay un matiz técnico delicioso: aunque el clic de descarga cree un contrato con quien descarga, la estructura de Apache 2.0 concede a cada receptor posterior su licencia directamente de los contribuyentes, así que la política obliga al que hizo clic y se evapora en la primera redistribución. No puede viajar con los pesos. Su función real no es vincular licenciatarios: es mostrar diligencia ante los reguladores en la era del AI Act. Señalización de cumplimiento, no propiedad intelectual. Creative Commons acaba de decirlo con honestidad institucional en su guía sobre licencias CC en la era de la IA: sus licencias siguen valiendo tal cual, pero la licencia por sí sola no puede gobernar el uso por máquinas, y para expresar expectativas sobre usos en IA construyó CC Signals, una capa de señales explícitamente separada de la licencia y sin pretensión de vincular a nadie. Es la versión transparente de lo que las políticas de uso anexas hacen disfrazándose de obligación. Mientras tanto, el modelo sigue sin datos ni pipeline de entrenamiento: la licencia mejoró, los componentes no, y bajo la OSAID sigue siendo pesos abiertos, no open source. La licencia es condición necesaria; nunca fue suficiente.
La etiqueta importa porque empezó a tener consecuencias regulatorias. El AI Act europeo otorga un tratamiento diferenciado a los modelos publicados bajo licencias libres y de código abierto. Si la categoría legal termina incluyendo licencias como la de Llama, la exención se convierte en un subsidio al openwashing; si exige el estándar OSAID, casi ningún modelo comercial califica. La definición es la política. Volveremos sobre esto en la entrega 9.
Y hay una capa previa que en América Latina casi nadie discute: la legalidad del entrenamiento mismo. Mark Lemley y otros han construido en Estados Unidos la doctrina del fair learning: entrenar sobre obras protegidas sería fair use porque el modelo aprende patrones estadísticos, no expresión. Los tribunales estadounidenses lo están decidiendo caso a caso, y el 1 de septiembre el propio Departamento de Justicia tomó partido en el litigio del New York Times contra OpenAI: el entrenamiento es fair use, dijo, porque exigir licencias dañaría la competitividad y la seguridad nacional. Léase bien: la potencia que no legisla sobre esto tampoco lo deja al azar; lo decide como política industrial. La Unión Europea tiene excepciones expresas de minería de textos y datos, con derecho de exclusión de los titulares; Japón tiene una excepción amplia desde 2018. ¿Chile? Nada. Ni excepción TDM, ni fair use, ni doctrina. Lo mismo en casi toda la región. La consecuencia es doble: entrenar localmente sobre datos no licenciados es una zona gris que ningún marco open resuelve, y el riesgo, una vez más, se administra por la vía contractual, con todo lo que eso implica en costos y asimetrías. Es una desventaja competitiva autoimpuesta de la que hablaremos en la entrega final.
Actualización del 19 de septiembre. Quince días después de esa intervención del Departamento de Justicia llegó la pregunta que sí pertenece a esta serie. El 16 de septiembre, el Noveno Circuito de Estados Unidos confirmó el rechazo de la demanda de programadores de código abierto contra GitHub, Microsoft y OpenAI por Copilot y Codex: el litigio más grande sobre entrenamiento con código abierto en la historia del país, con más de 9.000 millones de dólares reclamados. La base era el artículo 1202(b) de la Digital Millennium Copyright Act, que sanciona remover de una obra existente su información de gestión de derechos de autor (autor, aviso de copyright, términos de licencia). El tribunal concluyó que Copilot no removió esa información: generó código nuevo que nunca la tuvo. Sin copia, no hay remoción.
Dos matices que la cobertura dejó afuera. Los demandantes también habían planteado que la infracción ocurrió antes, al despojar el código de sus avisos de licencia para usarlo como dato de entrenamiento; esa tesis, la única que de verdad toca el entrenamiento, ni siquiera fue resuelta: se dio por abandonada, porque el abogado no la sostuvo con claridad en primera instancia. La pregunta sigue completamente abierta, a la espera de un litigante más cuidadoso. Y las demandas por incumplimiento de las licencias como contrato (GPL, MIT, Apache), la misma arquitectura licencia como contrato de la segunda entrega de esta serie, siguen vivas en el tribunal de distrito. El fallo más citado del año sobre IA y código abierto todavía no ha resuelto la pregunta que la mayoría cree que zanjó.
Actualización del 21 de septiembre. Creative Commons acaba de reconocer el límite de su propio invento. En una reflexión sobre estos años, admite dos cosas: que el copyright, por sí solo, no puede darles el equilibrio que necesitan, y que los laboratorios de IA tratan cualquier condición voluntaria (un "sí, si..." o un "no, salvo...") como un "no" liso y llano, sin siquiera negociarla. Por eso exploran ahora, de forma experimental y sin nada construido todavía, una herramienta legal distinta del copyright para condicionar el acceso masivo a colecciones de datos. La organización que mejor entiende de licencias abiertas en el mundo llega, por su cuenta, al mismo diagnóstico que este texto: una señal sin consecuencia jurídica se parece más a un deseo que a una norma, y quien de verdad quiera gobernar el entrenamiento de modelos va a necesitar algo con más dientes que el copyright y sus señales.
Mientras tanto, el test práctico. Cuando lean que un modelo es open source, tres preguntas: ¿publicaron los datos o información verificable sobre ellos? ¿Publicaron el código de entrenamiento? ¿La licencia restringe usos o usuarios? Casi siempre, las tres respuestas juntas demuelen la etiqueta en menos de un minuto.
Próxima entrega: la geopolítica de los pesos abiertos, o por qué la generosidad de DeepSeek no es generosidad.