이 누리집은 대한민국 공식 전자정부 누리집입니다.

dependency 중에 GPL-3.0 라이선스 문의

2026.08.31

Node.js 프로젝트에서 npm 패키지를 여러 개 사용하고 있는데, dependency 중에 GPL-3.0 라이선스 패키지가 하나 포함되어 있는 것을 확인했습니다.

해당 패키지는 저희가 직접 import해서 사용하는 것이 아니라 다른 npm 패키지의 dependency로 들어온 경우입니다.

이 경우에도 저희 프로젝트에 GPL 라이선스가 적용될 수 있을까요?

package-lock.json 기준으로 dependency가 포함되어 있는데, 실제 제품 배포 시 어떤 부분을 확인해야 하는지도 궁금합니다.

댓글 1

관리자 라이선스 담당자 2026-08-31 15:26
안녕하세요, 오픈소스SW 라이선스 관리자입니다. 문의주신 내용 답변드립니다. GPL-3.0의 적용 여부는 "직접 import했는지"가 아니라, 그 패키지가 실제 배포되는 제품에 포함되어 귀사 코드와 하나의 프로그램으로 결합·실행되는지를 기준으로 판단합니다. 따라서 transitive dependency(다른 패키지의 의존성으로 딸려 들어온 경우)라 하더라도, 그 코드가 최종 배포물(번들·node_modules·Docker 이미지 등)에 포함되어 런타임에 귀사 프로그램과 함께 실행된다면 직접 import한 경우와 동일하게 GPL-3.0이 적용될 수 있습니다. LGPL과 달리 GPL-3.0에는 링킹 예외 조항이 없으므로, 결합된 전체 프로그램에 대해 소스공개 의무가 발생하는 것이 원칙입니다. 반대로 해당 패키지가 devDependency로만 존재해 빌드·테스트 단계에서만 쓰이고 최종 배포물에는 포함되지 않는다면, 제품을 배포해도 그 부분은 "배포"에 해당하지 않아 의무가 발생하지 않습니다. 실제 제품 배포 전 확인이 필요한 부분은 다음과 같습니다. 1. 의존 경로 확인: npm ls <패키지명>으로 어느 dependencies 체인을 통해 들어왔는지 확인 — production dependency 체인인지, devDependency 전용 체인인지가 핵심입니다. 2. 최종 배포물 포함 여부: 번들러(webpack/esbuild 등) 결과물이나 배포 이미지(node_modules 포함 여부)에 해당 패키지 코드가 실제로 들어가는지 확인합니다. 3. 런타임 결합 여부: 별도 프로세스로 분리되어 CLI 형태로만 호출되는 구조인지, 아니면 같은 프로세스 안에서 함수 호출로 링크되어 동작하는지 확인합니다. 후자라면 귀사 코드까지 결합된 하나의 프로그램으로 취급될 가능성이 높습니다. 4. 대체 가능성 검토: 상위 패키지가 해당 GPL-3.0 의존성을 필수로 요구하는지, 아니면 옵션 기능이라 overrides/resolutions로 제외하거나 대체 라이브러리로 교체할 수 있는지 확인합니다. 위 확인 결과 배포물에 실제로 포함·결합되는 것으로 판단되면, 제품을 고객에게 배포할 때 귀사 프로그램 전체의 대응 소스코드(Corresponding Source)를 GPL-3.0 조건에 따라 제공해야 하는 것이 원칙입니다. 감사합니다. ※ 법적 분쟁 발생시 본 답변은 법률적 해석이나 논리로 활용될 수 없습니다.

댓글 작성

댓글을 작성하려면 게시글 작성 시 입력한 이메일과 패스워드를 입력해주세요.

* 표시는 필수 입력 사항입니다.