Yazılım Geliştirme Sözleşmesi: Kabul, Ayıp ve Kaynak Kod

Bir şirket, sipariş üzerine geliştirilen bir yazılımın bedelini öder, sistemi kullanmaya başlar ve aylar sonra ciddi bir performans sorunuyla karşılaşır. Geliştiriciye başvurduğunda iki cevaptan biriyle karşılaşması muhtemeldir: "yazılım teslim edildi ve kabul edildi" ya da "bu kapsam dışında, ek geliştirme gerekir". Aynı şirket bir süre sonra çalıştığı geliştiriciyle yollarını ayırmak istediğinde üçüncü bir sürprizle karşılaşır: kaynak kod elinde değildir ve sözleşmede bu konuda açık bir hüküm bulunmamaktadır.

Bu üç sorunun ortak noktası, sözleşmenin imzalandığı aşamada birkaç cümleyle önlenebilecek olmasıdır. Türk hukukunda sipariş üzerine yazılım geliştirme ilişkisi, Türk Borçlar Kanunu'nun eser sözleşmesine ilişkin hükümleriyle Fikir ve Sanat Eserleri Kanunu'nun mali hakların devrine ilişkin hükümlerinin kesiştiği bir alanda yer alır. Bu yazı, kabul, ayıp, zamanaşımı ve kaynak kod başlıklarını birbirine bağlı tek bir zincir olarak ele almaktadır.

Yazılım geliştirme sözleşmesi hangi sözleşme tipidir?

Nitelendirme, sonraki bütün soruların cevabını belirlediği için ilk adımdır. Müşterinin belirlediği bir şartnameye göre, belirli bir bedel karşılığında ve bağımsız çalışan bir geliştirici tarafından üretilen yazılım, kural olarak eser (istisna) sözleşmesi kapsamında değerlendirilir. Yüklenici bir sonuç taahhüt eder; ortaya çıkan yazılımın sözleşmede kararlaştırılan nitelikleri taşıması gerekir.

Bu nitelendirme her yazılım ilişkisi için geçerli değildir. Hazır bir yazılımın abonelik karşılığı kullanıma sunulduğu SaaS modeli, sonuç taahhüdü içeren bir eser ilişkisi değildir; burada süreklilik arz eden bir kullandırma ilişkisi söz konusudur ve ayıp, kabul, zamanaşımı gibi başlıklar farklı işler. Aynı şekilde, müşterinin talimat ve denetimi altında, işyerine bağlı olarak çalışan bir geliştiriciyle kurulan ilişki iş sözleşmesi niteliğindedir. Aradaki fark yalnızca etiket meselesi değildir; aşağıda ele alınan hak sahipliği sonuçlarını doğrudan değiştirir.

Teslim ile kabul aynı şey değildir

Uygulamadaki en pahalı yanlış anlama budur. Yazılımın müşterinin kullanımına sunulması teslim, müşterinin bunu sözleşmeye uygun bulduğunu ortaya koyması ise kabultür. İkisi arasında, işsahibinin üzerine düşen bir külfet vardır.

Türk Borçlar Kanunu'nun 474. maddesi uyarınca işsahibi, eserin tesliminden sonra işlerin olağan akışına göre imkân bulur bulmaz eseri gözden geçirmek ve varsa ayıpları uygun bir süre içinde yükleniciye bildirmekle yükümlüdür. Bu bir borç değil, külfettir: yerine getirilmemesi bir tazminat sorumluluğu doğurmaz, ancak hak kaybına yol açar. Açık ayıplar süresinde bildirilmezse eser örtülü olarak kabul edilmiş sayılır ve bu ayıplara dayalı talepler ileri sürülemez hâle gelir.

Kabulün gerçekleşmesiyle birlikte yüklenici, ağır kusuruyla gizlediği ayıplar dışında sorumluluktan kurtulur. Sonradan ortaya çıkan gizli ayıplar bakımından ise 477. madde devreye girer: gizli ayıp, ortaya çıkar çıkmaz yükleniciye bildirilmelidir.

Kabul testi sözleşmede nasıl kurgulanır?

Kanun "uygun süre" der ve bir gün sayısı vermez. Sözleşme bu boşluğu doldurmadığında süre uyuşmazlık hâlinde takdir edilir; bu da her iki taraf için öngörülemezlik demektir. Sözleşmede kabul testi (UAT) düzenlenirken en az şu noktaların yazılı olması beklenir: testin süresi, kabul kriterlerinin ölçülebilir biçimde tanımı, kısmi teslimlerde her modülün ayrı ayrı mı yoksa bütün hâlinde mi kabul edileceği, test süresince sessiz kalınmasının sonucu ve düzeltme sonrası testin yeniden başlayıp başlamayacağı.

