자바 LGPL 라이브러리를 쓰려면 어떤 일을 해 주어야 할까요?
자바로 된 상용 프로그램을 작성중인데 LGPL을 따르고 있는 라이브러리를 쓰려고 고려중입니다.
이 라이브러리를 사용하려면 어떤 일을 해 주어야 할까요?
KLDP에서 검색해 보아도 딱히 이런 상황에서 어떻게 해야할지 모르겠습니다.
일단 의도는 라이브러리 사용에 대한 감사의 마음은 표하고 싶으나,
저희 제품의 소스코드를 공개해야 하는 입장에 처하고 싶지는 않다는 것입니다.
라이브러리를 사용한다면 다음 문맥에서 사용할 듯 합니다.
1. 라이브러리를 수정하지 않고 그대로 사용할 예정입니다.
2. 라이브러리의 바이너리와 제공된 API 문서만으로 제품을 만들 예정입니다.
(아마 이건 복사, 배포, 변경이 아니므로 LGPL의 소관이 아닌 듯 합니다만)
3. 그러나 현재 사용하려는 라이브러리가 없다면 프로그램은 수행되지 않을 것입니다.
4. 자바 소스에는 해당 라이브러리의 클래스나 인터페이스를 참조하는 부분이
저희쪽 소스코드에 포함될 것으로 보입니다.
참조의 의미는
a. 클래스나 인터페이스를 new 나 singleton 메소드 등으로 생성하거나 얻어와서
정의된 메소드를 사용하는 것
b. 클래스나 인터페이스의 필드를 참조하는 것
LGPL의 5번 문구의 해석이 상당히 애매한데,
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
윗 문구에 의하면 저희 제품은 라이브러리의 derivative를 포함하고 있지 않은 듯 하여,
LGPL에 적용이 안되므로 아무런 조치를 안 해도 된다는 것 같이 해석이 됩니다.
이 경우에도 BSD나 Apache처럼 해당 라이브러리를 쓰고 있다고 표시해 주고 싶은데,
이에 대해 어떻게 하라고 나와있는것이 없습니다.
LGPL의 derivative work이 아니더라도 LGPL이 적용되는 라이브러리를 사용한다면
LGPL 문구를 제품에 표시해 주거나 배포판에 텍스트파일 형태로 함께 배포해야 된다는
규정이 있는지 궁금합니다.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
C 등의 static 링킹을 언급하는 것으로 보이는데 이게 자바에도 적용되는 것일까요?
만일 제품 배포판에 해당 라이브러리를 같이 배포한다면 이 내용이 적용될까요?
해당 라이브러리는 사용자가 다운로드 받게 한다면 이 내용은 적용되는걸까요?
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
소스코드에서 라이브러리의 클래스등을 참조하는 것은 당연히
소스레벨의 derivative work이 되는건가요? 그럼 저희 제품의 소스도 공개를 해야되는것인가요?
(억지로 자체적으로 mock 라이브러리를 만들지 않는다면) 라이브러리가 없이는
컴파일이 안될터인데 저희 소스코드나 컴파일된 바이너리는 derivative work이 되는걸까요?
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Java의 경우에는 javadoc 에 제공된 API를 사용하면 법적으로는 derivative work이지만
복사, 배포, 변경은 영향을 안 받는다는 의미로 해석될 수 있는것인가요?
자세히 읽어보지는
자세히 읽어보지는 않았는데, lgpl 라이브러리를 사용하실 경우에는 다음과 같은 사항을 준수하시면 됩니다. 사용하시려는 라이브러리가 a이고 그 라이브러리를 링크하는 상용 sw가 b라면 사용자 매뉴얼 혹은 별도의 보증서 등에 '이 제품은 lgpl 하에 배포되는 a 소프트웨어를 사용하였습니다' 정도와 사용하신 a 라이브러리를 소비자가 받을 수 있는 방법(웹사이트 혹은 회사 연락처), lgpl 전문을 매뉴얼 혹은 별도의 보증서 등에 기재하시면 됩니다. b 소프트웨어는 어떻게 개발하시든 상관이 없고, a 라이브러리는 만약 수정한 부분이 있으면 수정한 내용을 소비자의 요청이 있을 경우 제공하셔야 합니다. b 소프트웨어는 어떻게 개발하거나 수정하든 상관 없고요.
댓글 달기