LGPL 라이브러리의 static link 배포와 라이센스 문제
글쓴이: june8th / 작성시간: 수, 2003/05/21 - 10:59오전
생각의 발단은 RisaPapa님의 글을 읽던 중이었습니다.
http://bbs.kldp.org/viewtopic.php?p=63735&highlight=#63735
제가 몸담고 있는 회사에서 Linux제품을 개발하는 중이고,
그것은 libc등의 LGPL로 배포된 라이브러리를 사용하는 독점 소프트웨어 입니다.
문제는 여러 배포판에서 생기는 미묘한 차이를 없애는 방법으로
static link로 만들어 배포하는 것을 고려했었는데
이 위 인용된 링크의 글을 읽던중,
그것이 라이센스를 어기는 것일지도 모른다는 내용을 발견했습니다.
LGPL을 몇번 읽어보았는데, 잘 모르겠더군요..
LGPL로 배포된 library의 binary를 static link하여 배포하는 것이
라이센스를 어기는 것인지, 어떤 조건을 만족하면 되는 것인지,
비슷한 예가 있는지, 다른분들의 의견을 듣고 싶습니다..
감사합니다.
Forums:
어떤 프로그램을 LGPL 라이브러리와 함께 사용하려면 다음 세가지 선택이
어떤 프로그램을 LGPL 라이브러리와 함께 사용하려면 다음 세가지 선택이 있습니다.
- 라이브러리와 동적 링크
- 정적 링크가 가능하도록 오브젝트 파일을 공급
- 소스 코드를 공급
세번째는 독점 프로그램이라면 원천적으로 불가능한 것이고, 두번째의 경우 수십 수백개나 될 .o 파일을 배포한다는 것은 현실상 무리입니다. 따라서 실제적인 선택은 첫번째가 유일하다고 봐야죠.
위 내용은 리눅스저널 1996년 9월호를 참조했습니다.
[quote="방준영"]- 정적 링크가 가능하도록 오브젝트 파일을 공급
궁금점이 생겨서.. 질문이 있는데요.
그럼 혹시 수많은 .o 파일들을 .a로 묶은 다음 공급하는 것은 될까요?
그리고 사용된 라이브러리도 배포할 때 넣어서 makefile에서 빌드할 때 그 라이브러리를 링크시키면(정적으로...) 라이센스에 위배되는 것일까요?
rommance.net
아마 기본적인 논리가 새로 추가한 부분과 기존의 LGPL 라이센스를 따르
아마 기본적인 논리가 새로 추가한 부분과 기존의 LGPL 라이센스를 따르는 라이브러리와의 구분을 명확하게 하기 위해서 그런가 보죠.
아무래도 static 하게 묶어 버리면 이 프로그램이 어떤 라이브러리를 쓰고 있는지 알지 못하게 되어서 그런가 보죠.
도큐먼트 등으로 명시해도 문제가 될려나?
위에서 언급하신 자료가 이것이군요..[url]http://www.li
위에서 언급하신 자료가 이것이군요..
http://www.linuxjournal.com/article.php?sid=1297
결론은, LGPL과의 static 컴파일한채로 배포되는 것은 불가하다.
dynamic link할 수 있도록 배포하여야 한다. 이것이군요...
여러 배포판을 상대하여야 하는 독점소프트웨어 공급업체로서는
각 배포판의 다양한 library 환경을 고려해야하는 노력이 필요하겠군요. ;-)
[quote="송지석"][quote="방준영"]- 정적 링크가 가능하도록
.a로 묶어서 공급해도 될 겁니다. 풀면 .o 파일이 나오니까요. 문제는 .o 파일로 공급하면 심볼명이라든가 내부 구조가 노출된다는 점이겠죠.
독점 프로그램들은 소스 파일을 배포할 리가 없으니 위배 여부를 떠나서 그런 일은 불가능하지 않을까요.
소스가 아니라
독접 프로그램의 .a 파일과 LGPL 라이브러리인 .a를 같이 배포해서
Makefile이 둘을 합쳐주게만 하면, 어떻게 되나요?
----------------------------
May the F/OSS be with you..
Re: 소스가 아니라
그런 경우에는 합법입니다. 아무도 그렇게 하지 않는다는 점은 별개의 문제지만요.