Qué significan realmente los LLM open source

Hace ya tiempo que aprendí que cuando una empresa grande dice que algo es open, conviene parar un segundo y preguntar: open, ¿respecto a qué?. El mundo geo aún recordamos aquel mantra de que ESRI is open, y me está pasando ahora, a otra escala, con los modelos de lenguaje. Casi cada semana aparece un anuncio de un LLM open source que, en la práctica, no lo es del todo. O no lo es en el sentido en el que quienes venimos del software libre entendemos esa palabra.

Y es que el problema no es que se liberen cosas. El problema es que se vacía el significado de una palabra que nos costó décadas construir.

Cuatro libertades, otra vez

En el software libre la brújula siempre fueron las cuatro libertades: usar el programa para cualquier propósito, estudiarlo, modificarlo y compartirlo, con o sin cambios. La Open Source Initiative tradujo esa idea a una definición práctica de licencias. No es un eslogan. Es un contrato social: si no puedes estudiar y cambiar lo esencial, no es libre aunque diga open en la caja.

Con la IA pasó lo previsible. Empezaron a circular modelos con licencias permisivas sobre los ficheros de pesos, y de ahí al titular de “modelo open source” había un paso muy corto y muy tentador. La OSI, después de un proceso largo y ruidoso, publicó la Open Source AI Definition 1.0. No inventa una filosofía nueva: aplica las mismas libertades a un sistema de IA.

Para que un sistema de IA se considere Open Source AI, tiene que permitirte usarlo, estudiarlo, modificarlo y compartirlo sin pedir permiso. Y aquí viene la parte que a mucha gente le molesta: una precondición de esas libertades es tener acceso a la forma preferida de hacer modificaciones. En software clásico eso es, básicamente, el código fuente. En aprendizaje automático no basta con un binario bonito.

De qué está hecho un modelo (y qué habría que liberar)

Un LLM no es un programa al uso. Es más bien el resultado de un proceso industrial: datos, código, cómputo y parámetros. Si uno se pregunta qué habría que liberar para que las cuatro libertades sean reales, la OSI lo deja bastante claro en tres bloques.

Información sobre los datos. No siempre se puede redistribuir el dataset entero —hay derechos de terceros, datos personales, contratos— y la definición no es ingenua al respecto. Pero sí exige información suficientemente detallada como para que una persona competente pueda construir un sistema sustancialmente equivalente: procedencia, alcance, cómo se obtuvieron y seleccionaron los datos, etiquetado, filtrado, qué partes son públicas y dónde están, qué partes se compran a terceros y a quién. Sin eso, “estudiar el sistema” se queda en mirar el escaparate.

Código. El código completo para entrenar y ejecutar el sistema. Procesado y filtrado de datos, entrenamiento con sus argumentos y ajustes, validación, librerías de apoyo, tokenizadores, código de inferencia, arquitectura. Es decir: no solo el script de demo que carga el modelo y te contesta en el terminal.

Parámetros. Los pesos y demás configuración aprendida. Idealmente también checkpoints intermedios y estado del optimizador cuando aplique. Esto es lo que la gente descarga cuando dice “me he bajado el modelo”.

Si te fijas, liberar solo el último de los tres es como publicar el ejecutable compilado y decir que el software es libre porque cualquiera puede copiar el binario. Puedes usarlo, a veces incluso adaptarlo un poco, pero no puedes reconstruir el camino. Y sin el camino, la libertad de estudiar y modificar de verdad se queda a medias.

Hay otra forma de verlo, más de oficio: el valor de un modelo grande no está solo en el fichero final. Está en la receta, en las decisiones de filtrado, en lo que se dejó fuera, en lo que se reforzó en el alineado, en los fallos que se corrigieron a mitad de entrenamiento. Esa es la parte que casi nunca se abre del todo. Y es justo la parte que permitiría auditar sesgos, reproducir resultados o mejorar el sistema desde fuera sin empezar de cero cada vez.

Entonces, ¿qué son los open weights?

