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

GCC Çalışma Zamanı Kütüphanesi İstisnası Gerekçeleri ve SSS

Giriş

29 Haziran 2007 tarihinde Özgür Yazılım GPLv3 lisansını yayınladı. 15 GNU projesi tarafından anında benimsendi ve izleyen aylarda çok daha fazlası geçiş yaptı. Çoğu GCC kaynak kodu tabanı 4.2.2 sürümünde yeni lisansa göç etti ve şimdi bu süreci tamamlamaya hazırlanıyoruz.

GCC'ye eşlik eden bazı kütüphanelerin lisansları henüz değişmedi. Bu kütüphaneler GCC'nin ürettiği nesne kodu tarafından otomatik olarak kullanılıyor. Bu nedenle, eğer bu kütüphaneler basitçe sadece GPL şartları altında dağıtılsaydı, GCC'nin ürettiği tüm nesne kodunun da aynı şartlar altında yayınlanması gerekirdi. Ancak, FSF yıllar önce geliştiricilerin GCC kütüphanelerini kullanarak, lisansına bakmadan herhangi bir yazılımı derlemesine izin vermeye karar vermişti. Özgür olmayan yazılım geliştirilmemesi toplumumuz için iyi değil ve bizim bunu kolaylaştırma gibi bir yükümlülüğümüz yok. Buna izin vermeye karar vermemizin nedeni, yasaklamanın geri tepebilecek gibi gözükmesi ve GCC'nin kullanımını sınırlamak için küçük kütüphaneler kullanmanın, önemsiz bir ayrıntının önemli bir duruma etki edecek gibi gözükmesiydi.

Bu yüzden, GCC'nin ürettiği nesne kodunu insanların herhangi bir lisans altında dağıtmasına izin vermek için bu kütüphanelerin her zaman lisans istisnaları vardı. Şimdi bu kütüphaneleri GPLv3'e taşıyoruz ve istisnalarını güncelliyoruz. Temel politikamız değişmedi; yeni lisans, önceden izin verdiğimiz tüm GCC kullanımlarına izin vermeyi amaçlıyor. Ancak bu fırsatı üç amaca ulaşmak üzere istisnayı güncellemek için kullanmaya karar verdik:

GPLv3 ile birlikte, taslağı oluştururken çeşitli kullanıcıların kaygılarını dinlemek ve onları uygun bir şekilde ele almak için yoğun çaba gösterdik. Bu süreçte toplamda bir yıldan fazla bir zaman harcadık. Özgür Yazılım Vakfı ve GCC Yürütme Komitesi olarak Yazılım Özgürlüğü Hukuk Merkezi'nden Richard Fontana, Bradley Kuhn ve Karen Sandler'a, istisnaya ilişkin tüm yoğun çabaları ve destekleri için teşekkür ederiz. Buradaki değişiklikler GCC topluluğunu güçlendirecektir, olanak vereceği derleyici geliştirmelerini sabırsızlıkla bekliyoruz.

GCC geliştiricilerin yaşamında önemli bir yer tuttuğu için, bu değişiklikler hakkında birçok soru bekliyoruz ve bu soruların yanıtlandıklarından emin olmak istiyoruz. Aşağıda kullanıcıların aklına geldiğini düşündüğümüz bazı meseleleri ele alıyoruz. Yeni istisna hakkında burada değinilmediğini düşündüğünüz sorularınız varsa, <licensing@fsf.org> adresini kullanarak bizimle bağlantı kurmaktan lütfen çekinmeyin.

İstisna Nasıl Çalışıyor

