OSS 라이센스 가이드 및 해설서

From ITnLAW

• 현재로서는 이제까지 오픈소스 및 라이센스와 관련하여 제가 발표했었던 자료들을 취합한 내용들 위주입니다. 논문형식으로 발표된 글들이기에 문체가 건조하고 딱딱합니다. 이와 같은 취합을 한 후, 관련 내용을 새롭게 정리하고, 부족한 내용들을 보충하며, 글의 문체도 개발자들이 이해하기 쉽도록 수정될 예정입니다.

목차 1 오픈소스소프트웨어 라이센스 가이드 1.1 오픈소스소프트웨어의 개요 1.2 오픈소스소프트웨어의 지적재산권과 라이센스 1.3 오픈소스 라이센스의 구체적 내용 1.3.1 공통적 준수사항 1.3.2 라이센스별 준수사항 1.3.3 주요 쟁점 1.3.4 주요 오픈소스소프트웨어 사례 1.4 기업에서의 오픈소스 라이센스 관리/활용 방안 1.4.1 오픈소스소프트웨어관련 정책의 수립 1.4.2 오픈소스라이센스관리를 위한 프로세스/조직의 구축 2 서론(OSS의 의미, 역사, 현황 등) 3 S/W의 지적재산권과 라이센스 4 주요 OSS 라이센스 4.1 GPL 4.1.1 GPL 제정의 배경과 의미 4.1.2 GPL의 주요쟁점 4.2 LGPL 4.3 BSD/MIT/Apache 4.4 MPL/EPL/CPL 4.5 주요 쟁점과 라이센스간 비교 4.6 GPL version 3 5 주요 OSS제품의 라이센스 분석 6 기업에서의 OSS 라이센스 관리/활용 방안 6.1 기업에서의 OSS 활용권장 프로세스 6.1.1 (1) 기획(S/W Design) 단계 6.1.2 (2) 구현(Implementation) 6.1.3 (3) 검증(Verification) 6.1.4 (4) 제품화(Production) 6.2 구체적 사례 7 OSS라이센스 분쟁 사례 7.1 S/W 지적재산권침해 일반 7.1.1 OSS에서의 주요 위반사항 7.2 OSS 라이센스 위반의 발견 및 처리과정 7.3 주요 사례 (Wikipedia 참조) 7.3.1 BusyBox Cases 7.3.2 Innovation LLC v. Red Hat and Novell (특허관련) 7.4 분쟁발생시 기업의 대응 7.4.1 특허침해소송에서의 대응 8 부록 8.1 주요 OSS 라이센스 8.2 참고자료

오픈소스소프트웨어 라이센스 가이드

오픈소스소프트웨어의 개요

오픈소스소프트웨어란 무엇인가

오픈소스소프트웨어(Open Source Software)는 일반적으로 자유롭게 사용, 복제, 배포, 수정할 수 있으며, 소스코드가 공개되어있는 소프트웨어를 말한다. OSS의 예로는 리눅스 커널 및 관련 GNU 소프트웨어, 아파치 웹서버, FireFox 웹브라우저, MySQL 데이터베이스시스템, Python/PHP/Perl 언어, Eclipse 툴 등을 들 수 있으며, 그 외에도 전세계의 수많은 개발자들이 개발하고 있는 프로그램들이 있다.

통상 오픈소스소프트웨어는 자유소프트웨어(Free Softwaer)를 포함한 넓은 의미로 사용되며, 국내에서도 자유소프트웨어를 포함한 오픈소스소프트웨어를 ‘공개소프트웨어'로 번역하여 사용하고 있다. 하지만 역사 및 추구하는 이념 등에서 자유소프트웨어와 오픈소스소프트웨어는 미묘한 차이가 있다.

자유소프트웨어(Free Software)는 리차드 스톨만과 FSF(Free Software Foundation)에 의해 만들어진 개념으로서, 소프트웨어의 이용자에게 해당 소프트웨어를 실행, 복제, 배포할 수 있는 자유, 그리고 소스코드에 대한 접근을 통해서 이를 학습, 수정, 개선시킬 수 있는 자유를 부여하는 소프트웨어이다. 1980년대에 들어 PC가 널리 보급되기 시작하면서 이전에는 하드웨어의 부속물로만 간주되던 소프트웨어가 거대한 부가가치산업으로 발전하기 시작하였고, 이러한 흐름과 함께 지적재산권 및 라이센스계약을 통하여 소프트웨어의 사용, 복제, 배포, 수정에 일정한 제한을 가하려는 움직임이 나타나게 된다. 소프트웨어를 둘러싼 이러한 일련의 흐름에 반대하고 소프트웨어의 자유로운 사용, 공유, 수정에 대한 기존의 권리를 지키기 위하여 리차드 스톨만은 FSF를 설립하고 자유소프트웨어(Free Software) 운동을 전개하였다.

한편 1990년대 들어서면서 인터넷과 더불어 GPL(General Public License)로 배포된 리눅스가 널리 보급되기 시작하였고, MS의 익스플로러에 밀려 어려움을 겪고 있던 Netscape사가 웹브라우저의 소스코드를 공개하는 결정을 내렸으며, IBM, Sun 등이 자유소프트웨어에 대한 지원을 시작하였다. 그러나 자유소프트웨어의 ‘자유Free'라는 단어가 한편으로 ’무료‘라는 의미를 가진다는 점, 엄격한 GPL조항 때문에 상용 기업들이 참여를 꺼려한다는 점 등을 이유로 '오픈소스(Open Source)'라는 용어가 제안되었고, 1998년 Open Source Initiative가 활동하기 시작하면서 오픈소스소프트웨어가 널리 사용되게 되었다. OSI는 오픈소스소프트웨어로 인정받을 수 있는 10가지 ‘라이센스 조건’을 정의하고, 각각의 소프트웨어에 대한 라이센스를 분석하여 오픈소스소프트웨어라이센스에 해당하는지 여부에 대한 인증을 하고 있다. 주요 내용을 살펴보면, 소프트웨어에 대한 배포 및 수정의 자유를 인정해야 하며 소스 코드를 제공할 수 있어야 할 것, 그리고 어떤 사람이나 그룹 또는 이용분야에 대한 차별이 없어야 한다는 조건 등을 두고 있다. 2007년 6월 기준으로, 58개의 라이센스가 오픈 소스 라이센스로 인정되어 등록되어 있다. 하지만 실제로 많이 사용되는 라이센스의 갯수는 한정되어 있다. 오픈 소스 프로젝트 개발 포털사이트인 freshmeat.net에 등록되어 있는 프로젝트들 중에서 오픈소스로 분류되는 약 34,368개 프로젝트의 라이센스 채택 현황을 보면 아래와 같다. <<라이센스 분포 표>> 약 82%에 해당하는 프로젝트가 GPL/LGPL을 사용하고 있으며, 그 뒤를 BSD가 차지하고 있다. 따라서 GPL/LGPL/BSD 라이센스가 주로 사용되고 있음을 알 수 있다. 그러나 Mozilla 웹브라우저, Apache 웹서버 등 일부 중요한 오픈소스 소프트웨어들은 자체적으로 라이센스를 가지는 경향도 있다.

오픈소스소프트웨어 라이선스 분포표

오픈소스소프트웨어의 사례

아래는 유명한 오픈소스소프트웨어들의 사례이다.

• Linux 커널 : 가장 대표적인 오픈소스소프트웨어인 Linux라 하면 보통 "Linux 운영체제"를 통칭한다. 하지만 여기서는 명확한 설명을 위해 Linux 커널에 한정하기로 한다. 보통 RedHat, SusE, 그리고 한컴리눅스 등이 배포하는 Linux 운영체제에는 Linux 커널을 포함하여 많은 애플리케이션과 유틸리티로 구성되어 있다. 또한 각 애플리케이션 및 유틸리티는 서로 다른 라이센스 하에 배포되고 있다. Linux 커널은 토발즈에 의해 최초로 개발되었고, 이후 많은 사람들의 자발적 참여와 기여 덕택에 오늘날 가장 인기있는 운영체제 중 하나가 되었다. 토발즈는 현재까지도 Linux 커널 개발의 중심에 있으며 Linux 개발 커뮤니티에는 수천명의 개발자가 서로 협력하고 아이디어를 공유하며 Linux를 더 좋은 운영체제로 만들어 가고 있다.

• Apache : Apache는 현재 가장 많이 이용되는 웹서버이다. 오늘날 Apache의 전신은 1995년까지 NCSA(National Center for Supercomputer Applications)에 의해 개발되었다. 이 후 핵심 개발자인 Rob McCool를 포함 많은 개발자들이 NCSA 떠나면서 NCSA 주도의 웹 서버 개발이 정체되었다. 그래서 많은 웹마스터들은 스스로 필요한 기능을 개발하고 버그를 수정해 나가야만했다. 이런 상황에서 소수의 몇몇 웹마스터들이 이메일과 정기적인 미팅을 통해 NCSA가 개발한 웹서버를 공식적으로 유지보수하기 시작하였다. 이들은 자신들을 Apache Group이라 명명하였고, 오늘날 Apache Software Foundation의 근간이 되었다. Apache Software Foundation(ASF)은 1999년에 설립되었고 지금은 Apache 개발을 주도하고 있다.

• Bind : BIND(Berkeley Internet Name Daemon)는 일반 IT유저에게는 잘 알려져 있지 않지만 가장 많이 이용되는 DNS(Domain Name System)이다. 즉, BIND는 호스트명을 IP주소로 변환시켜주는 프로그램으로서 인터넷의 인프라를 구성하는 매우 중요한 요소다. BIND는 모든 Unix 시스템에서는 사실상의 표준으로 자리잡았으며, 다른 많은 다른 시스템에 포함되어 있기 때문에 사실상 인터넷 표준이라 할 수 있을 것이다. BIND는 1984년에 Paul Mockapetris에 의해 처음 개발되었고, 현재는 Paul Vixie가 주도하고 있는 ISC(Internet Software Consortium)에서 주도적으로 개발을 책임지고 있다. 참고로, ISC는 1993년에 UUNET의 지원을 받아 Rick Adams에 의해 설립되었고 지금은 SUN, HP, IBM, SGI 등 주요 소프트웨어기업의 지원을 받고 있다. BIND는 ISC에서 자체 개발한 라이센스를 적용하고 있으며, 개인적 혹은 상업적 용도 구별없이 자유롭게 이용, 복제, 수정, 및 재배포가 가능하다.

• Mozilla Firefox : Mozilla는 Netscape에 의해 시작된 오픈 소스 브라우저 프로젝트이다. 이 프로젝트의 일원이었던 Dave Hyatt와 Blake Ross는 Netscape가 받고있는 상업적 후원이 오히려 Mozilla 브라우저 개발에 악영향을 미치고 있다고 믿었다. 그래서 이들은 실험적으로 Mozilla Project에서 파생한 작은 Firefox Project를 별도로 시작하여 핵심적 기능을 갖춘 브라우저 개발에 착수하였다. 그런데 2003년 4월, Mozilla Foundation은 기존 Mozilla Project보다 오히려 Firefox Project에 더 전념할 계획을 밝혔다. 이 후 Firefox Project는 몇 번 이름 변화 과정을 거쳤다. 원래 Phoenix라 명명되었지만, Phoenix Technologies사와 상표권 분쟁으로 인해 Firebird로 변경하였다. 하지만, Firebird 역시 Firebird란 무료 데이터베이스 소프트웨어 프로젝트로 부터 거센 저항을 받았다. 결국 Mozilla Firebird로 다시 이름을 고쳤지만, 지속된 반발로 인해 2004년 2월 오늘날의 이름은 Mozilla Firefox로 다시 변경하였다.

오픈소스소프트웨어의 지적재산권과 라이센스

소프트웨어의 지적재산권과 라이센스

현재 소프트웨어는 다음과 같이 저작권, 특허권, 영업비밀, 상표 등의 지적재산권법에 의해 보호받고 있다.

• 저작권 : 어떤 프로그래머가 특정 소프트웨어를 개발하게 되면 컴퓨터프로그램저작권이 자동적으로 발생하며, 프로그래머 또는 그가 속한 회사에 부여된다. 저작권(copyright)은 시, 소설, 노래 등 저작물에 대해 부여되는 권리로서 그 표현(expression)의 결과물을 보호하는 것이다. 누구도 원 저작자나 저작권자의 허가가 없이는 해당 저작물을 복사, 개작, 재배포할 수 없다.

• 특허권 : 특허는 하드웨어에 구현되거나 소프트웨어에 의해 동작이 구현되는 발명(invention)을 보호한다. 특허권은 자동으로 부여되는 것이 아니고 법에 정해진 절차에 의해 출원을 하여야 하며, 심사를 통해 부여되는 권리이다. 특허 기술을 구현(implementation)하기 위해서는 반드시 특허권자의 허락을 득하여야만 한다. 특허 소유자는 소유자가 허가하지 않은 사람이 해당 특허를 활용한 제품을 만들거나, 사용하거나, 판해하는 것을 막을 수 있다. 특허는 무엇인가 유용한 것을 하도록 하는 방식(method)이므로 소프트웨어의 경우 특허받은 방식을 구현하는 소프트웨어라면 프로그래밍 언어가 다르거나 소스코드가 다르더라도 해당 특허권자의 명시적인 허가를 받아야 하며 이는 오픈소스소프트웨어, 독점소프트웨어에 공통으로 해당된다.

• 영업비밀 : 영업비밀이란 공연히 알려져 있지 아니하고 독립된 경제적 가치를 지니는 것으로서 상당한 노력에 의하여 비밀로 유지되는 생산 방법, 판매 방법, 기타 영업 활동에 유용한 기술상/영업상의 정보로 정의되어 있다. 이러한 영업비밀은 "부정경쟁방지 및 영업비밀보호에 관한 법률"에 의하여 보호받고 있으며, 이와 같은 영업비밀을 부당한 수단으로 취득하거나, 비밀유지의무가 있음에도 다른 사람에게 누출하는 것은 처벌받게 된다.

• 상표 : 상표권이란 제품이나 서비스와 연계되어 마케팅에 활용되는 이름 등을 보호한다. 또한 상표는 시장에서 나의 제품과 타인의 제품을 구별해 주는 역할을 한다.

이상과 같은 지적재산권에 의해 권리자는 소프트웨어에 대한 배타적인 권리를 가지게 되며, 원칙적으로 권리자만이 소프트웨어를 사용, 복제, 배포, 수정할 수 있다. 하지만 다양한 필요에 의해 이들 권리자가 다른 사람에게 일정한 내용을 조건으로 하여 특정 행위를 할 수 있는 권한을 부여할 필요가 있는데, 이와 같은 권한을 보통 '라이센스(license, 사용허가권)'라고 한다. 이러한 의미에서 라이센스는 물건을 판매하는 매매와는 차이가 있으며, 소프트웨어에 대한 지적재산권은 여전히 원래의 권리자에게 남아있고 일부 사용에 대한 권리만을 부여하는 것이다. 마이크로소프트, 오라클 등 일반적인 독점(proprietary)소프트웨어 업체의 라이센스는 고객이 소프트웨어 권리자에게 대금을 지급하고 소프트웨어의 ‘사용’ 권한만을 허락하는 것이 일반적이다. 따라서 허락을 얻지 않고 소프트웨어를 복제, 배포, 수정하는 행위는 라이센스를 위반함과 동시에 불법에 해당한다.

오픈소스 라이센스의 특징

오픈소스소프트웨어 역시 독점소프트웨어(proprietary software)와 동일하게 저작권 등에 의한 법적 보호를 받고 있으며, 이와 같은 권리에 기반하여 이용자에게 라이센스를 부여한다. 그러나 오픈소스라이센스는 일반적인 독점소프트웨어 라이센스와는 많은 점에서 차이가 있다. 기본적으로 오픈소스 라이센스는 다음과 같이 사용자의 자유로운 사용, 복제, 배포, 수정을 보장하고 있다.

• 라이센시는 해당 오픈소스소프트웨어를 자유롭게 사용할 수 있다.
• 라이센시는 해당 오픈소스소프트웨어를 자유롭게 복제할 수 있으며, 일정한 조건하에 재배포할 수 있다.
• 라이센시는 해당 오픈소스소프트웨어를 자유롭게 수정하여 사용할 수 있으며, 일정한 조건하에 수정된 내용을 재배포할 수 있다.
• 라이센시는 해당 오픈소스소프트웨어의 소스코드를 자유롭게 획득하고 접근할 수 있다.

오픈소스 라이센스는 소프트웨어의 사용, 복제, 배포, 수정의 자유를 부여함과 아울러 다른 한편으로는 소프트웨어의 사용자에게 일정한 의무를 부과하고 있다. 구체적인 내용은 오픈소스소프트웨어와 함께 배포되는 라이센스의 내용을 통해 알 수 있다. 해당 오픈소스소프트웨어에 대한 라이센스는 주로 소스코드 내부나 홈페이지 등에 명시되어 있다. 소스코드에서는 주로 최상위 디렉토리에 COPYING이라는 독립된 파일에 라이센스 조항을 기록하기도 하며, 각각의 소스코드 파일 상단에 명시해 두기도 한다.

