Özgür yazılım mı yoksa açık kaynak mı tartışmaları bu iki kavramın ortaya çıkışı ve zaman zaman birbiri karşısında iki farklı kamp gibi konumlanmasından bu yana çok uzun süredir tartışılıyor. Kişisel tartışmalar ve hatta hesaplaşmaların da eskisi kadar olmasa da çok fazla etkilediği bu alan, sadece yazılımın felsefesine meraklı bir avuç geek ve çevresinde kümelenmiş bir grup avukatın fildişi kulelerde birbiriyle mücadele etmesi gibi gözükse de, sonuçları hem yazılım geliştiricileri hem de son kullanıcıları ciddi manada ilgilendiriyor.
Kısa bir açık kaynak tarih dersi!
Yazdığım blog yazılarını daha önce takip edenler genelde konuya giriş yapmamın iki yazı sürdüğünü bilirler. Bir kez olsun ilginçlik yapıp, bu yazıyı o kadar uzun tutmamayı ve konuya hemen girmeyi düşünüyorum. O yüzden özgür yazılım ve açık kaynak yazılım kavramlarından yeterince haberdar değil ve bu yazıyı da okumak istiyorsanız, her iki kavramı hem bu sitedeki önceki yazılardan hem de wikizero (onun aslı vikipedi değil miydi ya?) sitesinden biraz inceleyin derim.
Özellikle sonradan adı özgür yazılım olarak yerleşecek yazılım özgürlüğü kavramı, sabah erken kalkanın garajında bilgisayar yapabildiği ama bir yandan da bir yazıcı sürücüsü düzenlemek için binlerce dolar ödemek zorunda olduğunuz 80’li yıllara dayanıyor. Bu yıllarda başarı şansının düşük, batma riskinin yüksek olduğu endüstride, insanların rekabet edebilmesi için yazılımlarını olabildiğince kendine saklaması, diğer donanımlarla uyumluluğunu düşünmemesi hatta yazılımın bir donanımı satabilmek için anahtar olması çok normal sayılıyordu. Sonrasında FSF‘yi oluşturacak bir grup insan; yazılımın herkes için açık, ulaşılabilir, değiştirilebilir ve dağıtılabilir olması gerektiği şiarıyla yola çıkmış ve bunu hayata karşı bir politik duruşa çevirip, oluşturulan değer zincirinin her adımındaki kişinin bu özgürlüklere sahip olması gerektiğini söylemişti. Bu düşüncelerle kaleme alınan Genel Kamu Lisansı ailesi zamanla özgür yazılım kavramının en bilinen lisansı oldu ve bugün uydulardan cep telefonlarına kadar hayatın her yerinde olan Linux çekirdeğinin de lisansı haline geldi.
Öte yandan 90’lı yılların sonuna doğru yavaş yavaş değişen endüstriyle birlikte oyuncuların daha az ama daha büyük hale gelmesi yazının başında yer alan tartışmaların alevlenmesini sağladı ve bu alanın diğer kampı olan Açık Kaynak kavramının doğmasını sağladı. Açık Kaynak kampı için yazılım özgürlüğü politik bir meseleden ziyade pratik bir meseleydi ve yazılımın kalitesini, oluşturma süreçlerini ve kendisini etkiliyordu. Bu da doğal olarak iş modeli ile ilgiliydi ve açık kaynak bir iş modeli haline gelecekse bunun için endüstri ile uyumlu olması gerekiyordu. Daha sonra OSI ismini alacak topluluk Debian’ın Özgür Yazılım Kuralları‘nı adapte ederek oluşturdukları manifestoyu duyurdular ve böylece Özgür Yazılım ile Açık Kaynak kavramları hayatımıza girmiş oldu.
Kavramın mihmandarlığını yapan her iki kurum de facto olarak bu kavramların onay mercisi haline geldiler zaman içinde. Her iki kurum da çeşitli başvuru kanalları tarafından kendilerine iletilen lisans metinlerini özgür yazılım ve açık kaynak lisansı adıyla onaylamaya bizler de bu onayı alan lisanslara sahip yazılımlara bu isimleri vermeye başladık. Elbette bu konuyla daha az ilgili geliştiriciler ve kullanıcılar için epey faydalı oldu. Bu onay mekanizması sayesinde kendi projemizde bu lisanslara sahip bir bileşen kullanmak istiyorsak iyi kötü girdiğimiz alanın sınırlarını tahmin etme ve yükümlülük ile haklarımızı belirleme şansına sahip olduk. Öte yandan lisanslar ve kavramlar geliştiriciler ve ilgililer için hayatımızın bir parçası haline geldiği ve bir yandan çoğumuzun meslek hayatından daha uzun süredir de yaşamlarını sürdürdüğü için kavramları çok az sorgulamaya başladık.
Gelen bulut çağı, sanallaştırmanın geldiği nokta (insanlar fiziksel makinenın üstündeki sanal sunucunun içindeki konteynerin üstünde uygulama çalıştırıyor artık malum) ve bunun endüstri üzerindeki etkileri bizleri bu kavramları tekrar sorgulamaya itiyor (mu?).
Bulut çağında açık kaynak
Malum bir süredir MongoDB, Redis gibi bazı yazılım projelerin lisans değişiklikleri gündemde kendisine yer ediyor. Bu değişiklikler temelde bu yazılımların hamisi diyebileceğimiz şirketler açısından bakıldığında manalı gibi görülse de özgür yazılım ve açık kaynağın gittiği yer konusunda beni şahsen endişeye düşürmeye başladı.
IaaS ve PaaS kavramlarının hayatımıza girdiği yıllardan bu yana on-premise iş geliştiren yazılım firmaları, danışmanlık firmaları ve üreticiler bu yeni ortama uyum sağlamaya çalışıyor. Yüksek regülasyon nedeniyle buluta çıkamayan birkaç sektörü saymazsak bugün herhangi bir firma tüm IT ihtiyaçlarını giriş maliyetine katlanmadan herhangi bir bulut sağlayıcı üzerinde birkaç tıklama ve bir kredi kartı marifeti ile yapabilir hale gelmiş durumda. Hal böyle olunca özellikle bir servis olarak sunulabilecek firmalar için ilginç bir paradoks oluşmaya başladı. Bu firmalar kendi geliştirdikleri ürünün büyük bulut sağlayıcılar tarafından sağlanan bir servis olmasını istediler -zira geniş kitlelere kendi geliştirdikleri teknolojileri ancak bu şekilde zahmetsizce sunabileceklerdi- ama bir yandan bu servisi sunan bulut firmalarının da zaman içinde kendilerine rakip olduğunu fark ettiler.
Geliştirdikleri yazılımların kahir ekseriyeti açık kaynak olduğundan büyük bulut sağlayıcılar herhangi bir mali yükümlülüğün altına girmeden ürünü kendi ürünü gibi sunabilir ve ölçek ekonomisinin getirdiği fiyat avantajı ile kolayca müşteri toplayabilir hale geldi. Hatta bu durum öyle bir hale geldi ki, lax permissive lisanslara sahip olan projeler için bu bulut sağlayıcılar kendi geliştirmelerini upstream ile paylaşmadan dağıtır hale geldi. İşte bu durum teknolojiyi asıl geliştiren ve bunun üzerine koyduğu hizmet katmanı ile ticari değer sağlamaya çalışan firmaların bir yol ayrımına gelmesine neden oldu. Bu firmalar ya en büyük rakipleri haline gelmiş olan bulut sağlayıcı firmaların yararına açık kaynak teknolojilerini geliştirmeye devam edeceklerdi ya da yıllardır üstünde durdukları ve hatta ticari olarak bir satış faktörü olarak kullandıkları açık kaynak olmak fikrinden vazgeçeceklerdi. Bazı firmalar ilk yolu seçip kendi geliştirme ve ticari iş fikirlerini koruyarak yollarına devam etseler de bazıları sorunu hukuki açıdan karmaşık yollarla çözmeye karar verdi.
Hukuki açıdan karmaşık yol ise firmaların birbiri adına açık kaynağın yeni nesli olma iddiasında olduğunu söyleyebileceğimiz lisans metinleri yayınlamak oldu. Bunları, Common Clause ya da SSPL gibi isimlerle görme şansına sahip olduk. Temelde bu metinler yazılımın kullanım şartlarında herhangi bir kısıtlama getirmiyor ama eğer siz bir bulut sağlayıcıysanız ya yazılımı bir SaaS olarak vermenizi ya da eğer veriyorsanız çok geniş bir şekilde altında çalıştırdığınız tüm bileşenleri açık kaynak yapmanızı gerektiriyor.
Açık kaynak iddiasını sürdürmek için de bu lisansların sahipleri yazının başında belirttiğim gibi kavramın de facto bekçiliğini yapan OSI’nin kapısını çaldılar. OSI ise çoğumuzu şaşırtmayan bir kararla yıllardır sürdürdüğü çizgisinden farklı bir adım atmayarak bu lisansların insanların yazılımı kullanma şartlarını kısıtladığını ve bu sebeple kendi kuralları ile çeliştiğini, dolayısıyla da OSI tarafından onaylanmış bir açık kaynak lisansı olamayacağını söyledi. Tahmin ettiğiniz gibi tartışma da tam bu noktada alev aldı.
Kim haklı?
Bir yanda özellikle bu lisansları savunanlar OSI ve FSF gibi kuruluşların elinde tuttukları bu yetkiyi artık günümüz koşullarına göre güncellemeleri ve açık kaynak yazılım geliştiren insanları bu tip yeni dönemin sıkıntılarına karşı da korumalarını gerektiğini ve aksi halinin yazılımın açıklığına önem vermeyen ticari oluşumların bu tip projelerin sömürülmesine olanak tanıdığını söyledi.
Öbür kampta olan insanlarsa bu kavramların yaşamları boyunca çok sayıda yenilikle (merhaba JavaScript) test edildiğini ve buna rağmen başta yer alan prensiplerin ve ilkelerin korunarak yeniliklerin açık kaynak ve özgür yazılım kavramı ile yaşamaya devam edebildiğini ve bu ilkelerin değiştirilmesi halinde işte o zaman kavramların zarar göreceğini söyler vaziyette. Ben şahsen kendimi bu kampta hissediyorum. Ticari olarak bakınca özellikle servis olarak bulut sağlayıcılar tarafından verilen yazılımları geliştiren bu şirketlerin yaşamlarını sürdürmesinin zor olduğunun farkındayım ama bunun çözümünün de insanların açık kaynak kullanabildikleri alanları kısıtlamaktan geçmediğini düşünüyorum. Bu tip kısıtların olduğu bir lisans elbette olabilir sonuçta telif sahibi olan insanların nasıl kullanılabileceği konusunda her zaman tek söz sahibidir ama bu durumda da bu lisansın OSI tarafından kabul edilmesi yönünde bir baskı oluşturmak da bence doğru değil.
OSI zamanında open source kelimesini marka olarak tescil etmeye çalışıp bunda başarısız olduğuna göre elbette kimseye gidip burada “open source” / “açık kaynak” kavramını kullanamazsın diyemez fakat ben şahsen bu tip projelerin de sırf geçmişin hatırına kendilerine açık kaynak demememiz gerektiğini düşünüyorum. Hatta bir adım daha ileriye gideyim bence kavramı çevirip kaynağı açık diyebilirler zira bu kaynak koduna erişimin olduğu ama istediğiniz gibi bu koddan yararlanamayacağınız manasına gerçekten geliyor.
Öte yandan bu camiları zorlayan tek konu elbette sadece ticari meseleler değil. Kimi zaman ortaya çıkan bazı lisanslar da anın şartları göz önüne alındığında iyi bir şey yapmaya çalışsa bile bu iki otorite tarafından reddedilebiliyor. Bunun son örneklerinden biri anti-996 lisansı oldu. Son zamanlarda Çin menşeli şirketlerin özellikle kendi ülkelerinde geliştiricilerini haftanın 6 günü 9’dan 9’a çalışmaya zorlaması, geliştiriciler arasında bir tepkiye neden oldu. GitHub’da bu konuyla ilgili açılan bir repo birkaç hafta içinde 200.000 civarında yıldız alarak en yıldızlı ikinci depo konumuna gelirken, bu deponun adresi Çin otoritelerince engellendi. Tüm bu hengamenin içinde yazılan anti-996 lisansı bu lisansa sahip yazılımları kullananlara, çalışanların haklarına uluslararası çalışma kurallarına göre saygı gösterme yükümlülüğü yüklüyordu. Yazılımın kullanma koşullarını kısıtlaması nedeniyle bu lisans da FSF tarafından özgür olmayan bir lisans olarak kayıtlandı. Baktığınız zaman bu durum sadece çalışanların modern dünyaya aykırı bir mesai yükü altında ezilmesini engellemek için yazılmış bir lisansı kullanılmaz olarak yaftalayarak aslında kötü bir mesaj veriyor. Madalyonun öteki yanından baktığınızda, her ne olursa olsun çekirdek sayılabilecek özgürlüklere dokunulmasını engelleyerek, yazılımın “her zaman” “herhalde” “herkes için” ve “her durumda” açık ve/veya özgür olmasını sağlıyor.
Biz ne yapabiliriz?
Yukarıdaki sorunların elbette ne kolay bir çözümü var ne de herkesi mutlu edecek bir metodu. Peki, kurum ya da şahıs olarak açık kaynak kodlu yazılımlar geliştiriyorsanız neler yapmanız gerekiyor? Öncelikle kullandığınız bileşenler yakın zamanda bu tip bir lisans değişikliği yaşadıysa kullandığınız bileşenleri gözden geçirmelisiniz. Ayrıca bu yeni lisanslarla sizin iş modelinizin uyumlu olup olmadığını belirlemeniz gerekiyor. Elbette bu yeni lisansa sahip sürüme geçip geçmemek de bu kararların içerisinde olmalı zira lisans değişikliklerinin geriye yürümesi mümkün değil.
İkinci olarak da tavsiye edebileceğim konu, yazılımınıza FSF ya da OSI tarafından onaylanmamış bir lisansa ait bileşen alırken iki kere düşünmeniz gerektiği. Bu tip yazılımlar ya da kitaplıklar kendilerini elbette open source olarak niteleyebilir fakat FSF ve OSI’nin lisanslarına onay vermemesi, gerçekten öyleler mi diye düşünmeniz için çok büyük bir ünlem işareti.
Biz artistanbul olarak yazılım projelerinde açık kaynak bileşen kullanan firmalara bu konuda bir yönetişim modeli kurabilmesi için profesyonel destekler de sunuyoruz. Böyle bir desteğe ihtiyacınız olduğunu düşünürseniz, verdiğimiz hizmetleri inceleyebilir ya da bizimle iletişime geçebilirsiniz.
