Bir önceki yazıda açık kaynak lisans türlerinin temel ayrımlarını ele almıştım. Bu yazıda, pratikte en çok sorun yaratan konuya odaklanıyorum: copyleft lisanslar — özellikle AGPL — ticari yazılım geliştirme ve bulut hizmetleri (SaaS) bağlamında ne tür riskler taşıyor?

Copyleft Mekanizması: Kısa Bir Hatırlatma

Copyleft lisansların temel prensibi basit: eğer copyleft lisanslı bir yazılımı değiştirip dağıtıyorsanız, değiştirilmiş versiyonun kaynak kodunu da aynı lisans altında sunmak zorundasınız.

Anahtar kelime "dağıtım" (distribution). Klasik GPL açısından dağıtım, yazılımın bir kopyasının üçüncü bir kişiye transfer edilmesidir. Bu tanım fiziksel ve dijital kopya teslimini kapsıyor, ancak uzun süre tartışmalı olan bir durumu kapsamıyordu: yazılımı kendi sunucunuzda çalıştırıp kullanıcılara ağ üzerinden erişim sağlamak.

SaaS Boşluğu (The SaaS Loophole)

İşte tam bu noktada GPL'in mimarisindeki en kritik boşluk ortaya çıkıyor.

Bir şirket, GPL lisanslı bir yazılımı alıp önemli ölçüde değiştiriyor. Ancak bu değiştirilmiş versiyonu kimseye dağıtmıyor — kendi sunucularında çalıştırıp bir web arayüzü veya API üzerinden hizmet sunuyor. GPL'in "dağıtım" tetikleyicisi hiçbir zaman aktive olmuyor. Sonuç: şirket, topluluk tarafından geliştirilen açık kaynak yazılımdan ticari fayda sağlıyor, ama kendi geliştirmelerini topluluğa geri vermek zorunda kalmıyor.

Bu durum 2000'li yılların ortasında, bulut bilişimin yükselişiyle birlikte ciddi bir tartışma konusu oldu. Google, Amazon ve diğer büyük bulut sağlayıcıları GPL yazılımları yoğun şekilde kullanıyor, değiştiriyor, ama SaaS modeli sayesinde kaynak kod paylaşım yükümlülüğünden muaf kalıyordu.

AGPL: Boşluğu Kapatan Lisans

Free Software Foundation, bu soruna yanıt olarak 2007'de GNU Affero General Public License'ı (AGPLv3) yayımladı. AGPL, GPL'in tüm hükümlerini içeriyor, ancak kritik bir ekleme yapıyor: Section 13 — Remote Network Interaction.

Bu hükme göre, AGPL lisanslı yazılımı değiştirip bir ağ üzerinden kullanıcılara hizmet sunuyorsanız, değiştirilmiş kaynak kodu bu kullanıcılara da sunmak zorundasınız. Dağıtım gerçekleşmese bile, ağ etkileşiminin kendisi copyleft yükümlülüğünü tetikliyor.

Ticari Kullanımda Somut Riskler

1. "Bulaşma" Riski (Copyleft Propagation)

Bir ticari yazılım projesine AGPL lisanslı bir bileşen dahil edildiğinde, bu bileşenle etkileşimin niteliğine bağlı olarak projenin tamamının AGPL kapsamına girmesi riski doğar. Bu durum genellikle "viral etki" veya "bulaşma" (copyleft propagation) olarak adlandırılır.

Kritik soru: AGPL bileşenle nasıl bir bağlantı kurulduğu. Statik bağlama (static linking) genellikle tek bir eser oluşturduğu kabul edilir ve copyleft etkiyi tetikler. Dinamik bağlama (dynamic linking) ise tartışmalıdır. AGPL ve GPL metinleri bu konuda açık bir tanım vermez; Free Software Foundation geniş yorumlar, ancak bu yorum yargı kararlarıyla kesinleşmiş değildir.

Uygulama açısından en güvenli yaklaşım: AGPL bileşenin, ana yazılımdan ayrı bir süreç (separate process) olarak çalıştırılması ve aralarındaki iletişimin arm's-length bir protokol (HTTP API, soket, vb.) üzerinden sağlanması. Bu mimari ayrılık, copyleft etkinin ana yazılıma sirayet etme riskini önemli ölçüde azaltır — ancak tamamen ortadan kaldırdığı kesin değildir.

2. Kaynak Kod İfşa Yükümlülüğü

AGPL ihlali tespit edildiğinde en acil sonuç, değiştirilmiş kaynak kodun ifşa edilmesi yükümlülüğüdür. Ticari yazılım geliştiricide bu, rekabet avantajı sağlayan proprietary kodun açığa çıkması anlamına gelebilir.

Önemli bir nüans: AGPL yükümlülüğü yalnızca AGPL bileşenin kendisi ve onunla birlikte "tek bir eser" oluşturan kod için geçerlidir. Tamamen bağımsız modüller, ayrı süreçler ve yalnızca standart arayüzler üzerinden iletişim kuran bileşenler kural olarak kapsam dışında kalır. Ancak bu sınırın nerede çizileceği büyük ölçüde somut olayın koşullarına bağlıdır.

3. Çift Lisanslama Stratejileri ve Ticari Baskı

