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

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

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

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

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

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

MIT 라이선스

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

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

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

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

Apache 2.0 라이선스

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

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

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

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

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 라이선스 (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

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

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

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

• MIT/BSD 라이브러리: 저작권 표시만 유지. 상용·비공개 프로젝트 모두 문제없다.
• Apache 2.0 라이브러리: 저작권 표시 + NOTICE 파일 포함. 수정했으면 명시. 상용 가능.
• 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)의 호환성 가이드를 참조하라.