오픈소스 라이선스 실무 가이드 — MIT, Apache 2.0, GPL 프로젝트별 선택법

오픈소스 라이선스를 무시했다가 법적·사업적으로 타격을 받은 사례는 실제로 존재한다. 2008년 Cisco는 GPL 라이선스 코드가 포함된 Linksys 라우터 펌웨어를 라이선스 의무를 이행하지 않고 배포해 SFLC(Software Freedom Law Center)로부터 소송을 당했다. 2017년에는 Artifex Software가 자사의 GPL 라이선스 소프트웨어 Ghostscript를 상용 제품에 포함하면서 라이선스 비용을 지불하지 않은 Hancom(한컴)을 상대로 미국 법원에서 승소했다.

기업 법무팀이 오픈소스 컴플라이언스에서 체크하는 핵심 포인트는 세 가지다. 첫째, 의존성 트리의 라이선스 전파 여부: npm 패키지 하나를 쓰면 그 패키지가 의존하는 패키지들의 라이선스까지 연쇄적으로 따라온다. 둘째, 소스 공개 의무 발생 여부: GPL 계열 코드를 제품에 포함하면 해당 제품 소스 전체를 공개해야 할 수 있다. 셋째, 특허 조항 유무: Apache 2.0은 기여자가 자신의 특허를 사용자에게 명시적으로 부여하지만, MIT에는 이 조항이 없다.

스타트업에서 오픈소스 컴플라이언스가 현실적 문제로 부각되는 시점은 주로 M&A 실사(Due Diligence)다. 대기업이 스타트업을 인수하려 할 때 소프트웨어 BOM(Bill of Materials)과 각 컴포넌트의 라이선스를 요구한다. GPL 코드가 상용 제품 핵심부에 들어가 있다면 인수 가격 협상에 직접 영향을 미치거나 딜이 무산될 수 있다.

SaaS 제품을 운영하는 팀이라면 AGPL(Affero GPL)을 특히 주의해야 한다. GPL의 SaaS 루프홀(네트워크를 통해 제공하는 서비스는 소스 공개 의무가 없다는 허점)을 막기 위해 만들어진 라이선스로, AGPL 코드를 서버에서 실행하면 해당 서비스 전체 소스를 공개해야 할 수 있다. MongoDB, Elasticsearch(구버전), Grafana 등이 AGPL을 채택한 이유다.

OSI(Open Source Initiative)가 승인한 라이선스는 100종이 넘지만, 실무에서 마주치는 대부분의 오픈소스 소프트웨어는 MIT, Apache 2.0, BSD, GPL v3, LGPL 중 하나에 해당한다. 아래 표는 판단에 필요한 핵심 항목만 정리했다.

Copyleft 강도가 핵심 판단 기준이다. MIT·BSD·Apache 2.0은 Permissive(허용적) 라이선스로 분류된다. 소스를 공개하지 않고 상용 제품에 포함할 수 있다. GPL/LGPL/AGPL은 Copyleft 라이선스로, 파생 저작물에도 같은 조건을 적용해야 한다는 "바이럴(viral)" 특성이 있다.

Apache 2.0과 MIT의 가장 큰 실무 차이는 특허 조항이다. Apache 2.0은 기여자가 자신의 특허를 소프트웨어 사용자에게 무상으로 허락한다는 조항이 명문화되어 있다. 특허 소송 위험이 있는 대형 프로젝트에서 Apache 2.0이 선택되는 이유다. MIT에는 이 조항이 없으므로, MIT 라이선스 코드를 사용해도 기여자의 특허에 대한 보호는 받지 못한다.

MIT 라이선스는 오픈소스 라이선스 중 가장 짧고 단순하다. 핵심 의무는 단 하나, 저작권 고지(copyright notice)와 라이선스 전문을 소프트웨어 사본에 포함하는 것이다. 수정, 재배포, 상업적 사용, 사유화(Proprietary화) 모두 허용된다.

자주 오해하는 점이 있다. MIT는 소스코드를 공개하지 않아도 되지만, 바이너리(실행 파일, 빌드 결과물) 배포 시에도 저작권 고지를 포함해야 한다. 모바일 앱 배포 패키지, 도커 이미지, npm 패키지 등 배포 형태와 관계없이 MIT 라이선스 전문과 저작권 고지를 포함해야 한다. 많은 팀이 앱 스토어 앱에서 이 의무를 이행하지 않는 경우가 있다.

특허 보호 부재가 MIT의 가장 큰 함정이다. 예를 들어, 기업 A가 특정 알고리즘에 대한 특허를 보유하면서 해당 알고리즘을 구현한 코드를 MIT로 오픈소스화했다고 가정하자. 개발자가 이 코드를 상용 제품에 사용할 경우, 저작권 관점에서는 MIT 라이선스로 보호받지만 특허 침해는 별개의 문제로 남는다. 이런 이유로 아마존, 구글 등 대기업의 핵심 오픈소스 프로젝트는 Apache 2.0을 선택한다.

MIT를 선택하기 좋은 경우: 개인 라이브러리, 학습용 프로젝트, 널리 쓰이길 원하는 유틸리티 패키지. 채택 장벽을 최소화하고 싶을 때 적합하다. React(Facebook/Meta), Vue.js, jQuery, Rails, Express.js 모두 MIT다.

Apache 2.0은 허용적(Permissive) 라이선스이면서 MIT보다 훨씬 상세한 법적 구조를 갖는다. 기업 환경에서 선호되는 이유는 크게 세 가지다.

1. 명시적 특허 부여(Patent Grant): Apache 2.0 Section 3은 기여자가 자신의 특허 중 소프트웨어 사용에 필요한 특허를 사용자에게 무상으로, 비독점적으로, 영구적으로 허락한다고 명시한다. 단, 특허 소송을 제기하면 특허 허락이 자동 종료된다(특허 보복 조항). 이 구조가 오픈소스 기여를 장려하면서 특허 소송 위험을 낮춘다.

