LGPL ve Java

Bu, orijinali İngilizce olan bir sayfanın çevirisidir.

Bu yazı, LGPLv2.1'in lisansın en güncel sürümü olduğu zaman, Kasım 2004'te yazıldı. O tarihten sonra LGPLv3 yayınlandı. Bu yazının LGPLv3 hakkındaki ana fikri doğruluğunu korusa da, bazı ayrıntılar, örneğin bölüm numaraları, değişti.

Her zaman FSF'nin görüşü, uygulamaların, kütüphanelere dinamik olarak bağlanmasının hem kütüphane hem de uygulama kodundan türetilmiş tek bir çalışma ürettiği şeklindeydi. GPL tüm bu türetilmiş çalışmaların bir bütün olarak GPL altında lisanslanmasını gerektirir, “kalıtsal” olarak betimlenebilecek bir etki. Bu nedenle, eğer bir uygulama GPL altında lisanslı bir kütüphaneye bağlanırsa, uygulamanın da GPL altında lisanslanması gerekir. Buna karşın, GNU Kısıtlı Genel Kamu Lisansı (LGPL) altındaki kütüphaneler, özel mülk uygulamalara bağlanabilirler.

2003 yılı Temmuz ayında Slashdot'ta yayınlanan bir yazıda, Java örneğinde LGPL'nin istendiği şekilde işlemediği şeklinde bir savım olduğunu iddia etti. Bu yazı, licensing@gnu.org'a gönderilen bir soruya yanıtın yanlış anlaşılmasından kaynaklanıyor ve Slashdot yazısındaki sorunları açıklamaya yönelik birçok çaba kabul edilmedi. O zamandan beri yazı hakkında, hem licensing@gnu.org hem de kişisel e-postam aracılığıyla birçok soru aldım.

Başından sonuna kadar FSF'nin konumu sabit kalmıştır: LGPL, Java da dahil olmak üzere tüm bilinen programlama dilleriyle istendiği şekilde işliyor. LGPL kütüphanelerine bağlanan uygulamaların LGPL altında lisanslanması gerekmiyor. Uygulamalar sadece LGPL'nin 6. bölümündeki gereksinimleri izlemelidir: kütüphanenin yeni sürümlerinin uygulamalara bağlanmasına izin verin; ve buna ilişkin hata ayıklama için ters mühendisliğe izin verin.

Java'ya özgü düzenleme, bir uygulamanın kullandığı her kütüphanenin ayrı bir JAR (Java Arşiv) dosyası olarak dağıtılmasıdır. Uygulamalar, bu kütüphanelerden sınıflara erişmek için Java'nın “import” işlevselliğini kullanırlar. Uygulama derlendiğinde, fonksiyon imzaları kütüphaneyle karşılaştırılır, bir bağlantı oluşturulur. Uygulama, o halde, genellikle kütüphanenin türetilmiş bir çalışmasıdır. Bu yüzden, kütüphanenin telif hakkı sahibi çalışmanın dağıtımına yetki vermelidir. LGPL bu dağıtıma izin verir.

Eğer LGPL kütüphaneleri içe aktaran bir Java uygulaması dağıtıyorsanız, LGPL lisansına uymak kolaydır. Uygulamanızın lisansı, kullanıcıların kütüphaneyi değiştirmesine ve bu değişikliklerin hata ayıklaması için kodunuzun ters mühendisliğine izin vermelidir. Bu, uygulamanızın kaynak kodunu veya herhangi bir içsel ayrıntısını sağlamanız gerektiği anlamına gelmiyor. Elbette, kullanıcıların kütüphanede yaptığı bazı değişiklikler arayüzü bozabilir, kütüphanenizin uygulamanızla çalışmasını olanaksız kılabilir. Buna ilişkin kaygılanmanıza gerek yok, kütüphaneyi değiştiren kişiler çalışmasını sağlamaktan da sorumludur.

Kütüphaneyi uygulamanızla (veya tek başına) dağıttığınızda, kütüphanenin kaynak kodunu da eklemelisiniz. Ancak uygulamanız kullanıcıların kütüphaneyi kendi başlarına almasını gerektiriyorsa, kütüphanenin kaynak kodunu sağlamanıza gerek yok.

LGPL'nin bakış açısından Java ve C arasındaki tek fark Java'nın, kalıtımı destekleyen, nesne yönelimli bir programlama dili olmasıdır. LGPL, gereksinim duymadığı için, kalıtıma özel şartlar içermez. Kalıtım, geleneksel bağlamayla aynı şekilde türetilmiş çalışmalar oluşturur ve LGPL bu türdeki türetilmiş çalışmalara, olağan fonksiyon çağrılarına izin verdiği şekilde izin verir.