허용형 vs 카피레프트 — 내 프로젝트에 맞는 라이선스 고르는 법

먼저 목표를 정한다

라이선스 선택은 취향이 아니라 내가 무엇을 원하는지의 문제입니다. 대부분은 아래 두 목표 사이 어딘가에 있습니다.

최대한 많이 쓰이길 원한다 — 기업 제품, 다른 오픈소스, 비공개 앱 어디에든 부담 없이 들어가길 바란다면 허용형이 유리합니다.
개선이 공개로 돌아오길 원한다 — 누군가 내 코드를 고쳐 배포한다면 그 수정도 공개되길 바란다면 카피레프트가 맞습니다.

허용형: 넓은 채택, 적은 마찰

MIT, BSD, ISC, Apache-2.0 는 고지 유지 정도만 요구합니다. 기업 법무팀 대부분이 사전 승인 목록에 올려 두는 라이선스라 도입이 빠릅니다. 대신 누군가 코드를 고쳐 비공개 제품에 넣어도 막을 수 없습니다.

허용형 안에서의 선택은 주로 두 가지입니다.

특허: 명시적 특허 허락과 특허 보복 조항이 필요하면 Apache-2.0, 아니면 MIT.
GPL-2.0 과의 호환: Apache-2.0 은 GPL-2.0-only 프로젝트에 넣을 수 없다는 것이 FSF 입장이므로, 리눅스 커널 주변 생태계라면 MIT·BSD 가 편합니다.

카피레프트: 공개의 연쇄

GPL 은 결합한 프로그램 전체, LGPL 은 라이브러리, MPL 은 파일 단위로 공개 의무를 둡니다. 서버에서 도는 소프트웨어라면 AGPL 이 GPL 의 공백을 메웁니다. 카피레프트를 쓰면 일부 기업은 사용이나 기여를 꺼릴 수 있습니다. 특히 AGPL 은 많은 회사가 내부 정책으로 사용을 제한합니다. 이것이 의도한 효과일 수도, 원치 않는 부작용일 수도 있습니다.

생태계 관행도 무시할 수 없다

라이선스는 커뮤니티의 관례와 맞을 때 마찰이 적습니다.

생태계	흔한 라이선스	비고
JavaScript(npm)	MIT, ISC	작은 패키지가 많아 짧은 허용형 선호
Rust(crates.io)	MIT OR Apache-2.0	Rust 자체가 이 듀얼 방식
Python(PyPI)	MIT, BSD-3-Clause, Apache-2.0	과학 계산 쪽은 BSD-3 이 많음
Go	BSD-3-Clause, MIT, Apache-2.0	Go 표준 라이브러리는 BSD-3
리눅스 커널 모듈	GPL-2.0-only	커널과 결합하려면 사실상 필수
데스크톱 GNU 도구	GPL-3.0-or-later	GNU 프로젝트 기본
C/C++ 라이브러리	LGPL, MIT, BSL-1.0	링크 방식이 선택에 영향

결정 체크리스트

의존성 확인: 이미 쓰고 있는 라이브러리의 라이선스가 선택지를 제한하지 않는지 봅니다. GPL 라이브러리와 결합한 프로그램을 배포한다면 선택지는 GPL 호환 라이선스로 좁혀집니다.
사용 형태: 설치형인지, 라이브러리인지, 서비스인지에 따라 카피레프트의 효과가 달라집니다.
수익 모델: 상용 라이선스를 따로 팔 계획이라면 카피레프트 + 상용 듀얼 라이선스와 기여자 라이선스 계약(CLA)을 함께 고려합니다.

한 문장 요약

널리 쓰이는 게 최우선 → MIT (특허가 걱정되면 Apache-2.0)
라이브러리 개선은 돌려받고 싶지만 쓰는 쪽은 자유롭게 → MPL-2.0 또는 LGPL-3.0
모든 파생 프로그램이 공개되길 → GPL-3.0
서버 소프트웨어의 수정본까지 공개되길 → AGPL-3.0
아무 조건도 두고 싶지 않다 → 0BSD, Unlicense, CC0

선택 마법사에서 이 기준을 질문 형태로 답하면 후보와 이유를 보여 줍니다.

이 글은 일반 정보이며 법률 자문이 아닙니다. 중요한 결정은 전문가와 상의하세요.

참고 출처

choosealicense.com — https://choosealicense.com/
FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
Rust 라이선스(MIT OR Apache-2.0) — https://github.com/rust-lang/rust