Editing OSS 라이센스 가이드 및 해설서 (section)

From ITnLAW

You are not logged in. Your IP address will be recorded in this page's edit history.

WARNING: This page is 34 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

===오픈소스 라이센스의 구체적 내용===

====공통적 준수사항====
오픈소스 라이센스의 의무사항은 각각의 라이센스마다 조금씩 차이가 있지만 크게 나누어 보면 공통적으로 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이센스의 소프트웨어 조합시 조합 가능 여부 확인' 등이 있고 선택적으로는 '소스코드 공개', '특허관련 사항 준수' 등이 있다.

아래는 모든 오픈소스소프트웨어에 공통적으로 적용되는, 항상 지켜야 할 사항들이다.

* '''저작권 관련 문구 유지''' : 앞에서 저작권이란 표현된 결과물에 대해 발생하는 권리이며 자동적으로 부여된다고 기술하였다. 소프트웨어의 소스코드에 대해서도 마찬가지이며 잘 관리되는 오픈소스 소프트웨어들의 경우 거의 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있는데 만약 이러한 개발자 정보를 임의로 수정하거나 삭제하여서는 안된다. 특히 GPL등 수정된 결과물을 다시 공개하도록 규정하고 있는 '상호주의(reciprocal)' 라이센스들의 경우 만약 소스코드 상에 개발자 정보가 수정/삭제된 채로 외부에 소스코드를 공개하였다가 그 사실이 밝혀질 경우 더 큰 문제가 발생할 수 있다. 상식적으로도 쉽게 판단 가능한 사항이므로 항상 준수하여야 한다.

* '''제품명 중복 방지''' : 사용하는 오픈소스 소프트웨어와 동일한 이름을 제품명이나 서비스 명으로 사용하여서는 아니된다. 특히 유명한 오픈소스 소프트웨어들일수록 해당 오픈소스 소프트웨어의 이름이 상표로서 등록되어 있는 경우가 많기 때문에(예: 리눅스) 더욱 조심하여야 한다. 다만 이러한 제품명/서비스명에 대한 결정이 개발자들에 의해 이루어지는 경우는 많지 않으므로 역시 상식적인 수준에서 판단하면 될 것이다.

* '''서로 다른 라이센스의 조합''' : 소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이센스가 상호 상충되는 경우가 있다. 예컨대 MPL 조건의 A코드와 GPL 조건의 B코드를 결합하여 ‘A+B’라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 ‘A+B’의 A부분을 MPL로 배포할 것을 요구하는 반면, GPL은 ‘A+B’ 전체를 GPL로 배포할 것을 요구하기 때문에, ‘A+B’프로그램을 배포하는 것은 불가능하게 된다. 이러한 문제를 가르켜 라이센스의 양립성(Compatibility) 문제라고 한다. 따라서 어떤 오픈소스 소프트웨어에 다른 오픈소스 소프트웨어를 섞을 경우 반드시 두개의 라이센스가 서로 호환되는지를 확인하여야 한다. 양립성문제는 자유/오픈소스소프트웨어 진영에 심각한 문제점을 제기하였으며, 이를 해결하기 위한 노력도 다양하게 진행되고 있다. 예를 들어 모질라 프로젝트(Mozilla.org)에서는 프로젝트의 결과물을 MPL, GPL, LGPL의 3가지(triple) 라이센스로 배포하는 라이센스 정책을 채택하여, 라이센스의 양립성과 관련된 불확실성을 제거하고 모질라 코드를 GPL 또는 LGPL 기반의 응용프로그램에 사용할 수 있도록 하였다. Trolltech도 Qt 라이브러리에 대한 오픈소스소프트웨어라이센스인 QPL과 GPL의 양립성 문제를 해결하기 위하여 QPL 및 상용라이센스 이외에 GPL을 추가하는 정책을 취하고 있다. 한편 최근 개정된 GPL 3.0은 Apache License 2.0과 양립가능하다.

아래는 라이센스에 따라 다르다. 어떤 라이센스의 경우는 아래 세가지 사항 모두에 관계되는 경우도 있고, 어떤 라이센스는 아래 중 일부만을 요구하는 경우도 있다. 자세한 사항은 라이센스별 해설 부분을 참고하기 바란다.

