24 Aug 2017

OpenSource Licens List

“펌, KLDP wiki”

3.2.1. GPL 2.0

GPL은 현재 가장 많은 OpenSource 소프트웨어가 채택하고 있는 라이센스이다. OpenSource 라이센스들 중에서 가장 많이 알려져 있고 의무사항들도 타 라이센스에 비해 엄격한 편이다. GPL의 주요 내용은 다음과 같다.

소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실 명시 소프트웨어를 수정하거나 새로운 소프트웨어를 링크(Static과 Dynamic linking 모두)시키는 경우 GPL에 의해 소스 코드 제공해야 함. Object Code 또는 Executable Form으로 GPL 소프트웨어를 배포하는 경우, 소스 코드 그 자체를 함께 배포하거나 또는 소스코드를 제공받을 수 있는 방법에 대한 정보 함께 제공해야 함 자신의 특허를 구현한 프로그램을 GPL로 배포할 때는 GPL 조건을 준수하는 이용자에게는 로열티를 받을 수 없으며, 제3자의 특허인 경우에도 특허권자가 Royalty-Free 형태의 라이센스를 제공해야만 해당 특허 기술을 구현한 프로그램을 GPL로 배포하는 것이 가능

GPL 소프트웨어를 사용하였을 경우 “본 제품(소프트웨어)는 GPL 라이센스 하에 배포되는 소프트웨어 XXX(사용한 GPL 소프트웨어 이름)를 포함합니다”와 같은 문구를 매뉴얼 혹은 그에 준하는 매체에 포함시키고, GPL 전문을 첨부해야 한다.

GPL에서 가장 논란이 되는 부분은 소스코드 공개 범위이다. 실제 소스코드 공개 범위는 다음 장의 쟁점 부분에서 확인하기로 한다. 소스코드를 공개하기 위해서는 소스코드를 CD Rom 등의 매체에 담아서 제품판매시 함께 배포하거나, 매뉴얼에 소스코드를 요청할 수 있는 연락처를 기입하여 두거나, 혹은 FTP 서버, 웹서버 등에 소스코드를 업로드해 두고 매뉴얼에 해당 주소를 기입하면 된다.

최근 특허에 관한 쟁점도 중요성이 증가하고 있는데, 자세한 내용은 다음 장의 쟁점 부분에서 설명한다.

3.2.2. LGPL 2.1

FSF가 일부 Library에 GPL보다 다소 완화된 형태인 GNU Lesser General Public License (LGPL)를 만들어 사용하고 있는 이유는 오픈 소스 소프트웨어의 사용을 장려하기 위한 전략적인 차원에서이다. 만일 상용 Library와 동일한 기능을 제공하는 Library에 GNU와 같은 엄격한 라이센스를 적용하게 되면, 개발자들이 Library의 사용을 꺼려할 것이다. 오히려 이미 널리 사용되고 있는 상용 Library와 동일한 기능을 제공하는 Library를 LGPL로 배포하여 그 사용을 장려하고 사실상의 표준으로 유도하는 한편, 관련된 다른 오픈 소스 소프트웨어를 보다 더 많이 사용할 수 있도록 하겠다는 것이 FSF의 전략이다. LGPL Version 2.1은 GNU ‘Library’ General Public License version 2.0의 후속 버전이다. 일부 한정된 Library에 대해서만 LGPL을 사용하려는 것이 FSF의 의도였으나 ‘Library’란 단어가 라이센스 이름에 포함되어 개발자들이 모든 Library를 위한 라이센스로 오인하는 경향이 있었다. 결국 이러한 오인을 방지하기 위하여 ‘Library’를 ‘Lesser’로 수정하였을 뿐 기본적인 내용은 동일하기 때문에 Version 2.1으로 표기한 것이다. LGPL의 주요 내용을 요약하면 다음과 같다.

소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 LGPL에 의해 배포된다는 사실 명시 LGPL Library의 일부를 수정하는 경우 수정한 Library를 LGPL에 의해 소스 코드 공개 LGPL Library에 응용프로그램을 링크시킬(Static과 Dynamic Linking 모두) 경우 해당 응용프로그램의 소스를 공개할 필요 없음. 다만 사용자가 Library 수정 후 동일한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그램의 Object Code를 제공해야 함 특허의 경우 GPL과 동일함