İhtiyaç duyduğunuz —bu GCC kütüphanelerinden nesne kodunu kendi projenizin lisansıyla taşıma— izni esasen 1. bölümde yer alıyor:

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. [Çalışma Zamanı Kütüphanesiyle, Bağımsız Modüllerin birleşmesinden oluşan bir Hedef Kod çalışmasını, aksi durumda böyle bir yayma GPLv3'ün koşullarını ihlal edecek olsa bile, tüm Hedef Kodun Uygun Derleme Süreciyle üretilmiş olması koşuluyla, yaymaya izniniz vardır. Öyleyse bu tür bir birleşimi, Bağımsız Modüllerin lisanslamasıyla tutarlı olacak bir şekilde, istediğiniz koşullarda yayabilirsiniz.]

Bu bölüm birçok tanımlanmış terim kullanıyor ve istisnanın nasıl çalıştığı bu terimlerin anlamlarına çok bağlı. Bu bölümde bu terimlerin başlıca senaryolarla ilişkisine bakıyoruz.

Kendi yazılımınızı yazdığınızda, bir takım kaynak kod dosyaları içerir. Her bir dosya, GCC kütüphanelerinden herhangi bir kaynak kod içermedikçe “Bağımsız bir Modüldür” [Independent Module].

Bu kaynak kod dosyalarını derlediğinizde, genellikle bazı adımlardan geçerler: kaynak kod üretimi, önişleme [preprocessing], düşük düzey koda derleme, birleştirme [assembling] ve bağlama [linking]. Hangi dili kullandığınız ve nasıl yazıldığına bağlı olarak tüm projeler bu adımları izlemiyor olabilir, ancak her zaman evreler bu sıradadır ve GCC kullanan herkes yüksek düzey kodun, birleştirici kodu veya Java bytecode gibi daha düşük düzey bir dile derlenmesi sürecinden geçer. Bu aşama GCC'nin kendi kodunuzla, GCC kütüphanelerinden kodu birleştirdiği veya bağladığı aşamadır. Bu aşamaya “Derleme Süreci” diyoruz. Bu aşamadan elde ettiğiniz çıktı, bu çıktı derleyici tarafından ara bir gösterim olarak veya bu tür bir ara gösterim oluşturmak için kullanılmadığı sürece “Hedef Kod”tur.

Bu izinden yararlanmak için, Hedef Kodu oluşturmak için kullandığınız Derleme Süreci “Uygun” olmalıdır, yani hem GCC hem de GPL uyumsuz yazılım içermemelidir. Derleme Sürecinin, GCC'ye herhangi bir yüksek düzey kod beslediğinizde başladığını ve Hedef Kod olarak değerlendirilebilecek bir şey ürettiğinde bittiğini unutmamalısınız. Bu nedenle, GCC ara bir gösterim yazmadığı sürece Derleme Süreciniz, GCC'yi GPL ile uyumsuz birleştiriciler, bağlayıcılar veya yüksek düzey kaynak üreticiler ile birlikte kullansanız bile yine de Uygun olabilir, bu programlar burada tanımlanan Derleme Sürecinde yer almıyorlar. GCC ile birlikte GPL ile uyumsuz yazılımı kullanamayacağınız tek yer ana derleme çalışmasını yaparkendir.

Dolayısıyla, eğer, ister GPL ile uyumsuz iyileştirmelerle olsun ister olmasın GCC kullanırsanız, bu Uygun bir Derleme Süreci olacaktır. Eğer sadece GPL ile uyumsuz derleyici araçları kullanırsanız, bu da Uygun Derleme Süreci olacaktır (insanların GNU/Linux yazılımları oluştururken, farklı bir derleyici kullansalar bile GCC kütüphaneleriyle bağlamaları alışılmamış bir uygulama değildir). Ancak, eğer GCC'yi, yüksek düzeyde kodu düşük düzeyde koda dönüştürme işlemi sırasında GPL ile uyumsuz yazılımla kullandıysanız, bu Uygun Derleme Süreci olmayacaktır. Bu, örneğin, GCC'yi özel mülk bir eklentiyle kullanırsanız olacak olandır.

Uygun Derleme Süreci kullandığınız sürece, GCC'nin ürettiği Hedef Kodu almaya ve “istediğiniz koşullar altında” yaymaya izniniz vardır.

Derleme Süreci sırasında GCC ile birlikte GPL ile uyumsuz yazılım kullandıysanız, bu izinden yararlanamazsınız. GCC'nin ürettiği tüm nesne kodu bu GPL altındaki kütüphanelerden olacağı için, bu nesne kodunun herhangi bir kısmını yaymak için GPL'nin şartlarını izlemeniz gerekecekti. GCC'yi kendi GPL uyumsuz yazılımınızı geliştirmek için kullanamazsınız.

Sıkça Sorulan Sorular

GPL ile uyumsuz bir yazılım derlemek için (FSF tarafından sağlanan veya işletim sistemimle gelen) standart bir GCC sürümü kullanıyorum, bu değişiklik beni nasıl etkiler?

Sizi hiç etkilememesi gerekiyor. Eğer GCC'yi ara gösterimleri çıktı olarak verecek şekilde ayarlamadıysanız (bu çok nadirdir), yeni istisna, derleme yaparken herhangi bir lisans yükümlülüğünüz olmayacak şekilde tasarlanmıştır, tıpkı eski istisnaların olduğu gibi.

Bu değişiklik kimi etkiliyor?

Şu an GCC kullanan hiç kimsenin bu değişiklikten etkilenmesini beklemiyoruz. Politikadaki tek değişiklik, geliştiricilerin GCC'ye gelecekte elverişli hale gelebilecek belirli değişiklikleri yapmasını önlemektir. FSF, GCC'nin bugün farklı insanlar tarafından nasıl kullanıldığını öğrenmek için ve bu faaliyetlerine yeni istisna altında da devam edebilmelerini güvence altına almak için GCC geliştiricileriyle yakın bir şekilde çalışıyordu.

Programımı derlemek için GCC'yi özel mülk önişlemcilerle ve/veya kaynak üreticilerle birlikte kullanıyorum. Yine de bu istisnadan yararlanabilir miyim?

Evet. Derleme Süreci “ara bir dilde değil de, tamamen yüksek düzeyde temsil edilen herhangi bir kod ile” başlayabilir. Bu bir önişlemci veya başka özel mülk yazılım tarafından üretilen kodları da içerir. Bu durumda Derleme Süreci herhangi bir özel mülk yazılım içermez. Uygun olarak nitelenebilir ve bu program için istisna kullanılabilir.

Programımı derlemek için GCC'yi özel mülk birleştiriciler ve/veya bağlayıcılarla birlikte kullanıyorum. Yine de bu istisnadan yararlanabilir miyim?

Evet. Derleme Süreci, derleyici “çalıştırma aşaması ve/veya bir birleştirici, yükleyici veya bağlayıcı için uygun bir girdi” olan çıktıyı içeren Hedef Kod ürettiğinde tamamlanır. Başka bir deyişle, bu durumda Derleme Süreci, kodunuzu birleştirdiğinizde veya GCC'den nesne dosyalarının bağlantısını kaldırdığınızda tamamlanmıştır, dolayısıyla herhangi bir özel mülk yazılım içermez. Uygun olarak nitelenebilir ve bu program için istisna kullanılabilir.

Programımın bazı kısımlarını derlemek için GCC ve diğer kısımlarını derlemek için özel mülk bir derleyici kullanıyorum. Parçalar daha sonra birleştirme veya bağlama aşamasında bir araya getiriliyor. Yine de bu istisnadan yararlanabilir miyim?

Evet. Bu durumda, her Bağımsız Modül Uygun Derleme Süreci aracılığıyla bir Hedef Kod'a dönüşüyor. Her ne kadar farklı modüller farklı süreçlerden geçse de, bu program için istisna kullanılabilir.

Programımı derlemek için, GCC'nin hiçbir kısmını kullanmadan özel mülk derleyici araç kümesi kullanıyorum ve onu libstdc++ ile bağlıyorum. Programımın kendisi, GCC ile derlenmiş programların libgcc içermesiyle aynı şekilde herhangi bir çalışma zamanı kütüphanesi kodu içermiyor. Yine de bu istisnadan yararlanabilir miyim?

Evet. Her ne kadar GCC derlenmiş kod ile libgcc'yi birleştirmek bu istisnanın en yaygın kullanıldığı durum olsa da, ne GPL ne de GCC Çalışma Zamanı Kütüphanesi İstisnası statik bağlama ile dinamik bağlama veya kodu kendi koşullarında birleştirmenin diğer yöntemleri arasında bir fark görmüyor. Aynı izinler, hangi metodu kullandığınızdan bağımsız olarak, aynı koşullar altında sizin için de geçerli.

Ama unutmayın, libstdc++ bağımsız bir kütüphane olarak dağıtırsanız, GPL'nin koşullarını izlemeniz gerekir. Örneğin, eğer kütüphanenin kendisini nesne kodu şeklinde dağıtırsanız, alıcılarınıza GPLv3'ün 6. bölümünde listelenen yöntemlerden birini kullanarak kaynak kodunu da sağlamalısınız. Ancak kendi programınız için GCC Çalışma Zamanı Kütüphanesi İstisnası'ndan yararlanmaya uygun olduğunuz sürece, GPL'nin koşulları sizi etkilemez.

Neden derleyicinin ara gösterimi “Hedef Kod” tanımı kapsamında değil?

GCC'ye bir eklenti altyapısı eklemeyi ilk düşündüğümüzde, birinin GCC'nin içsel, düşük düzey derleme veri yapılarını yalnızca diske kaydeden bir eklenti yazma ihtimaline karşı derin bir kaygı duyduk. Bunun yapılmasıyla, diğer yazılımlar GCC'ye doğrudan bağlı olmadan kodu eniyilebilir veya geliştirebilirdi. Bu programların GPL'nin copyleftine tabi olduğunu öne sürmemiz bizim için zor olabilirdi, bu yüzden bu gibi düzenlemelerden caydırmak istedik.

Bunu, bu gibi çıktıları Hedef Kod tanımının dışında tutarak yapıyoruz. Böylece, eğer biri bu bilgiyi diske kaydeden bir eklenti yazsa bile, GCC Hedef Kodu yazmadan yapıları değiştiren herhangi bir program Derleme Sürecinde yer almış olacak. Eğer bu program özel mülk ise ,onunla derlenen hiçbir program istisna kapsamında yer almayacak; GCC'nin sonuçta oluşturduğu nesne kodunun, GPL şartları kapsamında dağıtılması gerekecek.

Birleştirici dili kapsamında bir kod yazarsam, bu kodu, normal olarak derlenmiş başka kodlarla birleştirebilir miyim ve yine de bu istisnadan yararlanabilir miyim?

Tüm nesne kodu Uygun Derleme Süreci aracılığıyla derlendiği sürece, evet. Elle yazılmış birleştici kodunu, bir birleştirici aracılığıyla çalıştırmak, “tamamen, insan tarafından yazılmış kod için tasarlanmış [bir] ara olmayan dilde[] temsil edilen kodu... Hedef Koda dönüştür[düğü]” için bir Derleme Sürecidir.

GCC Çalışma Zamanı Kütüphanesi İstisnası hangi kütüphaneleri kapsıyor?

GCC Çalışma Zamanı Kütüphanesi İstisnası, lisans başlıklarında bu istisnanın geçerli olduğuna ilişkin bildirimde bulunan herhangi bir dosyayı kapsar. Bu kapsamda libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov, ve GCC ile dağıtılan diğer kütüphaneler var.

Classpath bu yeni istisnayı mı kullanacak?

Her ne kadar Classpath'ın yeni istisnası benzer bir amaç gütse de, onu şimdi güncellemiyoruz. Çünkü özgür yazılım Java topluluğunda yaşanan son gelişmeler nedeniyle, Classpath'ın lisans politikalarının öncelikleri, GCC kütüphanelerinkinden farklıdır ve onu bağımsız olarak değerlendiriyoruz.