Pesos abiertos no es lo mismo que software abierto: qué puedes hacer de verdad con un modelo descargable

Qué es lo que te descargas

Un modelo de lenguaje entrenado es, en la práctica, un objeto de datos: un conjunto de parámetros —los números que el entrenamiento ha dejado en la red— que, combinados con una arquitectura y un código de inferencia, producen una salida a partir de una entrada. Ese archivo de parámetros es lo que la industria llama pesos (weights).

Cuando un laboratorio publica esos números para que cualquiera se los descargue y los ejecute, dice que el modelo tiene pesos abiertos. Es una descripción de lo que se entrega, no de lo que se permite con ello.

La distinción que importa

La Iniciativa por el Software Abierto (OSI), la organización que mantiene la definición de software abierto, publica una página específica para este tema. Su formulación es directa: los pesos abiertos se refieren a los pesos y sesgos finales de una red neuronal, y se diferencian del software abierto porque no incluyen:

1. El código de entrenamiento —los scripts o frameworks usados para crear y curar el conjunto de datos—.
2. El conjunto de datos de entrenamiento —cuando es posible distribuirlo legalmente—.
3. Transparencia exhaustiva sobre los datos —composición, métodos de limpieza o técnicas de equilibrado—.

Es decir: tener los pesos permite ejecutar y adaptar un modelo, pero no permite estudiar cómo se construyó. Y esa es la diferencia que separa «abierto» de «abierto del todo».

Qué exige el software abierto

La Open Source AI Definition (OSAID) 1.0, aprobada por el Consejo del OSI el 27 de octubre de 2024, exige que un sistema se distribuya en condiciones que concedan cuatro libertades: usar el sistema para cualquier propósito sin pedir permiso, estudiar cómo funciona e inspeccionar sus componentes, modificarlo para cualquier fin, incluido cambiar su salida, y compartirlo con otros, con o sin modificaciones.

Y añade un requisito previo: para poder ejercer esas libertades hace falta acceder a la forma preferente para hacer modificaciones. En el caso de un modelo eso significa, según la definición, dos cosas: información suficiente sobre los datos de entrenamiento como para que una persona con los conocimientos necesarios pueda construir un sistema sustancialmente equivalente —con la procedencia de los datos, su alcance y características, cómo se obtuvieron y seleccionaron, el etiquetado y los métodos de procesamiento y filtrado— y el código completo usado para entrenar y ejecutar el sistema, incluidos los argumentos y ajustes del entrenamiento.

Componente	Pesos abiertos	Software abierto
Pesos y sesgos	Se publican	Se publican
Código de entrenamiento	No se comparte	Se comparte
Puntos de control intermedios	Se retienen	Deseables
Conjunto de datos de entrenamiento	No se comparte	Se publica*
Composición de los datos	Parcial o no divulgada	Totalmente divulgada

(*) Cuando la distribución legal lo permite. El OSI admite excluir datos no públicos, como información personal identificable, siempre que se describan con detalle su procedencia, características, recopilación y tratamiento.

La tabla resume la idea: los pesos abiertos son un subconjunto de lo que el software abierto exige. Todo lo que cumple la definición de software abierto publica pesos; no todo lo que publica pesos cumple la definición de software abierto.

La segunda trampa: la licencia, no la etiqueta

Aun cuando un modelo cumpla la definición, queda la pregunta práctica: ¿qué puedo hacer con él en mi producto? Y ahí la respuesta está en el texto de la licencia de esa versión concreta, no en la etiqueta.

La Fundación de Software Apache mantiene una revisión de los términos de uso de herramientas generativas —las condiciones con las que se ofrece un producto o servicio de IA— contra la pregunta de si esos términos restringen la salida generada de un modo incompatible con la definición de software abierto. Conviene precisar qué es y qué no es esa página, porque es fácil malinterpretarla: no clasifica licencias de pesos, sino cláusulas de los términos de uso, y cada fila se refiere a la combinación exacta de herramienta, plan y vía de acceso. La propia página advierte de que es un documento de trabajo en revisión, no una guía aprobada de la fundación.

Aun así, su taxonomía es útil para entender el panorama, porque el mismo producto puede cambiar de categoría según el plan o la versión:

• Categoría A: los términos no imponen ninguna restricción sobre la salida generada. La propia página la delimita con precisión: solo responde a esa pregunta y no cubre otras condiciones de la guía, como el material de terceros copiado en la salida, la procedencia de los derechos de autor, la confidencialidad de lo que metes en la herramienta o la calidad del código.
• Categoría B: nada bloquea claramente la salida, pero hay una condición de manejo que forma parte de la respuesta.
• Categoría X: los términos restringen el uso o la redistribución de la salida. No se debe contribuir con salida generada bajo esos términos.

La familia no decide: la versión sí

La conclusión práctica que se desprende de esa revisión es que mirar solo la familia del modelo no basta. Dentro de una misma familia conviven licencias y planes distintos, y la diferencia puede estar entre dos tamaños del mismo modelo.

