Mozilla Public License ile Dosya Düzeyinde Copyleft
Açık kaynak dünyasında izin verici ve kopyalanamaz lisanslar arasındaki en önemli fark, türev eserlerin hangi şekilde lisanslanacağı konusunda ortaya çıkar. İzin verici lisanslar, yazılımı kullanan kişiye oldukça esnek haklar tanırken türevlerin kapalı kaynak olarak dağıtılmasına izin verir. Copyleft lisanslar ise bu özgürlüğü güvence altına almayı hedefler ve türev işlerin de aynı şartlarla paylaşılmasını ister. Bu nedenle bir projenin lisans seçimi, kurumsal hedefler ve topluluk beklentileri göz önüne alınarak dikkatle yapılmalıdır. Hangi yaklaşımın daha doğru olduğu çoğu zaman projenin yapısı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ı doğru biçimde kullanabilir. Özellikle kurumsal ortamlarda lisans uyumluluğu, denetim süreçlerinin vazgeçilmez bir parçası hâline gelmiştir. Kısacası, izin verici ve kopyalanamaz lisanslar arasındaki çizgi net olmalı ve her proje bu çizgiyi bilinçli biçimde belirlemelidir.
MIT lisansı, açık kaynak dünyasının en sade ve anlaşılır lisanslarından biridir. Bu lisansın temel koşulu, yazılımın telif hakkı bildiriminin ve izin metninin tüm kopyalarda bulunması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 sadelik sayesinde MIT lisansı, hem bireysel geliştiriciler hem de büyük şirketler tarafından yaygın olarak tercih edilir. Lisans metni oldukça kısa olduğu için okunması da kolaydır ve hukuki belirsizliklere az yer bırakır. Yine de bildirimin silinmesi gibi basit bir ihlal bile lisans koşullarının çiğnenmesi anlamına gelebilir. Bu nedenle paylaşı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, patent haklarını net biçimde ele alması bakımından öne çıkar. Lisansı kabul eden katılımcılar, katkıda bulundukları kodun patent 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 belirli 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ı sınırlamaya yönelik koruyucu bir unsurdur. Apache 2.0 ayrıca ticari marka haklarını kapsamaz, bu da markaların bağımsız olarak korunması gerektiğini gösterir. Büyük ölçekli projelerde tercih edilmesinin nedenlerinden biri de bu ayrıntılı patent düzenlemesidir. Lisansın değişiklik bildirimi gerektiren maddeleri de şeffaflığı destekler.
GPL lisans ailesi, copyleft ilkesinin en güçlü örneklerinden biridir ve sirayet 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ığı, yalnızca kodun fiilen birleştirildiği hallerde geçerli sayılır, bu nedenle hangi bileşenlerin ayrı sayılabileceği dikkatle incelenmelidir. Yorumlar zaman zaman farklılaşabildiği için hukuki danışmanlık almak yararlı 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 önemli bir engel oluşturabilir.
LGPL lisansı, GPL'in daha esnek bir türevi olarak tasarlanmıştır ve özellikle kütüphanelerin kullanılması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ı özgürce seçilebilir. Ancak kütüphanenin kendisi üzerinde yapılan değişiklikler yine de LGPL koşullarıyla paylaşılmak zorundadır. Bu denge, hem özgürlüğü korumayı hem de ticari kullanımın önünü açmayı amaçlar. Dinamik bağlantı ile statik bağlantı arasındaki fark, LGPL'in yorumlanmasında kritik bir öneme sahiptir. Geliştiricilerin bağlantı yöntemini dikkatli seçmesi, sorumlulukların kapsamını belirler. LGPL, özellikle yaygın kullanılan sistem kütüphanelerinde seçim edildiği için geniş bir ekosistemin omurgasını oluşturur.
AGPL ile ağ üzerinden hizmet konusunda önemli bir ayrım ortaya koyar. Standart GPL yalnızca paylaşılan program kodunda kaynak kodu yükümlülüğü doğururken, AGPL ağ üzerinden sunulan servislerde bile son kullanıcılara kaynak erişim sağlama şartı getirir. Sunucuda işleyen tek bir modifikasyon yapıldığında, yazılımcı bu düzenlemeleri ağ hizmet alanlara paylaşmak durumundadır. Bu madde, bulut yazılımı modelinde faaliyet gösteren şirketler açısından oldukça özen gerektirir tek bir husustur. Kullanıcılar tarayıcı aracılığıyla iletişime geçtiğinde bile kaynak kodu hakkı doğar. kurumsal ürünlerde bu yükümlülük maliyet ile yasal risk bakımından değerlendirilmelidir. Kapalı kaynaklı bileşenlerin AGPL çerçevesine girip girmediği dikkatle kontrol edilmelidir. Dolayısıyla kurumlar, lisans tercihini yapmadan hukuk departmanı danışmanlığından yararlanmalıdır.
BSD lisansları kısa ile esnek yapılı maddeleriyle tanınır. Orijinal dört maddeli versiyon, reklam maddesi nedeniyle bugün görece nadiren tercih edilmektedir. 2 maddeli sürüm, kaynak yeniden dağıtımda telif bildirimini ve feragat bildirimini tutmayı şart kılar. 3 maddeli BSD ya da bu maddelere ilaveten yazılım markanın onaysız kullanımını engeller. Her üç sürümler de ticari uygulamaya büyük ölçüde izin tanır. Kapalı kaynak ürünlere entegre edilmesi olanaklıdır, ancak lisans metni bildiriminin dağıtımla birlikte verilmesi zorunludur. Bu esneklik, bu lisans kodlarının geniş çevrelerce benimsenmesini sağlamıştır.
Kurumsal uygulama söz konusu olunca lisans türü uyum en önemli hale gelir. Her açık kaynak lisans metni kendi özgü yükümlülükler içerdiğinden, yazılım geliştiren firmaların bu koşulları ayrı ayrı incelemesi şarttır. Ücretli bir ürünün bünyesinde yer alan her bağımlılık için lisans kaydı oluşturulmalıdır. Bu tür süreç, kaynak kod denetimi yazılımlarıyla kendiliğinden hale getirilebilir. Yanlış bir lisans seçimi, şirketler açısından ciddi mali zararlar doğurabilir. Bununla birlikte bazı lisanslar kurumsal lisans modeliyle birlikte sunulmaktadır. Bu sayede kuruluşlar, gereksinimlerine en uygun seçeneği belirleyebilir.
Lisans türleri bileşenleri arasındaki uyumsuzluk sorunları, birden fazla açık kaynak bileşenin bir projede aynı bir arada gelmesinden kaynaklanır. Örneğin GNU Genel Kamu Lisansı ve Apache Lisansı 2.0 arasındaki çelişki, söz konusu iki lisansın maddelerinin tamamen uyuşmamasından dolayı gelir. Böyle bir durumda uyumsuzluk saptan edildiğinde, yazılımın yayımlanması hukuken tehlikeli hale dönüşebilir. Yazılımcılar bu sorunda ya modülü yeniden yazmak veya de lisans istisna isteğinde bulunmak durumundadır. Uyumluluk kontrolleri sürekli olarak yapılmalı. Bu şekilde geliştirme ekibi çalışanları farkında hale gelir ve olası hatalar erkenden giderilebilir.
Telif hakkı hakkı ve katkı koşulları, açık kaynak projelerinin devamlılığı bakımından esas önemli bir unsurdur. Bir geliştirici kod gönderdiğinde, çoğu zaman bu kodun telif hakkı haklarının hangi şekilde devredileceği tanımlanır. Bazı projeler geliştirici lisans anlaşması (CLA) talep ederken, bazıları ancak Geliştirici Certificate sertifikası Origin (DCO) mekanizmasını tercih eder. Katılım sözleşmesi, proje yönetimine çok kapsamlı haklar tanırken, DCO sadece kodun hukuki menşeini doğrulamayı hedefler. Katkıcılar söz konusu koşulları kabul vermeden evvel belgeyi mutlaka incelemelidir. Doğru bir tür katılım politikası, hem de katılımcıları hem de projeyi korur.
Özgür yazılım kullanım izinlerinin en önemli noktaları
Özgür yazılım kullanım izinleri, yazılımın kaynak kodunu dağıtma özgürlüğünü kullanıcılara veren yasal çerçevelerdir. Bu koşullar sıklıkla türev eser oluşturma yetkilerini net biçimde tanımlar. Geliştiriciler hangi lisansı seçtiklerine göre, katkıcıların yükümlülükleri ayrıca şekillenir. Bazı metinler uyarlamaların aynı lisansla yayımlanmasını gerektirir. Kalan modeller ise daha esnek bir yaklaşım sunar. Bu nedenle lisans metnini titizlikle incelemek önemlidir.
Lisanslama sürecinde en yaygın eksiklikler
Lisans seçiminde en çok karşılaşılan hatalardan biri, metinlerin ticarî uygulamaya uygun olmadığını araştır etmeden bırakmaktır. Pek çok kişi bir paketin açık kaynak olmasını her koşulda serbest kullanım anlamına geldiğini zanneder. Halbuki copyleft koşulları ürünün tümünü şekillendirebilir. Ayrıca bir yanılgı ise alt bileşenlerin lisanslarını tek tek değerlendirmemektir. Üçüncü taraf bileşenler farkında olunmayan kısıtlamalar getirebilir. Dolayısıyla periyodik lisans taraması uygulamak önerilir.
Tecrübeli mühendislerin belirttiği ipuçları
Deneyimli geliştiriciler, lisans kararına başlamadan projenin amaçlarını berrak biçimde belirlemeyi öneriyor. Ürününüzü kapalı koruma altında bulundurmak istiyorsanız, esnek koşullar daha elverişli olabilir. Katkıcıların değişikliklerini yeniden toplamak önemsiyorsanız ise copyleft çerçeveler çok makul bir alternatif değerlendirilebilir. Buna ek olarak metin örneklerini kurumunuzla birlikte tutarlılık yaratmak yararlıdır.
Lisanslama bütçesi ve bütçe değerlendirmesi
Özgür lisansların çoğu parasız olmakla birlikte, uygulamada tamamen bedelsiz olmayabilir. Hukuki danışmanlık bunun gibi gizli harcamalar ortaya dökülebilir. Özellikle ticari uygulamalarda, lisans uyumsuzlukların doğurabileceği mali riskler hesaba katıldığında, koruyucu kaynaklar daha kıymetli görünebilir. Kaynak çerçevesi hazırlanırken, güvenlik güncellemesi harcamaları ayrıca dikkate konulmalıdır. Bu sayede sürpriz harcama yüklerinin önüne geçilebilir.
Lisans kararının vakti ve geliştirme aşamaları
Açık kaynak lisans kararı, proje yaşam döngüsünün erken safhalarında yapılmalıdır. Geç dönemde koşul güncellemesi gerçekleştirmek, özellikle pek çok ortağın yer aldığı ortamlarda, oldukça karmaşık bir çalışma hâline gelebilir. Bu yüzden başlangıç sürümü yayımlanmadan evvel koşul seçiminin kesinleşmesi hayati önem arz eder. Genişleme aşamasında ise, paket envanterinin sürekli biçimde güncellenmesi önemlidir. Uygulamanın geliştiği dönemlerde uygulanan düzenli kontroller, ileride yaşanabilecek problemleri zamanında görmeyi mümkün kılar.
Merak edilen soru ve yanıtlar
Kullanıcılar sıklıkla özgür lisansların hukuki etkisini araştırır. Genel bir yaklaşımla, lisans belgeleri hukuken geçerli birer sözleşme özelliği taşır. Sık gelen bir merak ise koşulların revize edilip yenilenemeyeceği hakkındadır. Sunulmuş bir paket açısından sunulan haklar çoğunlukla geriye dönük kısıtlanamaz, ancak sonraki sürümler farklı şartlarla dağıtılabilir. Son bir soru olarak pek çok kez sorulan bir konu de odur: Koşul çakışmalarını nasıl giderebilirim? Bu konuda alanında deneyimli bir danışmana başvurmak en doğru yoldur.