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

Note

“오픈소스니까 그냥 써도 되지?” — 아닙니다. 오픈소스도 저작권이 있는 소프트웨어이고, 라이선스는 “이 조건을 지키면 써도 된다”는 이용 허락 계약입니다. 조건을 어기면 저작권 침해가 됩니다. 특히 어떤 라이선스는 내 코드까지 같은 라이선스로 공개하라고 요구해서, 모르고 가져다 쓰면 사업 전체가 흔들릴 수 있습니다.

이 글에서는 가장 많이 쓰이는 MIT·Apache 2.0·GPL을 중심으로, BSD·LGPL·MPL·AGPL까지 핵심 의무를 정리하고 한눈 비교표와 실무 선택 가이드를 제공합니다. (분류·용어는 오픈소스SW 라이선스 종합정보시스템(OLIS) 기준을 따릅니다.)

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

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

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

Tip

고지 의무는 거의 공통 어떤 라이선스든 최소한 저작권 표시와 라이선스 전문(또는 고지)을 유지하라고 요구합니다. “그냥 복붙”이 위험한 가장 흔한 이유가 이 고지를 빠뜨리는 것입니다.

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

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

허용적 (고지만, 전염 없음) MIT · BSD · Apache 2.0 카피레프트 (상호주의 — 같은 라이선스로 공개) 약 │ MPL 2.0 (파일 단위) │ LGPL (라이브러리/링크 단위) 강 │ GPL (결합 저작물 전체) │ AGPL (네트워크 서비스까지)

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

3 MIT — 가장 단순한 허용적

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

의무MIT

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

Tip

라이브러리·예제·스타터 템플릿에 가장 무난. 받는 쪽 부담이 거의 없어 채택률이 가장 높습니다.

4 BSD (2·3-clause)

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

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

Note

3-clause의 비보증(non-endorsement) “이 제품은 ○○가 만들었다”는 식으로 원저작자를 끌어다 마케팅하는 걸 막는 조항입니다. 의무는 여전히 가벼워서 허용적으로 분류됩니다.

5 Apache 2.0 — 특허 조항 포함

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

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

Warning

Apache 2.0 ↔ GPLv2 비호환 Apache 2.0의 특허·추가 조건 때문에 GPL 2.0과는 한 저작물로 결합 시 비호환으로 봅니다. 반면 GPL 3.0과는 호환(GPLv3가 이를 수용). 코드 결합 시 라이선스 호환성을 꼭 확인하세요.

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

대표적 강한 카피레프트. GPL 코드를 포함해 배포하면, 결합된 저작물 전체를 소스와 함께 같은 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” 표기가 중요)

Warning

제품에 GPL을 섞기 전에 독점 소프트웨어에 GPL 라이브러리를 정적/동적으로 결합해 배포하면, 그 제품 전체를 GPL로 공개해야 할 수 있습니다. SaaS로만 제공하면(배포 아님) GPL은 트리거되지 않지만 — 그건 AGPL이 막습니다(아래).

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

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

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

Tip

“GPL은 부담스럽지만 라이브러리는 공개로 두고 싶다”는 절충점. 독점 제품에서 외부 라이브러리로 쓰기엔 동적 링크가 안전합니다(정적 링크는 조건이 더 까다로움).

8 AGPL 3.0 — 네트워크까지

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

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

Warning

SaaS 회사가 가장 조심해야 할 라이선스 AGPL 컴포넌트를 백엔드에 넣고 서비스하면 서비스 코드 전체 공개 요구로 이어질 수 있습니다. 많은 기업이 AGPL 의존성을 사내 정책으로 금지하는 이유입니다. 도입 전 반드시 검토하세요.

9 MPL 2.0 — 파일 단위

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

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

Note

“기여는 공개로 환원하되, 사업 코드는 지키고 싶다”는 균형점. 파이어폭스(Mozilla) 계열에서 쓰입니다.

10 한눈 비교표

라이선스	분류	고지	소스공개	동일 라이선스	특허조항	네트워크
`MIT`	허용적	✔	—	—	—	—
`BSD 2/3`	허용적	✔	—	—	—	—
`Apache 2.0`	허용적	✔	—	—	✔ 명시	—
`MPL 2.0`	약 카피레프트	✔	파일 단위	파일만	✔	—
`LGPL`	약 카피레프트	✔	라이브러리	라이브러리	3.0	—
`GPL 2.0/3.0`	강 카피레프트	✔	전체	✔	3.0	—
`AGPL 3.0`	강 카피레프트	✔	전체	✔	✔	✔

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

11 실무 선택 가이드

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

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

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

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

Warning

“오픈소스 = 공짜·무제한”이 아니다 가장 흔한 사고는 (1) 고지 누락, (2) GPL/AGPL을 독점 제품에 결합, (3) 비호환 라이선스 혼합입니다. 자동 스캐너(FOSSA·ScanCode 등)와 OLIS 비교표로 도입 전에 점검하세요.

정리

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

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

Tip

요점 고를 때는 “얼마나 퍼지길 원하는가”, 가져다 쓸 때는 “내 제품에 공개 의무가 전염되는가”를 본다. 애매하면 OLIS 비교표(olis.or.kr)와 라이선스 전문을 확인하고, 사업적 영향이 크면 법률 검토를 받으세요.