LGPL은 링크하는 소프트웨어의 소스코드를 공개할 필요가 없다는 점이 GPL과 가장 큰 차이점이다. 여하한 경우에도 LGPL 소프트웨어 자체는 공개해야 하지만 LGPL 소프트웨어와 링크되는 부분의 소프트웨어 소스코드는 공개해야 할 의무가 발생하지 않으므로 기업의 입장에서는 LGPL 소프트웨어를 좀더 선호하게 된다. 사용 여부 명시 등은 GPL과 동일하게 반영하면 되고 공개해야 할 소스코드의 공개 역시 GPL과 동일한 방식을 이용하면 된다.

3.2.3. BSD License

BSD(Berkeley Software Distribution) 라이센스는 GPL/LGPL보다 덜 제한적이기 때문에 허용범위가 넓다. 이는 BSD 라이센스로 배포되는 프로젝트가 미국 정부에서 제공한 재원으로 운영되었기 때문이다. GPL과의 차이점 중 가장 중요한 사항은 BSD 라이센스는는 소스코드 공개의 의무가 없다는 점이다. 따라서 BSD 라이센스의 소스 코드를 이용하여 새로운 프로그램을 개발하여도 새로운 프로그램의 소스 코드를 공개하지 않고 BSD가 아닌 다른 라이센스를 적용하여 판매할 수 있다. 주요 내용을 요약하면 다음과 같다.

소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 수정 프로그램에 대한 소스 코드의 공개를 요구하지 않기 때문에 상용 소프트웨어에 무제한 사용가능

3.2.4. Apache License

아파치 라이센스는 아파치 웹서버를 포함한 아파치 재단(ASF: Apache Software Foundation)의 모든 소프트웨어에 적용되며 BSD 라이센스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다. 다만 “Apache”라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 명시적으로 들어가 있고, 특허권에 관한 내용이 포함되어 BSD 라이센스보다는 좀더 법적으로 완결된 내용을 담고 있다. 특히 Apache License 2.0에서 특허에 관한 조항이 삽입되어 GPL 2.0으로 배포되는 코드와 결합되는 것이 어렵다는 문제가 었었는데, GPL 3.0(안)에서는 이 문제를 해결하여 아파치 라이센스로 배포되는 코드가 GPL 3.0으로 배포되는 코드와 결합하는 것이 가능해졌다.

3.2.5. MPL(Mozilla Public License)

MPL은 Netscape 브라우저의 소스코드를 공개하기 위해 개발된 라이센스이다. MPL은 공개하여야할 소스코드의 범위를 좀더 명확하게 정의하였다. GPL에서는 링크되는 소프트웨어의 소스코드를 포함하여 공개하여야 할 소스코드의 범위가 모호하게 정의되어 있지만 MPL에서는 링크 등의 여부에 상관없이 원래의 소스코드가 아닌 새로운 파일에 작성된 소스코드에 대해서는 공개의 의무가 발생하지 않는다. 따라서 MPL 소프트웨어 그 자체는 어떻게 하든 공개를 해야 하지만 원래 소스코드에 없던 새로운 파일들은 공개하여야 할 의무가 발생하지 않으므로 GPL에 비해 훨씬 명확하다. 주요 내용을 요약하면 다음과 같다.

소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 MPL에 의해 배포된다는 사실을 명시 MPL 코드를 수정한 부분은 다시 MPL에 의해 배포 MPL 코드와 다른 코드를 결합하여 프로그램을 만들 경우 MPL 코드를 제외한 결합 프로그램에 대한 소스코드는 공개할 필요가 없음 소스코드를 적절한 형태로 제공하는 경우, 실행파일에 대한 라이센스는 MPL이 아닌 다른 것으로 선택가능 특허기술이 구현된 프로그램의 경우 관련 사실을 ‘LEGAL’파일에 기록하여 배포

Github