Yaklaşık iki ay önce işlerin yoluna girebileceğini, ayrılmaların Pardus’un gelişimini etkilemeyeceğini anlatan; geçmişten bir çok örnek içeren bir nevi bir moral yazısı yazmıştım. O yazı da yazdıklarım hala geçerli tabi ki. Fakat yazının başlığından olsa gerek insanlar benim de Pardus’tan ayrıldığımı düşünmüş olacaklar dı ki, ayrıca bir de dipnot eklemiştim bir yere gitmediğime dair. Şimdi o dipnot yalan oldu, 14 Aralık 2011, benim Pardus ofisinde çalıştığım son gün oldu.

Neden ayrıldığımı soracak olursanız cevabım kısaca “sıkıldım” olacak, cevabımın nedenlerini bilenler biliyordur, bilmeyenler de bilmesin…

Bugün bu yazıyı yazdığımda Pardus ofisinden ayrılışımın ikinci haftasındayım. Neredeyse 6 yıldır aynı insanlarla, aynı konu üzerinde fakat her zaman farklı alanlarda çalıştım. Özgür yazılıma katkım o veya bu şekilde yine olacaktır fakat yeni işim (Sigma RD’de Kinect ile akla hayale sığmayacak teknolojiler geliştiriyoruz, dünyayı ele geçireceğiz) gereği eskisi gibi çalışamayacağım aşikar. Özgür yazılım camiasına, özgür yazılım kullanan insanlara bir yararım dokunduysa ne mutlu bana. Sağlıcakla kalın.

Bu paragraftan sonrakilerin hiçbirini okumasanız da olur, kendi kendime neler yapmışımın notlarını aldım sadece.

Özgür yazılıma elle tutulur ilk katkım 2002 yılında yaptığım ilk şenliğin afişiydi (şimdi bakınca berbat gözüken). Şenliğin devamında LKD sayesinde bir çok yerde standlar kurduk, sunumlara katıldık, insanlara özgür yazılımı anlattık.

O dönemlerde Murat Koç’un yönettiği FrontSite adlı şirkette yarı zamanlı çalışmaya başladım, Barış Metin ve Enver Altın ile birlikte çalışma fırsatı buldum.

Kerem Can Karakaş’ın önerisi ve o dönem (2004) Pc World  Genel Yayın Yönetmeni olan Güçlü Aydoğan’ın da desteği ile Pc World dergisinde açık kaynak köşesinde bir süre haber ve inceleme yazıları yazdım.

Bu dönem ve sonrasında da pek sevgili Ümit Bozkır, Arda Çetin ve adını hatırlayamadığım bir çok özgür yazılım gönüllüsü ile birlikte standlar kurduk, fuarlara katıldık, LKD’yi temsil ettik.

Yine bu dönemlerin sonuna doğru Penguen Yazılım bünyesinden Kosgeb desteği alan firmalara Linux’a giriş eğitimi verdim.

Bu arada üniversite bitmek üzereydi, staj yapmam gerekiyordu. 2006 yılında ki Özgür Yazılım günlerinde Erkan Tekman’a Pardus projesinde staj yapıp yapamayacağımı sordum, karşılığında aldığım “stajı boş ver gel yarı zamanlı ekibe katıl” cevabının ardından 2006 Nisan’ında Pardus serüvenim başlamış oldu.

O aralar sıkça ilgilendiğim web teknolojileri konusunda da kendimi geliştirebilmek için aynı zamanlarda Octeth’te PHP ile ilgilendim, Cem Hürtürk’ün de desteği sayesinde Octeth’in amiral gemisi OemPro için bir kaç özellik ekledim.

Sonra okul bitti, artık tam zamanlı olarak bir işe başlamam gerektiğinden 2007 yılında Tübitak Uekae’de Pardus Projesindeki çalışma hayatıma başladım…

2009 Ağustos ayında işe güce kısa bir ara verip 2010 Şubat’ında tekrar işe başladım. 14 Aralık 2011′de ise Tübitak günlerim sona erdi.

