GNU 약소 일반 공중 사용 허가서 #392

개요

GNU 약소 일반 공중 사용 허가서(GNU Lesser General Public License, LGPL)는 자유 소프트웨어 재단(Free Software Foundation, FSF)이 배포하는 자유 소프트웨어 라이선스다. 일반GNU 일반 공중 사용 허가서(GPL)의 강한 카피레프트(copyleft) 조항과 일반BSD 허가서·일반MIT 허가서 같은 허용적 라이선스의 단순한 사용 허가 사이에서 절충안으로 만들어졌다. LGPL은 라이브러리 코드 자체에는 카피레프트를 적용하되, 그 라이브러리를 링크해 사용하는 응용 프로그램에는 카피레프트를 강제하지 않는다. 다만 응용 프로그램이 라이브러리의 수정된 버전과 다시 링크될 수 있도록 하고, 라이브러리 수정 사항을 공개하도록 하는 등 일정한 의무는 부과한다. 주로 소프트웨어 라이브러리에 쓰이며, 모질라(Mozilla)나 오픈오피스(OpenOffice.org) 같은 독립적인 프로그램에도 채택된 사례가 있다.[1][2][3]

역사

설립과 초기 버전 (1991)

LGPL은 1991년 리처드 스톨만(Richard Stallman)이 이벤 모글렌(Eben Moglen)의 법률 자문을 받아 작성했으며, 처음에는 GNU 라이브러리 일반 공중 사용 허가서(GNU Library General Public License)라는 이름으로 공개되었다. 버전 번호는 당시 최신인 GPL 버전 2와 맞추기 위해 2로 정해졌다.[2][3]

명칭 변경과 2.1 버전 (1999)

1999년 마이너 개정판인 버전 2.1이 나오면서 명칭이 GNU 약소 일반 공중 사용 허가서(GNU Lesser General Public License)로 바뀌었다. 이는 "모든 라이브러리가 LGPL을 써야 하는 것은 아니다"라는 FSF의 입장을 반영한 것이었다. 리처드 스톨만은 1999년 에세이 "Why you shouldn't use the Lesser GPL for your next library"에서 LGPL이 폐기된 것은 아니지만, 모든 라이브러리에 기본으로 쓰일 필요는 없다고 밝혔다.[2][3]

버전 3 공개 (2007)

2007년 6월 29일, GPL 버전 3에 부가 권한(additional permissions) 형태로 얹히는 LGPL 버전 3이 발표되었다. LGPLv3는 GPLv3의 조항을 그대로 포함하면서 라이브러리 결합(Combined Work), 헤더 파일 인라인 코드, 설치 정보 제공 등 라이브러리 특유의 상황을 다루는 추가 조항(0~4절)을 둔다. FSF는 LGPLv2.1과 LGPLv2.0을 "폐지(deprecated)" 상태로 표시하고 있다.[3][4]

사업과 조직

배포 주체: 자유 소프트웨어 재단

LGPL의 저작권자는 자유 소프트웨어 재단(Free Software Foundation, Inc.)이다. FSF는 미국 매사추세츠주 보스턴에 본부를 둔 비영리 단체로, GNU 프로젝트와 각종 자유 소프트웨어 라이선스의 관리를 맡는다. LGPL 공식 문서와 FAQ, 번역본, 로고, 구버전 아카이브 등은 FSF가 운영하는 GNU 공식 사이트(gnu.org/licenses/lgpl.html)에서 제공된다.[4]

라이선스 구조와 버전 관리

LGPLv2 (1991, "GNU Library GPL")

LGPLv2.1 (1999, 명칭 변경)

LGPLv3 (2007, GPLv3 기반 부가 권한)

각 버전은 독립적으로 존재하며, "or any later version" 문구가 있을 때만 상위 버전으로 전환 가능하다. LGPLv3는 GPLv2와 본질적으로 호환되지 않으나, GPLv2 "or later"로 배포된 코드와는 GPLv3 전체 조건 하에 결합할 수 있다.[3]

논란·평가

FSF의 라이브러리 라이선스 권고 변화

