초보 개발자를 위한 오픈 소스 라이선스 길잡이 Part 2: 오픈 소스 소프트웨어와 라이선스의 이해

이진태 lawboy@socop.or.kr 컴퓨터프로그램보호위원회 연구실에서 소프트웨어 지적재산권 관련된 연구 및 연구기획 업무를 담당하고 있으며, 중앙대학교에서 법학 학사와 석사를 마치고 현재 고려대학교 정보경영 공학전문대학원 박사과정에 재학중이다. 2007년 11월 13일

연재순서
1회(2007년 10월): 기초 개념 탑재하기
2회(2007년 11월): 오픈 소스 소프트웨어와 라이선스의 이해

웹 2.0으로 대두되는 인터넷 환경의 패러다임 변화에 있어서 오픈 소스 소프트웨어의 영향력은 그 누구도 부인하지 않을 것이다. 많은 오픈 소스 소프트웨어가 웹 2.0을 가능하게 했던 원동력이며, 지금도 수많은 오픈 소스 소프트웨어가 우리의 인터넷 세상을 점점 풍요롭게 바꿔가고 있다.
가트너에 따르면 오픈 소스 소프트웨어의 시장점유율은 2005년 11%(42.6억 달러)에서 2010년에는 24%(161.5억 달러)로 28.5%의 성장할 것이며, ¹ 2010년까지 적어도 상용 소프트웨어 제품의 80%가 오픈 소스 코드를 포함하게 될 것이라고 한다. ² 그 외에도 디지털 기기에 포함된 임베디드 소프트웨어를 중심으로 많은 하드웨어에서 오픈 소스 소프트웨어를 사용하지 않고서는 제품 단가를 맞출 수 없을 정도로 그 사용범위도 점점 더 확대되고 있다.
문제는 오픈 소스 소프트웨어 사용이 이처럼 늘어남에 따라 이로 인한 분쟁도 점차 늘어나고 있다는 것이다. 즉, 우리가 공짜로 사용해도 되는 것으로 알고 있는 오픈 소스 소프트웨어들은 거의 대부분 지적재산권으로 보호받고 있다. 이러한 지적재산권이 있는 소프트웨어를 사용하려면 일정한 사용 조건을 담은 라이선스를 만들고, 이러한 라이선스에 따라 소프트웨어를 사용해야 한다. 만약 조건을 위반하여 사용하면 라이선스 위반으로 법적 제재를 받는다. 그러나 오픈 소스 소프트웨어에서 제시하는 라이선스의 조건들이 어려운 것이 아니므로 조금만 주의를 한다면 오픈 소스 소프트웨어를 통해 제공되는 훌륭한 소스코드들을 자유롭게 사용할 수 있다.
이 글에서는 이러한 오픈 소스 소프트웨어를 자유롭고 안전하게 사용하기 위해 오픈 소스 소프트웨어에서 제시하는 라이선스라는 것이 무엇이고 이것이 어떤 법적 구속력이 있으며, 마지막으로 오픈 소스 소프트웨어에서 제시하는 라이선스와 그 준수사항들을 살펴보고자 한다.

위로

오픈 소스 소프트웨어의 지적재산권

오픈 소스 소프트웨어와 지적재산권

일반적으로 많은 개발자가 인터넷에 올려진 오픈 소스 소프트웨어는 공짜(free)라고 생각한다. 그래서 이러한 오픈 소스 소프트웨어를 기반으로 자신이 원하는 프로그램을 개발하기도 하고, 메인 프로그램의 일부분을 오픈 소스 소프트웨어를 사용하여 개발하기도 한다.
그러나 이렇게 사용하는 소프트웨어에도 지적재산권이라는 것이 있다. 알다시피 지적재산권이란 동산(자동차, 증권 등)이나 부동산(건물, 토지 등)에 권리가 부여되듯이 무형의 재산에 대하여 부여되는 권리를 말한다. 무형의 재산에 대해 이러한 권리를 부여하는 이유는 저작물을 창작한 자가 노력해 만든 결과물에 대해 일정 기간동안 창작자에게 권리를 주어 노력에 대한 보상을 받을 수 있도록 하기 위함이다. 따라서 소프트웨어를 개발하면 개발자는 해당 소프트웨어에 대한 지적재산권을 소유하게 되고 그러한 권리를 이용하여 개발한 소프트웨어를 통해 일정 기간 수익을 창출할 수 있다. 더 정확하게는 지적재산권 중에서도 저작권을 갖게 된다.
그러나 수익을 창출하려면 지적재산권을 사용하려는 사람과 지적재산권을 가진 자가 서로 일정한 사용 조건과 범위를 정하는 계약을 맺어야 하는데 이러한 계약을 라이선스(license), 또는 사용허락이라고 한다. 그리고 이러한 라이선스를 작성해야만 법률적으로 유효하게 사용자가 법적 보호를 받으면서 권리를 행사할 수 있다.

