CUPS ve Lisanslar Üzerine

Türkiye’de geçmişte açık kaynak bileşen ve kütüphaneleri kullanan bazı firmalar, başlangıçta lisans kurallarına dikkat etmediği için iş modelini değiştirmek ve hiç arzulamadığı halde kaynak kodunu açmak zorunda kaldı. Kullandığınız açık kaynak bileşendeki küçük bir lisans değişikliği yaptığınız işi nasıl etkiler, hiç düşündünüz mü?

(…)

“Linux Nedir? Yenir mi?” sunumu kadar olmasa bile açık kaynak dünyasıyla ilgilenmeye başladığımdan beri gerek ülkede gerekse harcıâlemde pek çok “Açık kaynak mı? Özgür yazılım mı?” ya da “Özgür yazılım açık kaynağı döver” sunumuna denk gelmişimdir. Başlangıçta teorik düzlemde felsefi bir tartışma gibi gelse de, aslında bu iki kavram günümüz teknoloji dünyasına yön verir vaziyette.

Rekabetin ve buna bağlı olarak beklentilerin arttığı bu dönemde geliştiricilerden ve geliştirme ve faaliyetinden de istekler ve beklentiler artıyor. Günde 50 devreye alma (deployment) süreci işletenin 49 devreye alma sürecini işleten rakibini geçtiği bir hıza gelmiş durumdayız. Geliştiriciler açısından yazdığı kodun üretim ortamına çıkma hızı önemli bir performans ölçütü haline gelmişken, operasyon ekipleri de bu kadar hızlı bir geliştirme ortamının hem geliştiriciler hem de iç ve dış müşteriler açısından sağlıklı sonuçlar vermesini sağlamaya çalışıyorlar.

Geliştirme hızının artmasına izin veren en önemli şeylerden birisi, muhakkak ki özgür yazılımların ortaya çıkması oldu. Bugün “bulut” diye adlandırdığınız herhangi bir teknolojinin altında mutlaka özgür yazılım ürünleri çalışıyor. Öte yandan geliştirme faaliyetini hızlandıran bir diğer etmen olan hazır bileşenlerin yazılımlarda kullanılabilmesi de yine kendisine özgür yazılımlar sayesinde taban bulmuş olan fikirlerden biri.

Yazılım lisanslarının önemini, ne işe yaradığını (bizim tabirle yenip yenmediğini), nelere dikkat edilmesi gerektiğini uzun süredir elimden geldiği kadarıyla anlatmaya çalışıyorum. Bu konuda insanlarda yavaş yavaş bilinç oluştuğunu görmek de beni son derece mutlu ediyor.

Genç bir programcının kendisi için ve GitHub’da yayınladığı birkaç yüz satırlık bir yazılımın lisansı belki çok önem arzetmese de, binlerce insanın kullandığı servislerde ya da yüzbinlerce eve girmiş donanımlarda kullanılan lisansların takibi ve değerlendirilmesi, yazılım süreçlerine entegre edilmesi gereken önemli bir adım.

Açık kaynak kod ile özgür yazılım arasındaki fark da tam olarak burada devreye giriyor. Her ne kadar açık kaynak kod fikri özgür yazılımı kapsasa da, iki kampın sahip olduğu lisanslar, bu lisanslara sahip bileşenlerin aynı projelerde kullanılması hatta bu lisanslara sahip bileşenlerin kapalı kaynak kodlu yazılımlarla birlikte kullanılması gibi durumlar hem hukukçu hem de teknik insanları bir araya getirecek bir süreç kurulmasını gerektiriyor.

Yakın zamanlarda Linux ve Mac OS X kullanan herkesi ilgilendiren bir lisans değişikliği, CUPS yazılımında oldu. CUPS temel olarak sahip olduğumuz herhangi bir dosyanın yazıcıdan çıktı olarak alınabilmesi sürecindeki her şeyle ilgilenen bir yazılım. Apple tarafından geliştirilen CUPS’ın kasım ayına kadar çıkan sürümleri farklı iki lisansla yayınlanıyordu ve bu durum özellikle Linux çevresinde yazılım geliştiricilerin lisans şartlarına uyması için kolaylık sağlıyordu.

