오픈소스 라이센스 소개

해당 게시물은 한국저작권위원회가 발행한 오픈소스 소프트웨어 라이선스 가이드 3.0을 참고해서 작성되었습니다.

소프트웨어 지적 재산권

저작권(copyright)

창작물에 대하여 창작자(저작자)가 취득하는 권리로서 창작의 결과물을 보호하며, 창작과 동시에 권리가 발생한다. 따라서 어떤 프로그래머가 소프트웨어를 개발하면 저작권이 자동으로 발생하며, 그 권리는 프로그래머 또는 그가 속한 회사에 부여된다. 저작권이 있는 저작물은 저작권자의 허락이 없이는 누구도 해당 저작물을 복제, 배포, 수정할 수 없다.

특허권(patent)

특허권(patent)은 발명에 관하여 발명자(특허권자)가 갖는 독점배타권이다. 저작권과는
달리 일정한 방식으로 출원해야 하며, 심사를 통과한 후 등록되어야만 권리가 발생한다.

특허기술을 사용하기 위해서는 반드시 특허권자의 허락을 얻어야만 한다. 특허받은
방식을 구현하는 소프트웨어라면 프로그래밍 언어에 상관없이 특허권의 범위에 속한다.

공개되지 않은 소스코드는 영업비밀로서 보호를 받을 수 있다. 하지만 영업비밀은 일단
공개되면 더 이상 보호받기 어렵고, 또한 영업비밀을 알지 못하고 사용한 제3자에게
법적으로 문제를 삼을 수 없다는 한계가 있다.

오픈소스 라이선스

일반 상용 소프트웨어와 마찬가지로 오픈소스에도 저작권 등 지적재산권이 있다. 그래서 권리자의 허락 없이 함부로 사용하면 소송을 당할 수 있다.

그런데 오픈소스의 권리자들은 되도록 많은 사람이 자유롭게 사용할 수 있도록 광범위한 라이선스를 부여하고 있다.

예를 들어 사용자들에게 사용에 대한 권리뿐만 아니라 마음대로 복제 및 배포를 할 수 있도록 하고, 소스코드까지 제공하여 마음대로 수정할 수 있도록 허락한다.
하지만 상용 소프트웨어처럼 그에 따르는 로열티를 요구하지는 않으며, 대신 몇 가지 지켜야 할 의무사항을 요구한다.

구체적인 예를 통해 몇 가지 의무사항을 살펴보기로 하자.

저작권, 개발자 및 기여자 정보의 표시

대부분의 오픈소스 라이선스는 개발자 또는 기여자에 관한 사항과 저작권에 관한 사항을 제품에 표시하거나 포함하도록 요구하고 있다. 마치 저작인격권의 하나인 성명표시권과 유사하다.

코드를 수정한 경우 수정한 정보의 표시

이용자가 소스코드를 수정하였을 때에는 수정한 사람, 수정 일자 등 수정에 관한 내용을 포함하도록 함으로써, 원본과 구별할 수 있도록 한다. 저작인격권의 하나인 동일성유지권에 비유할 수 있다.

라이선스 정보의 제공

많은 오픈소스 라이선스들은 이용자들이 오픈소스에 관한 권리를 잘 이해할 수 있도록 배포자가 해당 라이선스의 사본을 함께 첨부할 것을 요구하고 있다.

동일한 라이선스로 재배포할 것 (카피레프트)

라이선스에 따라 큰 차이를 보이는 부분은 ‘카피레프트(Copyleft)’에 관한 사항이다.

GPL을 대표로 하는 카피레프트 라이선스들은 이용자들이 소프트웨어를 수정한 후 배포하고자 할 때 수정된 소프트웨어도 동일한 라이선스로 배포할 것을 요구한다.

카피레프트(Copyleft)라는 용어는 원래 저작권(Copyright)에 반대한다는 의미로 “Copy-right”에서 “right” 대신 “left”로 바꾸어 사용하기 시작한 것이다. 그런데, FSF가 말하는 “소프트웨어의 자유”를 지키기 위한 구체적인 수단이 GPL이며, 그 중에서도 핵심적인 내용은 파생저작물을 GPL로 재배포할 것을 요구하는 조항이기 때문에, 보통 이 조항을 가리켜 카피레프트 조항이라고 부르고 있다.

