Yaklaşık 30 sene önce başlayan özgür yazılım hareketi, günümüzde açık kaynak hareketi ile birlikte bilgi işlem sektörünün hemen her alanında olmazsa olmaz kabul edilmekte ve en kritik iş uygulamalarından tutun en sıradan günlük ofis uygulamalarına dek somut alternatifler sunmaya devam etmektedir.

Google, IBM, Yahoo, Amazon gibi devasa iş operasyonlarını başta GNU/Linux işletim sistemi olmak üzere özgür ve açık kodlu yazılımlara emanet eden şirketlerin yanısıra, araştırma geliştirme çalışmalarını özgür ve açık platformda sürdüren dünya çapında üniversiteler de göstermektedir ki özgür ve açık kodlu yazılımlar ticaretin ve inovasyonun ötesinde geleceğe yönelik öncü teknolojilerin de sağlam zemini teşkil etmektedir.

Özgür ve açık kodlu yazılım dünyası, ortaya koyduğu kısa vadeli teknolojik ve maddi avantajlara ek olarak çok önemli bir amaca daha hizmet etmektedir: teknolojiyi, bilimi inceleyip, araştırıp anlamak ve çok daha iyisini geliştirmek isteyen zihinler için değeri para ile ölçülemeyecek bir fırsatlar ve kaynaklar havuzunu beslemek ve yeni nesilleri üretkenliğe, paylaşımcılığa teşvik etmek.

Günümüzde çoğu kişi tarafından sorulan temel soru “özgür yazılımlara geçmeli miyiz?” sorusu değildir. Artık “hangi özgür ve açık kodlu yazılım kombinasyonlarını ne tür işlerde kullanabiliriz?”, “geliştirdiğimiz özgür yazılım için ne tür bir iş modelini hedeflemeliyiz?”, “hedeflediğimiz özgür yazılımlar için en iyi eğitimleri nasıl alabilir yahut verebiliriz?” gibi pratik sorular gündemdedir. Bilgi işlem dünyasının amacı artık düşük maliyetli, güvenilir, açık standartlarla uyumlu ve ticari dalgalanmalar ile krizlere dayanıklı sistemleri tasarlamak, bunları olabildiğince yaygınlaştırmaktır.

İstanbul Bilgi Üniversitesi ve Linux Kullanıcıları Derneği‘nin bu amaca katkıda bulunmak için gerçekleştirmekte oldukları etkinlikler 11. yılını kutluyor.

Kaynak: http://ozguryazilimgunleri.org/2012/hakkinda/

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.

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.

Daha dün OpenSSL'in 1.0.0 sürümü çıkmışken bugün de lisansıyla ilgili bir şeyler yazayım. Tam iki yıl önce eduroam'a dahil olabilmek için freeradius kurmaya çalışırken OpenSSL lisansının GPL ile problemlerinden dolayı bayağı uğraşmış ve sonunda kendi deb paketlerimi yapıp öyle kullanmaya başlamıştım. Aradan geçen bunca zamandan sonra ara ara paketleri güncelliyordum ama 2 Ocak tarihli güncellemeyi kaçırmışım. Tabi GPL'de veya debian politikasında bir değişiklik olmamış, OpenSSL lisansına aşağıdaki istisna eklenmiş ve artık freeraidus paketleri (olması gerektiği gibi) OpenSSL destekli dağıtılıyor.

This LICENSE file is a modification to the main LICENSE file, which is
GPLv2. It applies only to the files in the "src" directory.

In addition, as a special exception, the copyright holders give
permission to link the code of this program with the OpenSSL library,
and distribute linked combinations including the two.
You must obey the GNU General Public License in all respects
for all of the code used other than OpenSSL. If you modify
file(s) with this exception, you may extend this exception to your
version of the file(s), but you are not obligated to do so. If you
do not wish to do so, delete this exception statement from your
version. If you delete this exception statement from all source
files in the program, then also delete it here.

Henüz stable depoya girmemiş olsa da testing deposundan paketleri alıp kullanmak mümkün. Akıllı davranıp bu düzenlemeyi yapanlara teşekkürler. Bu mevzu da benim için kapanmış oldu böylece.

Hep Pardus ile ilgili görüşleri ele alan ciddi (Yok daha neler) yazıları ele almıştım. Bu da biraz eğlence olsun. Kendime bu plakanın 34lüsünü almayı düşünüyorum şahsen bi 18e girelim…

Düşündüm de,  güzel olur. 34 KDE 44 . Plakayı da GPL ile lisansladık mı…

