오픈소스 라이선스 비교: MIT, Apache, LGPL, GPL 차이점과 주의사항

“이거 써도 되는 거 맞아요?”

개발을 하다 보면 라이브러리는 거의 기본 전제로 사용된다. 하지만 라이선스를 정확히 이해하고 사용하는 개발자는 생각보다 많지 않다. GPL이면 위험하다는 이야기, LGPL은 조금 낫다는 이야기, MIT는 그냥 써도 된다는 이야기가 섞여 있다. 이번 글에서는 GPL, LGPL을 중심으로 주요 오픈소스 라이선스를 실무 관점에서 정리한다.

 

1. 오픈소스 라이선스란?

오픈소스는 “무료”가 아니라 “사용 조건이 명시된 공개 소프트웨어”다. 소스코드를 공개하되, 사용·수정·배포에 대한 조건을 계약 형태로 명시한 것이 라이선스다. 따라서 라이선스는 법적 효력을 가지는 사용 계약이다.

 

 

2. 주요 라이선스별 특징

MIT License

• 개요: 가장 단순하고 제약이 없는 라이선스다.
• 의무: 소프트웨어 사용 시 저작권 고지만 유지하면 된다.
• 상용 활용: 소스코드 공개 의무가 없으므로 상용 소프트웨어 개발에 가장 적합하다.

Apache License 2.0

• 개요: MIT와 유사하나 특허권 관련 조항이 추가된 라이선스다.
• 특징: 기여자가 사용자에게 특허권을 허용한 것으로 간주하므로 특허 분쟁 위험이 적다. 기업 주도의 대형 프로젝트(Spring, Kubernetes 등)에서 선호된다.

LGPL (Lesser GPL)

• 개요: GPL의 강력한 전염성을 완화한 버전이다.
• 공개 범위: 라이브러리를 단순 링크하여 사용할 경우, 메인 소스코드는 공개할 의무가 없다. 단, 라이브러리 자체를 수정했다면 해당 수정본은 공개해야 한다.

GPL (General Public License)

• 개요: '카피레프트'의 대표 격으로 소스코드의 자유로운 공유를 지향한다.
• 전염성: GPL 코드를 한 줄이라도 포함하거나 정적/동적 링크할 경우, 배포 시 프로젝트 전체 소스코드를 동일한 GPL로 공개해야 한다. 상용 솔루션 납품 시 가장 주의해야 할 대상이다.

 

 

2. 라이선스 분류

1) Copyleft 계열

• GPL
• AGPL
• LGPL (완화형)

특징: 수정하거나 배포할 경우 동일 라이선스로 공개해야 할 수 있으며, 조건에 따라 소스 공개 의무가 발생한다.

 

2) Permissive 계열

• MIT
• Apache 2.0
• BSD

특징: 상업적 사용 가능, 소스 공개 의무 없음, 출처 표기 의무 정도만 존재한다.

 

 

3. GPL (GNU General Public License)

GPL을 포함해 배포하면 전체가 GPL 대상이 될 수 있다.

주요 특징

• 수정 가능
• 상업적 사용 가능
• 배포 시 전체 소스 공개 의무
• 2차 저작물도 GPL로 공개해야 함

GPL 라이브러리를 포함한 프로그램을 외부에 배포할 경우, 전체 프로그램이 GPL 적용 대상이 될 가능성이 있다. 즉, 회사의 자체 코드까지 공개해야 하는 상황이 발생할 수 있다. 내부 사용만 하는 경우에는 문제가 되지 않지만, 배포형 제품(설치형 소프트웨어)에서는 특히 주의해야 한다.

결론적으로, 상용 소프트웨어에서는 매우 신중하게 검토해야 하는 라이선스다.

 

 

4. LGPL (Lesser GPL)

라이브러리는 GPL이지만, 프로그램 전체까지 강제하지는 않는다.

주요 특징