소스코드의 제공

카피레프트 조항을 포함하는 라이선스의 경우, 소프트웨어를 배포할 때 소스코드까지 함께 배포하도록 요구한다.

라이선스의 특징 및 의무사항	BSD	Apache2.0	GPL 2.0	GPL 3.0	LGPL 2.1	MPL	CDDL	CPL/ EPL
복제·배포·수정의 권한 부여	O	O	O	O	O	O	O	O
배포시 라이선스 사본 첨부		O	O	O	O	O	O	O
저작권고지사항 또는 Attribution 고지사항 유지	O	O	O	O	O	O	O	O
배포시 소스코드 제공 의무(Reciprocity)와 범위			derivative work	work based on the program	derivative work	file	file	module
조합저작물(Larger Work)작성 및 타 라이선스 배포 허용	O	O			O	O	O	O
수정시 수정내용 고지		O	O	O	O	O	O	O
명시적 특허라이선스의 부여		O		O		O	O	O
라이선시가 특허소송 제기시 라이선스 종료		O		O		O	O	O
복이름, 상표, 상호에 대한 사용제한	O	O				O	O	O
보증의 부인	O	O	O	O	O	O	O	O
책임의 제한	O	O	O	O	O	O	O	O

주요 오픈소스 라이선스

BSD형 라이선스 및 주요 프로젝트

BSD형 라이선스에는 BSD, MIT, Apache 라이선스 등이 포함되며, 비교적 오랜 역사를 가진 라이선스들이다. 이들 라이선스는 카피레프트(Copyleft) 조항을 포함하지 않으며, 의무사항도 비교적 간단하다.

BSD 라이선스

BSD 라이선스는 버클리 대학에서 만든 라이선스로, 소프트웨어를 재배포할 때 저작권 표시를 할 것과 준수 조건 및 보증부인에 대한 고지사항을 소스코드 또는 문서 및 기타자료에 포함할 것을 요구하고 있다.

4개의 조항으로 구성된 BSD 4-Clause 라이선스 (Original BSD 혹은 Old BSD 라고도 불림)에는 “광고 조항”이 포함되어 있다.
이는 파생저작물의 모든 홍보물에 “This product includes software developed by the ” 문구를 포함해야 하는데, 이는 문제 소지가 있는 조항으로 판단되어 1999년 7월 이를 삭제한 BSD 3-Clause 라이선스(Modified BSD 혹은 New BSD 라고도 불림)가 만들어졌다.

Apache 라이선스

Apache 라이선스는 아파치소프트웨어재단(Apache Software Foundation)에서 만들어 배포한 라이선스이다. 1.0과 1.1 버전은 BSD와 비슷하게 간단한 내용만을 담고 있었지만, 현재 사용되고 있는 2.0 버전은 2004년에 배포된 것으로 비교적 상세한 내용을 담고 있다.

배포 시의 의무사항으로는 저작권, 특허, 상표, 권리귀속(attribution)에 대한 고지사항을 소스코드 또는 “NOTICE” 파일 등에 포함할 것과, 수취인에게 라이선스 사본을 제공하도록 요구하고 있으며, 파일을 수정하여 배포할 경우 수정된 파일에 대해 수정사항을 표시한 안내 문구를 첨부할 것을 요구하고 있다.

하지만 카피레프트 조항을 포함하고 있지 않기 때문에 반드시 동일한 라이선스로 배포할 필요는 없으며, 소스코드 제공 의무도 없다는 점에서 기본적으로 BSD 라이선스와 비슷한 것으로 평가할 수 있다.

MIT License

MIT 라이선스(MIT License)는 미국 매사추세츠 공과대학교(MIT)에서 해당 대학의 소프트웨어 공학도들을 돕기 위해 개발한 라이선스다.

