Özel Yazılım Projesinde Kabul Testi ve Ayıp Bildirimi: TBK 474-477 | 2026

Özel yazılım projelerinde en sık yapılan sözleşme hatalarından biri “teslim” ile “kabul”ün aynı işlem kabul edilmesidir. Yazılım geliştirici bir sürümü sunucuya yüklediğinde veya müşteriye repository erişimi verdiğinde teknik teslim gerçekleşebilir; fakat müşterinin şartnamedeki fonksiyonları test etmesi, hataları sınıflandırması ve kabul veya ret iradesini kayda geçirmesi ayrıca düzenlenmelidir. Bu ayrım yapılmadığında proje sonunda “çalışıyor”, “çalışmıyor”, “eksik”, “ayıplı”, “change request” ve “yeni özellik” kavramları birbirine karışır.

Bu yazıyla ilgili genel bir sorunuz mu var? Anonim soru sor

Hukuki çözümün temeli sözleşmenin niteliğini doğru tespit etmektir. Belirli bir yazılım sonucunun meydana getirilmesi ve teslimi üstlenilmişse eser sözleşmesi hükümleri uygulanabilir. Buna karşılık sürekli SaaS aboneliği, lisans, destek veya personel tahsisi gibi ilişkilerde farklı sözleşme hükümleri birlikte uygulanabilir. Bu yazı, müşteri için belirli bir yazılım eserinin geliştirilip teslim edildiği projelerde TBK m.474-478 eksenindeki kabul ve ayıp düzenini ele almaktadır.

• Özel yazılım sözleşmesi ne zaman eser sözleşmesidir?
• Teslim ile kabul arasındaki fark
• TBK m.474 gözden geçirme ve bildirim
• Yazılım kabul testi nasıl tasarlanır?
• Açık ayıp ve gizli ayıp
• Eksik iş ile ayıplı iş farkı
• TBK m.475 seçimlik haklar
• Ücretsiz onarım hakkı
• Bedelden indirim
• Sözleşmeden dönme
• TBK m.476 müşteri talimatından doğan ayıp
• TBK m.477 kabulün sonucu
• TBK m.478 zamanaşımı
• Bug, ayıp ve change request ayrımı
• Kabul tutanağı ve deliller
• Agile projelerde sprint kabulü
• Canlıya geçiş kabul anlamına gelir mi?
• Sözleşmeye yazılması gereken maddeler

1. Özel Yazılım Sözleşmesi Ne Zaman Eser Sözleşmesi Niteliğindedir?

TBK m.470 eser sözleşmesini, yüklenicinin bir eser meydana getirmeyi ve işsahibinin bunun karşılığında bedel ödemeyi üstlendiği sözleşme olarak düzenler. Müşteriye özgü ERP modülü, mobil uygulama, entegrasyon yazılımı veya otomasyon sistemi geliştirilmesinde yüklenicinin borcu yalnız çalışma süresi sağlamak değil, teknik şartnamede belirlenen sonucu meydana getirip teslim etmekse eser sözleşmesi hükümleri gündeme gelir.

Ancak her “yazılım sözleşmesi” otomatik olarak eser sözleşmesi değildir. Hazır yazılım lisansı, bulut aboneliği, sürekli bakım, danışmanlık veya yalnız geliştirici personel sağlanması farklı hukuki unsurlar içerir. Bu nedenle kabul ve ayıp hükümleri uygulanmadan önce yüklenicinin asli borcu sözleşmeden tespit edilmelidir.

Uygulamada tek sözleşme birden fazla unsur da içerebilir. Örneğin ilk aşamada özel yazılım geliştirme, ikinci aşamada lisans, üçüncü aşamada bakım ve bulut hizmeti bulunabilir. Kabul testi, özellikle meydana getirilen özel yazılım bölümüne bağlanmalıdır.

2. Teslim ile Kabul Aynı Şey Değildir

Teslim, tamamlanan eserin işsahibinin inceleyebileceği ve hâkimiyet alanına gireceği şekilde sunulmasıdır. Yazılımda bu işlem; üretime kurulum, test ortamına deploy, çalışır paket teslimi, kaynak kod repository erişimi veya sözleşmede belirlenen başka yöntemle yapılabilir.

