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 일반 공중 라이선스의 엄격함을 피하려는 사용자들에게 인기가 있다.
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)8)의 범위가 어디까지인지에 관해 논란이 많다. 일반적으로 계약이나 법 조항이 명확하지 않은 경우 당사자의 의도나 거래 관행 등을 종합적으로 고려하여 법원에서 결정하게 된다. GPL도 명확하지 않은 부분이 많으며, 최종적으로는 법원에서 가려지겠지만, GPL을 만든 FSF에서는 GPL의 해석에 도움을 주고자 많은 FAQ를 제공하고 있다.
GPL로 배포된 소프트웨어를 수정하였거나 새로운 소프트웨어에 정적 링크시키는 경우, 즉 두 개의 모듈이 동일한 실행 파일에 포함되어 있을 경우는 해당 실행파일에 포함된 모든 소스는 GPL이 적용된다.
또한, 동일한 바이너리에 포함되지 않더라도 동적 링크 등의 방식으로 공유주소영역에서 링크되어 실행되도록 설계된 경우, 플러그인이 동적으로 링크되어 함수를 호출하고 데이터구조를 공유하는 경우에도 GPL 소프트웨어와 함께 링크되어 실행되는 소프트웨어에도 GPL이 적용되어 소스코드를 제공해야 한다.
반면, 두 개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments 형태로 통신하는 경우, 플러그인이 fork나 exec을 이용하는 경우 등은 별도의 저작물로서 GPL이 적용되지 않는다고 답변하고 있다.
그런데, FSF의 이와 같은 해석이 저작권법상의 파생저작물 또는 2차적 저작물의 범위를 벗어난다는 주장도 일부 있다. GPL 3.0에서는 이와 같은 비판을 고려하여 “derivative works”라는 용어를 삭제하고 “Work based on the program”으로 통일하고 있다.
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)의 내용은 GPL2.0과 동일하거나 유사하지만, vi) ~ vii)은 LGPL에 해당하는 내용이다.
LGPL은 라이브러리를 정적 링크할 때와 동적 링크할 때 다소 다른 의무사항을요구한다.
- 라이브러리를 정적 링크 시 요구사항
LGPL 라이브러리를 정적 링크하는 애플리케이션을 배포하는 경우에는 (즉, LGPL 라이브러리가 정적 라이브러리 (예: *.a 파일)) LGPL 라이브러리의 소스코드를 공개해야 할 뿐만 아니라, 애플리케이션의 오브젝트 코드도 공개해야 합니다. 이는 사용자에게 LGPL 라이브러리를 수정하고, 수정된 라이브러리를 포함한 애플리케이션을 생성하기 위해 Relink 할 수 있는 방법을 제공하기 위한 LGPL의 요구사항을 충족시키기 위해서다.
- 라이브러리를 동적 링크 시 요구사항
LGPL 라이브러리를 동적 링크하는 애플리케이션을 배포하는 경우에는 (즉, LGPL라이브러리가 동적 라이브러리 (예: *.so 파일)) LGPL 라이브러리의 소스코드를 공개해야한다. 이외, 애플리케이션의 소스코드나 오브젝트 코드는 공개할 필요 없다. 이는 사용자가 수정한 LGPL 라이브러리는 애플리케이션과 Relink 하지 않고도 애플리케이션 동작 시 반영되기 때문이다.
단, LGPL 라이브러리가 애플리케이션에 포함되어 함께 배포되는 것이 아니라, 사용자의 컴퓨터에 이미 존재하고 있는 LGPL 라이브러리를 배포한 애플리케이션이 동적 링크하여 사용하는 구조라면, LGPL 라이브러리의 소스코드조차도 공개할 필요가 없다.