오픈소스라이센스에서 요구하고 있는 준수사항을 라이센시가 이행하지 않으면 권리자로부터 저작권 위반 (또는 계약 위반)으로 소송을 제기 당할 수 있다. 만약 권리를 침해한 것으로 결론이 내려지면 소프트웨어의 배포가 더 이상 불가능할 뿐만 아니라 이미 배포한 소프트웨어에 대한 손해배상 등 막대한 책임을 부담할 수 있다. 특히 임베디드 소프트웨어의 경우 이를 내장한 제품까지 판매하지 못하거나 리콜(Recall) 해야 하는 경우도 발생할 수 있으므로 라이센스의 의무사항을 명확히 이해하여 이와 같은 상황을 사전에 예방하는 것이 필수적이다. 그러나 이러한 위험 때문에 오픈소스 소프트웨어를 전혀 사용하지 않겠다는 결론을 내릴 필요는 없다. 독점소프트웨어 라이센스에서 규정하고 있는 의무사항에 비하면 오픈소스 라이센스가 요구하고 있는 내용이 결코 어려운 것이 아니므로, 오히려 이를 잘 이해하고 준수함으로써 오픈소스 소프트웨어의 장점을 적극 활용할 필요가 있다. 또한 몇몇 라이센스만이 독자 개발한 소스 코드의 공개를 요구하고 있기 때문에 이를 잘 분석한 후 사용한다면 문제 발생 소지는 거의 없을 것이다.

따라서 인터넷 상에서 자유롭게 구할 수 있는 오픈 소스를 다운로드받아 개발에 적용할 때는 반드시 라이센스의 요구 사항을 반드시 확인하여야 한다. 또한, 자체 판단이 불가능할 경우에는 외부 전문가에게 조언을 의뢰하여 개발 시작 전 해당 라이센스의 요구 사항과 오픈 소스 사용 목적을 확실히 분석하여야 한다. 이렇게 하는 것만으로도 충분히 올바르게 오픈 소스를 최대한 활용할 수 있으며, 나중에 발생할 수 있는 문제들을 사전에 차단할 수 있다.

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

공통적 준수사항

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

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

• 저작권 관련 문구 유지 : 앞에서 저작권이란 표현된 결과물에 대해 발생하는 권리이며 자동적으로 부여된다고 기술하였다. 소프트웨어의 소스코드에 대해서도 마찬가지이며 잘 관리되는 오픈소스 소프트웨어들의 경우 거의 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있는데 만약 이러한 개발자 정보를 임의로 수정하거나 삭제하여서는 안된다. 특히 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.와 접촉해서 별도의 라이센스를 받아야만 한다.

기업에서의 오픈소스 라이센스 관리/활용 방안

오픈소스소프트웨어관련 정책의 수립

최근 국내외 많은 기업들이 오픈소스소프트웨어를 활용하여 비즈니스를 수행하고 있다. 선진 기업들은 기업 외부의 오픈소스소프트웨어를 도입하여 활용할 뿐만 아니라, 오픈소스개발방법론을 통해 기업에서 필요한 소프트웨어를 개발하기도 하며, 그 과정에서 외부에 있는 오픈소스 커뮤너티를 적극 활용하기도 한다. 하지만 국내 기업들의 대다수는 오픈소스소프트웨어관련 정책을 따로 마련하지 않고 개발자들 수준에서 기업외부에 존재하는 오픈소스소프트웨어를 단순 활용하는 수준에 머물러 있는데, 향후 오픈소스소프트웨어에 대한 활용의 필요성이 지속적으로 증가할 것이라는 점을 고려한다면 개별기업차원에서 오픈소스소프트웨어관련 정책을 수립할 필요성이 있다. 오픈소스소프트웨어 관련 정책을 수립할 때에는 개별기업이 속한 시장의 상황, 오픈소스소프트웨어의 발전정도, 개별기업들의 기술수준 및 비즈니스모델 등을 고려할 필요가 있다.

개별기업에서 오픈소스를 활용할 경우에는 오픈소스의 장/단점을 명확히 이해한 상태에서 활용 여부 및 방향을 결정하여야 할 것이다. 일반적으로 오픈소스소프트웨어는 다음과 같은 장점을 가지고 있다.

• Low Entry Cost : 일반적으로 오픈소스는 Web 상에서 무료로 다운로드 및 소스 코드 수정/ 재배포가 가능한 것이 특징이다. 따라서 초기 개발을 시작하기 위한 비용이 적게 요구된다는 장점이 있다.
• Fast, Flexible Development : 오픈소스 커뮤니티는 보통 최신 기술 정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운영되기 때문에 독점 프로그램에 비해 기술 발전 속도가 빠르다.
• Open Formats & Protocols : 오픈소스는 주로 Open Formats 또는 Protocols을 사용하기 때문에 서로 다른 소프트웨어간 상호 연동성이 보장되는 장점이 있다. 모든 기기들이 서로 다른 Network을 통해 하나로 연결되는 Ubiquitos 시대에는 필수적인 요소로 볼 수 있다. 또한 오픈소스 운동의 주 원인 역시 상용 프로그램들간의 비호환성을 해결하는 것이다.
• Reliability & Stability : 오픈소스의 개발 과정을 볼 때, 전세계에 있는 수많은 우수한 개발자들이 직접 개발과 Debugging 과정에 참여하기 때문에 In-house에서 폐쇄적으로 개발되는 독점 프로그램에 비해 비교적 안정적으로 동작한다는 평이 일반적이다. 하지만 이러한 Reliability와 Stability는 많은 개발자들의 적극적인 참여가 있을 때에만 가능한 것이기 때문에, 사용하고자 하는 오픈소스의 개발 과정을 주의깊게 살펴볼 필요가 있다. 참고로 최근 OSDL에서 발표한 Linux Kernel 개발과정을 보면 Linux Kernel이 단순히 Community 멤버들의 자발적인 참여에 의해 이루어지는 것이 아니라 체계적이고 과학적인 개발 방법론에 의해 이루어지고 있음을 알 수 있다. <<OSDL 그림첨부>> Linux 커널 개발 프로세스
• Networking : 오픈소스가 확산된 가장 큰 이유가 다양하고 강력한 Networking 기능 지원이라 해도 과언이 아닐 것이다. 대표적으로 Apache는 전세계 웹 서비스의 절반 이상을 차지하고 있을 정도이다. 또한 Open Source Networking Solution은 대부분 상용 프로그램과 호환되기 때문에 상품화에도 아주 잘 활용될 수 있을 것이다.

반면 오픈소스소프트웨어는 다음과 같은 단점이 지적되고 있다.

• 애플리케이션의 부족: 대부분의 사용자들은 Windows 기반의 GUI(Graphical User Interface)를 갖고 있는 Application에 익숙해 있지만, 이에 버금가는 Linux 기반의 Application이 많이 부족한 것이 현실이다. 또한 Linux 기반으로 개발된 많은 Application들은 Windows 기반 Application들과 호환되지 않는 문제점도 있다.
• 빈약한 문서: 상용 프로그램에 비해 오픈소스는 체계적인 문서를 갖고 있지 못한 단점이 있다. 이는 경우에 따라서는 개발과정의 지연을 초래할 수도 있기 때문에 활용하고자 하는 오픈소스가 얼마만큼 문서화가 잘 되었는지도 잘 살펴보아야 한다.
• 불확실한 개발 로드맵: 오픈소스는 영리를 목적으로 하는 회사에서 개발되는 것이 아니라, 자발적 참여를 바탕으로 Web 상에서 자유롭게 개발되는 것이 특징이다. 그렇기 때문에 독점 프로그램에서 볼 수 있는 Roadmap을 기대하기 힘든 면이 있다. 오픈소스의 이러한 단점은 오픈소스를 활용하는 개발 과제의 Roadmap에 까지 영향을 미칠 수 있기 때문에 활용하고자 하는 오픈소스의 향후 개발 계획이 얼마나 체계적으로 세워져 있는지도 고려해야 한다.
• 지적 재산권: 오픈소스에 기업이 보유한 특허 및 소스코드를 포함시킬 경우 오픈소스 라이센스는 일반적으로 Royalty-free를 요구하고 있다. 따라서 Royalty-free를 원치 않을 경우에는 해당 오픈소스를 사용할 수가 없으며, 또한 사용 후 Royalty를 주장하게 되면 해당 오픈소스에 대한 사용 권한이 박탈되는 경우가 일반적이다. 따라서 오픈소스를 활용하여 특허를 구현하거나 기존 소스코드를 포함하고자 할 경우, 반드시 Royalty에 대한 입장을 명확히 하여야 할 것이다.

오픈소스라이센스관리를 위한 프로세스/조직의 구축

오픈 소스를 활용하기 위해서는 독점소프트웨어와 마찬가지로 반드시 해당 오픈소스의 라이센스에 대한 준수가 필수적이다. 하지만 오픈소스 라이센스에서 강제하고 있는 내용에 대해서 개발자 및 관리자들의 이해가 아직도 많이 부족한 것이 현실이다. 자칫 잘못하면 라이센스 위반으로 이미 판매중인 제품을 리콜하거나, 소스코드를 공개해야 하며, 개발중인 제품을 아예 처음부터 다시 개발해야 하는 상황을 초래할 수도 있으므로 체계적인 프로세스를 수립하고 이를 담당할 관련 조직을 구축하는 것이 필요하다.

개발이 끝난 이후에 오픈소스 라이센스관련 문제가 발견된다면 수정에 많은 시간과 비용이 소요되므로 과제 계획 단계부터 오픈소스 라이센스문제를 고려할 필요가 있다. 또한 개발이 진행되면서도 단계별로 준수해야 할 사항들을 정의하고 반드시 체크해야만 한다. 본 문서에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 S/W 개발프로세스를 다음과 같이 표준화/단순화하였다.

'기획(SW Design)' -> '구현(Implementation)' -> '검증 (Verification)' -> '제품화(Production)'

기획(S/W Design)단계

오픈소스 라이센스 관련 문제를 피하는 가장 좋은 방법은 개발 기획 시점부터 이를 고려하는 것이다. 우선 해당 과제에 오픈소스를 활용할 것인지의 여부를 판단하여야 하며, 구체적으로 어떤 프로그램을 사용할 지를 판단하여야 한다. 오픈소스의 특성상 Web 상에 여기저기 흩어져 있지만, 쉽게 오픈소스에 관한 정보를 찾을 수 있는 곳으로는 Freshmeat.net, SourceForge, OSDir.com, BerliOS, Bioinformatics.org 등을 들 수 있다. 이와 같은 사이트들은 대부분 License별 오픈소스 분류 항목을 두고 있기 때문에 쉽게 해당 프로그램의 라이센스를 확인할 수 있을 것이다.

기획 단계의 마지막으로 해당 S/W Component별로 소스코드 공개가능여부를 판단하여야 한다. GPL등 소스코드 공개 의무가 발생하는 오픈소스소프트웨어를 사용할 경우에는 과제 결과물의 소스코드 공개가 요구되기 때문에, 경우에 따라서는 S/W 구현 방법을 달리해야하기 때문이다. 소스코드의 공개가능 여부에 대한 판단 기준으로 다음의 사항을 참조할 수 있을 것이다.

• Maintenance : 소프트웨어의 경우 하드웨어와 달리 개발 후 지속적 Upgrade 및 Debugging과 같은 Maintenance 과정이 중요하다. 이러한 Maintenance 과정은 상당한 Resource를 요하기 때문에 Maintenance를 직접 할 것인지에 대한 고려가 필요하다. 개발한 소스 코드를 오픈소스 커뮤니티에 공개하고, 이를 바탕으로 오픈 소스 커뮤니티를 통한 Maintenance 방법 역시 경우에 따라 아주 효율적일 수도 있을 것이다.
• Fast Development : 오픈소스의 개발 모델 중 가장 특징적인 것이 바로 ‘Release Early and Often’을 통한 ‘Parallel Development and Debugging’이 가능한 것이다. 이를 통해 오픈소스는 빠른 개발 속도를 가능케 하고 있다. 이러한 모델을 Resource가 부족한 개발 과제에 적용하면 보다 효율적이고 빠른 개발이 가능할 것이다.
• Reliability 확보: S/W의 신뢰성 확보의 가장 좋은 방법은 다양한 사용자들이 다양한 환경에서 해당 프로그램을 사용하면서 발견되는 문제점을 신속히 수정하는 것이다. 이런 측면에서 볼 때 오픈소스 커뮤니티를 잘 활용하면 S/W Reliability 확보에 상당한 도움을 얻을 수 있을 것이다.
• 차별화 유지 어려움 : 소스 코드를 공개하게 되면 그 소스 코드는 경쟁사에게도 공유되는 것이기 때문에 결국 제품의 차별화 확보가 불가능하게 되는 단점이 있다.
• 지적재산권 확보의 어려움: 기업이 보유한 특허를 구현하여 소스코드를 공개하는 것은 결국 모든 사용자들에게 Royalty-free의 조건으로 특허를 공개하는 것이나 마찬가지가 된다.
• 특허 침해 소송 제기 가능성 증가: 소스 코드가 공개되어 있으면 누구든 그 소스 코드를 볼 수 있기 때문에 특허 침해 소송 제기 가능성이 증가하게 되는 문제점이 발생할 수 있을 것이다.

구현(Implementation)단계

자체 개발한 소스 코드를 공개해도 무방한 경우는 특별히 구현 방법에 신경 쓸 필요가 없다. 단, 소스 코드를 공개할 경우 회사보유의 지적재산권을 포함시키지 않도록 주의할 필요가 있다. 그러나 소스 코드 공개를 원하지 않을 경우는 사용하는 오픈소스의 라이센스 강제 사항과 활용하고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한 경우가 발생할 수 있기 때문에, 이럴 경우는 라이센스 혹은 법률 전문가에게 의뢰하여 정확한 판단을 받아야 할 것이다.

검증(Verification)단계

개발이 완료된 후에는 개발 결과물인 소스 코드에 대해 실질적인 검증 작업이 필요하다. 개발 계획서 그 자체로는 라이센스 이슈가 없었더라도 실제 구현 과정에서 개발자가 오픈소스 라이센스에 대한 검증없이 사용한 경우가 있을 수 있기 때문이다. 최근에는 특정한 소스코드가 오픈소스 코드와 일치하는지를 검증하여 주는 프로그램을 활용하는 사례가 증가하고 있다.

제품화(Production)단계

이 단계에서는 사용된 오픈소스 소프트웨어들을 라이센스별로 분류하고 각 라이센스에서 준수해야 할 사항들이 실제로 제품에 반영될 수 있도록 하여야 한다. 앞에서 오픈소스의 라이센스 의무사항은 크게 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이센스 조합', '사용 여부 명시', '소스코드 공개', '특허' 등이 있다고 기술하였는데 이중에서 '저작권 관련 문구 유지', '제품명 중복 방지', '특허' 등은 기획 및 구현 단계에서 확인되어야 할 사항이고, 제품화단계에서는 '소스코드 공개', '사용 여부 명시' 등을 확인할 필요가 있다.

소스코드 공개는 공개 의무가 발생하는 소스코드를 제품을 배포할 때 함께 배포한다거나(예: CD롬 등), 연락처를 기재하고 해당 연락처로 요청하게 한다거나, 혹은 별도의 웹사이트 등에 업로드하여 두고 받아 가도록 하는 등의 방법이 가능하다.

사용 여부 명시는 해당 의무가 발생하는 소프트웨어에 대한 설명을 사용자 매뉴얼 등에 기재함으로써 이루어지는데, GPL/LGPL/MPL에서 이를 요구하고 있다. 이와 같은 경우 오픈소스를 사용하였음을 숨기지 않고 고객에게 그 사실을 정확히 전달할 필요가 있다.

서론(OSS의 의미, 역사, 현황 등)

• OSS의 의의와 역사

통상 오픈소스소프트웨어(Open Source Software)는 자유소프트웨어(Free Software)를 포함한 넓은 의미로 사용되고 있으며, 국내에서도 자유소프트웨어를 포함한 오픈소스소프트웨어를 ‘공개소프트웨어’로 번역하여 사용하고 있다. 하지만 자유소프트웨어와 오픈소스소프트웨어는 추구하는 이념 등에 있어서 미묘한 차이가 있다.

