GPL, Android ve “Bionic” sorunlar

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.

Reklamlar

UEFİ, Windows 8 ve Linux – bu sefer işler karışacak

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.

  • Windows 8 uyumlu sertifikası için secure boot özelliğinin açık olması gerekiyor.
  • sertifika almak için uefi’nin kapatılabilir olmasına gerek yok. Burada üreticinin insiyatifine kalmış durumdasınız ve bazı üreticiler şimdiden bu özelliğin kapatilamayacagi müjdesini verdi.
  • sertifika almak için microsfotun anahtarına güvenmeniz yeterli. Yani imzalı bir bootloaderimiz olsa bile buna güvenmek yine üreticinin insiyatifinde olacak.
  • 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.

    Masaüstü nereye?

    Bir süredir hem bulut bilişim hem de mobil sistemler üstünde ilgimi çeken makaleleri takip etmeye çalışıyorum. Son bir kaç senenin havalı sözcüğü bulut – cloud özellikle akıllı cep telefonlarının ve tabletlerin verdiği rüzgarla birlikte bir süre daha bizi oyalamaya devam edecek gibi gözüküyor.

    Geçtiğimiz hafta geliştirici sürümü yayınlanan Windows 8 ve ondan önce yayınlanan OsX Lion bildiğimiz anlamda olan masaüstü kavramını değiştirecek gibi gözüküyor. Özellikle Windows 8 arayüzü bugüne kadar Ms’den görmeye alışık olmadığımız kadar radikal bir değişiklik getirirken benim aklıma şu soruyu getirdi:

    “Bildiğimiz anlamda olan masaüstü ölüyor mu?

    Masaüstü kavramı aslında kişisel bilgisayarın algısını ve kullanımını değiştiren ve şu an için kullanıcıya istediğini yapma özgürlüğünü veren bir kavram. Bilgisayarınızın sadece üreticisi tarafından belirlenen şekilde değil sizin istediğiniz şekilde kullanılmasını sağlamak için vazgeçilmez bir kavram bütünü sunuyor masaüstü.

    Son zamanlarda ise insanlar hem tabletlerde hem akıllı telefonlarda masaüstü kavramı yerine uygulama kavramını benimseyerek ve onlara üretici  / geliştirici tarafından sunulan yeteneklerle yetinmeye başladılar gibi gözüküyor. Biraz ayrıntıya indiğiniz zaman durumu daha farklı okumak da mümkün. Ben uygulamaların temeli olan mobil işletim sistemlerinin -Android ve ios vd.- birer masaüstü görevi görmeye başladığını düşünüyorum. Ergonomi ve görünüm farklı olsa bile -özellikle ios için- bu platformlar işlevsel anlamda birer masaüstü ortamı sunacak kadar esnek olmaya başladılar. Bir kaç yıl önce smartphone olarak adlandırığımız cihazlar bu gün yukarıda adı geçen mobil işletim sistemleri sayesinde hızla feature phone olarak adlandırılmaya başladılar. Hatta belki nokia’nın oyunu kaybetmesinin temel nedenlerinden biri de bu esnekliğe zamanında adapte olamaması oldu.

    Tabi bu işletim sistemlerinin birer masaüstü haline gelecek kadar esnek olmasının nedeni üreticilerin çok yetenekli ve evladiyelik telefon yapma isteğinden çok internet’in hayatamızda yerinin artması oldu. Bir araştırma bulamadım ama benim gözlem ve öngörüm masaüstünde artık en çok kullandığımız şeyin tarayıcı olduğu yönünde. Yani işlerimizi bilgisayarımızın kendisinde değil ama bir masaüstü uygulaması olan tarayıcı üstünde yapıyoruz. Bu yüzden ben tarayıcıyı tek bir uygulama değil ama sunulan / alınan her bir hizmet için farklı bir masaüstü uygulaması olarak görüyorum.

    İşte tam bu noktada aslında bilgisayarınızda yer alan masaüstü ile telefon ve tabletlerinizde yer alan masaüstü birden örtüşüyorlar. Çünkü iki masaüstünde de uygulamalarınızın tek amacı sizi internet üstünden aldığınız hizmete ulaştırmak. Nielsen’in 2011 2. çeyrek uygulama indirme sayılarına bakacak olursanız insanlar cep telefonlarına oyunlardan sonra -ki bunların pek çoğu da aslında sizi online oyun sunucusuna bağlamak istiyor – en çok internet hizmetlerine ulaşım sağlayan uygulamaları yüklüyorlar.

    Bu yazı kapsamında ben bu uygulamaları sadece çok iyi özelleştirilmiş birer tarayıcı olarak yorumluyorum ve bu sebeple post-pc cihazlarla pc üstünde yer alan masaüstü kavrmaının birbirinden çok farklı olmadığını düşünüyorum.

    Masaüstü ölmüyorsa kim ölüyor?

    Peki eğer klasik anlamda PC üstünde yer alan masaüstü ile post-pc cihazların üstünde yer alan masaüstü fikir olarak aynıysa neden PC’nin klasikleşmiş hatta tabulaşmış kuralları ile oynamaya başladığımızı merak ediyor olabilirsiniz. Bence bunun cevabı son derece basit. İnsanlar artık her an yanlarında PC taşıyamayacak hale gelmeye başlamış durumdalar. Ofislerinde bir PC, evlerinde bir PC ve evleri ile ofisleri arasında post-pc cihazlar kullanırken her bir PC’nin kendi hafızasında kalan bilgilere ulaşamamak insanları her an yanlarında taşıyacakları post-pc cihazlara yöneltiyor.

    Bana kalırsa insanların sorunu masaüstünden çok mobil olamamaktan kaynaklanıyor ve dikkat ederseniz hem Ms hem Apple son güncel sürümlerinde bilginin görünmeden göze batmadan PCler ile post-pcler arasında taşınması ve internet hizmetlerinden kopmamayı öne çıkarmış durumda. Apple bunu icloud ile çözerken Ms daha farklı bir çözümle benzer arayüzler ve aynı SDK’yı kullanan yazılımlarla çözmeye çalışıyor. Her iki firma da klasik anlamda masaüstü görünümünden ve işlevlerinden ne vazgeçmiş ne de vazgeçebilecek durumda.

    Eh bu kadar özet bilgiden sonra o halde başlıkta sorduğumuz soruyu tekrar sormanın vakti geldi. Masaüstü nereye gidiyor?

    PC için masaüstü kavramı bana kalırsa olduğu yerde sağlam bir şekilde durmaya devam ediyor ve yaşıyor. Bununla birlikte biraz kabuk değiştirerek artık çalışma ortamı olarak kendi üstünde çalıştığın bilgisayarın hafızası ve belleği yerine sizi mobil hizmetleri aldığınız dünyada çalışmaya devam ediyor. Bu arada post-pc olarak adlandırdığımız cihazlarda ise masaüstü, ergonomi nedeniyle farklı bir izdüşüm halinde olmaya devam ediyor.

    Peki kim kaybediyor sorusunun yanıtı basit. Sadece olduğu bilgisayarda çalışmaya programlanmış masaüstü işletim sistemi kaybedecekler listesine giriyor ne yazık. İşletm sisteminin artık sadece üstünde çalıştığı bilgisayarda değil kullanıcısının olduğu her yerde olma zorunluluğu büyük bir hızla geliyor. Çalışılan belgelerin, dinlenen şarkıların, bakılan resimlerin sadece çalışan PC’nin hafızasından çok aynı anda başka bir PC’nin ya da hemen yanında duran tabletin de hafızasında olması gerekiyor.

    Bu sebeple yapılması gereken artık işletim sistemini tek bir bilgisayarda çalışacak şekilde düşünmekten çok post-pc ve diğer PC’ler ile çalışmaya hazır bir şekilde uyarlamak özellikle mobil olan kullanıcıya her noktada hizmet vermeyi sağlayacak bir temel haline getirmek kalıyor. Bunu yapamayan işletim sistemlerinin bireysel pazarda yavaş yavaş pazar paylarını kaybedeceğine inanıyorum.

    Patentler, Android ve HTC

    Geçtiğimiz haftanın önemli gelişmelerinden biri -en azından benim için- Asya’nın en büyük ikinci telefon üreticisi HTC’nin Apple’ın açtığı patent ihlali davasında ilk raundu kaybetmesi oldu. Her ne kadar bu sıradan bir şirket haberi sayılsa da aslında hem biz Android kullanıcıları hem de yazılım patentlerine karşı olan insanlar için önem taşıyan bir gelişme. Yazılım patentinden konuyu açmışken ilk etapta belki yazılım patenti nedir meselesinde biraz bakmak gerekiyor.

    Meseleyi biliyorum diyenler biraz daha aşağıdan devam edebilir. Yok böyle iyi diyenlere iki dakikada tarih dersi geliyor. Efenim bildiğiniz gibi insanoğlu/kızı özellikle sanayi devrimiyle birlikte alet işler el övünür sözünün kavramını biraz daha net olarak kavramış olacak ki icatlarını korumak, hayatlarını vakfettikleri çalışmalarının kendileri adına tescil edilmesini arzulamışlar. Zamanla bu arzuların etkisiyle güdülenen insanlar bunun için hem uluslararası hem ulusal düzeyde fikri mülkiyeti koruyacak kurumlar geliştirmişler. Bu kurumlar temelde iki dala ayrılıyor. İlki fikri mülkiyet başlığı altında toplanırken bugün HTC’nin başını ağırtan diğer kurumsa patentler olmuş. Patent mevcut tekniği ileri götüren yeni bir icat yeni bir buluş meydana getirildiğinde bu buluştan belirli bir yıl süresince sadece buluş sahibinin ve onun yetki verdiği insanların yararlanmasını sağlayan bir koruma yolu. Patentlerin Amerika ve Avrupa’da birbirlerinden en çok ayrılmasını sağlayan şey ise Amerika’nın yazılım konusunda patentlerin olabileceğini kabul ederken Avrupa’nın bunu kabul etmemesi.

    Yazılımın doğası gereği patentle korunması son derece manasız. Zira örneğin bir ilaç formulünün patentini aldığınızda bir hastalığı belirli bir metodla tedavi eden belirli bir formül elde ediyorsunuz ve bu formül korunuyor. Bununla birlikte ne yazık ki yazılımda yazdığınız kodun değil ama yazılan koddan daha önemli bir şeyi bu kodu yazma nedeninizi yani çalışma metodunuzu patentliyorsunuz. Bu durumda hangi kodu yazarsanız yazın ya da hangi dilde olursa olsun bir işi çözme metodu olarak bir yazılım patentine konu olan yöntemi uygularsanız o patenti ihlal etmiş olursunuz. Şimdi bu konuyu bir örnekle somutlaştıralım. Örneğin bir firma internet üstünden satış yaparken tek tuşla satın alma diye bir metod geliştiriyor. Bu sayede kredi kartınızı ve adresi önceden kaydedip istediğiniz ürünü tek tuşa basarak kapınıza kadar getiriyorsunuz. Bu metodu Amerika Patent Ofisi’nde bir yazılım olarak patentliyor. Bunun akabinde her ne kadar farklı bir kod yazılmış olsa bile Amerika’da başka bir kişinin aynı metodu kullanarak satış yapması patent sahibinin iznine bağlanıyor. Bu yüzden bu metodu kullanan bir firma açılan dava sonucunda sırf patenti ihlal etmemek için bir adım daha eklemek zorunda kalmıştı zamanında. Bu kısa tarih dersinden sonra şimdi gelelim konumuza.

    Efenim bildiğiniz gibi HTC Android ile birlikte Samsung’un ardından Asya’nın ikinci en büyük telefon üreticisi konumunda. Bununla birklikte HTC’nin bir diğer özelliğiyse aynı zamanda Google tarafından piyasaya sürülen Nexus One’ın üreticisi olması. Apple geçtiğimiz aylarda Nexus One üstünden HTC’nin Apple’a ait iki patenti ihlal ettiğine dair Amerika’da bulunan ITC (Uluslarasası Ticaret Komisyonu) nezninde bir soruşturma başlatılmasını istedi. ITC son zamanlarda özellikle patente ilişkin konularda olan uyuşmazlıklara bakan bir kurum haline gelmiş durumda. Her ne kadar bir mahkeme olmasa da ITC’nin elinde özellikle büyük üreticileri son derece korkutan bir güç var. ITC Amerika’ya ithal edilen her bir ürünün ülkeye ithalat iznini veren kurum olduğu için eğer bir fikri mülkiyet ihlali olduğu kararına varırsa o ürünün ülkeye sokulmasını engelleme / ürünlerin ülkeye sokulduğu durumda satıştan menine karar verebiliyor.

    Yapılan soruşturma kapsamında ilk etapta kurumun ilgili yetkilisi HTC’nin iki patenti ihlal ettiğine karar verdi. Bu kapsamda Apple’ın hem donanımın seri gelen verileri paralel işlemesi hem de verilerin belirli bir sistematik ile parelel işlenmesine dair olan iki patentine ait fikri mülkiyetin HTC tarafından izinsiz kullanıldığına dair bir öngörü oluşmuş durumda. Kurum ise kesin kararını altı kişilik komisyonun toplanacağı Aralık ayında verecek.

    Yazılım uzmanları özellikle video / ses işleme ve Android’e eklenen hesaplar arasında etkileşime izin veren metodun patentleri ihlal ettiğini ve bunların Android’in neredeyse kalbinde olduğu için çevresinde dolanılmasının zor olacağını söylüyorlar. HTC her ne kadar yaptığı açıklamada Aralık ayına kadar bir çözüm bulunacağını söylüyor olsa bile durum hala çok karmaşık gözüküyor.

    İlgililerin bileceği gibi daha önce Microsoft’da bir patentinin ihlal edildiği gerekçesi ile HTC ile anlaşmak istemiş ve bu kapsamda HTC sattığı her bir Android cihaz için lisans bedeli olarak MS’e 5$ ödemeyi kabul etmişti. Sırf bu sayede MS’in HTC’den yıllık 150 milyon $ gibi bir lisans parası alacağı kulislerde konuşulurken Apple’ın daha farklı bir plan içerisinde olduğu konuşuluyor. Son dedikodular Apple’ın bu patentlerin lisansını ya çok yüksek bedellerle HTC’ye vereceği ya da hiç vermeyeceği yönünde. Bu durumda eğer HTC yıl sonuna kadar bu patentlerde belirlenen metodların etrafından dolaşmanın bir yolunu bulamazsa Amerika piyasasınından tamamen çıkmak zorunda kalabilir. Daha korkutucu olan nokta ise Apple’ın bu davayı herhangi bir Android üreticisine yönlendirmesinin önünde herhangi bir engel kalmayacak olması. Her ne kadar bu durum doğrudan bizi ilgilendirmeyecek olsa bile -zira bu patentler ülkemizde ve Avrupa’da tanınmıyor.- Amerika gibi büyük bir piyasada bu denli bir darbe almak hem HTC ve üreticiler hem de Android açısından son derece yaralayıcı olacaktır.

    Gelişmeleri takip edip aktarmaya çalışacağım. Bu arada merak edenler ilgili patentlerde neyin ihlal edildiğine dair bir tabloya bu adresten erişebilirler.

    Özgür Yazılım Lisansları Sunumu

    Geçtiğimiz haftalarda 1-2 Nisan tarihinde Bilgi Üniversitesi’nde LKD ve Bilgi işbirliğiyle yapılacak olan şenlikten bahsetmiştim. Şenlikte hasbel kader bana özgür yazılım lisansları ile ilgili bir sunum yapma şansı tanındı. Sevgili dostum Koray Löker’in tavsiyesiyle sunumu soru cevap şeklinde hazırlamaya çalıştım.

    Sunumun PDF halini buradan temin edebilirsiniz…

    Not: sunumun pek çok yerinde cevapları GPL tabanlı olarak vermeye çalıştım. Elbette sunumda bahsedilen konuların hukuki tavsiye niteliğinde değil kişisel görüş olduğunu söylememe gerek yok 🙂