Not: bir süredir kız arkadaşımın beni KDE’den kıskanmaya başladığını seziyorum…

Filed under: Özgürlükİçin Gezegenine, Pardus Topluluk Seçkisi Tagged: Özgürlükİçin Gezegenine, Eğlence..., GPL, KDE, Komedi, Plaka

Not: Bu benim Linux ile tanışma hikâyemi anlatan, bilgisayarı gerçek hayata benzeten bir yazıdır. Buradakiler yalnızca benzetmedir. Hayatımda bu kadar kişi ile beraber olsa idim….. Yaklaşık 5 yıl kadar önce idi. Microsotf ailesinin bana göre en saygın üyesi olan Windows 2000 ile bir dostluğum vardı. Ama farkında olmadığım hâlde arkamdan ne işler çeviriyordu… Hem benden izinsiz evime (bilgisayarıma) her kesi sokuyor, hem de en özel sırlarımı anlatıyordu. Bir gün beni ekmesi sonucu artık ona olan tüm güvenim ortadan kalkmıştı. Artık o benim dostum değildi. Zaten hiç dost olmadığımızı anladım. Beni hem kandırmış ve kullanmış biri nasıl dostum olabilirdi? Aslında onun tek düşündüğü Bill Amcasının banka hesap(lar)ı idi. Bir süre yalnızlık içinde dolaşmaya karar verdi. Hiç bir dostum yoktu. Yalnız başıma o bardan o bara (İnternet Kafe) dolaşıp durdum.

Tam bu boşluk esnasında iken Mac OS X adında genç, alımlı bir bayan ile tanışmıştım. Görünüşü ile beni büyülemişti. Onunla tanışayım dedim. Bir süre beraber takıldıktan sonra bir birliktelik ortaya çıktı. Ama maalesef birbirimize uymadığımız için kısa sürede ayrıldık. Bu boşluk içerisinde dolaşırken birden kendimi bir köprüde buldum. Hayatıma (Bilişim hayatıma) elveda diyecektim. Ama bir şey bana engel oldu. Arkamı döndüm. Bu şeyin ne olduğuna baktım. Sevimli bir penguendi. Elimden tuttu ve beni çekiştirerek bir yere doğru götürmeye başladı. Bana bu yerde özgürlüğü bulabileceğimi söyledi. Bu şehrin adı GNU/Linux idi. Bir süre sonra Debra ve Ian adlı bir çift (Debian) ile tanıştım. yalnızdım. Ama beni aralarına kabul ettiler. Hoş bir aile yaşamı idi onlarınki. Ancak sorun şurada idi ki; ben fazla yetersizdim. Çok fazla kültürlü bir çift idi. Onlarla yaşamanın zorluğu işte burada idi. Pek çok konuda deneyimsiz ve bilgisiz kalıyordum. Ama yılmadım, usanmadım, çalıştım, çabaladım. Onlara ayak uydurmak için elimden geleni yaptım. Bir süre sonra daha da rahat etmeye başladım. Ama bir süre sonra bu aile ile arama giren bir kız çıkageldi. Adı Fedora idi. Oldukça sade ve alımlı biri… Ama bu da tıpkı Mac OS X ile olan ilişkim gibi yürümedi. İstekleri bir türlü bitmiyordu. O dönemde bir süre dostum olan biri ile tanıştım. Open Suse. Hayatıma “Özgürlük Vaadi ile girdi. Aslında bu özgürlüğü sundu da. Ama sorun şurada idi ki, onu anlamakta güçlük çekiyordum. Fazla ilginçti. Gerçi bunu benden duymak biraz saçma gelebilir ama evet, Open Suse bana çok ilginç geliyordu. Ama gerçekten de onunla olduğum süre zarfında ayrı bir özgürlük tattım. İyi bir dosttu. Ancak onunla ayrı yerlere gitmemiz gerekti. O olduğu yerde kalacaktı. Ama ben… ben daha da derin bir özgürlük hissi arıyordum. Aradığımı bulmak için başka ufuklara yelken açmayı denedim. Bu süre zarfında pek çok kişi ile tanıştım. Ama hepsi gelip geçici tiplerdendi. Uzun bir boşluğun arından bir hemşerimi buldum. O da benim gibi bir Türk idi. Adı Pardus’tu. Oldukça esprili (Uygulamaların adı bile esprili), ve özgür biri idi. Ama bir sorun vardı. Hiç olgun değildi. 2007 yılının ortalarında, olgunlaştıktan sonra geri dönme sözü ile gitti. Bu süre zarfında Ubuntu, kardeşi Kubuntu, Mandriva ve bir kaç isimle daha tanıştım. Hatta ve hatta Open Suse ve Fedora hayatıma yeniden girmeye çalıştılar. Bir de PcLinuxOs adlı biri ile de tanıştım. Ama hiç biri bana tam olarak aradığım bir özgürlük sunmadı nedense. Bu yüzden Debra ve Ian çiftinin yanına geri döndüm. Kısa bir süre sonra, 2008′in ortalarına yakın, Pardus geri döndü. Bana bas bas bağırarak “Artık daha olgunum!” diyordu. Biraz sohbetin ardından anladım ki gerçekten de daha olgundu. Onunla bir süre, Debra ve Ian’ın evinde kaldık. Ama bu da yetmedi. Bir zaman sonra kendimize Sony marka bir araba (Dizüstü) aldık. Artık yollarda dolaşmaya başladık. Ama 2009′un ortasında bir şey fark ettik. Pardus’un yakışıklılığı artmıştı ve bu yüzden pek çok kız arabamıza otostop çekiyordu (Bilgisayarımı merakla kurcalayanlar). Ama artık Neşeli ve eğlenceli bir hayatımız vardı. Daha da önemlisi: TAMAMEN ÖZGÜRDÜK!!! Pardus 2009 Masaüstüm