Kasım 2017 tarihiyle Apache 2.0 lisansına geçen CUPS, bundan sonra sadece bu lisansla dağıtılacak. Apple, CUPS’a katkı yapan herkesten imzalattığı -gerçekten ıslak imza alıyor!- bir sözleşmeyle, yaptığı katkının haklarına ilişkin basit ruhsat aldığı ve bu ruhsat verilmezse ilgili katkıyı depoya almadığı için kolaylıkla lisansı değiştirmek konusunda söz sahibi. Bizim içinse konuyu örnek olay haline getirense Apache 2.0 ile GPL 2.0 lisansları arasındaki uyum sorunu.

 

Apache 2.0, GPL 2.0 ve CUPS

Bir özgür yazılım lisansı olarak GPL‘in en önemli özelliği, GPL bir yazılımın yeniden dağıtılması durumunda yazılımın ancak ve ancak GPL ile dağıtılmasını zorlamasıdır. Bu sayede yazılımı ister aynen isterse değiştirerek dağıtan herkes GPL kullanmak zorunda kalır ve böylece yazılıma herkes eşit ve GPL tarafından belirlenen şartlarla ulaşır.

Kullandığınız tek bir bileşen olduğu zaman bu konu ciddi bir mesele yaratmasa da, temel sorun GPL’in birden fazla bileşenle bir araya geldiği zaman ortaya çıkıyor. GPL aynı zamanda virütik olduğu için bir arada yeni bir eser meydana getirdiği durumlarda ortaya çıkan yeni eserin tamamının da GPL olarak dağıtılması gerkeiyor.

Apache 2.0’ın bazı durumlarda getirdiği sonlandırma koşullarına ilişkin koşulların GPL ile uyumlu olmaması nedeniyle GPL 2.0 ve Apache 2.0 lisanslı iki bileşeni tek bir bileşen gibi dağıtmak mümkün olmuyor. GPL 2.0 ve sonrası olarak işaretlenen bileşenlerdeyse yazılımın hak sahipleri işlerini GPL’in güncel sürümleri ile de lisanslamaya izin verdikleri için Apache 2.0 bir bileşenle birlikte çalışabiliyorlar. Temel sorunsa bu lisans değişikliğinden “GPL 2.0 only” lisansıyla dağıtılan bileşenlerin CUPS ile bundan sonra nasıl çalışacağı konusu.

Şimdi dilerseniz, bu örnek üzerinden lisanslara ilişkin bu sorunu nasıl çözebileceğimize bakalım.

 

Özel istisna

Özgür yazılım ve açık kaynak lisansları her ne kadar standart metinler de olsa, zaman zaman bu metinlerin sonuna bazı istisnalar konabiliyor. Bu istisnalar genelde belli bir yazılımı işaret etse de zaman zaman genel geçer sonuçlar da doğurabilir. Apple, Apache 2.0’a geçme kararı aldığında lisansın sonuna ekleyeceği bir istisnayla yazılımın GPL 2.0 bir yazılımla beraber dağıtıldığında GPL 2.0 olacağını söyleyen bir istisna koyarak sorunu çözebilirdi fakat karmaşıklığı arttırmamak için böyle bir yola gitmediler.

 

Yorum farkları

Bir lisansa sahip bir yazılımın başka bir yazılımla iletişim kurması halinde ortaya çıkacak yeni eserin hangi şartlara tabi olacağı konusunda elbette iki lisansın farklı kurallar getirmesi mümkün. Böyle bir durumda yapılması gereken, hangi lisansın geçerli olacağı sonucuna bakmak olacaktır.

Örneğin GPL bir yazılımın diğerine linklenmesinin işleme eser olarak kabul ederken, Apache Lisansı sadece bir yazılımdan diğer yazılıma kod kopyalanması durumunda işleme eser ortaya çıktığını söylemekte. Hal böyle olunca, iki yazılımın bir araya gelip çalıştığı bir durumda bir taraf diğer tarafa göre esnek davranabilmekte.

