GPL bulaşması yazımızda ürününüze giren kodu ele almıştık. Bu yazının konusu ise dışarıya verdiğiniz kod: müşterileriniz daha hızlı entegre olsun diye yayımladığınız SDK, geliştirici topluluğu oluşturmak için açtığınız çekirdek ya da iyi bir tanıtım aracı olduğu için paylaştığınız iç araç. Bir Türk şirketi kaynak kodunu yayımladığı anda herkese bir lisans vermiş olur. Lisans metni de şu soruların cevabını belirler: bir rakip kodun barındırılan bir sürümünü işletebilir mi, katkı verenlerin patentleri lisansın kapsamında mı, şirket kodu ileride yeniden kapatabilir mi ve bir alıcının due diligence ekibi tarama yaptığında kod hangi kategoriye girer. Seçenekler dört ailede toplanır: izin verici lisanslar (MIT, BSD, Apache-2.0), zayıf copyleft (MPL-2.0, LGPL), güçlü ve ağ copyleft’i (GPL-3.0, AGPL-3.0) ve aslında hiç açık kaynak sayılmayan source-available lisanslar (BUSL-1.1, SSPL-1.0, Elastic License 2.0). Bu yazıda her ailenin neyi verip neyi elde tuttuğunu, seçimin Türk telif hukukuyla nasıl kesiştiğini ve kararın nasıl verileceğini ele alıyoruz. Standart metinleri ve SPDX kimliklerini açık kaynak lisans rehberimizde bir arada bulabilirsiniz.
Türk hukukuna göre aslında ne veriyorsunuz?
5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK) yazılımı korunan eserler arasında sayar (m.2/1) ve mali haklar eser sahibine aittir. Açık kaynak lisansı, FSEK’in diliyle bir ruhsattır: mali haklar devredilmeden bunları kullanma yetkisi verilir (m.48/2). m.52’ye göre bu tür tasarrufların yazılı yapılması ve verilen hakların tek tek gösterilmesi gerekir. İyi hazırlanmış lisanslar bu şartı zaten karşılar: MIT kullanma, kopyalama, değiştirme, birleştirme, yayımlama, dağıtma, alt lisans verme ve satma haklarını sayar; Apache-2.0 ve GPL ailesi ise çoğaltmayı, türev eser hazırlamayı, umuma göstermeyi, dağıtmayı ve Apache’de ayrıca patent lisansını açıkça düzenler. Şirketin kendi kaleme aldığı bir “kullanımı serbesttir” notu çoğu zaman bunu yapmaz. Kendi metninizi yazmak yerine standart bir metin seçmenizin ilk sebebi de budur.
Türk hukukunun iki özelliği değerlendirmeyi doğrudan etkiler. Birincisi, manevi haklar (m.14–16) gerçek kişi eser sahiplerinde kalır ve devredilemez. Bu nedenle lisanslardaki atıf ve yanıltıcı tanıtım yasağı koşulları Türk hukukuyla rahatça bağdaşır; ancak şirketin önce lisansladığı mali haklara sahip olması gerekir. Çalışanın yazdığı kod m.18/2 uyarınca işverene geçer, kurucunun veya yüklenicinin kodu ise ancak yazılı devirle. Bu konuyu fikri mülkiyetin şirkete geçişi yazımızda anlattık. İkincisi, açık kaynak metniyle herkese verilen lisans uygulamada geri alınamaz. Metinler bunu açıkça söyler; FSEK de bedel karşılığında ya da belirtilen şartlarla verilmiş bir ruhsatı geri çekmek için genel bir hak tanımaz. Tek istisna, ruhsat sahibinin hakları kullanmaması hâlinde m.58’de öngörülen dar kapsamlı cayma hakkıdır. Kısacası bir sürümü MIT ile yayımladığınızda o sürüm için geri dönüş yoktur.
İzin verici lisanslar: en geniş yayılım, en az kontrol
MIT ve BSD-2/3-Clause yalnızca telif bildiriminin ve lisans metninin kodla birlikte taşınmasını şart koşar. Apache-2.0 bunlara üç önemli unsur ekler: her katkı verenden, kendi katkısını kapsayan açık bir patent lisansı; kodun patent ihlali oluşturduğunu ileri sürerek patent davası açan kişinin patent lisansını sona erdiren bir misilleme hükmü; ve atıf için NOTICE dosyası mekanizması. Ücretli ürününüzün satın alınmasını kolaylaştırmak için var olan bir SDK, istemci kütüphanesi veya entegrasyon için izin verici lisans neredeyse her zaman doğru tercihtir: amacınız mümkün olan en geniş kullanımdır ve koruduğunuz şey kodun kendisi değil, arkasındaki hizmettir. Bunun karşılığında bir rakip kodu alıp kapalı biçimde geliştirebilir ve hiçbir şeyi geri paylaşmayabilir. Bu risk sizin için önemliyse izin verici lisans size uygun değildir.
Copyleft: türev eserleri açık tutmak
MPL-2.0 dosya düzeyinde işler: değiştirilen dosyaların MPL ile yayımlanması gerekir, ama kod daha büyük bir eser içinde kapalı dosyalarla birleştirilebilir. LGPL, kütüphanenin kendisini açık tutarken kapalı kodun ona bağlanmasına izin verir. GPL-3.0, türev eser dağıtıldığında eserin tamamının GPL ile dağıtılmasını ister. AGPL-3.0 buna 13. maddeyi ekler: yazılımı değiştirip başkalarının ağ üzerinden onunla etkileşmesine imkân veren kullanıcı, bu kişilere kaynak kodu sunmak zorundadır. Böylece bulut sağlayıcılarının GPL yazılımını hiçbir şey dağıtmadan çalıştırmasına imkân veren “SaaS boşluğu” kapanır. Ürünü doğrudan kodun kendisi olan bir şirket için AGPL, açık kaynak lisansları arasında en güçlü korumayı sağlar: rakipler kodu kullanabilir, ama ancak kendi değişikliklerini yayımlayarak. Bunun bedeli daha dar bir yayılımdır. Pek çok kurumsal alıcı ve bulut pazar yerlerinin çoğu AGPL bileşenleri baştan reddeder; alıcının due diligence taraması da sizin AGPL sürümlerinizin yanı sıra yığınınızdaki her AGPL bağımlılığını işaretler.
Source-available: kod açık, iş modeli kapalı
Kodunu göstermek isteyen ama rakiplerine bedavaya barındırılan bir ürün sunmak istemeyen girişim sermayesi destekli şirketler en çok üç lisansı kullanıyor. MariaDB’nin geliştirdiği Business Source License 1.1 kaynak kodu yayımlar, ancak lisans verenin tanımladığı Additional Use Grant dışında kalan “üretim kullanımını” yasaklar. Her sürümden en geç dört yıl sonrasına konabilecek bir Change Date geldiğinde kod, lisans verenin belirlediği Change License’a (genellikle GPL veya Apache) kendiliğinden geçer. MongoDB’nin hazırladığı Server Side Public License 1.0, 13. maddesi genişletilmiş bir AGPL’dir: yazılımı hizmet olarak sunan herkesin, hizmet yığınının tamamının kaynak kodunu yayımlamasını ister; Open Source Initiative bu lisansı onaylamayı reddetti. Elastic License 2.0 ise izin verici lisanslara benzeyen, üç yasak içeren kısa bir metindir: yönetilen hizmet sunmak, lisans anahtarlarını aşmak ve bildirimleri kaldırmak yasaktır. Bu üç lisansın hiçbiri Açık Kaynak Tanımı’na göre “açık kaynak” değildir. Tanıtımda aksini söylemek hem topluluğun düzeltmesine yol açar hem de müşteriler nezdinde yanıltıcı tanıtım sorunu doğurur. Buna karşılık savunulabilir bir orta yol sunarlar: kullanıcılara şeffaflık ve kendi sunucularında barındırma imkânı, şirkete barındırılan hizmette tekel ve BUSL’de kodun belirli bir takvime göre açık kaynağa dönüşeceği güvencesi.
Katkı sözleşmeleri ve ileride fikir değiştirme hakkı
Dışarıdan katkı kabul ediyorsanız, birleşik eseri ileride yeniden lisanslayabilmeniz gerekir; örneğin AGPL’den BUSL’e geçmek ya da şirketi temiz bir hak zinciri bekleyen bir alıcıya satmak için. Bunun için iki araç vardır. Contributor License Agreement (CLA) ile her katkı veren, katkısını şirkete devreder veya geniş kapsamlı olarak lisanslar. FSEK açısından CLA’nın m.52’deki şartları karşılaması ve gerçek kişiler bakımından ispatlanabilir biçimde yazılı imza taşıması gerekir. Developer Certificate of Origin (DCO) ise daha hafif bir araçtır: katkı veren her commit’te, kodu proje lisansıyla sunma hakkına sahip olduğunu beyan eder. DCO şirkete yeniden lisanslama hakkı vermez. Ticari kontrolü elinde tutmak isteyen şirketler CLA’yı, topluluk projeleri ise DCO’yu tercih eder. Hangisini seçerseniz seçin, kimin neye katkı verdiğini kayıt altına alın; çünkü due diligence sırasında karşınıza çıkacak soru şu olacaktır: “Bu depodaki her satırın size lisanslandığını gösterebilir misiniz?”
Nasıl karar vermeli?
Sırasıyla üç soru sorun. Birincisi: Kod, ücretli bir ürünün yaygınlaşmasını sağlayan bir araç mı, yoksa ürünün ta kendisi mi? Yaygınlaşmaya hizmet eden araçlar için izin verici bir lisans seçilir; patentler önem taşıyabilecekse Apache-2.0. İkincisi: Güçlü finansmana sahip bir rakibin barındırılan bir kopya çıkarması, ürünün kendisi için gerçekçi bir tehdit mi? Cevap evetse AGPL-3.0 (açık kaynak, topluluğun benimsediği ama kurumsal alıcıları uzaklaştıran) ile BUSL-1.1 (açık kaynak değil, kurumsal alıcıların kabul edebildiği, zamanla açık kaynağa dönüşen) arasında seçim yapın. Üçüncüsü: Kodu tarayacak taraflardan yatırım almayı ya da onlara satış yapmayı planlıyor musunuz? Öyleyse seçiminizi belgeleyin, her dosya başlığında SPDX kimliği kullanın, bağımlılık envanterinin yanında kendi sürümlerinizin lisans envanterini de tutun ve gerekçenizi açıklamaya hazır olun. Bu dosyaya iki düzenleyici not da eklenmeli. AB Siber Dayanıklılık Yasası ((AB) 2024/2847 sayılı Tüzük), ticari olarak desteklenen açık kaynak yazılımı bir ürün olarak ele alıyor: zafiyet bildirim yükümlülükleri 11 Eylül 2026’dan itibaren uygulanıyor, yükümlülüklerin tamamı ise 11 Aralık 2027’den itibaren uygulanacak. Kod bir araç değil de bir model ise AI Act’in açık kaynak muafiyetinin sınırları da önem kazanıyor.
Şimdi MIT ile yayımlayıp ileride BUSL’e geçebilir miyiz?
Tüm haklar sizdeyse (kendi kodunuz ve CLA kapsamındaki katkılar) gelecek sürümlerin lisansını değiştirebilirsiniz. Ancak yayımlanmış sürümler için verdiğiniz MIT lisansını geri alamazsınız; herkes bu sürümleri MIT altında kullanmaya ve çatallamaya devam edebilir.
Lisans metninin Türkçe olması gerekir mi?
Hayır. FSEK lisans için belirli bir dil şartı aramaz; standart metinler de dünyanın her yerinde İngilizce olarak kullanılır. Bu metinleri çevirmeyin: çeviri ayrı bir metin olur ve SPDX kimlikleri orijinal metne atıf yapar.
İkili lisanslama hâlâ bir seçenek mi?
Evet. İkili lisanslama (topluluk için AGPL, AGPL’yi kabul edemeyen müşteriler için ticari lisans) hâlâ işleyen bir model. Tek şart, ticari lisans verme hakkına sahip olmanız; bu da yine dış katkılar için CLA gerektirir.
İlgili: copyleft · açık kaynak lisans yükümlülükleri · açık kaynak lisans rehberi.
Kaynak. 5846 sayılı Fikir ve Sanat Eserleri Kanunu (m.2, 14–16, 18, 48, 52); lisans metinleri için SPDX Lisans Listesi (MIT, BSD-3-Clause, Apache-2.0, MPL-2.0, LGPL-3.0, GPL-3.0, AGPL-3.0, BUSL-1.1, SSPL-1.0, Elastic-2.0); Open Source Initiative, Açık Kaynak Tanımı; (AB) 2024/2847 sayılı Tüzük (Siber Dayanıklılık Yasası).
Bu yazı genel bilgilendirme amacıyla hazırlanmıştır ve hukuki tavsiye niteliği taşımaz. Somut bir durumun değerlendirilmesi için hukuki destek alınmalıdır.
