Açık Kaynak Lisansları ile Neşeli Geliştirme

Yazı dizimizin ikincisiyle karşınızdayız. Bu yazımızda Açık Kaynak Lisansları ile ne yapıp, ne yapamayacağınızı konuşacağız.

Bu yazı dizisinin ilk yazısını doğum günümden bir gün önce, 20 Temmuz tarihinde yayına aldık. Sonra araya doğum günüm girince, ikinci yazıyı yayına hazırlamak biraz zaman aldı (Arka planda “Work hard play hard” şarkısını çalarsak ne kadar çılgın bir hayatım olduğunu anlarsınız).

Şaka bir yana, geçen yazıda sizlere hem fikri mülkiyet kavramının ortaya çıkışından hem de özgür yazılım kavramının ortaya çıkışından bahsetmeye çalışmıştım. Bu yazıdaysa özgür yazılım ve açık kaynak lisanslarının, projenizde nasıl kullanılacağına biraz bakmaya çalışalım.

Malumunuz, geçtiğimiz yıllar içinde içerikleri çok çabuk tüketir hale gelmemiz, mobil platformların ortaya çıkması, bir şeye girişmenin iyi bir fikir olduğunun birçok kişi tarafından benimsenmesi gibi bir sürü nedenle fikrinizin uygulamaya dönüşmesi sürecinin giderek kısalması gerekti. Eskiden basketbolculara verilen MVP titrindeki most kavramı, günümüzde yatırımın en hızlı şekilde dönmesini sağlayacak ve riski minimize edecek MVP kavramındaki minimuma dönüşmüş durumda.

Dolayısıyla geliştiriciler, proje yöneticileri ve bu işin içinde olan herkes, temel işlevleri düzgün çalışır, kaliteli, güvenilir ve güvenli bir uygulamayı bir an önce devreye almak için çeşitli yöntemler aramaya başladı. Bu yöntemlerden biri de uygulamanın tamamını geliştirmek yerine, önceki geliştirme faaliyetlerinden yararlanmanın bir yolunu bulmak oldu. Özellikle açık kaynaklı yazılımların mobil uygulamalarda bu kadar çok yer bulmasının temelinde bunun yattığını düşünüyorum.

Açık kaynağın sahipli yazılım geliştirme yöntemlerine göre avantajlarının ve bunun projelerinize nasıl uygulayacağınız hakkında internet üzerinde epey bir kaynak var. Onları tekrar etmemek için bu konuyu hızlı geçiyorum. Özetle şunu söylemek mümkün:

Açık kaynak kazandı!

Facebook, kendi geliştirdiği birçok teknolojiyi geliştiricilere açık kaynak olarak sunuyor.

 

Lisans neydi?

Sizin ürettiğiniz ya da internette bulduğunuz bir yazılımın ya da kodun bazı haklarının saklı olduğundan ve bu hakların kural olarak o yazılımı üretmiş kişiye ait olduğundan, bundan bir önceki yazıda bahsetmiştik. Yine aynı yazıda bu hakları kendilerine saklamak yerine, insanlarla paylaşan insanlar olduğundan ve bu sayede özgür yazılım ve daha sonra açık kaynak kavramlarının oluştuğundan da bahsetmiştik. Şimdi sıra bu bilgileri kullanarak bunun pratikte yer alan yansımalarına bakmaya geldi.

GitHub‘da sunulan projeler arasında dolaştığınızda, her depoda üç aşağı beş yukarı bulabileceğiniz ortak şeyler vardır. Readme dosyaları, belgeler ya da bizim yazımızın konusunu oluşturan lisans dosyaları. Bu lisans dosyaları hemen hemen standartlaşmış ve bizim bu yazılımı kendi projemizde nasıl kullanacağımızı anlatan temel belgelerdir. İster uzun ister kısa olsunlar ya da içlerinde ilk duyduğunuzda size garip gelecek olan bazı koşullar içerseler bile, her bir lisans metni o projenin sahiplerinin iradesini yansıtması bakımından geçerli ve hukuki bağlayıcılığı olan bir metindir.