Pardus projesinde çalıştığım dönem boyunca bir çok alt projede görev aldım, sahipsiz olan bir çok gereksiz işi de yaptım. Yalı, Yönetici Ailesi, Grafikler, arayüzü olan hemen hemen her Pardus teknolojisine katkıda bulundum. Zaman su gibi geçti gitti. Çok güzel günlerdi, çok güzel insanlarla tanıştım arkadaş oldum. Yaptığım hiç bir şeyden de pişman olmadım. Çoh iyiydi yani.

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.

Meraklılar 20 Eylül günü ilgililerin gündemine bomba gibi düşen Windows 8′in logo programı gereklerini duymuştur. Microsoft yeni çıkaracağı Windows 8 ürünü için üreticilere Ağustos ayında logo programının detaylarını gönderdi. Onlarca isteğin içinde neredeyse bütün özgür yazılım camiasını ilgilendiren en önemli istek Microsoft’un Windows 8 ile önyüklü gelecek bilgisayarların UEFI ile gelmesini istemesi ve üstüne üstlük bir de bu protokolun sunduğu bir özellik olan Secure Boot özelliğinin ön tanımlı açık gelmesini istemesi oldu.

Secure Boot’u basitçe anlatmak gerekirse -ki zaten ancak basitçe anlatabilirim – bu özelliğin açık olduğu bilgisayarların UEFI firmwarei -şu an kullandığımız BİOS’larla aynı işlevi gören yazılım- bir diskin üstünde yer alan çalıştırılabilir dosyaların – örneğin Windows’un boot etmesini sağlayan dosyanın – o bilgisayara önceden yüklenmiş güvenli anahtarla imzalanmış olmasını istiyor. Eğer dosya imzalı değilse ya da güvenilen bir anahtarla imzalanmamışsa UEFI diskin üstünde yer alan çalıştırılabilir dosyanın -örneğin standart Grub- çalışmasını engelliyor. Tipik bir anahtar kilit ilişkisi kuracak olursak işletim sisteminin çalışması için UEFI’nın secure boot özelliğini kilit ve çalıştırılabilir dosyanızı anahtar olarak tanımlayabiliriz. İşletim sisteminin çalışması için anahtarın kilidi açması şart.

Peki bu olay neden özgür yazılım camiasını ilgilendirsin ki sorusunun cevabı basit. Eğer Secure Boot özelliği Windows 8 ile yüklenecek bilgisayarlarda ön tanımlı olarak açık gelirse bilgisayarınıza farklı bir işletim sistemi yüklemeniz bu özellik açık olduğu sürece mümkün olmayacak. Bilgisayarınıza örneğin Pardus yüklemeniz için Pardus’un bootloader’ı olan Grub’ı üreticinizin güvenliği bulduğu bir anahtarla imzalamanız gerekecek. Sorun aslında burada başlıyor. UEFI standardının yetkili bir otoritesi olmadığı için anahtarlar için bir standart bulunmuyor. Diğer bir söylemle her üreticinin hangi anahtara güveneceği ve hangi anahtarı sisteme ekleyeceği tamamen o üreticiye kalmış durumda. Microsoft ise Windows 8 için henüz üreticilerin mi anahtar yayınlayacağı yoksa kendi anahtarını mı dağıtacağını açıklamamış durumda. Bu durumda en azından ortalama bir son kullanıcının bilgisayarına Windows 8 dışında bir işletim sistemi kurması şu an son derece zor gibi gözüküyor.

Microsoft’un bu yöntemi seçmesinin temelinde bence iki husus yatıyor. Bunlardan birincisi son yıllarda özellikle artan önyükleyici ile birlikte çalışan zararlı yazılımın önünü almak -tabi bunun için manalı bir güvenlik şeması içeren iyi bir işletim sistemi yapmak da çözüm olabilirdi- ve bir diğeri de yeni bilgisayarlara artık Windwos XP ve Vista gibi ekonomik ömrünü çoktan tamamlanmış yazılımların önünü almak. Tabi belki Linux’ten masaüstü pazarında korkmaya da başlamış olabilir. – Durum böyleyse bu süper haber olurdu-

