Open Source

오픈소스 라이선스 완벽 가이드

한 줄 요약: 오픈소스 라이선스는 코드를 어떻게 써도 되는지에 대한 법적 계약이다. MIT·Apache·GPL·AGPL·BSD·MPL 각각 허용 범위와 의무가 다르며, 잘못 선택하면 상용 제품 배포나 SaaS 운영에 법적 문제가 생긴다. 오픈소스 라이선스는 크게 두 범주로 나뉜다. 퍼미시브(Permissive): 사용, 수정, 배포, 상용화 모두 허용.

by Lee발행: 2026-05-05

한 줄 요약: 오픈소스 라이선스는 코드를 어떻게 써도 되는지에 대한 법적 계약이다. MIT·Apache·GPL·AGPL·BSD·MPL 각각 허용 범위와 의무가 다르며, 잘못 선택하면 상용 제품 배포나 SaaS 운영에 법적 문제가 생긴다.

오픈소스 라이브러리를 프로젝트에 넣기 전에 라이선스를 확인하는 개발자는 생각보다 적다. MIT면 그냥 쓰면 되고, GPL이면 복잡하다는 정도의 직관만 갖고 있다. 이 글은 실무에서 실제로 판단해야 하는 상황 — 상용 제품에 포함, SaaS로 제공, 수정 후 배포 — 별로 각 라이선스가 무엇을 요구하는지 정리한다.

6대 오픈소스 라이선스 개요

오픈소스 라이선스는 크게 두 범주로 나뉜다.

퍼미시브(Permissive): 사용, 수정, 배포, 상용화 모두 허용. 저작권 표시만 유지하면 된다. MIT, Apache 2.0, BSD가 여기에 속한다.
카피레프트(Copyleft): 수정·배포 시 동일 라이선스 적용 의무. GPL, AGPL이 대표적이다. MPL은 파일 단위 카피레프트로 중간 지점이다.

어느 쪽이 더 좋은 게 아니다. 목적과 상황에 맞는 라이선스가 있을 뿐이다.

6대 오픈소스 라이선스 개요 — 프로젝트 구조 다이어그램 — 오픈소스 라이선스 완벽 가이드 — 프로젝트 구조 다이어그램 (출처: 공식 문서 및 벤치마크 데이터 기반)

MIT와 Apache 2.0 — 가장 널리 쓰이는 퍼미시브 라이선스

MIT 라이선스

가장 단순한 오픈소스 라이선스다. 사실상 두 가지 의무만 있다.

소스 코드나 바이너리에 원본 저작권 표시와 MIT 라이선스 텍스트를 포함할 것
소프트웨어를 있는 그대로 제공하며, 보증하지 않는다는 면책 조항을 유지할 것

상용 제품에 포함해도 된다. 수정 후 비공개 유지도 된다. 특허 침해에 대한 명시적 보호는 없다는 점이 Apache 2.0과 다른 점이다.

주요 사용 사례: React, Vue.js, Next.js, Rails, Django

Apache 2.0 라이선스

MIT와 마찬가지로 퍼미시브이지만 두 가지가 추가된다.

특허 허여(Patent Grant): 기여자가 자신의 특허에 대해 사용자에게 명시적으로 라이선스를 준다. 반대로 사용자가 기여자를 상대로 특허 소송을 제기하면 이 특허 허여가 자동 취소된다.
변경 사항 명시: 소스 코드를 수정했다면 수정했다는 사실을 명시해야 한다.

엔터프라이즈 환경에서 특허 분쟁 리스크를 줄이고 싶다면 MIT보다 Apache 2.0을 선호하는 경우가 많다.

주요 사용 사례: Kubernetes, TensorFlow, Kafka, Android

MIT와 Apache 2.0 — 가장 널리 쓰이는 퍼미시브 라이선스 — 기능 비교 차트 — 오픈소스 라이선스 완벽 가이드 — 기능 비교 차트 (출처: 공식 문서 및 벤치마크 데이터 기반)

GPL과 AGPL — 카피레프트 라이선스

GPL v2 / GPL v3

GPL(GNU General Public License)은 대표적인 카피레프트 라이선스다. 핵심 조건은 다음과 같다.

GPL 코드를 수정하거나 포함한 소프트웨어를 배포하면, 전체 소프트웨어도 GPL로 공개해야 한다.
"배포"는 바이너리를 제3자에게 전달하는 행위다. 사내에서만 쓰는 경우는 배포가 아니다.

GPL v2와 v3의 차이: v3는 특허 허여 조항과 "Tivoization" 방지 조항이 추가된다. Tivoization은 GPL 코드를 탑재하되 사용자가 수정한 코드를 실행하지 못하게 하드웨어 잠금을 거는 관행을 막기 위한 것이다.