자유 소프트웨어(Free Software)는 리차드 스톨만(Richard Stallman)에 의해 만들어진 개념으로서, 소프트웨어의 이용자에게 해당 소프트웨어를 실행, 복제, 배포할 수 있는 자유, 그리고 소스 코드에 대한 접근을 통해서 이를 학습, 수정, 개선시킬 수 있는 '자유'를 부여하는 소프트웨어이다. 1980년대 초반, MIT의 한 연구소에서 소프트웨어 프로그래머로 일하던 스톨만은 간단한 운영체제의 일종인 Emacs을 포함한 상당수의 유용한 소프트웨어 프로그램을 개발하였다. 하지만 그의 프로그램은 다른 어떤 프로그램과는 전혀 다른 특징을 갖고 있었다. 그것은 바로 그가 개발한 모든 프로그램에는 "이 프로그램의 소스 코드를 동료들과 공유하세요. 그리고 이 프로그램을 통해서 새로운 프로그래밍 방법을 배우고 이 프로그램을 더 좋은 프로그램으로 만들어 주세요. 마지막으로 당신이 작업을 마무리하였으면 이 프로그램을 다시 커뮤니티에 기여해 주시기 바랍니다"라는 메세지가 담겨있는 것이었다. 한 마디로 그는 컴퓨터 프로그래머이자 이상을 꿈꾸는 공상가였다.

스톨만은 소프트웨어 공유의 꿈을 실현시키기 위해 오랫동안 고군분투하였다. 그는 사용자들에게 한푼도 요구하지 않고 그의 소프트웨어를 자발적으로 공유할 수 있었다. 하지만 더 큰 문제는 어떻게 다른 사람들이 개발한 소프트웨어를 공유하도록 하느냐는 것이었다. 결국 그의 결단은 프로그래밍 도구와 기본적으로 필요한 애플리케이션을 모두 갖춘 완전한 운영체제 전체를 개발하는 것이었다. 그래서 사용자들이 공유할 수 있는 무언가를 개발할 수 있도록 이 모든 툴과 애플리케이션을 무료로 공유하는 것이었다. 얼핏보면 이런 그의 꿈은 웃음거리가 될 수도 있었을 것이다. 하지만 스톨만은 그의 꿈을 굽히지 않고 차근차근 준비해 나갔다.

스톨만은 소프트웨어 자유의 꿈을 나눌 수 있는 이들을 찾아 나섰고, 그들과 함께 Free Software Foundation (FSF)을 설립하며 소프트웨어를 개발하기 시작하였다. 그는 우선 새로운 버전의 Emacs을 개발하였고, 당시 최고의 C언어 컴파일러였던 GCC를 공개하였다. 또한 그는 당시 가장 인기있던 운영체제인 Unix의 개발 도구와 거의 동일하게 개발할 수 있는 많은 자원봉사자들을 모집할 수 있었다. 이런 모든 과정은 GNU Project의 일부였다.

1991년까지 GNU Project는 Unix 시스템 기능의 거의 대부분을 개발할 수 있었다. 하지만 운영체제의 핵심인 커널(Kernel) 개발에는 많은 문제점이 남아 있었다. 스톨만과 다른 자원봉사자들은 HURD라 불리는 커널 개발에 전념하였지만 결과는 만족할 만한 수준이 되질 못했다. 반면, 핀란드 헬싱키대학의 학부생이었던 라이누스 토발즈(Linus Torvalds)는 장난감 수준의 아주 단순한 커널을 개발해서 comp.os.minix에 공개하였다. 토발즈의 장난감을 발견한 GNU Project팀은 바로 토발즈와 협력하기 시작하였다. 이후 많은 사람들의 자발적 참여와 토발즈를 포함한 GNU Project팀의 기여 덕분에 오늘날 이 세상에서 세 번째로 가장 많이 이용되는 운영체제가 탄생하였다.

이런 과정을 통해 확립된 자유 소프트웨어는 다음과 같은 4가지 구체적인 이용자들의 자유를 보장하고 있다. 1. 어떠한 목적으로든 프로그램을 실행할 수 있는 자유. 2. 프로그램이 어떻게 작동하는지를 연구하고 그들의 필요에 맞게 수정할 수 있는 자유. 이를 위해서는 소스코드에 접근할 선행 자유가 보장됨. 3. 주변의 이웃들을 돕기 위해서 복제 및 배포할 수 있는 자유. 4. 공동체 전체의 이익을 위해 프로그램을 개선한 후 이를 공중에 공개할 수 있는 자유.

-오픈 소스 소프트웨어-

에릭 레이몬드(Eric Raymond)는 스톨만의 오랫 친구이자 한 때 꽤 괜찮은 소프트웨어 개발자였다. 그는 또한 유명한 "성당과 시장(The Cathedral and The Bazaar)"의 저자이기도 하다. 에릭은 스톨만의 급진적인 사상인 "Free"의 개념을 약간 덜 형식적이고 거부감이 없는 "Open source"로 재포장하였다. 에릭은 오픈 소스 소프트웨어가 되기 위한 아래 10가지 조건을 구체적으로 명시하였다.

1. 자유배포(Free Redistibution): 소프트웨어의 일부 또는 전부가 재배포되지 못하도록 제한을 설정할 수 없다.

2. 소스 코드(Source Code): 프로그램 저작물에는 반드시 소스 코드가 포함되어야 한다. 포함시키지 않을 시는 인터넷에서의 무료 다운로 드 허용 등 소스 코드를 제공받을 수 있는 조치를 취해야 한다.

3. 파생저작물(Derived Works): 프로그램 원저작물의 개작이나 이를 이용한 2차적 프로그램의 창작이 허용되어야 하며 이 창작 프로그램이 최초 프로그램과 같이 동일한 조건하에서 재배포될 수 있어야 한다.

