오픈소스 라이선스 파헤치기
npm install한 번에 회사 코드베이스가 GPL 오염되는 거, 생각보다 흔한 일임.
GPL · AGPL · LGPL · MIT · Apache 2.0 · BSD · MPL · 듀얼 라이선스까지 케이스별로 완전 정리.
목차
1. 왜 알아야 하는가
개발자가 라이선스를 모르는 것 자체가 취약점이다.
라이선스 컴플라이언스 실패의 결과는 3가지다.
- 소스 코드 강제 공개 — 핵심 IP 노출
- 상용 라이선스 소급 구매 — 예산 외 지출
- 제품 출시 지연 또는 배포 금지 — 비즈니스 타격
실제 사례
한 SaaS 스타트업이 MongoDB AGPL 버전을 백엔드에 사용하다 소스 공개 요청을 받음.
결국 MongoDB Atlas 상용 라이선스로 전환하는 데 수천만 원 비용 발생.
2. 핵심 개념 먼저
2.1 배포(Distribution)란?
라이선스 의무가 발생하는 핵심 트리거는 배포다.
| 배포 형태 | GPL 배포 해당 여부 |
|---|---|
| 바이너리 배포 (앱스토어, 다운로드) | ✅ 해당 |
| 온프레미스 납품 | ✅ 해당 |
| 도커 이미지 외부 배포 | ✅ 해당 |
| SaaS / REST API 제공 (GPL 기준) | ❌ 비해당 |
| 사내 내부 사용 | ❌ 비해당 |
| SaaS / REST API 제공 (AGPL 기준) | ✅ 해당 |
2.2 카피레프트 전파 강도
| 강도 | 라이선스 | 전파 범위 |
|---|---|---|
| 강한 카피레프트 | GPL v2/v3, AGPL v3 | 링크된 모든 코드에 전파 |
| 약한 카피레프트 | LGPL, MPL | 해당 라이브러리 수정분만 전파 |
| 퍼미시브 | MIT, Apache 2.0, BSD | 전파 없음 — 저작권 표시만 |
| 네트워크 카피레프트 | AGPL v3 | 네트워크 사용도 전파 트리거 |
2.3 링크(Link)의 의미
GPL 전파는 링크 관계가 있을 때 발생한다.
- 정적 링크 (Static Link) — 컴파일 시 코드가 합쳐짐 → 카피레프트 전파
- 동적 링크 (Dynamic Link) — 런타임에 외부 라이브러리 참조 → LGPL은 안전, GPL은 논쟁적
- 프로세스 분리 (IPC/HTTP) — 별도 프로세스로 통신 → GPL 전파 차단 가능 (AGPL 제외)
- Python import / Node.js require — 동일 프로세스 내 임포트 → 링크로 해석 가능
3. 라이선스 유형별 상세
🔴 AGPL v3 — 가장 강력, 가장 조심
제정 목적: GPL의 SaaS 우회를 막기 위해 2007년 등장. 네트워크 서비스 제공도 배포로 간주.
| 항목 | 내용 |
|---|---|
| 소스공개 조건 | 외부 배포 또는 네트워크를 통한 서비스 제공 시 전체 소스 공개 |
| 전파 범위 | 링크된 모든 코드 전체 |
| 위험 케이스 | MongoDB, Grafana, Nextcloud를 SaaS에 사용 |
| 안전 케이스 | 순수 사내 내부 도구 (외부 접근 없음) |
| 대표 패키지 | MongoDB (4.x 이하), Grafana OSS, Mastodon, Nextcloud |
| 상업적 대안 | MongoDB Atlas (유료), Grafana Cloud (유료) |
핵심: 백엔드 서버에서 AGPL 패키지를 실행하고 API로 서비스를 제공하면 소스 공개 의무 발생.
“우리는 배포 안 하고 서버에서만 쓰는데요”가 AGPL에서는 통하지 않음.
🟠 GPL v2 / v3 — 배포하면 전파됨
| 항목 | 내용 |
|---|---|
| 소스공개 조건 | 외부 배포(앱 출시, 납품 등) 시 전체 소스 공개 |
| SaaS 사용 | 서버에서만 실행하고 API로 제공하면 배포 아님 → 공개 불필요 |
| 사내 사용 | 배포 없으므로 공개 불필요 |
| v2 vs v3 차이 | v3는 특허 보호 조항 추가, 티보이제이션(하드웨어 잠금) 금지 |
| 위험 케이스 | GPL 패키지를 앱에 링크 후 앱스토어 배포, 고객사 온프레미스 납품 |
| 대표 패키지 | Linux Kernel, GCC, Bash, FFmpeg (일부 빌드), MySQL Community |
| 상업적 대안 | MySQL Enterprise, FFmpeg LGPL 빌드 |
핵심: GPL v2/v3는 SaaS/API 형태로만 제공하면 소스 공개 불필요.
하지만 바이너리·도커 이미지·납품물에 포함하는 순간 전파.
🟡 LGPL v2.1 / v3 — 동적 링크 허용
| 항목 | 내용 |
|---|---|
| 핵심 원칙 | 라이브러리 자체 수정 시에만 소스 공개. 사용하는 애플리케이션은 공개 불필요. |
| 동적 링크 | .so / .dll 형태로 링크 → 애플리케이션 소스 공개 불필요 |
| 정적 링크 | 컴파일 타임에 합쳐지면 LGPL 코드 수정분은 공개해야 함 |
| 실전 팁 | pip install, npm install로 사용하는 대부분의 경우 동적 링크로 처리됨 |
| 주의 사항 | 라이브러리 자체를 수정(패치)했다면 수정된 라이브러리 코드 공개 의무 |
| 대표 패키지 | GNU C Library (glibc), Qt (LGPL 옵션), libvlc, FFmpeg (LGPL 빌드) |
🟢 MIT — 상업적으로 가장 무난
| 항목 | 내용 |
|---|---|
| 소스공개 의무 | 없음. 상용 소프트웨어에 포함해 배포해도 됨. |
| 유일한 의무 | 저작권 고지 및 MIT 라이선스 텍스트를 포함해야 함 |
| 특허 조항 | 없음 (Apache 2.0과의 차이점) |
| 실전 팁 | README, NOTICE 파일에 원본 MIT 라이선스 텍스트 첨부로 충분 |
| 대표 패키지 | React, Vue.js, Express.js, Flask, Ruby on Rails, jQuery |
🔵 Apache 2.0 — 특허 보호 포함
| 항목 | 내용 |
|---|---|
| 소스공개 의무 | 없음. MIT와 마찬가지로 상용 포함 배포 자유. |
| MIT와 차이 | 특허 허여(Patent Grant) 조항 포함 → 특허 분쟁 방어에 유리 |
| 특허 보복 조항 | 사용자가 Apache 프로젝트에 특허 소송 제기 시 라이선스 자동 종료 |
| 의무 사항 | 저작권 고지, NOTICE 파일 포함, 수정 사항 명시 |
| GPL 호환성 | Apache 2.0은 GPL v3와 호환, GPL v2와는 비호환 (주의) |
| 대표 패키지 | Kubernetes, TensorFlow, Kafka, Hadoop, Spring Framework, Android |
🟣 BSD — MIT와 유사, 버전 주의
| 항목 | 내용 |
|---|---|
| 버전 구분 | 2-Clause (MIT와 거의 동일) / 3-Clause (비광고 조항 추가) |
| 소스공개 의무 | 없음 |
| 3-Clause 추가 의무 | 광고 및 판촉 자료에 원작자 이름 사용 금지 |
| 실전 팁 | BSD 2-Clause와 MIT는 사실상 동일하게 취급 가능 |
| 대표 패키지 | FreeBSD, OpenBSD, Django, Go 표준 라이브러리 일부 |
🟤 MPL 2.0 — 파일 단위 카피레프트
| 항목 | 내용 |
|---|---|
| 전파 단위 | 파일 단위. MPL 파일을 수정하면 그 파일만 공개 의무. |
| 애플리케이션 | MPL 파일과 다른 파일을 분리하면 앱 전체 공개 불필요 |
| GPL 호환성 | MPL 2.0은 GPL v2/v3, LGPL v2.1 호환 |
| 실전 포지션 | GPL보다 기업 친화적, MIT보다 오픈소스 기여 장려 |
| 대표 패키지 | Firefox, Thunderbird, LibreOffice (일부), Mozilla NSS |
4. 케이스별 판단 가이드
4.1 배포/사용 형태별 매트릭스
| 사용 케이스 | GPL v2/v3 | AGPL v3 | LGPL |
|---|---|---|---|
| 사내 내부 도구 | ✅ 안전 | ✅ 안전 | ✅ 안전 |
| SaaS / REST API 제공 | ✅ 안전 | ❌ 소스공개 | ✅ 안전 |
| 모바일 앱 배포 | ❌ 위험 | ❌ 위험 | ⚠️ 링크방식 확인 |
| 웹앱 번들 배포 | ❌ 위험 | ❌ 위험 | ⚠️ 링크방식 확인 |
| 온프레미스 납품 | ❌ 위험 | ❌ 위험 | ⚠️ 링크방식 확인 |
| 도커 이미지 공개 배포 | ❌ 위험 | ❌ 위험 | ⚠️ 링크방식 확인 |
| 별도 프로세스(IPC/HTTP) | ✅ 안전 | ❌ 소스공개 | ✅ 안전 |
| 정적 링크 후 배포 | ❌ 위험 | ❌ 위험 | ❌ 위험 |
| 동적 링크 후 배포 | ⚠️ 논쟁적 | ❌ 위험 | ✅ 안전 |
4.2 백엔드 상세 케이스
✅ 안전한 케이스
GPL v2/v3 패키지를 백엔드 서버에서만 실행하고, REST API로 제공
바이너리를 배포하지 않으므로 카피레프트 전파 없음.
GPL 컴포넌트를 별도 컨테이너/마이크로서비스로 분리하고 HTTP/gRPC 통신
프로세스 경계가 링크 관계를 차단함. (AGPL 제외)
[내 서비스] ←─ HTTP/gRPC ─→ [GPL 컴포넌트 전용 컨테이너]❌ 위험한 케이스
AGPL v3 패키지를 SaaS 백엔드에 사용
네트워크를 통한 기능 제공 자체가 배포로 간주 → 전체 소스 공개 의무.
GPL 패키지가 포함된 도커 이미지를 고객사에 납품하거나 공개 배포
이미지 배포 = 바이너리 배포로 해석됨.
GPL 패키지를 동일 프로세스에 임포트한 채로 바이너리 납품
Python import, Node.js require도 링크로 해석 가능.
4.3 프론트엔드 케이스
웹 프론트엔드는 번들(빌드 결과물)을 브라우저에 전송하는 것이 배포에 해당한다.
| 케이스 | 위험도 | 설명 |
|---|---|---|
| GPL 패키지 npm install 후 빌드 배포 | 🔴 높음 | 번들에 GPL 코드 포함 → 전체 소스 공개 대상 |
| AGPL 패키지 프론트엔드 사용 | 🔴 높음 | 브라우저에 전송 = 배포 + AGPL 전파 |
| LGPL 패키지 webpack 번들링 | 🟡 주의 | 정적 링크와 유사하게 해석될 수 있음 |
| MIT/Apache 패키지 사용 | 🟢 안전 | 저작권 표시만 유지하면 됨 |
| CDN으로 외부 LGPL 라이브러리 로드 | 🟢 안전 | 동적 링크로 해석 가능 |
4.4 모바일 앱 케이스
앱스토어 배포는 명확한 배포에 해당한다.
- iOS/Android 앱에 GPL 라이브러리 정적 링크 → 앱 전체 소스 공개 의무
- LGPL 라이브러리는 동적 링크 형태 유지 시 안전 (Android NDK 빌드 방식 주의)
- 실전 대응: GPL 의존성을 MIT/Apache 대체재로 교체하는 것이 가장 안전
- Apple App Store 정책과 GPL이 충돌하는 경우 배포 자체가 불가능해질 수 있음
5. 듀얼 라이선스 전략
많은 기업이 오픈소스 버전(GPL) + 상업용 버전(유료) 의 듀얼 라이선스 모델을 채택한다.
스타트업이 모르고 GPL 버전을 쓰다가 나중에 과금 폭탄을 맞는 케이스가 실제로 있다.
| 프로젝트 | 오픈소스 버전 | 상용 라이선스 | 주요 제한 |
|---|---|---|---|
| MySQL | GPL v2 | Oracle Commercial | 상업 배포 시 상용 필요 |
| Qt | GPL v3 / LGPL v3 | Qt Commercial | 앱 상업 배포 시 LGPL 조건 확인 |
| MongoDB | AGPL v3 (4.x 이하) | MongoDB SSPL / Atlas | SaaS 사용 시 전체 공개 또는 유료 |
| Elasticsearch | AGPL v3 (8.x+) | Elastic Commercial | 포크 OpenSearch는 Apache 2.0 |
| Redis | RSAL (7.4+) | Redis Cloud | 클라우드 서비스 제공 제한 |
| GitLab | MIT (CE) | GitLab EE | 엔터프라이즈 기능 유료 |
실전 팁: 듀얼 라이선스 프로젝트는 버전별 라이선스 변경 이력을 반드시 확인할 것.
MongoDB는 4.x에서 SSPL로, Elasticsearch도 7.10 이후 라이선스가 바뀌었다.
6. 실전 컴플라이언스 체계
6.1 즉시 할 수 있는 스캔
| 에코시스템 | 도구 | 명령어 |
|---|---|---|
| Node.js | license-checker | npx license-checker --summary |
| Node.js | licensee | npx licensee |
| Python | pip-licenses | pip-licenses --format=table |
| Java | license-maven-plugin | mvn license:aggregate-add-third-party |
| 전체 | FOSSA | fossa analyze |
| 전체 | Trivy | trivy fs --scanners license . |
| 전체 | spdx-sbom-generator | spdx-sbom-generator |
6.2 라이선스 정책 등급 분류
| 등급 | 라이선스 | 사용 조건 |
|---|---|---|
| 🟢 GREEN — 자유 사용 | MIT, Apache 2.0, BSD 2/3, ISC, Unlicense | 저작권 고지 후 자유 사용 |
| 🟡 YELLOW — 조건부 허용 | LGPL v2.1/v3, MPL 2.0, EPL 2.0 | 링크 방식, 수정 여부 확인 후 사용 |
| 🔴 RED — 검토 필요 | GPL v2/v3 | 배포 형태, 링크 방식, 법무 검토 필수 |
| ⛔ BLACK — 원칙적 금지 | AGPL v3, SSPL, Commons Clause 포함 | SaaS 사용 금지. 법무팀 사전 승인 필수 |
6.3 의존성 관리 프로세스
- 신규 패키지 도입 전 라이선스 확인 (GREEN/YELLOW/RED/BLACK 분류)
- AGPL 패키지 감지 시 즉시 대체재 탐색 또는 법무 검토
- CI/CD 파이프라인에 라이선스 스캔 자동화 통합 (FOSSA, Trivy 등)
- SBOM(Software Bill of Materials) 주기적 생성 및 보관
- 사용 중인 오픈소스 프로젝트의 라이선스 변경 공지 구독
- 배포 빌드에 NOTICE 파일 자동 생성 파이프라인 구성
6.4 아키텍처 레벨 우회 패턴
GPL 패키지를 반드시 사용해야 하는 경우, 프로세스 경계로 카피레프트 전파를 차단하는 패턴이 실전에서 쓰인다.
패턴 1 — 사이드카 컨테이너
[내 서비스] ←─ HTTP/gRPC ─→ [GPL 컴포넌트 전용 컨테이너]네트워크 경계로 링크 관계 차단. GPL v2/v3에서는 유효. AGPL에서는 불가.
패턴 2 — 마이크로서비스 분리
[메인 앱] ←─ REST API ─→ [GPL 기반 독립 서비스]GPL 컴포넌트를 완전히 독립된 서비스로 운영. 결합도 낮추고 라이선스 경계 명확화.
패턴 3 — 대체재 교체 (가장 확실)
| 교체 전 | 교체 후 |
|---|---|
| MongoDB AGPL | PostgreSQL (MIT) / MongoDB Atlas (유료) |
| Elasticsearch AGPL | OpenSearch (Apache 2.0) |
| Grafana OSS (AGPL) | Grafana Cloud (유료) / Victoria Metrics (Apache 2.0) |
7. 퀵 레퍼런스
7.1 라이선스 호환성 매트릭스
합쳐서 배포할 때 두 라이선스가 호환되는지 확인.
| MIT | Apache 2.0 | LGPL v3 | GPL v2 | GPL v3 | AGPL v3 | |
|---|---|---|---|---|---|---|
| MIT | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Apache 2.0 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| LGPL v3 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| GPL v2 | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ |
| GPL v3 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| AGPL v3 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
⚠️ Apache 2.0과 GPL v2는 비호환. 두 라이선스의 코드를 합쳐 단일 바이너리로 배포 불가.
7.2 라이선스 선택 가이드
| 상황 | 추천 라이선스 | 이유 |
|---|---|---|
| 상용 제품에 포함할 오픈소스 의존성 | MIT, Apache 2.0 | 소스 공개 의무 없음 |
| 특허 분쟁 리스크가 있는 환경 | Apache 2.0 | 특허 허여 및 보복 조항 포함 |
| 내 라이브러리를 널리 퍼뜨리고 싶음 | MIT, BSD 2-Clause | 가장 낮은 진입장벽 |
| 커뮤니티 기여를 강제하고 싶음 | GPL v3 | 수정 코드 공개 강제 |
| SaaS 우회도 막고 싶음 | AGPL v3 | 네트워크 제공도 카피레프트 |
| 라이브러리는 공개하되 앱은 보호 | LGPL | 앱 소스 공개 불필요 |
7.3 긴급 점검 체크리스트
- 현재 프로젝트에 AGPL 패키지가 있는가?
→ 있다면: SaaS로 서비스 중인지 확인. 맞다면 즉시 법무 검토 또는 대체재 교체 - GPL 패키지를 외부 배포 앱/납품물에 포함하는가?
→ 있다면: 링크 방식 확인, 프로세스 분리 가능한지 검토 - 듀얼 라이선스 프로젝트의 버전과 라이선스를 확인했는가?
→ MongoDB, Elasticsearch, Redis 등은 버전마다 라이선스가 다름 - CI/CD에 라이선스 스캔이 자동화되어 있는가?
→ 없다면: Trivy 또는 FOSSA 통합 검토 - NOTICE 파일 / 저작권 고지가 배포물에 포함되어 있는가?
→ MIT/Apache 사용 시에도 고지 의무 있음 - 의존성 라이선스 목록 (SBOM)이 최신 상태인가?
→ 분기 1회 이상 갱신 권장
마무리
라이선스를 모르는 것은 취약점이다.
공격자만 코드를 보는 게 아니라, 법무팀도 본다.
백엔드에 AGPL 있는지 지금 바로 확인해보자.
# Node.js
npx license-checker --summary | grep -i agpl
# Python
pip-licenses --format=table | grep -i agpl
# 컨테이너/전체
trivy fs --scanners license . | grep -i agpl