Öte yandan linklenmenin çeşidine göre konuyu daha da karmaşık hale getirmek mümkün. Malumunuz olduğu gibi çoğu işletim sistemi statik linkleme yerine dinamik linkleme yapmakta. Dinamik linkleme çalıştırabilir dosyanın bağlandığı diğer kitaplıkların çalıştırılabilir dosyanın oluşturulduğu anda değil de, çalıştırıldığı/yüklendiği zaman bağlanmasını sağlayan bir metot. Bu sayede API/ABI kırmadığınız sürece çalıştırabilir dosyaya dokunmadan kitaplığı güncelleme ve aynı kitaplığı birden farklı çalıştırabilir dosyaya linkleyip yerden tasarruf etme şansına sahip olabilirsiniz.

Dinamik linklemenin bu özellikleri GPL açısından bakıldığındaysa bir gri alan oluşturmakta, zira yukarıda da bahsettiğim gibi dinamik linkleme dilediğiniz zaman kodun kesin olarak ayrılmasını sağlayacak bir katman oluşturmaya izin veriyor. Yani GPL’in GPL ile birlikte çalışan bir yazılımın da GPL olmasını sağlayan virütik yapısını engellemeye izin veriyor diyebiliriz.

Bunun üstüne bir de yazılımların bir paket yöneticisi tarafından sisteme ayrı ayrı kurulduğunu düşünecek olursanız bu soyutluğu iyice arttırmak mümkün. Zaten çoğu dağıtım şu aşamda statik linklenmeye izin vermediği ve uygulamaları birer paket yöneticisi aracılığıyla dağıttıkları için de bir araya gelen yazılımların GPL anlamında bir işleme eser olmadığını söylemekte. Dolayısıyla eğer gömülü bir cihaz üreticisi değilseniz, sizin açınızdan esaslı bir değişiklik olmayacak hayatınızda.

Tüm bu açılardan incelediğinizde Apache ile linklenen bir GPL yazılımın iki ayrı lisansla yaşamına devam edebileceğini söylemek mümkün. Öte yandan “GPL 2.0 only” olup da örneğin statik olarak CUPS’a linklenen bir yazılımın dağıtılması gelecekte sorun oluşturabilir.

 

Profesyonellerin neye dikkat etmesi gerek?

Son kullanıcı bu durumdan nasıl etkilenecek diye soruların geldiğini duyar gibiyim. Sizi biraz hayal kırıklığına uğratacağım ama cevabım muhtemelen “Etkilenmeyecek!” olacaktır. Peki, biz niye buraya geldik diye merak ediyor olabilirsiniz. Temel meselemiz bu tip bir değişikliğe sahip bir yazılımı üreten, dağıtan ve kendi projelerinde kullanan geliştiricilerin farkındalık kazanması. Zira farkında olmadan kullandığınız bir bileşenin sahip olduğu lisans kimi zaman kariyeri etkileyecek sonuçlara neden olabilir.

Dolayısıyla özellikle bir tarafında sahipli bir kod olan projenin içindeyseniz projeye eklediğiniz her bir bileşenin lisansına ve bu bileşenin sahip olduğu lisansın hak ve yükümlülüklerine bakmanız ve bunu takip edebileceğiniz bir envanter oluşturmanız gerekmekte. Bu envanteri derleme/sürüm politikanıza entegre etmeniz ve daha da önemlisi çalıştığınız ekibin ve kurumun kültürüne de bu envanteri dayatmak yerine sürecin bir parçası olduğunu kabul ettirmeniz gerekecektir.

Böyle bir envanteri oluşturmak ve kurum kültürüyle iş süreçlerine dâhil etmek her zaman kolay olmayabilir. Artistanbul olarak bu alanda sizlere yardımcı olabiliriz. Bizimle bu konuda iletişime geçmek için iletisim@artistanbul.io‘ya bir e-posta gönderebilirsiniz.

 

 

Açılış görseli: rangizzz / 123RF Stok Fotoğraf