Skip to content

GNU General Public License

GNU 일반 공중 사용 허가서(GNU General Public License, GNU GPL 또는 GPL)는 자유 소프트웨어 재단에서 만든 자유 소프트웨어 라이선스이다. 대표적으로 리눅스 커널이 이용하는 사용 허가이다. GPL은 가장 널리 알려진 강한 카피레프트 사용 허가이며, 이 허가를 가진 프로그램을 사용하여 새로운 프로그램을 만들게 되면 파생된 프로그램 역시 같은 카피레프트를 가져야 한다. 이러한 철학에서 GPL은 컴퓨터 프로그램을 이용하는 사람에게 자유 소프트웨어의 권한을 누리며 카피레프트를 사용함으로써 그러한 자유가 보전되고, 심지어는 그러한 작업이 변형되거나 추가될 수도 있는 자유마저 있다. 이는 허용적인 자유 소프트웨어 허가로서, BSD 사용허가가 대표적인 예이다.

GNU 약소 일반 공중 사용 허가서(The GNU Lesser General Public License, LGPL)는 이를 변형하여 더 허가된 형태로서, 소프트웨어 라이브러리를 염두에 둔 것이다. 또 GNU 자유 문서 사용 허가서 (GNU FDL)은 GNU 소프트웨어에 대한 문서의 사용 허가로 시작하였으나 위키백과 프로젝트와 같이 다른 문서 형태에도 널리 퍼지게 되었다.

다만 현재까지 이 계약서는 미국과 유럽 일부 국가등에서만 법원의 판단등으로 합법한 계약서로 인정받았고, 대다수 국가에서는 이에 따른 법률적 판단을 받은 바 없다. 대한민국 내에서도 직접 이 계약서가 합법한가에 대한 법원의 판단은 없었으며, 다만 계약서라는 특성상 준법행위를 하는 다수는 분쟁없이 이 계약서의 제약을 따르고 있을 뿐이다.

대한민국 내에서도 한 차례 법원의 판단을 받을 뻔했던 엘림넷과 하이온넷 사건이 있었으나, 회사 기밀 유출 사건으로 형사기소되는 바람에 중요 쟁점일 수 있었던 GPL 에 대한 판단은 형사법원에서 다루지 않고 다른 이유로 1,2심 법원에서 유죄를 판결, 최종 확정한 바 있다.

따라서 현재로서는 적어도 공정거래위원회 등을 통해 표준 약관심의 따위를 받아 확정지을 필요가 있으며, 다만 그렇다 하더라도 이 표준 계약서가 부당하다는 법률적 판단도 없으므로, 이 계약을 위반할 시 자유 소프트웨어 재단으로부터 기소당할 수 있다.

주요 원칙

GPL의 주요 원칙은 다음과 같다.

  • 컴퓨터 프로그램을 어떠한 목적으로든지 사용할 수 있다. 다만 법으로 제한하는 행위는 할 수 없다.
  • 컴퓨터 프로그램의 소스 코드를 용도에 따라 변경할 수 있다. (개작 가능)

아래의 내용은 GPL의 주요 특징인 '전염성'에 관한 부분이다.

  • 컴퓨터 프로그램의 실행 복사본은 언제나 프로그램의 소스 코드와 함께 판매하거나 소스코드를 무료로 배포해야 한다. (원본 배포 전염성)
  • 변경된 컴퓨터 프로그램 역시 프로그램의 소스 코드를 반드시 공개 배포해야 한다. (파생물 배포 전염성)
  • 변경된 컴퓨터 프로그램 역시 반드시 똑같은 라이선스를 취해야 한다. 즉 GPL 라이선스를 적용해야 한다. (파생물 라이선스 전염성)

LGPL 원칙

LGPL은 전염성에 대한 강제 조항은 없다.

  • LGPL "라이브러리"는 소스 코드를 공개해야 한다.
  • 다만 사용자가 Library 수정 후 동일한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그램의 Object Code를 제공해야 함.

IPC 사용에 대한 내용

"저는 GPL 프로그램과 (정적이든 동적이든) 링크하지 않습니다. 저는 소켓이나 IPC를 사용하고 있을 뿐입니다."

[우리는] [GPL 프로그램과 폐쇄 소스 앱] 사이에 어떤 종류의 API를 구현하고 싶습니다. [GPL 프로그램]은 클라이언트처럼 작동하므로 폐쇄 소스 앱은 API를 제공해야 합니다. 제가 아는 한, 정적 또는 동적으로 링크된 라이브러리와 같은 프로그램 수준 API를 구현하려면 서비스 제공 애플리케이션 코드를 공개해야 합니다.

이 주제에 대한 기존의 인터넷 상식은 다음과 같습니다. "LGPL 프로그램과 정적으로 링크하는 경우 프로그램도 (L)GPL이어야 합니다. LGPL 프로그램과 동적으로 링크하는 경우 프로그램은 폐쇄 소스로 유지될 수 있습니다. GPL 프로그램과 정적으로 또는 동적으로 링크하는 경우 프로그램도 GPL이어야 합니다."

그러나 이것은 GPL이 말하는 바와 전혀 다르며, 실제로 법적 분쟁이 있는 경우 판사가 이런 식으로 볼 가능성은 낮습니다. GPL의 섹션 5는 GPL 프로그램을 배포할 때 해야 할 일이라는 주요 의무를 다룹니다.