Mesele bununla da kalmıyor. UEFİ sadece bilgisayarınız ilk çalıştığında değil ayrıca işletim sisteminiz donanımlarla iletişim kurduğunda da devreye giriyor. Diğer bir söylemle eğer secure boot özelliği açıksa donanım üreticinizin ve işletim sisteminizin desteklemediği bir donanımı da bilgisayarınızda kullanmanız mümkün olmayacak.

Peki daha önce benzer krizleri trusted computing ve DRM gibi konularda da yaşayan Linux ve özgür yazılım camiası bu durumu nasıl aşacak sorusunun cevabı ne?

Durumu teknik açıdan ele almam pek kolay olmasa da okuduklarımdan şunu söyleyebilirim. Donanım tarafında henüz Linux çekirdeğinde secure boot için destek yok. Bununla birlikte zaten piyasada da henüz bu özelliği destekleyen bir donanım yok. Söylenenlere bakacak olursak bir haftada bu desteğin çekirdeğe girmesi mümkün. (nefes alıp rahatlayabilirsiniz)

Mamafih asıl sorun ne yazık teknik değil. Asıl sorun hukuki – ah bu avukatlar – ne yazık. Secure boot için malum imzalı bir önyükleyiciye ihtiyaç duyuyoruz. Dağıtımlar tarafından gittikçe daha fazla kullanılmaya başlanan grub2 GPLv3 lisanslı ve lisans açık bir şekilde lisansın geçerli olmasını o ikili dosyayı oluşturan tüm kaynak kodun -derleme betikleri, koda başlık vs. Ekleyen araçların vb.- lisanslanmasini şart koşuyor. Bu durumda bizim olayımızda secure boot için anahtar dahil imzalama işini yapan tüm parçaların da gpl olması gerekiyor ki bu durum teorik olarak mümkün değil. -meraklılara asimetrik anahtar arama konusu olsun- Pardus’un da kullandığı Grub gpl2 ve lisansın bu sürümünde böyle açık bir ifade yok. Bununla birlikte imzalama işi kaynağın derlenmiş halini alan kişinin kaynağı tekrar derlediğinde aynı ikili dosyaya sahip olmasını engellediğinden -çünkü bu kişide anahtar yok- gplv2′nin de bu duruma izin vermesi bence mümkün değil.

Microsoft her ne kadar konuya net bir açıklık getirmese bile Windows 8 ve secure boot politikası ile ilgili şunları şimdilik kesin gözüküyor.

Tüm bunlara baktığımız zaman Microsfotun ve üreticilerin bu kararlarını değiştirmezlerse kullanıcının ne kullanacağına ve ne kullanamayacağına hükmetmesi mümkün gibi gözüküyor. Özellikle secure uefi’nin donanım tarafına da uzanması üreticilerin hangi bilgisayarin hangisinin upgrade -yeni ram takma, ekran kartı değiştirme vs.- edilip edilemeyeceğine karar vermesini sağlayacağı için iştah kabartıcı gözüküyor.

Tabi son paragrafı okuyan herkes, bunun tekel anlamına geleceğini ve başta AB’nin buna izin vermeyeceğini düşünmüştür. Bu doğru fakat AB’de bile tekel davalarının ne kadar uzun sürdüğünü düşünecek olursak sırtımızı davalara yaslanmamak gerektiğini anlayabiliriz.

Gelişmeler şimdilik böyle. Ben sizleri bilgilendirmeye çalışırken ana akım camia hem kampanya hazırlıklarına başlamış hem de uefi standardında açık bile aramaya başlamış durumda…

Ayrıntıları yazmaya devam edeceğim.