소프트웨어 라이선스 정리

소프트웨어 라이선스 요약

소프트웨어 라이선스는 사용, 수정, 배포할 때 따라야 하는 규칙을 정한 계약입니다. 이 글은 실무에서 자주 헷갈리는 지점(소스 공개, NOTICE, 특허, 상용 배포, 의존성 체인)을 중심으로 정리합니다.

---

1. GPL (GNU General Public License)

• 자유 소프트웨어 재단이 만든 Copyleft 라이선스.
• 사용·수정·배포는 허용되지만, 배포 시 파생물에도 같은 라이선스 적용이 기본 원칙이다.
• 네트워크 서비스로 수정본을 제공하는 경우 AGPL(GPLv3 계열) 적용 여부를 따로 확인해야 한다.
• 특허 특약이 포함되므로 의존성 체인 전체의 라이선스/조항을 함께 점검해야 한다.

추가 포인트

• GPL 코드만 쓰는 것 자체가 위험한 건 아니고, 배포 시점에 소스 공개와 동일 라이선스 유지 조건을 만족하면 된다.

2. Apache License 2.0

---

2. Apache License 2.0

• Apache 소프트웨어 재단의 허가형 라이선스.
• 상업적 이용이 비교적 자유롭고, 소스 공개 의무는 없다.
• 배포 시 라이선스 원본과 NOTICE 항목을 함께 두는 것이 관행.
• Apache 2.0에는 특허 라이선스 조항이 있어 엔터프라이즈에서 선호되는 편이다.

---

3. MIT License

• 가장 단순한 허가형 라이선스 중 하나.
• 거의 모든 사용·수정·재배포에 제약이 적고, 배포 시 소스 공개 의무는 없다.
• 다만 저작권 공지(copyright/license)를 유지해야 한다.

---

4. BSD License

• BSD 계열(2-clause/3-clause)의 공통점은 상업적 이용이 가능하고 핵심 의무가 단순하다.
• 소스 공개 의무는 없지만 라이선스 고지 보존은 필수다.

5. AGPL (GNU Affero General Public License)

• AGPL은 GPL의 한 갈래로, 네트워크로 제공(서비스)할 때도 소스 공개 의무가 확장되는 라이선스다.
• SaaS 형태로 코드를 배포하는 제품은 꼭 적용 범위를 확인해야 한다.

---

6. LGPL (GNU Lesser General Public License)

• GPL의 제약을 일부 완화해 라이브러리 사용이 상용 제품과 결합되기 쉽도록 만든 모델.
• 라이브러리를 수정하면 수정한 라이브러리 자체의 소스 공개가 필요할 수 있다.
• 라이브러리를 링크해 사용하는 상위 코드는 보통 공개 의무가 없다(연결 방식/버전에 따라 세부 차이 존재).

실무 관점 핵심

• GPL/LGPL의 핵심은 “누구를 배포 대상으로 볼 것인가”보다 “수정본 또는 수정된 라이브러리 파일을 어떻게 처리했는가”에 더 가깝다.

---

7. MPL (Mozilla Public License)

• Mozilla의 중간형 Copyleft.
• 파일 단위로 적용 범위가 결정되는 경향이 있어, 특정 파일은 공개하고 다른 파일은 비공개로 둘 수 있다.
• 수정한 해당 파일을 배포할 때 소스 공개를 요구한다.

---

8. CDDL (Common Development and Distribution License)

• Sun/Oracle 진영의 파일 단위 공개 성격을 가진 라이선스.
• 상용 사용은 가능하지만, 영향을 받는 파일/수정본 배포 규칙을 꼭 지켜야 한다.

9. 운영 체크리스트

라이선스를 고를 때 아래 질문을 먼저 답하면 흔한 실수를 많이 줄일 수 있다.

• 배포 경로가 있나? (사내 사용만인지, 배포/오픈 배포인지)
• 소스 공개가 필요한가? (GPL/LGPL/MPL 등)
• NOTICE/라이선스 텍스트 보관 의무가 있는가? (Apache/실무 빌드 프로세스)
• 특허 조항이 중요한가? (엔터프라이즈에서 Apache vs MIT 선택 시 자주 따져봄)
• 의존성 전파 규칙이 맞는가? (라이선스 체인이 더 제한적이지 않은가)

빠른 판단 기준

• 상용 릴리스가 있다면, 라이선스별로 소스 공개 범위, NOTICE 의무, 특허 조항을 먼저 본다.
• 내부 전용 코드라 해도 제3자 라이브러리를 공개 저장소에 올리면 공개 의무가 달라질 수 있다.

---

📝 소프트웨어 라이선스 Cheat Sheet

라이선스	개발자/단체	상용 사용	수정 가능	재배포 가능	소스 공개 의무	비고
GPL	자유 소프트웨어 재단	✅ 가능 (단, 소스 공개 필요)	✅ 가능	✅ 가능	⚠️ 반드시 공개 (Copyleft)	수정 후 배포 시 동일 라이선스 적용 필요
AGPL	자유 소프트웨어 재단	✅ 가능	✅ 가능	✅ 가능	⚠️ 네트워크 배포 포함 공개	SaaS/호스팅 사용 시 영향 큼
Apache 2.0	Apache Software Foundation	✅ 가능	✅ 가능	✅ 가능	⚠️ NOTICE·라이선스 본문 포함	상업적 소프트웨어에 많이 쓰임
MIT License	매사추세츠 공과대학교	✅ 가능	✅ 가능	✅ 가능	❌ 공개 의무 없음	가장 자유로운 허가형 라이선스
BSD License	UC 버클리	✅ 가능	✅ 가능	✅ 가능	❌ 공개 의무 없음	조항/버전(2-clause, 3-clause) 차이 주의
LGPL	자유 소프트웨어 재단	✅ 가능 (라이브러리 사용 시)	✅ 가능	✅ 가능	⚠️ 라이브러리 수정 본문 공개	상용 코드와 결합이 비교적 유연
MPL	모질라 재단	✅ 가능	✅ 가능	✅ 가능	⚠️ 파일 단위 공개	상용 제품에도 사용 가능, 배포 시 MPL 포함
CDDL	선 마이크로시스템즈	✅ 가능	✅ 가능	✅ 가능	⚠️ 적용 파일 공개	배포 시 CDDL 본문 포함 필요

---

🔹 아이콘 의미

• ✅ : 가능
• ⚠️ : 반드시 준수해야 함
• ⚪ : 선택적
• ❌ : 제한 없음

참고 링크 (공식 원문)

• GNU: GPL / LGPL / AGPL: https://www.gnu.org/licenses/
• Apache 2.0: https://www.apache.org/licenses/LICENSE-2.0
• MIT: https://opensource.org/licenses/MIT
• BSD: https://opensource.org/licenses/BSD-3-Clause
• MPL: https://www.mozilla.org/en-US/MPL/
• CDDL: https://www.oracle.com/downloads/licenses/cddl-license-3978153.html

---

💡 Tip:

• Copyleft: 공개 의무를 두는 제약형 모델(주로 Copyleft 계열).
• MIT/BSD/Apache는 통상적으로 상용 통합이 쉬운 편.
• 의존성은 라이선스 전파 체인이 항상 최악의 조합을 만들 수 있으니 SBOM + 라이선스 체크 자동화가 중요.

⚠️ 이 글은 법률 자문이 아니며, 릴리스/라이선스 판단은 조직의 법무/컴플라이언스 절차와 함께 검토해야 한다.