Kabul ise müşterinin teslim edilen yazılımı sözleşme ve teknik şartname bakımından değerlendirmesi sonucunda eseri kabul ettiğini açıklamasıdır. Kabul açık biçimde tutanakla yapılabilir veya TBK m.477’deki şartlar oluşursa örtülü kabul sonucu doğabilir.

Sözleşmede “teslimden itibaren 10 iş günü içinde kabul testi yapılır” hükmü varsa teslim tarihi test süresini başlatır. “Canlıya alındı” kaydı tek başına bütün ayıplardan vazgeçildiği anlamına gelecek biçimde yazılmamalıdır; hangi testlerin tamamlandığı ve hangi açık maddelerin kaldığı kabul tutanağında gösterilmelidir.

3. TBK m.474 Müşteriye Hangi Yükümlülüğü Getirir?

TBK m.474/1 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 ayıplar varsa bunları uygun bir süre içinde yükleniciye bildirmek zorundadır. Kanun sabit “3 gün” veya “7 gün” gibi tek bir süre koymaz; incelemenin kapsamı ve eserin niteliği dikkate alınır.

Yazılım projelerinde bu nedenle sözleşmeyle belirli bir UAT yani kullanıcı kabul testi süresi kararlaştırılması ispat kolaylığı sağlar. Örneğin “teslimden itibaren 15 iş günü” denildiğinde taraflar inceleme takvimini önceden bilir. Bununla birlikte sözleşmede belirlenen süre, gizli ayıbın sonradan ortaya çıkmasına ilişkin TBK m.477 hükmünden ayrı değerlendirilir.

TBK m.474/2, taraflardan her birinin giderini karşılayarak eserin bilirkişi tarafından gözden geçirilmesini ve sonucun raporla belirlenmesini isteyebileceğini de açıkça düzenler. Yazılım uyuşmazlığında bağımsız teknik inceleme, hatanın mevcut olup olmadığını ve şartnameye aykırılığın niteliğini somutlaştırabilir.

4. Yazılım Kabul Testi Nasıl Tasarlanmalıdır?

Kabul testi genel “uygulama çalışıyor mu?” sorusuna indirgenmemelidir. Test kriterleri sözleşme imzalanırken veya en geç geliştirme başlamadan belirlenmelidir. Her fonksiyon için beklenen sonuç, veri seti, performans eşiği, güvenlik kriteri ve entegrasyon çıktısı tanımlanmalıdır.

Örneğin sipariş modülü için yalnız “sipariş oluşturur” demek yeterli değildir. Zorunlu alanlar, stok kontrolü, vergi hesabı, ödeme sonucu, iptal senaryosu, kullanıcı yetkisi ve dış sistem entegrasyonu ayrı kabul kriteri olmalıdır. Böylece teslimde hangi davranışın ayıp, hangisinin yeni özellik talebi olduğu ölçülebilir.

Testin kim tarafından yapılacağı da belirlenmelidir. Müşteri proje yöneticisi, teknik ekip ve iş birimi temsilcilerinin onay yetkileri ayrılabilir. “Her çalışan ret verebilir” modeli yerine yetkili kabul mercii sözleşmede gösterilmelidir.

5. Açık Ayıp Nedir?

Açık ayıp, usulüne uygun gözden geçirmede tespit edilebilen ayıptır. Yazılımda ekranın hiç açılmaması, sözleşmede bulunan fonksiyonun teslim edilmemesi, açıkça yanlış hesaplama yapılması veya test senaryosunda doğrudan görülen hata bu kapsamda değerlendirilebilir.

TBK m.474 gereğince açık ayıplar uygun sürede bildirilmelidir. Bildirim, hatayı ayırt edilebilir şekilde göstermelidir. “Yazılım sorunlu” veya “sistem beğenilmedi” şeklindeki genel mesaj yerine modül, ekran, işlem adımı, tarih-saat, kullanılan veri ve beklenen/gerçek sonuç yazılmalıdır.

Jira, Azure DevOps veya benzeri hata takip sistemindeki kayıtlar sözleşmede resmi bildirim kanalı olarak kabul edilmişse delil değerini güçlendirir. Buna ek olarak kritik kabul reddi ve seçimlik hak kullanımı ayrıca yazılı ihtarla bildirilebilir.

6. Gizli Ayıp Nedir ve Ne Zaman Bildirilir?

