Copyleft ile Permissive Lisanslar Arasındaki Fark
Açık kaynak dünyasında permissive ve copyleft lisanslar arasındaki en önemli fark, türev eserlerin hangi şekilde lisanslanacağı konusunda ortaya çıkar. İzin verici lisanslar, yazılımı kullanan kişiye geniş haklar tanırken türevlerin kapalı kaynak olarak dağıtılmasına izin verir. Copyleft lisanslar ise bu özgürlüğü korumayı hedefler ve türev işlerin de aynı şartlarla paylaşılmasını ister. Bu nedenle bir projenin lisans seçimi, ticari hedefler ve topluluk beklentileri göz önüne alınarak dikkatle yapılmalıdır. Hangi yaklaşımın daha uygun olduğu çoğu zaman projenin amacına bağlıdır. Yanlış seçilen bir lisans, sonradan ciddi hukuki sorunlara yol açabilir. Geliştiriciler bu ayrımı iyi anladığında, hem kendi emeğini koruyabilir hem de başkalarının çalışmalarını uygun biçimde kullanabilir. Özellikle kurumsal ortamlarda lisans uyumluluğu, denetim süreçlerinin temel bir parçası hâline gelmiştir. Kısacası, izin verici ve kopyalanamaz lisanslar arasındaki sınır net olmalı ve her proje bu çizgiyi bilinçli biçimde çizmelidir.
MIT lisansı, açık kaynak dünyasının en sade ve kolay kavranan lisanslarından biridir. Bu lisansın temel koşulu, yazılımın telif hakkı bildiriminin ve izin metninin tüm kopyalarda korunmasıdır. Kullanıcılar yazılımı kişisel amaçlarla kullanabilir, değiştirebilir, kopyalayabilir ve dağıtabilir. Lisans, yazılımın hiçbir garanti vermediğini açıkça belirtir ve geliştiricinin yükümlülüğünü sınırlandırır. Bu açıklık sayesinde MIT lisansı, hem bireysel geliştiriciler hem de büyük şirketler tarafından sıkça tercih edilir. Lisans metni oldukça kısa olduğu için anlaşılması da kolaydır ve hukuki karmaşalara az yer bırakır. Yine de bildirimin silinmesi gibi basit bir ihlal bile lisans koşullarının ihlal edilmesi anlamına gelebilir. Bu nedenle dağıtım yapan herkesin metni dahil etmesi önemlidir. MIT lisansı, özgürlük ile sorumluluk arasında ölçülü bir yapı sunduğu için uzun yıllardır geniş kabulünü korumaktadır.
Apache 2.0 lisansı, BSD gibi izin verici lisanslara benzer bir yapıya sahip olmakla birlikte, buluş haklarını net biçimde ele alması bakımından öne çıkar. Lisansı kabul eden katılımcılar, katkıda bulundukları kodun buluş haklarını da kullanıcılara verdiklerini kabul ederler. Bu hüküm, geliştiricilerin ve kullanıcıların patent tehditlere karşı daha korunaklı hissetmesini sağlar. Ancak lisansın bir koşulu vardır: Eğer bir kullanıcı, lisanslı yazılımın kendi patentini çiğnediğini iddia ederek dava açarsa, patent hakkı geri alınabilir. Bu mekanizma, kötüye kullanımı önlemeye yönelik dengeleyici bir unsurdur. Apache 2.0 ayrıca ticari marka haklarını kapsamaz, bu da markaların ayrı olarak korunması gerektiğini gösterir. Büyük ölçekli projelerde seçim edilmesinin sebeplerinden biri de bu kapsamlı patent düzenlemesidir. Lisansın değişiklik bildirimi gerektiren hükümleri de şeffaflığı artırır.
GPL lisans ailesi, copyleft ilkesinin en bilinen örneklerinden biridir ve bulaşıcılık olarak adlandırılan bir özelliğe sahiptir. Bu ilkeye göre, GPL kapsamındaki bir kodu içeren türev bir yazılım dağıtılıyorsa, o yazılımın da GPL koşullarıyla paylaşılabilir olarak sunulması gerekir. Böylece özgürlük, yazılımın sonraki tüm sürümlerinde korunmuş olur. Bu yaklaşım, geliştiricilerin kapalı ticari ürünler üretmesini sınırlar. GPL'in bulaşıcılığı, sadece kodun fiilen birleştirildiği hallerde geçerli sayılır, bu nedenle hangi bileşenlerin ayrı sayılabileceği dikkatle değerlendirilmelidir. Yorumlar zaman zaman farklılaşabildiği için hukuki danışmanlık almak faydalı olabilir. GPL, özgür yazılım hareketinin ana taşlarından biri olarak görülür. Yine de bu katı yapısı, bazı kurumlar için ciddi bir engel oluşturabilir.
LGPL lisansı, GPL'in daha yumuşak bir türevi olarak tasarlanmıştır ve özellikle kütüphanelerin kullanımını kolaylaştırmak amacıyla ortaya çıkmıştır. LGPL kapsamındaki bir kütüphane, kapalı kaynak bir uygulama tarafından bağlantılı olarak kullanılabilir ve uygulamanın kendi lisansı serbestçe seçilebilir. Ancak kütüphanenin kendisi üzerinde yapılan değişiklikler hâlâ LGPL koşullarıyla paylaşılmak zorundadır. Bu denge, hem özgürlüğü korumayı hem de ticari uygulamaların önünü açmayı hedefler. Dinamik bağlantı ile statik bağlantı arasındaki fark, LGPL'in uygulanmasında kritik bir rol sahiptir. Geliştiricilerin bağlantı yöntemini doğru seçmesi, sorumlulukların kapsamını belirler. LGPL, özellikle yaygın kullanılan sistem kütüphanelerinde seçim edildiği için büyük bir ekosistemin temelini oluşturur.
AGPL ve bulut tabanlı servis alanında kritik bir fark ortaya koyar. Standart GPL yalnızca dağıtılan program kodunda kaynak kodu yükümlülüğü doğururken, AGPL internet aracılığıyla erişilen hizmetlerde bile son kullanıcılara kaynak kodu sunma koşulu getirir. Sunucuda işleyen bir değişiklik gerçekleştirildiğinde, geliştirici bu düzenlemeleri ağ hizmet alanlara açmak zorundadır. Bu madde, bulut yazılımı modelinde faaliyet gösteren şirketler açısından oldukça dikkat isteyen bir husustur. Kullanıcılar web arayüzü aracılığıyla iletişime girdiğinde dahi kaynak kodu erişimi doğar. Ticari ürünlerde bu yükümlülük masraf ve yasal risk bakımından değerlendirilmelidir. tescilli bileşenlerin AGPL kapsamına dahil olup olmadığı titizlikle kontrol edilmelidir. Dolayısıyla kurumlar, lisans seçimini yapmadan hukuk departmanı danışmanlığından faydalanmalıdır.
Berkeley Yazılım Dağıtımı ailesi kısa ve esnek maddeleriyle tanınır. Orijinal dört maddeli versiyon, tanıtım koşulu sebebiyle günümüzde görece az kullanım edilmektedir. 2 maddeli BSD, kaynak dağıtımında telif hakkı bildirimini ve feragat metnini tutmayı koşul kılar. üç maddeli sürüm ya da bu maddelere ek olarak yazılım adının izinsiz kullanılmasını yasaklar. Her üç varyant da kurumsal kullanıma geniş ölçüde serbesti tanır. tescilli ürünlere dahil edilmesi olanaklıdır, fakat lisans notunun dağıtımla beraber verilmesi gerekir. Söz konusu esneklik, bu lisans kodlarının geniş topluluklarca benimsenmesini sağlamıştır.
Ticari uygulama söz konusu olduğunda lisans uyum en kritik hale gelir. Tüm açık kaynak lisans metni kendine özgü yükümlülükler içerdiğinden, ürün geliştiren şirketlerin bu koşulları ayrı ayrı incelemesi şarttır. Ticari tek bir yazılımın içinde kullanılan her bağımlılık için lisans bilgisi kaydı tutulmalıdır. Bu tür uygulama, kaynak kod taraması araçlarıyla kendiliğinden hale dönüştürülebilir. Yanlış tek bir lisans, şirketler için ciddi mali zararlar doğurabilir. Bununla birlikte bazı lisans türleri ticari lisanslama modeliyle eşzamanlı sunulmaktadır. Bu sayede kuruluşlar, gereksinimlerine daha elverişli seçeneği saptayabilir.
Lisans türleri arasındaki çakışma sorunları, çok sayıda özgür bileşenin tek bir yazılımda aynı araya gelmesinden doğar. Örneğin GNU Genel Kamu Lisansı ve Apache Lisansı 2.0 arasındaki uyumsuzluk, söz konusu iki farklı metnin maddelerinin tamamen uyuşmamasından ileri gelir. Bu tür bir durumda çakışma tespit edildiğinde, yazılımın yayımlanması hukuken tehlikeli hale dönüşebilir. Geliştiriciler söz konusu durumda ya da modülü yeniden yazmak ya de lisans muafiyet talebinde bulunmak zorundadır. Uyumluluk denetimleri düzenli olarak yapılmalı. Bu şekilde ekip çalışanları bilinçli olur ve olası hatalar önceden çözülebilir.
Telif hak ile katkı koşulları, özgür yazılım topluluklarının sürdürülebilirliği bakımından esas bir unsurdur. Herhangi bir geliştirici kod gönderdiğinde, genellikle bu eklentinin telif haklarının nasıl aktarılacağı belirtilir. Bazı topluluklar geliştirici lisans sözleşmesi (CLA) ister ederken, diğerleri ise Geliştirici Sertifika of Kökeni (DCO) yöntemini tercih eder. Katılım sözleşmesi, proje sahibine daha geniş yetkiler tanırken, DCO sadece içeriğin yasal kaynağını doğrulamayı hedefler. Katkıcılar söz konusu koşulları onay etmeden evvel belgeyi mutlaka okumalıdır. Uygun bir tür katkı politikası, hem de katılımcıları hem de projeyi güvence altına alır.
Açık kaynak lisans modellerinin en önemli noktaları
Özgür yazılım lisans modelleri, yazılımın kaynak kodunu kullanma yetkisini kullanıcılara bahşeden belgelerdir. Bu metinler çoğu zaman kopyalama haklarını yazılı olarak sıralar. Ekipler hangi lisansı benimsediklerine bağlı olarak, kullanıcıların yükümlülükleri ayrıca farklılaşır. Bazı metinler uyarlamaların benzer koşullarla dağıtılmasını zorunlu kılar. Öteki lisanslar ise görece daha özgür bir çerçeve sunar. Bu yüzden sözleşme ifadesini titizlikle okumak gereklidir.
Lisans seçiminde en yaygın yanılgılar
Lisans seçiminde en sık karşılaşılan sorunlardan biri, koşulların ticari uygulamaya elverişli olup olmadığını denetle etmeden bırakmaktır. Birçok geliştirici bir kütüphanenin özgür görünmesini her durumda sınırsız kullanım demek olduğunu düşünür. Halbuki kopyalanabilirlik koşulları ürünün tamamını değiştirebilir. Ayrıca bir sorun ise alt bileşenlerin lisanslarını ayrı ayrı göz ardı etmektir. Zincirleme paketler öngörülmemiş sonuçlar doğurabilir. Dolayısıyla sistematik uyumluluk kontrolü gerçekleştirmek tavsiye edilir.
Uzman geliştiricilerin belirttiği öneriler
Deneyimli uzmanlar, lisans kararına önce uygulamanın amaçlarını berrak şekilde belirlemeyi öneriyor. Ürününüzü kapalı koruma altında bulundurmak hedefliyorsanız, serbest koşullar görece daha uygun düşünülebilir. Kullanıcıların iyileştirmelerini yeniden almak hedefliyorsanız ise paylaşımcı çerçeveler daha yerinde bir tercih olabilir. Bunun yanında metin örneklerini takımınızla ortak olarak uyum sağlamak faydalıdır.
Lisans ekonomik boyutu ve bütçe değerlendirmesi
Açık kaynak koşulların birçoğu parasız olmakla birlikte, uygulamada hiç masrafsız olmayabilir. Uyumluluk incelemesi bunun gibi görünmeyen masraflar karşımıza gelebilir. Bilhassa kurumsal uygulamalarda, koşul ihlallerinin getirebileceği mali sonuçlar göz önüne alındığında, önleyici yatırımlar çok kıymetli görünebilir. Finansman planı tasarlanırken, destek giderleri de hesaba katılmalıdır. Bu şekilde sürpriz harcama yüklerinin önüne geçilebilir.
Lisans tercihinin zamanlaması ve geliştirme süreçleri
Açık kaynak lisans seçimi, geliştirme yaşam döngüsünün erken aşamalarında verilmelidir. Sonradan koşul güncellemesi yapmak, bilhassa birçok katkıcının yer aldığı topluluklarda, oldukça karmaşık bir çalışma olarak karşımıza çıkabilir. Dolayısıyla temel yayın yayımlanmadan evvel lisans tercihinin netleştirilmesi büyük önem taşır. Büyüme döneminde bununla birlikte, bileşen kaydının sürekli biçimde yenilenmesi şarttır. Projenin büyüdüğü aşamalarda gerçekleştirilen rutin kontroller, ileride yaşanabilecek sorunları önceden tespit etmeyi mümkün kılar.
En çok sorulan soru ve yanıtlar
Kullanıcılar sıklıkla açık kaynak koşulların hukuki bağlayıcılığını araştırır. Temel bir yaklaşımla, koşul sözleşmeleri resmî birer mutabakat niteliği taşır. Bir başka soru ise izinlerin güncellenip yenilenemeyeceği yönündedir. Yayımlanmış bir paket için tanınan izinler genellikle geri alınarak kısıtlanamaz, fakat sonraki sürümler başka kurallarla dağıtılabilir. Bir diğer konu olarak çok defa merak edilen bir husus ise şudur: Lisans çelişkilerini ne şekilde giderebilirim? Bu sorunda bir hukukçuya danışmak en sağlıklı adımdır.