라이선스란 무엇인가

라이선스란 권리자가 자신의 권리 중 일부분 또는 전체를 사용자가 사용할 수 있도록 하기 위해 체결한 계약을 말한다. 그리고 이러한 계약은 법률적인 효과가 있어 이를 위반할 때에는 법적 책임을 지게 된다.
그러나 우리가 말하는 '라이선스'라는 말은 법률 용어가 아니며, 법률 용어로는 ‘사용허락’이라고 한다. 즉, 소프트웨어를 사용하고자 하는 자에 대해 일정한 범위와 방법으로 프로그램을 사용할 수 있도록 인정해주는 것이 바로 사용허락이다. 그런데 실제 소프트웨어를 사용하는 데 있어서는 이러한 ‘사용허락’이나 ‘라이선스’라는 용어보다는 ‘사용권 계약’, ‘소프트웨어 사용 계약서’, ‘최종 사용자 이용 계약’이라는 용어를 더 많이 사용한다. 아래 그림은 안철수 연구소의 V3 2007을 설치할 때 나오는 화면으로 권리자인 안철수 연구소가 V3 2007 사용자를 상대로 프로그램의 사용범위를 명시한 ‘안철수 연구소 소프트웨어 사용권 계약서’다. 대부분의 소프트웨어들이 이러한 방식으로 권리자와 사용자간의 사용허락 또는 라이선스 계약을 맺고 있다.

이러한 계약은 법적인 효력을 지니고 있어 이를 지키지 않을 경우에 발생할 수 있는 손해에 대해 배상을 해야 하거나 이를 불법적으로 복제•배포 등의 행위를 했을 경우에는 5000만 원 이하 또는 5년 이하의 징역에 처하게 된다. ³

오픈 소스 소프트웨어 라이선스의 법적 구속력

오픈 소스 소프트웨어 라이선스란 오픈 소스 소프트웨어 개발자와 이용자 간에 사용 방법 및 조건의 범위를 명시한 계약을 말한다. 따라서 오픈 소스 소프트웨어를 이용하려면 오픈 소스 소프트웨어 개발자가 만들어놓은 사용 방법 및 조건의 범위에 따라 해당 소프트웨어를 사용해야 하며, 이를 위반할 경우에는 라이선스를 위반함과 동시에 저작권 침해로 이에 대한 처벌을 받는다.
대표적인 라이선스로는 GNU GPL(General Public License)/LGPL(Lesser General Public License), BSD(Berkeley Software Distribution), MPL(Mozilla Public License) 등의 라이선스가 있으며, 이런 오픈 소스 소프트웨어 라이선스는 기본적으로 사용자의 자유로운 사용•복제•수정•배포를 보장한다.
오픈 소스 소프트웨어가 이와 같은 라이선스를 만들어 운영하는 이유는 만약 오픈 소스 소프트웨어에 라이선스가 없다면 오픈 소스 소프트웨어를 가지고 무단으로 상용 소프트웨어를 개발하는 데 사용하고 해당 소스코드를 공개하지 않을 수 있기 때문에 법의 테두리 안에서 소스코드 공개를 강제할 수 있도록 하기 위한 것이다. 만약 오픈 소스 소프트웨어 라이선스를 위반할 경우에는 상용 소프트웨어와 마찬가지로 법적인 제재를 받게 된다.

위로

오픈 소스 소프트웨어 라이선스 위반사례