Gizli ayıp, usulüne uygun kabul incelemesinde fark edilemeyen ve sonradan ortaya çıkan ayıptır. TBK m.477’nin son fıkrası, ayıp sonradan ortaya çıkarsa işsahibinin durumu gecikmeksizin yükleniciye bildirmesini zorunlu kılar; bildirim yapılmazsa eser kabul edilmiş sayılır.

Örneğin yalnız belirli veri hacminde ortaya çıkan bir bellek sorunu veya aylık dönem kapanışında yanlış hesap yapan bir modül ilk kabul testinde objektif olarak fark edilemiyorsa gizli ayıp niteliği gündeme gelebilir. Ayıp ortaya çıktığı anda müşteri beklememeli; kayıtları koruyup yükleniciye bildirim yapmalıdır.

“Garanti süresi içinde istediğim zaman bildiririm” yaklaşımı TBK m.477 ile uyumlu değildir. Sözleşmesel garanti süresi, gizli ayıbın öğrenildikten sonra gecikmeksizin bildirilmesi yükümlülüğünü ortadan kaldırmaz.

7. Eksik İş ile Ayıplı İş Arasındaki Fark Nedir?

Eksik iş, sözleşmeyle üstlenilen bir edimin hiç veya kısmen yapılmamış olmasıdır. Ayıplı iş ise teslim edilen edimin sözleşmedeki nitelik ve fonksiyon şartlarını taşımamasıdır. Yazılımda “raporlama modülü hiç teslim edilmedi” eksik iş; modül teslim edildiği hâlde sözleşmedeki hesabı yanlış yapıyorsa ayıplı iş söz konusudur.

Bu ayrım kabul tutanağında açık kurulmalıdır. Eksik modül “bug” etiketiyle kapatılmamalı; sözleşmesel deliverable eksikliği olarak gösterilmelidir. Aynı şekilde müşterinin sonradan istediği yeni rapor da “ayıp” olarak kaydedilmemelidir.

Uyuşmazlığın çözümü için sözleşme kapsam matrisi, backlog’un sözleşmeye dahil edilmiş sürümü ve change request kayıtları birlikte incelenmelidir.

8. TBK m.475 Hangi Seçimlik Hakları Verir?

TBK m.475, yüklenicinin ayıptan sorumlu olduğu hâllerde işsahibine üç temel seçimlik hak verir. Birincisi, eser kullanılamayacak veya hakkaniyet gereği kabulü beklenemeyecek ölçüde ayıplı ya da sözleşmeye aynı ölçüde aykırıysa sözleşmeden dönmedir. İkincisi, eseri alıkoyup ayıp oranında bedelden indirim istemektir. Üçüncüsü, aşırı masraf gerektirmediği takdirde bütün masrafları yükleniciye ait olmak üzere ücretsiz onarım istemektir.

Maddenin devamında işsahibinin genel hükümlere göre tazminat isteme hakkının saklı olduğu açıkça belirtilir. Bu nedenle seçimlik hak ile zarar talebi birbirinden ayrıdır.

Müşteri aynı ayıp için birbiriyle bağdaşmayan seçimlik hakları aynı anda kesin olarak kullanamaz. Hangi hakkın seçileceği ayıbın ağırlığı, onarımın mümkün olup olmadığı ve yazılımın kullanılabilirliği değerlendirilerek belirlenmelidir.

9. Ücretsiz Onarım Yazılımda Nasıl Uygulanır?

Yazılım ayıbında en sık kullanılan çözüm ücretsiz düzeltmedir. TBK m.475/1-3 uyarınca onarım aşırı masraf gerektirmiyorsa işsahibi, masrafları yükleniciye ait olmak üzere ayıbın giderilmesini isteyebilir.

Düzeltme talebinde ayıp ile yeni özellik ayrımı korunmalıdır. Sözleşmede bulunmayan yeni filtre, farklı iş akışı veya ek entegrasyon ücretsiz onarım değildir; change request olabilir. Buna karşılık şartnamede açıkça bulunan özelliğin yanlış çalışması düzeltme kapsamındadır.

Sözleşmeye severity sistemi eklenmesi yararlıdır: kritik hata, yüksek, orta ve düşük hata için farklı çözüm süreleri belirlenir. Ancak severity tanımı TBK’daki seçimlik hakları ortadan kaldıracak biçimde kullanılmamalıdır.

10. Bedelden İndirim Hakkı Ne Zaman Kullanılır?