초기 명칭 "GNU Library GPL" 때문에 "모든 라이브러리는 LGPL을 써야 한다"는 오해가 생겼으나, 1999년 명칭 변경과 스톨만의 에세이를 통해 FSF는 전략적 선택으로서 LGPL 사용을 권고하게 되었다. GPL을 쓰면 자유 소프트웨어 개발자에게 이점을 줄 수 있지만, LGPL을 쓰면 사유 소프트웨어에서도 라이브러리를 쓸 수 있어 보급에 유리하다. 프로젝트 목표에 따라 둘 중 하나를 선택하라는 것이 현재 FSF 입장이다.[3]

파생물(derivative work) 판단과 링크 방식

LGPLv2.1 5절은 "라이브러리를 사용하는 작업(work that uses the Library)"을 정의하며, 동적 링크(.so, .dll)로 결합된 독립 실행 파일을 파생물이 아닌 것으로 간주한다. 정적 링크인 경우에도 소스 코드나 링크 가능한 오브젝트 파일을 제공하면 허용된다. 하지만 "파생물 여부는 법적 문제"라는 문구가 있어, 실제 소송에서는 관할 법원 해석에 따라 결론이 갈릴 수 있다. 이 불확실성이 LGPL 채택 시 법률 검토가 필요한 이유로 꼽힌다.[2][3]

객체지향 상속과 템플릿·헤더 온리 라이브러리

C++ 템플릿, 헤더 온리 라이브러리, Ada 제네릭, Lisp 매크로 등은 컴파일 시점에 인스턴스화되어 바이너리에 녹아들기 때문에, 전통적인 "동적 링크로 분리" 모델과 맞지 않는다. LGPLv3는 3절에서 헤더 파일로부터 인라인·템플릿 코드(10줄 이하)가 객체 코드에 포함될 때 통지 의무만 부과하는 식으로 완화했다. Lisp 커뮤니티는 별도 서문(LLGPL)을, Ada는 GNAT 수정된 GPL(GMGPL)을 만들어 용어를 명확히 했다.[3]

아파치 라이선스와의 호환성

LGPLv3 ↔ Apache License 2.0: 호환

LGPLv2 / LGPLv2.1 ↔ Apache License 2.0: 비호환 (단, "or later" 조항으로 LGPLv3 선택 시 호환 가능)

모든 LGPL 버전 ↔ Apache License 1.0/1.1: 비호환

이 때문에 아파치 2.0 라이브러리와 LGPLv2.1 라이브러리를 같은 프로젝트에서 결합하려면 라이선스 예외 조항을 별도로 두거나, LGPL 쪽을 "or later"로 배포해야 한다.[3]

GPL로의 재라이선스 허용

LGPL 모든 버전은 3장(LGPLv2.1) 또는 2절 옵션 b(LGPLv3)에서 수신한 LGPL 코드를 GPL로 재라이선스할 수 있는 권한을 준다. 이로 인해 LGPL 라이브러리 코드를 GPL 프로젝트에 직접 가져다 쓸 수 있으며, 결합된 전체 저작물은 GPL 조건을 따른다.[3]

그 밖의 주제

프로그래밍 언어별 용어 명확화

LGPL 원문은 C 언어 계열(컴파일·링크·공유 라이브러리) 용어를 기준으로 쓰여 있다. ▸ Lisp: Franz Inc.가 별도 서문을 붙인 LLGPL 배포 ▸ Ada: 제네릭 인스턴스화 문제를 풀기 위한 GMGPL ▸ C++: 템플릿·헤더 온리 라이브러리 문제를 LGPLv3 3절에서 부분 해소[3]

공식 자료와 구버전 아카이브

FSF 공식 사이트에서는 ▸ LGPLv3 전문(평문·DocBook·HTML·LaTeX·Texinfo·Markdown·ODF·RTF) ▸ LGPLv3+GPLv3 결합본 ▸ LGPLv2.1·LGPLv2.0 구버전(폐지 표시) ▸ 위반 사례 대응 가이드 ▸ 번역본 ▸ 프로젝트 적용 지침 등을 제공한다.[4]

GNU 약소 일반 공중 사용 허가서

개요

역사