안녕하세요, 오픈소스SW 라이선스 관리자입니다. 문의주신 내용 답변드립니다. 저장소 최상위의 LICENSE 파일(MIT)은 그 프로젝트가 기본적으로 채택한 라이선스를 나타낼 뿐, 개별 파일에 별도로 명시된 라이선스 문구를 무효화하거나 덮어쓰지 않습니다. 오픈소스 프로젝트는 외부에서 가져온(vendored) 코드나 임베디드 라이브러리를 원래 라이선스 그대로 포함하는 경우가 흔하며, 이런 파일에는 저장소 전체 LICENSE와 다른 라이선스 문구가 파일 헤더에 남아있을 수 있습니다. 따라서 "저장소가 MIT라고 되어 있으니 전체를 MIT로 본다"는 판단은 위험하며, 실제 제품에 포함해 배포할 계획이라면 파일(또는 디렉터리) 단위로 라이선스를 확인하셔야 합니다. 확인 절차는 다음과 같이 진행하시는 것을 권장합니다. 1. 저장소 내 별도 문서 우선 확인: LICENSES/ 폴더, NOTICE 파일, README의 "Third-party licenses"·"라이선스" 섹션 등에 파일별 라이선스가 정리되어 있는지 먼저 확인합니다. 잘 관리되는 프로젝트는 SPDX 헤더(SPDX-License-Identifier: ...)로 파일마다 명시해두는 경우가 많습니다. 2. 실제 사용·배포할 파일만 대상으로 점검: 귀사 제품 빌드에 실제로 포함되는 파일들만 골라 각 파일 상단의 라이선스 문구를 확인합니다. 사용하지 않는 예제·문서·테스트 파일이라면 배포 대상이 아니므로 판단 대상에서 제외할 수 있습니다. 3. 라이선스별로 분리해서 의무 이행: 확인 결과 파일이 여러 라이선스로 나뉜다면, 각 파일 그룹은 자신의 라이선스 조건을 각각 따라야 합니다. - MIT 파일 → 저작권 고지·라이선스 전문 포함 - Apache-2.0 파일 → 저작권 고지·라이선스 전문·(NOTICE 있다면) NOTICE 내용 포함 - GPL 관련 파일 → 가장 주의가 필요합니다. 해당 GPL 코드가 귀사 제품과 결합되어 하나의 프로그램으로 배포된다면, MIT/Apache와 달리 GPL의 강한 카피레프트 조건이 적용되어 결합된 전체(또는 해당 범위)에 대해 소스공개 의무가 발생할 수 있습니다(이전에 안내드린 GPL 결합 판단 기준과 동일합니다). 4. 애매하면 메인테이너에게 직접 확인: 저장소 대표 라이선스와 파일별 라이선스 문구가 불일치하는 것 자체가 관리 소홀이나 실수일 수 있어, 상용 제품에 포함하기 전 이슈(issue)를 남기거나 직접 문의해 명확히 확인하시는 것이 안전합니다. 감사합니다. ※ 법적 분쟁 발생시 본 답변은 법률적 해석이나 논리로 활용될 수 없습니다.