핵심 차이는 파생 소프트웨어의 공개 의무입니다. MIT와 Apache 2.0은 저작권·라이선스 고지를 유지하면 비교적 자유롭게 사용할 수 있지만, GPL은 배포 방식과 결합 형태에 따라 소스코드 제공과 동일 라이선스 적용이 문제가 될 수 있습니다.
📌 핵심 5줄 요약
1. MIT는 사용·수정·배포·판매를 폭넓게 허용하는 간단한 퍼미시브 라이선스입니다.
2. Apache 2.0은 MIT와 비슷하게 자유로운 이용을 허용하면서 특허 라이선스와 NOTICE 관련 조건을 더 명확하게 둡니다.
3. GPL은 대표적인 카피레프트 라이선스로, GPL 코드를 포함해 배포하는 파생 프로그램에 소스코드 제공 의무가 발생할 수 있습니다.
4. 내부 사용과 외부 배포는 판단이 다르므로, 배포·판매·클라우드 제공 여부를 먼저 구분해야 합니다.
5. 실제 적용 전에는 프로젝트의 LICENSE 파일뿐 아니라 의존성별 라이선스와 버전까지 함께 확인해야 합니다.
📌 목차
01 | 오픈소스 라이선스가 필요한 이유
02 | MIT 라이선스의 특징
03 | Apache 2.0의 특징
04 | GPL 라이선스의 특징
05 | 세 라이선스 핵심 비교
06 | 상업적 이용과 판매 가능 여부
07 | 소스코드 공개 의무의 차이
08 | 저작권 표시와 NOTICE 관리
09 | 특허 조항은 왜 중요한가
10 | 라이브러리와 애플리케이션의 차이
11 | 실제 선택 기준
12 | 사용 전 확인 절차
13 | 자주 발생하는 실수
14 | 라이선스 충돌과 주의사항
01 | 오픈소스 라이선스가 필요한 이유
오픈소스라고 해서 아무 조건 없이 사용할 수 있다는 뜻은 아닙니다. 저작권자가 사용·복제·수정·배포를 허용하는 범위와 지켜야 할 조건을 라이선스 문서로 정해 둔 것입니다.
따라서 코드를 내려받았다는 사실만으로 상업적 이용, 재배포, 수정본 공개가 모두 허용되는 것은 아닙니다. 프로젝트에 포함된 LICENSE 파일과 각 의존성의 라이선스를 확인해야 합니다.
02 | MIT 라이선스의 특징
MIT 라이선스는 대표적인 퍼미시브 라이선스입니다. 라이선스 문구와 저작권 고지를 유지하는 조건으로 소프트웨어를 사용·복제·수정·병합·배포·판매할 수 있도록 폭넓게 허용합니다.
수정한 소스코드를 공개해야 한다는 일반적인 의무가 없기 때문에, MIT 코드를 제품이나 사내 시스템에 포함한 뒤 전체 소스코드를 공개하지 않는 방식도 검토할 수 있습니다. 다만 원본의 저작권 및 라이선스 고지는 배포물에 남겨야 합니다.
03 | Apache 2.0의 특징
Apache License 2.0도 퍼미시브 라이선스이므로 상업적 이용과 수정·재배포가 가능합니다. MIT보다 문서가 길고, 저작권 고지·라이선스 사본·변경 사항 표시·NOTICE 파일 등 배포 시 확인할 항목이 더 구체적입니다.
특히 Apache 2.0은 기여자가 자신의 특허 권리를 일정 범위에서 이용할 수 있도록 하는 특허 라이선스 조항을 포함합니다. Apache Software Foundation은 배포 시 LICENSE와 올바른 NOTICE 파일을 함께 관리하도록 안내합니다.
04 | GPL 라이선스의 특징
GPL은 카피레프트 라이선스입니다. GPL 프로그램을 수정하거나 결합한 프로그램을 외부에 배포할 때, 해당 프로그램의 소스코드 제공과 GPL 조건 적용이 문제될 수 있습니다.
GPL의 목적은 사용자가 프로그램을 실행하고, 소스코드를 확인하고, 수정하고, 수정본을 다시 공유할 자유를 보장하는 데 있습니다. GNU GPLv3는 2007년 6월 29일 공개된 버전이며, 배포 시 소스 제공과 관련된 조건을 상세히 규정합니다.
05 | 세 라이선스 핵심 비교
| 구분 | MIT | Apache 2.0 | GPL |
|---|---|---|---|
| 기본 성격 | 퍼미시브 | 퍼미시브 | 카피레프트 |
| 상업적 이용 | 허용 | 허용 | 허용 가능하나 배포 조건 확인 필요 |
| 수정본 공개 | 일반적 의무 없음 | 일반적 의무 없음 | 배포 시 공개 의무가 문제될 수 있음 |
| 저작권·라이선스 고지 | 유지 필요 | 유지 필요 | 유지 필요 |
| 특허 조항 | 상대적으로 간단함 | 명시적 특허 조항 포함 | 버전에 따라 별도 조건 확인 |
표의 내용은 일반적인 비교입니다. 실제 의무는 라이선스 버전, 코드 결합 방식, 배포 형태, 별도 예외 조항에 따라 달라질 수 있습니다.
06 | 상업적 이용과 판매 가능 여부
세 라이선스 모두 상업적 이용 자체를 금지하는 라이선스는 아닙니다. 오픈소스는 무료 사용만을 뜻하지 않으며, GPL도 조건을 지키는 범위에서 복제본을 판매할 수 있습니다.
다만 GPL 코드를 포함한 제품을 판매한다고 해서 소스코드 제공 의무가 사라지는 것은 아닙니다. 판매 여부보다 중요한 것은 다른 사람에게 프로그램을 전달하거나 배포했는지, 그리고 어떤 형태로 결합했는지입니다.
07 | 소스코드 공개 의무의 차이
MIT와 Apache 2.0은 일반적으로 수정한 코드 전체를 공개하도록 요구하지 않습니다. 대신 라이선스 사본, 저작권 고지, Apache 2.0의 경우 NOTICE와 변경 관련 고지를 확인해야 합니다.
GPL은 배포되는 파생 저작물에 대해 소스코드를 제공해야 하는 구조가 핵심입니다. 단순히 GPL 파일을 참고했는지, 같은 프로그램으로 결합했는지, 별도 프로세스로 통신하는지에 따라 판단이 달라질 수 있으므로 구조만 보고 단정하면 안 됩니다.
08 | 저작권 표시와 NOTICE 관리
MIT 코드를 제품에 포함한다면 원 저작권 표시와 MIT 라이선스 문구를 배포물에 포함하는 방식이 일반적입니다. 소스 저장소뿐 아니라 바이너리 배포 패키지와 제품의 법적 고지 화면도 확인하는 것이 좋습니다.
Apache 2.0은 LICENSE와 별도로 NOTICE 파일이 포함될 수 있습니다. 프로젝트가 요구하는 NOTICE 내용을 임의로 삭제하거나 축약하지 말고, 원 프로젝트의 배포 지침을 확인해야 합니다.
09 | 특허 조항은 왜 중요한가
특허 조항은 코드의 저작권과 별개로, 해당 소프트웨어를 사용하는 과정에서 특허권 문제가 발생할 때 어떤 권리와 제한이 적용되는지와 관련됩니다.
Apache 2.0은 특허 라이선스와 특허 소송 제기 시 권리 종료와 관련된 조항을 명시합니다. 특허 위험이 있는 기업 프로젝트라면 MIT와 Apache 2.0을 단순히 글자 수나 인지도만으로 비교하지 말고 법무·컴플라이언스 검토를 병행해야 합니다.
10 | 라이브러리와 애플리케이션의 차이
라이브러리는 다른 프로그램에 연결되어 사용되므로 GPL 적용 여부를 판단할 때 결합 방식이 특히 중요합니다. GPL FAQ에서도 라이브러리와 독점 프로그램의 결합 문제를 별도로 다루며, 자유로운 연결을 원한다면 LGPL 같은 다른 라이선스를 검토할 수 있다고 설명합니다.
반면 독립 실행형 프로그램이 별도 프로세스로 작동하고 네트워크 등으로 통신한다고 해서 항상 GPL 의무가 자동으로 사라지는 것은 아닙니다. 배포물 구성과 실제 코드 결합 관계를 기준으로 검토해야 합니다.
11 | 실제 선택 기준
개인 프로젝트와 빠른 배포
간단한 도구, 예제 코드, 웹 개발 라이브러리처럼 사용자가 자유롭게 활용하기를 원한다면 MIT가 이해하기 쉽고 관리 부담이 적습니다.
기업 프로젝트와 특허·고지 관리
기업 제품이나 여러 조직이 함께 사용하는 프로젝트라면 Apache 2.0을 검토할 수 있습니다. 특허 조항과 NOTICE 관리가 명확하다는 점이 장점이지만, 배포 패키지의 고지 체계는 별도로 갖춰야 합니다.
수정본의 자유로운 공유를 중시하는 경우
파생 프로그램도 같은 자유 소프트웨어 조건으로 공유되기를 원한다면 GPL이 목적에 더 가까울 수 있습니다.
12 | 사용 전 확인 절차
첫째, 프로젝트의 LICENSE 파일에서 정확한 라이선스 이름과 버전을 확인합니다. 둘째, package.json, pyproject.toml, pom.xml, Cargo.toml 등 의존성 관리 파일을 확인합니다.
셋째, 직접 포함한 코드와 외부 패키지의 라이선스를 목록으로 정리합니다. 넷째, 제품이 외부에 배포되는지, 고객사에 설치되는지, 사내에서만 사용하는지 구분합니다. 다섯째, 배포한다면 LICENSE·NOTICE·저작권 고지·소스코드 제공 방식이 준비됐는지 확인합니다.
13 | 자주 발생하는 실수
가장 흔한 실수는 프로젝트 전체가 MIT라고 생각하고 의존성까지 모두 MIT라고 판단하는 것입니다. 상위 프로젝트의 라이선스와 하위 패키지의 라이선스는 다를 수 있습니다.
또 다른 실수는 소스 저장소에 LICENSE 파일만 올리면 모든 의무가 끝난다고 생각하는 것입니다. 바이너리, 설치 파일, 모바일 앱, 컨테이너 이미지 등 실제 배포 형태에 맞춰 고지를 제공해야 할 수 있습니다.
14 | 라이선스 충돌과 주의사항
서로 다른 라이선스의 코드를 하나의 프로그램에 포함할 때는 호환성이 중요합니다. 특히 GPL 버전 간에도 조건이 다를 수 있으며, GPLv2와 GPLv3는 일반적으로 서로 호환되지 않는 조합으로 설명됩니다.
라이선스 표기가 없거나, 원본에 추가 조건이 붙어 있거나, 여러 저작권자가 공동으로 권리를 보유한 경우에는 임의로 라이선스를 바꾸면 안 됩니다. 배포 전에는 공식 라이선스 원문과 프로젝트의 배포 안내를 확인하고, 상업 서비스라면 전문 법률·컴플라이언스 검토를 받는 것이 안전합니다.
☑ 체크리스트
□ 프로젝트의 정확한 라이선스 이름과 버전을 확인했나요?
□ 직접 작성한 코드와 외부 의존성의 라이선스를 구분했나요?
□ 제품이 내부 사용인지 외부 배포인지 판단했나요?
□ LICENSE, 저작권 고지, NOTICE 파일을 배포물에 포함했나요?
□ GPL 코드가 포함된 경우 소스코드 제공 방식을 준비했나요?
□ 특허 위험과 라이선스 호환성을 검토했나요?
□ 불확실한 부분을 법무 또는 오픈소스 컴플라이언스 담당자에게 확인했나요?
📖 자주하는 질문 Q&A
MIT와 Apache 2.0 중 무엇이 더 자유로운가요?
둘 다 퍼미시브 라이선스라 자유로운 이용이 가능하지만, Apache 2.0은 특허 조항과 NOTICE 등 더 구체적인 조건을 둡니다. 단순함을 우선하면 MIT, 특허와 기업 배포 체계를 중시하면 Apache 2.0을 검토할 수 있습니다.
GPL 코드를 상업적으로 사용할 수 있나요?
가능할 수 있습니다. 다만 프로그램을 외부에 배포하거나 판매하는 경우 GPL의 소스코드 제공과 라이선스 적용 조건을 함께 지켜야 합니다.
오픈소스 라이선스는 한 번 정하면 바꿀 수 없나요?
저작권을 보유한 코드라면 향후 버전의 라이선스 정책을 바꿀 수 있지만, 이미 배포한 버전의 이용자에게 부여한 권리를 일방적으로 회수할 수 있는 것은 아닙니다. 여러 기여자가 있는 프로젝트는 모든 권리자의 동의가 필요한지 확인해야 합니다.
라이선스가 없으면 자유롭게 사용해도 되나요?
아닙니다. 별도 라이선스가 없으면 저작권자의 허락 범위가 명확하지 않으므로 자유로운 재사용을 전제로 하면 안 됩니다. 저장소의 LICENSE, 저작권 안내, 배포 문서를 먼저 확인해야 합니다.
공식 원문 확인:
👉 Apache License 2.0 공식 문서 바로가기
📝 마무리
MIT는 간단하고 폭넓은 활용을 원할 때, Apache 2.0은 특허와 기업 배포 조건까지 고려할 때, GPL은 파생물의 자유로운 공유를 중시할 때 적합합니다. 최종 판단은 라이선스 이름만 보지 말고 버전, 결합 방식, 배포 형태, 의존성 목록을 함께 확인해 결정해야 합니다.