MIT 라이선스를 따르는 소프트웨어를 개조한 제품을 반드시 오픈 소스로 배포해야 한다는 규정이 없으며 GNU 일반 공중 라이선스의 엄격함을 피하려는 사용자들에게 인기가 있다.

The MIT License

MIT 라이선스

Copyright (c)

Copyright (c) <연도> <저작권자>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

이 소프트웨어의 복제본과 관련된 문서화 파일(“소프트웨어”)을 획득하는 사람은 누구라도 소프트웨어를 별다른 제한 없이 무상으로 사용할 수 있는 권한을 부여 받는다. 여기에는 소프트웨어의 복제본을 무제한으로 사용, 복제, 수정, 병합, 공표, 배포, 서브라이선스 설정 및 판매할 수 있는 권리와 이상의 행위를 소프트웨어를 제공받은 다른 수취인들에게 허용할 수 있는 권리가 포함되며, 다음과 같은 조건을 충족시키는 것을 전제로 한다.

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

위와 같은 저작권 안내 문구와 본 허용 문구가 소프트웨어의 모든 복제본 및 중요 부분에 포함되어야 한다.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF ERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

이 소프트웨어는 상품성, 특정 목적 적합성, 그리고 비침해에 대한 보증을 포함한 어떠한 형태의 보증도 명시적이나 묵시적으로 설정되지 않은 “있는 그대로의” 상태로 제공된다.

소프트웨어를 개발한 프로그래머나 저작권자는 어떠한 경우에도 소프트웨어나 소프트웨어의 사용 등의 행위와 관련하여 일어나는 어떤 요구사항이나 손해 및 기타 책임에 대해 계약상, 불법행위 또는 기타 이유로 인한 책임을 지지 않는다.

안드로이드 플랫폼

아파치 서버 등 아파치재단의 프로젝트들뿐만 아니라, (2008년 조사결과) Source Forge.net의 5,000개 이상의 프로젝트가 Apache 라이선스로 배포되고 있다.
또한, 2008년 5월 구글은 블로그를 통해 Google Code의 100,000여개 프로젝트 중 25%가 Apache 라이선스를 사용하고 있다고 발표했었다.

최근 Apache 라이선스로 배포되는 가장 큰 프로젝트는 안드로이드 플랫폼이다.
커널과 애플리케이션을 제외한 안드로이드 플랫폼의 많은 부분은 Apache 라이선스로 배포되고있다.

하지만 일부 구성요소들은 CPL, EPL, GPL, LGPL 등으로 배포되고 있으며, 이들은 Apache 라이선스가 아닌 각각의 라이선스 규칙을 따라야 한다는 점을 주의할 필요가 있다.

APACHE2 bionic/linker
APACHE2 dalvik
APACHE2 dalvik/libcore-disabled/instrument
APACHE2 dalvik/libcore-disabled/sound
APACHE2 dalvik/libcore/annotation
APACHE2 dalvik/libcore/archive
APACHE2 dalvik/libcore/auth
APACHE2 dalvik/libcore/awt-kernel
APACHE2 dalvik/libcore/crypto
APACHE2 dalvik/libcore/dalvik
APACHE2 dalvik/libcore/logging
APACHE2 dalvik/libcore/luni
APACHE2 dalvik/libcore/luni-kernel
APACHE2 dalvik/libcore/math
…

CPL dalvik/libcore/junit
EPL prebuilt/common/eclipse
EPL prebuilt/common/osgi
EPL prebuilt/darwin-x86/swt
...
GPL external/blktrace
GPL external/e2fsprogs
GPL external/e2fsprogs/e2fsck
...
LGPL external/e2fsprogs/lib/blkid
LGPL external/e2fsprogs/lib/e2p
...
MIT external/e2fsprogs/lib/ss
OSL1 external/elfutils
W3C dalvik/libcore/xml

안드로이드 애플리케이션의 라이선스 이슈