Özgür yazılıma yönelik ilk adımların ve organizasyonların özellikle ABD menşeli olması nedeniyle, bu metinlerin bir miktar ABD hukuk sistemine yönelik hazırlanmış olmasına yol açtı. ABD’de olmasanız bile merak etmeyin; çünkü bu metinlerin geçerliliği dünya çapında çeşitli davalarda defalarca ispatlandı. Dolayısıyla ister bir özgür yazılım projesi geliştiriyor olun isterseniz böyle bir projeyi kendi yazılımınızda kullanın, ilgili lisansın geçerliliği konusunda bir şüphe duymanıza gerek yok.

Elinizde hukuki geçerliği konusunda en azından şeklen sorunu olmadığını düşündüğünüz bir metin olduğuna göre, sizin için asıl önemli konu olan içeriğe geçmek gerekiyor. Sahipli yazılımların lisansları genelde size yazılımla ne yapamayacağınızı söylerler. Örneğin program üzerinde tersine mühendislik yapamazsınız ya da tekrar satamazsınız ya da ek kopya alamazsınız gibi.

Açık kaynaklı yazılım lisanslarıysa temelde bu yazılımla neler yapabileceğinize dair bir belgedir. Lisansla verilen özgürlükler, bana sormayın da ne yaparsanız yapınla başlayıp örneğin askeri bir projede bu yazılımın kullanımını yasaklamaya varacak kadar o yazılımın üreticilerini ve telif sahiplerini yansıtan metinlerden oluşmaktadır. Peki, ortada bunca yazılım, bu yazılımlara ait buna farklı lisans varken, kendi projenizde bu lisansları nasıl kullanacaksınız? Yavaş yavaş bu konuya girebiliriz.

 

Temel ayrım: Kısıtlayıcı ve serbest lisanslar

Daha birkaç dakika önce açık kaynak, özgür yazılım derken konu başlığımızın içinde kısıtlama kelimesi geçmesi dikkatli okuyucularımızı şaşırtmış, ironi seven okuyucuları güldürmüş olsa da FOSS (Free and Open Source Software -­ Özgür ve Açık Kaynak Kodlu Yazılım) ailesi içindeki temel ayrım lisansın kısıtlayıcı mı yoksa serbest mi olduğu ile ilgilidir. Konuyu kısaca özetlemek gerekirse, kısıtlayıcı bir lisans size bir lisansla verilmiş kodun, sizin tarafınızdan tekrar dağıtımı yapılırken, yeni şartlar belirtmenizi engelleyen ve aldığınız lisansın aynısıyla kodu dağıtımanızı zorlayan lisanslardır. Bu lisansların en bilineni FSF tarafından yazılmış olan ve aynı zamanda en çok kullanılan lisans ailesi olan GPL ailesidir.

Bu lisanslarda, siz kodu GPL ile lisanslanmış alırsanız bu kodu tekrar dağıtırken yine GPL şartlarını sağlayıcınızı kabul edersiniz. Bu sayede kod kişiden kişiye geçerken her zaman özgür yazılım olarak kalabilmektedir. Hatta GPL bu konuyu bir adım öteye götürür ve GPL yazılımın ayrılmaz parçaları olarak kabul edilebilecek parçaların da GPL gibi dağıtılmasını şart koşar. Dolayısıyla yazılımın gerçekten özgür olması sağlanır. Örneğin, bu yüzden her bir telefon üreticisi ürettiği Android tabanlı bir telefonun içindeki Linux çekirdeğini talep eden herkes ile paylaşmak zorundadır; çünkü Linux çekirdeği GPL ile lisanslanmıştır.

Öte yandan serbest ya da liberal diyebileceğimiz lisanslarda ise yazılım lisansı sadece sizin kodu hangi şartlarla nasıl kullanacağınızı belirler ve sizin bu kodu nasıl dağıtacağınıza dair bir hüküm getirmez. Dolayısıyla dilerseniz açık kaynak olarak aldığınız bir yazılımın kaynağını kapatarak dağıtabilirsiniz. Bu, tabii ki özgür yazılım mantığına aykırıdır ve temelde özgür yazılımla açık kaynak kod arasındaki fark buradan kaynaklanmaktadır.