Posted in Özgürlükİçin Gezegenine Tagged: Özgür Dünyanın Yolu, Özgür Yazılım, Özgürlükİçin, Özgürlükİçin Gezegen, Bill Amca'nın banka hesap(lar)ı, Debian, Eleştiri, Fedora, Fintows, GPL, Kısa Hikaye, Linux, Mac OS X, Open Suse, İşletim Sistemi

Not: Bu yazıya başlamayı aslında 8 ay önce planlamıştım! Ancak yazının şansı şimdiye çıktı. Peki neden erteledim? İlk yazmaya başladığımda asi bir dönemimde idim. O yüzden fazla sivri dilli olmuştu. Gerçi şimdi de biraz sivri olabilir… Şimdi bir düşünün, özgürlük nedir? Bu özgürlüğü illa bilgisayarınızda düşünmeyin, günlük hayattaki özgürlük de ele alınabilinir. İstediğin gibi giyinme, istediğin gibi yaşama, istediğini yeme, istediğini içme… Bunları diğer insanları rahatsız etmeyecek şekilde yapmamış özgürlüktür. Şimdi gel gelelim asıl konu olan bilgisayarda özgürlüğe! Ve dolayısı ile asıl sorumuzu sormam gerek? Bilgisayarınızda ne kadar özgürsünüz? %100 diye bir cevap maalesef şimdilik mümkün değil. Ama yavaş yavaş o orana geliyor. Şimdi koyu bir özgür yazılımcı gibi değil de biraz iki taraflı bakacağım işe.

Özgür yazılımın da her şeyde olduğu gibi artıları ve eksileri mevcut. Peki nedir bu artı ve eksiler? Özgür yazılımda hangisi daha ağır basıyor? Özgür yazılım taban olarak kullanıcı refahını düşünen bir felsefedir. Bunun en güçlü temsilcisinin GNU/LINUX olduğunu söyleyebiliriz. Ancak tek temsilci de değildir. Özgür yazılımın Kapalı Kaynaklı olan benzerleri ile arasındaki en büyük farklar nedir.