4. 소스 코드의 보전(Integrity of The Author's Source Code): 프로그램을 개작할 목적으로 소스 코드와 패치파일을 함께 제공할 경우 라이센스 안에 소스 코드의 수정을 제한하는 항목을 추가할 수 있다. 다만, 수정된 소스 코드를 이용해 만들어진 프로그램에 대한 자유로운 배포를 허용해야 한다.

5. 개인이나 단체에 대한 차별 금지(No Discrimination Against Persons or Groups): 라이센스는 모든 개인과 단체에 대해서 동일한 기준으로 적용되어야 한다.

6. 사용 분야에 대한 차별 금지 (No Discrimination Against Fields of Endeavor): 라이센스 안에 특정한 분야에서의 사용을 금지하는 제한을 설정해서는 안된다.

7. 라이센스의 배포(Distribution of License): 프로그램에 대한 권리는 반복되는 배포에 따른 별도의 라이센스 승인이나 양도 과정 없이도 프로그램을 배포받은 모든 사람에게 동일하게 적용된다.

8. 라이센스 적용상의 동일성 유지(License Must Not Be Specific to a Product): 라이센스는 반복 배포 과정에서 특정한 배포판에 포함되어 있는 상태로만 유효하지 않고 모든 배포 단계에서 동일한 효력을 갖는다. 즉, 특정 배포판에 포함되어 있던 프로그램을 독립적으로 사용하거나 재배포할 경우에도 해당 프로그램을 배포받은 사람은 프로그램이 포함되어 있던 최초의 배포판 상태에서 발생된 권리와 동일한 권리를 갖는다.

9. 다른 라이센스의 포괄적 수용(License Must Not Restrict Other Software): 라이센스에 오픈소스 소프트웨어와 함께 배포되 는 소프트웨어에 대한 제한을 설정해서는 안된다. 예를 들면, 동일한 매체를 통해서 배포되는 소프트웨어는 모두 오픈소스 소프트웨어여야 한다 등의 제한을 해서는 안된다.

10. 기술 중립적 라이센스 (License Must Be Technology-Neutral): 개별 기술이나 인터페이스에 한정적인 라이센스는 오픈 소스 소프트웨어에 사용되지 않는다.

위의 10가지 조건들을 살펴보면 짐작하겠지만, 오픈소스 소프트웨어는 단순히 소프트웨어의 소스를 공개하여 소스에 대한 접근을 허용하는 것만을 의미하는 것이 아니다. 위의 10가지 조건을 모드 수용해야만 오픈 소스 소프트웨어가 될 수 있는 것이다.

• 최근의 국내외 활용현황

1. 가장 인기있는 웹서버-Apache: 모든 웹사이트에 대한 통계 자료를 수집하는 Netcraft에 따르면, 2007년 4월 기준으로 아파치 웹서버는 58.66%의 시장 점유율을 보이며 웹서버 시장에서 1위를 차지하였다. 2위를 차지한 마이크로소프트의 시장 점유율은 31.13%였다. 아파치는 1996년 시장 점유율 1위를 차지한 후 줄곧 1위 자리를 고수하고 있다.

2. 새로운 서버 시스템에 압도적 리눅스 채택율: 2006년 11월 9일 IBM 발표 자료에 따르면, 83%의 조사 대상 기업들은 향후 자사의 새로운 서버 시스템에 리눅스를 채택할 것이라 밝혔다. 반면, 마이크로소프트의 채택율은 23%에 불과하였다. 또한, 응답자의 2/3 이상은 향후 리눅스 사용 비중을 더욱 늘릴 계획이라고 밝혔다.

3. 이메일 서버의 최고 소프트웨어- Sendmail과 Postfix: 2007년 MailChannel이 발간한 자료에 따르면 이메일 서버 시장에서 모두 오픈 소스 소프트웨어인 Sendmail(12.3%)과 Postfix(8.6%)가 각각 1, 2위를 차지하였다. 그 뒤를 상용 소프트웨어인 Postini(8.5%)와 Microsoft Exchange(7.6%)가 차지하였다.

4. 마이크로소프트의 SQL 서버보다 훨씬 빠른 MySQL의 성장 속도: 2004년 1월 발표된 550여명의 개발자를 대상으로 조사한 Evans Data의 자료에 따르면, MySQL은 매년 약 30%의 성장 속도를 보이는 반면, 마이크로소프트의 SQL 서버와 Access 데이타베이스는 약 6% 성장 속도를 보였다고 한다. 비록 여전히 마이크로소프트가 훨씬 많은 시장 점유율을 차지하고 있지만, 가격, 안정성, 그리고 다른 소프트웨어와의 호환성이 좋은 MySQL이 많은 개발자들의 관심을 끌고있는 것으로 나타났다.

5. 인터넷 익스플로러의 시장 점유율을 잠식하고 있는 오픈 소스 웹 브라우저 Firefox: PC World는 2004년 7월 한달동안 마이크로소프트의 인터넷 익스플로러가 처음으로 시장 점유율을 1%가량 잃은 것으로 나타났다고 밝혔다. 반면, 같은 기간동안 Firefox는 26% 가량 시장 점유율이 증가했다고 밝혔다. 여전히 익스플로러의 시장 점유율이 압도적으로 높지만(94.73%), 익스플로러는 공개된 후 한 번도 시장 점유율이 하락하지 않았다고 한다.

6. 매분기 10억불 이상의 리눅스용 서버 하드웨어 매출: BusinessWeek의 2005년 10월 3일자 기사("Torvalds’ Baby Comes of Age)에 따르면, 하드웨어 회사들은 매분기 10억불 이상의 리눅스용 하드웨어를 판매하는 것으로 나타났다. 반면, 상용 운영체제용 서버 하드웨어 판매량은 지속적으로 감소하고 있다고 밝혔다.

7. 소프트웨어 개발자들의 오픈 소스 소프트웨어 이용 증가: IDC의 2006년 봄 전 세계 116개국 5,000여명의 개발자들을 대상으로 한 조사에 따르면, 오픈 소스 소프트웨어는 전 세계 개발자들의 약 71%가 이용하고 있으며, 54%는 실제 어떤 형태로든 개발/생산되고 있는 것으로 나타났다.

대표적인 자유/오픈소스소프트웨어로는 분야별로 다음과 같은 것을 들 수 있다. (소프트웨어진흥원 자료 참조).

웹 및 응용  : Samba, Apache, Jigsaw, Tomcat, Mozilla, Jboss, PHP, Squid, SendMail, Perl, Eclipse

데이터베이스 : MySQL, PostgreSQL, Firebird, picoSQL, Metakit, HSQL, InterBase

멀티미디어  : MPEG4IP, Darwin, ffmpeg, KOM Streaming

보안  : Snore, prelude, iptables, tripwire

시스템관리  : Webmin, Openpagasus, Bacula, REOBack, storebackup, taper

운영체제  : Linux, FreeBSD

최근 리눅스, 아파치 등 자유/오픈소스소프트웨어의 도입사례가 웹서버 등 기존의 서버분야에서뿐만 아니라 셋탑박스, 휴대폰단말기, PMP 등의 내장(Embeded) 소프트웨어분야에서 꾸준히 증가하고 있다. 그에 따라 General Public License(이하 ‘GPL') 등 자유/오픈소스소프트웨어 라이센스에 대한 관심도 꾸준히 증가하고 있다. 예를 들어 일부 대기업에서는 자유/오픈소스소프트웨어라이센스 가이드라인을 작성하고, 소프트웨어의 개발과정에서 관련 라이센스를 철저히 관리하는 한편, 엔지니어들에 대한 교육을 실시하는 등 다양한 대책을 마련하고 있다. 이와 같은 GPL에 대한 관심은 2006년 말 Sun이 컴파일러(javac), 가상머신(HotSpot), JavaHelp 등 자바(Java) 관련 일부 프로그램을 GPL로 공개하고, 2007년 상반기까지 자바개발도구(JDK) 대부분을 GPL로 공개하겠다는 발표를 하면서 더욱 증대되고 있다.

S/W의 지적재산권과 라이센스

• 소프트웨어관련 지적재산권과 라이센스

• OSS 라이센스: 주요 오픈소스소프트웨어라이센스와 그 含意

오픈소스소프트웨어는 구체적인 소프트웨어제품을 지칭하기보다는 소프트웨어의 개발과 사용에 관한 일정한 유형이라고 할 수 있는데, 그러한 유형의 특징은 오픈소스소프트웨어가 사용하고 있는 라이센스에 잘 나타나 있다. MS, 오라클 등 일반적인 사유소프트웨어업체의 라이센스는 고객이 소프트웨어 권리자에게 대금을 지급하고 소프트웨어의 ‘사용’ 권한만을 허락하는 것이 일반적이다. 따라서 허락을 얻지 않고 소프트웨어를 복제, 배포, 수정하는 행위는 라이센스를 위반하는 것이다. 그러나 오픈소스소프트웨어라이센스는 이러한 사유소프트웨어의 라이센스와는 다르다. 현재 오픈소스소프트웨어라이센스로 가장 중요한 것은 GPL, LGPL이며, 기타 BSD, MIT, Apache 라이센스 및 MPL 등이 있다.

① GPL은 FSF가 소프트웨어에 대한 저작권을 전제로 소프트웨어의 자유로운 공유 및 수정을 보장하고자 만든 것이다. FSF는 대부분의 소프트웨어를 GPL에 의해 배포하였으며, 다른 개발자들도 본인들의 의사에 기하여 자신의 소프트웨어를 GPL 조건으로 배포하기 시작하여, 현재 GPL조건의 소프트웨어가 오픈소스소프트웨어의 가장 많은 부분을 차지하고 있다. GPL의 주요 내용은 소프트웨어에 대한 자유로운 사용, 복제, 배포 및 수정을 허용하고, 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실을 명시해야 하며, 오브젝트코드(Object Code) 또는 실행파일형태로 소프트웨어를 배포하는 경우 소스코드를 함께 배포할 것 등이다. GPL의 가장 큰 특징은 소프트웨어를 수정하거나 새로운 소프트웨어를 링크시키는 경우 수정한 내용이나 링크시킨 소프트웨어도 GPL에 의해 소스코드를 공개해야 한다는 것이다. 이러한 조항을 가리켜 ‘카피레프트(copyleft)' 조항이라고 하며, 이러한 조항에 의해 수정된 프로그램이 계속해서 GPL에 의해 배포되는 효과를 ‘바이러스효과(viral effect)'라고 칭하기도 한다. 이 밖에 자신의 특허를 무료(Royalty-Free)로 제공하는 경우에 한하여 이를 구현한 프로그램을 GPL로 배포할 수 있으며, 제3자의 특허인 경우에도 특허권자가 라이센스를 무료로 제공해야만 해당 특허기술을 구현한 프로그램을 GPL로 배포하는 것이 가능하다는 내용의 규정을 두고 있다.

② LGPL(GNU Lesser General Public License)은 응용프로그램이 LGPL 라이브러리(Library)를 이용하더라도 GPL 또는 LGPL이 아닌 다른 내용의 라이센스가 가능하도록 하여, 결과적으로 해당 응용프로그램의 소스코드를 공개하지 않아도 될 수 있도록 하였다. 그 밖의 나머지 사항들은 대부분 GPL과 동일하다. FSF가 일부 라이브러리에 GPL보다 다소 완화된 형태인 LGPL을 만들어 사용하고 있는 이유는 오픈소스소프트웨어의 사용을 장려하기 위한 전략적인 차원에서이다. 만일 사유소프트웨어 라이브러리와 동일한 기능을 제공하는 라이브러리에 GPL과 같은 엄격한 라이센스를 적용하게 되면, 개발자들이 사용을 꺼려할 것이다. 오히려 이미 널리 사용되고 있는 사유소프트웨어 라이브러리와 동일한 기능을 제공하는 라이브러리는 LGPL로 배포하여 그 사용을 장려하고 사실상의 표준으로 유도하는 한편, 관련된 다른 오픈소스소프트웨어를 보다 더 많이 사용할 수 있도록 하겠다는 것이 FSF의 전략이다.

③ BSD 라이센스는 저작권자의 표시, 보증책임이 없다는 표시만 한다면 누구든지 소스코드 또는 바이너리코드의 사용, 수정, 배포가 허용된다. 이는 BSD관련 프로젝트가 주로 미국 정부에서 제공한 재원으로 운영되었기 때문이다. 아울러 프로그램을 수정한 경우 수정된 프로그램에 대한 소스코드의 공개를 요구하지 않기 때문에, 소스코드를 공개하지 않는 사유소프트웨어개발자들이 BSD 라이센스로 배포되는 소프트웨어를 자신의 제품에 자유롭게 사용할 수가 있다. MIT, Apache 라이센스도 약간의 차이가 있긴 하지만 대체로 BSD 라이센스의 내용과 동일하다.

④ MPL은 웹브라우저 시장을 장악하고 있던 Netscape가 MS의 익스플로러에 밀려 시장점유율이 크게 떨어지자 이를 극복하기 위한 방안으로 웹브라우저의 소스 코드를 공개하기로 결정하고 만든 라이센스이다. 이를 통해 Netscape는 오픈소스소프트웨어개발공동체가 제공하는 이점을 받아들이는 한편, Netscape 나름대로의 비즈니스 전략(예컨대 서버 제품에 수정된 코드를 적절히 이용한다는 전략)을 만들어 가고자 하였다. 라이센스의 주요 내용은 소프트웨어의 자유로운 사용, 복제, 배포, 수정을 허용하고, 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 MPL에 의해 배포된다는 사실을 명시하도록 한다는 점에서 다른 오픈소스라이센스와 비슷하다. 하지만 MPL 코드를 수정한 부분은 다시 MPL에 의해 배포하게 하고 있다는 점에서 카피레프트(copyleft) 조항을 두고 있다고 볼 수 있다. GPL과의 차이점은 MPL 코드와 다른 코드를 결합하여 프로그램을 만들 경우 MPL 코드를 제외한 결합 프로그램에 대한 소스는 공개할 필요가 없다는 점이다. 따라서 소스코드를 적절한 형태로 제공하는 경우, 실행파일에 대한 라이센스는 MPL이 아닌 다른 것으로 선택가능하다. 이 밖에 특허권의 처리에서도 약간의 차이가 있는데, 이는 제4장에서 자세히 살펴본다.

이상에서 살펴본 오픈소스소프트웨어라이센스들의 공통점은 소스코드를 공개하여 모든 사람들이 자유롭게 사용할 수 있게 할뿐만 아니라, 프로그램의 복제, 배포, 수정의 자유를 인정하고 있다는 점이다. 이와 같은 특징은 OSI가 요구하고 있는 오픈소스소프트웨어정의(open source software definition)요건을 통해서도 확인할 수 있다. 동 요건에 의해 오픈소스소프트웨어라이센스로 인정받기 위해서는 소프트웨어의 자유로운 배포를 허용해야 하며, 소스코드를 공개하고, 이를 통해 프로그램을 수정하여 2차적 프로그램을 작성하는 것을 허용해야 한다. 뿐만 아니라 개인이나 단체에 대해 차별을 해서는 안되며, 사용분야에 대한 차별을 둘 수도 없다.

오픈소스소프트웨어라이센스에 대한 이와 같은 요구는 첫째, 해당 소프트웨어에 대한 기술을 완전히 공개하도록 한다. 소프트웨어에 관한 기술공개는 응용프로그램인터페이스(API), 통신프로토콜 등을 통해 다양하게 이루어질 수 있는데, 이 중 소스코드에 의한 공개는 소프트웨어의 모든 것을 공개한다고 해도 과언이 아닐 정도의 완전한 공개이다. 소프트웨어 기술의 공개와 상호공유는 인터넷 등의 네트워크를 기반으로 한 최근의 소프트웨어 발전추세에 있어서 필수적이다. MS 등 일부 사유소프트웨어기업까지 자사의 소스코드를 일부 공개하고 있는 상황은 이를 잘 말해주고 있다. 오픈소스소프트웨어라이센스가 가지는 두 번째 의의는 소프트웨어의 복제, 배포, 수정의 자유를 허락한다는 점이다. 이러한 허락은 소프트웨어에 대해 컴퓨터프로그램보호법 혹은 저작권법상 가지는 재산권적 권리를 포기함으로써 사회전체의 공유재산으로 기부하겠다는 의미이기도 하다. 이러한 측면에서 파악할 때 오픈소스소프트웨어는 리눅스, 아파치 등 특정한 제품 이상의 것, 즉 공공의 소유에 제공된 소프트웨어로 이해할 수 있다. 제공의 정도는 GPL, BSD, MPL 등 라이센스에 따라 차이가 있다.

OSS와 일반 S/W의 차이

• 개발동기

소프트웨어는 비배제성의 특성을 지니고 있기 때문에 무임승차의 문제가 발생하고, 그 결과 지적재산권에 의한 보호가 없다면 이윤을 추구하는 기업들은 소프트웨어 개발에 투자를 하지 않을 것이라는 결론에 도달했었다. 하지만 오픈소스소프트웨어의 비약적인 발전은 이와 같은 ‘이윤’의 동기로서 설명하기가 어려우며, 그와 같은 동기가 있다고 하더라도 사유소프트웨어의 경우보다 약하다.

해커사회에 대한 인류학자로 평가받고 있던 에릭 레이몬드는 오픈소스공동체의 중요한 특성을 ‘기부문화(gift culture)’로 파악하면서, 개인들이 이러한 공동체에 참여하고 있는 동기를 利他主義(altruism)와 相互主義(reciprocity)에서 찾고 있다. 하지만 일련의 경제학자들은 이를 부수적인 요소로 파악하면서, 신호효과(Signaling Effect)를 가장 중요한 동기로 파악하고 있다. 이 때 ‘신호효과’란 어떤 개발자가 중요한 결함 또는 문제를 해결하거나, 성능이 뛰어난 소프트웨어를 개발할 경우, 다른 개발자들이나 사용자들에게 자신의 능력을 알릴 수 있음을 의미한다. 그 결과 향후 높은 보수를 보장하는 좋은 직장을 구하는 등 금전적 이익을 취할 수 있기 때문에 개발자들이 오픈소스공동체에 참여하게 된다는 것이다.

한편 초기의 오픈소스소프트웨어운동과는 달리 현재는 IBM, HP, RedHat, Ximian 등 기업들이 적극적으로 지원하고 있는데, 신호효과만으로는 이들 기업들의 지원동기를 설명하긴 어렵다. 이에 대해 기업들간 약간의 차이가 존재하긴 하지만, 대체적으로 오픈소스소프트웨어와 보완재관계에 있는 하드웨어(IBM, Sony, Nokia 등), 소프트웨어(MySQL AB, IBM, Ximian 등) 및 서비스(RedHat 등)를 판매하기 위한 것으로 설명가능하며, 소프트웨어 개발부문의 효율성 때문에 지원하고 있다는 지적도 있다.

신호효과 또는 보완재판매를 위해 소프트웨어를 개발한다는 사실은 소프트웨어에 대한 지적재산권 보호의 필요성을 약화시킨다. 즉 소프트웨어가 비배제성을 지니고 있음에도 불구하고 자발적 참여에 의해 소프트웨어 생산의 문제가 해결된다는 것이다. 하지만 사유소프트웨어회사가 새로운 제품을 개발함에 따라 얻게 되는 이익과 비교할 때, 오픈소스소프트웨어개발자들이 신제품개발을 통해 얻게 되는 인센티브는 상대적으로 적다. 따라서 매우 혁신적인 신제품의 개발은 오픈소스소프트웨어보다는 사유소프트웨어에 의해 이루어질 가능성이 높다는 지적도 있다.

• 시장의 차이

오픈소스소프트웨어는 운영체제, 서버응용소프트웨어 등 전문가들의 수요가 많은 전문가시장(expert market)을 중심으로 발전해 온 반면, 사유소프트웨어들은 최종소비자용의 응용프로그램분야, 즉 소비자시장(consumer market)에서 많이 개발되었다. 사유소프트웨어회사들은 자사 제품의 잠재적인 수요에 민감하다. 수요가 많은 제품일수록 가치가 높기 때문이다. 따라서 시장조사를 통해 소비자들의 요구사항을 조사하고 이를 제품에 반영하기 위해 노력한다. 소비자시장에 내놓을 소프트웨어를 개발하기 위해서는 소비자들의 기호나 성향을 세밀하게 분석할 필요가 있다. 예를 들어 회계프로그램이나 게임프로그램 등을 개발하기 위해서는 IT 전문가뿐만 아니라 회계 또는 게임에 관한 전문가와의 협력이 필요하다.

사유소프트웨어회사들과는 달리 오픈소스소프트웨어개발자들은 일반적으로 그러한 활동에 참여하려는 경우가 드물다. 오픈소스소프트웨어의 경우 이용자들이 대부분 전문가들이며, 이들은 직접 자신들의 요구사항에 맞게 소프트웨어를 수정할 능력을 가지고 있다. 그 결과 오픈소스개발자들은 이용자들의 요구사항에 덜 민감하게 반응한다. 또한 대규모의 수요가 곧바로 이익으로 연결되지 않기 때문에, 굳이 대규모시장이 있는 제품을 개발할 인센티브를 갖지 않는다. 이에 따라 오픈소스소프트웨어는 운영체계, 파일서버, 웹서버, 메일서버, 개발툴 등 뛰어난 기술이 요구되는 분야에서 유용한 것으로 나타난 반면, 기술보다는 사용의 편리성을 중요시하는 일반 소비자들을 위한 제품부분에서는 상대적으로 미약하였다. 하지만 오픈소스 제품들은 사유소프트웨어개발자들에게는 계속해서 경쟁상의 압력으로 작용할 것으로 보이며, 특히 오픈소스소프트웨어의 생산방법이 기술적 전문가들에게 유용하기 때문에 그러한 압력은 계속해서 지속될 것으로 보인다.

• 독점적 시장의 보완

구체적인 제품의 내용에 따라 약간씩 다르겠지만, 일반적으로 소프트웨어는 요구사항분석, 설계 및 코딩, 테스트, 패키징 등의 제작과정을 통해 만들어진 후 대량복제를 통해 소비자에게 판매된다. 이를 비용측면에서 보면, 소프트웨어는 상품의 제작과정에 대부분의 비용이 들고, 복제 및 배포에는 상대적으로 적은 비용이 소요된다. 따라서 소프트웨어시장은 생산이 증가함에 따라 제품당 평균비용은 점차 감소하게 되어 수확체증의 법칙에 의한 규모의 경제가 잘 나타난다고 볼 수 있다. 한편 소프트웨어는 어느 상품이 다른 상품과 연결되어 네트워크의 일부로서 사용되는 결과 이에 대한 소비자의 가치평가가 그 네트워크의 크기, 즉 이용자 수에 의해 영향을 받게 되는데, 이러한 효과를 네트워크효과라고 한다. 네트워크효과는 해당 소프트웨어와 보완적인 관계에 있는 상품(하드웨어, 운영체계, 응용프로그램 등)과의 관계에서도 나타나는데, 이를 특히 간접 또는 2차적 네트워크 효과라고 한다. 규모의 경제와 네트워크효과는 이론적으로 소프트웨어시장에서 독점이 형성되기 쉽다는 것을 의미하는데, 이를 반영하듯 현실에서도 PC 운영체계시장에서의 MS, DBMS(Database Management System)시장에서의 오라클, ERP(Enterprise Resource Planning)시장에서의 SAP 등 독과점 기업이 개별 시장을 지배하고 있다.

오픈소스소프트웨어는 소프트웨어시장의 경쟁정책적 관점에서 볼 때 중요한 의미를 지니고 있다. 많은 프로그램들의 공통기반이 되는 부분에 대한 소스코드가 공개되고 이를 자유로이 이용할 수 있다면, 새로이 소프트웨어시장에 진출하는 기업은 공통기반이 되는 부분들은 오픈소스소프트웨어를 자유롭게 이용하고, 이를 기반으로 새롭게 추가되는 기능에 집중하여 신제품을 개발할 수 있다. 한편 네트워크효과에 의한 독점의 폐해를 막기 위해서는 상호호환성이 확보되어야 한다. 오픈소스소프트웨어는 소스코드가 공개되고 이를 자유롭게 이용할 수 있다는 측면에서 상호호환성 확보가 용이하다. 물론 시장에서 사유소프트웨어가 사적 표준을 통해 상호호환성을 확보하는 경우도 많지만, 오픈소스소프트웨어에 비하면 결코 쉽지 않으며 비용도 만만치 않다. 요약하자면 오픈소스소프트웨어는 규모의 경제와 네트워크효과로 독점화된 소프트웨어시장의 진입장벽을 낮추고 새로운 기업들의 참여를 가능하게 함으로써 소프트웨어시장의 경쟁을 촉진시키는 것에 크게 기여할 수 있다.

• 기타

사유소프트웨어는 소스코드를 공개하지 않고 바이너리코드만 배포하기 때문에, 소비자들은 소프트웨어의 버그를 수정하거나 자신들의 특수한 목적에 맞게 개량하는 것이 불가능하다. 반면 오픈소스소프트웨어는 공개된 소스코드를 통해 사용자들이 쉽게 수정할 수 있으며, 개량된 제품을 개발할 수 있다. 또한 이론적으로 오픈소스는 사유소프트웨어보다 ‘프라이버시’보호에 유리하다. 이는 소스코드가 공개되어 있기 때문에 이용자들을 감시할 수 있는 ‘스파이’ 프로그램을 삽입하기 어렵기 때문이다. 하지만 현실적으로 사유소프트웨어회사들이 그러한 행위를 하고 있다는 증거가 있기 전까지는 이론상의 장점으로만 볼 수 있을 뿐이다. 나아가 오픈소스소프트웨어는 대부분 무료로 사용할 수 있기 때문에 소위 ‘정보격차’를 해소하는데 도움이 될 수 있다.

반면 오픈소스의 단점으로는 금전적인 이익을 얻기가 어렵다는 점, 그에 따라 소비자의 기호나 성향을 고려하기가 어렵다는 점, 이용자들이 자유롭게 수정하는 것이 가능하기 때문에 소프트웨어의 ‘분기(fragmentation)’가 일어나 상호 호환되지 않는 프로그램이 개발될 수 있다는 점 등이 지적되고 있다.

주요 OSS 라이센스

GPL

GPL 제정의 배경과 의미

자유소프트웨어(Free Software)는 리차드 스톨만과 FSF에 의해 만들어진 개념으로서, 소프트웨어의 이용자에게 해당 소프트웨어를 실행, 복제, 배포할 수 있는 자유, 그리고 소스코드에 대한 접근을 통해서 이를 학습, 수정, 개선시킬 수 있는 자유를 부여하는 소프트웨어이다. 자유소프트웨어가 추구하는 자유는 구체적으로 ⅰ) 어떠한 목적으로든 프로그램을 실행할 수 있는 자유, ⅱ) 프로그램이 어떻게 작동하는지를 연구하고 이용자의 필요에 맞게 수정할 수 있는 자유, ⅲ) 주변의 이웃들을 돕기 위해서 프로그램을 복제 및 배포할 수 있는 자유, ⅳ) 커뮤니티 전체의 이익을 위해 프로그램을 개선한 후 이를 공중에 공개할 수 있는 자유를 의미한다. 이와 같은 내용의 자유를 실질적으로 보장하기 위해 리차드 스톨만은 자신의 소프트웨어에 대한 저작권을 확보한 뒤, 이러한 권리를 전제로 해당 저작물을 일정한 조건에 의해 사용하도록 허락하는 GPL을 만들었다. 1989년 제1판이 발표된 이래 FSF는 대부분의 소프트웨어를 GPL에 의해 배포하였으며, 다른 많은 자유/오픈소스소프트웨어 개발자들도 본인들의 의사에 기하여 자신이 만든 소프트웨어를 GPL 조건으로 배포하였다. 그 결과 현재 GPL조건의 소프트웨어가 자유/오픈소스소프트웨어의 가장 많은 부분을 차지하고 있다.

GPL 제3판의 개정방향에 대한 논의가 진행되는 가운데, 모글렌 교수는 GPL은 단순한 라이센스 이상의 다양한 의미를 지닌 것으로 파악하고, GPL의 개정시 이러한 요인들을 고려하여야 한다고 주장하였다. 그에 따르면 GPL 자체가 리차드 스톨만이 만든 저작물에 해당한다. 또한 GPL은 하나의 라이센스이며, 자유/오픈소스소프트웨어가 전세계적으로 확산되면서 전세계적으로 사용되는 라이센스이다. 이와 더불어 GPL은 다음과 같이 보다 넓은 의미를 지니고 있다고 주장하였다.

