El cumplimiento de licencias de GitHub ya está disponible para todos

GitHub puso el cumplimiento de licencias de código abierto a disposición de todos el 16 de octubre de 2026, para los repositorios de GitHub Enterprise Cloud que tienen activado GitHub Code Security. La función comprueba la licencia de cada dependencia que añade una pull request y puede bloquear el merge cuando esa licencia incumple la política de la empresa. Importa porque la revisión de licencias suele hacerse tarde, a mano, cuando el código ya está escrito.

Qué hace el cumplimiento de licencias

Todo paquete de código abierto viene con una licencia, las condiciones legales para usarlo. Algunas licencias, como MIT o Apache 2.0, piden poco a quien las usa. Otras añaden condiciones que los abogados de una empresa quizá no acepten. "Casi todo el software lleva algún tipo de acuerdo de licencia", escribieron Jeff Luszcz y Eric Sorenson, gestores de producto de GitHub, según cita Help Net Security.

El changelog de GitHub dice que la función amplía la acción dependency review con una sola política de licencias para toda la empresa. En GitHub, una empresa (enterprise) es la cuenta de nivel superior que agrupa muchas organizaciones. Las comprobaciones se ejecutan automáticamente en cualquier pull request que añade o cambia una dependencia. Cada dependencia cuya licencia no está permitida recibe una anotación, una nota adjunta a la pull request.

Después, quien desarrolla tiene tres salidas, según el changelog. Puede quitar o sustituir el paquete, cambiar la política de licencias o pedir una excepción para ese paquete concreto.

Qué cambió desde la versión preliminar de junio

GitHub abrió la función como versión preliminar pública el 30 de junio de 2026. La versión general añade cuatro cosas, según el changelog.

Añadido en la disponibilidad general	Qué hace
Soporte de residencia de datos	Los datos de licencias ya llenan el gráfico de dependencias y las exportaciones SBOM en Enterprise Cloud con residencia de datos
Eventos del registro de auditoría	Los cambios en la política de licencias quedan registrados, para que sistemas externos puedan seguirlos
API REST de políticas	Nuevos endpoints descargan, actualizan y sustituyen la política de licencias de la empresa
Endpoint de comprobación de paquetes	Indica a una herramienta si los paquetes cumplen, para que los agentes de programación eviten los que no cumplen

Un SBOM, o lista de materiales de software, es una lista de todos los componentes de un programa. La última fila es la que más importa para las herramientas de programación con IA. Un agente ya puede preguntar a GitHub si un paquete está permitido antes de añadirlo.

Cómo se aplica la política

La política enumera las licencias permitidas. La documentación de GitHub dice que quienes administran eligen de una lista integrada o añaden otras por identificador SPDX, el código corto estándar de una licencia. La comprobación también cubre las dependencias transitivas, es decir, los paquetes que arrastran tus paquetes.

Los rulesets aplican la política a nivel de empresa, organización o repositorio. Un ruleset es la forma que tiene GitHub de fijar reglas en muchos repositorios a la vez. La documentación describe dos modos:

• Active: un ruleset con la condición "Requires license compliance results before merging" bloquea el merge hasta que se corrige el problema.
• Evaluate: se ejecuta la misma comprobación y se anota la pull request, pero no se bloquea.

Las solicitudes de excepción van a un nuevo rol de empresa predefinido. El changelog lo llama Enterprise Open-Source License Manager. Quienes tienen ese rol reciben avisos por correo y aprueban las solicitudes desde la consola de la empresa.

La documentación de GitHub sugiere una política central amplia más excepciones por repositorio. Los equipos pueden añadir una propiedad de repositorio personalizada con los valores inactive, evaluate y active. Después, los rulesets apuntan a esos valores para fijar la aplicación repositorio a repositorio.

Cómo lo usa GitHub internamente

La propia oficina de programas de código abierto de GitHub usa la herramienta, informó Help Net Security en julio. Esa oficina dejó sus herramientas internas unos dos meses antes del artículo. Tuvo los repositorios en modo Evaluate durante cerca de un mes antes de activar la aplicación. La mayoría de las solicitudes de licencia se revisaron "en pocas horas", según el informe. La lista inicial de licencias permitidas era MIT, Apache 2.0 y BSD-3-Clause.

El mismo informe señala una válvula de seguridad. Un equipo puede pasar un repositorio de Active a Evaluate para una corrección crítica y luego volver a cambiarlo.

GitHub ha ido reforzando la pull request este mes. Lanzó AI Scan para pull requests con disponibilidad general el 15 de octubre. Un día después, los lockfiles de workflows para GitHub Actions entraron en versión preliminar pública.

Qué significa esto para los desarrolladores

Si tu empresa usa GitHub Enterprise Cloud con Code Security, puedes activarlo hoy. Ninguna de las fuentes indica un precio aparte. Comprueba qué cubre tu contrato actual de Code Security antes de planear el despliegue.

Empieza en modo Evaluate, como hizo el propio equipo de GitHub. Un mes de anotaciones muestra de qué licencias depende ya tu código antes de que nada bloquee un merge. Después pasa los repositorios a Active grupo a grupo con la propiedad personalizada.

Acuerda primero la lista de licencias permitidas. MIT, Apache 2.0 y BSD-3-Clause son un punto de partida habitual. Decide quién tiene el rol de gestión de licencias, porque las solicitudes de excepción se atascan sin una persona revisora concreta.

Si creas herramientas internas o agentes de programación, mira el nuevo endpoint de comprobación de paquetes. Un agente que revisa un paquete antes de instalarlo te ahorra después una pull request bloqueada.

Ninguna de las fuentes indica qué ecosistemas de paquetes están cubiertos. Prueba un repositorio de cada lenguaje que use tu empresa antes de contar con una cobertura completa.