GPL bulaşması yazımız ürününüze giren kodla ilgiliydi. Bu yazı dışarı verdiğiniz kodla ilgili: müşteriler daha hızlı entegre olsun diye yayımladığınız SDK, geliştirici topluluğu kurmak için açtığınız çekirdek, iyi pazarlama olduğu için paylaştığınız iç araç. Bir Türk şirketi kaynak kodu yayımladığı anda dünyaya bir lisans verir ve lisans metni şunları belirler: rakip bir barındırılan sürümü kim işletebilir, katkı verenlerin patentleri kapsanıyor mu, şirket kodu bir gün yeniden kapatabilir mi ve bir alıcının due diligence ekibi tarama çalıştırdığında kod nasıl sınıflandırılır. Seçim dört aile arasındadır: izin verici (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 hiç açık kaynak olmayan source-available lisanslar (BUSL-1.1, SSPL-1.0, Elastic License 2.0). Bu yazı her ailenin neyi verip neyi sakladığını, seçimin Türk telif hukukuyla nasıl etkileştiğini ve nasıl karar verileceğini anlatıyor. Kanonik metinler ve SPDX kimlikleri açık kaynak lisans rehberimizde toplu hâlde.
Türk hukukuna göre fiilen ne veriyorsunuz?
5846 sayılı Fikir ve Sanat Eserleri Kanunu’na (FSEK) göre yazılım korunan bir eserdir (m.2/1) ve mali haklar eser sahibindedir. Açık kaynak lisansı FSEK terimiyle bir ruhsattır: mali hakları devretmeden kullanma yetkisi verir (m.48/2). m.52, bu tür tasarrufların yazılı olmasını ve verilen hakların ayrı ayrı gösterilmesini şart koşar. İyi yazılmış lisanslar bunu doğal olarak yapar: 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 çoğaltma, türev eser hazırlama, umuma gösterme, dağıtma ve Apache’de bir patent lisansını açıkça yazar. Ev yapımı bir “kullanımı serbesttir” notu genellikle bunu yapmaz; kendi metninizi yazmak yerine standart bir metin seçmenin ilk gerekçesi budur.
Türk hukukunun iki özelliği analizi şekillendirir. Manevi haklar (m.14–16) gerçek kişi eser sahiplerinde kalır ve devredilemez; dolayısıyla lisanslardaki atıf ve yanlış tanıtmama koşulları Türk hukukuyla uyumludur, ama şirket önce lisansladığı mali haklara sahip olmalıdır: çalışanın kodu m.18/2 uyarınca işverene geçer, kurucunun veya yüklenicinin kodu yalnızca yazılı devirle; bunu fikri mülkiyetin şirkete geçişi yazısında anlattık. İkincisi, açık kaynak metniyle dünyaya verilen lisans uygulamada geri alınamaz: metinler bunu söyler ve FSEK, belirtilen şartlarla verilmiş bir ruhsatı geri çekmek için, ruhsat sahibinin hakları kullanmaması hâline özgü m.58 cayma hakkı dışında, genel bir hak tanımaz. MIT ile yayımlamak, yayımlanan sürüm için tek yönlü bir kapıdır.
İzin verici aile: azami yayılım, asgari kontrol
MIT ve BSD-2/3-Clause yalnızca telif notunun ve lisans metninin kodla birlikte taşınmasını ister. Apache-2.0 üç değerli şey ekler: her katkı verenden kendi katkısını kapsayan açık bir patent lisansı, kodun patent ihlali oluşturduğu iddiasıyla patent davası açanın patent lisansını sona erdiren bir patent 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 hemen her zaman doğrudur: en geniş kullanımı istersiniz ve koruduğunuz şey kodun kendisi değil, arkasındaki hizmettir. Bedeli, bir rakibin kodu alıp özel olarak geliştirip hiç paylaşmayabilmesidir; bu risk önemliyse aradığınız izin verici bir lisans değildir.
Copyleft: türevleri açık tutmak
MPL-2.0 dosya düzeyinde çalışır: değiştirilen dosyalar MPL ile yayımlanmalıdır, ama kod daha büyük bir eserde özel dosyalarla birleştirilebilir. LGPL, kütüphanenin kendisini açık tutarken özel koddan bağlanmaya izin verir. GPL-3.0, türev eserin tümünün dağıtıldığında 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 etkileşmesine izin veren kullanıcı onlara kaynağı sunmak zorundadır; bulut sağlayıcılarının GPL yazılımı hiçbir şey dağıtmadan işlettiği “SaaS boşluğu” böylece kapanır. Ürünü kodun kendisi olan şirket için AGPL mevcut en güçlü açık kaynak konumudur: rakipler kullanabilir, ama yalnızca değişikliklerini yayımlayarak. Bedeli yayılımdır. Birçok kurumsal alıcı ve bulut pazar yerlerinin çoğu AGPL bileşenleri doğrudan reddeder ve alıcının due diligence taraması kendi AGPL sürümleriniz kadar yığınınızdaki her AGPL bağımlılığını da işaretler.
Source-available: açık kod, kapalı iş modeli
Kodunu göstermek ama rakiplere bedava barındırılan ürün vermemek isteyen girişim sermayeli şirketler üç lisansı yaygın kullanıyor. MariaDB’nin yarattığı Business Source License 1.1 kaynağı yayımlar ama lisans verenin tanımladığı Additional Use Grant dışındaki “üretim kullanımını” yasaklar; her sürümden en fazla dört yıl sonra gelebilecek bir Change Date’te kod, lisans verenin belirlediği bir Change License’a (tipik olarak GPL veya Apache) kendiliğinden dönüşür. MongoDB’nin yazdığı Server Side Public License 1.0, 13. maddesi genişletilmiş bir AGPL’dir: yazılımı hizmet olarak sunan herkesin tüm hizmet yığınının kaynağını yayımlamasını ister; Open Source Initiative onaylamayı reddetti. Elastic License 2.0 ise üç yasaklı kısa, izin verici tarzda bir metindir: yönetilen hizmet yok, lisans anahtarlarını aşma yok, notları kaldırma yok. Üçü de Açık Kaynak Tanımı’na göre “açık kaynak” değildir; pazarlamada aksini söylemek topluluktan düzeltme ve müşteriler nezdinde yanlış tanıtım sorunu davet eder. Sundukları şey savunulabilir bir orta yoldur: kullanıcılar için şeffaflık ve kendi sunucusunda barındırma, şirket için barındırılan hizmet tekeli ve BUSL’de kodun belirli bir takvimde açık kaynağa dönüşeceği vaadi.
Katkı sözleşmeleri ve fikir değiştirme hakkı
Dışarıdan katkı kabul ediyorsanız birleşik eseri sonradan yeniden lisanslama hakkına ihtiyacınız var; örneğin AGPL’den BUSL’e geçmek veya şirketi temiz bir hak zinciri isteyen alıcıya satmak için. İki araç var. Contributor License Agreement (CLA), her katkı verenin katkısını şirkete devretmesini veya geniş biçimde lisanslamasını sağlar; FSEK’e göre m.52’yi karşılamalı ve gerçek kişiler için ispat edebileceğiniz biçimde yazılı imza taşımalıdır. Developer Certificate of Origin (DCO) ise her commit’te katkı verenin kodu proje lisansıyla sunma hakkına sahip olduğunu beyan ettiği daha hafif bir onaydır; şirkete yeniden lisanslama hakkı vermez. Ticari kontrolü elde tutmak isteyen şirketler CLA’yı, topluluk projeleri DCO’yu seçer. Her durumda kimin neye katkı verdiğini kayıt altına alın; çünkü due diligence sorusu “bu depodaki her satırın size lisanslandığını gösterebilir misiniz?” olacaktır.
Nasıl karar verilir?
Sırayla üç soru sorun. Kod, ücretli bir ürünün yayılımını sürükleyen bir araç mı, yoksa ürünün kendisi mi? Yayılım araçları izin verici gider; patentler önemli olabilecekse Apache-2.0. İyi finanse edilmiş bir rakibin barındırılan klonu ürünün kendisi için gerçekçi bir tehdit mi? Evetse AGPL-3.0 (açık kaynak, topluluk dostu, kurumsal alıcıya itici) ile BUSL-1.1 (açık kaynak değil, kurumsal alıcının katlanabildiği, sonradan dönüşen) arasında seçim yapın. Kodu tarayacak taraflardan yatırım almayı veya onlara satmayı planlıyor musunuz? O zaman seçimi belgeleyin, her dosya başlığında SPDX kimliği kullanın, bağımlılık envanterinin yanında kendi sürümlerinizin lisans envanterini tutun ve nedenini açıklamaya hazır olun. O dosyaya iki düzenleyici dipnot da girmeli: AB Siber Dayanıklılık Yasası ((AB) 2024/2847 sayılı Tüzük) ticari olarak desteklenen açık kaynak yazılımı, 11 Eylül 2026’dan itibaren uygulanan zafiyet bildirim yükümlülükleri ve 11 Aralık 2027’den itibaren tam yükümlülükler taşıyan bir ürün olarak ele alıyor; AI Act’in açık kaynak muafiyetinin sınırları ise kod bir araç değil bir modelse önem kazanıyor.
Şimdi MIT ile yayımlayıp sonra BUSL’e geçebilir miyiz?
Tüm haklara sahipseniz (kendi kodunuz artı CLA kapsamındaki katkılar) gelecek sürümlerin lisansını değiştirebilirsiniz. Yayımlanmış sürümler için MIT lisansını geri alamazsınız; herkes o sürümleri MIT altında kullanmaya ve çatallamaya devam edebilir.
Türkçe lisans metni gerekir mi?
Hayır. FSEK lisans için belirli bir dil şart koşmaz ve standart metinler dünya çapında İngilizce kullanılır. Çevirmeyin: çeviri farklı bir metindir ve SPDX kimlikleri orijinale 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) işleyen bir model olmayı sürdürüyor; ticari lisans verme hakkına sahip olmanız şartıyla, ki bu yine dış katkılar için CLA demektir.
İ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.
Yazar
Bu konu masanızdaysa
Kurucu Akademisi'nde şablonlar ve kontrol listeleri ücretsiz; spesifik bir durum için 30 dakikalık ön görüşme planlayabilirsiniz.
Kurucu AkademisiGörüşme planlayın