| 라이선스 | 상업적 사용 | 수정 | 배포 | 소스 공개 의무 | 특허권 | 같은 라이선스 적용 의무 |
|---|---|---|---|---|---|---|
| MIT | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Apache 2.0 | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ |
| BSD 2-Clause | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| BSD 3-Clause | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| BSL 1.0 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Unlicense | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| CC0 1.0 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| MPL 2.0 | ✅ | ✅ | ✅ | ⚠️ 파일 단위 | ✅ | ⚠️ 파일 단위 |
| LGPL 2.1 | ✅ | ✅ | ✅ | ⚠️ 라이브러리 | ✅ | ⚠️ 라이브러리 |
| EPL 2.0 | ✅ | ✅ | ✅ | ⚠️ 모듈 단위 | ✅ | ⚠️ 모듈 단위 |
| GPL 2.0 | ✅ | ✅ | ✅ | ✅ 전체 | ❌ | ✅ |
| GPL 3.0 | ✅ | ✅ | ✅ | ✅ 전체 | ✅ | ✅ |
| AGPL 3.0 | ✅ | ✅ | ✅ | ✅ 전체 + 네트워크 | ✅ | ✅ |
| No license | ❌ | ❌ | ❌ | - | - | - |
⚠️ = 조건부, ✅ = 허용/필수, ❌ = 없음/불가
각 라이선스 상세 설명
MIT License
가장 단순하고 널리 쓰이는 라이선스다. 저작권 표시만 유지하면 복사, 수정, 배포, 상업적 사용 모두 자유롭다. React, jQuery, Node.js, Rails 등 수많은 프로젝트가 채택하고 있다.
핵심 조건은 딱 하나, 원본 저작권 표시와 라이선스 문구를 포함하는 것이다.
Apache License 2.0
MIT와 비슷하게 관대하지만, 특허권 조항이 추가되어 있다. 기여자가 보유한 관련 특허에 대해 자동으로 사용 권한이 부여된다. 대신 특허 소송을 걸면 라이선스가 즉시 종료된다. Kubernetes, Android, TensorFlow 등 대규모 기업 프로젝트에서 주로 사용한다.
MIT와의 차이점은 수정 사항을 명시해야 하고, NOTICE 파일이 있으면 반드시 포함해야 한다는 점이다.
BSD 2-Clause "Simplified" License
MIT와 거의 동일한 수준의 관대한 라이선스다. 저작권 표시와 라이선스 문구만 유지하면 된다. FreeBSD 등에서 사용한다.
BSD 3-Clause "New" or "Revised" License
BSD 2-Clause에 한 가지 조항이 추가된다. 원저작자의 이름을 허가 없이 홍보 목적으로 사용할 수 없다. Go 언어, Django 등에서 채택하고 있다.
Boost Software License 1.0 (BSL 1.0)
C++ Boost 라이브러리를 위해 만들어진 라이선스다. 소스 코드 배포 시에만 라이선스 문구를 포함하면 되고, 바이너리 배포 시에는 아무 조건이 없다. 이 점이 MIT와의 가장 큰 차이다.
Creative Commons Zero v1.0 Universal (CC0 1.0)
저작권을 완전히 포기하는 선언이다. 퍼블릭 도메인으로 헌정하며, 법적으로 퍼블릭 도메인이 불가능한 지역을 위해 대체 라이선스도 포함한다. 데이터셋, 문서, 사양서 등 비-소프트웨어 저작물에 주로 사용된다.
The Unlicense
소프트웨어를 퍼블릭 도메인에 두는 것이 목적이다. CC0과 유사하지만 소프트웨어에 더 초점이 맞춰져 있다. 아무 조건 없이 자유롭게 사용 가능하다.
Mozilla Public License 2.0 (MPL 2.0)
파일 단위 카피레프트다. MPL로 라이선스된 파일을 수정하면 그 파일은 MPL로 공개해야 하지만, 새로 추가한 파일은 다른 라이선스(심지어 독점 라이선스)를 적용할 수 있다. Firefox, Thunderbird 등 Mozilla 프로젝트에서 사용한다.
GPL과 Apache의 중간 지점에 위치하는 라이선스다.
GNU Lesser General Public License v2.1 (LGPL 2.1)
라이브러리 단위 카피레프트다. LGPL 라이브러리 자체를 수정하면 소스를 공개해야 하지만, 라이브러리를 단순히 링크해서 사용하는 프로그램은 소스 공개 의무가 없다. 따라서 독점 소프트웨어에서도 LGPL 라이브러리를 사용할 수 있다. Qt, GTK, FFmpeg 등이 채택하고 있다.
Eclipse Public License 2.0 (EPL 2.0)
모듈 단위 카피레프트다. 수정한 모듈은 공개해야 하지만, 별도 모듈로 작성한 코드는 자유롭게 라이선스를 선택할 수 있다. Eclipse IDE 생태계에서 주로 사용한다. GPL과의 비호환성 때문에 GPL 코드와 섞어 쓸 때 주의가 필요하다.
GNU General Public License v2.0 (GPL 2.0)
강한 카피레프트의 대표격이다. GPL 코드를 사용한 파생 저작물은 전체를 GPL로 공개해야 한다. Linux 커널이 GPL 2.0을 사용한다. GPL 3.0과 달리 특허 조항이 명시적으로 없고, "or later version" 조항을 선택적으로 포함할 수 있다.
GNU General Public License v3.0 (GPL 3.0)
GPL 2.0의 업그레이드 버전이다. 특허 보복 조항, Tivoization 방지(하드웨어에서 수정된 소프트웨어 실행을 차단하는 것을 금지), DRM 관련 조항이 추가되었다. Bash, GIMP, WordPress 등에서 사용한다.
GNU Affero General Public License v3.0 (AGPL 3.0)
GPL 3.0에 네트워크 조항이 추가된 가장 강력한 카피레프트 라이선스다. 소프트웨어를 배포하지 않더라도, 네트워크를 통해 서비스를 제공하면 소스 코드를 공개해야 한다. 이 조항은 SaaS 형태로 GPL의 소스 공개 의무를 회피하는 것(이른바 "ASP 루프홀")을 방지하기 위해 만들어졌다. MongoDB(과거), Grafana 등에서 채택했다.
No license (라이선스 없음)
라이선스가 없으면 기본 저작권법이 적용된다. 코드를 볼 수는 있지만, 복사, 수정, 배포가 모두 금지된다. 오픈소스처럼 보이지만 실제로는 가장 제한적인 상태다.
카피레프트 강도 비교
제한 없음 가장 강한 제한
│ │
▼ ▼
Unlicense/CC0 → MIT/BSD → Apache → MPL → LGPL → EPL → GPL → AGPL
퍼블릭도메인 관대함 +특허 파일단위 라이브러리 모듈단위 전체 +네트워크어떤 라이선스를 선택할까?
| 목적 | 추천 라이선스 |
|---|---|
| 최대한 자유롭게 쓰이길 원함 | MIT, Unlicense |
| 특허 보호도 필요함 | Apache 2.0 |
| 수정한 파일만 공개하길 원함 | MPL 2.0 |
| 라이브러리인데 독점 SW에서도 쓰이길 원함 | LGPL 2.1 |
| 파생 저작물도 반드시 오픈소스여야 함 | GPL 3.0 |
| SaaS로 우회하는 것도 막고 싶음 | AGPL 3.0 |
| 데이터/문서/비소프트웨어 저작물 | CC0 1.0 |
| C++ Boost 생태계 | BSL 1.0 |
자주 묻는 질문
Q. GPL 코드를 상업적으로 사용할 수 있나?
상업적 사용 자체는 가능하다. 다만 배포 시 전체 소스 코드를 GPL로 공개해야 한다.
Q. MIT와 BSD의 차이는?
실질적으로 거의 없다. BSD 3-Clause는 원저작자 이름의 홍보 목적 사용을 금지하는 조항이 하나 더 있을 뿐이다.
Q. LGPL 라이브러리를 사용하면 내 코드도 공개해야 하나?
동적 링크(dynamic linking)로 사용하면 공개 의무가 없다. LGPL 라이브러리 자체를 수정한 경우에만 해당 수정분을 공개하면 된다.
Q. 라이선스 없이 올린 코드를 포크해도 되나?
GitHub의 이용약관상 공개 레포지토리를 포크하고 볼 수는 있지만, 복사·수정·배포·사용은 저작권자의 명시적 허가 없이 할 수 없다.
Q. AGPL과 GPL의 실질적 차이는?
서버에서 실행만 하고 배포하지 않는 경우, GPL은 소스 공개 의무가 없지만 AGPL은 네트워크를 통해 서비스를 제공하는 것만으로도 소스 공개 의무가 발생한다.
