[License] GPL과 LGPL 비교, CVE와 라이선스 충돌에 관하여
GNU와 GPL란
GNU
“GNU's Not Unix!”의 약자로, 자유 소프트웨어 재단(FSF)의 OS프로젝트임.
GNU 프로젝트는 유닉스(Unix)와 유사한 운영 체제를 만들기 위한 프로젝트이며, 대부분의 소프트웨어가 GNU 프로젝트의 GPL 라이선스로 배포됨. 이 프로젝트에서는 glibc, bash 등의 프로그램을 개발했으며, 리눅스 커널과 함께 사용되는 운영체제의 나머지 도구들을 만든 것임. (그래서 GNU/Linux라고 부르기도 함)
GPL
GNU = 프로젝트, GPL = GNU 프로젝트에서 만든 대표적인 라이선스명
| 항목 | GNU | GPL |
|---|---|---|
| 정의 | GNU's Not Unix: 자유 소프트웨어 생태계를 만들기 위한 프로젝트 이름 | GNU General Public License: GNU 프로젝트에서 만든 대표적인 오픈소스 라이선스 |
| 종류 | 운영체제, 컴파일러, 툴체인, 유틸리티 등 전체 생태계 | GPLv2, GPLv3 등 버전별 라이선스 |
| 창시자 | 리처드 스톨만 (RMS) | 동일 |
| 목적 | UNIX를 대체할 수 있는 완전한 자유 소프트웨어 운영체제 제공 | 소스코드 공개를 강제하는 카피레프트 라이선스 제공 |
| 상징 | 🐃 GNU 엠블럼 | 📜 자유 소프트웨어를 보호하는 법적 텍스트 |
GPL과 LGPL 비교
GPL(GNU General Public License)과 LGPL(GNU Lesser General Public License)은 모두 GNU에서 만든 오픈소스 라이선스지만,
적용 범위와 강제 조건의 강도에서 차이가 나타남.
| 항목 | GPL (General Public License) | LGPL (Lesser General Public License) |
|---|---|---|
| 의미 | 일반 공중 사용 허가서 | 덜 엄격한 공중 사용 허가서 |
| 철학 | 강한 카피레프트 (자유를 전염시킴) | 약한 카피레프트 (자유를 존중하되 제한 완화) |
| 목적 | 파생 소프트웨어도 모두 오픈소스로 만들게 함 | 라이브러리와 함께 사용하되, 전체 소스 공개까지는 강제하지 않음 |
| 정적 링크 시 | 전체 소스코드 공개 필수 | 전체 공개 필요. 단, 예외 조항 설명 시 부분 허용 가능 |
| 동적 링크 시 | 전체 소스 공개 필요 (실무에서 논란 있음) | 동적 링크는 허용, 소스 공개 의무 없음 |
| 상용 소프트웨어 포함 여부 | ❌ 사실상 불가 (소스 공개 조건 때문에) | ✅ 가능 (동적 링크 전제) |
| 호환성 | 다른 라이선스와 병합 어려움 (예: Apache 2.0과 GPLv2는 충돌) | 상대적으로 병합 용이함 |
| 실무에서 사용시 유의사항 | 코드 포함 시 반드시 전체 소스 공개해야 함 | 링크 방식에 따라 공개 의무 없음 (그러나 LGPL 조건 충족 필요) |
- GPLv2-only는 GPL 2.0만 따르고 "or later" 조건 없음
- GPLv2-or-later는 GPL 2.0 또는 이후 버전 선택 가능
- LGPLv2.1은 약한 카피레프트 라이선스
많은 상용 소프트웨어는 그래서 LGPL 라이브러리는 동적 링크만 사용
GNU GPL v1.0은 1989년에 만들어진 최초 버전의 GPL임
이후 버전과 달리 링크 방식(static vs dynamic)에 대한 명확한 언급이 없음.
취약점 점검
최신 버전일수록 보안 패치가 들어가 취약점에서 벗어날 수 있음.
https://repology.org/project/perl/cves?version=5.6.2
이런 페이지에서 취약점들을 버전별로 확인할 수 있음.
예를 들어, CVE-2023-31484같은 보안 취약점은 5.38까지 영향받음. 5.40.1로 버전업하면 2개의 cve 취약점에서 벗어날 수 있음.
CVE란? (Common Vulnerabilities and Exposures)
CVE는 전 세계 보안 취약점을 고유하게 식별하기 위해 사용되는 표준 번호 체계임.
각 취약점에 대해 고유한 번호를 부여해 혼동을 방지함.
CVE-2022-40674: expat XML parser에서 버퍼 오버플로우 발생 가능성
BDSA란? (Black Duck Security Advisory)
Black Duck(오픈소스 보안 플랫폼)이 자체적으로 발행하는 보안 취약점 ID임
- Synopsys 사의 Black Duck SCA(Software Composition Analysis) 도구
BDSA가 많다고 더 많이 검출되었다기보다, 같은 CVE라도 영향받는 컴포넌트를 쪼개서 관리하는 방식임.
라이선스 충돌
하나의 플젝에서 사용하고 있는 오픈소스 라이선스들은 서로 다른 의무사항을 가짐.
라이센스간 충돌이 발생하여 양립이 불가능한 경우들이 있음.
그래서 배포 전 라이선스간 충돌을 모두 확인하여야 함.
- Apache 2.0과 GPL 2.0 라이센스는 충돌발생 (아파치는 특허권을 보장하는 라이센스이고, GPL은 결합되는 모든 소스가 GPL로 라이센싱되어야하므로 두 라이선스가 양립할 수 없음)
참고 - gnu.org 라이선스 Compatibility
ex. GPLv2-or-later라면, GPLv3 선택 가능 → 그때부터는 GPLv3 코드와 병합 가능
이중라이선스 - GNU GPL v1.0 or later or Artistic License 1.0
Perl처럼 "GNU GPL v1.0 or later" 또는 "Artistic License 1.0"을 따르는 라이브러리는 dual license(이중 라이선스)임
- 사용자가 둘 중 하나를 선택해서 적용 가능함
- 일반적으로는 Artistic License를 따르기 때문에 상용 프로그램과의 병합도 자유로움
- GPL only인 경우에는 따져봐야함.
라이선스 선언시 둘중 하나를 골라 선택하라고 써져있으며, Artistic License 1.0로 선언하면 자유로워짐.
OpenSSL 라이선스
OpenSSL의 최근 버전(3.0.0~)
Apache License 2.0으로 배포됨.
OpenSSL 3.0부터는 Apache 2.0이므로 라이선스 충돌 문제 없음
OpenSSL의 구 버전
OpenSSL 1.1.1 이하 버전은 OpenSSL License + SSLeay License 두가지 모두를 따라야함.
카피레프트가 없는 자유 소프트웨어 라이선스이지만, GNU GPL과는 호환되지 않음.
또한 원래 BSD 라이선스나 Apache 1.0처럼 광고 조항을 써야함.
Apache 2.0 라이선스
OpenSSL 라이선스 조항: 사용하는 제품은 해당 문구를 표시해야 함.
Apache License 2.0 조항: 추가적인 restrictions 조건을 붙이는 걸 금지함
OpenSSL 이전 버전의 배포자에게 광고 문구 삽입 의무는 Apache 2.0 기준에서 보면 "추가 조건 imposed"가 되는 것
즉, 동적 링크라도 Apache 2.0 코드에 OpenSSL의 광고 조항이 적용되면,
Apache가 허용하지 않는 추가적인 법적 조건이 덧붙은 셈이 되어 충돌 가능성이 발생함
Apache 2.0 코드에 OpenSSL 예외 조항을 추가하면 문제 없음
= Apache 기반 프로젝트에서 OpenSSL을 동적 링크할 경우 (OpenSSL linking exception) 예외조항선언이 관례적으로 쓰임