첫째, GPL은 자유/오픈소스소프트웨어 커뮤니티에서 행위규범(Code of Conduct)으로서의 의미를 지닌다. GPL은 자유/오픈소스소프트웨어에 대한 라이센스이기 때문에 자유/오픈소스소프트웨어를 복제, 수정 및 수정하려는 사람들은 이를 지켜야 한다. 즉 GPL은 자유/오픈소스소프트웨어의 이용에 관한 행위규범이 된다. 그 결과 자유/오픈소스소프트웨어를 둘러싼 시장에서의 행위가 GPL의 내용에 의해 영향을 받게 된다. 예를 들어 소스코드를 배포하는 방식이 GPL 제3조에 의해 영향을 받게 되고, 특허권이 관련된 자유/오픈소스소프트웨어의 이용에 관한 행동들이 GPL 제7조의 영향을 받는다. 그 결과 GPL의 개정작업은 하나의 라이센스를 개정하는 것 이상의 의미, 이를테면 시장의 표준을 제정하거나 "모범기준(best practices)"를 만드는 것과 비슷한 작업으로 볼 수 있다.

둘째 GPL은 자유소프트웨어운동의 헌법 또는 헌장으로서의 의미를 지닌다. FSF는 기술적인 의미의 ‘소프트웨어’를 만들거나 지원하는 것 이상의 의미를 자유소프트웨어에 두고 있다. 그들은 이용자들이 소프트웨어를 실행, 복제, 배포, 연구, 변경 및 개선할 수 있는 ‘자유’를 추구하는 운동(Movement)을 하고 있다. 그 결과 이들에게 있어서 GPL은 자유소프트웨어가 가져올 세계의 헌법 또는 헌장(Constitution)의 지위를 획득한다.

• GPL의 이념과 원칙

자유소프트웨어가 추구하는 자유는 구체적으로 ⅰ) 어떠한 목적으로든 프로그램을 실행할 수 있는 자유, ⅱ) 프로그램이 어떻게 작동하는지를 연구하고 이용자의 필요에 맞게 수정할 수 있는 자유, ⅲ) 주변의 이웃들을 돕기 위해서 프로그램을 복제 및 배포할 수 있는 자유, ⅳ) 커뮤니티 전체의 이익을 위해 프로그램을 개선한 후 이를 공중에 공개할 수 있는 자유를 의미한다. GPL의 궁극적인 목표도 이와 같은 자유를 실질적으로 보장하기 위한 것으로 볼 수 있으며(GPL 서문), 구체적으는 다음과 같은 원칙적인 내용과 조건을 담고 있다.

첫째, GPL 조건의 프로그램은 아무런 제한 없이 ‘사용’ 또는 ‘실행’할 수 있다(GPL 제0조 후단). 다시 말해 복제, 배포행위 이외에 프로그램을 단순히 이용하거나 실행하는 행위는 아무런 조건없이 누구나 자유롭게 할 수 있다.

둘째, GPL 조건의 프로그램을 수정하지 않고 소스코드형태로 배포하고자 하는 경우에는 저작권표시(copyright notice), 워런티가 없다는 표시(disclaimer of warranty), 그리고 해당 프로그램이 GPL에 의해 배포되고 있다는 표시를 하고, 동 프로그램과 함께 GPL 원문을 제공하기만 하면 GPL 프로그램을 자유롭게 ‘복제’, ‘배포’할 수 있다(GPL 제1조 전단). 이 때 이용자의 선택에 따라 복제물 제공에 대한 비용을 청구할 수 있으며, 유료로 워런티를 제공할 수 있다(GPL 제1조 후단).

셋째, GPL 조건의 프로그램을 수정한 2차적프로그램을 작성한 후 이를 배포하고자 하는 경우, 저작권표시 등 제1조의 의무와 함께, 수정했다는 사실 및 수정일자를 명시하고, 2차적프로그램 전체를 GPL에 의해 다시 제공할 것을 요구하고 있다(GPL 제2조).

넷째, GPL 조건의 프로그램을 오브젝트(Object) 코드나 실행파일 형태로 배포하고자 하는 경우에는 소스코드를 함께 제공하거나, 또는 최소 3년 동안 배포에 필요한 최소한의 비용만을 받고 소스코드를 제공하겠다는 문서(written offer)와 함께 제공하여야 한다(GPL 제3조).

이상과 같은 조건들을 준수하지 못할 경우 GPL에 의해 부여된 라이센스는 자동적으로 종료되며(GPL 제4조), 그럼에도 불구하고 계속해서 GPL 조건의 프로그램을 복제, 수정, 배포하는 경우에는 계약위반 또는 프로그램저작권침해의 책임을 지게 된다(GPL 제5조).

GPL의 주요쟁점

• 2차적프로그램의 작성과 소스코드의 제공범위

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

이와 같은 GPL의 특징은 다른 자유/오픈소스소프트웨어 라이센스와 비교할 때 명확히 드러난다. 예를 들어 LGPL(Lesser GNU Public License)은 일정한 요건을 충족시키는 경우 LGPL 라이브러리(Library)를 이용하는 프로그램(Work that uses the Library), 다시 말해 컴파일 또는 링크를 통해 LGPL 라이브러리와 함께 작동하도록 설계된 프로그램들을 배포할 경우에는 소스코드를 제공하지 않아도 된다.(LGPL 제5조). MPL(Mozilla Public License)도 한편으로는 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 조건에 의해 소스코드를 제공하는 경우에는 원칙적으로 제공된 소스코드에 의해 실행파일을 생성할 수 있도록 모든 소스코드를 제공해야 한다. 따라서 실행파일에 포함된 모든 모듈들의 소스코드, 관련된 인터페이스 정의파일, 그리고 실행물의 컴파일과 설치를 제어하는데 사용된 스크립트 등을 모두 제공해야 한다(GPL 제3조). 다만 일반적으로 실행파일이 실행될 운영체제의 주요 컴포넌트(Component; 예를 들면 컴파일러나 커널 등)에 (소스코드나 바이너리 형태로) 포함되어 배포되는 구성 요소들은 소스 코드의 배포 대상에서 제외시킬 수 있다(GPL 제3조).

• 특허권의 취급

자유소프트웨어진영이 소프트웨어특허에 대해 가지는 시각은 GPL 서문에 잘 나타나 있다. 주요 내용은 현재 소프트웨어특허로 인하여 자유소프트웨어가 끊임없이 위협을 받고 있는 상황이며, 만약 자유소프트웨어의 재배포자들이 개별적으로 특허를 취득하는 경우 해당 프로그램이 사유(proprietary)소프트웨어가 될 가능성이 있으므로, FSF는 이러한 문제에 대처하기 위해서 GPL 조건의 소프트웨어를 이용하는 모든 사람들이 무료로 자유롭게 사용할 수 있는 특허만을 자유소프트웨어에 포함시키고자 한다는 것이다. 그리고 GPL 제7조에서도 특허권에 관한 내용이 언급되고 있는데, 법원의 판결이나 특허권 침해에 대한 주장 또는 그 밖의 사유에 의해 GPL의 조건과 배치되는 상황이 발생할 경우, 법원의 명령이나 합의 등에 의해서 부과되는 조건과 GPL 조건을 동시에 만족시키는 것이 불가능한 경우 프로그램을 배포할 수 없다고 규정하고 있다(GPL 제7조). 이와 같은 내용을 통해 GPL과 특허권의 관계는 다음과 같이 정리할 수 있다.

첫째, 비록 자유소프트웨어진영이 소프트웨어특허에 대해 반대하고 있긴 하지만, 소프트웨어특허의 인정여부는 결국 각국의 입법 또는 법해석에 관한 문제이다. 따라서 GPL의 차원에서는 GPL 조건의 소프트웨어에는 관련 특허가 부여되었거나 앞으로 부여될 수 있다는 현실을 받아들일 수밖에 없다.

둘째, 특허권자 자신이 특허기술을 구현한 소프트웨어를 GPL로 배포하였다면, GPL 서문이나 제7조의 해석상, GPL 조건을 준수하면서 해당 소프트웨어를 사용하는 이용자에게는 특허권을 주장하지 않겠다는 서약을 한 것으로, 또는 특허라이센스를 묵시적으로 허락한 것으로 해석할 수 있다.

셋째, 소프트웨어에 제3자의 특허기술이 포함된 경우, 특허권자가 모든 GPL 이용자에게 무상의 라이센스를 제공하는 경우에만 해당 소프트웨어를 GPL로 배포할 수 있다. 다시 말해 프로그램의 복제물을 제공받은 임의의 제3자가 해당 프로그램을 무상으로(royalty-free) 사용하거나 재배포할 수 없는 경우, 해당 소프트웨어를 GPL로 배포하는 것은 불가능하다.

• 다른 라이센스와의 양립성(Compatibility)

소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드 또는 모듈을 재사용하거나 결합하는 경우가 많은데, 결합되는 각 모듈의 라이센스가 상호 상충되는 경우가 있다. 예컨대 MPL 조건의 A모듈과 GPL 조건의 B모듈을 결합하여 ‘A+B’라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 ‘A+B’의 A부분을 MPL로 배포할 것을 요구하는 반면, GPL은 ‘A+B’ 전체를 GPL로 배포할 것을 요구하기 때문에, ‘A+B’프로그램을 배포하는 것은 불가능하게 된다. 이러한 문제를 가르켜 라이센스의 양립성(Compatibility) 문제라고 한다. FSF는 GPL과 양립가능한 라이센스와 그렇지 못한 라이센스를 명확히 구분하여 제시하고 있다.

GPL과 기타의 자유/오픈소스소프트웨어 라이센스와의 양립성 문제는 3가지 이유에서 발생한다. 첫째, GPL은 수정된 프로그램을 GPL로 다시 배포할 것을 요구하고 있다. 다시 말해 GPL은 카피레프트(copyleft) 라이센스이다. 둘째, GPL은 프로그램 이용자들의 권리를 제한하는 어떠한 제한사항도 추가하지 못하도록 하고 있다. 셋째, 현재 이용되고 있는 많은 자유/오픈소스소프트웨어 라이센스들이 GPL이 금지하는 사항들을 포함하고 있다. 이러한 이유 때문에, 만약 어떤 이용자가 GPL과는 다른 조건을 가진 라이센스에 의해 배포되는 프로그램을 GPL 프로그램과 결합시킬 경우, 결합된 프로그램은 GPL의 조건을 충족시킬 수 없다.

양립성문제는 자유/오픈소스소프트웨어 진영에 심각한 문제점을 제기하였으며, 이를 해결하기 위한 노력도 다양하게 진행되고 있다. 예를 들어 모질라 프로젝트(Mozilla.org)에서는 프로젝트의 결과물을 MPL, GPL, LGPL의 3가지(triple) 라이센스로 배포하는 새로운 라이센스 정책을 채택하여, 라이센스의 양립성과 관련된 불확실성을 제거하고 모질라 코드를 GPL 또는 LGPL 기반의 응용프로그램에 사용할 수 있도록 하였다. Trolltech도 Qt 라이브러리에 대한 오픈소스소프트웨어라이센스인 QPL과 GPL의 양립성 문제를 해결하기 위하여 QPL 및 상용라이센스 이외에 GPL을 추가하는 정책을 취하고 있다.

• GPL 위반에 대한 감시와 制裁

GPL 소프트웨어의 이용자가 GPL 조건을 준수하고 있는지의 여부는 자유/오픈소스소프트웨어의 커뮤니티나 이용자들이 상시 감시하고 있으며, 특히 FSF와 gpl-violations.org가 가장 활발하게 활동하고 있다. GPL 위반사항을 발견하면 통상 위반한 개인이나 기업에게 위반사항을 통지하고 이를 시정할 것을 요구한다. 대부분의 경우 GPL을 위반했음을 인정하고 관련 소스코드를 제공하는 등의 시정조치를 취하지만, 경우에 따라서는 이를 거부하기도 한다. 이러한 경우에는 관련 GPL 소프트웨어에 대한 권리를 가진 개발자, 또는 이들로부터 권리를 위임받은 FSF나 gpl-violations.org가 법원에 소송을 제기하게 된다.

소송단계에서 종종 중요한 쟁점중의 하나로 거론되는 것은 GPL이 계약으로서 성립되었는가의 여부이다. 이러한 쟁점은 통상 쉬링크랩(shrink-wrap) 라이센스나 클릭랩(click-wrap) 라이센스가 유효한 계약으로 성립되었는가의 문제와 비슷한 것으로 볼 수 있다. 하지만 GPL 관련소송에서 GPL 위반자가 GPL이 계약으로 성립되지 않았다는 주장을 하게 되면, 해당 소프트웨어를 무단으로 사용한 책임, 즉 저작권침해의 책임을 지게 되므로, 이와 같은 주장을 할 실익이 크지 않다.

LGPL

BSD/MIT/Apache

MPL/EPL/CPL

주요 쟁점과 라이센스간 비교

• 소스공개의 범위
• 특허권의 취급

FSF를 비롯한 오픈소스소프트웨어 개발자들은 일반적으로 소프트웨어 특허를 반대하고 있다. 이들 주장의 핵심은 GPL의 서문에 잘 나타나 있다. 그에 따르면 ‘현재 소프트웨어 특허로 인하여 자유 소프트웨어가 끊임없이 위협을 받고 있는 상황이며, 만약 자유 소프트웨어의 재배포자들이 개별적으로 특허를 취득하는 경우 해당 프로그램이 사유소프트웨어가 될 가능성이 있으므로, FSF는 이러한 문제에 대처하기 위해서 어떠한 특허에 대해서도 그 사용 권리를 모든 사람들에게 자유롭게 허용하는 경우에 한해서만 자유 소프트웨어와 함께 사용할 수 있다’고 한다.

GPL, MPL 등이 특허를 어떻게 처리하고 있는가는 ⅰ) 라이센서(Licensor)의 특허인 경우, ⅱ) 제3자의 특허인 경우, ⅲ) 라이센시(Licensee)의 특허인 경우 3가지로 나누어 살펴볼 수 있다. 앞에서 살펴본 라이센스 중 LGPL은 특허와 관련해서는 GPL과 동일하게 규정하고 있으며, BSD는 특허에 관한 규정을 두고 있지 않기 때문에 이하에서는 생략한다.

① 라이센서(Licensor)의 특허인 경우

소프트웨어에 대해 저작권을 가지고 있는 주체가 특허권을 함께 가지고 있는 경우이다. GPL은 법원의 판결이나 특허권 침해에 대한 주장 또는 그 밖의 사유에 의해 GPL의 조건과 배치되는 상황이 발생할 경우, 법원의 명령이나 합의 등에 의해서 부과되는 조건과 GPL 조건을 동시에 만족시키는 것이 불가능한 경우 프로그램을 배포할 수 없다고 규정하고 있다(GPL 제7조). 예컨대 특정 특허 라이센스가 프로그램의 복제물을 직접 또는 간접적인 방법으로 제공 받은 임의의 제3자에게 해당 프로그램을 무상으로(royalty-free) 재배포할 수 있게 허용하지 않는 경우, 이를 GPL과 특허 라이센스를 동시에 만족시키는 유일한 방법은 프로그램의 배포를 하지 않는 것이다. 즉 특허를 무상으로 자유롭게 사용할 수 있도록 하지 않는 한 그 특허를 구현한 프로그램을 GPL로 배포할 수 없다고 한다. 이를 반대로 해석하면 특허권 소유자가 자신의 특허를 프로그램으로 구현하여 GPL로 배포한다는 것은 해당 프로그램과 관련한 자신의 특허를 무상으로 사용할 수 있게 한다는 묵시적 허락으로 볼 수 있다. 반면 최근 이루어지고 있는 GPL의 개정 초안에서는 이를 명시적으로 규정하고 있다.

MPL에서도 이를 명문으로 규정하고 있다. 그 내용을 살펴보면 MPL에 의해 프로그램을 배포하기 위해서는 특허 라이센스도 함께 부여하는 것으로 규정하고 있다(MPL 2.1(b), 2.2(b)). 그러나 원코드(Original Code)에서 삭제된 코드 또는 분리된 코드 등에 대해서는 라이센스가 허용되지 않는다(MPL 2.1(d), 2.2(d)). 최근 개정된 Apache 라이센스 version 2.0도 MPL과 마찬가지로 영구적, 비배타적, 무상의 특허라이센스를 부여한다는 규정을 추가하였다.

② 제3자의 특허인 경우

특허 소유자와 이를 프로그램으로 구현한 주체가 다른 경우인데, 역시 GPL 제7조에 의하면 특허 소유자가 무상(Royalty-Free) 조건의 특허 라이센스를 허용하지 않는다면 구현자는 이 프로그램을 GPL 조건으로 배포할 수 없다. 예를 들면 甲회사가 乙회사의 특허기술을 바탕으로 A라는 프로그램을 만들었을 경우, 乙회사가 그 특허를 모든 사람에게 무상으로 허용하지 않는다면, 설사 甲회사가 라이센스를 무료로 받았다고 할지라도 A프로그램을 GPL 조건으로 배포할 수 없다. 한편 특허 또는 저작권은 특허 등을 등록한 국가 내에서만 효력을 가진다. 이러한 상황을 고려하여 GPL 제8조는 특허 또는 저작권이 있는 인터페이스에 의해 특정 국가에서 프로그램의 사용이나 배포가 제한되는 경우, 해당 프로그램의 원 저작권자는 그러한 국가를 배제하는 지리적 배포제한(geographical distribution limitation)에 관한 사항을 추가할 수 있음을 밝히고 있다. 예를 들면, 한국에서 등록된 특허기술을 구현한 프로그램을 GPL로 배포하려고 할 때, 그 특허권자가 자유로운 사용을 허락하지 않는 경우 한국을 제외하고 나머지 지역에서 사용 가능하다는 조건으로 해당 프로그램을 GPL로 배포할 수 있다.

