LGPL도 소스 공개를 할 필요가 없네요...
http://wiki.kldp.org/wiki.php/OpenSourceLicenseGuide#s-3.2.2
-----------------------------
인용:
@ 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 LGPL에 의해 배포된다는 사실 명시
@ LGPL Library의 일부를 수정하는 경우 수정한 Library를 LGPL에 의해 소스 코드 공개
@ LGPL Library에 응용프로그램을 링크시킬(Static과 Dynamic Linking 모두) 경우 해당 응용프로그램의 소스를 공개할 필요 없음. 다만 사용자가 Library 수정 후 동일한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그램의 Object Code를 제공해야 함
@ 특허의 경우 GPL과 동일함
-----------------------
예전에는 LGPL의 경우 동적 링크로만 써야 소스 공개 의무가 없는줄 알았는데 라이센스가 바뀐건지
정적링크도 소스 수정을 안하면 공개 안해도 되네요
어쩐지 오우거 엔진이 MIT 라이센스로 바꿨는데 ,엔진에서 사용하는 외부 라이브러리들이
LGPL 라이센스를 그대로 쓰고 있는 것을 그대로 계속 쓰는게 이상하다 싶었습니다
만약 동적 링크해야만 하는 LGPL라면 오우거 엔진을 MIT 라이센스로 로 바꿔도 외부라이브러리들에 의해
오우거 엔진도 동적 라이브러리로 써야만 했을거 같었거든요
혹시 제가 잘못 알고 있는건지 , 아님 다들 그렇게 알고 있었는지 궁금하네요
저 문서가
저 문서가 잘못되었습니다. GPL 부분도 잘못되었는데요.
링크된 부분의 문제와는 별개로 (L)GPL 소프트웨어 부분의 소스 코드를 배포해야 한다는 조건은 수정 여부와는 상관이 없습니다.
제가 알고있기로는 저 문서 내용이 맞는데요.
아래분 얘기처럼 Object Code가 소스코드 공개에 준하는 경우가 있을지는 모르겠지만
LGPL은 애초에 링크되는 프로그램이 소스를 공개하지 않아도 되게 할려고 만든 걸로 알고있는데요.
설마... 아닌가요?
링크되는 프로그램
링크되는 프로그램 말고 LGPL 라이브러리 자체의 소스 코드요.
"수정하는 경우 공개"라는 말은 틀렸습니다.
오브젝트 파일
오브젝트 파일 공개가 사실상 소스 공개나 마찬가지 입니다.
비교적 간단한 작업만으로도 원본에 가까운 소스코드를 얻어낼 수 있죠....
그래서 임베디드계에서는 GPL을 굉장히 싫어한다더군요 'ㅅ');;
간단한 작업이..
간단한 작업이 어느정도 수준의 작업을 말쓴하시는 것인지요?
리버스 엔지니어링은 항상 최악의 작업입니다. 특히 바이너리 분석을 통한 것들은 최악중 최악이죠.
오브젝트 파일은
오브젝트 파일은 linking을 위해서 global namespace를 까놓기 때문에
본의 아니게 리버스 엔지니어링 작업에 도움을 주게 됩니다.
거기에 특별히 손을 써놓지 않는 이상 바이너리 분석보다는 훨씬 쉽습니다.
그리고 리버스 엔지니어링 간단합니다.
상황에 맞는 지식과 적절한 근성(!)만 갖춘다면 누구나 할 수 있죠.
음... '적절한 근성'에서 이미 어려운 작업일지도 모르겠군요 ㅎㅎ
결국 잘못된
결국 잘못된 문서라는거지요?
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스