Müşteri yazılımı kullanmaya devam etmek istiyor fakat ayıp nedeniyle eserin değeri sözleşmedeki seviyenin altında kalıyorsa TBK m.475/1-2 uyarınca ayıp oranında bedelden indirim isteyebilir.

İndirim rastgele yüzdeyle belirlenmemelidir. Ayıbın ürün değerine ve sözleşmedeki edim dengesine etkisi teknik ve mali olarak ortaya konulmalıdır. Kullanılmayan bir ana modül ile küçük arayüz hatasının bedel etkisi aynı değildir.

Kurumsal projelerde modül bazlı fiyatlama veya milestone bedelleri bu hesabı kolaylaştırır. Sözleşmede bütün proje için tek toplam bedel bulunuyorsa ayıplı bölümün değer kaybı bilirkişi incelemesi gerektirebilir.

11. Sözleşmeden Dönme Hangi Ölçüde Ayıpta Gündeme Gelir?

TBK m.475/1-1, her küçük hata için dönme hakkı vermez. Eserin işsahibinin kullanamayacağı veya hakkaniyet gereği kabul etmeye zorlanamayacağı ölçüde ayıplı ya da sözleşmeye aynı ölçüde aykırı olması gerekir.

Özel yazılım bakımından ana işlevin yerine getirilememesi, sistemin sözleşmedeki temel kullanım amacını karşılamaması veya güvenli biçimde kullanılamaması bu değerlendirmenin merkezindedir. Kozmetik hata, tek başına bütün proje sözleşmesinden dönmeyi haklı kılmaz.

Dönme kararı verilmeden önce sözleşmedeki cure period, düzeltme hakkı ve kabul prosedürü de kontrol edilmelidir. Tarafların açıkça kararlaştırdığı düzeltme mekanizması işletilmeden ağır sonuçlu fesih/dönme adımı atılması yeni uyuşmazlık doğurabilir.

12. TBK m.476 Müşteri Talimatından Doğan Ayıbı Nasıl Düzenler?

TBK m.476’ya göre eserin ayıplı olması, yüklenicinin açıkça yaptığı ihtara rağmen işsahibinin verdiği talimattan doğmuşsa veya herhangi bir sebeple işsahibine yüklenebiliyorsa işsahibi ayıptan doğan haklarını kullanamaz.

Yazılım projesinde müşteri, geliştiricinin yazılı güvenlik uyarısına rağmen desteklenmeyen eski altyapının kullanılmasını emretmiş ve ayıp doğrudan bu talimattan çıkmışsa m.476 gündeme gelir. Burada yüklenicinin açık ihtarı önemlidir. Sonradan “ben söylemiştim” demek yerine risk yazılı olarak açıklanmalıdır.

Aynı kural yanlış veri, erişim engeli veya müşteri tarafından sağlanması gereken üçüncü taraf API bilgisinin verilmemesi gibi işsahibine yüklenebilen nedenlerde de önem taşıyabilir.

13. TBK m.477 Kabul Edilen Yazılımda Ne Sonuç Doğurur?

TBK m.477/1, eserin açıkça veya örtülü olarak kabulünden sonra yüklenicinin her türlü sorumluluktan kurtulacağını; ancak yüklenicinin kasten gizlediği ve usulüne göre gözden geçirme sırasında fark edilemeyecek ayıplar için sorumluluğun devam edeceğini düzenler.

Aynı maddenin ikinci fıkrasına göre işsahibi gözden geçirmeyi ve bildirimde bulunmayı ihmal ederse eseri kabul etmiş sayılır. Üçüncü fıkraya göre sonradan ortaya çıkan ayıp da gecikmeksizin bildirilmelidir; aksi hâlde eser kabul edilmiş sayılır.

Bu nedenle kabul testini hiç yapmadan aylar sonra açık hataları ileri sürmek ciddi hak kaybı riski yaratır. Müşteri teslimle birlikte inceleme takvimini çalıştırmalı ve bulguları zamanında kaydetmelidir.

14. Canlıya Geçiş Otomatik Kabul Anlamına Gelir mi?

Canlıya geçişin hukuki etkisi sözleşmedeki kabul düzenine göre belirlenir. Sözleşmede “üretim ortamına alınması nihai kabul sayılır” hükmü varsa bu hüküm önem taşır. Böyle bir hüküm yoksa canlı kullanım, diğer delillerle birlikte örtülü kabul tartışmasına konu olabilir.

