Tag Archives: GPL

GPL 2.0의 주요 내용과 개정배경

오픈소스소프트웨어 라이선스 중 가장 중요한 것은 GPL이며, 주요 내용은 다음과 같다.

 

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

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

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

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

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

< GPL 2.0의 주요 내용 >

▪ 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실 명시

▪ 소프트웨어를 수정하거나 새로운 소프트웨어를 링크(Static과 Dynamic linking 모두)시키는 경우 GPL에 의해 소스 코드 제공해야 함. 다만 리눅스를 기반으로 개발된 응용프로그램은 소스코드 제공할 필요 없음

▪ Object Code 또는 Executable Form으로 GPL 소프트웨어를 배포하는 경우, 소스 코드 그 자체를 함께 배포하거나 또는 소스코드를 제공받을 수 있는 방법에 대한 정보 함께 제공해야 함

▪자신의 특허를 구현한 프로그램을 GPL로 배포할 때는 GPL 조건을 준수하는 이용자에게는 로열티를 받을 수 없으며, 제3자의특허인 경우에도 특허권자가 Royalty-Free 형태의 라이선스를 제공해야만 해당 특허 기술을 구현한 프로그램을 GPL로배포하는 것이 가능

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

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 DiscussionDraft)을 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 소프트웨어를 이용하는 경우의 처리 등이다. 이 밖에 소스코드의 범위를 명확히 하고, 새로운 용어를정의하는 등의 수정이 있었다.

SONY의 LGPL위반으로 인한 소송 휘말림 사례

소니가 LGPL 소스를 무단으로 사용하다 적발되어 소송당한 사례가 유명하다.

2005년 11월경에 인터넷을 크게 달구었던 내용으로
LGPL저작권자가 리버스엔지니어링을 통해 소니를 제소했던 사건으로
원 소스 저작권자가 승소한 큰 사례이다.

하기는 승소 사례 원문이다




Posted on 11/17/2005 8:33:09 AM PST by N3WBI3

Due to the importance of the latest discoveries, here’s another update. For the first time I’m updating twice on one day. I’m sure you’ve already been waiting for some proof about the GPL infringement by F4I. This post contains it in the already well-known form of a comparison between the original C code and an annotated disassembly of the F4I binary. All C code is from the function DoShuffle from the file drms.c which is part of the VideoLAN project.

I want to mention though that I’m not going to explain all code because the function is pretty long. I’ve picked two parts of the function where it’s easily recognizable that the two functions are basically the same (there’s one tiny difference explained later). Nevertheless I’m going to provide the other parts of the function too, I just won’t comment them. Here’s the full disassembly.

First: I’m sure all the code is going to break the HTML formatting. I’m not going to fix it though.

Let’s start right at the beginning of the function where we can find the code the decrypts the ROT13-encrypted Apple copyright message.

Here’s the C code.

static uint32_t i_secret = 0;

static uint32_t p_secret1[] = { 0xAAAAAAAA, 0x01757700, 0x00554580, 0x01724500, 0x00424580, 0x01427700, 0x00000080, 0xC1D59D01, 0x80144981, 0x815C8901, 0x80544981, 0x81D45D01, 0x00000080, 0x81A3BB03, 0x00A2AA82, 0x01A3BB03, 0x0022A282, 0x813BA202, 0x00000080, 0x6D575737, 0x4A5275A5, 0x6D525725, 0x4A5254A5, 0x6B725437, 0x00000080, 0xD5DDB938, 0x5455A092, 0x5D95A013, 0x4415A192, 0xC5DD393A, 0x00000080, 0x55555555 };