미들웨어가 Apache 라이선스로 배포되는 경우 애플리케이션의 라이선스에는 영향을 미치지 않는다. 그 결과 애플리케이션의 개발자들은 자유롭게 라이선스를 결정할 수 있다. 유료의 상용 라이선스를 선택하는 것도 물론 가능하다.

구글이 안드로이드 플랫폼에 대한 라이선스를 GPL이 아닌 Apache 라이선스로 결정한 것은 더욱 많은 개발자들의 참여를 끌어내기 위해서이다. 스마트폰의 경쟁력은 얼마나 많은 애플리케이션을 확보하고 있는가에 달려 있다.

구글의 입장에서는 GPL로 대변되는 오픈소스의 정신을 존중하는 것도 중요했지만, 개발자들에게 라이선스를 선택할 수 있는 자유를 주어 보다 많은 애플리케이션이 개발될 수 있도록 하는 것이 더 중요했다고 볼 수 있다.

그런데 애플리케이션에 따라서는 기존의 오픈소스를 기반으로 개발되는 것도 있다. 이러한 경우 해당하는 오픈소스 라이선스를 지켜야 하는 것은 물론이다. 예를 들어 GPL로 배포되는 오픈소스를 기반으로 안드로이드 애플리케이션을 개발하는 경우 GPL에 따라 소스코드를 제공해 주어야 한다. 앱스토어(안드로이드 마켓)를 통해 직접 소스코드를 제공하는 것은 어려우므로 애플리케이션의 일정 부분에 소스코드를 제공한다는 안내를
하고 다른 웹서버를 통해 소스코드를 제공하는 방법을 고려할 수 있다. 이러한 사항을 지키지 않는 경우 라이선스 위반에 해당하여 소송을 당할 수 있다.

이러한 경우 애플리케이션 개발자가 책임을 지는 것과는 별도로, 앱스토어 운영사도 라이선스 위반에 대한 책임이 있는가? 이 문제는 이용자의 저작권 침해에 대해 네이버 등 서비스제공자도 책임을 져야 하는가의 문제와 유사하다. 서비스유형에 따라 다른 판결이 나오고 있지만, 권리자가 권리침해가 있다는 통지를 해오는 경우 서비스제공자는 즉시 관련 저작물을 삭제하는 것으로 대응하고 있다.

GPL형 라이선스

GPL형 라이선스에는 GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0, AGPL 3.0 등이 포함되며, 대부분 FSF(Free Software Foundation)에서 주도하여 만든 것이다.

비교적 오랜 역사를 가진다는 점에서 BSD와 비슷하지만, 카피레프트 조항과 소스코드 제공 의무를 가지고 있다는 점에서 큰 차이가 있다. 카피레프트의 적용 범위 및 소스코드 제공 의무의 범위는 GPL, LGPL, AGPL 각각에 차이가 있다.

GPL 2.0

GPL 2.0으로 배포되는 오픈소스는

i) 각 복제본에 적절한 저작권 표시와 보증책임이 없음을 명시하고,

ii) GPL 라이선스를 언급하는 고지사항과 보증책임 관련 고지사항을 원본 그대로 유지하고,

iii) 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 GPL 라이선스 사본을 제공하고,

iv) 파일을 수정한 경우 수정했다는 사실과 날짜를 파일에 명기해야 한다. 그리고

v) 원본저작물과 파생저작물(derivative work)을 GPL 2.0에 의해 배포해야 하며,

vi) 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공해야 한다.

여기서 i) ~ iv)의 의무사항은 Apache 라이선스와 동일하거나 유사한 내용이지만, v) 및 vi)의 의무사항은 BSD형의 라이선스에서는 찾아볼 수 없는 내용이다.

<참고> 파생저작물의 범위에 관한 해석

오픈소스 현장에서는 GPL 2.0에서 언급하고 있는 파생저작물(derivative work)의 범위가 어디까지인지에 관해 논란이 많다.

일반적으로 계약이나 법 조항이 명확하지 않은 경우 당사자의 의도나 거래 관행 등을 종합적으로 고려하여 법원에서 결정하게 된다.