* '''사용 여부 명시''' : 많은 오픈소스 라이센스들은 소스코드를 자유롭게 열람하고 수정 및 재배포할 수 있는 권리를 부여하는 한편, 소프트웨어를 사용할 때 해당 오픈소스소프트웨어가 사용되었음을 명시적으로 표기하는 것을 의무사항으로 채택하고 있다. 이것은 마치 논문을 쓸 때 인용을 하는 것과 비슷하여, '이 소프트웨어는 오픈소스 소프트웨어인 무엇무엇을 사용하였습니다.'라는 식으로 사용 여부를 명확히 기술하라는 것이다. 사용자 매뉴얼이나 기타 매뉴얼을 대체하는 매체가 있다면 그곳에 기술하면 된다.

* '''소스코드 공개''' : 오픈소스 라이센스에 따라서는 수정하거나 추가한 부분이 있을 때 해당 부분의 소스코드도 공개하여야 한다고 명시하는 경우가 있다. 이에 해당하는 라이센스는 GPL이 가장 유명하다. 그러나 정확한 공개 범위는 각각의 라이센스에서 정하고 있는 범위가 다르고, 소프트웨어를 개발하는 방법에 따라서도 달라질 수 있다. 자세한 내용은 다음 절의 쟁점부분을 참고하기 바란다.

* '''특허''' : 특허에 대한 기본적인 내용은, 만약 어떤 기술이 특허로 보호될 경우 해당 기술을 구현할 때 반드시 특허권자의 허락을 받아야 한다는 것이다. 이는 오픈소스이냐 아니냐에 상관 없이 공통적으로 해당된다. 그러나 어떤 특허를 오픈소스로 구현할 경우 해당 특허의 구현 결과는 오픈소스 라이센스를 따르게 되는 등, 오픈소스소프트웨어와 관련된 특허권의 문제는 보다 복잡하게 전개되고 있다. 특히 최근 소프트웨어특허가 급격히 증가하면서 문제가 심각해지고 있기 때문에, 새롭게 만들어지는 오픈소스 라이센스들에서는 특허관련조항을 포함하고 있는 경우가 많아지고 있다. 이와 관련된 자세한 내용도 다음 절의 쟁점부분을 참고하기 바란다.

====라이센스별 준수사항====

이제 주요 라이센스 위주로 각각 준수해야 하는 사항들에 대해 살펴보기로 하자.

'''GPL 2.0'''

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

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

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

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

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