이 라이선스에 따라 사본을 소유하게 된 모든 사람에게 전체 작품을 전체적으로 라이선스해야 합니다 . 따라서 이 라이선스는 해당 섹션 7 추가 조건과 함께 전체 작품과 모든 부분에 적용되며, 패키지 방식에 관계없이 적용됩니다 .

프로그램이 LGPL이거나 링크 예외가 있는 GPL인 경우, 라이선스에 추가 언어가 있어서 어떤 상황에서 프로그램을 귀하의 프로그램과 결합할 수 있는지 명확히 설명하며, 귀하의 프로그램에 동일한 방식으로 라이선스를 부여할 필요가 없습니다. 그러나 일반적인 GPL의 경우 위 문단을 면밀히 살펴봐야 합니다.

따라서 진짜 질문은 최종 제품이 궁극적으로 하나의 작품으로 간주될지 아니면 별도의 작품으로 간주될지입니다. 이는 제품이 서로 IPC를 사용하는 두 개의 실행 파일로 패키징되든, 하나의 실행 파일과 일부 DLL, 정적으로 링크된 코드가 있는 하나의 실행 파일 또는 다른 방식으로 패키징되든 마찬가지입니다. FSF는 FAQ에서 이에 대한 답을 시도했습니다.

두 부분을 하나의 프로그램으로 결합하는 것은 무엇을 구성하는가?이는 법적 문제이며, 궁극적으로 판사가 결정할 것입니다.우리는 적절한 기준이 통신 메커니즘(exec, 파이프, rpc, 공유 주소 공간 내의 함수 호출 등)과 통신의 의미(어떤 종류의 정보가 교환되는지)에 달려 있다고 믿습니다.

모듈이 동일한 실행 파일에 포함되어 있는 경우, 확실히 하나의 프로그램으로 결합됩니다. 모듈이 공유 주소 공간에서 연결되어 실행되도록 설계된 경우, 이는 거의 확실히 모듈들을 하나의 프로그램으로 결합한다는 것을 의미합니다.

대조적으로 파이프, 소켓 및 명령줄 인수는 일반적으로 두 개의 별도 프로그램 간에 사용되는 통신 메커니즘입니다. 따라서 통신에 사용될 때 모듈은 일반적으로 별도의 프로그램입니다. 그러나통신의 의미가 충분히 친밀하고 복잡한 내부 데이터 구조를 교환하는 경우 두 부분을 더 큰 프로그램으로"결합"한 것으로 간주할 수 있는 근거가 될 수도 있습니다.

결론

프로그램 간 IPC를 통한 통신이 GPL 라이선스의 전염성을 유발하는지 여부는 해당 프로그램 간의 통합 정도와 독립성에 달려 있습니다.

일반적으로 IPC를 통한 단순한 데이터 교환은 전염성을 유발하지 않지만, 긴밀한 결합이 있는 경우에는 GPL 전염성을 고려해야 합니다.

명확한 법적 조언이 필요하다면, 관련 법률 전문가나 소프트웨어 라이선스 전문가와 상담하는 것이 좋습니다.

QnA

LGPL 라이브러리 동적링크를 통한 플러그인 제작시 라이선스
OLIS - LGPL 라이브러리 동적링크를 통한 플러그인 제작시 라이선스
LGPL 라이선스가 적용된 jar 라이브러리를 귀하가 개발하고자 하는 A 소프트웨어에 동적 링킹하여 사용하는 경우 A 소프트웨어는 LGPL의 영향을 받지 않으며, LGPL에 해당하는 라이브러리의 소스코드만 공개하면 됩니다.
만약 LGPL jar 라이브러리에 수정을 가했다면 수정한 버전의 소스코드 역시 수취인에게 배포해야 합니다.
LGPL 배포 라이브러리를 수정/변경 없이 사용하고, 개발 프로그램에 해당 라이브러리를 정적 링크, 동적 링크로 사용했을 경우 개발한 프로그램의 공개 여부 및 공개 범위
GPL v3, LGPL 라이선스 문의
LGPL 라이선스는 라이브러리와 링크하는 응용 프로그램의 소스 코드 공개에 완화된 라이선스입니다. 따라서 LGPL 라이브러리와 개발 프로그램을 링크하여 결합해도 LGPL 라이선스가 전염되지 않으며 개발 프로그램의 소스 코드를 공개하지 않아도 됩니다.
라이선스의 적용을 받는 라이브러리와 프로그램을 링크하여 연결하여 만들어진 프로그램은 '라이브러리를 사용하는 저작물'에 해당합니다. '라이브러리를 사용하는 저작물'은 리버스 엔지니어링(reverse engineering)이 가능해야 합니다. 라이브러리의 소스코드는 제1조와 제2조에 따라 공개 되어야 하고, 개발 프로그램의 경우에는 오브젝트 코드를 제공하여 프로그램 수취인이 라이브러리를 수정한 후에도 실행 할 수 있도록 해야 합니다.

Exception

호환성

BSD

GPL3로 바뀌면서 BSD 라이센스와 호환이 불가능해 졌다. 대표적으로 GCC가 4.2 버전부터 GPL2에서 GPL3로 변경되면서 BSD진영에서 LLVM/CLANG으로 갈아타는 현상이 발생되었다.

Document

GPL

LGPL

GFDL

See also

Favorite site

GPL & LGPL Issue

References

  1. Korea.gnu.org-gpl.zip ↩