GPL도 명확하지 않은 부분이 많으며, 최종적으로는 법원에서 가려지겠지만, GPL을 만든 FSF에서는 GPL의 해석에 도움을 주고자 많은 FAQ를 제공하고 있다.

예를 들면, GPL로 배포된 소프트웨어를 수정하였거나 새로운 소프트웨어에 정적 링크시키는 경우, 즉 두 개의 모듈이 동일한 실행 파일에 포함되어 있을 경우는 해당 실행 파일에 포함된 모든 소스는 GPL이 적용된다

또한, 동일한 바이너리에 포함되지 않더라도 동적 링크 등의 방식으로 공유주소영역에서 링크되어 실행되도록 설계된 경우, 플러그인이 동적으로 링크되어 함수를 호출하고 데이터구조를 공유하는 경우에도 GPL 소프트웨어와 함께 링크되어 실행되는 소프트웨어에도 GPL이 적용되어 소스코드를 제공해야 한다.

반면, 두 개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments형태로 통신하는 경우, 플러그인이 fork나 exec을 이용하는 경우 등은 별도의 저작물로서 GPL이 적용되지 않는다고 답변하고 있다.

GPL 3.0

GPL 3.0은 GPL 2.0이 배포되고 난 이후 오픈소스 환경을 둘러싼 다양한 변화들을 수용하여 만든 라이선스이다. GPL 3.0의 의무사항으로는

i) 각 복제본에 저작권 고지와 보증책임이 없음을 명시할 것,

ii) GPL 3.0의 조건 및 제7조의 조건에 관한 내용을 있는 그대로 유지할 것,

iii) 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 GPL 라이선스 사본을 제공할 것,

iv) 소프트웨어를 수정했을 경우 수정사실 및 일시를 명시할 것,

v) 원본저작물과 그에 기반한 저작물(Work based on the program)을 GPL 3.0에 의해 배포할 것,

vi) 원본저작물 및 그에 기반한 저작물(Work based on the program)에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공할 것,

vii) 사용자 제품(user product)에 대한 인증키 등 설치정보(installation information)를 제공할 것,

viii) 차별적인 특허라이선스 계약을 체결하지 말 것 등의 내용이 포함되어 있다.

i) ~ vi) 의 내용은 GPL 2.0의 내용과 같거나 내용을 더욱 명확히 하는 것이었지만, vii) 및 viii)의 내용은 GPL 3.0에 처음으로 포함된 내용으로 많은 논란을 불러일으켰다.

LGPL

LGPL은 주로 라이브러리에 사용하기 위해 FSF가 GPL과는 별도로 만든 라이선스이다.

라이브러리에 GPL 라이선스를 적용하게 되면 응용프로그램까지 GPL로 배포해야 하므로 사용자는 해당 라이브러리의 사용을 꺼리게 된다.

FSF는 GPL의 내용을 약간 수정하여 라이브러리 자체를 수정한 경우에는 카피레프트 조항을 적용하지만, 해당 라이브러리를 이용한 응용프로그램은 카피레프트 조항을 적용하지 않고 소스코드 제공 의무도 없는 형태로 LGPL 라이선스를 만들었다.

LGPL의 의무사항은

i) 각 복제본에 적절한 저작권 안내와 보증책임이 없음을 명시할 것,

ii) LGPL 라이선스를 언급하는 안내 사항과 보증책임 관련 고지사항을 원본 그대로 유지할 것,

iii) 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 LGPL 라이선스 사본을 제공할 것,

iv) 라이브러리 형태로의 수정을 허용하며, 만약 수정한 경우 수정사실과 날짜를 파일에 명기할 것,

iv) 원본저작물과 파생저작물을 LGPL 또는 GPL에 의해 배포할 것,

v) 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공할 것,

vi) 응용프로그램을 배포할 경우, LGPL 라이브러리를 사용하고 있다는 사실을 명시할 것,

vii) 사용자가 라이브러리를 수정해도 응용프로그램을 사용할 수 있도록 (예를 들어 응용프로그램의 오브젝트 코드를 제공하거나, 해당 라이브러리의 형태를 공유 라이브러리 방식 등을 이용하여) 허용할 것 등이다.

