GFDL

GNU GPL(General Public Licence)

자유 소프트웨어 재단(FSF)에서 만든 오픈 소스 소프트웨어에 대한 라이선스 계약서라 할수 있다. 리처드 스톨먼에 의해 제창되었다. 계약서 버젼에 따라 계약내용이 다소 다르다. 크리에이티브 커먼즈 라이선스 중 CC BY-SA와 유사하다고도 할수 있으나 오픈소스 소프트웨어 라이선스로 CC계약서를 채택하는 경우는 거의 없다. GPL 파생 저작물 조항에 의한 소스 코드 배포 의무가 있기 때문에 클로즈드 소스 프로그램에는 GPL 소스코드를 사용해서는 안된다.

다음은 GPL의 주요 특징이다. (GPL은 한마디로 오픈 소스 프로그램 개발자 또는 판매자를 위한 라이선스이다.)

GPL은 배포/유통된(distributed) 소프트웨어에만 적용된다. 소프트웨어를 배포하지 않은 경우 GPL 라이센스를 채택하지 않아도 된다.
즉, GPL 소스코드를 사용한 프로그램을 판매/배포시에 상기 GPL 라이선스를 따라야 한다.

GPL 계약서에는 “파생 저작물” (Derivative Work) 라는 표현이 등장하는데 이는 GPL 프로그램 소스코드를 그대로 사용하여 컴파일할시라고 정의하고 있다. GPL소스코드를 사용한 해당 소프트웨어는 GPL 라이선스로 배포되어야 하며 그에 따라 소스코드의 제공 의무가 있다.

GNU GPL의 이러한 파생 저작물에 대한 소스코드 제공 의무나 무료 오픈 소스 소프트웨어에 대해 과거 Microsoft사는 자사의 이익에 전혀 도움이 되지 않는다 하여 반대하는 정책을 취했으며 2014년 취임한 사티아 나델라 이후에 Github나 Xamarin/Mono를 인수 합병하는 등 서드파티 진영에 대해 오픈 소스 장려 정책을 펼치고 있으며 자사 크로스플랫폼 기술에 관련한 일부 소프트웨어에 한해서만 오픈소스 정책을 펼치고 있는등 철저한 자사 이익을 위한 전략만을 고수하고 있다.

GPL 프로그램과 통신 하는 것으로는 파생 저작물 조항에 해당되지 않는다. 리눅스처럼 GPL이 적용된 운영체제에서 제공하는 API 를 사용하는 것은 무방하다. 리눅스 커널부에서 동작하는 드라이버 소프트웨어 경우에도 모듈 기반을 사용하여 커뮤니케이션하게 만들면 파생 저작물에 해당되지 않는다. 엔비디아 그래픽스 드라이버처럼 별도 모듈로 동작시키면 리눅스 커널의 파생 저작물이 아니라 커뮤니케이션이기 때문에 소스코드 배포의무가 사라진다. 이처럼 커널 레벨의 모듈로 제공시 리눅스 소스코드 관리자 쪽에서 특정 회사의 드라이버만을 위한 코드 패치를 거절하므로 커널에 포함시키지 않고 리눅스 배포자가 별도 패키지로 제공하고 있다. 모듈 형태로 GPL과 Inter-Process Communication하도록 하면 파생 저작물 조항에 해당되지 않는다는 것이다.

GPL 프로그램 소프트웨어의 출력물은 GPL 라이센스의 영향을 받지 않는다. GCC 컴파일러 프로그램 소스코드에 GPL v3 라이선스가 적용되어 있다고 해서 GCC로 컴파일한 출력파일은 GPL을 따를 필요가 없으며 stdio.h, iostream 등의 GCC 헤더 파일과 GCC 런타임 라이브러리를 사용하는 소프트웨어를 위한 예외가 추가되어 있어 GPL이 적용되지 않는다 (GPL Runtime Library Exception) [1]
이런 라이센스 예외가 적용된 libgcc, libstdc++, libfortran, libgomp, libdecnumber 등도 마찬가지로 런타임을 위해 정적 링크를 하여도 GPL의 파생 저작물 조항을 따르지 않아도 되며, GPL은 어디까지나 소스코드 사용과 관련된 것이므로 GPL을 사용한 프로그램이 생성하는 결과물은 GPL과 관련이 없다.
GPL v3의 Tivoization 방지 조항때문에 GCC 4.2.2 버전부터 BSD 라이선스와 호환이 불가능한 GPL v3가 적용되자 FreeBSD와 애플은 GCC를 버리고 LLVM/Clang으로 컴파일러를 교체하였다. 기업이 관리하는 OpenJDK와 같은 소프트웨어도 Classpath exception이라는 예외 조항으로 GPL의 “파생 저작물”에 해당하지 않도록 한 것들이 있다.