MPL은 제3자의 특허인 경우 MPL 3.4에 자세한 규정을 두고 있는데, GPL과는 차이가 있다. GPL의 경우 제3자의 특허가 있는 경우 그 특허가 무상으로 자유로이 사용될 수 없는 한 GPL로 배포하지 못하도록 하고 있다. 그러나 MPL의 경우 원칙적으로 이를 허용하되, ‘LEGAL’이라는 이름의 파일을 추가하여 어떠한 특허가 문제되고 있는지, 어떤 사람이 클레임을 제기하고 있는지에 대한 사항을 자세히 기록하도록 하고 있다. 만약 이미 프로그램을 배포한 후에 그러한 사실을 안 경우에는 즉시 LEGAL 파일을 변경하고 메일링 리스트나 뉴스그룹을 통해 즉시 알려야 한다.

③ 라이센시(Licensee)의 특허인 경우

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

• Compatibility의 문제
• DRM관련 쟁점

GPL version 3

개정의 배경과 경과

1991년 배포된 GPL 제2판은 2007년 현재까지 16년 동안 수정 없이 사용되고 있다. 소프트웨어관련 기술과 이를 둘러싼 시장, 제도의 변화속도에 비추어보면 상당히 오랜 기간 동안 개정되지 않고 사용된 것으로 평가할 수 있다. 하지만 1990년대 초반 자유/오픈소스소프트웨어가 널리 사용되기 이전에 만들어진 GPL 제2판은 최근의 변화된 상황에서 조금씩 그 한계를 드러내고 있다. 예컨대 자유소프트웨어운동이 미국에서 시작되었으며 GPL 제2판도 미국의 법제도를 기반으로 만들어졌는데, 현재 자유/오픈소스소프트웨어 및 GPL은 전세계적으로 사용되고 있으며, 그에 따라 각국 법제도의 차이를 반영할 필요성이 제기되고 있다. 이밖에 소프트웨어특허의 확대와 그에 따른 위험의 증가, 자유/오픈소스소프트웨어 라이센스들의 증가와 양립성 문제, DRM 기술의 확대적용과 법에 의한 보호, 네트워크서버기반 소프트웨어의 증가, P2P 등 새로운 기술의 등장 등 일련의 환경변화로 GPL 개정의 필요성은 더욱 증대되었다.

하지만 자유/오픈소스소프트웨어와 GPL의 이용자가 많아질수록 개정의 필요성이 증대된 만큼 개정작업은 더욱 복잡해졌다. 1991년 GPL 제2판이 발표될 당시 리차드 스톨만이 몇몇 법률가와 개발자들로부터 의견을 수렴하긴 했었지만, GPL의 개정에 있어 현재와 같은 공식적인 의견수렴절차나 논의가 필요한 것은 아니었다. GPL 제2판이 발표되고 FSF는 곧바로 GNU 프로젝트의 결과물들을 GPL 제2판으로 교체하였으며, 리누스 토발즈도 리눅스커널에 GPL 제2판을 채택하였었다. 하지만 현재의 상황은 다르다. GPL은 전세계 수만의 프로젝트에서 사용되고 있으며, PC 운영체제로부터 휴대폰, PDA, 셋탑박스, 홈네트워킹 장비 등의 임베디드소프트웨어분야에서 광범위하게 사용되고 있다. 다시 말하면 더 이상 FSF의 GNU프로젝트에서만 사용되는 라이센스가 아니며, 그야말로 자유/오픈소스소프트웨어에 관계된 수많은 기업과 사람들이 지켜야 할 행동규범의 지위를 갖게 된 것이다.

FSF는 지난 수년 동안 자유/오픈소스소프트웨어 커뮤니티, 산업계, 학계 등과 공식적으로 또는 비공식적으로 GPL의 개정에 대해 논의해 왔으며, 이를 바탕으로 마련한 첫번째 안(First Discussion Draft)을 2006년 1월 발표하였다. 초안의 발표와 함께 다양한 의견을 수렴하기 위한 토론위원회 등의 공식적인 프로세스를 만들었다. 이를 바탕으로 인터넷을 통한 의견 수렴, 수차례의 국제 컨퍼런스를 거쳐 두번째 안(2nd Discussion Draft)을 2006년 7월 인터넷에 게시하였고, 이에 대한 의견을 인터넷과 국제 컨퍼런스를 통해 2007년 3월 28일 세 번째 토론안을 발표하고, 현재 의견을 수렴하고 있다.

2007년 3월 28일 발표된 3번째 안을 기준으로 GPL 제3판의 전체적인 체계를 보면, 서문을 제외하고 제0조부터 제15조까지 총 16개 조문으로 구성되어 있다. 이중 제4조 내지 제6조, 제8조 내지 제10조, 제12조, 제14조 내지 제15조는 기존의 GPL 제3판의 내용을 적절히 수정해서 재구성한 것이다. 새롭게 추가된 내용으로는 제0조 내지 제1조에서 각종 용어를 새로이 도입하거나 기존의 용어를 수정하였으며, 제3조를 중심으로 DRM과 관련된 내용이 추가되었다. 또한 자유/오픈소스소프트웨어 라이센스의 급격한 증가와 양립성 문제를 완화하고자 제7조에서 GPL에 부가적인 조건을 추가할 수 있도록 규정하고 있다. 아울러 제11조 등은 소프트웨어특허문제, 제13조에서는 Affero GPL과의 양립성문제에 대처하고자 새롭게 추가된 내용이다.

주요 개정내용과 쟁점(2d draft기준)

• 개요 및 용어의 정의

2007년 3월 28일 발표된 3번째 안을 기준으로 GPL 제3판의 전체적인 체계를 보면, 서문을 제외하고 제0조부터 제15조까지 총 16개 조문으로 구성되어 있다. 이중 제4조 내지 제6조, 제8조 내지 제10조, 제12조, 제14조 내지 제15조는 기존의 GPL 제3판의 내용을 적절히 수정해서 재구성한 것이다. 새롭게 추가된 내용으로는 제0조 내지 제1조에서 각종 용어를 새로이 도입하거나 기존의 용어를 수정하였으며, 제3조를 중심으로 DRM과 관련된 내용이 추가되었다. 또한 자유/오픈소스소프트웨어 라이센스의 급격한 증가와 양립성 문제를 완화하고자 제7조에서 GPL에 부가적인 조건을 추가할 수 있도록 규정하고 있다. 아울러 제11조 등은 소프트웨어특허문제, 제13조에서는 Affero GPL과의 양립성문제에 대처하고자 새롭게 추가된 내용이다.

일반적으로 하나의 라이센스가 전세계적으로 동일하게 사용되는 경우는 드물다. 라이센서(licensor)가 시장을 지역적으로 구분하고자 하는 전략적인 이유도 있겠지만, 각국마다 저작권법 등의 법제도가 상이하기 때문이다. 그래서 라이센서는 각국에 적합한 라이센스를 따로 만들어서 배포하게 된다. GPL 제2판은 일반적인 상용라이센스와는 다르긴 하지만, 어디까지나 미국의 법체계를 기반으로 만들어진 것이 틀림없다. 사용되는 용어에서나 워런티, 책임의 제한 등에 관한 내용이 이를 잘 말해주고 있다. 그렇지만 자유/오픈소스소프트웨어가 전세계적으로 사용되고 있는 현재, GPL이 미국이외의 지역에서 하나의 라이센스로 사용되기 위한 변화가 필요하다. 이와 관련하여 GPL 제3판에서는 다음과 같이 용어를 새롭게 정의하거나 추가하고 있다.

첫째, “수정된 저작물(Modified Version)" 또는 “다른 저작물을 기초로 한 저작물(Work based on the Program)"이란 각국의 저작권법에 의해 허가를 필요로 할 정도의 수정을 한 저작물을 말한다(GPL 제3판 0. Definitions). 이와 함께 GPL 제2판에서는 미국 저작권법상의 ”파생저작물(derivative work)" 개념을 사용하였으나, GPL의 세계화라는 의미에서 이를 삭제하였다.

둘째, 저작물을 “propagate"한다는 것은, 저작물을 컴퓨터에서 작동시키거나 다른 사람들과 공유하지 않고 저작물을 수정하여 사용하는 행위를 제외하고, 각국의 저작권법에 의해 저작권자의 허가가 필요한 모든 행위를 말한다(GPL 제3판 0. Definitions). 예를 들어 저작물을 복제, (수정하거나 그대로) 배포하거나 공중이 이용할 수 있도록 하는(making available to the public) 행위를 포함한다.

셋째, 저작물을 “convey"한다는 것은, 재라이센싱(sublicensing)를 제외하고, 다른 사람들로 하여금 저작물을 복제하게 하거나 복제물을 받도록 하는 모든 'propagation'을 말하며, 복제물을 전달하지 않고 네트워크를 통해 이용자와 상호작용하는 것은 포함되지 않는다. 첫 번째 초안(Draft 1)에서는 GPL 제2판에서와 같이 ”배포(distribution)“ 개념을 그대로 사용했으나, 각국의 저작권법에서 배포의 범위가 다르고, 일부 지역에서는 ”공중에의 전달(communicating to the public)" 등 다른 표현을 사용하고 있어 혼동을 가져올 수 있기 때문에 새롭게 사용하게 된 것이다. 재라이센싱(sublicensing)을 제외한 것은 GPL 제3판 제2조에서 이를 금지하고 있기 때문이다.

넷째, 오브젝트코드 형태의 저작물에 대한 “Corresponding Source"란, 시스템 라이브러리(System Libraries), 범용 툴(tools) 또는 일반적으로 사용가능한 자유프로그램을 제외하고, 오브젝트코드를 생성, 설치 및 구동하고, 동 저작물을 수정하기 위해 필요한 모든 소스코드를 의미한다(GPL 제3판 0. Definitions). 예를 들면 동작을 통제하기 위해 사용되는 스크립트, 소스파일과 관련된 인터페이스 정의파일, 프로그램을 위해 특별히 만들어진 정적 라이브러리 및 동적 서브프로그램에 대한 소스코드 등을 포함한다.

이상과 같은 용어정의를 바탕으로, 이하에서는 개정의 핵심적인 내용이라고 할 수 있는 소프트웨어특허의 문제, DRM의 기술의 문제, 추가적인 허가/요구사항의 허용을 통한 GPL의 유연성 확보에 관한 문제를 중심으로 GPL 제3판의 내용을 구체적으로 살펴보기로 한다.

• 특허권의 취급

GPL 제2판에서도 특허권에 관한 내용을 일부 다루고 있지만, 1990년대 후반부터 소프트웨어관련 특허권의 수가 급격히 증가해 왔으며, 이에 대한 대책이 필요하다는 요구가 자유/오픈소스소프트웨어 커뮤니티 내부에서 꾸준히 제기되었다. 이러한 주장의 배경에는 소프트웨어특허의 증가가 자유/오픈소스소프트웨어에 중대한 위협이 될 수 있다는 인식이 깔려있다. 소프트웨어특허와 관련된 쟁점 또는 위험은 ⅰ) 라이센서 등 전방(upstream)으로부터의 위험, ⅱ) 라이센시 등 후방(downstream)으로부터 제기되는 위험, 기타 ⅲ) 제3자로부터 제기될 수 있는 위험으로 나누어 볼 수 있는데, 이들 각각에 대해 GPL 제3판은 몇 가지 조항을 추가하고 있다.

첫째, 라이센서 등이 특허권에 의한 소송을 제기할 수 있는 위험과 관련하여, GPL 제2판에서는 명시적 규정을 두고 있지는 않았지만 제7조 등의 해석상 라이센서는 자신이 가지는 특허권을 ‘묵시적으로’ 허락하는 것으로 볼 수 있었다. 하지만 미국법상의 해석으로는 이러한 해석이 가능하지만, 모든 국가가 그와 같지는 않을 것이라는 의견이 있었으며, 그에 따라 GPL 제3판은 이에 관해 제11조에서 명문으로 규정하였다.

동 조항에 의하면 라이센시가 프로그램을 전달받아서 라이센스가 허락하고 있는 권리를 행사하는 경우, 동 프로그램의 저자와 전달자는 그와 같은 행위에 대해 필수특허청구항을 주장하지 않을 것이라는 서약(Covenant)을 한다고 규정하고 있다. 또한 라이센시가 프로그램을 전달하는 경우에도 모든 수령자에 대하여 라이센시의 필수특허청구항을 주장하지 않을 것이라는 서약을 한다고 규정하고 있다(GPL 제3판 11. Patents). GPL 제3판의 첫 번째 토론안(First Discussion Draft)에서는 동조항에서 명시적으로 특허라이센스를 허락하는 것으로 규정하였었다. 그러나 의견을 수렴하는 과정에서 특허권의 본질이 실시할 수 있는 권리를 적극적으로 부여하기보다는 제3자가 실시하는 것을 배제하는 것이기 때문에, 특허권자가 특허권의 주장을 하지 않겠다는 서약을 한다면 충분하다고 판단했기 때문에 위와 같이 변경하였다.

동규정은 프로그램을 수정하지 않고 다시 전달하는 경우(GPL 제3판 4.)와 프로그램을 수정해서 전달하는 경우(GPL 제3판 5.)를 구분하지 않고 있다. 따라서 프로그램을 단순히 재배포하는 경우에도 후방 이용자들에 대해 특허주장을 할 수 없다. 의견수렴과정에서 일부 사람들은 수정해서 배포하는 경우와는 달리 단순 재배포의 경우에는 동규정이 적용되지 않도록 해야 한다는 의견을 제시하였으나 받아들여지지 않았다.

두 번째는 라이센시 등으로부터 특허소송이 제기되는 경우인데, 이와 같은 경우를 다루고 있는 라이센스의 조항을 통상 특허보복(Patent Retaliation)조항이라고도 한다. 예컨대 애플의 경우, 애플공중소스라이센스(Apple Public Source License)에 의해 배포되는 프로그램을 사용하는 이용자가, 애플이 먼저 특허소송을 제기하지 않았음에도, 애플에 대해 특허소송을 제기하는 경우에는 아무런 통지 없이 라이센스가 자동으로 종료된다. 이와는 달리 아파치라이센스(Apache License)의 경우는, 상대방에 대한 반소제기 등 방어의 목적인지 여부와 상관없이, 아파치라이센스 프로그램을 사용하는 어떠한 이용자에 대해서 특허소송을 제기하는 경우, 소송을 제기한 날에 해당 라이센스가 종료하는 것으로 규정하고 있다.

이상과 같은 특허보복조항이 필요하다는 주장에 대해 FSF측은 그와 같은 조항의 실효성에 대해 의문을 제기하고 있다. 다만 일부 의견을 수용하면서, 특허소송에 대한 보복 또는 방어목적이 아닌 다른 목적의 특허소송을 제기하는 이용자에 대해, 라이센시가 라이센스를 종료시킬 수 있다는 조건을 추가하는 것을 허용하였다(GPL 제3판 7.b.5).

이와는 별도로 GPL 제3판은 수정프로그램을 사적으로(privately) 제조․사용하거나 제3자로 하여금 제조․사용하도록 하는 것은 조건 없이 허락하지만, 만약 다른 사람들이 2차적프로그램을 제조, 사용, 판매 또는 전달하는 행위에 대해 라이센시가 특허침해소송을 제기하면, 프로그램을 수정하여 제조․사용할 수 있는 권리가 종료된다는 내용을 추가하였다(GPL 제3판 2. Basic Permissions). 이와 같은 경우에도 기존의 수정된 프로그램을 계속 사용할 수 있는 자유는 GPL의 핵심적인 영역에 속하기 때문에 그대로 유지된다. 동규정이 충족되기 위해서는 두가지 요건이 필요하다. 첫째, 라이센시가 사적으로 수정한 프로그램에 구현된 필수특허청구항(essential patent claims)의 침해를 근거로 한 소송이어야 한다. 둘째, 침해행위는 GPL 제3판을 준수하여 2차적저작물을 제조, 사용 또는 전달하는 행위를 포함해야 한다.

