Yazılımın kaynak kodu kime ait? Sözleşme, hak devri ve kaynak kod emaneti

Türkiye'de bir yazılımın kaynak kodu, aksi yazılı olarak kararlaştırılmadıkça kodu yazan tarafa aittir. 5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK) bilgisayar programlarını 2. maddesinde ilim ve edebiyat eserleri arasında sayar, yani kod telif hakkıyla korunur. Kodu bordronuzdaki bir yazılımcı yazdıysa 18. madde lehinize çalışır: memur, hizmetli ve işçilerin işlerini görürken meydana getirdikleri eserler üzerindeki hakları, aralarındaki özel sözleşmeden veya işin mahiyetinden aksi anlaşılmadıkça, onları çalıştıran kullanır. Kodu dışarıdan bir ajans ya da serbest çalışan geliştirici yazdıysa denklem tersine döner. Eser sahibi odur, faturayı siz ödemiş olsanız bile. Hakların size geçmesi için yazılı bir devir gerekir; o devrin nasıl kaleme alındığı da en az varlığı kadar belirleyicidir.

Sözleşmede madde olması kodun elinizde olduğu anlamına gelmez

Sahada en sık gördüğümüz tablo şu: sözleşmede "tüm fikri mülkiyet hakları müşteriye aittir" yazıyor ve herkes rahat. Sonra depo geliştiricinin kişisel GitHub hesabında duruyor, uygulama onun adına açılmış bir bulut hesabında çalışıyor, alan adı onun kredi kartıyla yenileniyor, derleme betiği ise yalnızca onun bilgisayarında sorunsuz çalışıyor. Hukuken haklısınız. Pratikte elinizde çalışan bir sistem ve onu ayağa kaldırmayı bilen tek bir kişi var. Bunlar iki ayrı sorundur ve ayrı ayrı çözülür: biri sözleşme metniyle, diğeri teslim ve erişim disipliniyle.

FSEK devir için ne arıyor

Mali hakların devri 48. maddede düzenlenir. Eser sahibi bu hakları süre, yer ve içerik bakımından sınırlı ya da sınırsız olarak, bedelli veya bedelsiz devredebilir. 49. madde bir sonraki halkayı bağlar: devraldığı hakkı ya da kullanma ruhsatını bir başkasına aktarmak isteyen taraf, eser sahibinin yazılı muvafakatine ihtiyaç duyar. Alt yükleniciyle çalışan ajanslarda bu madde çoğu zaman atlanır, oysa zincirin bir halkası kopuksa en sondaki devir de sağlam değildir.

Asıl kritik hüküm 52. maddedir: mali haklara dair sözleşme ve tasarrufların yazılı olması ve konuları olan hakların ayrı ayrı gösterilmesi şarttır. Bu iki koşuldan ikincisi sık sık ihmal edilir. "FSEK'ten doğan tüm mali haklar devredilmiştir" gibi toplu bir cümle, hakları ayrı ayrı göstermediği için tartışmaya açık hale gelir. Devredilen hakların adıyla sayılması gerekir: işleme, çoğaltma, yayma, temsil ve umuma iletim. Manevi haklar (eseri kamuya sunma, adın belirtilmesi, eserde değişiklik yapılmasını yasaklama) devredilemez; bunlar için ancak kullanım yetkisi verilebilir, o da yazıyla.

Sözleşmeye yazılması gerekenler

Yazılım geliştirme sözleşmesinde şu başlıkların hepsi ayrı ayrı yer almalı:

• Devredilen mali hakların tek tek sayılması, süre ve yer sınırı olmadığının açıkça belirtilmesi.
• Kaynak kodun, sürüm geçmişiyle birlikte teslim edileceği ve teslimin hangi olaylara bağlı olduğu (kabul, ödeme, sözleşme sonu).
• İşleme hakkının kapsamı: kodu başka bir tedarikçiye devrederek geliştirmeye devam etme yetkisi.
• Alt yüklenici ve serbest çalışan kullanılıyorsa, onlardan alınmış yazılı devirlerin ibrazı.
• Geliştiricinin kendi kütüphanelerini kullanması halinde bunların lisans durumu.
• Sözleşme sona erdiğinde devir ve geçiş süreci: kaç gün destek, hangi doküman, hangi hesaplar.

Teslim listesi: kod tek başına yetmez

Kaynak kodu almak, sistemi devralmak demek değildir. Gerçek bir teslim paketinde şunlar bulunur: deponun tüm sürüm geçmişiyle birlikte kopyası, derleme ve dağıtım betikleri, sürümleri sabitlenmiş bağımlılık dosyaları, veritabanı şeması ve göç (migration) betikleri, altyapı tanımları, ortam değişkenlerinin listesi (değerleri değil, adları ve ne işe yaradıkları), kullanılan üçüncü taraf servislerin ve hesapların dökümü, bir de sıfırdan kurulum dokümanı.

Bunun tek geçerli testi vardır: temiz bir makinede, geliştiriciye tek soru sormadan derleyip çalıştırabiliyor musunuz? Cevap hayırsa teslim tamamlanmamıştır. Kabul tutanağını bu testten önce imzalamayın.

Hesaplar kimin adına açıldı

Alan adı, DNS yönetimi, SSL sertifikaları, bulut aboneliği, uygulama mağazası hesapları, ödeme sağlayıcısı, e-posta altyapısı, hata izleme ve analitik araçları. Bunların her biri ya sizin kurumsal hesabınız altında olmalı ya da devri sözleşmede yazılı olmalı. Alan adının geliştiricinin şahsi hesabında kaldığı ve iletişim koptuğunda yenilenmediği için yayından düşen siteler, sektörde tekrar tekrar görülen bir hikâyedir.

