오픈소스 소프트웨어 라이선스 종류
1. BSD형 라이선스
BSD형 라이선스에는 BSD, MIT, Apache 라이선스 등이 포함되며, 비교적 오랜 역사를 가진 라이선스들이다. 이들 라이선스는 카피레프트(Copyleft) 조항을 포함하지 않으며, 의무사항도 비교적 간단하다.
1) BSD(Berkeley Software Distribution) 라이선스
BSD 라이선스는 버클리 대학에서 만든 라이선스로, 소프트웨어를 재배포할 때 저작권 표시를 할 것과 준수 조건 및 보증부인에 대한 고지사항을 소스코드 또는 문서 및 기타자료에 포함할 것을 요구하고 있다.
4개의 조항으로 구성된 BSD 4-Clause 라이선스 (Original BSD 혹은 Old BSD 라고도 불림)에는 “광고 조항”이 포함되어 있다. 이는 파생저작물의 모든 홍보물에 “This product includes software developed by the
BSD 4-Clause 라이선스의 광고 조항은 별도의 제한 사항으로 볼 수 있어 GPL과 호환되지 않는다. 따라서 BSD 4-Clause 라이선스로 배포된 오픈소스가 GPL 프로그램을 사용하는 구조라면, 저작권자에게 BSD 3-Clause 라이선스로 변경하여 해결하라고 FSF는 안내하고 있다.
이와 같은 이유로 카 인포테인먼트 시스템의 대표적인 오픈소스 플랫폼인 GENIVI 플랫폼에서 사용하지 말도록 금지하고 있는 라이선스에 BSD 4-Clause 라이선스가 포함되어 있다.
BSD 3-Clause 라이선스에서 “제품에 대한 보증이나 홍보에 최초개발자나 기여자의 이름을 사용하지 못한다”는 조항을 삭제한 것이 BSD 2-Clause 라이선스다. 이는 BSD 라이선스 중 가장 간략하고 의무사항이 덜한 라이선스로 볼 수 있다.
2) Apache 라이선스
Apache 라이선스는 아파치소프트웨어재단(Apache Software Foundation)에서 만들어 배포한 라이선스이다. 1.0과 1.1 버전은 BSD와 비슷하게 간단한 내용만을 담고 있었지만, 현재 사용되고 있는 2.0 버전은 2004년에 배포된 것으로 비교적 상세한 내용을 담고 있다.
배포 시의 의무사항으로는 저작권, 특허, 상표, 권리귀속(attribution)에 대한 고지사항을 소스코드 또는 “NOTICE” 파일 등에 포함할 것과, 수취인에게 라이선스 사본을 제공하도록 요구하고 있으며, 파일을 수정하여 배포할 경우 수정된 파일에 대해 수정사항을 표시한 안내 문구를 첨부할 것을 요구하고 있다. 하지만 카피레프트 조항을 포함하고 있지 않기 때문에 반드시 동일한 라이선스로 배포할 필요는 없으며, 소스코드 제공 의무도 없다는 점에서 기본적으로 BSD 라이선스와 비슷한 것으로 평가할 수 있다.
| 라이선스의 특징 및 의무사항 | BSD | Apache 2.0 |
|---|---|---|
| 복제·배포·수정의 권한 부여 | O | O |
| 배포시 라이선스 사본 첨부 | O | |
| 저작권고지사항 또는 Attribution 고지사항 유지 | O | O |
| 배포시 소스코드 제공 의무(Reciprocity)와 범위 | ||
| 조합저작물(Larger Work)작성 및 타 라이선스 배포 허용 | ||
| 수정시 수정내용 고지 | O | |
| 명시적 특허라이선스의 부여 | O | |
| 라이선시가 특허소송 제기시 라이선스 종료 | O | |
| 이름, 상표, 상호에 대한 사용제한 | O | O |
| 보증의 부인 | O | O |
| 책임의 제한 | O | O |
2. 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 각각에 차이가 있다.
1) GPL 2.0
GPL 2.0으로 배포되는 오픈소스는
① 각 복제본에 적절한 저작권 표시와 보증책임이 없음을 명시하고,
② GPL 라이선스를 언급하는 고지사항과 보증책임 관련 고지사항을 원본 그대로 유지하고,
③ 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 GPL 라이선스 사본을 제공하고,
④ 파일을 수정한 경우 수정했다는 사실과 날짜를 파일에 명기해야 한다.
⑤ 원본저작물과 파생저작물(derivative work)을 GPL 2.0에 의해 배포해야 하며,
⑥ 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공해야 한다.
여기서 ① ~ ④의 의무사항은 Apache 라이선스와 동일하거나 유사한 내용이지만, ⑤ 및 ⑥의 의무사항은 BSD형의 라이선스에서는 찾아볼 수 없는 내용이다.
2) GPL 3.0
GPL 3.0은 GPL 2.0이 배포되고 난 이후 오픈소스 환경을 둘러싼 다양한 변화들을 수용하여 만든 라이선스이다.
GPL 3.0의 의무사항으로는
① 각 복제본에 저작권 고지와 보증책임이 없음을 명시할 것,
② GPL 3.0의 조건 및 제7조의 조건에 관한 내용을 있는 그대로 유지할 것,
③ 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 GPL 라이선스 사본을 제공할 것,
④ 소프트웨어를 수정했을 경우 수정사실 및 일시를 명시할 것,
⑤ 원본저작물과 그에 기반한 저작물(Work based on the program)을 GPL 3.0에 의해 배포할 것,
⑥ 원본저작물 및 그에 기반한 저작물(Work based on the program)에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공할 것,
⑦ 사용자 제품(user product)에 대한 인증키 등 설치정보(installation information)를 제공할 것,
⑧ 차별적인 특허라이선스 계약을 체결하지 말 것 등의 내용이 포함되어 있다.
① ~ ⑥의 내용은 GPL 2.0의 내용과 같거나 내용을 더욱 명확히 하는 것이었지만, ⑦ 및 ⑧의 내용은 GPL 3.0에 처음으로 포함된 내용으로 많은 논란을 불러일으켰다.
3) LGPL(Lesser General Public License)
LGPL은 주로 라이브러리에 사용하기 위해 FSF가 GPL과는 별도로 만든 라이선스이다. 라이브러리에 GPL 라이선스를 적용하게 되면 응용프로그램까지 GPL로 배포해야 하므로 사용자는 해당 라이브러리의 사용을 꺼리게 된다. FSF는 GPL의 내용을 약간 수정하여 라이브러리 자체를 수정한 경우에는 카피레프트 조항을 적용하지만, 해당 라이브러리를 이용한 응용프로그램은 카피레프트 조항을 적용하지 않고 소스코드 제공 의무도 없는 형태로 LGPL 라이선스를 만들었다.
LGPL의 의무사항은
① 각 복제본에 적절한 저작권 안내와 보증책임이 없음을 명시할 것,
② LGPL 라이선스를 언급하는 안내 사항과 보증책임 관련 고지사항을 원본 그대로 유지할 것,
③ 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 LGPL 라이선스 사본을 제공할 것,
④ 라이브러리 형태로의 수정을 허용하며, 만약 수정한 경우 수정사실과 날짜를 파일에 명기할 것,
⑤ 원본저작물과 파생저작물을 LGPL 또는 GPL에 의해 배포할 것,
⑥ 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공할 것,
⑦ 응용프로그램을 배포할 경우, LGPL 라이브러리를 사용하고 있다는 사실을 명시할 것,
⑧ 사용자가 라이브러리를 수정해도 응용프로그램을 사용할 수 있도록 (예를 들어 응용프로그램의 오브젝트 코드를 제공하거나, 해당 라이브러리의 형태를 공유 라이브러리 방식 등을 이용하여) 허용할 것 등이다.
① ~ ⑥의 내용은 GPL 2.0과 동일하거나 유사하지만, ⑦ ~ ⑧은 LGPL에 특유한 내용이다.
4) Affero GPL(Affero General Public License)
BSD, Apache, GPL, LGPL, MPL, EPL 등 대다수의 오픈소스 라이선스들은 해당 소프트웨어를 복제하여 ‘배포(distribute)’할 때 지켜야 하는 다양한 요구사항들을 규정하고 있다. 이를 반대로 해석하면 해당 소프트웨어를 배포하지 않고 기업이 해당 오픈소스를 내부적으로만 사용하거나 네트워크 서버 형태로 이용하고 있는 경우에는 라이선스에 따른 의무사항들이 거의 없다는 점이다.
오픈소스 라이선스의 이러한 한계에 대해 비판적인 견해를 가지고 있던 Affero 프로젝트는 기존의 GPL 라이선스를 변경하여 네트워크 서버에 의해 서비스를 제공하는 경우에도 카피레프트 조항과 소스코드 제공 의무가 적용되도록 하였다. Affero GPL의 의무사항은 GPL과 기본적으로 동일하다. 다만, 그 적용의 범위가 단순한 ‘배포’를 넘어서 네트워크 서버 형태로 소프트웨어를 이용하는 경우에도 적용된다는 점에 차이가 있다.
5) 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 적용이 되지 않도록 예외를 추가하였다. 소스코드 내 GPL 라이선스 설명 아래 다음과 같은 문구가 있으면 Bison exception이 적용되는 파일로 볼 수 있다.
② Classpath exception
GNU Classpath25) 프로젝트는 자바 언어의 가상머신 및 컴파일러에서 사용되는 핵심 클래스 라이브러리를 자유 소프트웨어로 대체하기 위한 프로젝트이다. 이를 널리 사용할 수 있도록, GNU Classpath 등 Classpath exception이 적용된 수정하지 않은 core class library를 link하여 생성한 program은 GPL의 영향을 받지 않는다. 예를 들면, OpenJDK 프로젝트에서 가상머신 자체는 GPL 2.0으로 배포하고, Class library와 가상머신 내의 Public API로 노출되는 부분은 Classpath exception으로 배포하고 있다.
③ Autoconf exception
GNU Autoconf26)는 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 의무사항을 모두 준수해야 한다
| 라이선스의 특징 및 의무사항 | GPL 2.0 | GPL 3.0 | LGPL | AGPL 3.0 |
|---|---|---|---|---|
| 복제·배포·수정의 권한 부여 | O | O | O | O |
| 배포시 라이선스 사본 첨부 | O | O | O | O |
| 저작권고지사항 또는 Attribution 고지사항 유지 | O | O | O | O |
| 배포시 소스코드 제공 의무(Reciprocity)와 범위 | derivative work | work based on the program | derivative work | derivative work |
| 조합저작물(Larger Work)작성 및 타 라이선스 배포 허용 | O | |||
| 수정시 수정내용 고지 | O | O | O | O |
| 명시적 특허라이선스의 부여 | O | O | ||
| 라이선시가 특허소송 제기시 라이선스 종료 | O | O | ||
| 이름, 상표, 상호에 대한 사용제한 | ||||
| 보증의 부인 | O | O | O | O |
| 책임의 제한 | O | O | O | O |
3. MPL형 라이선스
MPL형 라이선스는 주로 기업들이 주도하는 오픈소스 프로젝트에서 사용하는 라이선스로 MPL, CDDL, EPL 등이 포함된다. BSD형과 GPL형의 라이선스와는 달리, 처음부터 법률가들이 참여하여 만들었기 때문에 소프트웨어 라이선스의 관점에서는 더욱 정교하다고 볼 수 있지만, 프로그래머들에게는 그만큼 복잡하고 이해하기 어려운 라이선스들이다.
카피레프트 조항을 포함하고 있다는 점에서 GPL형과 비슷하지만, 적용 범위와 소스코드 제공범위는 GPL보다는 LGPL에 가까운 것으로 볼 수 있다.
1) MPL(Mozilla Public License)
MPL은 1998년 넷스케이프사가 자사의 브라우저를 오픈소스로 배포하면서 만든 라이선스이다.
MPL로 배포되는 오픈소스를 이용하기 위해서는
① 원 코드에 포함된 저작권 표시, 개발자 및 권리자에 관한 사항들을 그대로 표시할 것과,
② 배포 시 MPL 라이선스 사본을 첨부할 것,
③ 수정했을 경우에는 최초개발자의 코드로부터 파생되었다는 사실, 수정사항 및 날짜 등을 포함한 파일(Exhibit A)을 소스코드의 각 파일에 포함할 것,
④ 원본 및 수정코드를 MPL에 의해 배포할 것과,
⑤ 수정코드에 대한 소스코드를 전자배포방식 등을 통해 제공할 것,
⑥ 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과 각각 이후 버전들과 양립할 수 있게 된 것이 큰 변화이다.
2) CDDL
CDDL은 썬(sun)이 자사의 유닉스 운영체제인 솔라리스를 오픈소스로 배포하면서 만든 라이선스이다. MPL을 참조하여 만들었기 때문에 MPL의 내용과 비슷하다.
① 저작권 등 권리관련 사항, 라이선스 관련 사항 등의 고지사항을 제거하거나 변경할 수 없으며,
② 배포시 CDDL 라이선스 사본을 첨부해야 하며,
③ 수정한 경우 수정코드의 기여자임을 밝혀야 한다.
④ 원본 및 수정코드를 CDDL에 의해 배포해야 하며,
⑤ 수정코드에 대한 소스코드를 합리적인 방식으로 제공해야 한다.
3) CPL, EPL
CPL과 EPL은 IBM이 이클립스(Eclipse) 등 오픈소스 프로젝트를 진행하면서 만든 라이선스이다. CPL과 EPL은 특허보복조항에 관한 사항에서만 차이가 있고 다른 내용은 모두 동일하다. IBM은 현재 EPL만 사용하고 있다.
EPL로 배포되는 소프트웨어를 배포할 때 지켜야 할 의무사항으로는
① 각 코드의 저작권 고지사항을 제거하거나 변경하지 말 것과,
② EPL 라이선스 사본을 포함할 것과,
③ 각 기여물의 창작자를 식별할 수 있도록 신분을 밝힐 것과,
④ 오브젝트코드로 배포하는 경우 EPL 조건을 준수하고, 보증부인 및 책임배제에 관한 내용과 소스코드의 확보방법을 알려 줄 것,
⑤ 소스코드로 배포하는 경우 EPL 라이선스를 적용할 것과,
⑥ 상업적 배포의 경우 기여자에게 책임이 발생하지 않도록 조치할 것 등의 내용을 포함하고 있다.
| 라이선스의 특징 및 의무사항 | MPL | CDDL | CPL/EPL |
|---|---|---|---|
| 복제·배포·수정의 권한 부여 | O | O | O |
| 배포시 라이선스 사본 첨부 | O | O | O |
| 저작권고지사항 또는 Attribution 고지사항 유지 | O | O | O |
| 배포시 소스코드 제공 의무(Reciprocity)와 범위 | 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 |