static char p_secret2[] = “pbclevtug (p) Nccyr Pbzchgre, Vap. Nyy Evtugf Erfreirq.”; if( i_secret == 0 ) { REVERSE( p_secret1, sizeof(p_secret1)/sizeof(p_secret1[ 0 ]) ); for( ; p_secret2[ i_secret ] != ‘

LGPL 위반이라고 보았을 때 해야 되는 일

만약, 특정한 프로그램이나 소프트웨어가 GPL (또는 LGPL 또는 GFDL) 위반인지 아닌지를 확인하고 싶다면 다음과 같은 사항들을 확인해 보시기 바랍니다.

  • 배포판에 GPL 원문이 포함되어 있는가?
  • GPL에 의해서 배포되는 소프트웨어라는 사실이 명시되어 있는가? GPL로 선언된 소프트웨어가 아님에도 불구하고, GPL에 의한 소프트웨어라는 인상을 줄만한 문구가 포함되어 있는가?
  • 배포판에 소스 코드가 함께 제공되고 있는가?
  • 배포판이 바이너리, 즉 실행 파일만으로 구성되어 있다면 네트워크를 통한 배포와 같이 별도의 방법으로 소스 코드를 제공한다는 명시적인 확약이 있는가?
  • 제공되는 소스 코드가 완전한 형태이거나 GPL 이외의 라이센스 조건을 따르는 모듈들과 함께 연동해서 사용할 수 있도록 만들어졌는가?

만약, 위와 같은 확인을 통해서 GPL 위반이라는 판단이 선다면 소프트웨어의 이름과 그 제품을 배포하고 있는 개인이나 단체의 이름 그리고 그들과 연락할 수 있는 주소와 전화 번호 등의 정보를 위반 사항과 함께 자세히 적어서 GPL에 대한 적용이 잘못되고 있음을 저작권자에게 알려주시기 바랍니다. 저작권자란 소프트웨어가 GPL로 관리되도록 선언할 수 있었던, 해당 소프트웨어에 대한 법률적 권리를 갖고 있던 사람을 의미합니다.

라이브러리에 LGPL을 사용하지 말아야 하는 이유

GNU 프로젝트는 라이브러리에 두 가지 주된 라이선스를 사용하고 있습니다. 하나는 GNU Library GPL이고 또다른 하나는 일반적인 GNU GPL입니다. 라이선스의 선택은 큰 차이를 유발합니다. Library GPL이 적용된 라이브러리는 독점 소프트웨어에 사용될 수 있지만, 일반적인 GPL이 적용된 라이브러리는 단지 자유 프로그램에서만 사용될 수 있습니다.

특정한 라이브러리에 어떤 라이선스를 적용할 것인가라는 문제는 전략적인 사항이기 때문에 구체적인 상황에 따라 달라질 수 있습니다. 현재 대부분의 GNU 라이브러리들은 Library GPL을 따르고 있는데,이것은 우리가 두 가지 전략 중에서 하나는 무시한 채 다른 한 가지 전략만을 추구하고 있다는 것을 의미합니다. 이런 이유를 기준으로 우리는 일반적인 GPL로 배포할 수 있는 더욱 많은 라이브러리를 찾고 있습니다.

독점 소프트웨어 개발자들은 비용면에서 비교 우위를 갖고 있습니다. 그렇게 때문에 자유 소프트웨어 개발자들은 이러한 부분을 상쇄시킬 수 있는 이점을 서로에게 제공해 주어야 할 필요가 있습니다. 라이브러리에 일반적인 GPL을 적용하게 되면 자유 소프트웨어 개발자들은 이를 사용할 수 있지만, 독점 소프트웨어 개발자들은 사용할 수 없게 되어 자유 소프트웨어 개발자들에게 이점을 제공해 줄 수 있습니다.

일반적인 GPL의 적용이 모든 라이브러리에 장점을 제공해 주는 것은 아닙니다. 어떤 경우에는 Library GPL을 사용하는 것이 더 좋습니다. 이러한 경우의 일반적인 형태는 자유 라이브러리의 기능이 다른 대체 라이브러리를 통해서독점 소프트웨어에서도 쉽게 구현될 수 있을 때입니다. 이러한 경우에는 라이브러리가 자유 소프트웨어에 대한 특별한 이점을 보장해 줄 수 없기 때문에 단순히 Library GPL을 적용하는 것이 그 사용 범위를 넓히기 위해서라도 더 좋다고 볼 수 있습니다.

GNU C 라이브러리에 Library GPL을 적용한 것은 이러한 이유 때문입니다. GNU C 라이브러리 이외에도 다른 C 라이브러리들이 많이 존재하기 때문에 만약 GNU C 라이브러리에 GPL을 적용하게 되면 독점 소프트웨어 개발자들은 그들이 사용할 수 있는 다른 C 라이브러리를 사용하게 될 것입니다. 이러한 결과는 우리에게 문제를 더 가져다 줄 뿐이며 독점 소프트웨어 개발자들에게는 아무런 문제가 되지 않습니다.

그러나 만약 어떤 라이브러리가 GNU Readline의 경우와 같이 독자적이고 중요한 기능을 제공하는 것이라면 그것은 전혀 별개의 문제입니다. Readline은 에디터나 쉘과 같이 대화형으로 진행되는 프로그램을 사용할때 이용할 수 있는 명령행 편집이나 히스토리 기능을 제공할 수 있는 라이브러리로, 이러한 기능은다른 라이브러리에서 일반적으로 찾아볼 수 없는 특징적인 것입니다.따라서 Readline에 GPL을 적용하게 되면 Readline의 사용을 자유 소프트웨어에만 한정시킬 수 있기 때문에 자유 소프트웨어 공동체에 실질적인 지원을 제공할 수 있습니다. 이러한 방법을 통해서 Readline의 기능을 포함시키고자 하는 소프트웨어는 자연스럽게 자유 소프트웨어가 되게 만들 수 있습니다.

만약 우리가 독점 소프트웨어에는 찾아볼 수 없는 기능을 가진 GPL 기반의 강력한 라이브러리들을 축적할 수 있다면 그것은 새로운 자유 소프트웨어를 개발할 수 있는 매우 유용한 모듈들로 활용될 수 있을 것입니다. 이것은 자유 소프트웨어의 개발에 더욱 큰 이점을 줄 것이고,어떤 프로젝트들은 GPL이 적용된 라이브러리를 사용하기 위해서, 앞으로 개발될 소프트웨어를 자유 소프트웨어로만들기로 결정하기도 할 것입니다. 대학의 프로젝트는 이러한 영향을 쉽게 받을 수 있습니다. 최근에는 기업들도 자유 소프트웨어를 만들기 시작했으며, 심지어 몇몇 상업 프로젝트도 이러한 영향을 받게되었습니다.

자유 경쟁이 갖고 있는 중요한 이점을 부정하려고 하는 독점 소프트웨어 개발자들은 프로그램 저작자들에게 라이브러리를 GPL 소프트웨어에 포함시키지 말 것을 설득하려고 노력할 것입니다. 예를 들면, 만약 라이브러리를 독점 소프트웨어 제품을 만드는데 사용하게 된다면보다 많은 사용자들이 그 라이브러리를 사용하게 될 것이라는 점을 주장할 지도 모릅니다. 이러한 점을 프로그램 저작자들의 자존심과 공명심에 빌어 설득할 경우에는,상당한 인기를 가진 하나의 라이브러리를 만들어 내는 것이 마치 자유 소프트웨어 공동체가 당면한가장 필요한 요구라는 그릇된 판단을 유도하게 될 수 있습니다.

그러나 우리는 이러한 유혹에 넘어가서는 안됩니다. 왜냐하면 우리는 GPL 라이브러리를 통한 단결을 통해서 더욱 많은 것들을 달성할 수 있기 때문입니다. 자유 소프트웨어 개발자들은 서로가 서로를 지원해야만 합니다. 라이브러리를 자유 소프트웨어에 한정해서 배포하는 방법을 통해서 우리는 동료 개발자들이 만든 자유 소프트웨어 패키지들이 이에 대응되는 독점 소프트웨어를 능가하도록 도울 수 있습니다. 이러한 방법들을 통해서 자유 소프트웨어가 전반적인 경쟁 우위를 갖게 되면 결과적으로 전체적인 자유 소프트웨어 운동은 보다 많은 인기를 얻게 될 것입니다.

“Library GPL”이라는 이름은 이러한 관점에 대한 잘못된 오해의 소지를 갖고 있기 때문에 우리는 그 이름을 “Lesser GPL”로 변경할 예정입니다. 실제로 이름을 바꾸기 위해서는 약간의 시간이 필요하겠지만, 그것을 기다릴 필요없이 지금이라도 여러분이 만든 라이브러리를 GPL로 설정해서 배포할 수 있습니다.