Tabloda dikkat çekilmesi gereken pratik nokta, üçüncü satırdadır. Sözleşmelerde ödeme aşamaları çoğu zaman "kabul" kelimesine bağlanır. Ödeme yapılabilmesi için imzalanan bir tutanak, ayıp bakımından da kabul anlamına gelecek şekilde kaleme alınmışsa, muhasebe gerekçesiyle atılan bir imza hukuki hak kaybına dönüşebilir. Ödeme onayı ile teknik kabulün sözleşmede ayrı ayrı tanımlanması bu riski ortadan kaldırır.

Yazılımda "ayıp" nedir?

Ayıp, eserin sözleşmede kararlaştırılan veya dürüstlük kuralı gereği beklenen nitelikleri taşımamasıdır. Yazılım bakımından bunun kapsamı, günlük dildeki "hata" kavramından hem dar hem geniştir.

• Şartnamede yer alan bir işlevin bulunmaması veya çalışmaması açık bir ayıptır.
• Kararlaştırılmış performans eşiklerinin — eşzamanlı kullanıcı sayısı, yanıt süresi — karşılanmaması ayıptır.
• Sözleşmede öngörülen ortamda çalışmama, entegrasyonun kurulamaması ayıptır.
• Güvenlik açıkları, sözleşmede bir güvenlik standardı kararlaştırılmışsa ayıp oluşturur; kararlaştırılmamışsa değerlendirme dürüstlük kuralı üzerinden yapılır.
• Buna karşılık her yazılım hatası ayıp değildir. Kabul edilen bir hata payı içinde kalan, kullanımı engellemeyen kusurlar ayıp sayılmayabilir.

Ayıbın işsahibinin verdiği talimattan veya sağladığı malzemeden kaynaklanması hâlinde yüklenicinin sorumluluğu gündeme gelmez; ancak yüklenicinin bu konuda uyarma yükümlülüğü bulunduğu kabul edilir. Yazılım hatalarından doğan sorumluluğun ürün sorumluluğu boyutu ve sorumsuzluk kayıtlarının geçerliliği, yazılım hatalarında hukuki sorumluluk yazımızda ayrıca ele alınmıştır.

Ayıp hâlinde işsahibinin seçimlik hakları

Türk Borçlar Kanunu'nun 475. maddesi, ayıplı eser karşısında işsahibine üç seçimlik hak tanır: eserin ayıbı çok ağırsa ve kabule zorlanamayacak nitelikteyse sözleşmeden dönme; ayıp oranında bedelden indirim; aşırı bir masrafı gerektirmiyorsa ücretsiz onarım. Bu haklara ek olarak yüklenicinin kusuru varsa tazminat da istenebilir.

Yazılım projelerinde pratik olarak en çok kullanılan seçenek ücretsiz onarımdır; sözleşmeden dönme ise nadiren gerçekçidir, çünkü işletme çoğu zaman yazılıma bağımlı hâle gelmiştir. Bu nedenle sözleşmede onarım için azami süre, süre aşıldığında devreye girecek ceza koşulu ve onarımın başarısız kalması hâlinde izlenecek yol belirlenmelidir.

Seçimlik hakkın kullanılması tek taraflı bir irade beyanıdır; kural olarak kullanıldıktan sonra dönülemez. Bu nedenle hangi hakkın seçileceğine, teknik değerlendirme tamamlanmadan karar verilmemelidir.

Zamanaşımı: yazılımda süre beş yıl değil, iki yıldır

Eser sözleşmesi denildiğinde refleks olarak beş yıllık bir zamanaşımından söz edilir. Bu, yazılım bakımından yanlıştır.

Türk Borçlar Kanunu'nun 478. maddesi, ayıplı eser sebebiyle açılacak davaların teslim tarihinden başlayarak taşınmaz yapılar dışındaki eserlerde iki yılın, taşınmaz yapılarda beş yılın, yüklenicinin ağır kusuru varsa ayıplı eserin niteliğine bakılmaksızın yirmi yılın geçmesiyle zamanaşımına uğrayacağını düzenler. Yazılım bir taşınmaz yapı olmadığına göre uygulanacak süre iki yıldır.

Bu ayrımın iki pratik sonucu vardır. Birincisi, uzun soluklu kurumsal yazılım projelerinde iki yıl kısa bir süredir; ciddi bir mimari sorun çoğu zaman ikinci yılın sonuna doğru görünür hâle gelir. İkincisi, sözleşmeye yazılan garanti süresi ile zamanaşımı farklı kavramlardır. Sözleşmesel garanti tarafların anlaşmasıyla belirlenir; zamanaşımı ise dava açma hakkının süresidir. Bir yıllık garanti verilmiş olması, iki yıllık zamanaşımını kısaltmaz; üç yıllık garanti verilmiş olması da tek başına dava süresini uzatmaz. Bu iki sürenin sözleşmede ayrı ayrı ve bilinçli olarak düzenlenmesi gerekir.