2. 기여자 라이선스 계약(CLA)과 함께 운용 가능: Apache Software Foundation이 운영하는 대형 프로젝트들은 ICLA(Individual CLA)와 CCLA(Corporate CLA)를 요구한다. 기업 직원이 회사 업무로 기여할 때 법적 명확성을 확보하기 위함이다. 구글, 마이크로소프트, 아마존 모두 자사 주요 오픈소스 프로젝트에 CLA와 Apache 2.0을 조합한다.

3. 상표권 분리: Apache 2.0은 소프트웨어 자체와 프로젝트 이름/로고(상표)를 명확히 분리한다. 누구나 코드를 fork해 수정·배포할 수 있지만, 원본 프로젝트 이름이나 로고는 쓸 수 없다. AWS의 "Elasticsearch Service"가 나중에 "OpenSearch Service"로 이름을 바꾼 것도 Elastic이 상표권을 이용해 제한을 걸었기 때문이다.

Kubernetes, TensorFlow, Apache Kafka, Apache Spark, Android(AOSP), Swift, Go 언어 표준 라이브러리 등이 Apache 2.0을 채택하고 있다. 대형 생태계를 만들면서 특허 위험을 관리하고 기업 참여를 유도하기에 최적화된 라이선스다.

주의할 점: Apache 2.0 코드를 GPL v2 코드와 함께 배포할 수 없다. GPL v2와 Apache 2.0은 라이선스 조건이 충돌하기 때문이다(GPL v2는 추가 제한을 금지하는데, Apache 2.0의 특허 보복 조항이 추가 제한으로 해석될 수 있다). GPL v3과는 호환된다. Linux 커널이 GPL v2인 이유로 일부 Apache 2.0 컴포넌트를 직접 커널에 통합하지 못하는 제약이 여기서 나온다.

GPL(GNU General Public License)은 리처드 스톨만이 자유 소프트웨어 운동의 철학을 법적 구조로 구현한 라이선스다. 핵심은 "자유롭게 받은 것은 자유롭게 나누어야 한다"는 copyleft 원칙이다. GPL 코드를 수정하거나 포함한 소프트웨어를 배포하면, 그 소프트웨어 전체를 GPL로 공개해야 한다.

GPL v2 vs v3 주요 차이:

LGPL(Lesser GPL)은 라이브러리 배포를 위해 만들어진 약한 Copyleft다. LGPL 라이브러리를 동적 링킹(dynamic linking)으로 사용할 경우, 해당 라이브러리를 수정하지 않는 한 자신의 코드를 공개할 의무가 없다. 단, 정적 링킹(static linking)으로 LGPL 라이브러리를 포함하면 파생 저작물로 간주되어 소스 공개 의무가 발생할 수 있다. GNU libstdc++, FFmpeg 일부 빌드가 LGPL이다.

AGPL(Affero GPL)은 SaaS 환경을 위한 강화된 Copyleft다. GPL에는 "배포"가 이루어질 때만 소스 공개 의무가 발생하는데, 소스를 배포하지 않고 서버에서 실행하는 SaaS는 이 의무를 피할 수 있었다(SaaS 루프홀). AGPL은 "네트워크를 통해 서비스를 제공"하는 것도 배포와 동일하게 취급해 이 허점을 막는다. MongoDB Community Edition, Grafana, Nextcloud가 AGPL을 채택하고 있다.

라이선스 선택은 프로젝트 목적, 비즈니스 모델, 생태계 전략에 따라 달라진다. 아래는 유형별 실무 권장 사항이다.

개인 사이드 프로젝트 / 학습용 코드
MIT 또는 BSD를 선택한다. 채택 장벽이 없고 다른 개발자가 자유롭게 참고할 수 있다. 라이선스 관리 부담이 가장 적다. 단, 해당 코드를 기반으로 나중에 사업화할 계획이 있다면 Apache 2.0을 고려하는 것이 낫다.

스타트업 상용 제품에 포함되는 라이브러리나 SDK
Apache 2.0을 권장한다. 특허 보호, 기업 법무 친화성, 대형 생태계와의 호환성 등 모든 면에서 MIT보다 낫다. 저작권 고지 의무는 동일하지만 특허 리스크를 명확히 관리할 수 있다.

기업 내부 도구 (배포 없음)
사내에서만 사용하는 소프트웨어는 GPL 코드를 써도 소스 공개 의무가 발생하지 않는다. GPL의 copyleft는 "배포"를 트리거로 하기 때문이다. 단, AGPL은 사내에서도 네트워크 서비스로 제공하면 적용 여부를 검토해야 한다. 실질적으로는 MIT나 Apache 2.0 기반 의존성을 사용하는 것이 관리가 간단하다.

자신의 오픈소스 프로젝트를 공개할 때
상업적 착취를 원치 않는다면 AGPL, 최대한 많은 곳에서 쓰이길 원한다면 MIT, 기업 참여와 커뮤니티 균형을 원한다면 Apache 2.0이 맞다. "이중 라이선스" 전략도 있다: 커뮤니티 버전은 GPL/AGPL, 상용 고객은 상용 라이선스를 구매. MySQL, Elastic(구버전), GitLab EE가 이 모델을 사용한다.

의존성 라이선스를 자동으로 점검하는 도구로 license-checker(npm), LicenseFinder(Ruby/Python), FOSSA CLI 등이 있다. CI 파이프라인에 통합해 금지 라이선스(예: GPL, AGPL)가 의존성에 포함될 경우 빌드를 차단하는 방식으로 컴플라이언스를 자동화할 수 있다.