iPhone은 LGPL위반? --- 사파리가 어떻게 LGPL을 만족하는가?

답 해주셔서 감사합니다 :-) 덕분에 v3와 v2의 차이점에 대해서 인지하게 되었습니다. 제가 포스팅을 한 이유는, LGPL이 다이내믹 링크가 허락되지 않는 환경 (뉴클리어스 OS나 REX OS와 ARM CPU로 대표되는, 대부분의 전자사전, 고전적인 핸드폰, mp3등)에서는, 배포에 제한이 있는 독점 소프트웨어와 링크 하는 것이 불가능하거나 어렵기 때문에, LGPL을 만족하려면 주의해야한다는 것이었고, 이 점이 충분히 클리어 해진 듯 합니다.

고지의 의무가 없다, 라는 이야기는 : "iPhone이 work that use LGPL library"라면 고지의 의무와 동시에 (static link로 된 경우) iPhone전체의 바이너리 오브젝트를 릴리즈 해야 한다는 이야기였습니다. 반면에 safari만이 work that use LGPL 라이브러리라면 safari 프로그램에만 고지가 있으면 되고, safari 프로그램의 오브젝트가 공개되어야 하며, iPhone자체는 고지 하지 않아도 된다, 라는 이야기였습니다.

그리고, 다이내믹 링크를 할 경우에는, 아래 6.b를 따라야 합니다 : "interface-compatible"한 수정된 버전의 라이브러리를, 만약 사용자가 인스톨 하면, properly하게 동작해야 한다... 입니다. 해석의 여지가 있지만, 수정된 라이브러리를 설치할 수 있어야 하는 것 처럼 읽힙니다... (음...) 기계 자체가 라이브러리 인스톨이 안되면 몰라도, 아이폰 처럼 라이브러리 인스톨이 가능한 경우는, 이 항목에 따라 사용자의 라이브러리 인스톨을 허락해 주어야, 만족이 될것 같습니다.

A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

----

아 법무팀... 순선님! 맞장 뜰 수 있는 자사의 법무팀 말고, 고객사의 법무팀과 싸워야 하는 상황이 되면 ... 음... 생각이 쪼매 달라지실겁니다. 말씀하신 법무팀은 면피한다! 라는 것에 절대로 동의합니다 :) 사실, 그게 그들의 의무죠. 제 경우에는, 고객사의 법무팀이 딴지를 걸때 그것을 만족시켜야 했는데, 참 어렵습니다. 가령 수출용 핸드셋 제조회사의 법무팀은, 자신들의 핸드폰에 납품 받는 소프트웨어가 특허 및 저작권의 어떠한 문제가 없는지를 긴밀히 살피는데, 가령 나중에 지재권 소송이라도 나면 수출할 때의, 수입국 통관에서 막히기 떄문에 눈에 불을 켜고, 라이센스를 살핍니다.

그런 분들(!) 을 만족시키면서 상품을 공급해야 하는 입장이기 때문에, 라이센스에 LGPL을 넣어가기가 어렵습니다. ... 가령, 핸드폰 제조사의 핸드폰에다가, LGPL 라이브러리를 사용한 브라우저를 탑재한다고 가정해 보겠습니다. 대부분의 ARM9 베이스 (스마트 폰 아닌 폰들, 즉 대다수) 폰들은 OS 자체까지 모두 static link로 연결하여 단일한 바이너리로 만들어집니다. LGPL 을 사용하는 순간, 링크된 나머지 바이너리 오브젝트를 (end user에게라도) 보낼 수 있어야 하게 됩니다. 그런데, OS (이 경우에, 제일 많이 쓰이는 뉴클리어스로 예를 들겠습니다) 의 오브젝트를 밖으로 내보는 것 자체가, 해당 고객사가 취득한, OS 사용 계약의 위반이 됩니다. 링크되는 다른 코드의 라이센스가, LGPL을 만족시키기 위한 행동(이를 테면 배포)을 금지하게 하는 경우, LGPL 라이센스를 만족할 수 없는 것이며, 링크해서는 안된다고 FSF는 명시하고 있습니다.