Kaynak kod: bedel ödendi diye devredilmiş olmaz

Bilgisayar programları, Fikir ve Sanat Eserleri Kanunu kapsamında ilim ve edebiyat eseri olarak korunur. Buradan doğan sonuç, çoğu şirketin beklentisinin tersinedir: yazılımın bedelinin ödenmiş olması, eser üzerindeki mali hakların müşteriye geçtiği anlamına gelmez.

Kanun'un 48. maddesinin birinci fıkrası, mali hakların süre, yer ve içerik itibarıyla sınırlı veya sınırsız olarak devredilebileceğini düzenler. 52. maddesi ise şekil bakımından belirleyicidir: mali haklara ilişkin sözleşme ve tasarrufların yazılı olması ve konuları olan hakların ayrı ayrı gösterilmesi şarttır. "Tüm haklar müşteriye aittir" biçimindeki genel bir cümle, hakların ayrı ayrı gösterilmesi şartını karşılamadığı gerekçesiyle tartışmaya açıktır.

Uygulamada sözleşmeye yazılması beklenen asgari içerik şudur: hangi mali hakların (işleme, çoğaltma, yayma, temsil, umuma iletim) devredildiği tek tek sayılmalı; devrin süresi, yer bakımından kapsamı ve münhasır olup olmadığı belirtilmeli; kaynak kodun yanı sıra derleme ortamı, bağımlılık listesi ve teknik dokümantasyonun da teslim edileceği ayrıca kararlaştırılmalıdır. Kaynak kodun teslimi ile mali hakların devri ayrı meselelerdir: kodu elinde bulundurmak, onu değiştirme ve çoğaltma hakkına sahip olmak anlamına gelmez.

Ayrıca yazılımın içerdiği üçüncü taraf ve açık kaynak bileşenlerin beyan edilmesi istenmelidir. Lisans koşulları, müşterinin yazılımı kullanma ve dağıtma biçimini sınırlandırabilir.

Son yıllarda bu beyan yükümlülüğüne yeni bir boyut eklenmiştir: geliştirme sürecinde üretken yapay zekâ araçlarının kullanılıp kullanılmadığı. Bu araçlarla üretilen kod parçalarının hak sahipliği ve lisans uyumu bakımından doğurabileceği belirsizlikler, sözleşmede geliştiriciden bu konuda beyan alınmasını makul kılar. Kurum içinde denetimsiz yapay zekâ kullanımının yarattığı riskler için gölge yapay zekâ riskine ilişkin yazımıza bakılabilir.

Bağımsız geliştiriciyle çalışırken hak sahipliği

Fikir ve Sanat Eserleri Kanunu'nun 18. maddesinin ikinci fıkrası, aralarındaki özel sözleşmeden veya işin mahiyetinden aksi anlaşılmadıkça, memur, hizmetli ve işçilerin işlerini görürken meydana getirdikleri eserler üzerindeki hakların bunları çalıştıran veya tayin edenlerce kullanılacağını düzenler.

Bu hükmün, eser sözleşmesiyle çalışan bağımsız bir yükleniciye ne ölçüde uygulanacağı öğretide tartışmalıdır. Bu nedenle bağımsız geliştiriciyle veya ajansla çalışan bir şirketin, hak sahipliğini kanun hükmünün yorumuna bırakmak yerine 52. maddeye uygun yazılı bir devir hükmüne dayandırması güvenli yoldur. Serbest çalışan geliştiricilerle yürütülen projelerde, bu hükmün sözleşmede bulunmaması sık karşılaşılan bir eksikliktir.

Alt yüklenici kullanılan projelerde zincirin tamamının kontrol edilmesi gerekir: ana yükleniciyle imzalanan devir hükmü, alt yüklenicinin ürettiği bölümler bakımından ancak ana yüklenici o hakları usulünce edinmişse sonuç doğurur.

Kaynak kod emaneti (escrow): geliştirici ortadan kalkarsa

Kaynak kodun müşteriye baştan teslim edilmesi her zaman ticari olarak kabul edilebilir değildir; geliştirici açısından kaynak kod ticari sırrın kendisidir. Bu gerilimin uygulamadaki çözümü kaynak kod emanetidir.

Emanet ilişkisi üç taraflıdır: yazılımı geliştiren taraf, müşteri ve tarafsız bir emanetçi. Geliştirici kaynak kodun güncel sürümünü emanetçiye teslim eder; kod, ancak sözleşmede önceden belirlenmiş teslim koşulları gerçekleştiğinde müşteriye açılır. Yaygın teslim koşulları arasında geliştiricinin sözleşmeden doğan bakım ve destek yükümlülüklerini yerine getirmemesi, kilit personelin desteğini kesmesi ve geliştirici şirketin iflası yer alır.