오픈 소스 소프트웨어 라이선스를 위반했을 경우 어떤 문제가 발생하는지 사례를 몇 가지 들어보면 다음과 같다.

Bracken 사건

Bracken은 GNU/리눅스 운영체제 제품을 생산하는 회사로 이 회사에서 판매하는 제품은 주로 OEM 벤더들에 판매되며 응용장치에 설치되어 인터넷 브라우징 역할을 하는 장치 같이 단일한 용도로 쓰인다. Bracken의 제품은 거의 100% 자유소프트웨어(Free Software)이며, 대부분 GPL이나 관련된 자유소프트웨어 라이선스에 따라 생산된 것이었다. 그러나 Bracken은 소스코드 제공 없이 단순히 바이너리(binary)만 이용할 수 있도록 하고 있었으며, 최종 사용자 이용 계약(End User License Agreement, EULA)에는 GPL에 의해 승인된 허용범위와는 모순된 내용을 포함하고 있었다.
이러한 사실이 자유소프트웨어 저작권자들에 의해 FSF ⁴ 에 통보되었다. FSF는 Bracken에 자세한 위반사항을 전달했고 Bracken은 즉시 제품 배포를 일시 중단했다. 그리고 FSF와 합의에 따라 최종 사용자 라이선스 계약을 FSF 심사를 거치도록 하고 소스코드를 공개하였다. ⁵

Fortinet 사건

이 사건은 보안 소프트웨어 개발사인 Fortinet에서 자사의 소프트웨어에 리눅스 컴포넌트이자 GPL로 배포된 ‘initrd’를 사용하였으나 암호 기술을 사용하여 그 사용 사실을 숨긴 데서 발단했다. 이에 gpl-viloations.org 운영자인 벨테(Welte)가 이를 개발한 개발자에게 저작권을 양도받아 GPL 위반으로 독일 법원에 제소하였다. 이에 2005년 독일 뮌헨 지방법원은 Fortinet에 GPL 조건을 준수하지 않음을 이유로 배포금지명령을 내렸고, 이로 인해 자사 제품을 유통할 수 없게 되자 결국 Fortinet은 자사 소프트웨어 소스코드의 일부를 공개하였다.

Skype 사건

Skype는 인터넷 전화인 P2P VoIP(voice over IP) 소프트웨어로 유명한 회사로 자사가 판매하는 SMC 네트워크 VoIP 전화기가 있었다. 그러나 이 전화기에는 벨테(Welte)가 저작권을 가지고 있는 GPL 2.0으로 배포된 소프트웨어 2개를 포함한 리눅스 운영체제를 사용하였다. 그러나 이 제품은 GPL 2.0의 요구조건인 소스코드를 공개하지 않았을 뿐만 아니라 GPL 문구를 붙이지도 않았다. 이에 벨테는 독일 뮌헨 지방법원에 라이선스 위반으로 고소를 했고 승소했다. 이 사건에서 Skype의 위반 내용은 미미하기 때문에 업무정지나 판매정지를 받지는 않고 벌금만 낼 것으로 보인다.

위로

오픈 소스 소프트웨어 라이선스의 주요내용

현재 오픈 소스 소프트웨어 라이선스의 인증을 맡고 있는 OSI(Open Source Initiative)에 의해 인증을 받은 오픈 소스 소프트웨어 라이선스는 64개가 있는데, ⁶ 이 중에서 대표적으로 많이 사용되는 GPL, LGPL, BSD, MPL에 대해 살펴보기로 한다. ⁷

GPL 2.0

GPL이란 FSF의 리차드 스톨만이 자유소프트웨어 운동을 벌이면서 소스코드 공개를 담보하기 위해 만든 라이선스다. GPL 2.0은 현재 오픈 소스 소프트웨어 세계에서 가장 많이 채택한 라이선스이며 가장 잘 알려져 있다. 그러나 GPL은 다른 오픈 소스 소프트웨어 라이선스에 비해 준수사항들이 엄격한 편이다. GPL 2.0의 가장 핵심이 되는 내용은 GPL 2.0으로 배포되는 제품의 경우에는 무조건 그 제품 전체의 소스코드를 공개해야 한다는 것이다. 단. 배포하지 않고 사용만 하는 경우에는 소스코드를 공개하지 않아도 된다. GPL 2.0의 주요 내용은 다음과 같다.