Pues eso: pesos abiertos. Modelos en los que se publican los parámetros finales —a veces bajo Apache 2.0, MIT u otra licencia razonable; a veces bajo licencias propias con condiciones extra— para que cualquiera pueda descargarlos, ejecutarlos, hacer fine-tuning o montar un servicio encima.

No es poca cosa. Respecto a un modelo solo accesible por API, la diferencia es enorme. Puedes correrlo en tu máquina, no mandar tu código a un tercero, elegir el hardware, afinarlo para un dominio, o montar infraestructura propia. En un país, en una empresa o en una administración, eso cambia el tablero de la dependencia. Yo, que estos meses he estado usando modelos en local para escribir, programar y trastear con mapas, lo noto cada día: no es lo mismo alquilar inteligencia por token que tener el artefacto en casa.

Pero open weight no es open source en el sentido de la definición de la OSI. La propia OSI lo explica sin rodeos: los pesos abiertos no incluyen, por lo general, el código de entrenamiento completo ni la transparencia fuerte sobre los datos. Te dan el resultado del entrenamiento, no el proceso. Sirven para desplegar y adaptar; sirven mucho menos para reproducir, auditar de verdad o colaborar en la raíz del sistema.

Es un término útil, siempre que no se use como disfraz. El problema empieza cuando el marketing convierte “pesos abiertos” en “open source” y nos vamos acostumbrando a la trampa. Verdades a medias, otra vez: sí, es más abierto que un modelo cerrado; no, no es software libre con otro nombre.

Licencias que parecen libres (y no siempre lo son)

Aquí el software libre también tiene memoria. Hay licencias que parecen permisivas y luego meten una cláusula que rompe la libertad de uso para cualquier propósito, o la de compartir sin pedir permiso. En modelos pasa igual. Hay familias muy populares cuya licencia permite mucho… hasta que superas un umbral de usuarios o compites en cierto terreno. Otras son genuinamente permisivas sobre los pesos, y aún así el entrenamiento sigue siendo secreto industrial.

Desde el punto de vista ético del software libre, la pregunta no es solo “¿puedo descargarlo?”. Es “¿puedo usarlo para lo que me dé la gana, entender cómo se hizo, cambiarlo de verdad y pasar ese cambio a otra persona sin negociar con el dueño original?”. Si alguna de esas puertas está cerrada o solo entreabierta, llamarlo open source es, como mínimo, un abuso del diccionario.

Y conste que el modelo de negocio de no abrir el entrenamiento es lícito. Faltaría más. Igual que es lícito vender software privativo. Lo que no me parece de recibo es apropiarse del prestigio moral y técnico que el movimiento libre construyó, para vender como libertad lo que en realidad es una distribución controlada de un artefacto.

Por qué importa, más allá del purismo

Se puede pensar que esto es discusión de puristas. Yo creo que no. Cuando una administración pública o una empresa estratégica apuesta por un modelo “abierto”, la letra pequeña decide si estás reduciendo dependencias o solo cambiando de dueño. Si solo tienes pesos, puedes ejecutar y adaptar; si mañana necesitas reentrenar desde una base auditable, entender un fallo sistemático o demostrar cómo se construyó el sistema, te encuentras otra vez pidiendo permiso o reinventando la rueda.

En software libre aprendimos que la conveniencia mueve más que la filosofía. Por eso el statu quo siempre es frágil. Ahora mismo conviene a bastantes actores soltar pesos y quedarse el resto: ganan adopción, narrativa de apertura y una comunidad que mejora el producto en la capa de arriba, sin tocar la fábrica. Es un avance respecto al secretismo total. También es un techo de cristal si nos dormimos en la etiqueta.

A mí los pesos abiertos me parecen una buena noticia, y los uso. Me parece mejor un Llama, un Qwen, un Gemma o un DeepSeek descargable que un muro de API con términos que cambian cada trimestre. Pero no confundo el alivio con la llegada a destino. Open weight es un paso. Open source AI, de verdad, es otra cosa.