Open Source ile Free Software kampı arasındaki tartışma ve çekişme uzun süredir devam ediyor.

Dolayısıyla kendi projenizde FOSS ile lisanslanmış bir yazılım kullanacaksanız, karar vermeniz gereken ilk şey bileşenlerin özgür yazılım lisanslarına mı sahip olacağı yoksa açık kaynak lisanslarına mı sahip olacağı konusudur. Bu kararı daha sonra değiştirmeniz projede aksama ya da geri dönülmez sonuçlara yol açacağından iyi düşünmeniz gerekir.

GitHub’da Twitter tarafından paylaşılan bir projeye ait lisans bildirimi.

 

Sorumluklar, sorumluluklar ve sorumluluklar…

Projenize ister açık kaynaklı isterse özgür bir yazılım bileşeni dâhil ediyor olun, bu durum size bazı sorumluluklar yükleyecektir. Bu sorumlukları temel üç kategori içerisinde değerlendirmek mümkün.

 

Bildirim yükümlülüğü

Bugüne kadar karşılaştığım hemen tüm lisanslarda telif sahibi, projenizde kendi yazılımının da kullanıldığının bildirilmesini talep etmektedir. Genelde bunu nasıl yapmanız gerektiği, yazılım lisansının içerisinde yer almaktadır. Burada önemli olan lisans metnini ve telif satırını değiştirmeden ve varsa istenen ek bildirimle (genelde sorumluluk reddi vb.) birlikte kullanıcılarınıza bildirimde bulunmanızdır.

Çoğu cep telefonu uygulaması, bunu ayarlar menüsü altında bulunan bir “Telif Hakları” ya da “Açık Kaynak Lisansları” bölümünden ulaşılacak şekilde ayarlar.

Spotify’ın Android sürümünün lisans listesine, ayarlar menüsünden ulaşmak mümkün.

 

Kodu hangi şartlarda kullanabileceğinize dair yükümlülükler

Projenize almak istediğiniz kodun, projeye nasıl gireceği konusunda o kodu yazanların ne dediğinize bakmanız gerekiyor. Bunu yapmanın en basit yolu da lisans metnini hızlıca okumaktır. Örneğin BSD, MIT gibi liberal lisanslarda, sadece bir üst satırda bulunan bildirim yükümlülüğünü yerine getirmek, kodu kullanmak için yeterli. Kimi lisanslar ise projenin askeri içerikli olmamasını, kodu yazanın evsiz kalması durumunda kendisine yatabileceği bir kanepe verilmesini, hayatının tehlikede olması halinde öncelikli olarak kurtarılmasını ya da bir barda karşılaşıldığında bira ısmarlanması gerektiğini söylemektedir.

Bahsettiğim bu örnekler aslında gerçek lisanslardan alınan şartlar olup; bu şartlar,­ çoğu zaman hukuk düzeni tarafından korunan makul isteklerdir. Dolayısıyla kodu kullanmaya izniniz olup olmadığını değerlendirmenin en iyi yolu lisansı okumaktır.

Eğer bir FOSS yazılımı projenize alacaksanız, yapmanız gereken lisansını okuyup sizden istediklerini yerine getirip getiremeyeceğine karar verin ve eğer isteklerden biri hakkında bile şüphe duyuyorsanız o kodu yazılımınıza almayın.

Yazının başında belirttiğim gibi bir çeşit “hız” çağında olduğumuz için, insanlar hiçbir şey için uzun zaman ayırmak istemiyorlar. Hatta İngilizler özellikle uzun metinlerin can sıktığını dolayısı ile okumadıklarını anlatmak için bir de kısaltma bulmuş durumdalar. TL;DR (Too long; did not read – Çok uzun; okuyamadım.) olarak yazılan bu kısıtlamayı dilimize Ekşi Sözlük yazarlarının mükemmel yerelleştirmesi ile “Okumadım kardeş durumum yoktu” olarak çevirmek mümkün. Eğer siz de bu lisanları okumak istemiyor ya da doğru anladığınızdan emin olmak istiyorsanız, bu lisansların özetlendiği ve üç aşağı beş yukarı ne yapıp ne yapamayacağınızı anlatan tldrlegal.com adresine göz atabilirsiniz.

