Tras una vista previa pública abierta en junio de 2026, GitHub anunció el 16 de octubre la disponibilidad general del cumplimiento de licencias open source, reservada a los clientes de GitHub Enterprise Cloud con GitHub Code Security. La función permite definir una política de licencias a escala de la organización y aplicarla automáticamente en cada pull request que añada o modifique una dependencia.
El principio: una política de licencias aplicada en el momento de la fusión
Una política de licencias define qué licencias open source están permitidas, cuáles están prohibidas y cuáles requieren una validación caso por caso. En cuanto una pull request introduce una dependencia no conforme, GitHub añade una anotación. Nada de esto es nuevo en principio, pero la disponibilidad general abre la puerta a convertir este control en bloqueante.
Una nueva condición dentro de los rulesets
La política se aplica mediante un repository ruleset, siguiendo el mismo patrón que las condiciones de code scanning ya existentes. Una organización puede ahora exigir que el control de cumplimiento de licencias se supere antes de cualquier fusión, al mismo nivel que una revisión de código o una batería de pruebas en verde.
| Antes (vista previa, junio de 2026) | Después (disponibilidad general, octubre de 2026) |
|---|---|
| Sin datos de licencia para clientes con residencia de datos | Datos disponibles e integrados en el grafo de dependencias y las exportaciones SBOM |
| Sin condición de ruleset dedicada | Condición «Require license compliance results before merging» |
| Sin rol de gobernanza dedicado | Rol predefinido «Enterprise Open-Source License Manager» |
| Cambios de política sin trazabilidad | Cada cambio de política genera un evento en el audit log |
| Sin API de gestión de la política | Endpoints REST para leer, modificar y comprobar la conformidad de un paquete |
Resolver una anotación: tres caminos posibles
Cuando una dependencia se marca como no conforme, un equipo tiene tres opciones: retirar o sustituir la dependencia, pedir que la persona autorizada modifique la política de licencias, o crear una excepción puntual para ese paquete. El nuevo rol «Enterprise Open-Source License Manager» centraliza precisamente la revisión de esas solicitudes de excepción, con notificación por correo y gestión desde la consola de la organización, un flujo que se suma a las herramientas de línea de comandos que los equipos ya usan para auditar sus dependencias.
# Comprobar la conformidad de un paquete con la API REST del grafo de dependencias
gh api \
-H "Accept: application/vnd.github+json" \
/enterprises/ORG/dependency-graph/license-policy/check \
-f ecosystem=npm \
-f name=some-package \
-f version=2.4.1La política de licencias se comporta ahora como cualquier otra condición de ruleset: puede impedir la fusión de una pull request, al mismo nivel que una comprobación de code scanning o una revisión obligatoria.
GitHub también destaca un uso que va más allá de la gobernanza humana: los nuevos endpoints de API permiten a agentes de codificación automatizados comprobar la conformidad de un paquete antes de añadirlo a un proyecto. Una organización que ya estructura su cadena de despliegue en torno a reglas automatizadas, por ejemplo mediante un pipeline de auto-hospedaje estandarizado, encuentra aquí una palanca adicional para cerrar el círculo entre seguridad, cumplimiento y velocidad de entrega.
Lo que cambia para los equipos con muchas dependencias
Para una organización que gestiona decenas de repositorios, la diferencia respecto a la vista previa está sobre todo en el tooling de gobernanza: audit log, rol dedicado, API para agentes. Ese coste de seguimiento a escala explica por qué la función sigue posicionada en la oferta Enterprise Cloud y no en los repositorios individuales.
Lo que hay que recordar
El cumplimiento de licencias open source se convierte en un control de fusión de pleno derecho en GitHub, al mismo nivel que el code scanning. El principal valor añadido de la disponibilidad general está en el tooling de gobernanza: rol dedicado, audit log, API utilizable por agentes. La función sigue, no obstante, limitada a GitHub Enterprise Cloud, dejando a los repositorios individuales y los equipos pequeños sin un equivalente nativo.
Es el tipo de función que casi no importa por debajo de cierto tamaño, y que se vuelve indispensable por encima de él. En proyectos donde he visto hacerse una revisión de licencias a posteriori, normalmente disparada por una auditoría de cliente o una adquisición, el patrón es siempre el mismo: nadie recuerda ya exactamente qué licencias hay en el lockfile, y corregirlo después cuesta muchísimo más que haber bloqueado la fusión en el momento adecuado. Abrir la API a agentes de codificación es la señal más interesante aquí: el cumplimiento está a punto de dejar de ser un paso de revisión humana para convertirse en una restricción comprobada antes incluso de que se proponga el código. — Simon Janvier
Para profundizar: el anuncio oficial en el GitHub Changelog.