Mientras tanto, en los despachos

Y mientras debatimos esto en blogs y foros, gobiernos y agencias de supervisión de la IA hablan sin parar de ética, de confianza, de IA centrada en las personas. La pregunta es en qué se están fijando de verdad.

La respuesta, simplificando, es casi siempre la misma: en el uso. El Reglamento europeo de IA es el ejemplo más claro. Clasifica sistemas por riesgo, prohíbe prácticas inaceptables, exige supervisión humana, documentación, trazabilidad, etiquetado de contenido generado y, para los modelos de propósito general, transparencia y ciertas obligaciones sobre derechos de autor y seguridad. La Oficina Europea de IA y, aquí en España, la AESIA, nacen sobre todo para vigilar eso: que no se despliegue cualquier cosa en sanidad, empleo, fronteras o justicia; que la ciudadanía sepa cuándo habla con una máquina; que haya alguien a quien reclamar cuando el sistema falla.

Todo eso es necesario. Faltaría más. Un modelo libre mal usado también puede hacer daño, y el derecho a no ser discriminado por un algoritmo no se resuelve solo con una licencia OSI. Pero si miras el tablero con gafas de software libre, se ve el hueco enseguida: se regula el comportamiento del sistema en producción mucho más que la libertad de estudiarlo y reconstruirlo.

Cuando el reglamento pide un resumen público del contenido de entrenamiento de los modelos de propósito general, no está pidiendo el dataset ni la receta completa. Pide un mapa a grandes rasgos: fuentes, dominios, algo de procesado. Útil para ejercer derechos y para periodistas o investigadores con paciencia. Insuficiente para lo que la OSI llama la forma preferida de hacer modificaciones. Transparencia de cumplimiento no es lo mismo que apertura radical. Se parece más a la ficha técnica de un electrodoméstico que al código fuente de un compilador.

Lo mismo pasa con buena parte de las estrategias nacionales y de las “agencias de IA ética”. El centro de gravedad está en el riesgo del despliegue, en la gobernanza del proveedor, en la evaluación de impacto, en no comprar sistemas prohibidos. Casi nunca en exigir —ni siquiera en priorizar de verdad en la compra pública— modelos que uno pueda auditar de extremo a extremo, reentrenar con datos propios o mantener sin volver a pasar por caja del fabricante. Se habla de soberanía tecnológica, y a veces se financia un modelo europeo “abierto”; luego, al mirar la letra pequeña, vuelves a encontrarte pesos, licencias a medias y poca fábrica a la vista.

No es que no se mueva nada. Hay iniciativas de modelos abiertos con dinero público, hay excepciones o tratos más suaves para ciertos sistemas de código abierto en el propio reglamento, hay gente dentro de la administración que entiende la diferencia. Pero la corriente principal sigue siendo otra: ética del uso, no ética de la libertad del artefacto. Como si bastara con poner guardarraíles al coche sin preguntar si podemos abrir el capó, fabricar recambios o enseñar a otra persona a arreglarlo.

Desde el mundo del software libre, esa frontera es vieja. Llevamos años diciendo que no basta con que el programa “haga las cosas bien” si no puedes mirar cómo las hace y cambiarlas cuando dejen de hacerlas bien. Con la IA el argumento se vuelve más urgente, no menos: si el Estado y las agencias se conforman con fichas de transparencia y evaluaciones de riesgo sobre cajas negras —aunque sean cajas negras con pesos descargables—, estaremos domesticando el relato ético sin acercarnos de verdad a modelos que se parezcan al software libre.

En nuestras manos está, también como ciudadanía y como sector técnico, empujar la conversación un poco más lejos. No solo ¿se usa bien esta IA?, sino ¿podemos estudiar, modificar y compartir de verdad el sistema con el que nos gobiernan o nos atienden?. Porque si la respuesta es no, la ética se queda en el manual de instrucciones. Y el manual, ya se sabe, lo escribe quien tiene la llave de la fábrica.