Licencias en visión computacional: qué modelos puedes usar comercialmente (y cuáles te obligan a abrir tu código).

La historia se repite en cada proyecto de visión: se elige el modelo por precisión y velocidad, se llega a producción... y recién ahí alguien lee la licencia. Con los YOLO de Ultralytics eso significa descubrir que la AGPL-3.0 te obliga a liberar el código de tu producto completo — o a comprar una licencia Enterprise cuyo precio ni siquiera es público^[1]. Aquí va la guía que me hubiera gustado tener: tipos de licencia, las tres capas que casi nadie revisa, una tabla verificada modelo por modelo, y cuándo conviene entrenar el tuyo.

Las cuatro familias de licencias_

Permisivas (MIT, Apache-2.0, BSD). Uso comercial libre, código cerrado permitido, solo piden atribución. Apache-2.0 añade una concesión explícita de patentes — por eso es la preferida para productos^[2].

Copyleft (GPL-3.0).Si distribuyes software que incluye código GPL, debes liberar el conjunto bajo GPL. Durante años el SaaS fue el "hueco": si el software corre en tu servidor y nunca lo distribuyes, la obligación no se activa.

Copyleft de red (AGPL-3.0). Cierra ese hueco: basta que usuarios interactúen con tu software por la red para que debas ofrecer el código fuente completo de tu versión. Es la razón por la que muchas empresas la evitan por política — Google directamente la prohíbe en su infraestructura^{[10] [11]}.

Personalizadas ("open-ish").La tendencia 2025–2026: licencias propias con permiso comercial condicionado. Meta pasó SAM de Apache-2.0 a una "SAM License" propia y DINOv3 salió con acceso registrado^{[5] [6]}; Gemma ata a sus términos incluso a los modelos destilados a partir de él^[13]. Con estas licencias no hay atajo: se lee el texto completo.

Las tres capas: código, pesos y datos_

El error más caro en licenciamiento de visión es revisar solo la licencia del repositorio. En realidad hay tres capas independientes:

1. El código. La que aparece en GitHub. YOLO-NAS es Apache-2.0 aquí... y solo aquí^[7].
2. Los pesos preentrenados.Pueden tener SU propia licencia: los pesos de YOLO-NAS prohíben "cualquier uso comercial o en producción"^[7], y en Depth Anything V2 el checkpoint Small es Apache-2.0 pero Base/Large/Giant son CC-BY-NC-4.0 (no comercial) — en el mismo repo^[8].
3. Los datos de entrenamiento. ImageNet se otorga solo para investigación no comercial, y un estudio académico que revisó los datasets públicos más usados no encontró ningunocuya licencia autorice explícitamente comercializar un modelo entrenado con él. Si esa restricción "contamina" al modelo es una pregunta legal abierta — pero es un riesgo documentado^[12].

La tabla: modelo por modelo, verificado_

Licencias verificadas en los repositorios y páginas oficiales en agosto de 2026. El semáforo responde una sola pregunta: ¿puedo usarlo en un producto comercial de código cerrado sin pagar?

Dos lecturas rápidas: para detección comercial sin fricción, la ruta corta es RT-DETR, RF-DETR, D-FINE o YOLOX (Apache-2.0)^{[2] [3]}; y las licencias se mueven en ambas direcciones — DINOv2 pasó de no-comercial a Apache^[4] pero YOLOv5 pasó de GPL a AGPL^[1]. Guarda una copia fechada de la licencia con la que descargaste el modelo.

AGPL y la zona gris de los pesos_

Ultralytics sostiene la interpretación más amplia posible de la AGPL: usar su código, sus pipelines de entrenamiento o pesos entrenados/afinados con ellos te obliga a liberar todo tu proyecto — incluso en uso interno — salvo que compres Enterprise^[1]. Pero esa es la postura del vendedor, no jurisprudencia: no encontré ningún caso judicial que la haya probado.