Los ejemplos de Qwen lo ilustran. En la categoría A figuran Qwen3.8-27B —Apache-2.0 sin modificaciones, según la fila revisada— y Qwen2.5-Coder en cinco tamaños (0.5B, 1.5B, 7B, 14B y 32B), con texto de licencia idéntico. Pero en la categoría X están Qwen2.5-Coder-3B y 3B-Instruct, bajo un acuerdo de investigación de Qwen que lo limita a investigación o evaluación no comercial y exige una licencia separada de Alibaba Cloud para uso comercial, además de obligar a mostrar «Built with Qwen» o «Improved using Qwen» en la documentación del producto si se usan los materiales o sus salidas para entrenar otro modelo que luego se distribuye. Y el modelo insignia de la misma familia, Qwen3.8-2.4T, tiene una licencia propia, no una licencia abierta estándar: a partir de ciertos ingresos o usuarios hay que pactar licencia con Alibaba y mostrar el nombre del modelo en la interfaz.

Qué buscar al leer una licencia

Antes de usar un modelo en un producto comercial, conviene comprobar al menos cuatro cosas:

1. Si el uso comercial está permitido y si existe un umbral de escala o de ingresos que cambie las condiciones al superarlo. Ese tipo de puertas aparece tanto en licencias de «comunidad» como en términos de uso: por encima de un número de usuarios o de unos ingresos mensuales, el uso comercial deja de estar permitido por defecto y requiere acuerdo aparte.
2. Si la licencia restringe usar las salidas del modelo para entrenar otro modelo. Esa restricción aparece en varias licencias de modelos y no tiene equivalente en las licencias clásicas de software.
3. Si hay obligaciones de atribución o de nomenclatura. Apache 2.0 y MIT exigen conservar los avisos de copyright y de licencia en las copias o partes sustanciales; algunas licencias de modelos añaden además obligaciones de mostrar el nombre del modelo en la interfaz.
4. Si la restricción depende del plan o de la versión. En los servicios es habitual: una fila de la revisión de Apache puede cubrir el plan de pago y dejar fuera el gratuito, y al contrario.

Y una quinta, que no es de licencia sino de práctica: la licencia del código puede no ser la de los pesos. Un proyecto puede tener su código en Apache 2.0 y publicar pesos con una licencia más restrictiva. Ambas hay que leerlas por separado.

Lo que no es

Tres conclusiones que no se deducen de lo anterior, y conviene no dar por sentadas:

Que un modelo tenga pesos abiertos no significa que sea gratis de ejecutar. Los pesos se descargan sin coste, pero ejecutarlos exige hardware. La factura de infraestructura es la parte relevante para muchas aplicaciones, no la de la licencia.

Que un modelo cumpla la definición de software abierto no lo hace automáticamente mejor. La apertura es una propiedad de los derechos y de la reproducibilidad, no una medida de calidad. Un modelo abierto pequeño puede ser peor que uno cerrado grande para una tarea concreta.

Que una licencia sea «abierta» no la hace inocua para tu producto. Una licencia abierta estándar puede no incluir patentes, o puede tener obligaciones de atribución que tu cadena de distribución no pueda cumplir. El texto manda.

Cómo leerlo en la práctica

Si la pregunta es «¿puedo usar este modelo en mi producto?», el orden razonable es:

1. Identificar la versión exacta de los pesos, no la familia.
2. Leer el texto de licencia de esa versión, no la etiqueta de la página de inicio.
3. Comprobar si hay umbrales de escala o de ingresos que cambien las condiciones.
4. Comprobar si hay obligaciones de atribución o de nomenclatura.
5. Verificar si la licencia restringe el uso de las salidas para entrenar otros modelos.
6. Separar la licencia del código de la de los pesos.

Ninguno de esos pasos es un formalismo: la diferencia entre una licencia permisiva y una con umbral de usuarios puede ser la diferencia entre poder desplegar un producto o tener que negociar un acuerdo aparte.

Conclusión

«Pesos abiertos» y «software abierto» describen cosas distintas: la primera dice qué se entrega, la segunda dice qué se permite y qué se puede reconstruir. La confusión no es inocua, porque lleva a elegir un modelo pensando en una libertad que la licencia no concede.

La lectura útil es práctica: para usar un modelo en local, los pesos abiertos suelen bastar; para entender cómo se construyó, evaluar sus sesgos o reconstruirlo, hace falta la definición completa; y para usarlo en un producto comercial, lo que decide es el texto de licencia de la versión exacta, con sus umbrales y sus obligaciones.

Fuentes

• Open Source Initiative — What are Open Weights?: definición de pesos abiertos, lista de lo que no incluyen y tabla comparativa con la definición de software abierto. opensource.org
• Open Source Initiative — The Open Source AI Definition 1.0: las cuatro libertades, el requisito de la forma preferente de modificación y la exigencia de información suficiente sobre los datos y de código completo. opensource.org
• Open Source Initiative — acta del Consejo del 27 de octubre de 2024, donde se recoge la aprobación formal de la Open Source AI Definition 1.0. opensource.org
• Apache Software Foundation — Generative AI Tool Terms: Review Results: clasificación de los términos de uso de herramientas en Categoría A, B y X, con filas concretas por herramienta, plan y versión. La propia página advierte de que es un documento de trabajo en revisión, no una guía aprobada, y de que cada fila se limita a la combinación exacta que nombra. apache.org
• Apache Software Foundation — Generative AI Tool Terms: What to Look For: descripción de las cláusulas que importan —propiedad de la salida, restricciones que la siguen, obligaciones de terceros, dependencia del plan— y de qué significa cada categoría. apache.org