i) ~ v)의 내용은 GPL 2.0과 동일하거나 유사하지만, vi) ~ vii)은 LGPL에 특유한 내용이다.

Affero GPL

BSD, Apache, GPL, LGPL, MPL, EPL 등 대다수의 오픈소스 라이선스들은 해당 소프트웨어를 복제하여 ‘배포(distribute)’할 때 지켜야 하는 다양한 요구사항들을 규정하고 있다.

이를 반대로 해석하면 해당 소프트웨어를 배포하지 않고 기업이 해당 오픈소스를 내부적으로만 사용하거나 네트워크 서버 형태로 이용하고 있는 경우에는 라이선스에 따른 의무사항들이 거의 없다는 점이다.

오픈소스 라이선스의 이러한 한계에 대해 비판적인 견해를 가지고 있던 Affero 프로젝트는 기존의 GPL 라이선스를 변경하여 네트워크 서버에 의해 서비스를 제공하는 경우에도 카피레프트 조항과 소스코드 제공 의무가 적용되도록 하였다.

Affero GPL의 의무사항은 GPL과 기본적으로 동일하다. 다만, 그 적용의 범위가 단순한 ‘배포’를 넘어서 네트워크 서버 형태로 소프트웨어를 이용하는 경우에도 적용된다는 점에 차이가 있다.

GPL Exceptions

여러 오픈소스 프로젝트들은 해당 프로젝트는 GPL로 배포되길 바라면서 이를 활용하여 동작하는 프로그램들은 GPL의 copyleft 조항에서 자유로울 수 있도록, GPL 2.0의 2조를 다소 완화한 조건으로 배포할 수 있도록 허락해주는 exception을 추가하기도 한다.

이는 추가적인 제한 사항을 주는 것이 아니므로 GPL과도 호환된다.

Bison Exception

Bison은 GNU 파서 생성기로, 정의된 문법을 처리하고 해석하여 C 코드로 만들어주는 도구다.

Bison의 주요 결과물(Bison parser implementation file)은 상당 부분 Bison의 소스코드를 그대로 복사하여 skeleton 코드를 포함하게 된다.

일반적인 GPL이라면 이 skeleton 코드에도 GPL이 적용되어야 하고, 이에 따라 bison 결과물인 C 파일과 이를
사용하는 프로그램 모두 GPL이 적용되어, 사용자들이 bison 사용을 부담스러워할 수 있다.

이에 Bison에 예외 조항을 추가하여 Bison이 생성하는 소스코드에 대해서는 GPL 적용이 되지 않도록 예외를 추가하였다.

Classpath exception

GNU Classpath 프로젝트는 자바 언어의 가상머신 및 컴파일러에서 사용되는 핵심 클래스 라이브러리를 자유 소프트웨어로 대체하기 위한 프로젝트이다.

이를 널리 사용할 수 있도록, GNU Classpath 등 Classpath exception이 적용된 수정하지 않은 core class library를 link하여 생성한 program은 GPL의 영향을 받지 않는다.

예를 들면, OpenJDK 프로젝트에서 가상머신 자체는 GPL 2.0으로 배포하고, Class library와 가상머신 내의 Public API로 노출되는 부분은 Classpath exception으로 배포하고 있다.

Autoconf exception

GNU Autoconf는 M4 매크로의 확장 패키지로, 소스코드 패키지들의 환경을 설정하는 쉘 스크립트를 자동으로 생성한다. Autoconf는 GPL로 배포되며, configure.ac의 시스템 정보를 입력받아, Autoconf의 일부분과 결합, configure 스크립트를 생성한다.

이에 해당 configure 내에 autoconf의 일부가 포함될 수밖에 없음에도 해당 configure는
GPL의 파생저작물이 되지 않도록 예외를 적용해주는 것이 autoconf exception이다.

GCC Runtime Library Exception (GCC RLE)

