오픈소스 라이선스 한눈에
— MIT·Apache·GPL부터 AGPL까지

1 핵심 개념 — 허용·의무·카피레프트

라이선스를 읽을 때 보는 축은 결국 셋입니다 — 무엇이 허용되는가, 무슨 의무가 따르는가, 내 코드까지 전염되는가.

• 허용(Permission) — 복제·배포·수정·상업적 이용 등 대부분 허용
• 의무(Condition) — 저작권·라이선스 고지, (경우에 따라) 소스 공개·변경 명시·동일 라이선스 적용
• 카피레프트(Copyleft) — "이걸 쓴 저작물도 같은 라이선스로 공개하라"는 상호주의(reciprocity)

2 두 갈래 — 허용적 vs 카피레프트

라이선스는 크게 허용적(Permissive)과 카피레프트(Copyleft)로 나뉘고, 카피레프트는 다시 전염 범위에 따라 강·약으로 갈립니다.

위로 갈수록 자유롭고(내 코드 비공개 OK), 아래로 갈수록 공개 의무가 넓어집니다. "어디까지 전염되느냐"가 곧 그 라이선스의 성격입니다.

3 MIT — 가장 단순한 허용적

가장 널리 쓰이는 라이선스. 사실상 "저작권·라이선스 고지만 유지하면 뭐든 해도 된다"입니다. 상업적 이용·수정·비공개 모두 자유. 카피레프트 없음.

허용  복제 · 배포 · 수정 · 상업적 이용 · 비공개(독점) 가능
의무  저작권 표시 + 라이선스 전문 포함
전염  없음 (내 코드 공개 의무 X)
// 면책: 소프트웨어는 "있는 그대로" 제공, 보증 없음

4 BSD (2·3-clause)

MIT와 거의 같은 허용적 라이선스. 차이는 조항 수입니다.

• 2-clause (Simplified) — 저작권 고지 + 면책. MIT와 사실상 동급
• 3-clause (New/Revised) — 여기에 "저작자 이름을 (사전 동의 없이) 홍보에 쓰지 말 것" 조항 추가

5 Apache 2.0 — 특허 조항 포함

허용적이면서 특허(patent)를 명시적으로 다루는 라이선스. 기업 환경에서 선호됩니다.

• 명시적 특허 라이선스 허락 — 기여자가 가진 관련 특허를 사용자에게 함께 허락
• 특허 보복 종료 조항 — 이 소프트웨어로 특허 소송을 걸면 특허 허락이 종료(방어적)
• 변경 고지 — 수정한 파일에 변경 사실을 표시. NOTICE 파일이 있으면 유지
• 카피레프트 아님 — 더 큰 저작물은 다른 라이선스로 배포 가능

6 GPL 2.0 / 3.0 — 강한 카피레프트

대표적 강한 카피레프트. GPL 코드를 포함해 배포하면, 결합된 저작물 전체를 소스와 함께 같은 GPL로 공개해야 합니다. "전염성"이 가장 강합니다.

배포 시  결합 저작물 전체 소스 공개 + 동일 GPL 적용
고지     저작권 · 라이선스 · 변경 사실
// "배포(distribution)"가 트리거 — 사내 사용만이면 공개 의무 X

2.0 vs 3.0

• GPL 3.0 추가: 특허 보복 방지, Tivoization 금지(하드웨어로 수정 실행을 막는 것 차단), 추가 권한 명문화
• 호환성: GPLv3는 Apache 2.0·AGPL 3.0과 호환. GPLv2-only ↔ GPLv3는 서로 비호환(그래서 "GPLv2 or later" 표기가 중요)

7 LGPL — 약한 카피레프트(링크)

GPL을 라이브러리용으로 완화한 것. 라이브러리 자체의 수정분은 공개해야 하지만, 그 라이브러리를 링크해서 쓰는 내 애플리케이션은 독점으로 유지할 수 있습니다.

• LGPL 라이브러리 수정 → 그 부분은 공개(2차 저작물 의무)
• 단순히 링크(특히 동적 링크)해서 사용 → 내 앱 공개 의무 없음
• 사용자가 라이브러리를 교체할 수 있어야 한다는 조건(동적 링크면 자연히 충족)

8 AGPL 3.0 — 네트워크까지

GPL의 빈틈을 메운 라이선스. GPL은 "배포"에만 의무가 걸려서, 코드를 고쳐 서버에만 올려 서비스(SaaS)로 제공하면 소스를 안 줘도 됐습니다. AGPL은 이 네트워크 사용까지 공개 의무를 확장합니다.

• 네트워크로 서비스하면 그 사용자에게도 (수정 포함) 소스를 제공해야 함
• 강한 카피레프트 + 네트워크 조항 → 가장 강력한 공개 의무

9 MPL 2.0 — 파일 단위

파일 단위(file-level) 카피레프트. 수정한 그 파일들만 공개하면 되고, 더 큰 저작물(내 앱)은 다른 라이선스로 둘 수 있습니다. 허용적과 강한 카피레프트의 중간.

• MPL 파일을 수정 → 그 파일은 MPL로 공개
• 그 파일을 포함한 더 큰 프로그램은 독점 가능
• GPL 2.0과 호환(부속 허가), 단 GPL 3.0과의 결합은 별도 확인 필요

10 한눈 비교표

※ "소스공개·동일 라이선스"는 배포(또는 네트워크 제공) 시 발생하는 의무입니다. 사내에서만 쓰면 대체로 트리거되지 않습니다(AGPL 제외 주의).

11 실무 선택 가이드

내 코드를 공개할 때 — 어떤 라이선스를 붙일까

• 최대한 널리 쓰이길 원함 → MIT 또는 Apache 2.0(특허 보호까지 원하면 Apache)
• 기여를 공개로 환원받고 싶음 → MPL 2.0(파일 단위) 또는 LGPL(라이브러리)
• 파생물도 무조건 오픈소스이길 강제 → GPL 3.0, 서비스(SaaS)까지면 AGPL 3.0

남의 코드를 가져다 쓸 때 — 체크리스트

• ① 의존성의 라이선스를 전부 목록화(SBOM). 전이 의존성까지
• ② 배포 형태 확인 — 바이너리 배포? 라이브러리 링크? SaaS? (트리거가 달라짐)
• ③ 카피레프트(GPL/AGPL)가 제품 코드에 결합되는지 — 결합되면 공개 의무 검토
• ④ 고지 의무 이행 — 저작권·라이선스 전문·NOTICE 동봉(거의 모든 라이선스 공통)
• ⑤ 라이선스 호환성 — 예: Apache 2.0 ↔ GPLv2 비호환

정리

라이선스를 가르는 한 가지 질문은 "내 코드까지 공개해야 하나?"입니다.

• 허용적(MIT·BSD·Apache) — 고지만 하면 끝. 내 코드는 비공개 가능
• 약한 카피레프트(MPL·LGPL) — 가져온/수정한 부분만 공개
• 강한 카피레프트(GPL·AGPL) — 결합 저작물 전체 공개, AGPL은 SaaS까지