Удовлетворяет ли предоставление объектных файлов условию LGPL relink?

Из этого вопроса на SO , я прочитал, что:

Собственный Исходный код + Исходный код LGPL

статически связаны:
- Либо вы должны выпустить обе части как LGPL.
- Или предоставьте все, что позволит пользователю связать приложение с другой версией исходного кода LGPL. В этом случае другие требования такие же, как если бы он был динамически связан.

Похоже, что предоставления объектных файлов достаточно, чтобы удовлетворить LGPL с точки зрения статической привязки библиотеки LGPL к приложению с закрытым кодом. Хотя исполняемый файл статически связан, предоставление объектных файлов позволяет конечному пользователю перекомпилировать приложение, ссылаясь на другую версию библиотеки.

Это правильно, а если нет, то почему?

lgpl static-linking

— IvanB
источник

Да, вы абсолютно правы. Предоставление объектных файлов для вашего приложения достаточно, чтобы удовлетворить LGPL, поскольку это позволяет пользователю заменить библиотеку LGPL другой версией, если он того пожелает.

ФСФ даже прямо говорит в своем FAQ :

В целях соответствия LGPL (любая существующая версия: v2, v2.1 или v3):

(1) Если вы статически ссылаетесь на библиотеку LGPL, вы также должны предоставить свое приложение в объектном (не обязательно исходном) формате , чтобы у пользователя была возможность изменить библиотеку и заново связать приложение.

(2) Если вы динамически связываетесь с библиотекой LGPL, уже имеющейся на компьютере пользователя, вам не нужно передавать источник библиотеки. С другой стороны, если вы сами передаете исполняемую библиотеку LGPL вместе со своим приложением, независимо от того, связаны ли они статически или динамически, вы также должны передать источники библиотеки одним из способов, которые предоставляет LGPL.

— Ixrec
источник

Так почему Qt «инсайдеры» и сотрудники постоянно заявляют об обратном? LGPL Qt модифицирован или что-то?

— IvanB

Я не знаком с ситуацией с Qt, но, просматривая их страницы лицензирования, я не вижу ни одного языка, который бы явно отрицал эту возможность. Я думаю, что они просто опускают его в пользу рекомендации динамического связывания (что, вероятно, является более простым решением для большинства пользователей). Наиболее подходящая формулировка, которую я вижу: «В случае статического связывания библиотеки, само приложение больше не может быть« работой, использующей библиотеку »и, таким образом, становится предметом LGPL. Рекомендуется либо динамически связывать, либо предоставлять Исходный код приложения для пользователя под LGPL. ", что вполне разумно.

— Ixrec

Также похоже, что некоторые модули Qt доступны только под лицензией GPL, а не LGPL, если я правильно читаю эти страницы, так что, возможно, если бы они упомянули опцию статического связывания с объектами, им пришлось бы также использовать «если вы не используете X, Y или Z» и подобные скучные касательные детали.

— Ixrec

В идеальном мире динамическое связывание может быть великолепным, но в этом мире и при работе с Qt динамическое связывание - это ад. Как 60 с лишним мегабайт dll, многие из которых не внедряются инструментом развертывания, а обходчик зависимостей не обнаруживает. В их собственном FAQ по LGPL я вижу,

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