세 번째는 라이센서와 라이센시의 관계에 있지 않는 제3자가 특허소송을 제기하는 경우이다. 이와 같은 경우 라이센스규정을 통해 해결할 수 있는 문제는 별로 없으며, 소프트웨어 특허에 관한 정책 또는 법해석의 문제로 귀결된다. 그래서 FSF는 GPL 제2판에서와 같이 GPL 제3판에서도 서문(Preamble)을 통해 소프트웨어 특허의 위험성을 지적하고 각국이 소프트웨어 특허의 부여를 제한할 것을 주장하고 있다. 또한 GPL 제2판 제7조의 규정을 제12조에 그대로 위치시키면서, 모든 이용자가 GPL의 조건에 따라 프로그램을 이용할 수 있도록 하는 것이 불가능할 경우에는 제3자의 특허권을 구현한 프로그램을 GPL로 배포할 수 없도록 하고 있다(GPL 제3판 12.).

한편 라이센시가 재라이센스가 허용되지 않는 특허라이센스를 바탕으로 GPL 프로그램을 전달하는 경우, 라이센시는 ⅰ) 가능한 특허침해주장으로부터 후방 이용자(downstream users)들을 방어하거나, ⅱ) 모든 사람들이 공중이 이용가능한 네트워크 서버 등을 통해 GPL의 조건하에 무료로 관련 소스코드를 복제할 수 있도록 해야 한다(GPL 제3판 11. Patents).

이상과 같은 GPL 제3판의 특허권 관련 규정에 대해 일부 기업들은 자사가 가진 소프트웨어특허 포트폴리오 전체에 대한 권리를 상실할 가능성이 있다는 문제를 제기하였다. 이에 대해 FSF는 GPL 제3판이 특허권의 위험으로부터 이용자들을 보호하기 위한 것임을 설명하고, 다른 한편으로는 특허권을 상당수 보유하고 있는 기업들의 입장 차이를 조정하고자 노력하고 있다.

• DRM의 문제

일반적으로 DRM은 ”Digital Rights Management"의 약칭으로 저작권을 보호하기 위한 기술적 수단을 의미한다. 그러나 다른 한편으로 DRM은 이용자의 행위를 제한하는 측면이 있는데, GPL 제3판의 첫 번째 토론안에서는 이와 같은 측면을 강조하여 DRM 관련 규정의 제목을 “Digital Restrictions Management"로 표기했었다. FSF는 미국, 유럽 기타 각국이 DRM 기술을 회피하는 행위에 대해 민사책임을 부과하거나, 심지어 형사처벌을 하도록 하는 법률을 제정하는 것에 대해 비판하고 있으며, 이용자들의 자유를 보호하는 것을 최우선의 목표로 하고 있는 GPL 프로그램이 이와 같은 DRM으로 사용되고 있다는 것에 심각한 우려를 표명하고 있다. 그래서 GPL 제3판에서는 다음과 같은 규정을 신설하여, 프로그램을 GPL로 배포하는 경우 각국의 법률에 의해 보호받고 있는 기술적 보호조치로서의 법적 이익을 포기하도록 하였다. 이를 통해 GPL 프로그램을 수정하는 행위에 대해서는 민사적, 형사적 책임을 물을 수 없도록 하겠다는 것이 FSF의 의도이다.

첫째, GPL의 다른 규정에도 불구하고, 이용자들이 동 라이센스에 의해 부여되는 법적 권리를 행사하는 것을 부인하는 전달형식(modes of convey)은 허락되지 않는다. 어떠한 GPL 프로그램도 미국저작권법 제1201조의 효과적인 기술적 “보호”조치(an effective technological "protection" measure)를 구성하지 않는다. GPL로 프로그램을 전달할 때, 기술적 조치를 우회하는 것을 금지할 수 있는 법적 권리를 포기하게 되며, 이용자들에 대한 제3자의 법적 권리를 강제하는 수단으로서 프로그램의 작동 또는 수정을 제한할 어떠한 의사(intention)도 포기하게 된다(GPL 제3판 3. No Denying Users' Rights through Technical Measures).

DRM과 관련된 두 번째 규정은 “Corresponding Source"의 범위를 규정하고 있는 GPL 제3판 제1조이다. 동규정은 “Corresponding Source"의 범위에 수정된 프로그램을 설치/실행하는데 필요한 암호키 또는 인증키를 포함하도록 하여, 이용자들이 동일한 환경에서 동일한 기능을 구현할 수 있도록 하고 있다(GPL 제3판 1. Source Code). DVD 플레이어를 예로 들면, 이용자가 DVD 플레이어의 소스코드를 수정한 경우 이를 다시 DVD 플레이어에 탑재하여 DVD를 재생할 수 있도록 관련 인증키를 제공해야 한다. 다만 이용자가 이미 인증키를 가지고 있는 경우에는 다시 부여할 필요가 없다.

• 추가적인 허가/요구사항의 허용

GPL과 기타의 자유/오픈소스소프트웨어 라이센스들의 양립성문제에서 언급하였듯이, GPL은 이용자들의 권리를 제한하는 어떠한 사항도 추가하지 못하도록 하는 엄격한 입장을 취하고 있다. 하지만 다양한 자유/오픈소스소프트웨어 커뮤니티들에서는 각각의 커뮤니티가 처한 현실적인 이유 때문에 GPL이 금지하고 있는 제한사항들을 포함하거나, 또는 GPL보다 완화된 조건의 라이센스를 필요로 한다. FSF는 GPL이 어느 정도의 유연성을 발휘하여 자유/오픈소스소프트웨어 커뮤니티의 다양한 현실을 수용할 수 있도록 개정하였다. GPL 제3판 제7조는 라이센시가 추가적인 허가사항(additional permissions)과 추가적인 요구사항(additional requirements)의 조건들을 붙일 수 있도록 하고 있으며, 이러한 추가적인 조건들을 소스코드의 중앙 위치(central place)에 열거하도록 하고 있다.

① 추가적인 허가사항(GPL 제3판 7.a) 추가적인 허가사항(additional permissions)은 GPL 제3판이 요구하고 있는 조건에 대한 예외로 인정된다. 재라이센스를 허용하고 있는 많은 자유/오픈소스소프트웨어 라이센스들도 GPL 제3판 7.a의 관점에서 보면 추가적인 허가사항을 규정하고 있는 것이다. 따라서 많은 자유/오픈소스소프트웨어 라이센스들이 GPL 제3판의 제7조를 이용하여 GPL로 다시 쓰여질 수 있다. GNU LGPL(Lesser General Public License)도 GPL의 요구사항 중 일부분을 완화한 것이기 때문에 7.a를 통해 다시 작성할 수 있다. 뿐만 아니라 리눅스커널의 "Copying" 파일에 추가되어있는 조건도 추가적인 허가사항의 범위에 속한다고 볼 수 있다.

② 추가적인 요구사항(GPL 제3판 7.b) 추가적인 요구사항(additional requirements)이란 프로그램의 사용, 수정 또는 ‘propagation’ 행위를 제한하는 새로운 조건을 부가하는 것이다. 하지만 GPL 제3판은 다음과 같은 종류의 요구사항만을 추가할 수 있도록 하고 있으며, 이와 같은 범위에 포함되지 않는 요구사항, 예를 들어 변호사비용에 관한 규정, 관할, 조정 등에 관한 모든 조건은 금지된다(GPL 제3판 7.b).

ⅰ) 합리적인 법적 통지(legal notices) 또는 저작자표시(author attributions)를 유지할 것을 요구하는 조건;

ⅱ) 프로그램의 출처표시가 잘못되지 않도록 요구하거나, 수정된 프로그램을 원래의 프로그램과는 다른 합리적인 방법으로 표시하도록 요구하는 조건; ⅲ) GPL과는 다른 워런티(warranty) 또는 책임(liability)의 면책(disclaimers);

ⅳ) 특정한 라이센서들이나 저자들의 이름을 공표하지 못하도록 제한하거나, 명시적인 허락을 받지 않으면 특정의 상호, 상표, 서비스마크를 공개적으로 사용하지 못하도록 요구하는 조건;

ⅴ) 컴퓨터 네트워크를 통해 이용자들과 상호작용하도록 수정된 프로그램의 경우, 이용자들이 동일한 네트워크를 통해 Corresponding Source를 받을 수 있도록 요구하는 조건;

ⅵ) 소프트웨어특허소송에 대한 보복 또는 방어목적이 아닌 다른 목적의 특허소송을 제기하는 이용자에 대해 프로그램의 사용에 대한 허락을 종료시키는 조건;

ⅶ) GPL이 명시적으로 언급하고 있는 요구사항과 형태나 범위에 있어서 동등하다고 볼 수 있는 조건.

주요 개정내용과 쟁점 (2007. 3. 28. 3번째 안)...분석중

• 특허권 관련

특허권이 이전되는 경우 새로운 양수인에게 이와 같은 서약을 준수할 의무가 있는가에 대한 문제제기가 있었으며, GPL 제3판 세 번째 토론안에서는 다시 명시적으로 라이센스를 부여하는 것으로 바뀌었다. GPL 제3판 제11조.

라이센시가 특허소송을 제기하는 행위는 GPL이 금지하는 추가적인 제한(further restrictions)에 해당하여(제10조), 라이센시가 이를 위반하는 경우 제8조에 의해 라이센스가 종료될 수 있음을 규정하고 있다. 이와 같은 일반적인 특허보복조항이 도입됨으로써 두 번째 토론안에 규정되어 2개의 보복조항(제7조 b.5와 제2조)은 더 이상 필요가 없어 삭제되었다.

GPL 제3판 세 번째 토론안은 동 조항을 일부 수정하는 한편, 2006년 11월 마이크로소프트와 노벨의 사례에서와 같이 GPL 소프트웨어의 이용자들을 차별하는 특허라이센스계약을 규제하기 위한 내용을 포함시키고 있다.

• DRM 관련

GPL 제3판 세 번째 토론안은 동 규정의 취지는 살리면서, 그 적용범위를 ‘이용자제품(User Product)'로 줄이고, 이와 같은 이용자제품에 대한 ’설치정보(Installation Information)'를 제공할 것을 요구하는 내용으로 변경하여 제6조의 후단으로 자리를 옮겨 규정하고 있다.

• 추가적인 허가/요구사항의 허용 관련

GPL 제3판 세 번째 토론안은 동조항의 체제를 약간 변경하였다. a. Additional Permissions, b. Additional Requirements, c. Terms Added or Removed by You라는 소제목은 모두 삭제하고, 7.b에 포함되어 있던 7개 항목 중 앞부분 4개를 약간씩 수정하여 a., b., c., d.로 남기고, 나머지는 아래에서 설명하는 것처럼 다른 곳으로 이동시키거나 삭제하였다.

동 조항은 원래 Affero GPL과 GPL의 양립성을 위해 포함된 것이었는데, GPL 제3판 세 번째 토론안은 동 조항을 삭제하고 제13조를 새롭게 추가하여, 향후 새롭게 만들어질 Affero GPL 제2판과 GPL 제3판이 상호 양립하도록 하였다. 제13조의 핵심내용은 GPL 제3판의 적용을 받는 코드와 Affero GPL 제2판의 적용을 받는 코드를 링크시켰을 때, Affero GPL 제2판의 코드에는 GPL 제3판의 Copyleft 조항이 적용되지 않는다는 것이다.

GPL 제3판 세 번째 토론안에서는 제10조의 마지막 부분에 라이센시가 특허침해를 이유로 소송을 제기하지 못하도록 하는 내용을 포함시키고, 동 조항은 삭제하였다.

주요 OSS제품의 라이센스 분석

• Linux 커널
• gcc/glibc
• Apache
• MySQL/Berkeley DB/PHP/Perl
• Qt/Qtopia
• Java (ME)
• ...

기업에서의 OSS 라이센스 관리/활용 방안

기업에서의 OSS 활용권장 프로세스

앞서 살펴본 것처럼, 오픈소스 소프트웨어(Open Source Software)는 소스 코드의 공개로 인한 Royalty Free, 자유로운 사용/복제/수정/배포의 허락, 빠른 기술 발전 속도 등의 강점을 바탕으로 전 세계적으로 그 영역을 급속히 확장시키고 있다. 또한 Linux를 주축으로 한 오픈소스 소프트웨어의 활용이 국내에서도 확대되고 있는 상황이다. 그러나 오픈소스 소프트웨어 역시 개발자의 지적 활동의 소중한 결과물로서 관련 지적재산권법에 의해 보호되고 있다는 사실은 많이 알려져 있지 않다. 상용 소프트웨어를 사용하기 위해 라이센스 준수가 필수적이듯 오픈소스 소프트웨어 역시 이를 사용하기 위해서는 해당 오픈소스 소프트웨어의 라이센스 준수가 반드시 선행되어야만 하는 것이다. 이를 위반할 경우, 우선 해당 오픈소스 소프트웨어에 대한 사용 권리가 박탈되기 때문에 제품화를 한 경우 더 이상 제품을 판매할 수 없게 된다. 그리고 오픈소스 커뮤니티로부터의 Claim 및 라이센스 위반 기업(기관)이라는 이미지 훼손 및 신뢰성 추락을 예상할 수 있다. 이외에도 최악의 경우에는 법률 소송에 휘말릴 수 있으며, 각 라이센스에서 요구하는 벌칙을 받아야 한다.

오픈 소스를 활용하기 위해서는 상용 소프트웨어와 마찬가지로 반드시 해당 오픈소스의 라이센스에 대한 준수가 필수적이다. 하지만 오픈소스 라이센스에서 강제하고 있는 내용에 대해서 개발자들을(Developer) 비롯한 관리자들(Manager)의 이해가 아직도 많이 부족한 것이 현실이다. 자칫 잘못하면 라이센스 위반으로 이미 판매중인 제품의 경우 리콜하거나, 양산 또는 개발 중인 경우는 결과물(Source Code)을 공개하거나 아니면 아예 처음부터 다시 개발해야 하는 상황을 초래할 수도 있다. 따라서 오픈소스 활용에는 반드시 체계적인 프로세스가 필요하다.

오픈소스 라이센스 관련 문제를 사전에 방지하기 위해서는 과제 계획 단계부터 이를 고려하여야 한다. 그렇지 않으면, 개발이 끝난 후 문제를 발견하게 될 것이며, 이럴 경우 처음부터 다시 개발해야 하는 엄청난 개발 비용의 낭비 요인이 발생할 수 있다. 또한 개발이 진행되면서도 단계별로 준수해야 할 사항들을 정의하고 반드시 체크해야만 한다. 본 문서에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 S/W 개발프로세스를 다음과 같이 표준화/단순화하였다.

'기획(SW Design)' -> '구현(Implementation)' -> '검증 (Verification)' -> '제품화 (Production)'

(1) 기획(S/W Design) 단계

오픈소스 라이센스 관련 문제를 피하는 가장 좋은 방법은 개발 기획 시점부터 이를 고려하는 것이다. 좀 더 구체적으로 알아보면, 우선 해당 과제에 오픈소스를 활용할 것인지의 여부를 판단하여야 한다. 그런 후 활용하고자 하는 오픈 소스의 라이센스를 반드시 확인하여야 한다. 그리 고 기획 단계의 마지막으로 해당 S/W Component별로 소스코드 공개가능여부를 판단하여야 한다.

1. 오픈소스 활용 여부 결정

해당 과제에 오픈소스를 활용할지에 대한 판단의 기준으로 다음의 사항들을 참조할 수 있을 것이다.

• 장점
  • Low Entry Cost : 일반적으로 오픈소스는 Web 상에서 무료로 다운로드 및 소스 코드 수정/ 재배포가 가능한 것이 특징이다. 따라서 초기 개발을 시작하기 위한 비용이 적게 요구된다는 장점이 있다.
  • Reliability & Stability : 오픈소스의 개발 과정을 볼 때, 전세계에 있는 수많은 우수한 개발자들이 직접 개발과 Debugging 과정에 참여하기 때문에 In-house에서 폐쇄적으로 개발되는 상용 프로그램에 비해 비교적 안정적으로 동작한다는 평이 일반적이다. 하지만 이러한 Reliability와 Stability는 많은 개발자들의 적극적인 참여가 있을 때에만 가능한 것이기 때문에, 사용하고자 하는 오픈소스의 개발 과정 역시 주요 고려대상이 될 수 있다. 참고로 최근 OSDL에서 발표한 Linux Kernel 개발과정을 보면 Linux Kernel이 단순히 Community 멤버들의 자발적인 참여에 의해 이루어지는 것이 아니라 체계적이고 과학적인 개발 방법론에 의해 이루어지고 있음을 알 수 있다. <<OSDL 그림첨부>> Linux 커널 개발 프로세스
  • Security : 일반적으로 Virus나 Worm은 System의 취약한 부분, 즉 Bug를 통해 침입하기 때문에 위의 2번을 고려할 때 오픈소스는 상용 프로그램에 비해 Security 면에서 좀 더 안전하다고 볼 수 있다.
  • Networking : 오픈소스가 확산된 가장 큰 이유가 다양하고 강력한 Networking 기능 지원이라 해도 과언이 아닐 것이다. 대표적으로 Apache는 전세계 웹 서비스의 절반 이상을 차지하고 있을 정도이다. 또한 Open Source Networking Solution은 대부분 상용 프로그램과 호환되기 때문에 상품화에도 아주 잘 활용될 수 있을 것이다.
  • Fast, Flexible Development : 오픈소스 커뮤니티는 보통 최신 기술 정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운영되기 때문에 상용 프로그램에 비해 기술 발전 속도가 빠르다.
  • Open Formats & Protocols : 오픈소스는 주로 Open Formats 또는 Protocols을 사용하기 때문에 서로 다른 소프트웨어간 상호 연동성이 보장되는 장점이 있다. 모든 기기들이 서로 다른 Network을 통해 하나로 연결되는 Ubiquitos 시대에는 그야말로 필수적인 요소라 하겠다. 또한 오픈소스 운동의 주 원인 역시 상용 프로그램들간의 비호환성을 해결하는 것이다.

