오픈 소스 라이선스 설명: 좋은 점, 나쁜 점, 그리고 '잠깐, 이걸 실제로 사용할 수 있나요?'

Source: Dev.to

Introduction

멋진 무언가를 만들었고 오픈소스로 공개하고 싶나요? GitHub에서 “Choose a license”를 클릭하면 MIT, Apache 2.0, GPL v3, AGPL, BSD, MPL, ISC, Unlicense 등 수많은 옵션이 나타납니다. 특히 사람들이 코드를 사용해 주기만을 원한다면 압도적으로 느껴질 수 있습니다.

아래는 가장 흔히 쓰이는 오픈소스 라이선스들을 쉬운 영어(한국어)로 정리한 가이드이며, 각 라이선스가 실제로 허용하는 내용과 언제 선택하면 좋은지 설명합니다.

---

The spectrum: permissive ↔ copyleft

Permissive  ←--------------------------→  Copyleft
(do whatever)                         (share improvements)

MIT / BSD → Apache 2.0 → MPL → LGPL → GPL → AGPL

• Permissive licenses는 코드를 거의 제한 없이 사용할 수 있게 해 주며, 상용 제품에 포함시킬 수도 있습니다.
• Copyleft licenses는 수정본을 동일한 라이선스로 배포하도록 요구해 개선 사항이 계속 오픈되도록 합니다.

---

License breakdown

MIT (and BSD‑style)

What it says (simplified)

“Use this code however you want. Just keep my copyright notice. I’m not responsible if it breaks.”

Key points

• 상업적 사용, 수정, 배포, 재라이선스 모두 허용합니다.
• 변경 사항을 공유할 의무가 없습니다.
• 매우 짧고 널리 이해됩니다.

Typical projects
React (원래 BSD‑style), Node.js, jQuery, Tailwind CSS.

When to choose it

• 최대한 많은 채택을 원할 때.
• 기업이 여러분의 작업을 수익화하는 것이 괜찮을 때.
• 간단하고 관대한 라이선스가 필요할 때.

---

Apache 2.0

What it adds over MIT

• 특허 보호 – 기여자는 영구적이고 전 세계적인 무상 특허 라이선스를 부여합니다.
• 상표 보호 – 프로젝트 이름을 허가 없이 홍보에 사용할 수 없습니다.

Example clause (patent grant)

3. Grant of Patent License.  Each Contributor hereby grants to You a
   perpetual, worldwide, non‑exclusive, no‑charge, royalty‑free patent
   license to make, use, sell, offer for sale, import, and otherwise
   transfer the Work, where such license applies only to those patent
   claims licensable by such Contributor that are necessarily infringed
   by their Contribution(s) alone or by combination of their
   Contribution(s) with the Work to which such Contribution(s) was
   submitted.

Typical projects
Kubernetes, TensorFlow, Android, Swift.

When to choose it

• 특허를 보유하고 있거나 특허를 신청할 가능성이 있을 때.
• 기여자를 특허 트롤로부터 보호하고 싶을 때.
• 인프라스트럭처 프로젝트처럼 특허 위험이 중요한 경우.

---

BSD (2‑clause / 3‑clause)

What it says – MIT와 거의 동일하지만, 저자의 이름을 파생 작업에 사용하지 못하도록 하는 조항이 추가됩니다.

Example clause (endorsement)

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived
   from this software without specific prior written permission.

Typical projects
FreeBSD, OpenBSD, nginx.

When to choose it

• MIT와 같은 목표이지만 “보증 혼동”을 피하고 싶을 때.

---

GPL v3 (General Public License)

What it says (simplified)

• 소프트웨어를 사용·수정·배포할 수 있습니다.
• 수정본을 배포할 경우 반드시 소스 코드를 GPL v3로 공개해야 합니다.
• 컴파일된 바이너리에 대한 설치 방법을 제공해야 합니다.

Typical projects
Linux kernel, Git, WordPress, GIMP.

When to choose it

• 자유 소프트웨어 철학을 믿을 때.
• 개선 사항이 되돌아오길 원할 때.
• “바이럴” 특성이 상용 사용을 억제해도 괜찮을 때.

Gotcha: SaaS 제공자는 소프트웨어를 배포하지 않으므로(서버에서만 실행) 변경 사항을 공유할 의무가 없습니다.

---

AGPL v3 (Affero GPL)

What it adds – 네트워크를 통해 소프트웨어와 상호작용하는 경우에도 수정본 소스를 공유해야 합니다.

Typical projects
MongoDB (원래 AGPL), Grafana, GitLab CE, Mastodon, Nextcloud.

When to choose it

• 데이터베이스, 백엔드 서비스 등 인프라를 구축할 때.
• 클라우드 제공자가 여러분의 작업을 “스트립‑마이닝”하는 것을 방지하고 싶을 때.
• 상업적 채택을 어느 정도 제한해도 괜찮을 때.

---

LGPL v2.1 / v3 (Lesser GPL)

What it says – 라이브러리를 링크해서 상용 소프트웨어에 사용할 수 있지만, 라이브러리 자체를 수정하면 LGPL로 공개해야 합니다.

Typical projects
Qt, FFmpeg, GStreamer.

When to choose it