• 소프트웨어를 배포하는 경우 저작권 표시, 보증책임 이 없다는 표시 및 GPL에 의해 배포된다는 사실을 명시
• 소프트웨어를 수정하거나 새로운 소프트웨어를 링크(정적 및 동적 링크 모두)하는 경우 GPL에 의해 소스코드를 제공해야 함
• 오브젝트 코드(object code) 또는 실행(executable) 파일 형태의 GPL 소프트웨어를 배포하는 경우, 소스코드 그 자체를 함께 배포하거나 또는 소스코드를 제공받을 수 있는 방법에 대한 정보를 함께 제공해야 함
• 자신의 특허를 구현한 프로그램을 GPL로 배포하는 경우에는 그 프로그램을 GPL 조건에 따라 이용하는 이용자에게 특허에 대한 사용료를 받을 수 없으며, 제3자의 특허를 구현한 프로그램인 경우에는 그 특허권자가 GPL 조건에 따라 이용하는 프로그램 이용자에 대해 특허 사용료를 받지 않을 때에만 그 프로그램을 GPL로 배포하는 것이 가능

GPL 3.0

FSF에서는 지난 2007년 6월 29일 GPL 3.0을 공식 발표했다. GPL 3.0의 전체적인 체계를 보면, 서문을 제외하고 제0조부터 제17조까지 총 18개 조문으로 구성되어 있다. 이 중 제4조 내지 제6조, 제8조 내지 제10조, 제12조, 제14조 내지 제17조는 기존 GPL 2.0의 내용을 적절히 수정해 재구성한 것이다. 제0조 내지 제1조에서 각종 용어를 새로 도입하거나 기존 용어를 수정했으며, 제3조를 중심으로 DRM(Digital Rights Management) 관련 내용이 추가되었다. 또한 제11조 등에서는 소프트웨어 특허문제, 제13조에서는 Affero GPL과의 양립성 문제에 대처하고자 새롭게 추가된 내용이 있다. 기본적인 내용은 GPL 2.0과 동일하지만 GPL 3.0에서는 몇 가지 추가되거나 변경된 부분이 있다. 이에 대한 주요내용은 다음과 같다.

• GPL 3.0의 소스코드를 특정한 제품에 포함시키거나 혹은 그와 함께 배포하는 경우에는 해당 소스에 설치 정보(installation information) ⁹를 함께 제공해야 함. 다만 소프트웨어가 롬(ROM)에 설치된 경우처럼, 해당 제품의 제조업체나 여타 제3자도 수정된 코드를 제품에 설치할 수 없는 경우에는 설치 정보를 제공하지 않아도 됨
• DRM(Digital Rights Management)과 관련하여 각국의 법률에 의해 보호되는 이익을 포기해야 함
• 특허와 관련해 원래의 소스코드를 개선하여 배포한 기여자의 경우 자신이 기여한 부분에 대해서는 차별하지 않고 특허 사용료가 없다는 내용의 라이선스를 제공해야 함
• 특허와 관련해서 라이선시 ¹⁰ 등으로부터 특허소송이 제기되는 경우 소송을 제기한 날에 특허소송을 제기한 라이선시의 오픈 소스 소프트웨어 라이선스는 종료됨
• Apache License 2.0 및 Affero GPL과 양립 가능함

LGPL 2.1

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

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

BSD 라이선스

BSD(Berkeley Software Distribution) 라이선스는 소프트웨어의 소스코드를 공개하지 않아도 되는 대표적인 오픈 소스 소프트웨어 라이선스 중 하나다. BSD 라이선스는 소스코드를 공개하지 않아도 되기 때문에 GPL 및 LGPL과 비교하여 덜 제한적으로 사용할 수 있으며 허용범위가 넓다. BSD 라이선스의 허용범위가 넓은 이유는 BSD 라이선스로 배포되는 프로젝트가 미국 정부에서 제공한 재원으로 운영되었기 때문이다. 즉, 소프트웨어에 대한 대가를 미국 국민의 세금으로 미리 지불했기 때문에 사람들에게 그들이 원하는 방식으로 소프트웨어를 사용하거나 만들 수 있도록 허가된 것이다. 따라서 BSD 라이선스의 소스코드를 이용하여 새로운 프로그램을 개발하여도 새로운 프로그램의 소스코드를 공개하지 않고 BSD가 아닌 다른 라이선스를 적용하여 판매할 수 있다. 주요 내용을 요약하면 다음과 같다.

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

