GitHub 라이선스 판정이 패키지 레지스트리를 우선한다: SBOM 검토가 달라지는 지점

GitHub가 2026년 8월 13일부터 의존성 그래프의 라이선스 판정에 npmjs.org, PyPI 같은 각 생태계의 대표 패키지 레지스트리 메타데이터를 우선 사용한다. 기존의 주요 출처였던 ClearlyDefined는 보조 출처로 남는다. 변경된 정보는 GitHub 전반에 이미 적용됐으며, 별도의 런타임 버전이나 저장소 마이그레이션은 필요하지 않다.

무엇이 바뀌었나

적용 대상은 npm, NuGet, Python, RubyGems, Rust, Go, Maven, Dart, PHP 생태계다. GitHub는 각각 npmjs.org, nuget.org, pypi.org, rubygems.org, crates.io, pkg.go.dev, deps.dev, pub.dev, packagist.org의 정보를 우선한다. 파일을 깊게 검사하는 ClearlyDefined의 결과는 계속 활용하지만, 대표 레지스트리에서 명확한 정보를 얻지 못할 때의 보완 수단이 된다.

라이선스 이력도 개별 버전마다 별도 항목을 만드는 대신 버전 범위로 저장한다. GitHub가 든 예에서 Grafana 1.0.0~7.5.17은 Apache‑2.0, 8.0.0 이상은 AGPLv3로 구분된다. 재라이선스된 프로젝트를 한 가지 라이선스로 뭉뚱그리지 않고 버전 경계에 맞춰 표시하려는 변화다.

개발자에게 왜 중요한가

이 데이터는 의존성 인사이트, 소프트웨어 자재 명세서(SBOM)¹, GitHub Advanced Security의 오픈소스 라이선스 준수 기능, dependency review action에 쓰인다. GitHub는 1억7천만 개 패키지 가운데 라이선스가 비어 있던 비율이 45%에서 24%로 줄었다고 밝혔다. 누락 감소는 검토 대상을 넓혀 주지만, 숫자는 GitHub의 초기 집계이며 법적 적합성을 보증하는 지표는 아니다.

패키지 게시자가 레지스트리에 적은 메타데이터가 우선되면서, 실제 저장소의 LICENSE 파일이나 하위 구성 요소의 조건과 차이가 날 수도 있다. 자동화 결과가 더 많이 채워졌다고 해서 사람의 검토가 불필요해지는 것은 아니다.

기존 프로젝트 영향

애플리케이션 코드, 패키지 설치 방식, 런타임 호환성에는 직접 변화가 없다. 대신 같은 커밋에서 다시 생성한 SBOM이나 의존성 검토 결과의 라이선스 필드가 이전과 달라질 수 있다. 정책이 특정 라이선스를 차단하도록 설정된 조직에서는 과거에 ‘알 수 없음’이던 항목이 허용 또는 차단 대상으로 분류될 가능성이 있다.

특히 버전 범위 기반 이력은 재라이선스 경계가 있는 패키지에 영향을 준다. 잠금 파일의 정확한 버전과 SBOM의 버전 정보가 빠져 있으면 올바른 라이선스 범위를 판단하기 어렵다. 단순 패키지 이름만 남기는 자체 자산 목록은 보완할 필요가 있다.

적용·업데이트 전 확인 사항

• 변경 전후 SBOM을 비교한다. 새로 채워진 라이선스와 값이 바뀐 패키지를 분리해 검토한다.
• 정확한 버전을 보존한다. 재라이선스 경계를 판단할 수 있도록 잠금 파일과 SBOM에 버전 정보를 유지한다.
• 원문을 확인한다. 배포나 상용 이용에 중요한 패키지는 레지스트리 메타데이터뿐 아니라 해당 버전의 LICENSE·NOTICE·소스 헤더를 함께 확인한다.
• 자동 차단 정책을 시험한다. dependency review action과 조직의 라이선스 허용 목록이 새 데이터로 어떤 결과를 내는지 시험 풀 리퀘스트에서 확인한다.
• 법률 판단과 구분한다. GitHub의 분류는 공급망 관리 자료다. 복합 라이선스, 예외 조항, 결합 방식에 따른 의무는 별도 검토가 필요하다.

출처

• GitHub Changelog — License data quality improvements
• GitHub Docs — Dependency graph
• ClearlyDefined — 공개 라이선스 데이터 서비스

¹ SBOM(Software Bill of Materials): 소프트웨어에 포함된 구성 요소와 버전 등을 기계가 읽을 수 있게 정리한 목록.