Nesne dosyaları sağlamak LGPL yeniden bağlama yan tümcesini karşılar mı?

SO'daki bu sorudan şunu okudum:

Tescilli Kaynak kodu + LGPL Kaynak kodu

statik olarak bağlı:
- Her iki parçayı da LGPL olarak serbest bırakmalısınız.
- Veya kullanıcının uygulamayı LGPL kaynak kodunun farklı bir sürümüyle yeniden bağlamasını sağlayan her şeyi sağlayın. Bu durumda, diğer gereksinimler dinamik olarak bağlanmış gibi aynıdır.

Bu nedenle, bir LGPL kitaplığını özel bir kod uygulamasına statik olarak bağlama açısından LGPL'yi tatmin etmek için nesne dosyaları sağlamak gibi bir ses çıkarır. Yürütülebilir dosya statik olarak bağlıyken, nesne dosyalarının sağlanması son kullanıcının uygulamayı yeniden derlemesine ve kitaplığın farklı sürümüne bağlanmasına olanak tanır.

Bu doğru mu, değilse de neden?

lgpl static-linking

— IvanB
kaynak

Evet, tamamen haklısın. Uygulamanız için nesne dosyalarının sağlanması, LGPL'yi tatmin etmek için yeterlidir, çünkü kullanıcının isterse LGPL'd kütüphanesini başka bir sürümle değiştirmesine izin verir.

FSF bile SSS'lerinde açıkça şunu söylüyor :

LGPL (herhangi bir mevcut sürüm: v2, v2.1 veya v3) ile uyum amacıyla:

(1) Bir LGPL'd kütüphanesine statik olarak bağlarsanız, uygulamanızı bir nesne (mutlaka kaynak değil) formatında da sağlamanız gerekir , böylece bir kullanıcı kütüphaneyi değiştirme ve uygulamayı yeniden bağlama olanağına sahip olur.

(2) Kullanıcının bilgisayarında zaten mevcut olan bir LGPL'd kitaplığına dinamik olarak bağlarsanız, kitaplığın kaynağını aktarmanız gerekmez. Öte yandan, yürütülebilir LGPL'd kütüphanesini uygulamanızla birlikte kendiniz de iletirseniz, statik veya dinamik olarak bağlıysanız, LGPL'nin sağladığı yollardan biriyle kütüphanenin kaynaklarını da iletmeniz gerekir.

— Ixrec
kaynak

Peki neden Qt "içeriden" ve çalışanlar sürekli aksini iddia ediyorlar? Qt'ın LGPL'si değiştirildi mi?

— IvanB

Qt durumuna aşina değilim, ancak lisans sayfalarını gözden geçirerek bu olasılığı açıkça reddeden herhangi bir dil görmüyorum. Ben sadece dinamik bağlantı tavsiye lehine atlamak düşünüyorum (muhtemelen çoğu kullanıcı için daha basit bir çözümdür). Gördüğüm en alakalı ifadeler: "Kütüphanenin statik olarak bağlanması durumunda, uygulamanın kendisi artık" kütüphaneyi kullanan çalışma "olmayabilir ve bu nedenle LGPL'ye tabi olabilir. Dinamik olarak bağlantı kurmanız veya uygulama kaynak kodu LGPL altında kullanıcıya. ", ki bu tamamen makul.

— Ixrec

Ayrıca, bazı Qt modüllerinin LGPL yerine GPL altında mevcut olduğu anlaşılıyor, eğer bu sayfaları doğru okuyorsam, bu yüzden nesnelerle statik bağlantıdan bahsetmişlerse, "X, Y veya Z kullanmadığınız sürece" ve benzeri sıkıcı teğetsel ayrıntılar.

— Ixrec

Mükemmel bir dünyada, dinamik bağlantı harika olabilir, ancak bu dünyada ve Qt ile uğraşırken dinamik bağlantı cehennemdir. Çoğu dağıtım aracı getirmeyen ve bağımlılık yürüteç algılamayan dll 60+ megabayt gibi. Kendi LGPL SSS'lerinde

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.

zorunlu olmakla ilgili bir şey görmüyorum .

— IvanB

SSS'lerini okurken, LGPL'nin tescilli uygulamaların statik olarak Qt ile bağlantı kurmasına izin vermediğini (ima etmekte) çok iddialı görünüyorlar.

— IvanB