GitHub 라이선스 배지가 없을 때: 파일·버전·API 확인 기록 만들기

By ON Lab · Sources checked November 7, 2026

GitHub에서 라이선스 배지가 보이지 않으면 저장소의 README와 라이선스 파일을 먼저 확인하세요. 화면의 배지, API의 탐지 결과, 실제 파일의 내용은 서로 다른 확인 항목입니다. 파일을 찾았다는 사실만으로 계획한 사용 방식의 권한까지 확인됐다고 기록하면 안 됩니다.

다른 저장소의 코드를 쓰려는 사람이 라이선스 정보를 찾지 못하는 상황을 위한 확인 순서입니다. 여기서는 어떤 라이선스가 회사 제품에 적합한지 결론 내리지 않습니다. 어떤 저장소의 어느 파일을 확인했고 무엇이 아직 미확인인지 남겨, 유지관리자나 검토 담당자가 같은 근거를 다시 볼 수 있게 만드는 것이 목표입니다.

1. 확인 중인 저장소와 버전을 고정하기

먼저 저장소 소유자와 이름을 적습니다. 비슷한 이름의 fork나 예제 저장소를 원본으로 착각하지 않도록 URL 전체를 확인합니다. 설치하려는 릴리스나 태그가 있다면 그 버전의 파일을 읽습니다. 기본 브랜치에서 본 파일이 과거에 받은 압축파일에도 들어 있다고 가정하지 마세요.

기록에는 확인 날짜, 저장소 URL, 브랜치·태그 또는 커밋 식별자, 사용하려는 파일 경로를 따로 둡니다. GitHub 주소에 /blob/main/이 있으면 main 브랜치를 가리키므로 나중에 내용이 바뀔 수 있습니다. 특정 커밋으로 고정한 링크와 구분해 남기세요.

2. 배지보다 README와 실제 파일 읽기

GitHub 공식 안내는 라이선스 문서를 저장소 루트의 LICENSE.txt, LICENSE.md, LICENSE.rst 같은 파일에서 찾을 수 있고, README에 관련 설명을 두는 프로젝트도 있다고 설명합니다. 파일명이 정확히 LICENSE가 아니라는 이유만으로 확인을 끝내지 않습니다.

README의 라이선스 구역과 실제 문서가 서로 맞는지 읽습니다. 여러 라이선스를 안내하거나 특정 디렉터리·파일에 다른 조건을 적었다면 그 차이도 기록합니다. 코드와 함께 배포되는 그림, 글꼴, 데이터, 외부 코드까지 하나의 배지로 묶어 확인했다고 적지 마세요. 이 단계는 확인 범위를 나누는 작업이지 개별 파일의 법적 결론을 자동으로 내리는 방법이 아닙니다.

3. 배지가 없다는 것과 라이선스가 없다는 것 구분하기

GitHub의 공식 문서는 Licensee가 알려진 라이선스 목록과 파일을 비교해 탐지한다고 설명합니다. 여러 라이선스가 섞이거나 파일이 복잡하면 표시가 명확하지 않을 수 있습니다. 따라서 배지나 API 식별자가 없을 때 남길 정확한 기록은 ‘자동 탐지 미확인’입니다. 실제 파일을 읽지 않고 ‘라이선스 없음’으로 바꾸지 않습니다.

반대로 배지가 표시돼도 파일의 적용 범위와 사용 조건을 읽는 단계는 남습니다. 라이선스 이름은 문서를 찾는 출발점이며, 출처 표시·재배포·변경 등 자신이 하려는 사용과 관련한 조건을 대신 확인해 주는 승인 표시가 아닙니다.

4. 공개 저장소의 파일을 API로 확인하는 예제

파일을 여러 번 점검한다면 공식 API 응답에서 경로와 탐지 결과를 기록할 수 있습니다. 다음은 공개 저장소 하나의 라이선스 조회 예시입니다. 공식 문서는 공개 리소스만 요청할 경우 이 경로를 인증 없이 사용할 수 있다고 설명합니다. 개인 토큰을 예제에 넣을 필요가 없으며, 비공개 저장소 접근을 시도하는 명령도 아닙니다.

curl -L -H 'Accept: application/vnd.github+json'   https://api.github.com/repos/psf/requests/license

2026년 11월 7일 이 예제를 조회했을 때 HTTP 200, 파일 경로 LICENSE, 탐지 식별자 Apache-2.0을 관측했습니다. 이것은 해당 시점에 한 공개 저장소에서 받은 응답 예시입니다. 다른 저장소에도 같은 결과가 나온다는 뜻이나 Requests를 특정 제품에서 사용해도 된다는 별도 판단이 아닙니다.

응답 항목	기록할 의미
path	발견된 파일의 저장소 내 경로
html_url	브라우저에서 파일을 읽을 주소
license.spdx_id	API가 탐지한 라이선스 식별자
sha	해당 파일의 Git 객체 식별자

sha를 저장소의 커밋 번호로 적지 않는 것이 중요합니다. 이 응답의 파일 식별자와 검토 대상 버전을 고정하는 커밋 식별자는 구분해 기록해야 합니다. 본 예제의 html_url은 기본 브랜치를 가리켰으므로 이것만 저장하고 버전 고정을 완료했다고 표시하지 않았습니다.

5. 오류나 빈 탐지 결과가 나오면

요청 제한에 걸리면 응답 헤더의 제한 정보를 보존하고 반복 요청을 멈춥니다. 공개 저장소를 확인하는 작은 작업을 위해 새 계정을 만들거나, 다른 사람의 토큰을 가져오거나, 비공개 로그인 상태를 추정할 이유는 없습니다. 이미 저장해 둔 응답과 파일 확인 기록을 재사용하면 됩니다.

6. 어떤 상태까지 확인됐는지 기록하기

아래처럼 사실과 판단을 분리하면 ‘라이선스 확인 완료’라는 한 줄 때문에 적용 범위를 놓치는 일을 줄일 수 있습니다. 기록의 예시는 실제 권한 승인서가 아닙니다.

저장소: 소유자/이름
대상 버전: 태그 또는 커밋 / 미확인
확인 파일: README, LICENSE 및 필요한 하위 경로
파일 링크: 실제 읽은 URL
자동 탐지: 식별자 / 미탐지 / API 오류
파일 내용 확인: 확인한 범위와 미확인 범위
예정 사용: 내부 실행 / 코드 포함 / 재배포 등
권한 판단: 확인 담당과 근거 / 검토 필요
확인 날짜: YYYY-MM-DD

실제 라이선스가 없을 때의 기본 권리와 GitHub 안에서의 보기·fork 권한은 공식 저장소 라이선스 안내가 구분해 설명합니다. 공개되어 있다는 이유만으로 계획한 복제·재배포가 허용됐다고 적지 마세요. 실제 제품 사용의 권한이 불명확하면 유지관리자나 적절한 검토 담당자에게 정확한 대상 버전과 사용 범위를 전달해 확인해야 합니다.

검증 범위: 공식 GitHub 라이선스 안내와 API 문서를 대조하고 공개 API 한 건을 실제 조회했습니다. 외부 코드·이미지·라이선스 전문을 전재하거나 실행하지 않았습니다. 개별 프로젝트의 법적 적합성, 모든 하위 파일의 권리 또는 상업적 사용 허용을 판정한 글이 아닙니다.