위로

MPL(Mozilla Public License)

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

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

글을 마치며

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

지금까지 오픈 소스 소프트웨어와 라이선스에 대한 이야기를 해 보았다. 오픈 소스 소프트웨어의 'free'는 다 아는 것처럼 ‘공짜’라는 뜻이 아닌 ‘자유’라는 뜻이다. 그리고 자유에는 항상 그에 상응하는 책임이 뒤따르게 되어 있다. 오픈 소스 소프트웨어에서는 그러한 책임을 GPL, LGPL, BSD 등의 라이선스에 담아놓은 것이다. 공교롭게도 이러한 라이선스가 법적 효력을 가지고 있어서 자유롭게 소스코드를 사용하자는 오픈 소스의 취지에 맞지 않다고 생각할 수도 있겠지만 만약 라이선스가 없었다면 아마 지금과 같은 오픈 소스 소프트웨어 활성화는 이루어지지 않았을지도 모른다.
기업 입장에서는 결국 이렇게 법적 보호를 받고 있는 오픈 소스 소프트웨어를 어떻게 잘 관리하고 활용하는가 하는 것이 가장 중요한 문제이고 과제일 것이다. 그러나 그러한 문제는 라이선스라는 지침이 있고 이를 어떻게 활용할 것인가만 결정하면 되는 것이다. 즉, 기업에서는 기획 단계에서 해당 제품의 수익모델을 오픈 소스 소프트웨어를 사용하는 서비스 형태로 할 것인지, 배포를 요구하는 판매 형태로 할 것인지를 결정하면 이에 적합한 라이선스를 가진 오픈 소스 소프트웨어를 이용하면 되는 것이다. 만약 그것이 절대로 공개하면 안 될 제품이라면 BSD처럼 소스코드를 공개하지 않아도 되는 라이선스를 가진 오픈 소스 소프트웨어를 사용하면 된다. 따라서 오픈 소스 소프트웨어를 자유롭게 사용할 수 있는 최고의 방법은 오픈 소스 소프트웨어의 라이선스를 정확히 이해하는 것이라 하겠다.

위로

주

¹ Open-Source Software, Worldwide, 05-10, Gartner, '06.

² Peter Galli, Commercial Software Will Include Open Source, Gartner Says, 2007. 9. 19. [http://www.eweek.com/article2/0,1895,2185384,00.asp], 2007.11.9. 최종방문

³ 컴퓨터프로그램 보호법 제46조.

⁴ FSF(Free Software Foundation)은 자유소프트웨어(Free Software) 운동을 시작한 리차드 스톨만에 의해 창립된 비영리 단체로서, 자유소프트웨어의 이용 촉진 및 GNU 시스템 개발과 GPL 및 LGPL 관리를 하고 있다.

⁵ [http://www.itnlaw.co.kr/wiki/] 2007.11.6. 최종방문

⁶ 2007년 11월 6일 현재.

⁷ 이철남•권순선•최민석이 작성한 ‘오픈 소스 소프트웨어 라이선스 가이드’(안)의 내용을 바탕으로 정리한 것으로 더 자세한 내용은 [http://wiki.kldp.org/wiki.php/OpenSourceLicenseGuide]를 참고하기 바란다. 2007.11.6. 최종방문.

⁸ 해당 문구에서 보증책임이란 해당 소프트웨어로 인해 발생하는 문제에 대해서 원래 소스코드의 개발자가 지게 되는 책임을 말한다.

⁹ 설치정보란 소프트웨어를 수정하여 해당 제품에 설치하고 실행하는 데 필요한 방법(methods), 절차(procedures), 인증키(authorization keys) 혹은 여타 정보 모두를 의미한다.

¹⁰ 라이센시(licensee)는 라이선스를 받은 사람을 말한다.

[지난 Special Issue 보기]