En güvenli yöntem, go-live ile kabulü ayrı belgeler hâlinde yönetmektir. Sistem operasyonel zorunluluk nedeniyle canlıya alınabilir; buna rağmen kabul listesinde çözülmesi gereken açık ayıplar bulunabilir. Bu açık maddeler tutanağa yazılmalıdır.

“Canlıya aldık ama hiçbir şeyi kabul etmedik” şeklindeki sınırsız rezerv de doğru değildir. Hangi ayıplar bakımından çekince konulduğu somut biçimde belirtilmelidir.

15. Agile ve Sprint Bazlı Projelerde Kabul Nasıl Yapılır?

Agile yöntem TBK m.474-477 hükümlerini ortadan kaldırmaz. Taraflar her sprint sonunda demo, test ve kısmi kabul mekanizması kurabilir. Kabul edilen sprint çıktıları ile henüz geliştirme aşamasındaki backlog ayrıştırılır.

Her sprint user story’sinin acceptance criteria’sı bulunmalı, “done” tanımı sözleşmeyle uyumlu olmalıdır. Product owner’ın Jira’da “accepted” işaretinin hukuki kabul sayılıp sayılmayacağı sözleşmede açıkça düzenlenmelidir.

Nihai ürün kabulü ayrıca yapılacaksa sprint kabulü yalnız ara onay olarak tanımlanabilir. Aksi hâlde bir tarafta teknik “done”, diğer tarafta hukuki “kabul” kavramı kullanılması uyuşmazlık yaratır.

16. Kabul Testinde Performans ve Güvenlik Nasıl Ölçülür?

Fonksiyonel test tek başına yeterli değildir. Sözleşmede performans hedefi varsa eşzamanlı kullanıcı sayısı, yanıt süresi, throughput, hata oranı ve veri hacmi somut ölçülerle yazılmalıdır. “Yeterince hızlı” ifadesi hukuki ve teknik olarak zayıftır.

Güvenlik bakımından da “güvenli yazılım” gibi soyut taahhüt yerine belirli gereksinimler kullanılmalıdır. Örneğin kritik seviye bilinen güvenlik açığı bulunmaması, MFA desteği, şifreleme standardı, yetki matrisi veya belirli güvenlik testinin başarıyla tamamlanması kabul kriteri yapılabilir.

Yetkili güvenlik testinin hukuki sınırları bakımından bug bounty ve yetkili güvenlik testi rehberi ayrıca incelenebilir.

17. Hata Kaydı Ayıp Bildirimi İçin Nasıl Tutulmalıdır?

Her kayıtta benzersiz numara, tarih, sürüm, ortam, kullanıcı rolü, tekrar adımları, beklenen sonuç, gerçekleşen sonuç, ekran görüntüsü veya log ve önem seviyesi bulunmalıdır. Yüklenicinin “reproduce edemedim” cevabı da aynı kayıt içinde tutulmalıdır.

Sözleşme bildirim kanalını e-posta veya ticket sistemi olarak belirlemişse taraflar bu kanalı kullanmalıdır. WhatsApp mesajı veya sözlü toplantı notu sonradan ispat tartışması yaratabilir.

Kritik ayıplarda noter ihtarı zorunlu değildir; ancak seçimlik hakkın kullanılması, sözleşmeden dönme veya yüksek bedelli uyuşmazlıkta yazılı ve ispatlanabilir bildirim tercih edilmelidir.

18. TBK m.478 Zamanaşımı Yazılım İçin Ne Düzenler?

TBK m.478’e göre yüklenici ayıplı eser meydana getirmişse bu sebeple açılacak davalar, teslim tarihinden başlayarak taşınmaz yapılar dışındaki eserlerde iki yılın geçmesiyle zamanaşımına uğrar. Yüklenicinin ağır kusuru varsa ayıplı eserin niteliğine bakılmaksızın yirmi yıllık süre uygulanır. Yazılım taşınmaz yapı değildir; bu nedenle genel olarak iki yıllık kategori esas alınır.

Bu zamanaşımı süresi, TBK m.474 ve m.477’deki ayıbı zamanında bildirme yükümlülüğüyle karıştırılmamalıdır. Müşteri “iki yıl sürem var” diyerek açık ayıbı aylarca bekletemez. Bildirim külfeti ve dava zamanaşımı farklı kurallardır.