상용 제품에 GPL 라이브러리를 포함해서 배포하면 제품 전체를 GPL로 공개해야 할 수 있다. 이것이 GPL을 상용 프로젝트에서 기피하는 이유다.

주요 사용 사례: Linux 커널(v2), GCC, Git, WordPress

AGPL v3 (Affero GPL)

AGPL은 GPL의 "배포" 허점을 막기 위해 만들어졌다. GPL은 서버에서 소프트웨어를 실행하고 네트워크로 서비스를 제공하는 것을 "배포"로 보지 않는다. 즉, SaaS로 운영하면 소스 공개 의무가 없다. AGPL은 이 허점을 닫는다.

AGPL 코드를 수정하고 네트워크를 통해 서비스(SaaS)로 제공하면 수정된 소스 코드를 공개해야 한다.

MongoDB, Grafana 등은 상용 SaaS 경쟁자가 코드를 그대로 가져다 쓰는 것을 막기 위해 AGPL을 선택했다. 반면 SaaS 기업이 AGPL 라이브러리를 서버에 올리면 자사 코드 공개 의무가 생길 수 있어 대부분의 기업 정책에서 AGPL 사용을 금지 또는 제한한다.

주요 사용 사례: MongoDB (구버전), Grafana (일부), Nextcloud

BSD와 MPL — 중간 지점 라이선스

BSD 라이선스 (2-Clause, 3-Clause)

MIT와 매우 유사한 퍼미시브 라이선스다.

BSD 2-Clause: 저작권 표시 + 면책 조항 유지. MIT와 사실상 동일.
BSD 3-Clause: 2-Clause에 "기여자 이름을 홍보 목적으로 사용하지 말 것" 조항이 추가된다. 즉, 제품 광고에 "XX 대학교 XX 교수가 개발한 기술 적용"처럼 원 개발자를 동의 없이 홍보에 활용하면 안 된다.

MIT와 거의 같다고 봐도 무방하지만, 일부 오픈소스 정책에서는 BSD와 MIT를 구분해서 명시한다.

주요 사용 사례: FreeBSD, OpenBSD, NumPy (일부)

MPL 2.0 (Mozilla Public License)

MPL은 파일 단위 카피레프트다. GPL처럼 프로젝트 전체가 아니라, MPL로 라이선스된 파일을 수정했을 때만 그 파일을 같은 라이선스로 공개할 의무가 생긴다.

MPL 파일을 수정하지 않고 그대로 쓴다면 자사 코드를 공개할 필요가 없다.
MPL 파일을 수정했다면 수정된 MPL 파일만 공개하면 된다. 나머지 코드는 비공개 유지 가능.

GPL의 강한 카피레프트와 MIT의 완전 퍼미시브 사이에서 균형을 잡는다. 상용 소프트웨어에 포함하면서 수정 사항은 커뮤니티로 환원하게 유도하는 구조다.

주요 사용 사례: Firefox (Gecko), LibreOffice, Thunderbird

GPL과 AGPL — 카피레프트 라이선스 — 생태계 맵 시각화 — 오픈소스 라이선스 완벽 가이드 — 생태계 맵 시각화 (출처: 공식 문서 및 벤치마크 데이터 기반)

라이선스 비교표 — 상황별 의무

실무 선택 가이드 — 상황별 판단

내가 만드는 오픈소스 라이브러리 — 어떤 라이선스를 붙일까?

최대한 많이 쓰이길 원한다: MIT 또는 Apache 2.0. 기업이 채택하기 가장 쉽다.
기업이 공짜로 상업적 이용하는 걸 막고 싶다: AGPL v3. SaaS 제품으로 쓰려면 소스 공개 의무가 생긴다.
수정 사항은 공개하되 결합 제품은 자유롭게 하고 싶다: MPL 2.0.

오픈소스 라이브러리를 내 프로젝트에 포함할 때

GPL 라이브러리: 배포하는 최종 제품에 포함하면 GPL 의무가 전파될 수 있다. 법적 검토 필요. 사내에서만 쓴다면 배포가 아니므로 의무 없음.
AGPL 라이브러리: SaaS 서버에 올리면 소스 공개 의무. 대부분의 기업 OSPO(Open Source Program Office) 정책에서 AGPL 서버 사용을 금지 또는 별도 승인을 요구한다.

라이선스 호환성 주의

GPL v2 코드와 Apache 2.0 코드를 하나의 바이너리로 결합하면 라이선스 충돌이 발생할 수 있다. GPL v2는 Apache 2.0의 특허 종료 조항이 "추가 제한"에 해당한다고 볼 수 있기 때문이다. GPL v3와 Apache 2.0은 호환된다. 라이선스를 섞을 때는 각 조합의 호환성을 확인해야 한다. OSI(Open Source Initiative)나 FSF(Free Software Foundation)의 호환성 가이드를 참조하라.

