스킬이나 도구를 외부에 공개할 때, 라이선스는 다른 사람이 내 결과물을 어디까지 활용할 수 있는지를 규정합니다.
제약이 약한 라이선스는 상업적 재사용까지 폭넓게 허용하고, 제약이 강한 라이선스는 가져간 쪽에도 소스 공개 의무를 지웁니다. 종류는 많지만 제약 수위에 따라 세 단계로 정리됩니다.
어디까지 개방하고, 어디서부터 보호할 것인가
라이선스 선택은 결과물을 얼마나 개방하고 어디서부터 보호할지 정하는 결정입니다. 다섯 가지 라이선스는 제약 수위에 따라 세 단계로 나뉩니다.
제약이 가장 약합니다. 누구나 상업 제품에 포함하고, 수정하고, 재배포할 수 있습니다. 저작권 표시만 유지하면 됩니다.
조건부로 개방합니다. 라이브러리로 연결해 쓰는 것은 자유지만, 라이브러리 자체를 수정하면 그 부분은 공개해야 합니다.
가장 강하게 보호합니다. 내 코드를 사용한 결과물도 전체 소스를 같은 조건으로 공개해야 합니다. AGPL은 서버에서 실행하는 것만으로도 공개 대상이 됩니다.
5개 라이선스 한눈에 비교
왼쪽일수록 제약이 약한 초록불, 오른쪽일수록 제약이 강한 빨간불입니다
| 항목 | MIT | Apache 2.0 | GPL 3.0 | LGPL 3.0 | AGPL 3.0 |
|---|---|---|---|---|---|
| 상업적 이용 | O | O | O | O | O |
| 수정 허용 | O | O | O | O | O |
| 저작권 표시 | 필수 | 필수 | 필수 | 필수 | 필수 |
| 변경 사항 명시 | X | 필수 | 필수 | 필수 | 필수 |
| 소스코드 공개 | X | X | 필수 | 수정 시 | 필수 |
| 동일 라이선스 적용 | X | X | 전체 | 수정분만 | 전체 |
| 특허 보호 | X | O | O | O | O |
| 네트워크 서비스 공개 | X | X | X | X | 필수 |
| 제약 강도 | 약함 | 약함 | 강함 | 중간 | 매우 강함 |
MIT vs Apache 2.0, 한 줄로 말하면? ▾
MIT는 "그냥 맘대로 써, 내 이름만 남겨줘", Apache 2.0은 "맘대로 써. 대신 이름 남기고 특허로 뒤통수치지 마"입니다.
둘 다 상업·수정·재배포·비공개 모두 허용하는 허용적 라이선스이고, 차이는 3가지뿐입니다.
- ① 특허 조항
Apache는 기여자 특허를 자동으로 허락하고, 사용자가 특허 소송을 걸면 라이선스가 즉시 종료됩니다. MIT엔 이 장치가 없어서 나중에 누가 "내 특허다"라며 소송을 걸 수 있습니다. → 독창적 알고리즘·기업 제품은 Apache 2.0이 안전합니다. - ② 변경 표시 의무
Apache는 수정 부분을 표시해야 하지만, MIT는 그런 의무가 없습니다. - ③ NOTICE 파일
Apache는 원본 NOTICE를 함께 배포해야 하고, MIT는 LICENSE만 챙기면 끝입니다.
요약: 개인·소규모 스킬은 MIT, 기업·특허 이슈가 있으면 Apache 2.0.
처음이라면 MIT, 특허가 걱정되면 Apache 2.0 ▾
개인 프로젝트, Claude Code 스킬, MCP 서버는 대부분 MIT면 충분합니다. 조건이 가장 단순해 채택률이 가장 높습니다.
독창적 알고리즘이 있거나 기업에서 배포한다면 Apache 2.0을 쓰세요. 특허 소송 리스크를 막아줍니다. 잘 모르겠으면 MIT로 시작해도 됩니다.
MIT/Apache 라이선스 파일을 사용할 때 주의할 점 ▾
- LICENSE 파일을 반드시 포함하세요. 없으면 기본 저작권법이 적용돼 아무도 합법적으로 못 씁니다.
- 연도와 이름을 정확히 기입하세요.
[작성자 이름]을 그대로 두면 법적 효력이 없습니다. - 가져다 쓴 오픈소스의 LICENSE도 함께 포함하세요. 의존성 라이브러리의 라이선스를 삭제하면 위반입니다.
- Apache의 NOTICE 파일을 빠뜨리지 마세요. 원본에 있다면 배포 시 반드시 함께 넣어야 합니다.
- MIT와 Apache는 섞어 써도 됩니다. 단, GPL 코드를 MIT 프로젝트에 넣으면 전체가 GPL이 되니 주의하세요.
- "AS IS" 면책 조항을 이해하세요. 두 라이선스 모두 무보증 조항을 포함해, 사용 중 문제가 생겨도 법적 책임을 지지 않습니다.
이름의 유래: 매사추세츠 공과대학교(MIT)에서 1980년대 X 윈도 시스템을 배포하며 처음 사용한 라이선스입니다.
저작권 표시만 남기면 누구나 자유롭게 수정·재배포·상업 이용이 가능합니다. npm 패키지, GitHub 공개 저장소 대부분이 이 라이선스를 씁니다.
- LICENSE 파일에 MIT 전문과 이름·연도만 넣으면 끝
- 포크·수정해도 소스 공개 의무 없음
- 기업도 부담 없이 채택 → 채택률이 가장 높음
- 단점: 독점 제품에 가져다 써도 막을 수 없음
이름의 유래: 1995년 Apache HTTP Server 프로젝트에서 만든 라이선스입니다. 초기 개발자들이 패치(patch)를 많이 적용해 "A Patchy Server"라는 말장난에서 이름이 나왔습니다.
MIT만큼 자유로우면서 특허 라이선스 조항이 추가됐습니다. 독창적 알고리즘이 있거나 특허 분쟁이 걱정되면 안전합니다.
- 사용자가 수정하면 변경 사항 표시 필수
- 기여자 특허는 자동으로 사용 허락
- 특허 소송을 걸면 라이선스 자동 종료(악의적 소송 방지)
- NOTICE 파일로 기여자·출처 정보를 관리
이름의 유래: 리처드 스톨먼이 1989년 자유 소프트웨어 운동을 위해 만들었습니다. GNU는 "GNU's Not Unix"의 재귀 약자입니다.
가장 강력한 카피레프트 라이선스입니다. GPL 코드를 포함해 배포하면 전체 소스를 같은 GPL로 공개해야 합니다.
- 파생 저작물도 반드시 GPL로 배포(전염성)
- 바이너리 배포 시 소스 제공 또는 접근 방법 안내 필수
- v3는 특허 보호와 DRM 우회 금지 방지 조항 포함
- SaaS(서버 실행)는 배포로 보지 않아 공개 의무 없음
이름의 유래: GPL에서 파생된 완화 버전으로, Lesser는 "제약이 더 작다"는 뜻입니다.
LGPL 라이브러리를 수정 없이 가져다 연결해 쓰면 내 코드에는 다른 라이선스를 써도 됩니다. 라이브러리 자체를 수정한 부분만 LGPL로 공개하면 됩니다.
- 라이브러리를 그대로 링크하면 내 코드 공개 불필요
- 라이브러리를 수정하면 그 부분만 LGPL로 공개
- 독점 소프트웨어에서도 LGPL 라이브러리 사용 가능
이름의 유래: 처음 만든 회사 Affero, Inc.에서 왔습니다. Affero는 라틴어로 "전달하다"는 뜻으로, 네트워크 전달 상황까지 라이선스를 확장하겠다는 의도입니다.
GPL의 강화 버전입니다. 서버에서 실행하는 것만으로 '배포'로 간주해, 네트워크 서비스도 소스 공개 대상이 됩니다.
- GPL 조건 + 네트워크 사용도 배포로 간주
- 서버에서 AGPL 코드를 실행하면 사용자에게 소스 접근 방법 제공 필수
- SaaS 기업이 가장 주의해야 하는 라이선스
조건이 가장 단순하고 상업 이용에 제약이 없습니다.
특허 라이선스 조항이 법적 리스크를 줄여줍니다.
파생 저작물도 오픈소스로 유지돼 커뮤니티에 환원됩니다.
자유롭게 링크하되 라이브러리 수정분만 공개됩니다.
네트워크 서비스도 배포로 간주해 소스 공개를 요구합니다.
누구도 사용·수정·배포할 수 없으니 반드시 명시하세요.