Sözleşmede garanti veya destek süresinin daha uzun kararlaştırılması da kanuni ihbar rejiminin ayrıca değerlendirilmesine engel değildir.

19. Bug, Ayıp ve Change Request Nasıl Ayrılır?

Bug, teknik hata sınıflandırmasıdır. Her bug hukuken ayıp olmayabilir; çünkü sözleşmede taahhüt edilmeyen davranışın eksikliği hukuki ayıp sayılmaz. Ayıp, teslim edilen eserin sözleşmede taahhüt edilen nitelik veya işlevi taşımamasıdır. Change request ise mevcut sözleşme kapsamının değiştirilmesi veya genişletilmesidir.

Bu üç kavram sözleşmede ayrı tanımlanmalıdır. Müşteri yeni özellikleri ücretsiz “bug fix” adı altında isteyememeli; yüklenici de teslim etmesi gereken fonksiyonu “change request” diyerek ek ücret konusu yapmamalıdır.

En etkili çözüm, sözleşme ekinde kapsam matrisi ve acceptance criteria bulundurmak, değişiklikleri versiyonlu change request belgesiyle yönetmektir.

20. Kaynak Kod Teslimi Kabul Testinin Parçası Olabilir mi?

Eğer sözleşme kaynak kod teslimini deliverable olarak belirlemişse evet. Repository erişimi, branch yapısı, build scriptleri, dependency dosyaları ve teknik dokümantasyon teslim listesinde ayrı kalem olmalıdır.

Çalışır binary teslim edilmiş olsa bile kaynak kod sözleşmede açıkça taahhüt edilmişse kodun hiç teslim edilmemesi eksik edim oluşturur. Buna karşılık standart lisans modelinde müşteriye kaynak kod teslimi kararlaştırılmamışsa müşteri kabul aşamasında bunu sonradan zorunlu kalem hâline getiremez.

Kritik sistemlerde kaynak kod doğrudan müşteriye teslim edilmeyecekse kaynak kodu escrow mekanizması ayrı sözleşmeyle kurulabilir.

21. Yazılım Kabul Tutanağında Hangi Başlıklar Bulunmalıdır?

• Proje ve sözleşme numarası,
• Teslim edilen sürüm ve build numarası,
• Test ortamı ve test tarihi,
• Uygulanan kabul senaryoları,
• Başarılı ve başarısız kriterler,
• Açık ayıp/hata listesi,
• Eksik deliverable listesi,
• Change request olarak ayrılan talepler,
• Her hata için çözüm süresi,
• Varsa şartlı kabul ve çekinceler,
• Nihai kabul veya ret iradesi,
• Tarafların yetkili temsilcileri,
• Kaynak kod ve dokümantasyon teslim durumu.

22. Sözleşmeye Yazılması Gereken Kabul Maddeleri

Bir özel yazılım sözleşmesinde teslim yöntemi, kabul testi başlangıcı, test süresi, test verisini kimin sağlayacağı, yetkili kabul mercii, kabul kriterleri, hata seviyeleri, ret eşiği, düzeltme süreleri, tekrar test yöntemi, örtülü kabul şartı ve gizli ayıp prosedürü ayrı maddeler hâlinde düzenlenmelidir.

“Müşteri 5 gün içinde cevap vermezse yazılım kabul edilmiş sayılır” gibi hüküm, projenin büyüklüğüne ve gerçek test imkânına göre düzenlenmelidir. Tarafların sözleşme serbestisi TBK m.26’ya tabidir; ancak özellikle tüketici işlemlerinde veya genel işlem koşullarında emredici koruma hükümleri ayrıca uygulanır.

Kabul maddesi, ödeme planıyla da uyumlu olmalıdır. Nihai hakediş kabul tutanağına bağlanmışsa hangi çekincelerin ödemeyi durduracağı önceden yazılmalıdır.

23. Site İçindeki İlgili Rehberler

Yazılım hak sahipliği için çalışanın yazdığı yazılım ve FSEK m.18 rehberi, kaynak kodun gizliliği için kaynak kod ticari sır rehberi, kritik kodun bağımsız saklanması için kaynak kod escrow rehberi ve yazılımın telif koruması için Yazılımın Telif Hakkıyla Korunması incelenebilir.

24. Resmî Kaynaklar

