의존성을 추가할 때 라이선스를 보는 사람은 드물다. 문제는 제품을 고객사에 납품하거나 외부에 서비스를 열 때 뒤늦게 드러난다. 법무 판단은 법무의 일이지만 어떤 항목이 걸릴 수 있는지 알아보는 것은 코드를 넣는 사람의 일이다. 아래는 그 선별을 위한 정리이고 법률 자문은 아니다.
세 갈래로 나눠 본다
수십 종을 외울 필요는 없다. 전파 범위로 세 덩어리다.
| 갈래 | 대표 | 의무의 범위 |
|---|---|---|
| 허용형 | MIT, BSD, Apache-2.0, ISC | 저작권 표시와 라이선스 사본 유지 |
| 약한 카피레프트 | LGPL, MPL-2.0, EPL-2.0 | 그 라이브러리 자체의 변경분만 공개 |
| 강한 카피레프트 | GPL-2.0, GPL-3.0, AGPL-3.0 | 결합한 저작물 전체가 같은 조건 |
허용형은 표시만 지키면 상용 제품에 넣을 수 있다. Apache-2.0은 여기에 두 가지가 더 붙는다. 기여자의 특허 사용 허락이 명시되어 있다. NOTICE 파일이 있으면 배포물에 포함해야 한다. 특허 조항 때문에 사내 검토에서 MIT보다 선호되는 경우가 많다.
약한 카피레프트는 경계가 그 라이브러리에서 끝난다. 라이브러리를 고쳤으면 그 변경분을 공개하고 내 애플리케이션 코드는 공개하지 않는다.
강한 카피레프트는 결합한 결과물 전체로 번진다. 이 지점이 실무에서 가장 자주 문제가 된다.
전파는 언제 시작되는가
가장 흔한 오해가 "GPL은 상업적으로 못 쓴다"는 것이다. 그렇지 않다. GPL은 상업적 사용을 막지 않는다. 의무가 발생하는 계기는 배포다.
사내에서만 쓰고 밖으로 내보내지 않으면 GPL 의무는 대체로 발동하지 않는다. 사내 배치 서버에서 GPL 도구를 돌려도 문제가 없다. 그 도구를 링크한 제품을 고객사에 설치해 주는 순간부터 이야기가 달라진다.
그래서 확인할 질문은 라이선스 이름이 아니다. 이 코드가 회사 밖으로 나가는가. 나간다면 어떤 형태로 나가는가.
AGPL이 다른 지점
AGPL-3.0에는 다른 라이선스에 없는 조항이 있다. 13조다. 프로그램을 수정한 뒤 네트워크로 사용자와 상호작용하게 하면, 그 사용자에게 소스를 제공해야 한다.
즉 배포하지 않아도 의무가 생긴다. 서비스로 제공하는 것 자체가 계기가 된다. SaaS 형태로 서비스를 열 때 AGPL 컴포넌트가 핵심 경로에 있으면 검토가 필요하다.
주의할 표현이 있다. 조항은 수정한 경우를 말한다. 고치지 않고 그대로 쓰는 것과 고쳐서 쓰는 것이 다르다. 다만 "고쳤다"의 범위 판단은 애매한 경우가 많다. 여기까지 오면 법무에 넘기는 것이 맞다.
Redis가 2025년에 AGPLv3를 선택지에 넣은 것이 이 조항 때문에 화제가 됐다. 캐시로 쓰는 것과 그걸로 관리형 서비스를 파는 것이 다르게 취급되기 때문이다.
MPL은 파일 단위다
MPL-2.0의 경계는 파일이다. MPL로 배포된 파일을 고치면 그 파일을 공개하고 같은 프로젝트 안의 다른 파일은 독자 라이선스로 둘 수 있다.
경계가 명확해서 상용 제품에 섞기 쉽다. 라이브러리를 고쳐 쓸 가능성이 있는데 전체 공개는 피하고 싶을 때 선택되는 조건이다.
LGPL은 조금 다르다. 링크 방식이 기준선이다. 동적 링크로 쓰면 애플리케이션은 자기 라이선스를 유지할 수 있다. 다만 사용자가 그 라이브러리를 교체할 수 있어야 한다는 요건이 붙는다. 정적 링크로 배포하면 만족시켜야 할 조건이 늘어난다. 모바일 앱처럼 정적 링크가 기본인 환경에서 자주 걸린다.
섞을 때 걸리는 조합
라이선스마다 다른 라이선스와 호환되는 범위가 다르다. 실무에서 만나는 대표적인 것이 Apache-2.0과 GPLv2다.
Apache-2.0의 특허 조항이 GPLv2가 허용하지 않는 추가 제약으로 해석된다. 이 해석에 따르면 두 코드를 결합해 배포할 수 없다. GPLv3에는 특허 관련 조항이 들어가면서 이 문제가 해소됐다.
자바 생태계에서 이게 실제로 문제가 된다. Apache 재단 라이브러리가 Apache-2.0이고 일부 도구가 GPLv2인 경우가 있다. 라이브러리를 추가할 때 이미 들어와 있는 것과 어떻게 조합되는지 보는 절차가 필요하다.
실제로 확인하는 절차
사람이 목록을 눈으로 훑는 방식은 규모가 조금만 커지면 무너진다. 도구로 뽑는다.
# Maven
mvn license:add-third-party
# npm
npx license-checker --summary
# Gradle
./gradlew generateLicenseReport여기서 봐야 할 것은 직접 의존성이 아니라 추이 의존성이다. 내가 추가한 것은 Apache-2.0인데 그것이 끌어온 것이 GPL인 경우가 있다. 트리를 끝까지 봐야 한다.
mvn dependency:tree
npm ls --all목록을 기계가 읽을 수 있는 형태로 남기는 것이 SBOM이다. SPDX와 CycloneDX가 널리 쓰이는 형식이다. 라이선스를 SPDX 식별자로 적는다. Apache-2.0, MIT, GPL-3.0-only, AGPL-3.0-or-later 같은 문자열이다. 표기가 표준화되어 있어서 사람이 쓴 "아파치 라이선스 2.0"보다 자동 검사에 유리하다.
공공 부문 납품이나 금융권 프로젝트에서 SBOM 제출을 요구하는 경우가 늘었다. 납품 직전에 만들려고 하면 이미 들어간 컴포넌트를 뺄 수 없는 상황이 된다. 빌드 파이프라인에 넣어 두는 편이 낫다.
자주 어긋나는 것들
라이선스 파일만 넣으면 된다고 생각하는 경우가 있다. Apache-2.0은 NOTICE 파일도 배포물에 포함해야 한다. 배포 대상에 이 파일이 들어가는지 확인한다.
모델과 데이터셋은 소프트웨어 라이선스와 별개다. 가중치에 붙은 조건이 코드 라이선스와 다르다. 상업적 사용을 제한하거나 특정 용도를 금지하는 조항이 붙은 경우가 있다. 데이터셋도 마찬가지다. 오픈소스 라이선스 목록만 뽑고 모델은 안 보는 검토가 흔하다.
듀얼 라이선스는 고르는 것이다. 하나가 GPL이고 하나가 상용인 경우, GPL 조건을 지키거나 상용 라이선스를 구매하거나 둘 중 하나다. GPL 쪽만 보고 못 쓴다고 결론 내릴 필요는 없다.
라이선스 없는 저장소는 허용이 아니라 금지에 가깝다. 아무 조건이 명시되지 않으면 기본 저작권법이 적용되고 복제와 배포 권한이 없다. GitHub에 공개돼 있다는 사실만으로 쓸 수 있는 것이 아니다.
정리
- 전파 범위로 세 갈래다. 허용형, 약한 카피레프트, 강한 카피레프트.
- GPL은 상업적 사용을 막지 않는다. 의무의 계기는 배포다.
- AGPL은 배포하지 않아도 네트워크로 서비스하면 의무가 생긴다.
- MPL은 파일 단위, LGPL은 링크 방식이 기준이다.
- Apache-2.0과 GPLv2는 결합이 문제가 된다. GPLv3에서는 해소됐다.
- 추이 의존성까지 본다. SBOM을 빌드에 넣는다.
- 모델 가중치와 데이터셋은 별도로 확인한다. 라이선스가 없으면 쓸 수 없다.
참고
'dev' 카테고리의 다른 글
| Solr와 Elasticsearch, 그리고 분산 클러스터 설계 (0) | 2026.08.19 |
|---|---|
| 정보 검색의 이론적 토대 (0) | 2026.08.15 |
| MCP, 에이전트에 도구를 붙이는 규약 (0) | 2026.08.14 |
| submodule과 subtree, 그리고 자체 호스팅 GitLab (0) | 2026.08.13 |
| Lucene 색인과 검색 성능 튜닝 (1) | 2026.08.12 |