객체 파일 제공이 LGPL 재 링크 조항을 충족합니까?

독점 소스 코드 + LGPL 소스 코드

정적으로 링크 :
- 두 부분을 모두 LGPL로 해제해야합니다.
- 또는 사용자가 다른 버전의 LGPL 소스 코드로 애플리케이션을 다시 링크 할 수 있도록 모든 것을 제공하십시오. 이 경우 다른 요구 사항은 동적으로 링크 된 것과 동일합니다.

따라서 LGPL 라이브러리를 독점 코드 응용 프로그램에 정적으로 링크하는 측면에서 객체 파일을 제공하는 것이 LGPL을 만족시키기에 충분하다고 들립니다. 실행 파일은 정적으로 링크되어 있지만 최종 사용자는 응용 프로그램을 다시 컴파일하여 다른 버전의 라이브러리에 링크 할 수 있습니다.

이것이 맞습니까? 그렇지 않다면 왜 그렇습니까?

lgpl static-linking

— 이반 비
소스

예, 당신은 완전히 맞습니다. 응용 프로그램에 오브젝트 파일을 제공하면 사용자가 LGPL 라이브러리를 원하는 경우 다른 버전으로 대체 할 수 있으므로 LGPL을 만족시키기에 충분합니다.

FSF는 FAQ에 이렇게 명시 적으로 말합니다 .

LGPL (현재 버전 : v2, v2.1 또는 v3)을 준수하기 위해 :

(1) LGPL 라이브러리에 정적으로 링크 하는 경우, 사용자가 라이브러리를 수정하고 다시 링크 할 수 있도록 응용 프로그램을 소스 (필수는 아님) 형식으로 제공해야합니다.

(2) 사용자 컴퓨터에 이미 존재하는 LGPL 라이브러리에 동적으로 링크하는 경우 라이브러리 소스를 전달할 필요가 없습니다. 한편, 정적으로 또는 동적으로 링크 된 응용 프로그램과 함께 실행 가능한 LGPL 라이브러리를 전달하는 경우 LGPL이 제공하는 방법 중 하나를 사용하여 라이브러리의 소스도 전달해야합니다.

— 익 렉스
소스

Qt "내부자"와 직원은 왜 계속해서 다른 주장을합니까? Qt의 LGPL이 수정 되었습니까?

— IvanB

Qt 상황에 익숙하지 않지만 라이센스 페이지를 감추면이 가능성을 명시 적으로 거부하는 언어가 표시되지 않습니다. 나는 그들이 동적 링크를 추천하기 위해 그것을 생략한다고 생각합니다 (아마도 대부분의 사용자에게 더 간단한 해결책 일 것입니다). 가장 관련성이 높은 문구는 다음과 같습니다. "라이브러리의 정적 링크의 경우 응용 프로그램 자체는 더 이상"라이브러리를 사용하는 작업 "이 아니므로 LGPL의 적용을받을 수 있습니다. 동적으로 링크하거나 다음을 제공하는 것이 좋습니다. LGPL 하에서 사용자에게 애플리케이션 소스 코드를 제공해야합니다. "

— Ixrec

또한 Qt의 일부 모듈은 LGPL이 아닌 GPL에서만 사용할 수있는 것처럼 보입니다.이 페이지를 올바르게 읽으면 객체 옵션과의 정적 링크를 언급 한 경우에도 수정해야 할 수도 있습니다 "X, Y 또는 Z를 사용하지 않는 한"및 유사한 지루한 접선 방향 세부 사항.

— Ixrec

완벽한 세상에서 동적 연결은 훌륭 할 수 있지만,이 세상과 Qt를 다룰 때 동적 연결은 지옥입니다. 60MB 이상의 dll과 마찬가지로 배포 도구가 가져 오지 않고 종속성 워커가 감지하지 못하는 dll이 많습니다. 그들 자신의 LGPL FAQ에서 나는

The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.

의무적 인 것에 대해 아무것도 보지 못한다.

— IvanB

FAQ를 읽으면 LGPL이 독점 응용 프로그램이 Qt에 정적으로 링크되는 것을 허용하지 않지만 그것을 암시하는 데 매우 부지런하다고 주장하는 것은 부끄러운 것 같습니다.

— IvanB