• 6098 sayılı Türk Borçlar Kanunu – m.470 ve m.474-478
• TBMM – 6098 sayılı Türk Borçlar Kanunu metni
• T.C. Kültür ve Turizm Bakanlığı Telif Hakları Genel Müdürlüğü – FSEK mevzuatı

25. Sık Sorulan Sorular

Özel yazılım sözleşmesi her zaman eser sözleşmesi midir?

Hayır. Belirli bir yazılım sonucunun meydana getirilip teslim edilmesi borcu baskınsa eser sözleşmesi hükümleri uygulanabilir. Hazır lisans, SaaS, bakım ve personel tahsisi ilişkileri ayrıca değerlendirilir.

Yazılım teslim edilince otomatik kabul edilmiş olur mu?

Hayır. Teslim inceleme sürecini başlatır. Kabul, açık iradeyle veya TBK m.477’deki şartlar oluştuğunda örtülü biçimde gerçekleşebilir.

Açık ayıp ne zaman bildirilmelidir?

TBK m.474 gereğince teslimden sonra işlerin olağan akışına göre imkân bulunur bulunmaz gözden geçirilmeli ve tespit edilen ayıp uygun süre içinde yükleniciye bildirilmelidir.

Gizli yazılım hatası aylar sonra çıkarsa hak kaybolur mu?

TBK m.477 gereğince sonradan ortaya çıkan ayıp gecikmeksizin yükleniciye bildirilmelidir. Bildirim yapılmazsa eser kabul edilmiş sayılır.

Müşteri her hatada sözleşmeden dönebilir mi?

Hayır. TBK m.475’te dönme için eserin kullanılamayacak veya hakkaniyet gereği kabule zorlanamayacak ölçüde ayıplı ya da sözleşmeye aynı ölçüde aykırı olması gerekir.

Ücretsiz bug fix kanuni hak mıdır?

Ayıp yüklenicinin sorumluluğundaysa ve onarım aşırı masraf gerektirmiyorsa TBK m.475/1-3 uyarınca işsahibi ücretsiz onarım isteyebilir.

Yeni özellik talebi ayıp sayılır mı?

Hayır. Sözleşmede taahhüt edilmeyen yeni fonksiyon change request’tir. Ayıp, teslim edilen yazılımın kararlaştırılan nitelik veya işlevi taşımamasıdır.

Canlıya almak yazılımı kabul etmek anlamına gelir mi?

Sözleşmede bu yönde açık hüküm varsa kabul sonucu doğabilir. Açık hüküm yoksa canlı kullanım diğer davranışlarla birlikte örtülü kabul değerlendirmesinde dikkate alınır; açık ayıplar varsa çekince tutanağa yazılmalıdır.

Yazılım ayıbı davalarında zamanaşımı kaç yıldır?

TBK m.478 uyarınca taşınmaz yapı dışındaki eserlerde teslimden itibaren iki yıldır. Yüklenicinin ağır kusuru varsa yirmi yıllık süre düzenlenmiştir.

Kabul testini kim yapmalı?

Sözleşmede yetkili müşteri temsilcisi veya kabul komitesi belirlenmelidir. İş birimi, teknik ekip ve proje yöneticisinin görevleri ayrılmalı ve nihai kabul iradesini kimin vereceği yazılmalıdır.

26. Sonuç

Özel yazılım projesinde kabul testi, teknik kalite kontrolünün ötesinde hukuki hakların korunmasıdır. Eser sözleşmesi niteliğindeki ilişkide TBK m.474 müşteriye teslimden sonra gözden geçirme ve uygun sürede ayıp bildirimi külfeti yükler; TBK m.475 ayıba karşı dönme, bedelden indirim ve ücretsiz onarım haklarını; TBK m.477 ise kabulün ve gizli ayıp bildiriminin sonuçlarını düzenler.

Sağlıklı proje yönetimi için teknik şartname, acceptance criteria, hata sınıfları, test süresi, kabul tutanağı ve change request sistemi sözleşmeyle aynı dili kullanmalıdır. Bu yapı kurulduğunda “bug mı yeni özellik mi?”, “teslim edildi mi?”, “kabul edildi mi?” ve “ayıp zamanında bildirildi mi?” soruları somut kayıtlarla cevaplanabilir.

Av. Halil Bakırcı tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

Avukat Halil BAKIRCI, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Av. Halil Bakırcı profilini inceleyin →