실무 원칙: 상용 제품 또는 SaaS 개발자라면 의존성 라이브러리의 라이선스를 주기적으로 감사해야 한다. license-checker(npm), pip-licenses(Python), go-licenses(Go) 같은 도구로 자동화할 수 있다. CI 파이프라인에 라이선스 검사를 넣어두면 허용되지 않은 라이선스의 의존성이 추가될 때 알림을 받을 수 있다.

자주 묻는 질문

오픈소스 라이선스 완벽 가이드, 한 줄로 정리하면 어떻게 되나요?

라이선스 의무는 라이선스 종류가 아니라 코드를 어떻게 내보내느냐로 갈립니다. MIT·Apache·BSD 같은 퍼미시브 라이선스는 저작권 표시만 유지하면 상용 제품에 넣어도 되고, GPL은 바이너리를 외부에 배포하는 순간 제품 전체를 같은 라이선스로 공개해야 하며, AGPL은 SaaS로 서버에서 돌리기만 해도 수정한 소스를 공개해야 합니다. 사내에서만 쓰면 GPL이라도 공개 의무가 없다는 점까지 함께 기억하시면 됩니다.

실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?

라이브러리를 넣기 전에 던질 질문은 단 하나, '이 코드를 어떻게 배포하느냐'입니다. 사내 도구처럼 외부에 전달하지 않으면 GPL이라도 소스 공개 의무가 없고, 바이너리를 고객에게 배포하면 GPL은 제품 전체를 묶어버리며, SaaS로 서버에서만 돌리면 GPL은 안전하지만 AGPL은 수정 시 소스를 공개해야 합니다. 같은 라이브러리라도 배포 방식에 따라 의무가 완전히 갈리므로, 라이선스 종류보다 먼저 우리 제품의 전달 형태를 확정한 뒤 그 칸을 본문 비교표에서 읽으시면 됩니다.

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 흔한 사고는 직접 추가한 의존성만 보고 그 의존성이 다시 끌어오는 전이 의존성(transitive dependency)의 라이선스를 놓치는 것입니다. 최상위는 MIT인데 그 안에 GPL이나 AGPL 패키지가 숨어 있는 경우가 실제로 자주 나옵니다. 두 번째 함정은 같은 이름이라도 버전마다 라이선스가 바뀌는 경우로, MongoDB가 AGPL에서 SSPL로 갈아탄 것처럼 업그레이드 한 번에 의무가 달라집니다. 그래서 license-checker나 pip-licenses 같은 도구를 CI에 걸어 전체 의존성 트리를 매번 자동 점검하지 않으면 사람 눈으로는 반드시 빠뜨립니다.

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

내가 만든 라이브러리에 라이선스를 붙일 때 기준은 '남이 내 코드로 뭘 하길 허용하느냐'입니다. 채택률을 최대로 올리고 싶고 기업이 부담 없이 쓰길 원하면 MIT나 Apache 2.0이 맞습니다. 특허 분쟁 가능성이 있는 엔터프라이즈 환경이라면 특허 허여 조항이 있는 Apache 2.0이 MIT보다 안전합니다. 반대로 경쟁사가 내 코드로 SaaS를 차려 무임승차하는 걸 막고 싶으면 AGPL이 적합하고, 수정분만 환원받고 결합 제품은 비공개로 두고 싶으면 파일 단위 카피레프트인 MPL 2.0이 균형점입니다. 다만 라이브러리를 가져다 쓰는 입장에서 AGPL은 대부분 기업 정책상 금지되니, 폭넓게 쓰이는 게 목표라면 부적합합니다.

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

두 갈래로 권합니다. 첫째, 라이선스 본문을 직접 읽기 부담스럽다면 깃허브가 운영하는 Choose a License(choosealicense.com)에서 각 라이선스를 '허용·조건·제한' 표로 비교해 보세요. 둘째, 라이선스끼리 섞을 때의 호환성은 FSF의 라이선스 호환성 가이드(gnu.org/licenses)와 OSI 승인 목록에서 확인하시면 됩니다. 특히 GPL v2와 Apache 2.0이 왜 비호환인지, GPL v3와는 왜 호환인지를 이해하면 의존성 결합 사고를 거의 막을 수 있습니다. 실무 도구로는 license-checker(npm)·pip-licenses(Python)·go-licenses(Go)의 README를 읽고 CI에 거는 법을 익히는 것이 다음 단계입니다.

오픈소스라이선스MITGPLApache