Türk hukukunda kaynak kod emanetine ilişkin özel bir kanuni düzenleme bulunmamaktadır; ilişki, tarafların iradesiyle şekillenen ve saklama ile vekâlet ilişkilerinden yararlanılarak kurulan kendine özgü bir sözleşmedir. Bu belirsizlik, sözleşme metninin özenle kaleme alınmasını daha da önemli kılar.

Türkiye'de bu hizmet kurumsal olarak da sunulmaktadır. Türk Standardları Enstitüsü, sayısal kaynak kod emanetçiliği hizmeti kapsamında yazılımın son sürümünün AES-256 ile şifrelenerek güvenli sunuculara yüklenmesini ve proje geliştirmesi tamamlandığında dosyaların değiştirilemez hâle getirilmesini öngörmektedir.

Uygulamada dikkat edilmesi gereken üç nokta vardır. Emanete konulan kodun güncelliği düzenli olarak denetlenmelidir; yıllar önceki bir sürüm işe yaramaz. Emanet, kaynak kodla birlikte derleme talimatlarını ve bağımlılıkları da kapsamalıdır. Son olarak, emanet sözleşmesinin geliştiricinin iflası hâlinde iflas masasına karşı ne ölçüde ileri sürülebileceği tartışmalı bir konudur; bu ihtimalin sözleşme kurgusunda göz önünde bulundurulması yerinde olur.

Sözleşmede atlanmaması gereken sekiz başlık

1. Kapsam ve teknik şartname — değişiklik yönetimi prosedürüyle birlikte; kapsam dışı taleplerin nasıl fiyatlanacağı dâhil.
2. Teslim ve kabul testi — test süresi, ölçülebilir kabul kriterleri, sessiz kalmanın sonucu, düzeltme sonrası tekrar testi.
3. Ayıp ihbarı usulü — yazılı şekil şartı, bildirimin hangi kanaldan yapılacağı, gizli ayıplarda bildirim yükümlülüğü.
4. Garanti süresi ve zamanaşımının ayrı düzenlenmesi — ikisinin farklı kavramlar olduğunun metne yansıtılması.
5. Mali hakların devri — devredilen hakların tek tek sayıldığı, süre ve yer kapsamının belirtildiği yazılı hüküm.
6. Kaynak kod, dokümantasyon ve derleme ortamının teslimi — teslim zamanı ve biçimi.
7. Kaynak kod emaneti — emanetçi, güncelleme sıklığı ve teslim koşulları.
8. Üçüncü taraf ve açık kaynak bileşen beyanı — lisans uyumu ve müşterinin kullanım kapsamına etkisi.

Yazılımın kişisel veri işlediği projelerde bu listeye veri koruma hükümleri de eklenir; geliştiricinin veri işleyen sıfatıyla üstleneceği yükümlülükler için veri sorumlusu – veri işleyen ayrımına ilişkin yazımıza bakılabilir.

Kritik altyapıya yazılım sağlayanlar için yeni bir katman

19.03.2025 tarihli ve 32846 sayılı Resmî Gazete'de yayımlanan 7545 sayılı Siber Güvenlik Kanunu, kritik altyapılarda kullanılan siber güvenlik ürün, sistem ve hizmetlerinin Siber Güvenlik Başkanlığınca yetkilendirilmiş ve belgelendirilmiş sağlayıcılardan temin edilmesini öngörmektedir.

Siber Güvenlik Kurulu'nun 5 Mayıs 2026 tarihli toplantısında kritik altyapı sektörleri belirlenmiş; dijital altyapılar, dijital hizmetler, elektronik haberleşme, enerji, finans, gıda ve tarım, imalat sanayi, kamu hizmetleri, medya ve kriz iletişimi, posta ve kargo, sağlık, savunma sanayii, su yönetimi, ulaştırma ve uzay olmak üzere on beş sektör bu kapsama alınmıştır.

Bu sektörlere yazılım veya hizmet sağlayan şirketler bakımından sonuç, tedarik sözleşmelerine yeni bir uygunluk katmanının eklenmesidir. Sözleşmelerde yetkilendirme ve belgelendirme durumuna ilişkin beyan ve taahhütlerin, bu durumun sonradan değişmesi hâlinde uygulanacak sonuçların ve denetim yükümlülüklerinin düzenlenmesi gündeme gelmektedir.

Kaynaklar

• 6098 sayılı Türk Borçlar Kanunu — mevzuat.gov.tr
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu — mevzuat.gov.tr
• 7545 sayılı Siber Güvenlik Kanunu — 19.03.2025 tarihli ve 32846 sayılı Resmî Gazete
• Escrow – Sayısal Kaynak Kod Emanetçiliği Hizmeti — Türk Standardları Enstitüsü

Sık sorulan sorular