Czy udostępnianie plików obiektowych jest zgodne z klauzulą ponownego połączenia LGPL?

Z tego pytania dotyczącego SO przeczytałem, że:

Własny kod źródłowy + kod źródłowy LGPL

połączone statycznie:
- Musisz wydać obie części jako LGPL.
- Lub podaj wszystko, co pozwala użytkownikowi ponownie połączyć aplikację z inną wersją kodu źródłowego LGPL. W takim przypadku pozostałe wymagania są takie same, jakby były dynamicznie powiązane.

Wygląda więc na to, że dostarczenie plików obiektowych wystarczy, aby zaspokoić LGPL pod względem statycznego łączenia biblioteki LGPL z zastrzeżoną aplikacją kodową. Chociaż plik wykonywalny jest statycznie powiązany, udostępnienie plików obiektowych pozwala użytkownikowi końcowemu na ponowne skompilowanie aplikacji, łącząc się z inną wersją biblioteki.

Czy to prawda, a jeśli nie, to dlaczego?

lgpl static-linking

— IvanB
źródło

Tak, masz całkowitą rację. Dostarczenie plików obiektowych dla aplikacji jest wystarczające, aby zaspokoić licencję LGPL, ponieważ pozwala użytkownikowi zastąpić bibliotekę LGPL inną wersją, jeśli tak zdecyduje.

FSF nawet tak wyraźnie mówi w swoich FAQ :

W celu zapewnienia zgodności z licencją LGPL (dowolna istniejąca wersja: v2, v2.1 lub v3):

(1) Jeśli łączysz się statycznie z biblioteką LGPL, musisz także dostarczyć aplikację w formacie obiektowym (niekoniecznie źródłowym) , aby użytkownik miał możliwość zmodyfikowania biblioteki i ponownego połączenia aplikacji.

(2) Jeśli dynamicznie łączysz się z biblioteką LGPL już obecną na komputerze użytkownika, nie musisz przekazywać źródła biblioteki. Z drugiej strony, jeśli sam przenosisz bibliotekę wykonywalną LGPL wraz z aplikacją, niezależnie od tego, czy jest ona powiązana statycznie, czy dynamicznie, musisz również przekazać źródła biblioteki, na jeden ze sposobów, które zapewnia LGPL.

— Ixrec
źródło

Dlaczego więc „osoby z zewnątrz” Qt i pracownicy ciągle twierdzą, że jest inaczej? Czy zmodyfikowano LGPL Qt czy coś takiego?

— IvanB

Nie znam sytuacji Qt, ale po przejrzeniu ich stron licencyjnych nie widzę żadnego języka, który wyraźnie zaprzeczałby tej możliwości. Myślę, że po prostu pomijają to na korzyść dynamicznego linkowania (co jest prawdopodobnie prostszym rozwiązaniem dla większości użytkowników). Najbardziej odpowiednie sformułowanie, które widzę to: „W przypadku statycznego łączenia biblioteki, sama aplikacja może już nie być„ pracą korzystającą z biblioteki ”i tym samym stać się przedmiotem licencji LGPL. Zaleca się albo połączenie dynamiczne, albo udostępnienie kod źródłowy aplikacji dla użytkownika na podstawie LGPL. ”, co jest całkowicie uzasadnione.

— Ixrec

Wygląda również na to, że niektóre moduły Qt są dostępne tylko na GPL, a nie na LGPL, jeśli dobrze czytam te strony, więc możliwe jest, że gdyby wspomniały o opcji statycznego linkowania z obiektami, musiałyby się też przyczepić „chyba że użyjesz X, Y lub Z” i podobnych nudnych szczegółów stycznych.

— Ixrec

W idealnym świecie dynamiczne łączenie może być świetne, ale na tym świecie i w przypadku Qt, dynamiczne łączenie jest piekłem. Jak ponad 60 megabajtów bibliotek DLL, z których wiele nie jest dostępne w narzędziu do wdrażania, a walker zależności nie wykrywa. W ich często zadawanych pytaniach dotyczących licencji LGPL nie widzę

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.

nic, co by było obowiązkowe.

— IvanB

Po przeczytaniu często zadawanych pytań wydaje się, że po prostu nie podnoszą (fałszywego) twierdzenia, że LGPL nie zezwala na to, by zastrzeżone aplikacje łączyły się statycznie z Qt, jednocześnie bardzo pilnie implikując.

— IvanB

Czy udostępnianie plików obiektowych jest zgodne z klauzulą ​​ponownego połączenia LGPL?

Czy udostępnianie plików obiektowych jest zgodne z klauzulą ponownego połączenia LGPL?