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은 소스 고쳐도 공개 안해도 되는거 아닌가?

몇년전에 소니가 LGPL 소프트웨어의 소유권자로부터 소송을 당해 곤욕을 치룬 일이 있었다.

이것이 가능했던 것은 리버스 엔지니어링의 방법으로 소스 사용여부는 무척 쉽게 알 수 있었기 때문이다.

다음의 LGPL문구를 읽어보도록 하자.

0조의 일부입니다.

인용:

“라이브러리”란 소프트웨어 함수와 데이터를 함께 또는 개별적으로 수집해 놓은 것으로 이들 중 일부를 사용하는 응용 프로그램과 링크되어 실행물을 생성하는데 편리하도록 미리 준비된 것을 의미합니다.

“원시 코드”란 해당 저작물을 개작하기에 적절한 형식을 의미합니다. 라이브러리에 대한 완전한 원시 코드란 라이브러리에 포함된 모든 모듈들의 원시 코드와 이와 관련된 인터페이스 정의 파일 모두, 그리고 라이브러리의 컴파일과 설치를 제어하는데 사용된 스크립트 전부를 의미합니다.

 

다음은 5조의 일부입니다.

인용:

라이브러리의 어떠한 부분으로부터의 파생물도 포함하지 않지만, 컴파일 또는 링크를 통해서 라이브러리와 함께 작동하도록 설계된 프로그램은 “라이브러리를 사용하는 저작물”이 됩니다. 이러한 저작물이 별도로 분리되어 있을 때는 라이브러리에 대한 파생물이 아니므로 본 사용 허가서가 적용되지 않습니다.

그러나 “라이브러리를 사용하는 저작물”이 라이브러리와 링크된 결과로 생성된 실행물은, 실행물 안에 라이브러리의 일부를 포함하고 있기 때문에 라이브러리에 기반한 2차적 저작물을 구성하게 됩니다. 따라서 이러한 방식으로 생성된 실행물은 본 사용 허가서의 적용을 받습니다. 제6조는 이러한 종류의 실행물의 배포를 위한 규정을 담고 있습니다.

 

6조의 일부입니다.

인용:

제 6 조. 위의 조항들에 대한 예외의 하나로, 라이브러리와 “라이브러리를 사용하는 저작물”을 함께 결합하거나 링크시켜서 라이브러리의 일부분이 포함된 저작물을 만들었다면, 이를 자신이 선택한 규정에 따라 배포할 수 있습니다. 이 경우 배포 규정에는 피양도자들이 자신의 필요에 따라 저작물을 개작할 수 있으며 개작에 따른 디버깅을 위해 코드역분석(reverse regineering)을 허용한다는 사항이 포함되어야 합니다.

라이브러리와 라이브러리의 사용에는 본 사용 허가서가 적용된다는 것과 저작물 안에 이러한 라이브러리가 사용되고 있다는 사실을 담고 있는 안내 문구를 모든 복제물에 분명하게 명시해야 합니다. 또한 영문판 LGLP 사본을 함께 제공해야 합니다. 저작물이 실행될 때 저작권 사항이 표시되는 형태를 취하고 있다면 라이브러리에 대한 저작권 사항도 함께 포함시켜야 하며 LGPL 사본을 참고할 수 있는 방법을 명시해야 합니다. 또한 다음 중 하나의 사항을 반드시 만족시켜야 합니다.

제 1 항. 저작물에 포함된 라이브러리에 어떠한 수정이 가해졌다 하더라도 해당 라이브러리에 대한 컴퓨터가 인식할 수 있는 완전한 형태의 원시 코드를 저작물과 함께 제공해야 합니다. 이 원시 코드는 제1조와 제2조의 규정에 따라 배포될 수 있어야 합니다. 만약 저작물이 라이브러리와 링크되는 실행물이었을 경우에는 피양도자가 실행물과 링크되는 라이브러리를 개작한 뒤에도 링크를 통해 새로운 실행물을 만들 수 있도록 하기 위해서 “라이브러리를 사용한 저작물”로서 배포된 저작물에 해당하는 컴퓨터가 인식할 수 있는 완전한 형태의 원시 코드와 목적 코드 중 하나 또는 둘 모두를 제공해야 합니다. (라이브러리에 포함된 정의 파일의 내용을 수정한 경우에는 변경된 정의 부분을 사용하기 위해서 응용 프로그램을 반드시 다시 컴파일할 필요는 없다는 점은 인정됩니다.)

제 2 항. 라이브러리는 적절한 공유 라이브러리 방식을 사용해서 링크되어야 합니다. 적절한 방식이란, (1) 라이브러리의 함수를 실행물 속으로 직접 복제하는 것이 아니라 실행 시점에서 볼 때 이미 사용자의 컴퓨터 시스템 상에 존재하고 있는 라이브러리의 복제물이 사용되는 것입니다. 또한 (2) 사용자가 개작된 라이브러리를 설치한 경우에도 개작된 라이브러리가 저작물을 만들 때 사용된 라이브러리의 버전과 인터페이스상으로 호환되는 한, 적절하게 동작할 수 있어야 합니다.

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로 설정해서 배포할 수 있습니다.