GPL 소스 코드는 판매/배포시 요청에 의해 배포된다. 인터넷 등의 매체로 GPL 소프트웨어의 바이너리를 배포하는 경우 GPL 라이선스 계약서, 소스 코드가 제공하여야 하며 사용자가 다시 제3자에게 해당 소프트웨어를 재배포하는 것이 허용된다.

GPL 프로그램 소스 코드를 인터넷(HTTP,FTP)이건 또는 비용 청구하여 우편으로건 직/간접적인 방법으로 소스코드를 받을수 있도록 하면된다. GPL 버전 2의 3조에 따르면 3가지 방법이 있는데, a항은 같이 배포하는 것, b항은 최소 3년 동안 연락하면 인터넷으로 직/간접적으로 받게 하거나 일정 비용을 청구 CD/USB 미디어를 통해 소스코드를 제공하는것, c항은 b항을 통해 전달받은 코드를 제3자에게 전달할 때 b항의 내용을 전달해 주는 것. 이것이 전부다. 애초에 소프트웨어를 인터넷으로 배포하는 경우 소스 코드를 인터넷으로 같이 배포하면 a의 방법을 충족할 수 있으니까 문제가 없지만, 하드웨어 상의 소프트웨어의 경우는 소스 코드를 함께 배포하지 않는 한 b항을 택하면 된다.

프로그램은 무료로 쓰게 하면서 상업적 용도나 클로즈드 소스에 사용시 유료 라이선스를 취하고 있는 경우도 있다. Qt와 GhostScript가 있다. 참고로, 2015년 이후 보다 경쟁력 있는 소프트웨어 패지지들이 등장하면서 GPL의 그러한 소프트웨어 라이선스 전략은 시장에서 먹혀들지 않고있다.

GPL 소스 코드 프로그램 판매/배포자는 www.gnu.org 사이트의 GPL 라이선스 문서를 확인해 보면된다. GPL 소스코드를 사용하여 클로즈드 소스 상용 프로그램에 이용할 경우 GPL 소프트웨어 진영으로 부터 소송을 당할수도 있으나 소스코드 배포 의무가 없는 보다 경쟁력 있는 소프트웨어 패키지들이 등장하면서 OS 레벨의 일부 GPL 프로그램을 제외하고는 GPL의 영향력은 거의 없다.

GPL은 '기여자의 변형물 및 변형물에 포함되는 저작물'에 대해 특허권을 가지는 것은 인정하지만, GPL 라이선스가 적용되는 한에서 그 특허발명에 대한 제한없는 실시권 허락을 요구한다.[2]

개발자 홍길동이 자신이 작성한 소스 코드 A에 특허를 등록했다고 가정하자. 그런데 몇몇 기능들은 자신이 직접 만들 수 없어서 GPL로 배포되는 소스 코드 B를 가져다 붙이고 최종 프로그램인 A+B를 배포했다. 이럴 경우 GPL 라이선스 조항에 의해 A+B 전체가 GPL로 변한다. B의 라이선스가 GPL이 아니라면 A+B를 만든 홍길동은 '기여자'이고, 소스 코드 B에다 특허 출원된 A를 붙여 A+B라는 '변형물'을 기여한 것이므로 A와 A+B 모두에 대해 특허가 인정될 것이다. 그런데, GPL은 '비배타적이고 비상업적인' 경우에 한해서만 특허를 인정한다. 따라서 홍길동이 자신의 프로그램 A+B에 대해 특허를 인정받고 싶다면, A+B라는 '변형물'은 물론 그 변형물에 '포함되는' 소스 코드 A도 제약 없이 무료로 공개해야 한다. 이는 사실상 특허를 무력화시키는 것이라고 할 수 있다. 단, GPL이 적용되는 A+B에 포함되지 않는 저작물, 예를 들어 A+C의 경우에는 이러한 조항이 적용되지 않는다. 그리고 GPL이 적용된 프로그램이 제3자의 특허를 침해했을 경우, 그 날로 GPL의 효력은 종료된다.

아파치 라이선스의 것과 비슷한데, GPL에 따라 소스 코드를 사용했더니 특허침해라며 소송당하는 것을 방지하기 위한 조항이라고 한다.

2007년에 개정된 GPL v3은 하드웨어가 수정된 GPL 소프트웨어를 거부할 수 없도록 했다. 하드웨어 기기에 GPL v3 라이선스가 적용된 소프트웨어가 포함되는 경우 이용자가 해당 소프트웨어를 변경하여 구동시켰을 때 하드웨어가 실행을 거부할수 있는 DRM을 적용 한다면 위반이라는 조항이다. LGPL v3도 같은 내용이 추가된 것이다.