제 입장이 이해가 되시는지요? 뉴클리어스 OS + ARM 라이브러리로 만들어진 핸드셋이나 mp3를 만들 경우, 사실상 LGPL 과 링크 할 수가 없습니다. 해당 플랫폼의 기반이 되는, 뉴클리어스 OS나 ARM 라이브러리가, 이미 오브젝트의 재배포를 금지하고 있기 때문입니다. 그러면 그러한 고객사 제품에는, 납품이 불가능해지는 (원칙적으로는... 어디까지나 원칙적으로는..) 것입니다. 제 생각에, ARM9과 뉴클리어스 OS 등으로 대표되는 독점 소프트웨어 임베디드 기기에, LGPL 라이브러리를 쓴다는 것은 거의 불가능한 것 같습니다. (그래서 노벨과 같은 기업은, ARM + 독점OS와, ARM + Linux OS 라인업을 아예 따로 관리하는 정책을 취하는 듯 합니다)

물론 그거야 이상이고, 실지로 대형 회사 (S사, L사) 코드 보면, LGPL 코드가 들어가 있다고도 합니다. ... (저는 본적 없습니다, 라고 말할 수 밖에 없겠지요? .T.T) ... 혹시나 LGPL로 커버되는 코드가 들어가 있을 경우, 위반이 된다고, 저는 생각합니다. 그렇게 남들도 위반하는데 무슨 신경이냐, 라고 말할 수도 있겠지만, 저 역시도 LGPL 라이센스로 커버되는 어떤 대학 프로젝트의 한 부분을 맡아 진행하고 있고... 라이센스를 최대한 지켜서 천국 (그런게 있다면, 소프트웨어 엔지니어의 천국) 으로 가고 싶은 심정인지라, 이런 부분에 민감하게 굴게 되네요.

----

LGPL이 나쁘다거나, LGPL 을 써서 좋은 도구를 공급하고 있는 애플이 문제가 있다거나, 이런게 아니라... 생각보다 LGPL은 장사해먹기 좋은 라이센스가 아니며, 재링크에 대한 의무 부가가 (스태틱 링크와 독점 OS에 의존하고 있는 다수의 임베디드에서는) 발목을 많이 잡는 다는 것을 이야기 하고 싶었습니다. 좀 어렵게 왔지만, 결국 다 이야기 했네요. ;)

"LGPL을 가져다 쓴 경우 소스만 공개하면 문제가 없다,는 아니더라" 라고 인식들만 해 주셔도, 포스팅한 노력이 충분히 만족스럽습니다.

----

EDIT : 사족
PS. 누가 이 포스팅들을 보고, 앞으로 자신들의 저러한 제한된 디바이스에서 LGPL코드를 차근히 빼주기를 바라는 것은, 1) 자유 소프트웨어 발전에 도움이 되는 것일까요? 2) 자유소프트웨어를 사용하는 것을 꺼려하게 되서, 도리어 발전에 장애가 될까요.

FSF야 1)번이라고 하겠지만, 어느정도는 2)번이라고 보실 수도 있을것 같아서... ...좀 그렇습니다. 만약 모든 임베디드 기기에서 편히 쓰일 릴리즈를 하시고싶다면, LGPL 로 릴리즈 하면서 6번 relink 는 지키지 않아도 된다, 라고 릴리즈 하는 것을 고려해보시는 것도 나쁘지 않을 것입니다... 제 기억이 틀리지 않다면 OCAML 언어가 잠시 그랬었지요... 임베디드와는 상관없이, 아직 그 언어의 런타임이 다이내믹 링크를 지원하지 않는 시절에... OCAML로 짜여진 프로그램을 배포하려면 1차 컴파일된 소스나 object까지 같이 보내야 하는 문제가 있었는데, 소스를 노출 시키지 않을 방법이 없는 오브젝트 형이었거든요.

아, 노력에 감사드립니다! Webkit전체로 해당 코드들을 명하고 LGPL을 고지하고 있군요.

아마 LGPL 라이센스의 사본도 어디 있겠네요. (아마, 디지털 매체 안에라도 반드시 있을 성 싶습니다 -- 가령 맥용 사파리 브라우저의 경우에는, help안에 LGPL 라이센스와 관련된 라이센스들도 다 기록되어 있으니...)

>> 그리고 safari가 lgplv2 소프트웨어와 dynamic link된다면 애플이 애플리케이션의 오브젝트를 제공할 의무는 없는 것이지요.

맞습니다... 이 경우에는, 사용자가 시스템에 새 라이브러리를 설치할 경우, 돌아가기만 하면 문제가 없다, 라고 라이센스가 명시하고 있으니까요...