• 단점
  • 애플리케이션의 부족: 대부분의 사용자들은 Windows 기반의 GUI(Graphical User Interface)를 갖고 있는 Application에 익숙해 있지만, 이에 버금가는 Linux 기반의 Application이 많이 부족한 것이 현실이다. 또한 Linux 기반으로 개발된 많은 Application들은 Windows 기반 Application들과 호환되지 않는 문제점도 있다. 단적인 예로 WinCE기반의 PDA 사용자가 Linux 기반의 PDA 사용자보다 훨씬 다양한 Application을 이용할 수 있고 또 PC(Personal Computer)와의 연동성 역시 훨씬 쉽게 이용할 수 있는 것이 사실이다.
  • 빈약한 문서: 상용 프로그램에 비해 오픈소스는 체계적인 문서를 갖고 있지 못한 단점이 있다. 이는 경우에 따라서는 개발과정의 지연을 초래할 수도 있기 때문에 활용하고자 하는 오픈소스가 얼마만큼 문서화가 잘 되었는지도 잘 살펴보아야 한다.
  • 불확실한 개발 로드맵: 오픈소스는 영리를 목적으로 하는 회사에서 개발되는 것이 아니라, 자발적 참여를 바탕으로 Web 상에서 자유롭게 개발되는 것이 특징이다. 그렇기 때문에 상용 프로그램에서 볼 수 있는 Roadmap을 기대하기 힘든 면이 있다. 오픈소스의 이러한 단점은 오픈소스를 활용하는 개발 과제의 Roadmap에 까지 영향을 미칠 수 있기 때문에 활용하고자 하는 오픈소스의 향후 개발 계획이 얼마나 체계적으로 세워져 있는지도 고려해야 한다.

2. 지적재산권 보호

오픈소스에 회사 또는 단체가 보유한 특허 및 소스코드를 포함시킬 경우 오픈소스 라이센스는 일반적으로 Royalty-free를 요구하고 있다. 따라서 Royalty-free를 원치 않을 경우에는 해당 오픈소스를 사용할 수가 없으며, 또한 사용 후 Royalty를 주장하게 되면 해당 오픈소스에 대한 사용 권한이 박탈되는 경우가 일반적이다. 따라서 오픈소스를 활용하여 특허를 구현하거나 기존 소스코드를 포함하고자 할 경우, 반드시 Royalty에 대한 입장을 명확히 하여야 할 것이다.

3. 오픈 소스 라이센스 확인

해당 과제에 오픈소스를 사용하기로 결정하였다면 구체적으로 어떤 프로그램을 사용할 지를 판단하여야 한다. 오픈소스의 특성상 Web 상에 여기저기 흩어져 있지만, 쉽게 오픈소스에 관한 정보를 찾을 수 있는 곳으로는 다음과 같다.

• Freshmeat.net • SourceForge • OSDir.com • BerliOS • Bioinformatics.org

위의 사이트들은 대부분 License별 오픈소스 분류 항목을 두고 있기 때문에 쉽게 해당 프로그램의 라이센스를 확인할 수 있을 것이다.

4. 소스 코드 공개 가능 여부 결정

이제 과제 기획 단계의 마지막으로 S/W Component별 소스 코드 공개 가능 여부에 대하여 결정하여야 한다. 이에 따라 S/W 구현 방법이 많이 달라지기 때문이다. 소스 코드 공개 여부 판단 기준으로 다음의 사항을 참조할 수 있을 것이다.

• 장점
  • Maintenance : 소프트웨어의 경우 하드웨어와 달리 개발 후 지속적 Upgrade 및 Debugging과 같은 Maintenance 과정이 중요하다. 이러한 Maintenance 과정은 상당한 Resource를 요하기 때문에 Maintenance를 직접 할 것인지에 대한 고려가 필요하다. 개발한 소스 코드를 오픈소스 커뮤니티에 공개하고, 이를 바탕으로 오픈 소스 커뮤니티를 통한 Maintenance 방법 역시 경우에 따라 아주 효율적일 수도 있을 것이다.
  • Fast Development : 오픈소스의 개발 모델 중 가장 특징적인 것이 바로 ‘Release Early and Often’을 통한 ‘Parallel Development and Debugging’이 가능한 것이다. 이를 통해 오픈소스는 빠른 개발 속도를 가능케 하고 있다. 이러한 모델을 Resource가 부족한 개발 과제에 적용하면 보다 효율적이고 빠른 개발이 가능할 것이다.
  • Reliability 확보: S/W의 신뢰성 확보의 가장 좋은 방법은 다양한 사용자들이 다양한 환경에서 해당 프로그램을 사용하면서 발견되는 문제점을 신속히 수정하는 것이다. 이런 측면에서 볼 때 오픈소스 커뮤니티를 잘 활용하면 S/W Reliability 확보에 상당한 도움을 얻을 수 있을 것이다.

• 단점
  • 차별화 유지 어려움 : 소스 코드를 공개하게 되면 그 소스 코드는 경쟁사에게도 공유되는 것이기 때문에 결국 제품의 차별화 확보가 불가능하게 되는 단점이 있다.
  • IP 확보 불가능: 회사 또는 단체가 보유한 특허를 구현하여 소스코드를 공개하는 것은 결국 모든 사용자들에게 Royalty-free의 조건으로 특허를 공개하는 것이나 마찬가지가 된다.
  • 특허 침해 소송 제기 가능성 증가: 소스 코드가 공개되어 있으면 누구든 그 소스 코드를 볼 수 있기 때문에 특허 침해 소송 제기 가능성이 증가하게 되는 문제점이 발생할 수 있을 것이다.

(2) 구현(Implementation)

자체 개발한 소스 코드를 공개해도 무방한 경우는 특별히 구현 방법에 신경 쓸 필요가 없다. 단, 소스 코드를 공개할 경우 회사 또는 단체 보유의 지적재산권을 포함시키지 않도록 주의할 필요가 있다. 그러나 소스 코드 공개를 원하지 않을 경우는 사용하는 오픈소스의 라이센스 강제 사항과 활용하고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한 경우가 발생할 수 있기 때문에, 이럴 경우는 라이센스 혹은 법률 전문가에게 의뢰하여 정확한 판단을 받아야 할 것이다.

(3) 검증(Verification)

이제 개발이 완료 되었으면, 개발 결과물인 소스 코드에 대해 실질적인 검증 작업이 필요하다. 왜냐하면, 개발 계획서 그 자체로는 라이센스 이슈가 없었더라도 실제 구현 과정에서 개발자의 오픈소스 코드에 대한 라이센스 이슈 검증없이 사용된 경우가 있을 수 있기 때문이다. 소스 코드 레벨에서 수많은 오픈소스 코드와 비교하는 것이 불가능할 것으로 생각될 수도 있지만, 최근 미국의 Blackduck社와 Palamida社는 이러한 요구에 착안하여 소스 코드 레벨에서 오픈소스 코드의 사용을 확인할 수 있는 검증 도구를 개발하여 판매 중에 있다. 세부 내용은 Blackduck社(www.blackducksoftware.com)와 Palamida社(www.palamida.com)의 웹사이트를 참고하기 바란다. 본 문서에서는 본 툴의 활용 방법에 대해 간략히 설명할 것이다. 먼저, Blackduck社에서 개발한 검증 도구는 Eclipse Platform 기반의 서버-클라이언트 형식으로 되었다. 서버에는 수많은 오픈소스 코드를 Fingerprint 형식으로 Database化한 Knowledge System을 갖고 있으며, 사용자 프로그램인 클라이언트에서는 서버에 접속하여 자체 개발한 프로젝트의 소스 코드와 서버의 Database에 있는 오픈소스 코드를 비교하여 유사/동일한 소스 코드 사용에 대해Report를 해주는 방식이다. 이 Report를 바탕으로 라이센스 전문가는 실제 사용된 오픈소스 코드의 문제 여부를 최종 판단할 수 있게 된다. 다음으로 Palamida 툴은 18.98.7.5<보완> <<Blackduck 툴 및 Palamida툴 Overall Architecture 그림 삽입>> 및 <<Best practice 분석 포함>>

(4) 제품화(Production)

1. 소스 코드 공개

제품화 단계에서는 소스 코드 공개와 관련된 작업이 있다. 우선 소스코드 공개 방법으로 다음의 경우가 가능하다. ‘제품 판매 시 a) 제품과 함께 Machine-readable한 소스 제공, b) 제품과 함께 Written Offer만 제공하며 이를 통해 소스 제공에 대한 약속 및 정보 제공, 실제 소스는 웹 사이트에 공개’. 이 중 a)는 소스 제공이라는 측면에서는 가장 확실한 방법이 되겠지만 비용이 많이 들고 비효율적인 방법이다. 따라서 회사 또는 단체 입장에서는 b)의 방법을 이용하는 것이 더 효율적일 것이다.

2. 사용자 메뉴얼 작성

거의 대부분의 오픈소스 라이센스는 해당 오픈소스를 사용할 경우, 사용자에게 오픈소스를 사용하고 있음을 알릴 것을 요구하고 있다. 즉, 사 용자가 쉽게 접할 수 있는 문서(예: 사용자 메뉴얼) 등에 그 제품에 포함된 오픈소스 현황을 명시하고 관련 라이센스를 알려줘야 한다. FSF가 제시한 예시 문구를 보면 다음과 같다.

"<Program name> is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

<Program name> is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with <Program name>; if not, write to the <Company name, address, and contact point>"

구체적 사례

• HP/IBM
• LG전자/삼성전자(?)
• 한컴리눅스/리눅스코리아/미지리눅스
• SDS/CNS/SK C&C
• 구글/NHN
• 태터툴즈
• 서울시 등 공공기관

OSS라이센스 분쟁 사례

S/W 지적재산권침해 일반

OSS에서의 주요 위반사항

적용범위관련 쟁점

• 사용, 회사내 복제배포
• network server
• dynamic linking

위반사항

• 저작권 관련 문구 유지

• 사용여부 명시

• 소스코드 제공

• 서로 다른 라이센스의 조합

• 특허관련

OSS 라이센스 위반의 발견 및 처리과정

• 위반사항의 발견
• FSF에서의 처리과정
• gpl-violations.org에서의 처리과정===

주요 사례 (Wikipedia 참조)

• FSF v. Davrik/Bracken/Vigorien/Haxil

• gpl-violations.org v. Dlink

On September 6, 2006, the gpl-violations.org project prevailed in court litigation against D-Link Germany GmbH regarding D-Link's inappropriate and copyright infringing use of parts of the Linux Operating System Kernel.[36] The judgment finally provided the on-record, legal precedent that the GPL is valid and legally binding, and that it will stand up in German court

• netfilter/iptables v. Sitecom

In April 2004 the netfilter/iptables project was granted a preliminary injunction against Sitecom Germany by Munich District Court after Sitecom refused to desist from distributing Netfilter's GPL'ed software, allegedly in violation of the terms of the GPL.

• MySQL AB v. Progress NuSphere

NuSphere had allegedly violated MySQL's copyright by linking code for the Gemini table type into the MySQL server. After a preliminary hearing before Judge Patti Saris on February 27, 2002, the parties entered settlement talks and eventually settled.

• SCO v. IBM

SCO currently claims:

Any code belonging to SCO that might have been GPL'd was done by SCO employees without proper legal authorization, and thus is not legally GPL'd.

That for code to be GPL'd, the code's copyright owner must put a GPL notice before the code, but since SCO itself wasn't the one to add the notices, the code was never GPL'd.

• IChessU vs. Jin
• Sony BMG

• 옐림넷 v. 하이온넷

On September 8, 2005, Seoul Central District Court ruled that GPL has no legal relevance concerning the case dealing with trade secret derived from GPL-licensed work.[35] Defendants argued that since it is impossible to maintain trade secret while being compliant with GPL and distributing the work, they aren't in breach of trade secret. This argument was considered without ground.

• Daniel Wallace v. FSF

In May of 2005, Daniel Wallace filed suit against the Free Software Foundation (FSF) in the Southern District of Indiana, contending that the GPL is an illegal attempt to fix prices at zero. The suit was dismissed in March 2006, on the grounds that Wallace had failed to state a valid anti-trust claim; the court noted that "the GPL encourages, rather than discourages, free competition and the distribution of computer operating systems, the benefits of which directly pass to consumers."

• Drew Technologies, Inc. v. Society of Automotive Engineers, Inc., (표준관련)

The case is Drew Technologies, Inc. v. Society of Automotive Engineers, Inc., et al., Civil Action No. 03-CV-74535-NGE-PJK (E.D. Mi. filed Oct. 10, 2003). SAE laid claim to ownership of—wait for it—“ideas, procedures, processes, methods of operation, concepts, principles or discoveries” in SAE’s published technical standards.

The terms of the settlement 1 included SAE paying DrewTech $75,000 (half of which DrewTech contributed back to SAE as a charitable contribution), and SAE stipulated to the following: ” . . . the Society of Automotive Engineers, Inc. [‘SAE’] hereby stipulates and agrees that to the extent that computer software only implements any idea(s), procedure(s), process(es), system(s), methods(s) of operation, concept(s), principles(s), discovery or discoveries that is or are described, explained, illustrated, or embodied in any SAE technical standards (including standards set forth in Technical Report J1699-3), then no copyright claim exists to the extent of such implementation of standards in software code, and SAE shall not assert a copyright claim on that basis, and will dismiss its claim of infringement against Drew Technologies, Inc.”

BusyBox Cases

What was claimed to be the first US lawsuit over a GPL violation concerned use of BusyBox in an embedded device. The lawsuit[2], case 07-CV-8205 in the United States District Court for the Southern District of New York was filed on 20 September 2007 by the Software Freedom Law Center on behalf of Andersen and Landley against Monsoon Multimedia Inc., after BusyBox code was discovered in a firmware upgrade and attempts to contact the company had apparently failed. The case was settled with release of the Monsoon version of the source and payment of an undisclosed amount of money to Andersen and Landley.

On 21 November 2007, the SFLC brought two other lawsuits on behalf of Andersen and Landley against two more companies, Xterasys (case 07-CV-10456) and High-Gain Antennas (case 07-CV-10455), for similar alleged GPL violations concerning BusyBox code.[4][5] The Xterasys case was settled on December 17 for release of source code used and an undisclosed payment,[6] and the High-Gain Antennas case on March 6, 2008 for active license compliance and an undisclosed payment.[7] On 7 December 2007, a case was brought against Verizon Communications over its distribution of firmware for Actiontec routers that it distributes;[8][9] this case was settled March 17, 2008.[10]

Innovation LLC v. Red Hat and Novell (특허관련)

IP Innovation LLC filed the claim against Red Hat and Novell over U.S. Patent No. 5,072,412. groklaw

"Red Hat and Novell transact business in this judicial district and have committed acts of infringement in this judicial district, at least by selling and offering for sale their respective products: the Red Hat Linux system; the Novell Suse Linux Enterprise Desktop; and the Novell Suse Linux Enterprise Server which are accused of infringing the ‘412 Patent, the ‘183 Patent and the ‘521 Patent in this case, as well as conducting other business in this judicial district."complaint

IP Innovation LLC는 (대표적인 Patent Troll로 인식되고 있는) Acacia의 자회사이며, MS에서 활동하던 Brad Brunell와 Jonathan Taub를 영입 groklaw

분쟁발생시 기업의 대응

특허침해소송에서의 대응

특허침해주장에 대한 항변

• 라이센스 취득의 주장 :

some patent-holding companies have issued general public pledges or covenants that apply to the use of FOSS. The patent holder might have agreed with a standards body to provide royalty-free access to patents needed to implement the standard. The patent holder might also have granted a license by contributing or distributing code under a FOSS license, as some FOSS licenses include explicit patent license grants. A patent holder providing code under a FOSS license without an explicit patent license grant, such as GPLv2, would nonetheless probably be held to have granted a license implicitly to recipients of the code, though the scope and coverage of such an implied license would be difficult to establish.

• 비침해 주장 : Claim Chart의 작성

• 특허무효의 주장

• Unenforceability

기타

• Designing Around

• Re-examinations (미국)

부록

주요 OSS 라이센스

• GPL
• LGPL
• BSD
• MIT
• Apache
• MPL

참고자료

SFLC, A Legal Issues Primer