이처럼 수정된 GPL 소프트웨어의 하드웨어 구동을 막는 것을 GNU에서는 Tivoization이라 한다. 리눅스를 사용하는 TiVo 라는 DVR 업체가 서드파티의 모디파이된 바이너리 GPL 소프트웨어를 실행하지 못 하도록 했던게 어원이다. 리눅스 진영의 리누스 토르발스가 이러한 DRM 금지 라이선스 개정에 대해 반발했다. 이 때문에 리눅스는 GPL v2로의 배포만 허용한다.[3]

GPL은 이용허락 철회를 금지하고 있다. 따라서 이용허락 시에 몇 판 및 그 이후 버전으로 배포하는 식으로는 이용허락이 가능하지만, "최신판으로만 배포"는 허용되지 않는다. 최신판으로만 배포하게 해버리면 최신판이 공표되는 순간 이전 판의 이용허락이 자동적으로 철회되기 때문이다.

상식적인 것이지만 상표권과 GPL 소프트웨어와는 별개사항이다. 예를 들어 CentOS는 상용 레드햇 엔터프라이즈 리눅스 운영체제 소프트웨어를 레드햇의 브랜드/로고는 다른 것으로 리브랜딩하고 소스 코드 일부를 수정하여 재배포하고 있으며 크롬이 크로미움으로 이름을 바꾸고 오픈소스화 하여 배포되는 것이 그 예.

GNU의 다른 라이센스 종류로는 GNU 약소 일반 공중 사용 허가서(GNU Lesser General Public License, LGPL)와 더불어 문서에 써먹을 수 있는 GNU 자유 문서 사용 허가서(GNU Free Documentation License, GFDL)가 있다. GFDL은 문서에 대한 GPL로 볼 수 있으며, 위키백과의 라이선스이기도 하였다.[4] 또한 네트워크를 주로 활용하는 프로그램에 적용할 수 있는 GNU 아페로 일반 공중 사용 허가서(GNU Affero General Public License, AGPL)도 있다.

GPL과 달리 API나 라이브러리로 제공되는것을 사용하는 것에는 파생 저작물에 해당되지 않기 때문에 주로 소프트웨어 공급자의 라이브러리 소스코드에 적용되는 라이센스이다. LGPL 소프트웨어 라이브러리를 스테틱 정적 링크[5]할경우 소프트웨어의 오브젝트 파일[6]을 제공하면된다. LGPL 라이브러리를 다이나믹 동적 링크로 사용시 소스 코드 공개 의무가 없다.

LGPL은 파생 저작물에 해당되지 않는 라이브러리 소스코드 라이선스로서 많이 채택하고 있다. [7] 애초에 라이브러리를 염두에 두고 만들어진 라이선스라서, 초기 LGPL 라이선스의 명칭은 GNU Library General Public License였다. 그러나 라이브러리 뿐아니라 해당 라이선스에 대해 보다 허용적 내용이 있어 약자는 그대로이고 Library가 Lesser로 변경되었다.

기존의 GPL과 LGPL은 네트워크 동작에 대한 규정이 부족하다는 점을 보완하기 위하여 새롭게 만들어졌다.

L/GPL에서 정의하고 있는 "Distribute"나 "Convey"의 경우 “바이너리”가 사용자에게 전달되는 때를 의미하는데 바이너리를 배포하지 않고 SaaS(Software as a Service) 같은 클라우드 서비스 환경처럼 소프트웨어가 실행되는 결과값만 네트워크로 전달하는 방법을 사용해 GPL 소스 코드를 사용하고 개작하였지만 해당 바이너리가 소비자에게 배포되거나 노출되지 않으면 소스 코드를 배포하거나 라이센스 고지 의무가 없다는 약점을 보완하기 위한 라이센스이다.

AGPL이 적용된 소프트웨어 혹은 라이브러리가 다른 소프트웨어와 네트워크로 연결되어 이용된다면 그 소프트웨어 혹은 라이브러리의 소스코드를 공개하여야 한다. 다만, 네트워크로 연결된 상대방 소프트웨어의 소스코드를 공개하여야 할 의무는 없다.(HTTP 통신을 통해 클라이언트와 연결되는 경우 등을 생각해보면 이것이 실현 가능하지도 않다.) 네트워크의 '사용 여부'를 가지고 판별하므로 LGPL과 달리 정적/동적 링킹의 구분은 무의미하다.

한글과컴퓨터 측은 AGPL+상용 라이선스가 적용된 Artifex 사의 PDF 인터프리터 고스트스크립트(Ghostscript)를 한컴오피스에 무단으로 적용했다가 소송을 당했다. 이렇게 듀얼 라이선스를 가진 라이브러리를 사용하려면 저작권자에게 비용을 내거나, 해당 모듈이 적용된 전체 프로그램의 소스 코드를 공개해야 하는데 한컴은 어떤 조치도 하지 않았던 것. 결국 2017년 5월, 미 연방법원으로부터 GPL은 법적 계약과 동일한 효력이 있다는 판결을 받았고, # 이후 한컴은 Artifex와 고스트스크립트 라이선스 사용에 합의하였다. #