Los abogados especializados son más cautos. Kyle Mitchell apunta que la AGPL ni siquiera usa el término "obra derivada" — es lenguaje de copyright superpuesto al texto de la licencia^[10]. Y Denis Dorotenko concluye que si solo usas las salidas de un modelo AGPL (por ejemplo, para destilar), las obligaciones plausiblemente no se activan... aunque no hay respuesta definitiva en ninguna jurisdicción^[9]. Traducción práctica: la incertidumbre es el costo. Si tu producto no puede permitirse esa ambigüedad, elige Apache/MIT desde el día uno.

Checklist antes de adoptar un modelo_

1. Revisa las tres capas: licencia del código, licencia de los pesos y restricciones del dataset de origen^{[7] [8] [12]}.
2. Para producto comercial, prefiere Apache-2.0 o MITen código Y pesos; trata AGPL como "abrir todo o pagar"^{[1] [2]}.
3. Con licencias personalizadas (SAM 3, DINOv3, Gemma), lee el texto completo: umbrales, cláusulas de derivados y restricciones de uso que viajan con el modelo^{[5] [6] [13]}.
4. Archiva la licencia fechada al momento de la descarga: cambian en ambas direcciones (DINOv2 mejoró, YOLOv5 empeoró)^{[1] [4]}.
5. Si afinas (fine-tuning), recuerda que los pesos resultantes heredan la licencia de los pesos base — afinar YOLO-NAS no lo vuelve comercial^[7].
6. Documenta la decisión: qué modelo, qué licencia, qué capa revisaste y quién la aprobó. Es lo primero que pedirá un cliente corporativo (o su abogado).

¿Modelo de terceros o entrenar el propio?_

La licencia es una variable más de una decisión mayor. La comparación honesta:

La regla práctica que citan los que construyen esto a diario: problema genérico (conteo de personas, placas, EPP) → modelo preentrenado permisivo; dominio específico (tu producto, tu defecto de fábrica, tu cultivo) → fine-tuning sobre una base permisiva con datos propios. El patrón ganador casi siempre es híbrido: backbone preentrenado + afinado con tus datos^[16].

Cómo mejorar el sistema (sin comprometer la licencia)_

• Transfer learning / fine-tuning. Partir de pesos preentrenados evita reaprender lo básico (bordes, texturas): con decenas o pocos cientos de imágenes propias ya se afina un detector útil — sobre una base Apache/MIT para que el resultado sea tuyo^{[2] [16]}.
• Active learning. En lugar de etiquetar todo, el modelo señala las muestras donde más duda y solo esas van al etiquetador: menos costo de anotación por punto de precisión ganado^[15].
• Datos sintéticos. Gartner proyecta que el 75% de los datos de proyectos de IA serán generados sintéticamente en 2026 — útil para clases raras (accidentes, defectos) que no puedes fotografiar mil veces... con la advertencia de que también predice fallas de gestión de esos datos en la mayoría de equipos^[14].
• Destilación, con cuidado legal. Entrenar un modelo pequeño con las salidas de uno grande funciona técnicamente, pero el terreno legal varía por licencia: con AGPL es zona gris^[9], y licencias como Gemma la prohíben explícitamente al definir los modelos destilados como derivados^[13].
• Datos antes que arquitectura. El consenso data-centric: limpiar etiquetas, cubrir casos límite y minar los errores del modelo suele rendir más que cambiar de arquitectura otra vez.

Conclusión_

En visión computacional la licencia es una decisión de arquitectura, no un trámite: define si puedes vender tu producto, cuánto te cuesta y qué riesgo legal cargas. Mi resumen operativo: Apache-2.0/MIT en código y pesos para todo lo comercial, AGPL solo con licencia de pago o con todo el stack abierto, pesos "no comerciales" jamás en producción, y las licencias personalizadas se leen completas. Y como las licencias cambiaron cuatro veces solo en los últimos tres años de esta tabla — cada afirmación de arriba lleva su fuente y su fecha.