Apakah menyediakan file objek memenuhi klausa relink LGPL?

Dari pertanyaan ini di SO , saya membaca bahwa:

Kode Sumber Kepemilikan + Kode Sumber LGPL

ditautkan secara statis:
- Anda harus melepaskan kedua bagian sebagai LGPL.
- Atau sediakan segala sesuatu yang memungkinkan pengguna untuk menghubungkan kembali aplikasi dengan versi berbeda dari kode sumber LGPL. Dalam hal ini persyaratan lainnya sama seperti jika itu terkait secara dinamis.

Jadi kedengarannya seperti menyediakan file objek sudah cukup untuk memuaskan LGPL dalam hal menghubungkan secara statis perpustakaan LGPL ke aplikasi kode berpemilik. Sementara executable terhubung secara statis, menyediakan file objek memungkinkan pengguna akhir untuk mengkompilasi ulang aplikasi, menghubungkan ke versi perpustakaan yang berbeda.

Apakah ini benar, dan jika tidak, lalu mengapa?

lgpl static-linking

— IvanB
sumber

Ya, Anda sepenuhnya benar. Menyediakan file objek untuk aplikasi Anda cukup untuk memuaskan LGPL karena memungkinkan pengguna untuk mengganti perpustakaan LGPL dengan beberapa versi lain jika mereka memilihnya.

FSF bahkan mengatakannya secara eksplisit dalam FAQ mereka :

Untuk tujuan mematuhi LGPL (versi yang masih ada: v2, v2.1 atau v3):

(1) Jika Anda menautkan secara statis terhadap pustaka LGPL, Anda juga harus memberikan aplikasi Anda dalam format objek (tidak harus sumber) , sehingga pengguna memiliki kesempatan untuk memodifikasi perpustakaan dan menautkan kembali aplikasi.

(2) Jika Anda secara dinamis menautkan ke perpustakaan LGPL yang sudah ada di komputer pengguna, Anda tidak perlu menyampaikan sumber perpustakaan. Di sisi lain, jika Anda sendiri menyampaikan pustaka LGPL yang dapat dieksekusi bersama dengan aplikasi Anda, apakah terkait dengan statis atau dinamis, Anda juga harus menyampaikan sumber pustaka, dengan salah satu cara yang disediakan LGPL.

— Ixrec
sumber

Jadi mengapa Qt "orang dalam" dan karyawan terus-menerus mengklaim sebaliknya? Apakah LGPL Qt dimodifikasi atau semacamnya?

— IvanB

Saya tidak terbiasa dengan situasi Qt, tetapi dari membaca halaman lisensi mereka, saya tidak melihat bahasa apa pun yang secara eksplisit menyangkal kemungkinan ini. Saya pikir mereka hanya menghilangkannya demi merekomendasikan tautan dinamis (yang mungkin merupakan solusi sederhana untuk sebagian besar pengguna). Kata-kata yang paling relevan yang saya lihat adalah: "Dalam hal penghubung statis perpustakaan, aplikasi itu sendiri mungkin tidak lagi menjadi" karya yang menggunakan perpustakaan "dan dengan demikian menjadi tunduk pada LGPL. Disarankan untuk tautan baik secara dinamis, atau menyediakan kode sumber aplikasi ke pengguna di bawah LGPL. ", yang sepenuhnya masuk akal.

— Ixrec

Ini juga terlihat seperti beberapa modul Qt hanya tersedia di bawah GPL daripada LGPL, jika saya membaca halaman ini dengan benar, jadi ada kemungkinan bahwa jika mereka menyebutkan tautan statis dengan opsi objek, mereka juga harus memperbaiki "kecuali Anda menggunakan X, Y, atau Z" dan detail tangensial membosankan yang serupa.

— Ixrec

Di dunia yang sempurna, tautan dinamis mungkin bagus, tetapi di dunia ini dan ketika berhadapan dengan Qt, tautan dinamis adalah neraka. Seperti 60+ megabita dll, banyak di antaranya alat penyebaran tidak membawa dan walker ketergantungan tidak mendeteksi. Dalam FAQ LGPL mereka sendiri, saya tidak melihat

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.

apa-apa tentang keharusan.

— IvanB

Membaca FAQ mereka, tampaknya mereka hanya malu untuk membuat klaim (palsu) bahwa LGPL tidak mengizinkan aplikasi berpemilik untuk menghubungkan secara statis ke Qt, sementara sangat rajin menyiratkannya.

— IvanB