'''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과 동일한 방식을 이용하면 된다.

'''BSD License'''

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

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

'''Apache License'''

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

'''MPL(Mozilla Public License)'''

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

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

====주요 쟁점====

'''소스코드 공개 여부'''

앞에서 GPL/LGPL/BSD/MPL/Apache License 등 많이 사용되는 라이센스들을 간략히 살펴보았는데 이중에서 GPL/LGPL/MPL 등은 수정한 내용에 대한 소스코드를 공개하여야 하고 BSD/Apache License 등은 수정하더라도 소스코드를 공개할 의무가 발생하지 않는다. GPL/LGPL/MPL 등 소스코드 공개 의무가 발생하는 라이센스는 상호주의(reciprocal) 혹은 copyleft 라이센스라고 하며, 그 결과물이 원 소프트웨어의 파생물(derivative work)일 경우 소스코드를 공개해야 한다. 그런데 소스코드의 공개범위를 기계적으로 판단할 수 있는 방법은 없으며 라이센스마다 서로 다르게 정의하고 있으므로 잘 판단하여야 한다. GPL을 중심으로 보다 자세히 살펴보도록 하자.

GPL의 경우, GPL 프로그램의 소스코드를 이용자가 개발한 프로그램코드에 삽입하거나 링크시킨 후 함께 배포하고자 하는 경우, 이용자가 개발한 프로그램도 GPL 조건으로 배포해야 한다. 반면 GPL 제2조 후단에서는 ‘원 프로그램으로부터 파생되지 않고 그 자체로 독립적이고 분리되어 있는 저작물(separate works)은 다른 라이센스 조건에 의해 배포가능하며, 단순집합물(mere aggregation)로서 원 프로그램과 동일한 매체로 배포할 수 있다’고 규정하고 있다. 예를 들어 독립적으로 제작된 프로그램을 GPL 프로그램과 단순히 동일한 매체에 저장하여 배포할 경우에는 GPL이 아닌 다른 라이센스조건에 의해 배포할 수 있다. 하지만 구체적으로 어떠한 경우가 파생물에 해당하는지, 또는 독립된 프로그램의 단순한 집합물에 해당하는지를 구별하는 것은 쉽지 않다. 결국 최종적으로는 법원의 판단에 의해 결정될 문제인데, FSF는 GPL FAQ에서 몇 가지의 구별기준을 제시하고 있다. 예를 들어 두개의 모듈이 동일한 실행파일에 포함되어 있거나 공유주소영역(shared address space)에서 링크되어 실행되도록 설계된 경우에는 전자에 포함되고, 2개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments 형태로 통신하는 경우에는 후자에 해당한다. 플러그인(plug-ins)의 경우 동적으로 링크되어 함수호출을 하고 데이터구조를 공유하는 경우에는 전자에, fork와 exec를 이용하면 후자에,  해당한다. 인터프리터(interpreter)나 컴파일러(compiler)의 경우에는 원칙적으로 컴파일된 결과물과는 분리된 것으로 보지만, 컴파일과정에서 라이브러리나 클래스가 결과물에 추가된 경우에는 라이브러리 또는 클래스와 결과물은 하나의 프로그램으로 볼 수 있다.

이와 같은 GPL의 특징은 다른 오픈소스소프트웨어 라이센스와 비교할 때 명확히 드러난다. 예를 들어 LGPL은 일정한 요건을 충족시키는 경우 LGPL 라이브러리(Library)를 이용하는 프로그램(Work that uses the Library), 다시 말해 컴파일 또는 링크를 통해 LGPL 라이브러리와 함께 작동하도록 설계된 프로그램들을 배포할 경우에는 소스코드를 제공하지 않아도 된다.(LGPL 제5조). MPL도 한편으로는 GPL과 마찬가지로 수정된 코드의 소스코드를 제공할 것을 요구하면서, 다른 한편으로는 MPL 조건의 코드와 기타의 라이센스 조건의 코드를 결합한 프로그램(MPL에서는 이를 ‘Larger work’라고 표현하고 있다)을 만드는 것을 허용하고, 결합된 프로그램을 MPL이 아닌 다른 라이센스로 배포하는 것을 허용하고 있다(MPL 제3.7조). 예를 들면 별도의 파일로 함수(Function)를 추가할 경우 MPL은 기존 코드의 수정부분에만 적용할 뿐 추가된 함수에는 적용되지 않는다.

한편 원칙적으로 GPL 조건으로 배포하면서도 GPL 제2조와 관련해서는 다소 완화된 내용의 조건으로 프로그램을 배포하는 경우가 있다. 대표적 사례는 리눅스커널의 경우인데, 리눅스커널의 ‘COPYING' 파일에 포함되어 있는 라이센스 조건에는 ’정상적인 시스템 콜에 의해 커널 서비스를 이용하는 사용자프로그램(user programs)은 GPL에 의해 배포하지 않아도 좋다는 내용이 포함되어 있다. 이와 같은 내용에 따라 리눅스커널을 기반으로 한 라이브러리나 응용프로그램은 소스코드를 제공하지 않고도 배포할 수 있으며, 시장에서는 이를 확대해석하여 표준커널인터페이스를 이용하는 디바이스 드라이버나 동적 커널모듈(Loadable Kernel Module)도 사용자프로그램이 시스템 콜을 이용하는 것과 크게 다르지 않기 때문에 소스코드를 제공할 필요가 없는 것으로 보고 있다.

두 번째 사례는 GNU Classpath 프로젝트와 자바(Java) 플랫폼사례이다. GNU Classpath 프로젝트는 자바(java)언어의 가상머신(virtual machines) 및 컴파일러에서 사용되는 핵심 클래스라이브러리(core class libraries)를 자유소프트웨어로 대체하기 위한 프로젝트인데, 동 프로젝트의 결과물을 GPL로 배포하면서도 이와 링크된 다른 독립된 소프트웨어는 GPL로 배포할 필요가 없다는 내용의 예외를 인정하였다. 그런데 2006년 말 Sun이 향후 자바 플랫폼을 GPL 조건으로 배포하겠다는 선언을 하면서, 자바 플랫폼 중 특히 Java SE(Java Platform Standard Edition)와 Java EE(Java Platform Enterprise Edition)의 GPL 배포조건에 Classpath 예외를 추가한다고 발표하였다. 그 결과 Classpath 예외조항을 포함한 GPL 조건의 자바 플랫폼을 이용한 응용프로그램도 소스코드를 공개하지 않고 배포할 수 있다.

'''특허권'''

GPL, LGPL, MPL, Apache 라이센스 등의 오픈소스 라이센스는 특허와 관련된 조항들을 가지고 있는데, 각각의 경우를 ⅰ) 라이센서(Licensor)의 특허인 경우, ⅱ) 제3자의 특허인 경우, ⅲ) 라이센시(Licensee)의 특허인 경우로 구분하여 설명할 수 있다. 다만 LGPL은 특허와 관련해서는 GPL과 동일하게 규정하고 있으며, BSD는 특허에 관한 규정을 두고 있지 않기 때문에 이하에서는 생략한다.

* '''라이센서(Licensor)의 특허인 경우''' : 소프트웨어에 대해 저작권을 가지고 있는 주체가 특허권을 함께 가지고 있는 경우이다. MPL과 Apache 라이센스는 이와 같은 경우 라이센서가 소프트웨어를 오픈소스 라이센스조건으로 배포하는 경우 관련 특허권의 라이센스도 무상으로 제공하는 것으로 규정하고 있다. GPL의 경우에는 명문으로 규정하고 있지 않지만 대체적으로 관련 조문(제7조 등)의 해석상 묵시적인 라이센스를 제공하는 것으로 보고 있다. GPL 3.0에서는 단순 재배포자를 제외한 개발자 및 기여자(Contributor)의 경우 자신이 기여한 부분과 관련된 특허권 라이센스를 무상으로 제공하는 것으로 규정하고 있다. 한가지 주의하여야 할 것은 특허권 그 자체는 여전히 유효하다는 것이다. 따라서 예를 들어 특허권자 특허받은 정렬 알고리즘을 GPL로 배포되는 리눅스에 로열티 없이 사용 가능하도록 제공한다고 할지라도 독점 라이센스인 MS 윈도우즈에는 해당 정렬 알고리즘을 사용토록 허가하면서 여전히 로열티를 받을 수 있다.

* '''라이센시(Licensee)의 특허인 경우''' : 프로그램을 사용하는 이용자가 특허권을 가지고 있는 경우이다. MPL의 경우 이용자가 자신의 특허권을 문제 삼지 않고 그냥 사용하는 경우에는 아무런 문제가 없지만, 만약 이용자가 MPL 프로그램을 사용하던 중 자신의 특허권을 근거로 소송을 제기하게 되면, 적절한 시일 내에 소송을 철회하지 않는 한 라이센스가 종료되고, 그 결과 MPL 프로그램을 더 이상 사용할 수 없거나, 그 동안 사용했던 부분에 대하여 로열티 산정을 하는 등 일정한 보복이 가해진다. Apache 라이센스 2.0도 MPL과 비슷한 취지의 조항을 추가하였으며, GPL 3.0에서도 관련 내용이 추가되었다.

* '''제3자의 특허인 경우''' : 특허 소유자와 이를 프로그램으로 구현한 주체가 다른 경우인데, GPL 제7조에 의하면 특허 소유자가 무상(Royalty-Free) 조건의 특허 라이센스를 허용하지 않는다면 구현자는 이 프로그램을 GPL 조건으로 배포할 수 없다. 예를 들면 甲회사가 乙회사의 특허기술을 바탕으로 A라는 프로그램을 만들었을 경우, 乙회사가 그 특허를 모든 사람에게 무상으로 허용하지 않는다면, 설사 甲회사가 라이센스를 무료로 받았다고 할지라도 A프로그램을 GPL 조건으로 배포할 수 없다. 나아가 GPL 3.0에서는 제3자인 특허권자가 이용자들을 차별하여 라이센스를 부여하는 것을 막기위한 조항이 삽입되었다. 그 결과 2006년 말 MS와 노벨사이에 체결되었던 형태의 계약은 향후 어려울 것으로 보인다. MPL은 제3자의 특허인 경우에도 일단 배포는 허용하되, ‘LEGAL’이라는 이름의 파일을 추가하여 어떠한 특허가 문제되고 있는지, 어떤 사람이 클레임을 제기하고 있는지에 대한 사항을 자세히 기록하도록 하고 있다.

''' 듀얼 라이센스'''

또한 일부 오픈소스소프트웨어는 복수의 라이센스하에 배포되는 경우가 있다. 이를 주로 듀얼 라이센스(dual license)라고 하며, 이런 경우는 주로 오픈 소스 소프트웨어를 상업적 목적으로 이용할 뿐만 아니라 오픈소스 커뮤니티와의 협력을 위한 경우가 대부분이다. 하나 이상의 라이센스가 있는 오픈소스소프트웨어를 이용할 경우, 이용자는 사용 목적에 가장 잘 부합하는 라이센스 하에 배포되는 소스 코드를 선택할 수 있다. 대표적인 사례로는 MySQL, Trolltech의 Qt 라이브러리 등이 있다.

====주요 오픈소스소프트웨어 사례====
앞서 살펴본 오픈소스 라이센스에 대한 이해를 바탕으로 실제 많이 사용하고 있는 오픈소스소프트웨어들 중 특별히 기억해 두어야 할 라이센스 관련 이슈에 대해 살펴보자.

'''Linux 커널'''

Linux 커널은 GPL v2로 배포된다. 그런데 리눅스커널의 'COPYING'파일에는 GPL v2 전문과 함께 다음과 같은 내용이 맨 위에 추가로 기재되어 있다.

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
 
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.

정상적인 시스템 콜에 의해 커널 서비스를 이용하는 사용자프로그램(user programs)은 GPL에 의해 배포하지 않아도 좋다는 뜻이다. 이와 같은 내용에 따라 리눅스커널을 기반으로 한 라이브러리나 응용프로그램은 GPL v2의 영향을 받지 않는 것이다. 그러나 Linux 커널은 커널의 기능을 커널 모듈이라는 형태로도 이용할 수 있는 인터페이스를 제공하는데 이 커널 모듈도 위의 예외사항에 속하는지에 대한 논란이 계속되고 있다. 즉, 리눅스 커널모듈도 모두 GPL v2로서 소스코드를 공개해야 하는지, 아니면 독점 라이센스를 적용하여 소스코드를 공개하지 않아도 되는지에 대한 논란이다. 이에 대해서는 리눅스 커널 개발자들 사이에서도 의견이 갈리고 있다.

최소한, http://www.kernel.org 에서 배포되는 공식 커널 버전을 기준으로 모듈 인터페이스를 임의로 수정하지 않은 상태에서 동작이 가능한, 자체 개발된 커널 모듈은 GPL이 아닐 수 있다고 주장할 수 있다. 그러나 모듈 인터페이스를 임의로 수정할 경우에는 설득력이 훨씬 약해지며, 커널 모듈이 GPL이냐 아니냐에 대한 논란은 매우 첨예하게 대립하고 있으므로 커널 모듈은 모두 GPL이라고 가정하고 공개가 불가능한 부분은 사용자프로그램(user program)에서 구현하는 것이 바람직하다.

'''FreeBSD'''

FreeBSD는 1993년에 처음 발표되었다. FreeBSD는 Unix 시스템인 BSD(Berkeley Software Distribution)를 기반으로 개발되었고, 다양한 Unix 버전 중 오픈 소스 Unix라 할 수 있을 것이다. FreeBSD는 가장 제약 사항이 적은 BSD License에 의해 배포되고 있다. 따라서 FreeBSD 소스 코드를 상업적으로 아무런 제한없이 이용할 수 있다. 단, 소스 코드 혹은 바이너리 형식으로 재배포할 때는 FreeBSD의 원저작권자인 The Regents of the University of California의 저작권을 명시해야 한다. 현재 FreeBSD의 소스 코드에는 다음과 같이 저작권이 명시되어 있다. "All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by The Regents of the University of California" 또한, Free BSD를 이용하고 있음을 밝히기 위해서는 다음의 사항을 명시해야 한다. "This product includes software developed by the University of California, Berkeley and its contributors." 마지막으로 재배포 시에는 FreeBSD 소스 코드에 포함된 라이센스 내용을 그대로 포함시켜야 한다. 요약하면, FreeBSD는 소스 코드 공개를 요구하지 않으며, 만약 원본 혹은 수정된 소스 코드를 공개하고자 하면 위에서 언급한 사항들만 준수하면 된다.

'''MySQL'''

MySQL은 현재 가장 인기 있는 관계형 데이터베이스 서버로서 사용자는 GPL 라이센스나 일반 상용 라이센스 둘 중 한가지를 선택할 수 있는데, 상용 라이센스는 GPL 라이센스의 여러가지 요구사항들(소스코드 공개 등)을 지키기 어려운 경우에 선택할 수 있으므로 일반적인 상용 라이센스 판매를 통해 수익을 내고 있다. 이러한 라이센싱 모델을 듀얼 라이센스라고 하며 MySQL은 듀얼 라이센싱 모델의 대표적인 사례로서 종종 언급된다. MySQL의 이같은 듀얼 라이센싱 모델에 대해서 좀더 살펴보면 다음과 같다.

우선 오픈소스 프로젝트 목적으로 MySQL을 이용할 경우를 살펴보자. 만약, 이용자가 MySQL 라이브러리를 이용하여 개발한 애플리케이션을 GPL 라이센스 하에 배포한다면, 이 경우 MySQL은 GPL 라이센스가 적용된다. 즉, 이용자가 기꺼이 직접 개발한 애플리케이션을 GPL하에 배포하기 때문에 MySQL 라이브러리 역시 GPL이 되더라도 문제가 발생하지 않을 것이다. 또한, 이용자가 GPL이 아닌 Open Source Initiative에서 인정한 라이센스 하에 직접 개발한 애플리케이션을 배포할 경우에도 특별 예외 조항을 두어 라이센스 충돌이 발생하지 않도록 하였다. 즉, 비록 GPL 라이브러리를 이용하더라도, 직접 개발하였거나 GPL 라이브러리와 독립된 부분으로 인정이 되는 애플리케이션의 소스 코드는 GPL이 아닌 다른 오픈소스라이센스로 배포할 수 있도록 하였다. GPL의 원칙을 따를 경우, GPL 라이브러리에 기반한 애플리케이션 전체 소스 코드가 GPL이 되기 때문에 소스 코드 공개 의무가 발생한다. 한편 GPL 등 오픈소스 라이센스조건을 따르지 않는 형태로 사용하고자 하는 경우에는 MySQL AB사로부터 Commercial License를 받아야 한다.

그러나 한가지 주지하여야 할 것은 GPL의 의무사항은 소프트웨어를 배포할 때 발생하는 것이므로 만약 MySQL을 다운로드해서 MySQL과 연동되는 웹사이트 등을 만들어서 서비스만 하는 경우는 MySQL을 직접 배포하지 않는 것이므로 GPL의 의무사항이 발생하지 않는다는 것이다. 예를 들어 인터넷 포털 업체들은 MySQL의 상용 버전을 구입하지 않고 GPL 버전을 사용하면서 MySQL이나 관련 소프트웨어의 소스코드를 공개하지 않고 있다.

'''Apache'''

Apache 소프트웨어들은 현재 ASF에서 자체적으로 개발한 Apache License Version 2.0하에 배포되고 있다. Apache License에 따르면, 누구든 자유롭게 Apache 소프트웨어를 다운받아 부분 혹은 전체를 개인적 혹은 상업적 목적으로 이용할 수 있다. 또한, 재배포 시에도 원본 소스 코드 혹은 수정한 소스 코드를 반드시 포함시킬 것을 요구하지 않는다. 다만, 재배포하고자 할 경우에는 Apache License, Version 2.0을 포함시키고 ASF에 개발된 소프트웨어임을 명확히 밝힐 것을 요구한다. 아울러 ASF가 승인하지 않는 ASF 공식 마크를 임의로 사용할 수 없다.

'''Mozilla Firefox'''

Firefox는 오픈 소스 소프트웨어이며 현재 MPL, GPL, LGPL 세 가지 라이센스 하에 배포되고 있다. 이 세가지 라이센스는 모두 공통적으로 누구나 소스 코드를 보고 수정하며 재배포하는 것을 허용한다. 원래 Firefox는 MPL에 의해 배포되었다. 그런데 파생물의 상업적 이용을 제한적으로 허락하는 MPL은 GPL 혹은 LGPL과 호환될 수 없기 때문에 FSF로 부터 많은 비난을 받았다. 이 문제를 해결하기 위해 Mozilla는 Firefox를 MPL, GPL, 그리고 LGPL하에 다시 라이센싱하였다. 이 후, 개발자들은 이 세 가지 라이센스 중 자신들의 목적에 가장 잘 부합하는 라이센스를 선택할 수 있게 되었다. 그런데 하나 유의할 점은, Firefox의 일부 상용 컴포넌트를 포함하고 있기 때문에, 이 상용 컴포넌트는 위에서 언급한 세 가지 라이센스의 적용을 받지 않는다. 대신, 이들은 Mozilla End User License Agreement(EULA)의 제한을 받고 있다.

'''Sendmail'''

Sendmail은 1981년 Eric Allman에 의해 Mail Transfer Agent(MTA)로 개발되었다. 당시에 그는 UC Berkely에서 일하며 대학의 네트워크와 Arpanet 사이에 이메일을 주고받기 위한 목적으로 sendmail을 개발하였다. 처음부터 Sendmail은 메일 프로토콜의 개방성과 라우팅 기능성, 파일의 유연성에 초점을 맞추었기 때문에 오늘날 이메일 서버 시장의 1위 자리를 차지할 수 있었을 것이다. Allman은 여전히 Sendmail 개발의 중심에 있으며, Sendmail의 유지보수와 기능 및 성능 개선 등의 난관을 헤쳐가기 위해 Sendmail, Inc.이라는 회사를 설립하였다. Sendmail 8.9 이전 버전은 오픈 소스 형식으로 개발되었으며, 8.9 버전부터는 Allman이 설립한 회사에 의해 개발 및 공개되었다. 이러한 역사적 배경 때문에 Sendmail은 두 가지 다른 라이센스 형식을 취하고 있다. 우선, Sendmail을 단순히 컴파일해서 바이너리만 사용하거나, 아니면 오픈 소스 형식으로 소스 코드를 제공하며 이용할 경우는 Sendmail License를 적용받는다. 이 라이센스는 Sendmail의 자유로운 이용, 수정, 및 배포를 허락한다. 단, 재배포할 경우에는 배포에 필요한 비용 이상을 부과할 수 없으며, Sendmail에 포함된 copyright notice를 반드시 포함시켜야 한다. 그리고 재배포시 소스 코드를 포함시키지 않을 경우에는, 최대 3년까지 소스 코드 제공을 보장하는 문서를 포함시켜야 한다. 반면, 소스 코드 제공없이 상업적 용도로 이용할 경우에는 Sendmail, Inc.와 접촉해서 별도의 라이센스를 받아야만 한다.

Please note that all contributions to ITnLAW may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see ITnLAW:저작권 for details). DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!

바꾼내용 간추리기:

취소 | 편집 도움말 (새 창으로 열림)

원본 주소 - 'http://www.itnlaw.co.kr/wiki/index.php/OSS_%EB%9D%BC%EC%9D%B4%EC%84%BC%EC%8A%A4_%EA%B0%80%EC%9D%B4%EB%93%9C_%EB%B0%8F_%ED%95%B4%EC%84%A4%EC%84%9C'

Editing OSS 라이센스 가이드 및 해설서 (section)

From ITnLAW

Views

Personal tools

Navigation

찾기

Toolbox