GCC는 GNU 대표적인 컴파일러로, 이 Exception의 목적은 non-GPL 소스코드를 GCC로 컴파일할 때, GCC Runtime Library (header file 포함)가 Program에 포함되는 것을 허용하기 위한 것이다.

이 Exception에 의하면, “정당한 Compile 과정 (Eligible Compilation Process)” 중 Independent Module과 GCC Runtime Library가 결합하여 형성된 Target Code라면, 이는 GPL에 상관없이 다른 라이선스로 배포될 수 있다.

GCC Runtime Library는 libgcc, libstdc++, libfortran, libgomp, libdecnumber 등이 있다. 만약 GCC Runtime Library가 정당한 컴파일 과정에 의해서가 아닌, 다른 방법으로 Program에 포함된 경우에는 GPL 의무사항을 모두 준수해야 한다.

MPL형 라이선스

MPL 형 라이선스는 주로 기업들이 주도하는 오픈소스 프로젝트에서 사용하는 라이선스로 MPL, CDDL, EPL 등이 포함된다.

BSD형과 GPL형의 라이선스와는 달리, 처음부터 법률가들이 참여하여 만들었기 때문에 소프트웨어 라이선스의 관점에서는 더욱 정교하다고 볼 수 있지만, 프로그래머들에게는 그만큼 복잡하고 이해하기 어려운 라이선스들이다.

카피레프트 조항을 포함하고 있다는 점에서 GPL형과 비슷하지만, 적용 범위와 소스코드 제공범위는 GPL보다는 LGPL에 가까운 것으로 볼 수 있다.

MPL

MPL은 1998년 넷스케이프사가 자사의 브라우저를 오픈소스로 배포하면서 만든 라이선스이다. MPL로 배포되는 오픈소스를 이용하기 위해서는

i) 원 코드에 포함된 저작권표시, 개발자 및 권리자에 관한 사항들을 그대로 표시할 것과,

ii) 배포 시 MPL 라이선스 사본을 첨부할 것,

iii) 수정했을 경우에는 최초개발자의 코드로부터 파생되었다는 사실, 수정사항 및 날짜 등을 포함한 파일(Exhibit A)을 소스코드의 각 파일에 포함할 것,

iv) 원본 및 수정코드를 MPL에 의해 배포할 것과,

v) 수정코드에 대한 소스코드를 전자배포방식 등을 통해 제공할 것,

vi) MPL 코드를 사용할 때 제3자의 지식재산권에 의한 라이선스가 필요하다는 사실을 알고 있는 경우 “LEGAL” 파일에 관련 내용을 포함할 것 등이다.

MPL 2.0은 MPL 1.1에 비해 더욱 짧고 이해하기 쉽게 만든 라이선스이다. 특히 Apache License 2.0과 양립할 수 있게 되었으며 특허 관련 조항들이 정비되었다.

또한 MPL 2.0에서 Secondary License로 정의한 라이선스인 GPL 2.0, LGPL 2.1, AGPL 3.0과 각각 이후 버전들과 양립할 수 있게 된 것이 큰 변화이다.

CDDL

CDDL은 썬(sun)이 자사의 유닉스 운영체제인 솔라리스를 오픈소스로 배포하면서 만든 라이선스이다. MPL을 참조하여 만들었기 때문에 MPL의 내용과 비슷하다.

i) 저작권 등 권리관련 사항, 라이선스 관련 사항 등의 고지사항을 제거하거나 변경할 수 없으며,

ii) 배포 시 CDDL 라이선스 사본을 첨부해야 하며,

iii) 수정한 경우 수정코드의 기여자임을 밝혀야 한다.

iv) 원본 및 수정코드를 CDDL에 의해 배포해야 하며,

v) 수정코드에 대한 소스코드를 합리적인 방식으로 제공해야 한다.

CPL, EPL

CPL과 EPL은 IBM이 이클립스(Eclipse) 등 오픈소스 프로젝트를 진행하면서 만든 라이선스이다. CPL과 EPL은 특허보복조항에 관한 사항에서만 차이가 있고 다른 내용은 모두 동일하다. IBM은 현재 EPL만 사용하고 있다. EPL로 배포되는 소프트웨어를 배포할 때 지켜야 할 의무사항으로는

