MPL (Mozilla Public License) 라이선스란?

오픈소스를 프로젝트에 도입할 때 고려해야 할 가장 중요한 기준 중 하나는 라이선스 전파성(Copyleft)입니다.
GPL처럼 강력한 전파성은 사용에 제약이 따르고, MIT나 BSD처럼 완전히 자유로운 라이선스는 기여한 코드의 개방성을 유지하기 어렵죠.

이 사이 어딘가에 있는 절충안이 바로 MPL(Mozilla Public License)입니다.
코드 기여자는 오픈소스 정신을 지키면서도, 상업적 프로젝트와의 통합도 가능한 절묘한 균형의 라이선스죠.

이번 글에서는 MPL의 정의, 특징, 전파 범위, 활용 방법, 그리고 다른 주요 오픈소스 라이선스와의 비교표까지 자세히 살펴보겠습니다. 🚀

---

✅ 1. MPL 라이선스란?

💡 MPL (Mozilla Public License)은 Mozilla 재단이 만든 오픈소스 라이선스로,
“파일 단위”로 소스코드 공개 의무를 부과하는 약한 Copyleft 방식의 라이선스입니다.

즉, MPL 라이선스가 적용된 소스코드를 사용하면 해당 파일만 공개하면 되고, 나머지 애플리케이션 코드는 공개하지 않아도 됩니다.

📌 핵심 개념:

• 전파성은 있지만, 범위가 제한적
• 파일 단위로 Copyleft가 적용됨
• 상용 제품과 혼합 개발이 비교적 쉬움

✅ 결론: MPL은 코드 보호와 실용성을 동시에 고려한 절충형 오픈소스 라이선스입니다.

---

✅ 2. MPL의 주요 특징 정리

항목	설명
📁 파일 단위 공개	MPL이 적용된 파일은 수정 시 반드시 공개해야 함
📦 패키지 전체는 공개 의무 없음	단일 프로젝트 내에 MPL 파일이 있더라도 전체 소스 공개는 불필요
🔄 GPL 호환 가능 (v2 이상)	MPL 2.0은 GPLv2/GPLv3과 라이선스 호환 가능
✅ 상업적 사용 허용	MPL 파일을 포함한 상용 제품 개발 가능
📄 라이선스 전문 포함 필요	배포 시 MPL 라이선스 문서를 포함해야 함

 

📌 MPL을 쓰면 이런 구조가 가능해요:

• main_app.cpp (사유 코드) → 공개 안 해도 됨
• open_util.cpp (MPL 적용 코드) → 수정했으면 반드시 공개

✅ 정리: MPL은 파일 수준에서만 공개 의무를 부과하기 때문에, 프로젝트 전체의 전파 위험이 적음.

반응형

---

✅ 3. MPL vs 다른 오픈소스 라이선스 비교표

라이선스	소스코드 공개 범위	상업적 사용	Copyleft 수준	특허 보호	주요 사용 사례
MPL 2.0	해당 파일만 공개	✅ 가능	⚠️ 약한 전파 (파일 단위)	✅ 있음	Firefox, Bugzilla
GPL v3	전체 소스코드 공개	⚠️ 제한적	✅ 강한 전파	✅ 있음	Linux, WordPress
LGPL	수정된 라이브러리만 공개	✅ 가능	⚠️ 약한 전파 (라이브러리 단위)	✅ 있음	glibc, FFmpeg
MIT	없음 (출처만 표기)	✅ 완전 자유	❌ 없음	❌ 없음	React, Flask
Apache 2.0	없음 (NOTICE 필요)	✅ 완전 자유	❌ 없음	✅ 특허 보호	TensorFlow, Kubernetes

 

✅ 요약 포인트:

• MPL은 GPL보다 유연하고, MIT보다 보호적인 중간 지점의 라이선스
• 코드를 오픈하면서도 프로젝트 전체 공개는 피하고 싶은 경우 이상적

---

✅ 4. MPL 라이선스 사용 예시

📌 MPL 적용 유명 프로젝트

프로젝트	설명
Mozilla Firefox	웹 브라우저의 대표주자, MPL의 대표 사용 사례
Bugzilla	Mozilla에서 만든 오픈소스 버그 추적 시스템
LibreOffice (일부 구성 요소)	일부 구성 요소는 MPL과 LGPL 이중 라이선스 적용
Rust 언어	일부 도구 및 컴포넌트는 MPL로 배포

 

📌 실무 활용 시나리오

• 상용 앱에 MPL 라이브러리 파일을 포함하고 싶다면, 해당 파일만 공개하면 OK
• MPL 파일을 수정했더라도 다른 사유 파일에는 영향 없음
• 여러 라이선스를 함께 쓸 경우, MPL + Apache / MIT 조합은 문제 없음, MPL + GPL도 2.0 이상은 호환 가능

✅ 결론: MPL은 실제 상용 제품과 오픈소스를 병행하려는 개발자와 기업에 이상적인 선택지입니다.

---

✅ 5. MPL 사용 시 주의사항

1️⃣ 수정한 파일은 반드시 공개해야 함

• 전체 프로젝트가 아니라, MPL이 적용된 특정 파일만 소스 공개하면 됨

2️⃣ 파일을 나눠 전파를 우회하는 건 부적절할 수 있음

• 기능 분할로 Copyleft 회피를 시도하면 라이선스 취지 위반으로 해석될 여지 있음

3️⃣ 라이선스 문서 포함 필수

• 배포 시에는 MPL 전문과 변경 사항에 대한 문서 포함 필요

4️⃣ GPL과의 혼용은 버전 확인 필수

• MPL 2.0은 GPLv2, v3과 호환됨
• MPL 1.x는 GPL과 호환되지 않음 → 2.0을 우선 선택할 것

---

✅ 6. MPL은 어떤 경우에 선택하면 좋을까?

상황 MPL 적합성

상황	MPL 적합성
오픈소스 정신을 지키면서도 상용화 고려	✅ 매우 적합
특정 파일만 공개하고 싶을 때	✅ 이상적 구조
전체 공개가 부담스러운 프로젝트	✅ GPL보다 가볍고 실용적
Apache/MIT보다 더 명확한 오픈소스 보호를 원할 때	✅ 중간 수준의 보호 제공
강한 Copyleft가 필요한 경우 (예: 커널 등)	❌ GPL이 더 적합

---

✅ 7. 결론: MPL은 실용성과 자유를 동시에 잡는 똑똑한 선택이다

✔ MPL은 오픈소스 기여자의 권리를 보호하면서도, 상업적 활용에도 큰 제약을 주지 않는 유연한 라이선스입니다.
✔ 파일 단위 공개 조건으로 인해, 복잡한 시스템 구조에도 적용하기 쉽고, 리스크도 낮습니다.
✔ GPL의 강한 전파성과 MIT의 완전한 자유 사이에서 고민 중이라면, MPL이 가장 현명한 중간 지점이 될 수 있습니다.

👉 여러분의 프로젝트는 MPL에 어울리는 구조인가요?
👉 자유로운 공유와 실무 효율을 함께 추구하고 싶다면, MPL을 꼭 고려해보세요! 🔍🧠