TLDR’den GPL v3 özeti.

 

Dağıtım sonrası yükümlülükler

Özellikle özgür yazılım lisanslarının sadece yazılımı edinmenize ve kullanmanıza yönelik değil, bu yazılımı başkalarıyla da paylaşırken uymanız gereken şartlar getirdiğinden az önce bahsetmiştim. Bu üçüncü grup yükümlülükte işte bu şartları dikkate almanız gerekiyor. Bu şartlar genellikle yazılıma ait kaynak kodun yazılımla birlikte dağıtılıp dağıtılmayacağı ve dağıtılacaksa bunun hangi şartlarda ne kadar süreyle yapılacağına dair düzenlemelerdir.

Burada unutmamanız gereken bazı yazılım lisanslarının sadece kendisinin değil, projenin içindeki tüm yazılım bileşenlerini etkileyecek şartları içerdiğidir. Örneğin GPL bir bileşen bir proje içinde kullanıldıysa o projenin GPL ile ayrılamayacak bir etkileşime giren tüm kısımlarının GPL olarak dağıtılması gerekmektedir. Dolayısıyla bütün projeniz bir anda özgür yazılıma dönüşebilmektedir. Eğer baştan böyle bir amacınız yoksa ya da projenin içinde kaynağını dağıtamayacağınız bir bileşen varsa bu tip konuları önceden araştırmanız ve önlemlerinizi ona göre almanız gerekmektedir.

Bir not olarak eklemem gerekir ki, bu yazıyı kaleme aldığımda Apple ve Google Play dükkânlarında içinde GPL ailesinden bir yazılım barındıran bir uygulamanın dağıtılıp dağıtılmayacağı konusunda epey bir belirsizlik var. Bu yazılımlar özel anahtarlarla imzalandığı için daha sonra bu yazılımı alan birinin içindeki kitaplığı değiştirip aynı yazılımı derleyip cihaza yüklemesi mümkün olmadığından bu tip yazılımların içinde GPL olmasının bir ihlal oluşturacağı söyleniyor ki, ben de bu duruma katılıyorum.

Sonuç olarak projenizi bitirip dağıtmaya hazır olduğunuz zaman içinde kullandığınız bileşenlerin dağıtıma ilişkin hususlarının neler olduğunu iyice belirlemeniz gerektiğini unutmamalısınız.

 

Özetle…

Konu uzun, ben bol yazmayı sevdiğim için yazıyı yavaş yavaş toplasam iyi olacak diye düşünüyorum. Özetle size yazılımınızda kullanacağınız FOSS bileşenler için şu önerileri vereceğim.

• Her zaman kullandığınız 3. parti bileşenler için bir envanter tutun ve neyi nerede kullandığınızı yazın.
• Bir kitaplığın tamamını kullanmakla içinden birkaç fonksiyonu alıp kopyalamanın bir farkı yoktur. Dolayısıyla azıcık kopyalamanın da size aynı yükümlülükleri yüklediğini unutmayın.
• Lisans dosyasını bileşeni projeye ekleyip, kodu yazdıktan sonra değil önce okuyun. Sorumlulukları karşılayamayacağınızı düşünüyorsanız o bileşeni kullanmayın.
• FOSS bileşenlerde yaptığınız değişiklikleri ana projeye göndermeyi unutmayın. Bu sayede özgür yazılıma siz de destek olabilirsiniz.­
• Lisansların size yüklediği sorumlulukları angarya olarak görmeyin, zamanında ve hassasiyetle yerine getirin.

Sorularınızı yorumlarda dile getirirseniz, ben de elimden geldiğince yardımcı olmaya çalışacağım. Tekrar görüşmek üzere…