Bazı açık kaynak projeler, "çift lisanslama" (dual licensing) modeli uygular: yazılım bir yandan AGPL altında ücretsiz sunulur, öte yandan ticari bir lisansla (copyleft yükümlülüklerinden muaf) ücretli olarak lisanslanır. MongoDB (SSPL'ye geçmeden önce), Neo4j ve iText bu modelin bilinen örnekleridir.

Bu model hukuki açıdan meşrudur — eser sahibi, eserini dilediği koşullarla lisanslayabilir. Ancak ticari kullanıcılar açısından şu riski taşır: AGPL versiyonuyla başlayıp ticari lisansa geçiş maliyetinin yüksek olması. Proje bağımlılığı oluştuktan sonra ticari lisans ücretleri üzerindeki pazarlık gücü önemli ölçüde azalır.

4. Tedarik Zinciri Riski

Modern yazılım geliştirme, yoğun bir bağımlılık (dependency) ağı üzerine kuruludur. Bir Node.js projesinde yüzlerce, bir Java projesinde binlerce bağımlılık bulunması olağandır. Bu bağımlılıklardan herhangi birinin AGPL veya GPL lisanslı olması, tüm projeyi etkileyebilir.

Sorun: geliştiricilerin çoğu, kullandıkları bağımlılıkların lisanslarını sistematik olarak kontrol etmiyor. "npm install" veya "pip install" komutuyla eklenen her paket, beraberinde bir lisans yükümlülüğü getiriyor. Software Composition Analysis (SCA) araçları — FOSSA, Snyk, Black Duck gibi — bu riski yönetmek için tasarlanmış olmakla birlikte, kullanımları henüz Türkiye'deki yazılım sektöründe yaygınlaşmış değil.

Uluslararası Yargı Pratiğinden Örnekler

Açık kaynak lisans uyuşmazlıkları henüz geniş bir içtihat külliyatı oluşturmuş değil, ancak mevcut kararlar önemli işaretler veriyor:

Jacobsen v. Katzer (ABD, 2008): Federal devre mahkemesi, açık kaynak lisans koşullarının birer "koşul" (condition) olduğunu — sözleşmesel "taahhüt" (covenant) değil — ve ihlallerinin telif hakkı ihlali teşkil ettiğini teyit etti. Bu karar, açık kaynak lisansların ABD'de telif hakkı hukuku kapsamında uygulanabilirliğini güçlendirdi.

Welte v. Sitecom (Almanya, 2004): GPL ihlali davasında Münih Bölge Mahkemesi, GPL'in geçerli ve uygulanabilir bir lisans olduğunu kabul etti. Sitecom'un GPL lisanslı Linux bileşenlerini lisans koşullarına uymadan ticari ürünlerinde kullanması ihtiyati tedbir kararıyla durduruldu.

Telif hakkı ihlali olarak copyleft ihlali: Her iki kararda da mahkemeler, açık kaynak lisans ihlalini salt sözleşme ihlali olarak değil, telif hakkı ihlali olarak değerlendirdi. Bu ayrım önemli çünkü telif hakkı ihlali, ihtiyati tedbir ve tazminat açısından sözleşme ihlalinden daha güçlü hukuki araçlar sunuyor.

Uyum İçin Pratik Öneriler

Ticari yazılım projelerinde açık kaynak uyumluluğu için temel adımlar:

  1. Lisans envanteri oluşturun. Projede kullanılan tüm açık kaynak bileşenlerin ve bunların lisanslarının sistematik bir kaydını tutun. SCA araçları bu süreci otomatikleştirebilir.

  2. Mimari kararları lisans farkındalığıyla alın. Copyleft bileşenlerle entegrasyon yöntemi (statik/dinamik bağlama, ayrı süreç, API iletişimi) hukuki sonucu doğrudan etkiler.

  3. Bir açık kaynak politikası belirleyin. Hangi lisans türlerinin kabul edilebilir olduğunu, hangilerinin hukuki inceleme gerektirdiğini ve hangilerinin yasak olduğunu belirleyen kurumsal bir politika oluşturun.

  4. Çıkış stratejisi planlayın. Kritik bir bağımlılığın lisans koşulları değişirse veya ticari lisansa geçiş gerekirse, alternatif planınız hazır olsun.

  5. Katkıda bulunanlara dikkat edin. Eğer çalışanlarınız açık kaynak projelere katkıda bulunuyorsa, bu katkıların fikri mülkiyet hakkı ataması (IP assignment) ve lisanslama açısından kurumsal politikalarla uyumlu olduğundan emin olun.

Sonuç

Açık kaynak yazılımın ticari kullanımı, "ücretsiz yazılım kullanmak" kadar basit bir mesele değil. Özellikle copyleft lisanslar — ve bulut çağında AGPL — dikkatli bir hukuki değerlendirme gerektiriyor. Lisans uyumu ihmal edildiğinde ortaya çıkabilecek riskler, kaynak kod ifşasından tazminat sorumluluğuna kadar uzanıyor.

Bir sonraki yazıda konuyu Türkiye özelinde ele alacağım: Türk yazılım sektöründe açık kaynak kullanım pratikleri, karşılaşılan hukuki sorunlar ve mevcut düzenleyici çerçevenin yeterliliği.

Dr. Muhammed Furkan Akıncı, Boğaziçi Üniversitesi Hukuk Fakültesi Bilişim Hukuku Anabilim Dalı öğretim üyesidir.