Yazılım Eser Sözleşmelerinde Hukuki Yorum ve Dürüstlük Kuralı
1. Giriş: Yazılım Projelerinde Sözleşmesel İrade ve Hukuki Sınırlar
Yazılım geliştirme projelerinde karşılaşılan temel hukuki uyuşmazlıklar, yazılım mühendisliğinin doğası gereği dinamik ve esnek yapısı ile sözleşme hukukunun şekli ve bağlayıcı ilkeleri arasındaki uyumsuzluktan kaynaklanmaktadır. Müşteri (iş sahibi) veya yüklenici (yazılım geliştirici) tarafında uygulamada sıklıkla düşülen en yaygın yanılgı; sözleşmeye konulan her cümlenin, altına imza atıldığı gerekçesiyle mutlak ve koşulsuz bir biçimde uygulanabileceği düşüncesidir. "Sözleşmeye bu maddeyi yazdırdık, artık kaçamazlar" ya da "Metinde 'her türlü hata ve eksiklik giderilecektir' yazıyor, dolayısıyla her talebimizi karşılamak zorundalar" şeklindeki yaklaşımlar, Türk borçlar hukuku mantığıyla her zaman bağdaşmamaktadır.
Hukuk tekniği açısından, tarafların serbest iradeleriyle kaleme aldıkları her sözleşme maddesi mahkeme önünde doğrudan geçerlilik kazanmaz. Türk Borçlar Kanunu (TBK) ve Yargıtay'ın yerleşik içtihatları; tarafların basiretli hareket etme yükümlülüğünü esas almakla birlikte, taraflardan birini ticari yıkıma sürükleyen, aşırı ağır, dürüstlük kuralına aykırı veya edimler arasındaki dengeyi katı bir biçimde bozan maddeleri geçersiz kılan veya revize eden hukuki süzgeçlere sahiptir.
2. Yargıtay İçtihatları Işığında Temel Hukuki İlkeler
Yargıtay içtihatlarında, ısmarlama yazılım geliştirme sözleşmeleri ağırlıklı olarak Türk Borçlar Kanunu'nun 470 ve devamı maddelerinde düzenlenen Eser Sözleşmesi veya bünyesinde hem eser hem de hizmet unsurlarını barındıran Karma Sözleşme niteliğinde kabul edilmektedir. Bu nitelendirme gereğince, yazılım uyuşmazlıklarında yargılama makamlarınca esas alınan temel hukuk ilkeleri şu şekilde özetlenebilir:
Dürüstlük Kuralı ve Hakkın Kötüye Kullanılması Yasağı (TMK m. 2)
Sözleşme metninde taraflardan birine tek taraflı, geniş veya ucu açık bir hak tanınmış olsa dahi, bu hakkın karşı tarafı ticari olarak kilitlenmeye sürükleyecek, faaliyetini felç edecek veya amacını aşacak şekilde kullanılması hukuken korunmaz. Türk Medeni Kanunu'nun 2. maddesinde düzenlenen dürüstlük kuralı, sözleşme maddelerinin uygulanmasında bağlayıcı bir üst sınır oluşturur.
Basiretli Tacir Yükümlülüğü ve Hakkaniyet Denetimi (TTK m. 18/2)
Ticari işletmeler arasında akdedilen sözleşmelerde tarafların Türk Ticaret Kanunu'nun 18/2. maddesi uyarınca "basiretli bir tacir" gibi hareket etmesi ilkesi esastır. Ancak iş sahibinin kendi tecrübesizliğinden faydalanarak veya yazılım şirketinin ticari bağımlılığını suistimal ederek edimler arasındaki dengeyi tamamen bozan fahiş şartlar koyması halinde, dürüstlük kuralı çerçevesinde hakkaniyet denetimi gündeme gelmektedir.
Aşırı Cezai Şartın İndirimi ve Ekonomik Mahv Sınırı (TBK m. 182/Son)
Ticaret hukuku mevzuatında tacirler bakımından cezai şartın fahişliği gerekçesiyle indirim istenemeyeceği kuralı (TTK m. 22) yer alsa da, Yargıtay içtihatları bu kurala önemli bir sınır getirmektedir. Borçlu taciri ekonomik mahvına sebep olacak, ticari varlığını tehlikeye düşürecek veya borçlunun ekonomik özgürlüğünü aşırı derecede kısıtlayacak düzeydeki cezai şartlar, TBK m. 182/son, TMK m. 2 ve TBK m. 27 hükümleri uyarınca re'sen (kendiliğinden) makul bir seviyeye indirilmekte veya geçersiz sayılmaktadır.
Aşırı İfa Güçlüğü ve Sözleşmenin Uyarlanması (TBK m. 136 ve m. 138)
Yazılım projesinin yürütülmesi esnasında taraflarca öngörülemeyen veya öngörülmesi beklenmeyen teknik imkânsızlıkların, dördüncü taraf entegrasyon kısıtlamalarının ya da müşteri süreçlerindeki radikal sapmaların ortaya çıkması halinde (ispatlanmak kaydıyla), TBK m. 136 uyarınca imkânsızlık veya TBK m. 138 uyarınca sözleşmenin değişen koşullara uyarlanması gündeme gelebilir.
3. Uygulamada Karşılaşılan Uyuşmazlık Alanları ve Bilişim Bilirkişiliği
Kapsam Esnemesi ve "Sonsuz Revizyon" İddiaları
Uygulamada sıklıkla karşılaşılan senaryolardan biri, iş sahibinin sözleşmeye "Yazılım firması, sistem tam olarak çalışır hale gelene kadar müşteri tarafından bildirilecek tüm revizyonları ve eksiklikleri ek ücret talep etmeden yapmakla yükümlüdür" şeklinde hükümler ekletmesidir. Müşteri tarafı, canlıya geçiş öncesinde sürekli yeni modüller veya iş kuralları talep etmekte, bunları "eksiklik" olarak nitelendirerek hakediş ödemelerini bloke etmektedir.
Uyuşmazlık yargıya taşındığında, Yargıtay ve mahkemece görevlendirilen bilirkişiler sözleşmenin imza tarihindeki ilk teknik analiz veya kapsam dokümanını (iş tanımını) esas alır. Sözleşmede "tüm revizyonlar" ifadesi yer alsa bile, bunun ilk analizde kararlaştırılan temel mimari ve fonksiyonlar ile sınırlı olduğu kabul edilir. Başlangıç analizinde bulunmayan yeni bir özelliğin "hata veya eksiklik" olarak sunulması TMK m. 2 uyarınca hakkın kötüye kullanılması olarak değerlendirilir. Bu durumda iş sahibi ödemeden kaçınamaz; yazılım yüklenicisi ise ek süre ve ek maliyet talep etme hakkına sahip olur.
Fahiş Gecikme Cezaları
Örneğin 500.000 TL bedelli bir yazılım projesinde, "Gecikilen her gün için proje bedelinin %5'i oranında cezai şart ödenir" şeklinde bir maddenin yer alması ve projenin 1 ay gecikmesi durumunda, hesaplanan ceza tutarı sözleşme bedelini aşmaktadır. Taraflar tacir olsa dahi, Yargıtay (örneğin kapatılan 15. Hukuk Dairesi'nin yerleşik eser sözleşmesi kararları) yazılım şirketini batırma noktasına getiren ve projenin toplam değerini katlayan bu tür fahiş cezai şartları dürüstlük kuralına aykırı bulmakta, cezayı borçlunun ticari mahvına yol açmayacak makul bir orana indirmektedir.
Hata Bildirim Usulü, İspat Yükü ve Zımni Kabul
İş sahibinin yazılımın geç teslim edildiğini ileri sürerek sözleşmeyi feshettiği ve teminatı nakde çevirdiği, yazılım şirketinin ise ürünü teslim ettiğini fakat müşterinin sözlü bildirimlerle süreci uzattığını savunduğu hallerde mahkemeler teknik kod incelemesinden önce hukuki ispat vasıtalarını inceler.
Sözleşmede hata bildirim kanalının (örneğin e-posta, JIRA, KEP) açıkça düzenlenmediği durumlarda genel hükümler uygulanır. Hataların yazılı, tarihli ve somut ekran görüntüleriyle belgelenip belgelenmediği aranır. Hukukumuzda yazılımın ayıplı olduğunu iddia eden iş sahibi ispat yükü altındadır. Müşteri somut hata raporu sunmaksızın yalnızca "sistem çalışmıyor" diyerek süreci geçiştirmişse veya yazılımı canlı ortamda fiilen kullanmaya başlamışsa, eseri zımnen kabul etmiş sayılır (TBK m. 474 ve m. 477).
Bilirkişi İnceleme Metodolojisi ve Makul Hata Toleransı
Yazılım uyuşmazlıklarında mahkemeler dosyayı Hukukçu ve Yazılım Mühendisi / Bilişim Uzmanı heyetinden oluşan bilirkişilere sevk eder. Bilirkişi heyeti incelemesinde şu hususları dikkate alır:
Sözleşme Anındaki Kapsam: Tarafların mutabık kaldığı ilk teknik şartname ve kapsam sınırları.
Süreç Akışı ve Kayıtlar: Proje logları, e-posta yazışmaları ve bilet kayıtları incelenerek gecikmenin yükleniciden mi yoksa iş sahibinin veri sağlamadaki gecikmesinden mi kaynaklandığı.
Yazılımın Doğasına Uygunluk: Müşterinin "sıfır hata" talebinin hayatın olağan akışına uygunluğu. Yargıtay uygulamasında, sistemi kilitlemeyen makul seviyedeki küçük hatalar (bug) "eksik ifa" değil "ayıplı ifa" olarak değerlendirilir ve yükleniciye bu hataları gidermesi için makul bir süre verilmesi şart koşulur.
4. Taraflar Arasında Hak Dengesini Sağlayan Tip Sözleşme Hükümleri
Sözleşmede yer alan her madde mutlak geçerliliğe sahip değildir; emredici hukuk kurallarına, kamu düzenine ve dürüstlük kuralına aykırı hükümler TBK m. 27 uyarınca geçersizdir. Hem yazılım yüklenicisini hem de iş sahibini koruyan, yazılım dünyasının esnekliği ile hukuki öngörülebilirliği birleştiren örnek sözleşme hükümleri aşağıda gruplandırılmıştır:
4.1. Kapsam ve Değişiklik Yönetimi
Müşteri tarafından iletilen bitmeyen revizyon taleplerini düzene sokmak ve gelişen teknik ihtiyaçlara hukuki bir çerçeve çizmek amacıyla temel kapsam ile değişiklik talepleri açıkça ayrılmalıdır.
Temel Kapsam: "İşbu sözleşmenin konusunu oluşturan yazılımın temel işlev ve fonksiyonları Ek-1’de yer alan 'Teknik Analiz ve Kapsam Dokümanı' ile sınırlandırılmıştır. Sözleşme imza tarihinde Ek-1'de yer almayan, ancak süreç içerisinde iş sahibi tarafından talep edilen her türlü yeni ekran, modül veya iş kuralı 'Değişiklik Talebi' olarak değerlendirilir."
Değişiklik Prosedürü: "Taraflar, proje yürütülürken teknik gereksinimlerin gelişebileceğini kabul eder. Değişiklik talepleri yazılı olarak iletilir. Yüklenici, talebin projeye etkisini (ek süre ve ek maliyet) en geç 5 (beş) iş günü içinde iş sahibine raporlar. İş sahibi tarafından yazılı olarak onaylanmayan değişiklik talepleri için yüklenici geliştirme yapmakla yükümlü kılınamaz; iş sahibi de bu taleplerin yapılmadığını ileri sürerek teslimatı geciktiremez."
4.2. Hata Sınıflandırması ve Kabul Kriterleri
Teslimat ve garanti süreçlerindeki uyuşmazlıkları önlemek adına hataların seviyelendirilmesi ve geçici kabul kriterlerinin netleştirilmesi gerekir.
Hata Seviyeleri ve Kabul: "Teslim edilen modüllerin Kabul Testi aşamasında tespit edilen hususlar üç seviyede sınıflandırılır: A Seviye (Kritik - Sistemi durduran), B Seviye (Majör - İşlevselliği aksatan ancak alternatifi olan) ve C Seviye (Minör - Kozmetik/Görsel). Test sürecinde A veya B seviyesinde engelleyici bir hata bulunmadığı sürece yazılım 'Geçici Kabulü Yapılmış' sayılır. C seviyesindeki minör aksaklıklar kabulü engellemez, Garanti/Destek süreci kapsamında giderilir."
4.3. Onay Süreçleri ve Zımni Kabul
İş sahibinin onay süreçlerini sebepsiz yere uzatmasını önlemek amacıyla süreye bağlı zımni kabul mekanizması öngörülmelidir.
Zımni Kabul Hükmü: "Yüklenici tarafından test ortamına alınan veya canlıya geçişe hazır olduğu yazılı olarak bildirilen modüller için iş sahibi 10 (on) iş günü içinde yazılı ve somut hata raporu sunmakla yükümlü kılınır. İş sahibinin bu süre zarfında yazılı bildirimde bulunmaması veya yazılımı canlı ortamda fiilen kullanmaya başlaması halinde, ilgili modül/yazılım kayıtsız şartsız kabul edilmiş sayılır."
4.4. Gecikme, Hakkaniyetli Cezai Şart ve Sorumluluk Sınırı
Yargıtay'ın fahiş cezai şartın indirimi ilkesiyle uyumlu, tarafların ticari varlığını tehlikeye atmayacak bir sorumluluk sınırı (liability cap) belirlenmelidir.
Gecikme Cezası ve Üst Sınır: "Yüklenicinin kendi kusurundan kaynaklanan ve Ek-2 Proje Takvimi’ni aşan gecikmelerde; Yüklenici, gecikilen her tam hafta için toplam sözleşme bedelinin %0,5’i (binde beş) oranında gecikme cezası ödemeyi kabul eder. Ancak işbu sözleşme kapsamında uygulanacak toplam gecikme cezası tutarı, sözleşme toplam bedelinin %10’unu geçemez."
İş Sahibi Kaynaklı Gecikmeler: "İş sahibinin sunucu/altyapı tahsisi, üçüncü taraf API erişim yetkileri, içerik/veri girişi veya test onay süreçlerini geciktirmesi halinde; gecikilen süre, Yüklenici’nin teslimat takvimine otomatik olarak eklenir ve bu süre boyunca Yüklenici'ye gecikme cezası uygulanamaz."
4.5. Bildirim Kanalları, İspat Yükü ve Servis Seviyesi (SLA)
Uyuşmazlık anında şifahi iddialar yerine mahkemede geçerli somut kanıt mekanizması oluşturulmalıdır.
Resmi Bildirim Kanalı: "Sözleşme süresince yapılacak tüm teknik hata bildirimleri ve talep süreçleri yalnızca [Destek e-posta adresi / JIRA / Proje Takip Sistemi URL] adresi üzerinden kayıt altına alınarak yapılacaktır. Anlık mesajlaşma uygulamaları (WhatsApp vb.) veya şifahi görüşmeler üzerinden yapılan bildirimler hukuken geçerli teslimat veya hata bildirimi sayılmaz."
Hatasızlık Garantisi Sınırı: "Yüklenici, yazılımın %100 hatasız çalışacağını garanti etmez; ancak garanti süresince ortaya çıkabilecek A ve B seviye hataları Ek-3 Servis Seviyesi (SLA) Tablosu'nda belirtilen süreler içinde ücretsiz olarak gidermeyi taahhüt eder."
4.6. Üçüncü Taraf Bağımlılıkları ve İfadaki İmkânsızlık
TBK m. 138 uyarınca, projenin yürütülmesi esnasında dördüncü taraf altyapılarında meydana gelen beklenmedik değişiklikler için uyarlama imkânı tanınmalıdır.
Teknik İmkânsızlık ve Uyarlama: "Yazılımın entegre olacağı üçüncü taraf sistemlerin (ERP, ödeme kuruluşları, kamu entegrasyonları, dış servisler vb.) altyapı değişiklikleri, servis kapatmaları veya dokümante edilmemiş kısıtlamaları sebebiyle ortaya çıkan imkânsızlıklardan Yüklenici sorumlu tutulamaz. Bu tür durumlarda taraflar, sözleşme şartlarını dürüstlük kuralı çerçevesinde yeniden uyarlamayı kabul eder."
5. Özet Dengesi
Tip sözleşme hükümlerinin taraflar üzerindeki koruma dengesi aşağıdaki tabloda özetlenmiştir:
Sözleşme Alanı İş Sahibine Sağladığı Güvence Yükleniciye Sağladığı Güvence
Kapsam Yönetimi Temel fonksiyonel gereksinimlerin eksiksiz teslim edilmesini sağlar. Kapsam dışı bedelsiz iş taleplerinin önüne geçer.
Kabul Testleri Ayıplı veya kritik hatası olan ürünü teslim alma zorunluluğunu kaldırır. Test süreçlerinin sebepsiz uzatılarak ödemelerin kesilmesini önler.
Cezai Şart Projenin zamanında tamamlanması için caydırıcı finansal yaptırım sunar. Cezai şartın şirket varlığını tehdit edecek seviyeye ulaşmasını engeller.
Bildirim ve SLA Hatalara müdahale ve çözüm sürelerini hukuki taahhüde bağlar. Sözlü ve dağınık bildirimlerin yol açtığı ispat karmaşasını eler.
Kaynakça
Uyarlar, T. Yargıtay Kararlarında "Dürüstlük (Objektif İyi Niyet)" Kuralı (MK m. 2/I) ve "Hakkın Kötüye Kullanılması Yasağı" (MK m. 2/II). Dokuz Eylül Üniversitesi Hukuk Fakültesi Dergisi.
Gümüş, S. Yargıtay Kararları Kapsamında Ceza Koşulu ve Aşırı Ceza Koşulunun İndirilmesi. DergiPark.
Çoban, M. Haksız Şart Denetimi ve Kesin Hükümsüzlük (TKHK m. 5).
Eker, İ. Sözleşmenin Feshi – Hukuki Çerçeve, Yargıtay Görüşleri ve Uygulama.