Yine uzunca bir aradan sonra benim için heyecan verici bir konuda blog yazmaya karar verdim. Yakın çevrem tarafından artık gündelik bir olay halinde kanıksanan uykusuzluk krizlerim boyunca geçtiğimiz haftalarda okuduğum bir olayı aktarmak istiyorum.
Önce sıkıcı özet ve bi çimdik tarih dersi
Malum Android cephesinde bir yandan özgür yazılım kullanan ve savunan pek çok kişiyi sevindiren gelişmeler olurken bir yandan da kara bulutlar bu büyük yazılım projesinin peşini bırakmıyor. Daha popüler olduğu için sürekli gündemde olan Apple ve OEM üretici davaları bir yana asıl büyük sorunlara gebe olacak kısım özellikle Java ile ilgili konularda Oracle ve Google arasında. Her ne kadar davayı gören yargıç sulhe imkan tanımak amacıyla davayı bir miktar ertelemiş bile olsa Android’in özellikle bu dava sonucunda yara alması kaçınılmaz gibi duruyor.
Benim ilgimi çeken konuysa Android’in bazı konularda GPL’in etrafından dolaştığı ve GPL’in katı copyleft kuralını ihlal ettiği iddiası oldu.
Malum Android’in kalbini şu an Linux çekirdeğinin 2.6 ailesi oluşturuyor ve blogu takip edenlerin bileceği gibi bu çekirdek GPLv2 ile lisanslanıyor. Bu sayede hepimiz özgürce bu çekirdeği kullanabiliyor, değiştirebiliyor ve değiştirdiğimiz halini dahi yeniden dağıtabiliyoruz. Çekirdeğin yazıldığı dil gereği çekirdek geliştiricileri yazılımın bütününü oluşturan değişkenleri, sınıfları ve diğer tanımlamaları header -başlık- dosyalarında tanımlayıp daha sonra bu dosyaları yazılımın genelinde kullanarak hem aynı tanımlamaları tekrar tekrar yapmaktan kurtuluyor hem de istedikleri değişiklikleri tek bir noktada uygulayıp tüm yazılım genelinde etkin olmasını sağlıyorlar. Bu teknik zaten yıllardır C, C++ gibi pek çok dilin temel özelliği olarak kullanılıyor.
Linux çekirdeği de yaklaşık 750 dosyadan oluşan bir header setine sahip. Bu dosyalar tıpkı bağlı oldukları yazılım gibi GPL ile lisanslanmış durumda. Bu header dosyalarında tanımı yapılmış fonksiyonlar ve tanımlamalar aslında bu çekirdeğin üst katmanlarında çalışan yazılımların sistem çağrıları yapması için de bir API sunması açısından son derece önemli. Bir sistem kaynağı kullanmak isteyen yazılımlar bu API’den faydalanarak çekirdeğe ve onun üstünden kullanmak istedikleri sistem kaynağına -örneğin bir donanıma- ulaşabiliyor. Linux dünyasında bu dosyalar “raw headers” olarak isimlendiriliyor ve aslında teamül bu dosyalar yerine başka bir kitaplık ile çekirdeğe sistem çağrıları gönderilmesi üstüne kurulmuş durumda.
1990lı yılların başında Linux ekibi çeşitli lisans çakışmaları önlemek ve geliştiricilerin daha rahat çalışmasını sağlamak amacıyla zaten bu header dosyalarının oluşturduğu gurubu forklamıştı. Daha sonra FSF tarafından GNU işletim sistemi için geliştirilen ve hepimizin tanıdığı GNU C Libary -glibc- yine bu ekip tarafından forklanıp uzun yıllar bakımı yapılmıştı. 1997 yılında FSF’in glibc 2.0 yayınlamasıyla bu kitaplıkla gelen özellikleri gören Linux ekibinin forklarını öldürmesi ve FSF’in glibc ağacına geri dönmesi ile glibc sistem çağrıları vb. teknik işler için özgür yazılım dünyasının değişmez standardı oldu.
Glibc’nin kernel header dosyalarının sunduğu API yerine bu kadar çok kullanılıyor olmasının teknik nedenleri bir yana en önemli nedeni GPL yerine LGPL ile lisanlanması. Bu lisans uyarınca bu kitaplığı, kitaplığın kendisinde değişiklik yapmadığınız ve kitaplığın kodunu yazılımla beraber dağıtmanız halinde kapalı kaynak kodlu projelerde de glibc kullanılmasının mümkün olması.
Hızlandırılmış tarih dersi sonrası günümüze gelelim. Yukarılarda bir yerde Android’in kalbinde Linux çekirdeği olduğunu söylemiştik. İşte bu çekirdeğin yönettiği donanıma kullanıcı seviyesinde çalışan yazılımların ulaşması için çekirdekle bu yazılımların arasında arayüz oluşturacak bir API gerekiyor. Elbette hemen aklınıza Google’ın da glibc kullandığı fikri gelecek olsa bile durun hemen heyecanlanmayın.
Google üç temel nedenle API sağlamak amacıyla glibc kullanmıyor. Bunun ilki özellikle glibc’nin çok fazla platform için geliştirilmesi nedeniyle gömülü sistemlere uymayan pek çok fonksiyonu bünyesinde barındırıyor olması. Sırf bu yüzden zaten glibc farklı isimler altında bu gömülü sistemler için forklanmış durumda.
İkinci neden üreticilere özelleştirdikleri Android sürümlerini ve cihazları belirli sürümlere, belirli operatörlere, belirli ayarlara kilitleyebilme özgürlüğünü sağlamak. Glibc her ne kadar LGPL olsa bile kitaplıkta yapılan değişikliklerin yayınlanması zorunlu olduğundan üreticilerin glibc kullanarak cihazları belirli ayarlara kilitlemesi mümkün olmayacak.
Üçüncü ve son nedense Google’ın bir ilke kararı. Google ileride yazılım geliştiricileri -burada kastettiğim uygulama geliştiricileri- çeşitli lisans ihlalleri iddialarından korumak amacıyla userspace seviyesinde hiç bir GPL -ve copyleft- lisanslı yazılım girmesine izin vermiyor. Bu yüzden glibc Android’de kullanılmıyor.
Bu adamlar ne yapıyor
Peki userspace alanında çalışan yazılımların çekirdekle çalışmasını sağlamak amacıyla Google’ın geliştirdiği çözüm ne diye merak ediyorsanız hemen söyleyelim. Çözümün adı -ve belki sorunun adı – Bionic!
Bionic temel olarak yazılımla çekirdek arasında sistem çağrılarını sağlamak amacıyla kullanılan arayüzü oluşturan bir kitaplık. Bu kitaplık yine bir özgür yazılım lisansı olan BSD lisansı ile yayınlanıyor. BSD lisansı bir copyleft lisansı olmadığından isteyenler bu kitaplığı kaynak kodunu vermeden ve ister açık isterse kapalı kaynak kodlu yazılımlarda kullanabiliyor.
Buraya kadar herhangi bir sorun yokken asıl dert burada başlıyor. Bionic, Google’ın sıfırdan başladığı bir proje değil aslında. Google ekibi Linux çekirdeğinin raw header dosyalarını alıyor ve bu dosyaları kendi tabirleri ile bir temizliğe tabi tutuyor. Bu “temizlik” neticesinde Google header dosyaları içinde yer alan ve konusu fikri mülkiyete dahil olabilecek -dolayısı ile GPL lisanslı – tüm içeriği temizliyor ve geri kalan dosyaları bir kitaplık haline getirip Bionic ismiyle BSD lisansı ile yayınlıyor.
Bu temizleme betiği tüm header dosyalarını dolaşıp Android platformunda kullanılmayacak tüm tanımlama ve fonksiyonları, aynı zamanda header’lar içinde yer alan tüm yorumları, lisans bilgilerini siliyor. Bununla birlikte Android’in kullandığı tanımlamaları ve header dosyası içinde yer alan bazı makro ve fonksiyonlara ise dokunmuyor.
Lisans ihlali mi?
Bir fikri ürünün – örneğin yazılım- korunması ve eser sayılması için taşıması gereken temel özelliklerden birisi onu meydana getiren insanın özelliğini -kanun terimi ile hususiyetini- taşıması. Bu yüzden herhangi bir fikri çaba sarfedilmeden ortaya çıkan ürünler eğer onu meydana getirenin özelliğini taşımıyorsa eser sayılmazlar.
İşte bu noktada GPL ile lisanslanmış bir yazılımın, BSD ile yayınlanabileceğini ve bunun bir lisans ihlaline yol açmayacağını iki temel nedene dayandırılıyor. Tabi hemen bu söylenenlerin Google’ın resmi görüşü olmadığı sadece meraklı hukukçuların düşüncüleri olduğunu söyleyelim
Bunlardan ilki Google’ın temizlik betikleri ile hususiyet gösteren ve dolayısı ile eser olan bütün kodun, yorumların header dosyalarından çıkarması. Bu sayede geri kalan parçanın herhangi bir hususiyet göstermeyeceği ve bu yüzden lisanslanamayacağı düşüncesi.
İkincisi ise Amerika da konu ile ilgili daha önce verilmiş mahkeme kararları doğrultusunda oluşturulan bir kanı. 1992, 93 ve 2004 yıllarında farklı konularda verilen kararlar bu düşüncenin temelini oluşturuyor. En yeni karar olan 2004 kararında Lexmark yazıcılar için OEM kartuş üreten bir firma ürettiği kartuşlarda Lexmark’ın kartuş yetkilendirme kodunu -kartuşun orijinal olup olmadığını yazıcıya söyleyen 55 byte uzunluğunda kod- aynen kopyalamış ve kendi kartuşlarında kullanmıştı. Lexmark telif hakkı ihlali gerekçesi ile açtığı dava açmış ve dava kartuş üreticisi lehine sonuçlanmıştı.
Mahkeme temel olarak, üretilen bir kartuşun yazıcı ile çalışması için gerekli arayüzün oluşturulabilmesi için tek bir yol varsa bu yolun kullanılması için gerekli yazılımın kopyalanmasının adil kullanım olacağını ve telif ihlali yaratmayacağı kararını vermişti. Bu karar 1993 yılında ünlü -kime göre neye göre- Atari vs Nintendo davasında da benzer bir şekilde çıkmıştı.
Bu noktada Linux çekirdeği ile arayüz oluşturulması için mümkün olan tek yolun bu dosyaların kullanılması olduğu düşüncesiyle bu dosyaların GPL’e aykırı bir şekilde kopyalanması ve dağıtılmasının adil kullanım olacağı iddiası ortaya atılabilir.
İşte iş bu noktada benim diyecek yazılım uzmanı avukatı zorlayacak o güzel noktaya geliyor. Burada olası bir lisans ihlali söz konusu mu yoksa değil mi?
Aslında bionic’in her satırının tek tek incelenerek bu dosyalarda konusu fikri mülkiyete ait bazı kod parçalarının olup olmadığını incelemek gerekiyor. Özellikle bazı dosyalarda performansı arttırmak için header dosyalarında yer alan makroların korunması bana göre dosyalarda hala onu oluşturan kişinin hususiyetinin korunduğunun göstergesi.
Daha önemlisi ise tek tek dosya bazında incelemek yerine genel olarak yapılacak bir inceleme. Günümüzde artık sunduğunuz API’nın yazılımınızın ve hatta şirketinizin bir değeri haline geldiğini ve çoğu şirketin özel API’lerini korumak için önlem aldığını düşünecek olursak genel olarak tüm header dosyalarının oluşturduğu API’nın bir eser değeri taşımadığını söylemek çok doğru olmayacaktır.
GPL’in etrafından dolaşmak aslında herkes için son derece tehlikeli sonuçlar oluşturuyor. Bu sonuçlardan ilki isteyen birinin bionic kitaplığında yer alan tanımlamaları gerçekleyen bir yazılım geliştirmesi halinde Android’de yer alan çekirdeğin kapalı kaynak kodlu bir eşini oluşturması mümkün. Bu son derece teorik bir hikaye gibi görünse de pazarın büyüklüğünü düşünürsek neden olmasın dedirtecek bir durum.
İkinci tehlike elbette GPL ve onun kapsama alanı. GPL ile bu detayda oynamak onu workaround etmek için çeşitli yöntemler aramak bana kalırsa gelecekte özgür yazılım açısından gelecekte sıkıntılar doğurabilir.
Üçüncü tehlike ise elbette Android geliştiricileri için. Her ne kadar Google Bionic’i onlara korumak için üretmiş olsa bile bir gün Bionic’in GPL’i ihlal ettiği kanısına varılır ve doğal olarak Bionic GPL olmak durumunda kalırsa şu ana kadar Bionic’i kullanan tüm yazılımlar GPL olmak zorunda kalacak.
LKML listelerini takip edenler çekirdeğe yapılan sistem çağrılarının ve bu çağrıları yapan yazılımın GPL olması gerekmediğini bilirler fakat burada bu çağrıları yapan kitaplığın GPL olması durumunda bu kitaplığı kullanan yazılım GPL olmak durumunda kalacaktır.
Google şu anda belki yukarıda bahsettiğim belki başka nedenlere dayanarak “temiz” Boinc dosyalarının GPL olması gerekmediğine yönelik bir kumar oynamış durumda. Bu kumarın sonucu hepimiz için sürpriz sonuçlara yol açacak. Özellikle Oracle vs Google davasında mahkeme Oracle’ın Java API’sinin genel bir eser olarak korunabileceğine hükmederse benzer bir sonucu olası bir FSF vs Google davasında görebiliriz.