• 다른 사람(상용 앱 포함)이 사용할 수 있는 라이브러리를 배포하고 싶을 때.
• 라이브러리 자체의 개선은 오픈소스로 유지하고 싶을 때.

---

MPL 2.0 (Mozilla Public License)

What it says – copyleft이 파일 단위로 적용됩니다. 수정한 파일은 MPL을 유지해야 하지만, 새 파일은 어떤 라이선스든 사용할 수 있습니다.

Typical projects
Firefox, Thunderbird, LibreOffice.

When to choose it

• 관대함과 강력한 copyleft 사이의 중간 지점을 원할 때.
• 혼합 라이선스 코드베이스에 익숙할 때.

---

Unlicense (public domain)

What it says – “퍼블릭 도메인입니다. 뭐든지 하세요. 모든 권리를 포기합니다.”

Typical use cases – 작은 유틸리티, 교육용 예제.

Caveat – 일부 관할권에서는 저작권 포기가 법적으로 인정되지 않을 수 있어, Unlicense가 모든 곳에서 효력이 없을 수 있습니다. 사실상 동일한 효과를 갖는 MIT 라이선스가 더 안전합니다.

---

Choosing a license – decision tree

├─ "최대한 많이 채택하고 싶다"
│   └─ MIT 또는 Apache 2.0
│
├─ "개선 사항을 되돌려 받고 싶다"
│   ├─ 라이브러리 → LGPL 또는 MPL
│   ├─ 애플리케이션 / 서비스 → GPL
│   └─ SaaS → AGPL
│
├─ "클라우드 거인들이 이익을 얻는 걸 막고 싶다"
│   └─ AGPL
│
└─ "전혀 신경 쓰지 않는다"
    └─ MIT 또는 Unlicense

---

Compatibility matrix

Rule of thumb

• **관대형 라이선스(MIT, Apache)**는 다른 어떤 라이선스와도 결합할 수 있습니다.
• GPL은 프로젝트 전체에 “감염”됩니다—GPL 코드를 포함하면 전체 배포물이 GPL이어야 합니다.
• AGPL은 가장 제한적이며, 네트워크 사용 조항까지 추가됩니다.

---

Real‑world pitfalls & lessons

1. No license = legal limbo

개발자가 npm 패키지를 라이선스 없이 공개했습니다. 스타트업이 이를 사용했고, 개발자가 소송을 제기했을 때 법원은 라이선스가 없으면 “모든 권리 보유”라고 판단했습니다. 어느 쪽도 자신의 주장을 강제할 수 없었습니다.

Lesson: 반드시 라이선스를 포함하세요; “라이선스 없음”은 “무료 사용”과 동일하지 않습니다.

2. Patent clauses can backfire

Facebook은 React를 BSD‑style 라이선스와 특허 보복 조항(“특허 소송을 하면 React 라이선스를 잃는다”)으로 공개했습니다. 커뮤니티의 반발로 React를 MIT로 다시 라이선스했습니다.

Lesson: 특허 조항은 강력하지만 사용자에게 거부감을 줄 수 있습니다.

3. Adding restrictive clauses mid‑project hurts adoption

Redis Labs는 일부 모듈에 “Commons Clause”(“이 소프트웨어를 판매할 수 없다”)를 추가했습니다. 이는 오픈소스 정의를 위반한 것으로, 커뮤니티가 프로젝트를 포크해 Valkey를 만들었습니다.

Lesson: 출시 후 라이선스를 더 제한적으로 바꾸면 커뮤니티가 분열될 위험이 있습니다.

4. Cloud providers and AGPL

MongoDB의 AGPL 덕분에 AWS가 호환 “DocumentDB” 서비스를 제공했지만 소스 기여는 없었습니다. 이에 MongoDB는 SSPL(Server Side Public License)로 전환했습니다.

Lesson: AGPL도 대형 클라우드 제공자가 호스팅 서비스를 제공하는 것을 완전히 막지는 못합니다; 추가 비즈니스 모델을 고민해야 합니다.

5. GPL and SaaS

Linksys는 수정된 Linux 커널(GPL)로 라우터를 출하했지만 소스를 공개하지 않았습니다. GPL 커뮤니티가 소송을 제기했고, Linksys는 소스 공개를 강제당했으며, 이는 DD‑WRT·OpenWRT 같은 커뮤니티 펌웨어 프로젝트를 촉발했습니다.

Lesson: GPL 시행은 배포된 바이너리의 소스 공개를 강제하지만, 순수 SaaS에는 적용되지 않을 수 있습니다.

---

Quick recommendations

---

Final checklist

1. 목표 정의 – 채택, 기여 회수, 특허 보호, 클라우드 악용 방지 등.
2. 목표에 맞는 가장 간단한 라이선스 선택 – 복잡하게 만들지 마세요.
3. 리포지토리 루트에 LICENSE 파일 추가.
4. 각 소스 파일에 짧은 헤더 삽입 (예: “© 2025 Your Name – SPDX‑License‑Identifier: MIT”).
5. 추가 정책 문서화 – 기여 가이드라인, 행동 강령 등.

올바른 라이선스를 선택하면 프로젝트가 번창하면서도 여러분이 원하는 수준의 통제권을 유지할 수 있습니다. 즐거운 오픈소싱 되세요!