Чи надає файли об’єктів задовольняє застереження про повторне посилання LGPL?

З цього запитання про СО я прочитав, що:

Власний вихідний код + вихідний код LGPL

статично пов'язані:
- Ви повинні випустити обидві частини як LGPL.
- Або надайте все, що дозволяє користувачеві повторно зв’язати програму з іншою версією вихідного коду LGPL. У цьому випадку інші вимоги такі ж, як якщо б вони були динамічно пов'язані.

Таким чином, здається, що надання об’єктних файлів достатньо, щоб задовольнити LGPL з точки зору статичного зв’язку бібліотеки LGPL з власною програмою коду. Хоча виконуваний файл є статично пов'язаним, надання об’єктних файлів дозволяє кінцевому користувачеві перекомпілювати додаток, посилаючись на іншу версію бібліотеки.

Це правильно, а якщо ні, то чому?

lgpl static-linking

— ІванБ
джерело

Так, ви абсолютно правильні. Надання об’єктних файлів для вашої програми достатньо для задоволення LGPL, оскільки воно дозволяє користувачеві замінити бібліотеку LGPL на іншу версію, якщо він захоче.

FSF навіть так прямо говорить у своїх поширених запитаннях :

З метою дотримання LGPL (будь-яка існуюча версія: v2, v2.1 або v3):

(1) Якщо ви статечно посилаєтесь на бібліотеку LGPL'd, ви також повинні надати свою програму в об'єктному (не обов'язково вихідному) форматі , щоб користувач мав змогу змінювати бібліотеку та повторно зв’язувати програму.

(2) Якщо ви динамічно підключаєтесь до бібліотеки LGPL, яка вже є на комп'ютері користувача, вам не потрібно передати джерело бібліотеки. З іншого боку, якщо ви самі передаєте виконувану бібліотеку LGPL'd разом зі своїм додатком, незалежно від того, чи є вони статично чи динамічно, ви також повинні передати джерела бібліотеки одним із способів, якими надає LGPL.

— Іксрек
джерело

То чому чому Qt "інсайдери" та працівники постійно заявляють про інше? Чи модифікований LGPL Qt чи щось таке?

— ІванБ

Я не знайомий із ситуацією Qt, але, переглядаючи їхні сторінки ліцензування, я не бачу жодної мови, яка б прямо заперечувала цю можливість. Я думаю, що вони просто опускають це на користь того, щоб рекомендувати динамічні зв'язки (що, мабуть, є більш простим рішенням для більшості користувачів). Найбільш релевантне формулювання, яке я бачу, таке: "У разі статичного посилання на бібліотеку, сама програма більше не може бути" роботою, яка використовує бібліотеку ", і, таким чином, стає предметом LGPL. Рекомендується або посилатися динамічно, або надати вихідний код програми для користувача під LGPL. ", що цілком розумно.

— Іксрек

Також схоже, що деякі модулі Qt доступні лише під GPL, а не LGPL, якщо я читаю ці сторінки правильно, тому можливо, що якщо б вони згадували про статичне посилання з об'єктами, вони також повинні були би скористатися "якщо ви не використовуєте X, Y або Z" і подібні нудні дотичні деталі.

— Іксрек

У досконалому світі динамічне зв’язування може бути чудовим, але в цьому світі і при роботі з 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.

але нічого про те, щоб бути обов'язковим.

— ІванБ

Читаючи їхні запитання, схоже, вони просто соромляться висловити (помилкове) твердження, що LGPL не дозволяє власним додаткам статично пов'язувати Qt, хоча дуже ретельно їх натякає.

— ІванБ