• 동적 링크 사용 시 자체 코드 공개 의무 없음
• 라이브러리를 수정한 경우 공개 의무 발생
• 정적 링크 시 GPL과 유사하게 해석될 가능성 존재

라이브러리를 수정하지 않고 동적 링크 방식으로 사용하는 경우에는 비교적 안전하다. 다만 라이브러리를 수정하거나 정적 링크로 포함하는 경우에는 GPL과 유사한 문제가 발생할 수 있다. GPL보다는 유연하지만 여전히 주의가 필요한 라이선스다.

 

 

5. MIT License

출처만 남기면 자유롭게 사용 가능하다.

주요 특징

• 상업적 사용 가능
• 수정 및 재배포 가능
• 소스 공개 의무 없음
• 라이선스 및 저작권 고지 유지 의무

기업에서 가장 선호되는 라이선스 중 하나이며, 법적 리스크가 낮고 관리가 비교적 수월하다.

 

 

6. Apache License 2.0

특허권까지 고려한 라이선스.

MIT와 유사하게 관대한 라이선스이지만, 특허권에 대한 명시적 허용 조항이 포함되어 있다. 또한 특허 소송을 제기할 경우 라이선스가 종료되는 조항이 있다. 변경 사항 명시 의무가 있으며, 기업 환경에서 매우 선호되는 라이선스다.

 

 

7. AGPL

SaaS도 예외가 아니다.

일반 GPL은 “배포”를 기준으로 공개 의무가 발생한다. 반면 AGPL은 네트워크를 통해 서비스하는 경우에도 공개 의무가 발생할 수 있다. 즉, SaaS 형태로 운영하더라도 소스 공개 의무가 생길 수 있다. SaaS 기업에서는 특히 주의가 필요한 라이선스다.

 

 

8. 실무에서 반드시 확인해야 할 포인트

1. 단순 사용인가, 수정인가
   단순 사용은 비교적 안전하지만, 수정 시 공개 의무 가능성이 커진다.
2. 배포하는가
   내부 사용만 하면 문제되지 않지만, 외부 배포 시 라이선스 조건이 적용된다.
3. SaaS 형태인가
   AGPL의 경우 네트워크 제공만으로도 의무가 발생할 수 있다.

 

 

9. 기업 실무 대응 전략

1. SCA 도구 사용
   
   • OWASP Dependency-Check
   • Snyk
   • FOSSA
2. 라이선스 등급 분류
   
   • 허용
   • 조건부 허용
   • 금지
3. 신규 라이브러리 도입 시 사전 검토
   GPL 및 AGPL은 법무 검토를 거치는 것이 안전하다.

 

 

10. 자주 하는 오해

• 오픈소스는 무료이므로 아무렇게나 써도 된다 → 라이선스 위반 시 법적 책임이 발생할 수 있다.
• GitHub에 공개되어 있으면 다 MIT다 → 라이선스는 프로젝트마다 다르다.
• SaaS는 공개 의무가 없다 → AGPL은 예외다.

 

 

11. 요약 비교 표

라이선스	상업적 사용	소스 공개 의무	전염성	기업 친화도
GPL	가능	있음	강함	낮음
LGPL	가능	조건부	중간	보통
AGPL	가능	있음 (SaaS 포함)	매우 강함	낮음
MIT	가능	없음	없음	매우 높음
Apache 2.0	가능	없음	없음	매우 높음

 

 

 

12. 결론

오픈소스는 무료 소프트웨어가 아니라 조건부 사용 허가다. 특히 GPL과 AGPL은 구조와 배포 방식에 따라 회사 코드 공개 의무로 이어질 수 있으므로 신중한 검토가 필요하다. MIT와 Apache 2.0은 상대적으로 안전하지만, 출처 고지 의무 등 기본 조건은 반드시 준수해야 한다.

개발자는 단순히 기능만 보는 것이 아니라, 라이선스까지 함께 검토하는 습관을 가져야 한다.