Erişim bilgilerinin nasıl saklandığı da ayrı bir başlık. Depoya gömülmüş API anahtarları hem güvenlik açığı yaratır hem de devir sırasında hangi anahtarın nerede kullanıldığını takip etmeyi imkânsız hale getirir. Sır yönetimi rehberimizde bu konuyu ayrıntılı ele almıştık.

Açık kaynak bileşenler ve lisans riski

Özel yazılım diye teslim aldığınız projenin büyük bölümü, neredeyse her zaman açık kaynak kütüphanelerden oluşur. MIT, BSD ve Apache 2.0 gibi izin verici lisanslar ticari kullanımda genellikle sorun çıkarmaz. GPL ve özellikle AGPL ise farklıdır: AGPL, yazılıma ağ üzerinden erişilmesi halinde bile türev çalışmanın kaynak kodunun açılmasını gerektirebilir, yani bir SaaS ürününde dağıtım yapmasanız bile yükümlülük doğar.

Sözleşmeye tedarikçinin kullandığı üçüncü taraf bileşenlerin listesini (SBOM, yazılım malzeme listesi) ve lisans uyumu beyanını koyun. Bu liste, satın alma ve yatırım süreçlerinde teknik incelemenin ilk istediği belgelerden biridir. Bağımlılıkların yarattığı diğer riskler için yazılım tedarik zinciri güvenliği yazımıza bakabilirsiniz.

Kaynak kod emaneti (escrow) ne zaman mantıklı

Bazı durumlarda tedarikçi kaynak kodu vermez ve bu makul olabilir: ürünü birçok müşteriye satan bir yazılım firmasından söz ediyorsanız, kod onun ticari varlığıdır. Bu noktada kaynak kod emaneti devreye girer. Kod bağımsız bir üçüncü tarafa (escrow kuruluşu) yatırılır ve yalnızca sözleşmede sayılan olaylar gerçekleşirse size açılır. Standart tetikleyiciler iflas, tasfiye, faaliyetin durması ve sözleşmede taahhüt edilen bakım-destek hizmetinin verilmemesidir.

Escrow'un en sık görülen başarısızlık biçimi teknik değil, ihmaldir. Kod sözleşme imzalanırken bir kez yatırılır, bir daha güncellenmez ve hiç doğrulanmaz. Yıllar sonra tetikleyici olay gerçekleştiğinde açılan pakette eski bir sürüm, eksik bağımlılıklar ve derleme betiği olmadan çalışmayan bir kod yığını çıkar. Bunu önlemenin yolu iki maddeyi sözleşmeye yazmaktır: yatırma sıklığı (ürün ne sıklıkta değişiyorsa ona bağlı bir takvim) ve doğrulama hakkı (emanetteki paketin gerçekten derlenip çalıştığının, yılda kaç kez ve kimin masrafıyla test edileceği).

SaaS alıyorsanız escrow tek başına yetmez

Barındırılan bir hizmette kaynak kodu almak size pek yaramaz, çünkü asıl ihtiyacınız veri ve çalışır bir ortamdır. Burada sözleşmeye bakılacak yer çıkış maddesidir: hizmet sona erdiğinde verinizi hangi formatta (kapalı bir yedek değil, işlenebilir bir dışa aktarım), ne kadar sürede ve kaç kez alabileceğiniz. Verinin ne kadar süre saklanacağı ve ne zaman silineceği de yazılı olmalı; bu aynı zamanda KVKK açısından veri işleyenle aranızdaki sözleşmenin konusudur. Kurulum modeline göre sorumluluk sınırlarının nasıl değiştiğini paylaşılan sorumluluk modeli yazımızda anlatmıştık.

Kaynak kod elinizde yoksa kanunun tanıdığı hareket alanı dar

FSEK'in 38. maddesi, programı hukuka uygun yoldan edinmiş kişiye bazı yetkiler tanır: programın çalışması için gerekli yedek kopyayı almak (bu hak sözleşmeyle kısıtlanamaz), programı yüklemek, çalıştırmak ve hataları düzeltmek. Birlikte çalışabilirlik için gereken arayüz bilgilerine ulaşmak amacıyla kodun çoğaltılmasına da sınırlı bir izin vardır. Ancak bu istisna yalnızca birlikte çalışabilirlik amacıyla sınırlıdır; elde edilen bilginin başka amaçla kullanılması veya üçüncü kişilere aktarılması ihlal sayılır. Kısacası bu maddeler bir devir planının yerini tutmaz, sadece en kötü senaryoda hareket alanı bırakır.

Bir günlük tatbikat

Mevcut yazılım tedarikçilerinizle ilişkiniz iyi giderken şu üç soruyu cevaplayın. Birincisi: bu projenin mali haklarını devreden yazılı bir belge var mı, haklar orada tek tek sayılmış mı? İkincisi: bugün kaynak kodun tam bir kopyasını istesem, temiz bir makinede derleyip çalıştırabilir miyim? Üçüncüsü: alan adı, bulut hesabı ve ödeme sağlayıcısı hangi isme kayıtlı? Üçüne de net cevap veremiyorsanız, sorun tedarikçinizin niyetiyle ilgili değildir, sadece henüz kimse bu soruları sormamıştır. Hazır paket mi özel yazılım mı kararını verirken de bu üç soruyu masaya koymakta fayda var.