Pesos abiertos vs IA de código abierto: lo que realmente significan las etiquetas

"Open source AI" es la frase más sobrecargada en el campo. Se aplica a modelos que puedes descargar y ejecutar, a modelos con papers publicados, y ocasionalmente a una API alojada con una capa gratuita. Las distinciones importan, porque determinan lo que tus abogados te permitirán distribuir.

Tres cosas diferentes que la gente quiere decir

Pesos abiertos. Los parámetros entrenados se publican para descargar. Puedes ejecutar el modelo en tu propio hardware, inspeccionar los números, afinarlo y servirlo sin llamar a la API de nadie. Si puedes hacerlo comercialmente depende totalmente de la licencia adjunta.

Código abierto (el estándar real). Una licencia que cumpla con la Definición de Código abierto: libertad para usar con cualquier propósito, estudiar, modificar y redistribuir, sin restricciones sobre quién puede usarla o con qué. Apache-2.0, MIT y BSD cumplen. Licencias personalizadas que prohíben ciertos usos no lo hacen, aunque esas prohibiciones puedan parecer razonables.

Investigación abierta. Un paper, y quizá código de evaluación, sin pesos en absoluto. Útil para leer, imposible de desplegar.

Un modelo puede ser cualquier combinación de estas. La mayoría de los lanzamientos “abiertos” en titulares son pesos abiertos con una licencia personalizada y investigación abierta — no código abierto.

Qué suele añadir las licencias personalizadas

Las condiciones suelen ser suaves y a veces decisivas. Observa:

• Políticas de uso aceptable. Listas de aplicaciones prohibidas, incorporadas a la licencia por referencia y revisables por el editor.
• Umbrales de escala. Una cláusula que requiere un acuerdo separado por encima de un número determinado de usuarios activos mensuales. Irrelevante para una startup, potencialmente bloqueante para una plataforma grande.
• Atribución y nombres. Requisitos de mostrar "Construido con X" o de prefijar el nombre de un modelo derivado con el nombre del modelo base.
• Propagación de licencias derivadas. Las versiones afinadas deben distribuirse bajo la misma licencia.
• Restricciones de salida. Cláusulas que limitan el uso de las salidas del modelo para entrenar modelos competidores. Aparecen tanto en licencias de pesos abiertos como en los términos de API alojada.

Nada de esto es inusual en licenciamiento de software. El problema es que la palabra "open" implica que none of it applies.

Por qué la distinción no es pedantería

Tres situaciones concretas donde muerde:

White-labelling. Si revendes un producto construido sobre un modelo cuya licencia requiere nombrar el modelo base, tu oferta de white-label no es realmente sin marca.

Contaminación copyleft. Un número pequeño de componentes de IA se distribuyen bajo AGPL. En un producto alojado, la cláusula de red de AGPL puede obligarte a publicar tu propia fuente. Es una decisión de licenciamiento con consecuencias de producto, y debe tomarse deliberadamente.

Procuración. Los compradores corporativos y del sector público piden cada vez más una lista de materiales de software que nombre cada modelo y su licencia. Decir "es código abierto" no sobrevivirá a esa revisión si el archivo de licencia lo contradice.

Las preguntas que vale hacer antes de construir

1. ¿Qué archivo de licencia acompaña a los pesos? No la entrada del blog — el archivo en el repositorio.
2. ¿Puedo usarlo comercialmente, sin umbral? Si hay un límite de usuarios, modela tu crecimiento contra él.
3. ¿Puedo afinar y redistribuir? ¿Bajo qué licencia debe publicarse el resultado?
4. ¿Puedo usar las salidas libremente? Incluyendo para entrenar o destilar otro modelo.
5. ¿Aplica una política de uso aceptable, y puede cambiar? Una política incorporada por referencia puede revisarse después de que implementes.
6. ¿Qué dice la tarjeta del modelo sobre los datos de entrenamiento? No para confort legal — rara vez hay — sino para que sepas qué no puedes afirmar sobre la procedencia.

Qué "open" te compra sin importar la etiqueta

Incluso bajo una licencia de comunidad restrictiva, los pesos descargables entregan cosas que una API alojada no puede:

• Residencia de datos. El texto nunca sale de tu infraestructura. Para sectores regulados esto suele ser el factor decisivo.
• Estabilidad de versiones. El modelo no cambia bajo tus pies. Tus evaluaciones permanecen válidas.
• Estructura de costos. Intercambias precios por token por hardware que controlas — generalmente peor en bajo volumen, mejor en alto volumen estable.
• Inspeccionabilidad. Puedes examinar activaciones, cuantizar, podar y medir comportamiento de formas que una API prohíbe.

Esas ventajas son reales y por eso los lanzamientos de pesos abiertos importan, sea cual sea la licencia. Solo no dejes que la palabra de marketing suplante la lectura de los términos — y cuando escribas sobre un modelo, di "pesos abiertos" cuando eso es lo que quieres decir.