GitHub ha actualizado la forma en que determina la licencia de los componentes incluidos en los grafos de dependencias. La plataforma pasa a priorizar los registros canónicos de cada ecosistema, como npmjs.org y PyPI, para completar esa información en lugar de basarse principalmente en el servicio ClearlyDefined. El cambio ya está disponible en todas las herramientas afectadas de GitHub.
La mejora tiene consecuencias directas para quienes mantienen proyectos de software, especialmente cuando necesitan saber qué condiciones de uso acompañan al código de terceros. GitHub muestra estos datos en Dependency Insights, en las listas de materiales de software o SBOM, en la función de cumplimiento de licencias de código abierto de GitHub Advanced Security y en la acción Dependency Review.
Menos licencias ausentes en el grafo de dependencias
Según los datos iniciales comunicados por la compañía, el porcentaje de licencias que faltaban ha bajado del 45 % al 24 % entre los 170 millones de paquetes del grafo de dependencias. Es decir, se ha reducido aproximadamente a la mitad el número de paquetes sin una licencia identificada. GitHub añade que la cobertura real será mayor porque el sistema también contempla intervalos de versiones.
El servicio de grafo de dependencias consulta ahora metadatos del registro oficial correspondiente a cada gestor. Entre los casos incluidos están npm con npmjs.org, Python con PyPI, NuGet con nuget.org, RubyGems con rubygems.org, Rust con crates.io, Go con pkg.go.dev, Maven con deps.dev, Dart con pub.dev y PHP con Packagist. Esta relación entre ecosistema y registro busca acercar la licencia mostrada a la fuente que publica el paquete.
ClearlyDefined no desaparece del proceso: GitHub seguirá utilizándolo como respaldo y continuará colaborando con el servicio. La diferencia es que deja de ser la primera referencia. GitHub explica que su análisis profundo de archivos podía producir resultados complejos y difíciles de interpretar para las personas usuarias, mientras que los metadatos de los registros aportan una vía más directa para muchos paquetes.
Historial por rangos de versiones
La otra novedad es que la plataforma conserva el historial de licencias por rangos de versiones, en vez de exigir una entrada independiente para cada versión publicada. Esto permite cubrir versiones nuevas sin esperar a que se añadan una a una a la base de datos y simplifica el mantenimiento de esa información.
GitHub pone como ejemplo Grafana: las versiones desde la 1.0.0 hasta la 7.5.17 quedan asociadas a Apache-2.0, mientras que las versiones 8.0.0 y posteriores se vinculan a AGPLv3. Conservar ambos tramos ayuda a evitar que un proyecto que fija una versión antigua reciba la misma información de licencia que otro que ya usa una versión posterior.
Para equipos de desarrollo, esta actualización puede hacer más útil la revisión previa a aceptar una dependencia o una actualización. No sustituye la comprobación legal cuando el contexto lo exige, pero aporta datos más completos dentro de los flujos de seguridad habituales. También encaja con el trabajo de GitHub en el control de dependencias; recientemente, la compañía presentó Rule Insights para centralizar reglas en organizaciones.
La precisión importa porque una licencia ausente puede retrasar una revisión de cumplimiento, y una licencia mal contextualizada por versión puede conducir a decisiones equivocadas. Con el cambio, la información de licencias queda ligada tanto al ecosistema como a la evolución de cada paquete, dos elementos clave para interpretar correctamente una dependencia.