i) 각 코드의 저작권 고지사항을 제거하거나 변경하지 말 것과,

ii) EPL 라이선스 사본을 포함할 것과,

iii) 각 기여물의 창작자를 식별할 수 있도록 신분을 밝힐 것과,

iv) 오브젝트코드로 배포하는 경우 EPL 조건을 준수하고, 보증부인 및 책임배제에 관한 내용과 소스코드의 확보방법을 알려 줄 것,

v) 소스코드로 배포하는 경우 EPL 라이선스를 적용할 것과,

vi) 상업적 배포의 경우 기여자에게 책임이 발생하지 않도록 조치할 것 등의 내용을 포함하고 있다.

상담 사례

R을 이용한 상용 소프트웨어의 개발

Q: 저희가 개발하는 S/W의 기능 추가를 위해 GPL 2.0을 따르는 오픈소스를 사용하는 데
있어서 문제가 없는지 문의합니다.

1. R : 통계용 Open Source S/W (GPL 2.0)

2. qpcR : 저희가 추가하려는 기능의 핵심 모듈이 들어있는 패키지로 R이 기본적으로 설치되어 있어야 함.

3. R(D)-COM Interface : 저희가 개발하려는 S/W와 R 간의 Interface를 위한 S/W 위의 세 가지 모두 소스코드는 수정하지 않을 것이며, 아래와 같은 구조로 사용하려고 합니다.

위와 같이 사용하려고 할 때, 라이선스 관련 위배 사항이 없는 지 궁금하며, 위배 사항이 있을 경우 어느 정도까지 소스 공개가 되어야 하는 지 궁금합니다.

A: R(D)-COM은 별도의 라이선스 정책을 적용하고 있지는 않지만, 이미 GPL이 적용된 R과의 결합 정도에 따라 GPL 적용 여부가 결정될 것으로 판단됩니다.

GPL FAQ에 의하면 결합 정도에 따른 GPL 적용 범위의 구분 기준을 제시하고 있습니다.

예를 들어, 프로그램의 플러그인이 동적 링크로 실행되는 경우 메인 프로그램이 확장된 경우에 해당하여 GPL 적용 범위에 포함되지만, fork나 exec을 사용하는 경우에는 별도의 프로그램에 해당하여 포함되지 않습니다.

또는 두 개의 프로그램이 공유된 메모리를 사용하여 복합데이터 구조와 통신하는 경우 GPL 적용 범위에 포함되지만, 파이프(pipe), 소켓(socket), command-line argument 형태로 통신하는 경우에는 포함되지 않습니다.

당사가 개발한 소프트웨어와 R(D)-COM이 통신하는 경우에도, 소프트웨어 사용 환경 및 적용 범위를 고려하고 위의 구분 기준에 비추어 결합 정도를 판단하여야 할 것입니다.

만약 GPL의 적용 범위에 포함되는 것으로 판단되면 GPL 사본 첨부, 저작권 고지사항 유지, 프로그램 소스코드 제공 등의 GPL 요구사항을 준수하여야 합니다.

R 코어 팀에서 제공하는 FAQ에서도, R 패키지의 상업적 이용을 제한하지 않는다고 말하고 있지만, 관련 사항에 대해서는 담당 변호사에게 자문을 구하도록 하고 있으며, 직접적인 답변을 줄 수 없다고 명시하고 있습니다.

따라서, GNU·GPL이 사유 소프트웨어와 결합할 수 없다고 명시하고 있음에도 불구하고, R(D)-COM이 사유 소프트웨어인 마이크로소프트社의 엑셀 등과 GPL이 적용된 R을 연결하기 위해 사용되는 소프트웨어로 소개되어 있지만, 실질적으로 다른 소프트웨어와 함께 사용하는 경우에는 GPL이 적용된 R 패키지와의 동작 관계를 명확하게 확인하여야 할 것으로 판단됩니다.