소프트웨어의 사용자에게만 소스 코드 공개의 의무가 발생하므로, 개인적 용도나 사내에서 사용하는 것은 문제가 없지만 유출되는 경우는 별개다. 이것과 관련해 국내에 이와 같은 사건이 일어나기도 했다. 저작물 유출로 인해 단, 2차적 저작물은 독자적인 저작물로 보호되기 때문에 원저작자라 하더라도 배포를 하라고 강제할 권리는 없다. 이 사건은 차후 GPL에 근거하여 소스 코드 공개가 이루어졌지만, 법원은 GPL이 적용되는지를 별론으로 하고 영업비밀을 유출했기 때문에 피고인이 위법행위를 했다고 판결하였다.

국내 동영상 플레이어 프로그램들의 GPL 위반 의혹이 나기도 한다. 이유는 대부분의 플레이어에서 사용하는 FFmpeg이 GPL와 LGPL 이중 라이선스를 사용하기 때문인데, GPL가 포함된 부분까지 사용하고서는 소스 공개를 하지 않는 것이다.

이 문제에는 KMPlayer, 곰플레이어, 팟플레이어 등이 해당된다. 그냥 FFmpeg를 별 생각없이 프로그램에 내장시켰다가 GPL 위반 의혹이 난 것. GPL 위반 문제가 제기되도 별다른 대응이 없지만 그 중에서 팟플레이어가 소스를 공개하였다. 물론 전체 소스코드는 아니고 LGPL 라이선스와 함께 수정된 FFmpeg 소스코드를 다운로드 받을 수 있는 링크를 제공하고 본래의 프로그램에서 FFmpeg를 제거하고 따로 코덱 설치 파일을 배포한다. iOS의 AVPlayer의 경우는 소스코드 전체를 공개하고 있다.

gnu gpl violation이나 gpl-violations.org와 같이 GPL 라이센스 위반으로 부터 보호하는 단체도 있다. 오픈소스 GPL 프로그램 디자이너들은 특히 대기업이 GPL 관련하여 저작권을 침해하고 있다고 의심 되는 경우 이러한 단체에 신고하면 된다.

LGPL, MPL, BSD, MIT 허가서나 아파치 라이선스 같은 기타 많은 오픈 소스 라이선스들은 GPL과 같은 소스 코드 공개 의무가 없으며, 이러한 라이선스의 비중이 GPL 계열보다 많다. GPL은 보통 OS 레벨 소스 코드에 많이 적용되고 있으며 오래된 유틸리티 등의 프로그램들이 처음 개발될 당시 GPL라이센스로 시작된것이 있지만 그에 대한 대체 라이선스 코드들이 등장하면서 GPL의 영향력은 없어지고 있다.

소스 코드 비공개를 원하는 상용 소프트웨어 회사(특히 대기업)에게는 GPL이 불리하다. 그러나, 유료 GPL 소프트웨어를 재판매도 가능하고 무료 GPL 소프트웨어 소스코드를 수정해서 유료로 재판매가 가능하다는 장점이 있다. GPL 프로그램 개발자, 판매자, 재판매자에게는 오히려 유리한 것이 GPL이다. 주로 여러 유료 GPL 프로그램을 번들형태로 합쳐 파격적인 할인 가격의 패키지 형태로 재판매하고 있는 경우가 많다.

오픈소스 소프트웨어 진영의 경우 소스코드를 공개하여 많은 사람들이 참여하도록 하고 프로그램을 전략적으로 버젼업 시키는 형태를 취하거나 공개 소프트웨어를 사용한 서비스나 상품을 통한 수익으로 클로즈드 소스 유료 소프트웨어 진영과 경쟁을 하고 있는 경우가 많다. 그리고 대게 오픈소스 소프트웨어 진영은 클로즈드 소스 유료 프로그램을 캐칭업하는 전략을 펼치고 있는것이 일반적이다.

GPL 소스코드의 파생 저작물 조항을 회피하기 위한 방법으로는 리버스 엔지니어링에 의해 소스코드를 재작성하는 방법이 있다. 구글링을 해보면 GPL 파생 저작물 조항을 회피하는 방법이 많이 소개되어 있으며 소스코드 배포의무가 없는 보다 경쟁력있는 라이선스의 소프트웨어 소스코드 패키지들이 등장하면서 OS레벨의 일부 프로그램을 제외하고는 GPL의 영향력은 미미하다. 또한, GPL 소스코드를 리버스 엔지니어링한 중국이나 러시아쪽 소스코드를 사용하여 GPL을 우회/회피 하는 방법도 있다.