![[-]](http://wiki.kldp.org/imgs/plugin/arrup.png "[-]")
1.1 OpenSource 소프트웨어란 무엇인가
OpenSource 소프트웨어는 일반적으로 자유롭게 사용, 복제, 배포, 수정할 수 있으며, 소스코드가 공개되어있는 소프트웨어를 말한다. OpenSource 의 예로는 Linux 커널 및 관련 GNU 소프트웨어, 아파치 웹서버, FireFox 웹브라우저, MySQL 데이터베이스시스템, Python/PHP/Perl 언어, Eclipse 툴 등을 들 수 있으며, 그 외에도 전세계의 수많은 개발 자들이 개발하고 있는 프로그램들이 있다.
통상 OpenSource 소프트웨어는 자유소프트웨어(FreeSoftware)를 포함한 넓은 의미로 사용되며, 국내에서도 자유소프트웨어를 포함한 OpenSource 소프트웨어를 ‘공개소프트웨어'로 번역하여 사용하고 있다. 하지만 역사 및 추구하는 이념 등에서 자유소프트웨어와 OpenSource 소프트웨어는 미묘한 차이가 있다.
자유소프트웨어(FreeSoftware)는 리차드 스톨만(RichardStallman)과 FSF(Free Software Foundation)에 의해 만들어진 개념으로서, 소프트웨어의 이용자에게 해당 소프트웨어를 실행, 복제, 배포할 수 있는 자유, 그리고 소스코드에 대한 접근을 통해서 이를 학습, 수정, 개선시킬 수 있는 자유를 부여하는 소프트웨어이다. 1980년대에 들어 PC가 널리 보급되기 시작하면서 이전에는 하드웨어의 부속물로만 간주되던 소프트웨어가 거대한 부가가치산업으로 발전하기 시작하였고, 이러한 흐름과 함께 지적재산권 및 라이센스계약을 통하여 소프트웨어의 사용, 복제, 배포, 수정에 일정한 제한을 가하려는 움직임이 나타나게 된다. 소프트웨어를 둘러싼 이러한 일련의 흐름에 반대하고 소프트웨어의 자유로운 사용, 공유, 수정에 대한 기존의 권리를 지키기 위하여 리차드 스톨만은 FSF를 설립하고 자유소프트웨어(FreeSoftware) 운동을 전개하였다.
한편 1990년대 들어서면서 인터넷과 더불어 GPL(General Public License)로 배포된 리눅스가 널리 보급되기 시작하였고, MS의 익스플로러에 밀려 어려움을 겪고 있던 Netscape사가 웹브라우저의 소스코드를 공개하는 결정을 내렸으며, IBM, Sun 등이 자유소프트웨어에 대한 지원을 시작하였다. 그러나 자유소프트웨어의 '자유Free'라는 단어가 한편으로 '무료'라는 의미를 가진다는 점, 엄격한 GPL조항 때문에 상용 기업들이 참여를 꺼려한다는 점 등을 이유로 OpenSource 라는 용어가 제안되었고, 1998년 Open Source Initiative가 활동하기 시작하면서 OpenSource 소프트웨어가 널리 사용되게 되었다. OSI는 OpenSource 소프트웨어로 인정받을 수 있는 10가지 '라이센스 조건'을 정의하고, 각각의 소프트웨어에 대한 라이센스를 분석하여 OpenSource 소프트웨어라이센스에 해당하는지 여부에 대한 인증을 하고 있다. 주요 내용을 살펴보면, 소프트웨어에 대한 배포 및 수정의 자유를 인정해야 하며 소스 코드를 제공할 수 있어야 할 것, 그리고 어떤 사람이나 그룹 또는 이용분야에 대한 차별이 없어야 한다는 조건 등을 두고 있다.![[http]](http://wiki.kldp.org/imgs/http.png)
OpenSource 소프트웨어 라이선스 분포를 참고해 보면 약 82%에 해당하는 프로젝트가 GPL/LGPL을 사용하고 있으며, 그 뒤를 BSD가 차지하고 있다. 따라서 GPL/LGPL/BSD 라이센스가 주로 사용되고 있음을 알 수 있다. 그러나 Mozilla 웹브라우저, Apache 웹서버 등 일부 중요한 OpenSource 소프트웨어들은 자체적으로 라이센스를 가지는 경향도 있다.
위 문단은 마치 오픈소스가 GPL에 반대해서 시작된 것이고, GPLed software가 곧 Free Software인 것처럼 오해할 소지가 있습니다. OSI나 FSF쪽의 어느 누구도 그렇게 말한 사실이 없습니다. Open Source Definition은 몇년전부터 수많은 사람들이 free software 조건으로 말하던 Debian Free Software Guildelines를 데비안에 관련된 부분을 중립적으로 고친 것에 불과합니다. FSF 조차도 GPL이 아니더라도 광범위한 소프트웨어를 free software라고 말하고 있습니다. -- cwryu 2007-07-17 10:51:05
2007년 6월 기준으로, 58개의 라이센스가 오픈 소스 라이센스로 인정되어 등록되어 있다. 하지만 실제로 많이 사용되는 라이센스의 갯수는 한정되어 있다. 오픈 소스 프로젝트 개발 포털사이트인 http://freshmeat.net 에 등록되어 있는 프로젝트들 중에서OpenSource 로 분류되는 약 34,368개 프로젝트의 OpenSource 소프트웨어 라이선스 분포를 참고해 보면 약 82%에 해당하는 프로젝트가 GPL/LGPL을 사용하고 있으며, 그 뒤를 BSD가 차지하고 있다. 따라서 GPL/LGPL/BSD 라이센스가 주로 사용되고 있음을 알 수 있다. 그러나 Mozilla 웹브라우저, Apache 웹서버 등 일부 중요한 OpenSource 소프트웨어들은 자체적으로 라이센스를 가지는 경향도 있다.1.2 OpenSource 소프트웨어의 사례
아래는 유명한 OpenSource 소프트웨어들의 사례이다.
- Linux 커널 : 가장 대표적인 OpenSource 소프트웨어인 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로 다시 변경하였다.
2.1 소프트웨어의 지적재산권과 라이센스
현재 소프트웨어는 다음과 같이 저작권, 특허권, 영업비밀, 상표 등의 지적재산권법에 의해 보호받고 있다.
- 저작권 : 어떤 프로그래머가 특정 소프트웨어를 개발하게 되면 컴퓨터프로그램저작권이 자동적으로 발생하며, 프로그래머 또는 그가 속한 회사에 부여된다. 저작권(copyright)은 시, 소설, 노래 등 저작물에 대해 부여되는 권리로서 그 표현(expression)의 결과물을 보호하는 것이다. 누구도 원 저작자나 저작권자의 허가가 없이는 해당 저작물을 복사, 개작, 재배포할 수 없다.
- 특허권 : 특허는 하드웨어에 구현되거나 소프트웨어에 의해 동작이 구현되는 발명(invention)을 보호한다. 특허권은 자동으로 부여되는 것이 아니고 법에 정해진 절차에 의해 출원을 하여야 하며, 심사를 통해 부여되는 권리이다. 특허 기술을 구현(implementation)하기 위해서는 반드시 특허권자의 허락을 득하여야만 한다. 특허 소유자는 소유자가 허가하지 않은 사람이 해당 특허를 활용한 제품을 만들거나, 사용하거나, 판해하는 것을 막을 수 있다. 특허는 무엇인가 유용한 것을 하도록 하는 방식(method)이므로 소프트웨어의 경우 특허받은 방식을 구현하는 소프트웨어라면 프로그래밍 언어가 다르거나 소스코드가 다르더라도 해당 특허권자의 명시적인 허가를 받아야 하며 이는 OpenSource 소프트웨어, 독점소프트웨어에 공통으로 해당된다.
- 영업비밀 : 영업비밀이란 공연히 알려져 있지 아니하고 독립된 경제적 가치를 지니는 것으로서 상당한 노력에 의하여 비밀로 유지되는 생산 방법, 판매 방법, 기타 영업 활동에 유용한 기술상/영업상의 정보로 정의되어 있다. 이러한 영업비밀은 "부정경쟁방지 및 영업비밀보호에 관한 법률"에 의하여 보호받고 있으며, 이와 같은 영업비밀을 부당한 수단으로 취득하거나, 비밀유지의무가 있음에도 다른 사람에게 누출하는 것은 처벌받게 된다.
- 상표 : 상표권이란 제품이나 서비스와 연계되어 마케팅에 활용되는 이름 등을 보호한다. 또한 상표는 시장에서 나의 제품과 타인의 제품을 구별해 주는 역할을 한다.
2.2 OpenSource 라이센스의 특징
OpenSource 소프트웨어 역시 독점소프트웨어(proprietary software)와 동일하게 저작권 등에 의한 법적 보호를 받고 있으며, 이와 같은 권리에 기반하여 이용자에게 라이센스를 부여한다. 그러나 OpenSource 라이센스는 일반적인 독점소프트웨어 라이센스와는 많은 점에서 차이가 있다. 기본적으로 OpenSource 라이센스는 다음과 같이 사용자의 자유로운 사용, 복제, 배포, 수정을 보장하고 있다.
- 라이센시는 해당 OpenSource 소프트웨어를 자유롭게 사용할 수 있다.
- 라이센시는 해당 OpenSource 소프트웨어를 자유롭게 복제할 수 있으며, 일정한 조건하에 재배포할 수 있다.
- 라이센시는 해당 OpenSource 소프트웨어를 자유롭게 수정하여 사용할 수 있으며, 일정한 조건하에 수정된 내용을 재배포할 수 있다.
- 라이센시는 해당 OpenSource 소프트웨어의 소스코드를 자유롭게 획득하고 접근할 수 있다.
OpenSource 라이센스에서 요구하고 있는 준수사항을 라이센시가 이행하지 않으면 권리자로부터 저작권 위반 (또는 계약 위반)으로 소송을 제기 당할 수 있다. 만약 권리를 침해한 것으로 결론이 내려지면 소프트웨어의 배포가 더 이상 불가능할 뿐만 아니라 이미 배포한 소프트웨어에 대한 손해배상 등 막대한 책임을 부담할 수 있다. 특히 임베디드 소프트웨어의 경우 이를 내장한 제품까지 판매하지 못하거나 리콜(Recall) 해야 하는 경우도 발생할 수 있으므로 라이센스의 의무사항을 명확히 이해하여 이와 같은 상황을 사전에 예방하는 것이 필수적이다. 그러나 이러한 위험 때문에 OpenSource 소프트웨어를 전혀 사용하지 않겠다는 결론을 내릴 필요는 없다. 독점소프트웨어 라이센스에서 규정하고 있는 의무사항에 비하면 OpenSource 라이센스가 요구하고 있는 내용이 결코 어려운 것이 아니므로, 오히려 이를 잘 이해하고 준수함으로써 OpenSource 소프트웨어의 장점을 적극 활용할 필요가 있다. 또한 몇몇 라이센스만이 독자 개발한 소스 코드의 공개를 요구하고 있기 때문에 이를 잘 분석한 후 사용한다면 문제 발생 소지는 거의 없을 것이다.
따라서 인터넷 상에서 자유롭게 구할 수 있는 오픈 소스를 다운로드받아 개발에 적용할 때는 반드시 라이센스의 요구 사항을 반드시 확인하여야 한다. 또한, 자체 판단이 불가능할 경우에는 외부 전문가에게 조언을 의뢰하여 개발 시작 전 해당 라이센스의 요구 사항과 오픈 소스 사용 목적을 확실히 분석하여야 한다. 이렇게 하는 것만으로도 충분히 올바르게 오픈 소스를 최대한 활용할 수 있으며, 나중에 발생할 수 있는 문제들을 사전에 차단할 수 있다.
3.1 공통적 준수사항
OpenSource 라이센스의 의무사항은 각각의 라이센스마다 조금씩 차이가 있지만 크게 나누어 보면 공통적으로 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이센스의 소프트웨어 조합시 조합 가능 여부 확인' 등이 있고 선택적으로는 '소스코드 공개', '특허관련 사항 준수' 등이 있다.
아래는 모든 OpenSource 소프트웨어에 공통적으로 적용되는, 항상 지켜야 할 사항들이다.
- 저작권 관련 문구 유지 : 앞에서 저작권이란 표현된 결과물에 대해 발생하는 권리이며 자동적으로 부여된다고 기술하였다. 소프트웨어의 소스코드에 대해서도 마찬가지이며 잘 관리되는 OpenSource 소프트웨어들의 경우 거의 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있는데 만약 이러한 개발자 정보를 임의로 수정하거나 삭제하여서는 안된다. 특히 GPL등 수정된 결과물을 다시 공개하도록 규정하고 있는 '상호주의(reciprocal)' 라이센스들의 경우 만약 소스코드 상에 개발자 정보가 수정/삭제된 채로 외부에 소스코드를 공개하였다가 그 사실이 밝혀질 경우 더 큰 문제가 발생할 수 있다. 상식적으로도 쉽게 판단 가능한 사항이므로 항상 준수하여야 한다.
- 제품명 중복 방지 : 사용하는 OpenSource 소프트웨어와 동일한 이름을 제품명이나 서비스 명으로 사용하여서는 아니된다. 특히 유명한 OpenSource 소프트웨어들일수록 해당 OpenSource 소프트웨어의 이름이 상표로서 등록되어 있는 경우가 많기 때문에(예: 리눅스) 더욱 조심하여야 한다. 다만 이러한 제품명/서비스명에 대한 결정이 개발자들에 의해 이루어지는 경우는 많지 않으므로 역시 상식적인 수준에서 판단하면 될 것이다.
- 서로 다른 라이센스의 조합 : 소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이센스가 상호 상충되는 경우가 있다. 예컨대 MPL 조건의 A코드와 GPL 조건의 B코드를 결합하여 ‘A+B’라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 ‘A+B’의 A부분을 MPL로 배포할 것을 요구하는 반면, GPL은 ‘A+B’ 전체를 GPL로 배포할 것을 요구하기 때문에, ‘A+B’프로그램을 배포하는 것은 불가능하게 된다. 이러한 문제를 가르켜 라이센스의 양립성(Compatibility) 문제라고 한다. 따라서 어떤 OpenSource 소프트웨어에 다른 OpenSource 소프트웨어를 섞을 경우 반드시 두개의 라이센스가 서로 호환되는지를 확인하여야 한다. 양립성문제는 자유/OpenSource 소프트웨어 진영에 심각한 문제점을 제기하였으며, 이를 해결하기 위한 노력도 다양하게 진행되고 있다. 예를 들어 모질라 프로젝트(Mozilla.org)에서는 프로젝트의 결과물을 MPL, GPL, LGPL의 3가지(triple) 라이센스로 배포하는 라이센스 정책을 채택하여, 라이센스의 양립성과 관련된 불확실성을 제거하고 모질라 코드를 GPL 또는 LGPL 기반의 응용프로그램에 사용할 수 있도록 하였다. Trolltech도 Qt 라이브러리에 대한 OpenSource 소프트웨어라이센스인 QPL과 GPL의 양립성 문제를 해결하기 위하여 QPL 및 상용라이센스 이외에 GPL을 추가하는 정책을 취하고 있다. 한편 최근 개정된 GPL 3.0은 Apache License 2.0과 양립가능하다.
- 사용 여부 명시 : 많은 OpenSource 라이센스들은 소스코드를 자유롭게 열람하고 수정 및 재배포할 수 있는 권리를 부여하는 한편, 소프트웨어를 사용할 때 해당 OpenSource 소프트웨어가 사용되었음을 명시적으로 표기하는 것을 의무사항으로 채택하고 있다. 이것은 마치 논문을 쓸 때 인용을 하는 것과 비슷하여, '이 소프트웨어는 OpenSource 소프트웨어인 무엇무엇을 사용하였습니다.'라는 식으로 사용 여부를 명확히 기술하라는 것이다. 사용자 매뉴얼이나 기타 매뉴얼을 대체하는 매체가 있다면 그곳에 기술하면 된다.
- 소스코드 공개 : OpenSource 라이센스에 따라서는 수정하거나 추가한 부분이 있을 때 해당 부분의 소스코드도 공개하여야 한다고 명시하는 경우가 있다. 이에 해당하는 라이센스는 GPL이 가장 유명하다. 그러나 정확한 공개 범위는 각각의 라이센스에서 정하고 있는 범위가 다르고, 소프트웨어를 개발하는 방법에 따라서도 달라질 수 있다. 자세한 내용은 다음 절의 쟁점부분을 참고하기 바란다.
- 특허 : 특허에 대한 기본적인 내용은, 만약 어떤 기술이 특허로 보호될 경우 해당 기술을 구현할 때 반드시 특허권자의 허락을 받아야 한다는 것이다. 이는 OpenSource 이냐 아니냐에 상관 없이 공통적으로 해당된다. 그러나 어떤 특허를 OpenSource 로 구현할 경우 해당 특허의 구현 결과는 OpenSource 라이센스를 따르게 되는 등, OpenSource 소프트웨어와 관련된 특허권의 문제는 보다 복잡하게 전개되고 있다. 특히 최근 소프트웨어특허가 급격히 증가하면서 문제가 심각해지고 있기 때문에, 새롭게 만들어지는 OpenSource 라이센스들에서는 특허관련조항을 포함하고 있는 경우가 많아지고 있다. 이와 관련된 자세한 내용도 다음 절의 쟁점부분을 참고하기 바란다.
3.2.1 GPL 2.0
GPL은 현재 가장 많은 OpenSource 소프트웨어가 채택하고 있는 라이센스이다. OpenSource 라이센스들 중에서 가장 많이 알려져 있고 의무사항들도 타 라이센스에 비해 엄격한 편이다. GPL의 주요 내용은 다음과 같다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실 명시
- 소프트웨어를 수정하거나 새로운 소프트웨어를 링크(Static과 Dynamic linking 모두)시키는 경우 GPL에 의해 소스 코드 제공해야 함.
- Object Code 또는 Executable Form으로 GPL 소프트웨어를 배포하는 경우, 소스 코드 그 자체를 함께 배포하거나 또는 소스코드를 제공받을 수 있는 방법에 대한 정보 함께 제공해야 함
- 자신의 특허를 구현한 프로그램을 GPL로 배포할 때는 GPL 조건을 준수하는 이용자에게는 로열티를 받을 수 없으며, 제3자의 특허인 경우에도 특허권자가 Royalty-Free 형태의 라이센스를 제공해야만 해당 특허 기술을 구현한 프로그램을 GPL로 배포하는 것이 가능
GPL에서 가장 논란이 되는 부분은 소스코드 공개 범위이다. 실제 소스코드 공개 범위는 다음 장의 쟁점 부분에서 확인하기로 한다. 소스코드를 공개하기 위해서는 소스코드를 CD Rom 등의 매체에 담아서 제품판매시 함께 배포하거나, 매뉴얼에 소스코드를 요청할 수 있는 연락처를 기입하여 두거나, 혹은 FTP 서버, 웹서버 등에 소스코드를 업로드해 두고 매뉴얼에 해당 주소를 기입하면 된다.
최근 특허에 관한 쟁점도 중요성이 증가하고 있는데, 자세한 내용은 다음 장의 쟁점 부분에서 설명한다.
3.2.2 LGPL 2.1
FSF가 일부 Library에 GPL보다 다소 완화된 형태인 GNU Lesser General Public License (LGPL)를 만들어 사용하고 있는 이유는 오픈 소스 소프트웨어의 사용을 장려하기 위한 전략적인 차원에서이다. 만일 상용 Library와 동일한 기능을 제공하는 Library에 GNU와 같은 엄격한 라이센스를 적용하게 되면, 개발자들이 Library의 사용을 꺼려할 것이다. 오히려 이미 널리 사용되고 있는 상용 Library와 동일한 기능을 제공하는 Library를 LGPL로 배포하여 그 사용을 장려하고 사실상의 표준으로 유도하는 한편, 관련된 다른 오픈 소스 소프트웨어를 보다 더 많이 사용할 수 있도록 하겠다는 것이 FSF의 전략이다. LGPL Version 2.1은 GNU ‘Library’ General Public License version 2.0의 후속 버전이다. 일부 한정된 Library에 대해서만 LGPL을 사용하려는 것이 FSF의 의도였으나 ‘Library’란 단어가 라이센스 이름에 포함되어 개발자들이 모든 Library를 위한 라이센스로 오인하는 경향이 있었다. 결국 이러한 오인을 방지하기 위하여 ‘Library’를 ‘Lesser’로 수정하였을 뿐 기본적인 내용은 동일하기 때문에 Version 2.1으로 표기한 것이다. LGPL의 주요 내용을 요약하면 다음과 같다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 LGPL에 의해 배포된다는 사실 명시
- LGPL Library의 일부를 수정하는 경우 수정한 Library를 LGPL에 의해 소스 코드 공개
- LGPL Library에 응용프로그램을 링크시킬(Static과 Dynamic Linking 모두) 경우 해당 응용프로그램의 소스를 공개할 필요 없음. 다만 사용자가 Library 수정 후 동일한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그램의 Object Code를 제공해야 함
- 특허의 경우 GPL과 동일함
3.2.3 BSD License
BSD(Berkeley Software Distribution) 라이센스는 GPL/LGPL보다 덜 제한적이기 때문에 허용범위가 넓다. 이는 BSD 라이센스로 배포되는 프로젝트가 미국 정부에서 제공한 재원으로 운영되었기 때문이다. GPL과의 차이점 중 가장 중요한 사항은 BSD 라이센스는는 소스코드 공개의 의무가 없다는 점이다. 따라서 BSD 라이센스의 소스 코드를 이용하여 새로운 프로그램을 개발하여도 새로운 프로그램의 소스 코드를 공개하지 않고 BSD가 아닌 다른 라이센스를 적용하여 판매할 수 있다. 주요 내용을 요약하면 다음과 같다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시
- 수정 프로그램에 대한 소스 코드의 공개를 요구하지 않기 때문에 상용 소프트웨어에 무제한 사용가능
3.2.4 Apache License
아파치 라이센스는 아파치 웹서버를 포함한 아파치 재단(ASF: Apache Software Foundation)의 모든 소프트웨어에 적용되며 BSD 라이센스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다. 다만 "Apache"라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 명시적으로 들어가 있고, 특허권에 관한 내용이 포함되어 BSD 라이센스보다는 좀더 법적으로 완결된 내용을 담고 있다. 특히 Apache License 2.0에서 특허에 관한 조항이 삽입되어 GPL 2.0으로 배포되는 코드와 결합되는 것이 어렵다는 문제가 었었는데, GPL 3.0(안)에서는 이 문제를 해결하여 아파치 라이센스로 배포되는 코드가 GPL 3.0으로 배포되는 코드와 결합하는 것이 가능해졌다.
3.2.5 MPL(Mozilla Public License)
MPL은 Netscape 브라우저의 소스코드를 공개하기 위해 개발된 라이센스이다. MPL은 공개하여야할 소스코드의 범위를 좀더 명확하게 정의하였다. GPL에서는 링크되는 소프트웨어의 소스코드를 포함하여 공개하여야 할 소스코드의 범위가 모호하게 정의되어 있지만 MPL에서는 링크 등의 여부에 상관없이 원래의 소스코드가 아닌 새로운 파일에 작성된 소스코드에 대해서는 공개의 의무가 발생하지 않는다. 따라서 MPL 소프트웨어 그 자체는 어떻게 하든 공개를 해야 하지만 원래 소스코드에 없던 새로운 파일들은 공개하여야 할 의무가 발생하지 않으므로 GPL에 비해 훨씬 명확하다. 주요 내용을 요약하면 다음과 같다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 MPL에 의해 배포된다는 사실을 명시
- MPL 코드를 수정한 부분은 다시 MPL에 의해 배포
- MPL 코드와 다른 코드를 결합하여 프로그램을 만들 경우 MPL 코드를 제외한 결합 프로그램에 대한 소스코드는 공개할 필요가 없음
- 소스코드를 적절한 형태로 제공하는 경우, 실행파일에 대한 라이센스는 MPL이 아닌 다른 것으로 선택가능
- 특허기술이 구현된 프로그램의 경우 관련 사실을 ‘LEGAL’파일에 기록하여 배포
3.3.1 소스코드 공개 여부
앞에서 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의 특징은 다른 OpenSource 소프트웨어 라이센스와 비교할 때 명확히 드러난다. 예를 들어 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)도 사용자프로그램이 시스템 콜을 이용하는 것과 크게 다르지 않기 때문에 소스코드를 제공할 필요가 없는 것으로 보고 있다.
- 리눅스 커널은 부적절한 예제입니다. 리눅스 커널의 COPYING 파일의 내용은 GPL의 "derived work"가 어디까지인가에 대해 명확히 하는 부분이지, GPL에 따로 예외를 부여하는 조항이 아닙니다. 또 커널 모듈이 GPL이 아닐 수 있다는 내용도 리눅스 토발즈나 다른 리눅스 개발자의 생각과 다르며, 아래에 있는 내용과도 다릅니다. -- cwryu 2007-07-08 08:42:26
두 번째 사례는 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 조건의 자바 플랫폼을 이용한 응용프로그램도 소스코드를 공개하지 않고 배포할 수 있다.3.3.2 특허권
GPL, LGPL, MPL, Apache 라이센스 등의 OpenSource 라이센스는 특허와 관련된 조항들을 가지고 있는데, 각각의 경우를 ⅰ) 라이센서(Licensor)의 특허인 경우, ⅱ) 제3자의 특허인 경우, ⅲ) 라이센시(Licensee)의 특허인 경우로 구분하여 설명할 수 있다. 다만 LGPL은 특허와 관련해서는 GPL과 동일하게 규정하고 있으며, BSD는 특허에 관한 규정을 두고 있지 않기 때문에 이하에서는 생략한다.
- 라이센서(Licensor)의 특허인 경우 : 소프트웨어에 대해 저작권을 가지고 있는 주체가 특허권을 함께 가지고 있는 경우이다. MPL과 Apache 라이센스는 이와 같은 경우 라이센서가 소프트웨어를 OpenSource 라이센스조건으로 배포하는 경우 관련 특허권의 라이센스도 무상으로 제공하는 것으로 규정하고 있다. 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’이라는 이름의 파일을 추가하여 어떠한 특허가 문제되고 있는지, 어떤 사람이 클레임을 제기하고 있는지에 대한 사항을 자세히 기록하도록 하고 있다.
3.3.3 듀얼 라이센스
또한 일부 OpenSource 소프트웨어는 복수의 라이센스하에 배포되는 경우가 있다. 이를 주로 듀얼 라이센스(dual license)라고 하며, 이런 경우는 주로 오픈 소스 소프트웨어를 상업적 목적으로 이용할 뿐만 아니라 OpenSource 커뮤니티와의 협력을 위한 경우가 대부분이다. 하나 이상의 라이센스가 있는 OpenSource 소프트웨어를 이용할 경우, 이용자는 사용 목적에 가장 잘 부합하는 라이센스 하에 배포되는 소스 코드를 선택할 수 있다. 대표적인 사례로는 MySQL, Trolltech의 Qt 라이브러리 등이 있다.
3.4 주요 OpenSource 소프트웨어 사례
앞서 살펴본 OpenSource 라이센스에 대한 이해를 바탕으로 실제 많이 사용하고 있는 OpenSource 소프트웨어들 중 특별히 기억해 두어야 할 라이센스 관련 이슈에 대해 살펴보자.
3.4.1 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)에서 구현하는 것이 바람직하다.
커널 모듈 인터페이스에는 MODULE_LICENSE()라는 것이 있어서, 여기에서 커널 모듈의 라이센스를 GPL로 지정하면 EXPORT_SYMBOL_GPL()로 정의한 "GPL 심볼"을 사용할 수 있다. 커널 모듈의 라이센스를 GPL로 하지 않으면 "GPL 심볼"이 아닌 심볼만을 사용해야 한다. 이 인터페이스를 가이드라인으로 커널 모듈이 GPL이 되어야 하는 지 여부를 어느정도 판가름할 수 있다. 하지만 이 "GPL 심볼"만 피해가면 GPL로 안 해도 된다고 오해해서는 안 된다. 이와 같은 장치는 반드시 GPL이 되어야 하는 지 명확하게 하기 위한 목적일 뿐이다. 즉 "GPL 심볼"을 사용한 모듈은 반드시 GPL이 되어야 하지만, GPL 심볼을 사용하지 않도록 피해간다고 해서 GPL이 아니어도 된다는 의미는 아니다. 심볼 사용 여부와 관계없이 GPLv2의 2항에 따라 (If identifiable sections of that work ... can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.) 해당 커널 모듈이 리눅스 커널과 얼마나 독립적인가가 GPL 여부 판단의 문제가 된다. 실제로 GPL이 아닌 상태로 배포되고 있거나 배포되었던 커널 모듈들의 예로, Open Sound System (멀티 플랫폼, 최근에 GPL로 전환되기 전), NVidia/ATI의 비디오 카드 드라이버 (MS-Windows에서 포팅), AFS (유닉스에서 포팅) 등을 보면, 그 개발 과정이나 의존하는 플랫폼이 리눅스와는 독립적으로 이루어졌다고 볼 수 있다. (하지만 이들 역시 약간 애매한 상태에 있는 게 사실이다.)
3.4.2 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는 소스 코드 공개를 요구하지 않으며, 만약 원본 혹은 수정된 소스 코드를 공개하고자 하면 위에서 언급한 사항들만 준수하면 된다.
3.4.3 MySQL
MySQL은 현재 가장 인기 있는 관계형 데이터베이스 서버로서 사용자는 GPL 라이센스나 일반 상용 라이센스 둘 중 한가지를 선택할 수 있는데, 상용 라이센스는 GPL 라이센스의 여러가지 요구사항들(소스코드 공개 등)을 지키기 어려운 경우에 선택할 수 있으므로 일반적인 상용 라이센스 판매를 통해 수익을 내고 있다. 이러한 라이센싱 모델을 듀얼 라이센스라고 하며 MySQL은 듀얼 라이센싱 모델의 대표적인 사례로서 종종 언급된다. MySQL의 이같은 듀얼 라이센싱 모델에 대해서 좀더 살펴보면 다음과 같다.
우선 OpenSource 프로젝트 목적으로 MySQL을 이용할 경우를 살펴보자. 만약, 이용자가 MySQL 라이브러리를 이용하여 개발한 애플리케이션을 GPL 라이센스 하에 배포한다면, 이 경우 MySQL은 GPL 라이센스가 적용된다. 즉, 이용자가 기꺼이 직접 개발한 애플리케이션을 GPL하에 배포하기 때문에 MySQL 라이브러리 역시 GPL이 되더라도 문제가 발생하지 않을 것이다. 또한, 이용자가 GPL이 아닌 Open Source Initiative에서 인정한 라이센스 하에 직접 개발한 애플리케이션을 배포할 경우에도 특별 예외 조항을 두어 라이센스 충돌이 발생하지 않도록 하였다. 즉, 비록 GPL 라이브러리를 이용하더라도, 직접 개발하였거나 GPL 라이브러리와 독립된 부분으로 인정이 되는 애플리케이션의 소스 코드는 GPL이 아닌 다른 OpenSource 라이센스로 배포할 수 있도록 하였다. GPL의 원칙을 따를 경우, GPL 라이브러리에 기반한 애플리케이션 전체 소스 코드가 GPL이 되기 때문에 소스 코드 공개 의무가 발생한다. 한편 GPL 등OpenSource 라이센스조건을 따르지 않는 형태로 사용하고자 하는 경우에는 MySQL AB사로부터 Commercial License를 받아야 한다.
그러나 한가지 주지하여야 할 것은 GPL의 의무사항은 소프트웨어를 배포할 때 발생하는 것이므로 만약 MySQL을 다운로드해서MySQL과 연동되는 웹사이트 등을 만들어서 서비스만 하는 경우는 MySQL을 직접 배포하지 않는 것이므로 GPL의 의무사항이 발생하지 않는다는 것이다. 예를 들어 인터넷 포털 업체들은 MySQL의 상용 버전을 구입하지 않고 GPL 버전을 사용하면서 MySQL이나 관련 소프트웨어의 소스코드를 공개하지 않고 있다.
3.4.4 Apache
Apache 소프트웨어들은 현재 ASF에서 자체적으로 개발한 Apache License Version 2.0하에 배포되고 있다. Apache License에 따르면, 누구든 자유롭게 Apache 소프트웨어를 다운받아 부분 혹은 전체를 개인적 혹은 상업적 목적으로 이용할 수 있다. 또한, 재배포 시에도 원본 소스 코드 혹은 수정한 소스 코드를 반드시 포함시킬 것을 요구하지 않는다. 다만, 재배포하고자 할 경우에는 Apache License, Version 2.0을 포함시키고 ASF에 개발된 소프트웨어임을 명확히 밝힐 것을 요구한다. 아울러 ASF가 승인하지 않는 ASF 공식 마크를 임의로 사용할 수 없다.
3.4.5 Mozilla Firefox
Firefox는 오픈 소스 소프트웨어이며 현재 MPL, GPL, LGPL 세 가지 라이센스 하에 배포되고 있다. 이 세가지 라이센스는 모두 공통적으로 누구나 소스 코드를 보고 수정하며 재배포하는 것을 허용한다. 원래 Firefox는 MPL에 의해 배포되었다. 그런데 파생물의 상업적 이용을 제한적으로 허락하는 MPL은 GPL 혹은 LGPL과 호환될 수 없기 때문에 FSF로 부터 많은 비난을 받았다. 이 문제를 해결하기 위해 Mozilla는 Firefox를 MPL, GPL, 그리고 LGPL하에 다시 라이센싱하였다. 이 후, 개발자들은 이 세 가지 라이센스 중 자신들의 목적에 가장 잘 부합하는 라이센스를 선택할 수 있게 되었다. 그런데 하나 유의할 점은, Firefox의 일부 상용 컴포넌트를 포함하고 있기 때문에, 이 상용 컴포넌트는 위에서 언급한 세 가지 라이센스의 적용을 받지 않는다. 대신, 이들은 Mozilla End User License Agreement(EULA)의 제한을 받고 있다.
3.4.6 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.와 접촉해서 별도의 라이센스를 받아야만 한다.
4.1 OpenSource 소프트웨어관련 정책의 수립
최근 국내외 많은 기업들이 OpenSource 소프트웨어를 활용하여 비즈니스를 수행하고 있다. 선진 기업들은 기업 외부의 OpenSource소프트웨어를 도입하여 활용할 뿐만 아니라, OpenSource 개발방법론을 통해 기업에서 필요한 소프트웨어를 개발하기도 하며, 그 과정에서 외부에 있는 OpenSource 커뮤너티를 적극 활용하기도 한다. 하지만 국내 기업들의 대다수는 OpenSource 소프트웨어관련 정책을 따로 마련하지 않고 개발자들 수준에서 기업외부에 존재하는 OpenSource 소프트웨어를 단순 활용하는 수준에 머물러 있는데, 향후 OpenSource 소프트웨어에 대한 활용의 필요성이 지속적으로 증가할 것이라는 점을 고려한다면 개별기업차원에서 OpenSource소프트웨어관련 정책을 수립할 필요성이 있다. OpenSource 소프트웨어 관련 정책을 수립할 때에는 개별기업이 속한 시장의 상황,OpenSource 소프트웨어의 발전정도, 개별기업들의 기술수준 및 비즈니스모델 등을 고려할 필요가 있다.
개별기업에서 OpenSource 를 활용할 경우에는 OpenSource 의 장/단점을 명확히 이해한 상태에서 활용 여부 및 방향을 결정하여야 할 것이다. 일반적으로 OpenSource 소프트웨어는 다음과 같은 장점을 가지고 있다.
- Low Entry Cost : 일반적으로 OpenSource 는 Web 상에서 무료로 다운로드 및 소스 코드 수정/ 재배포가 가능한 것이 특징이다. 따라서 초기 개발을 시작하기 위한 비용이 적게 요구된다는 장점이 있다.
- Fast, Flexible Development : OpenSource 커뮤니티는 보통 최신 기술 정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운영되기 때문에 독점 프로그램에 비해 기술 발전 속도가 빠르다.
- Open Formats & Protocols : OpenSource 는 주로 Open Formats 또는 Protocols을 사용하기 때문에 서로 다른 소프트웨어간 상호 연동성이 보장되는 장점이 있다. 모든 기기들이 서로 다른 Network을 통해 하나로 연결되는 Ubiquitos 시대에는 필수적인 요소로 볼 수 있다. 또한 OpenSource 운동의 주 원인 역시 상용 프로그램들간의 비호환성을 해결하는 것이다.
- Reliability & Stability : OpenSource 의 개발 과정을 볼 때, 전세계에 있는 수많은 우수한 개발자들이 직접 개발과 Debugging 과정에 참여하기 때문에 In-house에서 폐쇄적으로 개발되는 독점 프로그램에 비해 비교적 안정적으로 동작한다는 평이 일반적이다. 하지만 이러한 Reliability와 Stability는 많은 개발자들의 적극적인 참여가 있을 때에만 가능한 것이기 때문에, 사용하고자 하는 OpenSource 의 개발 과정을 주의깊게 살펴볼 필요가 있다.
- Networking : OpenSource 가 확산된 가장 큰 이유가 다양하고 강력한 Networking 기능 지원이라 해도 과언이 아닐 것이다. 대표적으로 Apache는 전세계 웹 서비스의 절반 이상을 차지하고 있을 정도이다. 또한 Open Source Networking Solution은 대부분 상용 프로그램과 호환되기 때문에 상품화에도 아주 잘 활용될 수 있을 것이다.
- 애플리케이션의 부족: 대부분의 사용자들은 Windows 기반의 GUI(Graphical User Interface)를 갖고 있는 Application에 익숙해 있지만, 이에 버금가는 Linux 기반의 Application이 많이 부족한 것이 현실이다. 또한 Linux 기반으로 개발된 많은 Application들은 Windows 기반 Application들과 호환되지 않는 문제점도 있다.
- 빈약한 문서: 상용 프로그램에 비해 OpenSource 는 체계적인 문서를 갖고 있지 못한 단점이 있다. 이는 경우에 따라서는 개발과정의 지연을 초래할 수도 있기 때문에 활용하고자 하는 OpenSource 가 얼마만큼 문서화가 잘 되었는지도 잘 살펴보아야 한다.
- 불확실한 개발 로드맵: OpenSource 는 영리를 목적으로 하는 회사에서 개발되는 것이 아니라, 자발적 참여를 바탕으로 Web 상에서 자유롭게 개발되는 것이 특징이다. 그렇기 때문에 독점 프로그램에서 볼 수 있는 Roadmap을 기대하기 힘든 면이 있다.OpenSource 의 이러한 단점은 OpenSource 를 활용하는 개발 과제의 Roadmap에 까지 영향을 미칠 수 있기 때문에 활용하고자 하는 OpenSource 의 향후 개발 계획이 얼마나 체계적으로 세워져 있는지도 고려해야 한다.
- 지적 재산권: OpenSource 에 기업이 보유한 특허 및 소스코드를 포함시킬 경우 OpenSource 라이센스는 일반적으로 Royalty-free를 요구하고 있다. 따라서 Royalty-free를 원치 않을 경우에는 해당 OpenSource 를 사용할 수가 없으며, 또한 사용 후 Royalty를 주장하게 되면 해당 OpenSource 에 대한 사용 권한이 박탈되는 경우가 일반적이다. 따라서 OpenSource 를 활용하여 특허를 구현하거나 기존 소스코드를 포함하고자 할 경우, 반드시 Royalty에 대한 입장을 명확히 하여야 할 것이다.
4.2 OpenSource 라이센스관리를 위한 프로세스/조직의 구축
오픈 소스를 활용하기 위해서는 독점소프트웨어와 마찬가지로 반드시 해당 OpenSource 의 라이센스에 대한 준수가 필수적이다. 하지만 OpenSource 라이센스에서 강제하고 있는 내용에 대해서 개발자 및 관리자들의 이해가 아직도 많이 부족한 것이 현실이다. 자칫 잘못하면 라이센스 위반으로 이미 판매중인 제품을 리콜하거나, 소스코드를 공개해야 하며, 개발중인 제품을 아예 처음부터 다시 개발해야 하는 상황을 초래할 수도 있으므로 체계적인 프로세스를 수립하고 이를 담당할 관련 조직을 구축하는 것이 필요하다.
개발이 끝난 이후에 OpenSource 라이센스관련 문제가 발견된다면 수정에 많은 시간과 비용이 소요되므로 과제 계획 단계부터OpenSource 라이센스문제를 고려할 필요가 있다. 또한 개발이 진행되면서도 단계별로 준수해야 할 사항들을 정의하고 반드시 체크해야만 한다. 본 문서에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 S/W 개발프로세스를 다음과 같이 표준화/단순화하였다.
'기획(SW Design)' -> '구현(Implementation)' -> '검증 (Verification)' -> '제품화(Production)'
4.2.1 기획(S/W Design)단계
OpenSource 라이센스 관련 문제를 피하는 가장 좋은 방법은 개발 기획 시점부터 이를 고려하는 것이다. 우선 해당 과제에OpenSource 를 활용할 것인지의 여부를 판단하여야 하며, 구체적으로 어떤 프로그램을 사용할 지를 판단하여야 한다. OpenSource의 특성상 Web 상에 여기저기 흩어져 있지만, 쉽게 OpenSource 에 관한 정보를 찾을 수 있는 곳으로는 Freshmeat.net,SourceForge, OSDir.com, BerliOS, Bioinformatics.org 등을 들 수 있다. 이와 같은 사이트들은 대부분 License별 OpenSource 분류 항목을 두고 있기 때문에 쉽게 해당 프로그램의 라이센스를 확인할 수 있을 것이다.
기획 단계의 마지막으로 해당 S/W Component별로 소스코드 공개가능여부를 판단하여야 한다. GPL등 소스코드 공개 의무가 발생하는 OpenSource 소프트웨어를 사용할 경우에는 과제 결과물의 소스코드 공개가 요구되기 때문에, 경우에 따라서는 S/W 구현 방법을 달리해야하기 때문이다. 소스코드의 공개가능 여부에 대한 판단 기준으로 다음의 사항을 참조할 수 있을 것이다.
- Maintenance : 소프트웨어의 경우 하드웨어와 달리 개발 후 지속적 Upgrade 및 Debugging과 같은 Maintenance 과정이 중요하다. 이러한 Maintenance 과정은 상당한 Resource를 요하기 때문에 Maintenance를 직접 할 것인지에 대한 고려가 필요하다. 개발한 소스 코드를 OpenSource 커뮤니티에 공개하고, 이를 바탕으로 오픈 소스 커뮤니티를 통한 Maintenance 방법 역시 경우에 따라 아주 효율적일 수도 있을 것이다.
- Fast Development : OpenSource 의 개발 모델 중 가장 특징적인 것이 바로 ‘Release Early and Often’을 통한 ‘Parallel Development and Debugging’이 가능한 것이다. 이를 통해 OpenSource 는 빠른 개발 속도를 가능케 하고 있다. 이러한 모델을 Resource가 부족한 개발 과제에 적용하면 보다 효율적이고 빠른 개발이 가능할 것이다.
- Reliability 확보: S/W의 신뢰성 확보의 가장 좋은 방법은 다양한 사용자들이 다양한 환경에서 해당 프로그램을 사용하면서 발견되는 문제점을 신속히 수정하는 것이다. 이런 측면에서 볼 때 OpenSource 커뮤니티를 잘 활용하면 S/W Reliability 확보에 상당한 도움을 얻을 수 있을 것이다.
- 차별화 유지 어려움 : 소스 코드를 공개하게 되면 그 소스 코드는 경쟁사에게도 공유되는 것이기 때문에 결국 제품의 차별화 확보가 불가능하게 되는 단점이 있다.
- 지적재산권 확보의 어려움: 기업이 보유한 특허를 구현하여 소스코드를 공개하는 것은 결국 모든 사용자들에게 Royalty-free의 조건으로 특허를 공개하는 것이나 마찬가지가 된다.
- 특허 침해 소송 제기 가능성 증가: 소스 코드가 공개되어 있으면 누구든 그 소스 코드를 볼 수 있기 때문에 특허 침해 소송 제기 가능성이 증가하게 되는 문제점이 발생할 수 있을 것이다.
4.2.2 구현(Implementation)단계
자체 개발한 소스 코드를 공개해도 무방한 경우는 특별히 구현 방법에 신경 쓸 필요가 없다. 단, 소스 코드를 공개할 경우 회사보유의 지적재산권을 포함시키지 않도록 주의할 필요가 있다. 그러나 소스 코드 공개를 원하지 않을 경우는 사용하는 OpenSource 의 라이센스 강제 사항과 활용하고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한 경우가 발생할 수 있기 때문에, 이럴 경우는 라이센스 혹은 법률 전문가에게 의뢰하여 정확한 판단을 받아야 할 것이다.
4.2.3 검증(Verification)단계
개발이 완료된 후에는 개발 결과물인 소스 코드에 대해 실질적인 검증 작업이 필요하다. 개발 계획서 그 자체로는 라이센스 이슈가 없었더라도 실제 구현 과정에서 개발자가 OpenSource 라이센스에 대한 검증없이 사용한 경우가 있을 수 있기 때문이다. 최근에는 특정한 소스코드가 OpenSource 코드와 일치하는지를 검증하여 주는 프로그램을 활용하는 사례가 증가하고 있다.
4.2.4 제품화(Production)단계
이 단계에서는 사용된 OpenSource 소프트웨어들을 라이센스별로 분류하고 각 라이센스에서 준수해야 할 사항들이 실제로 제품에 반영될 수 있도록 하여야 한다. 앞에서 OpenSource 의 라이센스 의무사항은 크게 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이센스 조합', '사용 여부 명시', '소스코드 공개', '특허' 등이 있다고 기술하였는데 이중에서 '저작권 관련 문구 유지', '제품명 중복 방지', '특허' 등은 기획 및 구현 단계에서 확인되어야 할 사항이고, 제품화단계에서는 '소스코드 공개', '사용 여부 명시' 등을 확인할 필요가 있다.
소스코드 공개는 공개 의무가 발생하는 소스코드를 제품을 배포할 때 함께 배포한다거나(예: CD롬 등), 연락처를 기재하고 해당 연락처로 요청하게 한다거나, 혹은 별도의 웹사이트 등에 업로드하여 두고 받아 가도록 하는 등의 방법이 가능하다.
사용 여부 명시는 해당 의무가 발생하는 소프트웨어에 대한 설명을 사용자 매뉴얼 등에 기재함으로써 이루어지는데, GPL/LGPL/MPL에서 이를 요구하고 있다. 이와 같은 경우 OpenSource 를 사용하였음을 숨기지 않고 고객에게 그 사실을 정확히 전달할 필요가 있다.
5.1 GPL 개정의 배경과 경과
1991년 배포된 GPL 2.0은 2007년까지 16년 동안 수정 없이 사용되었다. 소프트웨어관련 기술과 이를 둘러싼 시장, 제도의 변화속도에 비추어보면 상당히 오랜 기간 동안 개정되지 않고 사용된 것으로 평가할 수 있다. 하지만 1990년대 초반 오픈소스소프트웨어가 널리 사용되기 이전에 만들어진 GPL 2.0은 최근의 변화된 상황에서 조금씩 그 한계를 드러내고 있었다. 예컨대 자유/오픈소스소프트웨어운동이 미국에서 시작되었으며 GPL 2.0도 미국의 법제도를 기반으로 만들어졌는데, 현재 자유/오픈소스소프트웨어 및 GPL은 전세계적으로 사용되고 있으며, 그에 따라 각국 법제도의 차이를 반영할 필요성이 제기되었었다. 이밖에 소프트웨어특허의 확대와 그에 따른 위험의 증가, 자유/오픈소스소프트웨어 라이선스들의 증가와 양립성 문제, DRM 기술의 확대적용과 법에 의한 보호, 네트워크서버기반 소프트웨어의 증가, P2P 등 새로운 기술의 등장 등 일련의 환경변화로 GPL 개정의 필요성은 더욱 증대되었다.
하지만 자유/오픈소스소프트웨어와 GPL의 사용자 층이 넓어진 만큼 개정작업은 더욱 복잡해졌다. 1991년 GPL 2.0이 발표될 당시 리차드 스톨만이 몇몇 법률가와 개발자들로부터 의견을 수렴하긴 했었지만, GPL의 개정에 있어 이번과 같은 공식적인 의견수렴절차나 논의가 필요한 것은 아니었다. GPL 2.0이 발표되고 FSF는 곧바로 GNU 프로젝트의 결과물들을 GPL 2.0으로 교체하였으며, 리누스 토발즈도 리눅스커널에 GPL 2.0을 채택하였었다. 하지만 이번의 상황은 그렇지 못했다. GPL은 전세계 수만의 프로젝트에서 사용되고 있었으며, PC․서버 운영체제로부터 휴대폰, PDA, 셋탑박스, 홈네트워킹 장비 등의 임베디드소프트웨어분야에서 광범위하게 사용되고 있었다. 다시 말하면 더 이상 FSF의 GNU프로젝트에서만 사용되는 라이선스가 아니며, 그야말로 자유/오픈소스소프트웨어에 관계된 수많은 기업과 사람들이 지켜야 할 행동규범의 지위를 갖게 된 것이다.
FSF는 지난 수년 동안 자유/오픈소스소프트웨어 커뮤니티, 산업계, 학계 등과 공식적으로 또는 비공식적으로 GPL의 개정에 대해 논의해 왔으며, 이를 바탕으로 마련한 첫번째 안(First Discussion Draft)을 2006년 1월 발표하였다. 초안의 발표와 함께 다양한 의견을 수렴하기 위한 토론위원회 등의 공식적인 프로세스를 만들었다. 이를 바탕으로 인터넷을 통한 의견 수렴, 수차례의 국제 컨퍼런스를 거쳐 2006년 7월에 두번째 안을, 2007년 3월과 5월 각각 세 번째 안과 네 번째 안을 발표하였으며, 지난 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과 관련된 내용이 추가되었다. 또한 오픈소스소프트웨어 라이선스의 급격한 증가와 양립성 문제를 완화하고자 제7조에서 GPL에 부가적인 조건을 추가할 수 있도록 규정하고 있다. 아울러 제11조 등은 소프트웨어특허문제, 제13조에서는 Affero GPL과의 양립성문제에 대처하고자 새롭게 추가된 내용이다.
GPL의 개정과정에서 가장 논란이 되었던 내용은 DRM(또는 ‘Tivoization’) 관련 쟁점, 특허권의 취급, 오픈소스라이선스간 양립성, 네트워크서버형태로 GPL 소프트웨어를 이용하는 경우의 처리 등이다. 이 밖에 소스코드의 범위를 명확히 하고, 새로운 용어를 정의하는 등의 수정이 있었다.
5.2 Tivoization과 DRM
미국의 Tivo라는 회사는 케이블방송 또는 위성방송 등의 방송프로그램을 하드디스크에 녹화하거나, 경우에 따라서는 개인 PC나 DVD 등에 저장할 수 있도록 하는 DVR(digital video recorder)제품을 시장에 출시하여 성공하였다. 한편 해당 제품에는 리눅스커널 등 GPL 소프트웨어가 포함되어 있었기 때문에 Tivo는 GPL 2.0의 규정에 따라 관련 소스코드를 이용자들에게 제공하였다. 그런데 일부 이용자들이 해당 소스코드를 수정하여 다시 Tivo의 제품에 포팅하였으나 정상작동하지 않았다. 이는 Tivo사가 이용자들이 해당 제품을 수정하여 사용하는 것을 허용하지 않았기 때문이다.
이상과 같은 Tivo의 정책에 대해 스톨만은 Tivo가 GPL을 악용하고 있다고 주장하였다. GPL의 근본 목적은 이용자들이 해당 소프트웨어를 자유롭게 수정하여 사용할 수 있도록 하는 것임에도 불구하고 Tivo는 이를 막고 있다는 것이다. 스톨만은 이와 같은 GPL의 남용행위를 Tivoization이라고 이름짓고, 이를 방지하기 위해 GPL 3.0에 다음과 같은 2가지 종류의 규정을 마련하였다.
첫 번째는 GPL 코드를 특정한 사용자제품(User Product)에 포함시키거나 혹은 그와 함께 배포하는 경우에는 해당 소스에 설치 정보(Installation Information)를 함께 제공해야 한다는 것이다. 이 때 ‘사용자 제품(User Product)’이란 통상적인 소비자 제품이나 집안에서 쓰일 목적으로 설계되었거나 판매되는 제품을 말하며, ‘설치 정보(Installation Information)'란 소프트웨어를 수정하여 해당 제품에 설치하고 실행하는 데 필요한 방법(methods), 절차(procedures), 인증키(authorization keys) 혹은 여타 정보 모두를 의미한다. 다만 소프트웨어가 ROM에 설치된 경우처럼, 해당제품의 제조업체나 여타 제3자도 수정된 코드를 제품에 설치할 수 없는 경우에는 설치정보를 제공하지 않아도 된다. 또한 사용자가 설치하거나 수정한 저작물 및 해당 제품에 대한 지원서비스나 보증, 업데이트를 계속해서 제공할 필요는 없다. 그리고 사용자의 수정으로 인해 네트워크의 작동에 실질적이고 부정적인 영향을 끼치거나, 네트워크를 통한 통신 규칙 및 프로토콜을 위반하는 경우에는 네트워크에 대한 접속을 거부할 수 있다.
사용자제품에 대한 GPL 3.0의 현행규정은 초안에서의 내용보다는 상당히 완화된 것이다. 개정 과정에서 리누스 토발즈를 포함한 리눅스커널 개발자들은 DRM 기술이 미디어기업들에 의해 남용될 가능성이 있다는 점은 인정하지만, GPL 3.0의 DRM 관련 규정을 적용하게 될 경우 최종이용자에 대한 제한을 포함하는 어떠한 라이선스도 받지 못하는 결과를 초래할 것이라고 주장하였다. 또한 어떠한 행위가 GPL의 남용에 해당하는지를 결정하는 것은 본질적으로 정치적인 문제인데, 정치적인 목적 때문에 FSF가 저작권을 가진 프로그램을 GPL 3.0으로 전환할 경우 FSF 스스로 신뢰를 깨뜨리는 것이라고 주장하였었다. 결국 이와 같은 비판을 어느 정도 수용하여 현행규정으로 수정한 것이다.
Tivo와 관련하여 GPL 3.0에 도입된 두 번째 규정은, DRM과 관련하여 각국의 법률에 의해 보호되는 이익을 포기하도록 한 것이다. DRM은 ”Digital Rights Management"의 약칭으로 콘텐츠 제공자의 권리와 이익을 안전하게 보호하기 위하여 적법한 사용자만 허용된 사용권한에 따라 콘텐츠를 사용하도록 하는 기술이다. 그러나 다른 한편으로 DRM은 이용자의 행위를 제한하는 측면이 있는데, GPL 3.0의 첫 번째 토론안에서는 이와 같은 측면을 강조하여 DRM 관련 규정의 제목을 “Digital Restrictions Management"로 표기했었다. FSF는 미국, 유럽 기타 각국이 DRM 기술을 회피하는 행위에 대해 민사책임을 부과하거나, 심지어 형사처벌을 하도록 하는 법률을 제정하는 것에 대해 비판해 왔다. 아울러 이용자들의 자유를 보호하는 것을 최우선의 목표로 하고 있는 GPL 프로그램이 이와 같은 DRM으로 사용되고 있다는 것에 심각한 우려를 표명하였다. 이와 같은 FSF의 GPL에 대한 반감은, 결국 현행 규정과 같이 GPL 3.0이 적용되는 프로그램을 포함한 DRM은 법적 보호를 받지 못하도록 하는 결과로 나타났다.
5.3 특허권의 취급
오픈소스소프트웨어, 특히 FSF 등 자유소프트웨어(Free Software)진영이 소프트웨어특허에 대해 가지는 시각은 GPL 서문에 잘 나타나 있다. 이에 따르면 현재 소프트웨어특허로 인하여 자유소프트웨어가 끊임없이 위협을 받고 있는 상황이며, 만약 자유소프트웨어의 배포자들이 개별적으로 특허를 취득하는 경우 해당 프로그램이 사유(proprietary)소프트웨어가 될 가능성이 있으므로, FSF는 이러한 문제에 대처하기 위해서 GPL 조건의 소프트웨어를 이용하는 모든 사람들이 무료로 자유롭게 사용할 수 있는 특허만을 자유소프트웨어에 포함시키고자 한다는 것이다. 이와 같은 기본인식에도 불구하고 GPL 2.0에는 특허권에 관한 내용이 짧게 언급되어 있을 뿐인데, 비록 자유소프트웨어진영이 소프트웨어특허에 대해 반대하고 있긴 하지만, 소프트웨어특허의 인정여부는 결국 각국의 입법 또는 법해석에 관한 문제이다. 따라서 GPL의 차원에서는 GPL 조건의 소프트웨어에 관련 특허가 부여되었거나 앞으로 부여될 수 있다는 현실을 받아들일 수밖에 없다. 특허권에 관한 GPL 2.0에서의 내용을 요약하면, 첫째, 특허권자 자신이 특허기술을 구현한 소프트웨어를 GPL로 배포하였다면, GPL 서문이나 제7조의 해석상, GPL 조건을 준수하면서 해당 소프트웨어를 사용하는 이용자에게는 특허권을 주장하지 않겠다는 서약을 한 것으로, 또는 특허라이선스를 묵시적으로 허락한 것으로 해석할 수 있다. 둘째, 소프트웨어에 제3자의 특허기술이 포함된 경우, 특허권자가 모든 GPL 이용자에게 무상의 라이선스를 제공하는 경우에만 해당 소프트웨어를 GPL로 배포할 수 있다. 다시 말해 프로그램의 복제물을 제공받은 임의의 제3자가 해당 프로그램을 무상으로(royalty-free) 사용하거나 재배포할 수 없는 경우, 해당 소프트웨어를 GPL로 배포하는 것은 불가능하다.
1980년대 이후 미국을 중심으로 소프트웨어를 특허권에 의해 보호하려는 경향이 높아졌으며, 특히 1990년대 후반부터 소프트웨어관련 특허권의 수가 급격히 증가하였다. 그에 따라 GPL 2.0의 한계를 지적하고 소프트웨어 특허에 대한 대책이 필요하다는 요구가 오픈소스소프트웨어 커뮤니티 내부에서 꾸준히 제기되었다. 이와 같은 문제제기는 GPL 3.0으로의 개정과정에서 다양한 논의로 연결되었으며, 가장 많은 논쟁과 수정안의 제출로 이러졌다. GPL 3.0에서의 특허권에 관한 논의와 주요내용은 ⅰ) 라이선서 등 전방(upstream)의 특허권, ⅱ) 라이선시 등 후방(downstream)의 특허권, 기타 ⅲ) 제3자가 가지는 특허권의 경우로 나누어 볼 수 있다.
첫째, 라이선서 등이 특허권에 의한 소송을 제기할 수 있는 위험과 관련하여, GPL 2.0에서는 명시적 규정을 두고 있지는 않았지만 제7조 등의 해석상 라이선서가 자신이 가지는 특허권을 ‘묵시적으로’ 허락하는 것으로 해석할 수 있음은 앞에서 본 바와 같다. 하지만 미국법상으로는 이러한 해석이 가능하지만, 모든 국가가 그와 같지는 않을 것이라는 의견이 있었다. 이러한 문제제기를 받아들여 GPL 3.0은 기여자(Contributor)의 경우 자신이 기여한 부분(Contributor Version)에 대해서는, 비차별적이고 무료인 (non-exclusive and free royalty) 특허 라이선스를 허락하는 것으로 규정하였다.
개정과정에서 이와 관련하여 가장 쟁점이 되었던 부분은, 개발자 및 기여자이외에 GPL 프로그램의 단순한 재배포자(distributor)도 동 규정의 범위에 포함시킬 것인가의 여부에 관한 것이었다. 두 번째 안에서는 단순 배포자도 무료의 특허라이선스를 허락하는 것으로 명시적으로 규정했었다. 하지만 이에 대해 특히 대규모 특허 포트폴리오를 가진 일부 기업들이 자사가 가진 소프트웨어특허 포트폴리오 전체에 대한 권리를 상실할 가능성이 있다는 문제점을 지적하였다. 이와 같은 의견이 일부 반영되어 세 번째 토론안부터는 현재와 같이 기여자만 특허라이선스를 허락하는 것으로 규정하고 단순 배포자는 제외되었다.
두 번째는 라이선시 등으로부터 특허소송이 제기되는 경우인데, 이와 같은 경우를 다루고 있는 라이선스 조항을 통상 특허보복(Patent Retaliation)조항이라고도 한다. 예컨대 애플의 경우, Apple Public Source License에 의해 배포되는 프로그램을 사용하는 이용자가, 애플이 먼저 특허소송을 제기하지 않았음에도, 애플에 대해 특허소송을 제기하는 경우에는 아무런 통지 없이 라이선스가 자동으로 종료된다. 이와는 달리 Apache License 2.0의 경우는, 상대방에 대한 반소제기 등 방어의 목적인지 여부와 상관없이, 아파치라이선스 프로그램을 사용하는 어떠한 이용자에 대해서 특허소송을 제기하는 경우, 소송을 제기한 날에 해당 라이선스가 종료하는 것으로 규정하고 있다.
이와 같은 특허보복조항의 필요성은 브루스 페렌스 등을 중심으로 오픈소스커뮤니티 내부에서 일찍부터 제기되었었다. 하지만 스톨만 등은 특허보복조항의 실효성에 의문을 제기하였으며, GPL 3.0의 두 번째 안에서는, 네트워크서버형태의 이용자에 대한 제한적인 보복조항을 도입하고, 일반적인 보복조항은 이용자들의 선택사항의 하나로 규정하는데 그쳤다. 그런데 이용자들의 선택사항을 규정한 조항(제7조)에 대한 배포판업체들의 비판, Apache License 2.0과의 양립성 등을 고려하여, 세 번째 안부터는 이용자들의 특허침해소송을 제10조 후단의 추가적인 제한(further restrictions)으로 규정함으로써, 일반적인 특허보복조항을 도입하는 것으로 결론내렸다.
세 번째는 라이선서와 라이선시의 관계에 있지 않는 제3자가 특허권을 소유하고 있는 경우이다. 이와 같은 경우 라이선스규정을 통해 해결할 수 있는 문제는 별로 없으며, 소프트웨어 특허에 관한 정책 또는 법해석의 문제로 귀결된다. 그래서 FSF는 GPL 2.0에서와 같이 GPL 3.0에서도 서문(Preamble)을 통해 소프트웨어 특허의 위험성을 지적하고 각국이 소프트웨어 특허의 부여를 제한할 것을 주장하고 있다. 또한 GPL 2.0 제7조의 규정을 제12조에 그대로 위치시키면서, 모든 이용자가 GPL의 조건에 따라 프로그램을 이용할 수 있도록 하는 것이 불가능할 경우에는 제3자의 특허권을 구현한 프로그램을 GPL로 배포할 수 없도록 하고 있다. 그런데 GPL 2.0의 특허규정을 엄격하게 요구하는 것은 현실적으로 어려움이 있다. 예를 들어 리눅스커널의 경우 (특정업체의 조사결과에 따르면) 미국특허 수백개가 관련되어 있는데, 각각의 특허에 대해 무료 라이선스를 취득하는 것은 불가능에 가깝다고 볼 수 있다. 특히 수백개의 GPL 프로그램들을 배포하는 GNU/리눅스 배포판업체들의 경우에는 더더욱 그러하다고 볼 수 있다. 이와 같은 현실적인 어려움을 받아들여 GPL 3.0은, 배포자가 제3자의 특허가 포함되어 있다는 사실을 알더라도, ⅰ) 공중이 이용가능한 네트워크 서버 등을 통해 무료로 관련 소스코드를 복제할 수 있도록 하거나, ⅱ) 해당 프로그램에 대하여, 본인에게 주어진 특허라이선스의 혜택을 스스로 박탈하거나, ⅲ) GPL의 요구사항에 부합하는 특허라이선스를 후방 이용자(downstream users)에게도 허락하는 경우에는, 제3자의 특허가 포함된 GPL 프로그램을 배포할 수 있다.
한편 개정과정의 후반부에서 가장 이슈가 되었던 사항은 MS와 노벨의 특허관련 협약의 체결과, 이와 같은 협약을 막기 위한 조항을 GPL에 도입하는 것이었다. MS는 최근 들어 계속해서 리눅스를 비롯한 오픈소스소프트웨어가 자사의 특허권들을 침해하고 있다고 주장하고 있다. 하지만 현실적으로 다수의 오픈소스소프트웨어관련 기업들을 상대로 소송을 제기하는 것이 쉽지 않으며, 여론도 무시할 수 없는 상황이다. 결국 노벨 등 일부 이해관계가 맞는 기업들을 중심으로 협약을 체결하는 형태로 오픈소스커뮤니티에서 자사의 특허를 인정(?)받고자 노력하고 있다. 이에 대해 스톨만은 MS의 이와 같은 차별적인(discriminatory) 특허라이선스가 부당하다고 판단하고 이를 막기 위한 조항을 규정을 마련하였다. 핵심 내용은 GPL 프로그램과 관련하여 특정인에게 특허라이선스를 허락하는 경우 후방 라이선시들에게도 특허라이선스가 자동적으로 주어진다는 것과, 차별적인 특허라이선스를 체결하는 경우 GPL 프로그램을 배포할 수 없도록 하는 것이다. 그러나 동 조항이 구체적으로 어떠한 의미를 지니는지, 차별적 특허라이선스협정과 포괄적인 크로스라이선스협정의 구별기준이 무엇인지 등 많은 의문이 제기되고 있으며, FSF(또는 소프트웨어자유법센터:SFLC)는 이에 관한 명확한 답변을 하지 못하고 있다. 동 조항이 GPL 3.0에 포함된 이후 삼성전자와 LG전자가 각각 MS와 특허크로스라이선스협정을 체결했다. 국내 기업들의 이와 같은 협정들이 GPL 3.0에서 금지하고 있는 협정에 해당하는지의 여부에 대한 분석도 필요한 시점이다.
5.4 라이선스의 양립성 : Apache, Affero GPL
소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이선스가 상호 상충되는 경우가 있다. 예컨대 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 조건의 엄격성 때문에 나타난다. GPL 3.0의 초기버전에서는 이러한 양립성 문제를 해결하기 위해 이용자들이 추가적인 제한/허용 조건을 선택할 수 있도록 폭넓게 규정했었다. 예를 들어 특허보복조항의 포함여부, 네트워크서버형태로 이용하는 경우 소스코드를 제공하게 할 것인지의 여부 등을 개별적으로 선택할 수 있도록 하였다. 그러나 GNU/리눅스 배포판업체들은 오픈소스소프트웨어 라이선스들의 증가와 그에 따른 양립성문제는 인정하지만, 추가적인 제한/허용 규정에 의해 수많은 프로그램들이 서로 다른 GPL 조건들을 가질 경우, 라이선싱과 관련된 문제들이 더욱 복잡하게 될 것이라고 주장하였다. 이러한 비판을 어느 정도 수용하여 현행규정은 앞에서 살펴본 것처럼 특허보복조항을 제10조에 포함시키고, 네트워크서버형태의 이용과 관련해서는 제14조를 별도로 만드는 등 보다 단순화하였다. 또한 이러한 조치를 통해 GPL 3.0은 Apache License 2.0과 양립가능하며, 네트워크서버형태로 이용하는 경우에도 소스코드를 제공하도록 요구하는 Affero GPL 3.0(안)과도 양립가능하게 되었다.
5.5.1 용어의 정리
일반적으로 하나의 라이선스가 전세계적으로 동일하게 사용되는 경우는 드물다. 라이선서(licensor)가 시장을 지역적으로 구분하고자 하는 전략적인 이유도 있겠지만, 각국마다 저작권법 등의 법제도가 상이하기 때문이다. 그래서 라이선서는 각국에 적합한 라이선스를 따로 만들어서 배포하게 된다. GPL 2.0은 일반적인 상용라이선스와는 다르긴 하지만, 어디까지나 미국의 법체계를 기반으로 만들어진 것이 틀림없다. 사용되는 용어에서나 워런티, 책임의 제한 등에 관한 내용이 이를 잘 말해주고 있다. 그렇지만 오픈소스소프트웨어가 전세계적으로 사용되고 있는 현재, GPL이 미국이외의 지역에서 하나의 라이선스로 사용되기 위한 변화가 필요하다. 이를 반영하여 GPL 3.0에서는 용어를 새롭게 정의하거나 추가하고 있다. 특히 중요한 용어로는 “propagate"와 ”convey"이다. 어떤 저작물을 “프로퍼게이트(propagate)”하는 것은, 저작권자의 허가를 받지 않고 어떠한 행위를 하는 경우 저작권을 위반하게 되는 모든 행위를 의미한다. 예를 들어 저작물을 복제, 배포, 전시하는 등의 행위를 포함한다. 다만 하나의 컴퓨터에서 단순 실행하거나 개인적으로 복제 또는 수정하는 것은 제외한다. 두 번째로 저작물을 “컨베이(convey)”하는 것은 제3자가 복사본을 제작하거나 받을 수 있도록 가능케 해주는 모든 종류의 프로퍼게이트 행위를 의미한다. GPL 2.0의 배포(distribution)에 해당하는 개념인데, 각국의 저작권법에서 배포의 범위가 다르고, 일부 지역에서는 ”공중에의 전달(communicating to the public)" 등 다른 표현을 사용하는 등 혼동을 가져올 수 있기 때문에 새롭게 정의하게 된 것이다. 다만 컴퓨터 네트워크를 통해 사용자와 상호작용하는 것은 컨베이가 아니다.
[edit]
5.5.2 소스코드 제공범위
오픈소스 라이선스 중에서 GPL/LGPL/MPL 등은 수정한 내용에 대한 소스코드를 공개하여야 하고 BSD/Apache License 등은 수정하더라도 소스코드를 공개할 의무가 발생하지 않는다. GPL/LGPL/MPL 등 소스코드 공개 의무가 발생하는 라이선스를 상호주의(reciprocal) 혹은 copyleft 라이선스라고 하며, 그 결과물이 원 소프트웨어의 2차적저작물(derivative work)일 경우 소스코드를 공개해야 한다. 그런데 소스코드의 공개범위를 기계적으로 판단할 수 있는 방법은 없으며 라이선스마다 서로 다르게 정의하고 있으므로 잘 판단하여야 한다. 특히 GPL과 관련하여 구체적으로 어떠한 경우가 2차적저작물에 해당하는지, 또는 독립된 프로그램에 해당하는지를 구별하는 것은 쉽지 않다. 결국 최종적으로는 법원의 판단에 의해 결정될 문제인데, FSF는 GPL FAQ에서 몇 가지의 구별기준을 제시하여 왔었다. 예를 들어 두개의 모듈이 동일한 실행파일에 포함되어 있거나 공유주소영역(shared address space)에서 링크되어 실행되도록 설계된 경우에는 전자에 포함되고, 2개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments 형태로 통신하는 경우에는 후자에 해당한다.
GPL 3.0에서는 소스코드의 공개범위와 관련하여 좀더 상세한 규정을 마련하였다. 동 규정에 의하여 공개할 범위에 포함되는 “해당 소스(Corresponding Source)”란, 목적코드를 생성, 설치, 그리고 (실행 가능한 작업물의 경우) 구동하고, 그 작업물을 수정하는데 필요한 모든 소스코드를 의미하며, 그 활동들을 제어하는 스크립트를 포함한다. 예를 들어 소스 파일과 연관된 인터페이스 정의 파일을 포함하고, 또한 프로그램의 다른 부분들과 그 서브프로그램 사이의 제어 흐름이나 밀접한 데이터 통신 등을 통해 프로그램이 특별히 필요로 하는, 동적 링크된 하위프로그램과 공용 라이브러리의 소스코드를 포함한다. 다만 프로그램의 시스템 라이브러리와 범용적인 툴 등은 포함하지 않는다. (KLDP 위키 번역 참조).
'Programming' 카테고리의 다른 글
| 유용한 이클립스 단축키 (0) | 2009.10.19 |
|---|---|
| 자주쓰는 정규표현식 표현 (0) | 2009.10.15 |
| InstallSheid Uninstall Shortcut 만들기 (0) | 2009.08.11 |
| 도움말 파일 만들기 가이드 (0) | 2009.08.04 |
| OSS 라이센스 비교 (0) | 2009.06.30 |