• Öncelikli olarak Özgür yazılımın geliştiricileri maaşa bağlanmış bir avuç insanla sınırlı değildir. Dünya üzerinde bir çok insan her hangi bir Özgür yazılımın gelişimine katkı sağlayabilir. Bu yüzden Özgür yazılım hem daha geniş bir hitap kitlesine sahip, hem de daha geniş bir geliştirici kitlesine. Peki, madem bir insan rahatlıkla katkı sağlayabiliyor, başka bir insan da kasıtlı olarak zararlı bir kod sokamaz mı? Teknik olarak mümkün. Ancak düşünürsek destekçi sayısı ile kontrol eden kişi sayısı doğru orantılı. yani 5.000 insan yazıyor ise, bir 5.000 insan da kontrol ediyor demektir. Bu yüzden kasıtlı olarak zararlı bir kod sokmak çok zor bir iştir.
• İçerikteki kısıtlama oranı da farklı. Kapalı kaynak camiasında işler daha çok banka hesaplarına baktığı için kullanıcıya fazla bir hak tanınmaz. Hatta isterseniz Windows lisansına bir göz gezdirin. (şimdiki cümle yalnızca bu lisansı kabul etmiş olanlar için) Nasıl bir antlaşmayı kabul ettiğinizi göreceksiniz. Bu lisansa göre işletim sistemi size ait değil, siz sadece bu işletim sistemi üzerinde işlerinizi yapmak için yetki almışsınız. sistem üzerinde hak sahibi olan tek kişi Bill Amca. Ancak Özgür yazılım camiasında en yaygın lisanslardan biri olan GPL (Genel Kamu Lisansı) için durum farklı. Eğer bu lisansı okuduysanız aslında bu lisansı kullanan yazılımlar üzerinde tam bir söz hakkında sahip olduğunuzu görürsünüz.
• Bir yanını beğenmediniz mi? Açın bir metin editörü, beğenmediğiniz kodları değiştirin… Peki ben neden böyle bir şeyi kapalı kaynak kodlu arkadaşlarda göremedim?
• Evet, gel gelelim şimdi Muhafazakâr (Kapalı kaynak kod üzerine bir espri yapmaya çalıştım. Umarım fazla kaçmamıştır ) arkadaşların avantajlı olduğu konulara. Öncelikli olarak Bill Amca‘nın banka hesap(lar)ı. Evet, acımasız bir gerçek. Şu an pek çok yazılım firmasının Kapalı kaynağa destek vermesinin başlıca sebebi bu. Ancak bu durum da yavaş yavaş değişmeye başladı. Örnek olarak Nvidia’nın Linux için yaptığı atılımları ele alabiliriz. Veyahut Google ağabeyimiz. Gerçi o en başından beri Özgür yazılıma destek verdi ama…
• Diğer bir Kapalı kaynak avantajı ise reklam. Aslında bunu da Bill Amca‘nın banka hesap(lar)ına bağlayabiliriz. Sonuç olarak bunların reklamını yapan para nereden suyunu alıyor? Bu arada yandaki resmi nasıl buldunuz? Ben ilk gördüğümde bayıldım…
• Son bir Muhafazakâr avantajı olarak olarak Oyun Sektörünü ele alabiliriz. peki bunun sebebi ne? Bill Amca‘nın banka hesap(lar)…

Evet, heme göze çarpıyordur. Kapalı kaynak kodun avantajlarını, ve doğal olarak Özgür yazılımın dezavantajlarını oluşturun genel etken Bill Amca‘nın banka hesap(lar)ı! Hatta resimde bile görebileceğiniz üzere adamın cepleri bayağı şişkin… Ancak yavaş yavaş Bill Amca‘nın banka hesap(lar)ı söz geçirme oranını kaybediyor. Ve bu durum gelecekte de yükselecek. Son bir soru: Kim kimin efendisi? Siz mi bilgisayarın, Bill Amca‘nın banka hesap(lar)ı mı sizin? Not: Bu “Bill Amca‘nın banka hesap(lar)ı “esprisinin suyu çıktı gibi gelmeye başladı…

Posted in Özgürlükİçin Gezegenine Tagged: Özgür Yazılım, Özgürlükİçin, Özgürlükİçin Gezegen, Bill Amca'nın banka hesap(lar)ı, Eleştiri, Fintows, Gözlem, GPL, Komedi, Parakoliklik

Turkcell’den beklemediğim ve beni şaşırtan bir haber geldi. Turkcell Teknoloji ilk açık kaynaklı, GPL lisanslı ürünü Isola Framework’u duyurdu. Isola, Java ile web uygulaması geliştirenler için yine bir javascript frameworku olan Extjs’i temel alarak geliştirilmiş bir javascript frameworku. Sanırım ajax4jsf’e benzer bir işi yapıyor.

Böyle büyük ölçekteki bir şirektin özgür yazılıma destek vermesi, ülkemizde özgür yazılımın gelişmesi adına güzel bir gelişme. Turkcell Teknoloji için bu bir ilk ama son olmayacaktır diye düşünüyor ve umuyorum.

Bu güzel hareketinden dolayı Turkcell’i ben de (*) tebrik ediyorum.

Turkcell Teknoloji’nin nasıl bir yer olduğunu merak edenleriniz varsa Televidyon’un videosunu izleyebilirler ve bilgi alabilirler.

Bu arada haberi sevgili Görkem Çetin‘in linux sohbet listesine attığı posta sayesinde öğrendim. Kendisine bu güzel haberi ilettiği için teşekkür ederim.