Yazılım Teslim ve Kabul Süreci: UAT, Ayıplı Yazılım, Revizyon ve Ödeme Uyuşmazlıkları

Bir yazılım şirketi, müşterisi için altı ay boyunca özel bir CRM sistemi geliştirmiş olabilir. Proje tamamlandığında yazılımın çalışır sürümünü müşteriye teslim eder ve son ödeme için fatura düzenler.

Ancak müşteri şu yanıtı verir:

"Yazılımı henüz kabul etmiyorum. İstediğim bazı özellikler eksik, birkaç hata var ve yeni eklemek istediğim modüller bulunuyor. Bunlar tamamlanmadan kalan bedeli ödemeyeceğim."

Yazılım geliştiricisi ise projenin sözleşmeye uygun şekilde tamamlandığını, müşterinin istediği yeni modüllerin başlangıç kapsamına dahil olmadığını ve ödemenin yapılması gerektiğini savunur.

Peki, bu uyuşmazlıkta kim haklıdır?

Bir yazılımın teknik olarak teslim edilmesi, her durumda sözleşmeye uygun şekilde kabul edildiği anlamına gelmez. Ancak müşterinin yazılımı kabul etmediğini söylemesi de geliştiricinin bütün ödeme haklarını kendiliğinden ortadan kaldırmaz.

Özellikle özel yazılım geliştirme projelerinde işin kapsamının, teslim usulünün, kullanıcı kabul testlerinin (UAT), ayıp bildirimlerinin ve ödeme koşullarının birlikte değerlendirilmesi gerekir.

Türk hukukunda yazılım geliştirme sözleşmelerinin hukuki niteliği somut sözleşmeye göre belirlenir. Belirli bir yazılımın meydana getirilmesinin üstlenildiği ilişkilerde Türk Borçlar Kanunu'nun eser sözleşmesine ilişkin hükümleri uygulanabilir.

Ancak sürekli teknik hizmet, bakım, danışmanlık ve abonelik ilişkileri içeren sözleşmelerde farklı veya karma hukuki nitelendirmeler gündeme gelebilir.

Bu rehberde yazılım teslim ve kabul sürecinin nasıl düzenlenebileceğini, UAT testlerinin hukuki önemini, ayıplı yazılımda tarafların haklarını, revizyon taleplerini, gecikmeleri, ödeme uyuşmazlıklarını ve mahkemede kullanılabilecek teknik delilleri inceliyorum.

1. Yazılım Teslim ve Kabul Süreci Nedir?

Yazılım teslim ve kabul süreci, geliştirilen yazılımın sözleşmede belirlenen gereksinimlere uygun olarak müşteriye sunulmasını ve bu uygunluğun kararlaştırılan yöntemle değerlendirilmesini ifade eder.

Ancak teslim ve kabul iki ayrı kavramdır.

Teslim, yüklenicinin sözleşmede üstlendiği ürünü veya ilgili proje aşamasını iş sahibinin değerlendirmesine ya da kullanımına sunmasıyla bağlantılıdır.

Kabul ise meydana getirilen işin sözleşmeye uygunluğu bakımından ortaya çıkan hukuki değerlendirmeyi ifade eder.

Örneğin bir yazılım geliştiricisi, müşterisine test ortamı bağlantısı göndererek belirli modülü incelemeye açmış olabilir.

Ancak bu işlem, sözleşmede üretim ortamına kurulumun ve gerekli belgelerin tesliminin öngörüldüğü bir ilişkide, bütün teslim yükümlülüklerinin yerine getirildiği anlamına gelmeyebilir.

Benzer şekilde müşterinin yazılımı belirli amaçlarla test etmesi, her durumda nihai ve kayıtsız şartsız kabul iradesi bulunduğunu göstermez.

Yazılımın teslimi için hangi koşullar gerekir?

Bu sorunun yanıtı sözleşmenin içeriğine bağlıdır.

Örneğin teslimin kapsamı şu unsurları içerebilir:

• Yazılımın çalışır sürümü,

• Belirlenen fonksiyonların tamamlanması,

• Test ortamına erişim,

• Üretim ortamına kurulum,

• Teknik dokümantasyon,

• Kaynak kod teslimi,

• Entegrasyonların tamamlanması,

• Veri aktarımı,

• Kullanıcı eğitimleri.

Ancak bütün projelerde bu unsurların tamamının teslim edilmesi zorunlu değildir.

Önemli olan teslim borcunun sözleşmede hangi kapsamda üstlenildiğinin belirlenmesidir.

2. Yazılım Geliştirme Sözleşmesi Eser Sözleşmesi midir?

6098 sayılı Türk Borçlar Kanunu'nun 470. maddesi, eser sözleşmesini yüklenicinin bir eser meydana getirmeyi, iş sahibinin ise bunun karşılığında bedel ödemeyi üstlendiği sözleşme olarak tanımlar.

Özel bir yazılım geliştirme projesinde belirli sonucun meydana getirilmesinin üstlenilmesi, eser sözleşmesi hükümlerinin uygulanmasını gündeme getirebilir.

Örneğin müşteri için belirli teknik şartnameye uygun bir stok yönetim yazılımının hazırlanması söz konusu olabilir.

Ancak bütün yazılım ilişkileri aynı hukuki nitelikte değildir.

SaaS abonelik sözleşmesi de eser sözleşmesi midir?

Her durumda değil.

Bir SaaS şirketi, müşterisine hazır ve sürekli işletilen bir yazılıma belirli süreyle erişim sağlıyor olabilir.

Bu ilişki, müşteriye özel bir yazılım meydana getirilmesi taahhüdünden farklıdır.

SaaS sözleşmesi lisans, hizmet, bakım, destek ve veri işleme ilişkilerini birlikte içerebilir.

Bu nedenle uygulanacak hükümler somut sözleşmenin niteliğine göre belirlenmelidir.

SaaS hizmetlerinin özel hukuki yapısını Yazılım ve Teknoloji Geliştirme Sözleşmelerinde SaaS Temel Hukuki Dinamikler başlıklı makalemde ayrıca inceledim.

Hukuki nitelendirme neden önemlidir?

Çünkü yazılımın geç teslim edilmesi, ayıplı olması, müşterinin bedel ödememesi veya sözleşmenin sona erdirilmesi halinde uygulanacak hükümler bu nitelendirmeden etkilenir.

Örneğin eser sözleşmesine ilişkin TBK m.474–478 hükümleri, ayıbın tespiti ve iş sahibinin seçimlik hakları bakımından önem taşır.

Buna karşılık sürekli hizmet ilişkileri içeren sözleşmelerde farklı hükümler uygulanabilir.

3. UAT Nedir? User Acceptance Testing Nasıl Yapılır?

User Acceptance Testing (UAT), geliştirilen yazılımın gelecekteki kullanıcılar tarafından belirlenen ihtiyaçlara ve kabul kriterlerine göre değerlendirilmesini amaçlayan kullanıcı kabul testidir.

UAT, yazılımın yalnızca teknik olarak çalışıp çalışmadığını değil, öngörülen iş süreçlerini karşılayıp karşılamadığını değerlendirmeye de yardımcı olur.

Örneğin bir muhasebe yazılımının:

• Fatura oluşturması,

• Müşteri bilgilerini kaydetmesi,

• Yetkili kullanıcıların rapor alabilmesi,

• Vergi hesaplamalarını belirlenen kurallara göre gerçekleştirmesi,

• Verileri doğru biçimde dışa aktarabilmesi

kabul testlerinin konusu olabilir.

UAT ile yazılımcının kendi testleri aynı mıdır?

Hayır.

Geliştirici ekip tarafından yürütülen birim testleri, entegrasyon testleri ve sistem testleri ile müşterinin kullanım senaryolarını değerlendirdiği kabul testleri farklı amaçlara hizmet eder.

Örneğin bir birim testi belirli fonksiyonun doğru hesaplama yapıp yapmadığını kontrol edebilir.

UAT ise müşterinin bir faturayı oluşturma, kaydetme ve raporlama sürecinin bütün olarak öngörülen ihtiyacı karşılayıp karşılamadığını değerlendirebilir.

UAT kanunen zorunlu mudur?

Her yazılım sözleşmesinde UAT başlıklı özel bir test prosedürü uygulanmasına ilişkin genel bir kanuni zorunluluk bulunmamaktadır.

Ancak taraflar sözleşmede kabul testleri öngörebilir.

Bu durumda testin kim tarafından, hangi ortamda, hangi sürede ve hangi kriterlere göre gerçekleştirileceği açıkça düzenlenmelidir.

UAT'nin teknik içeriği kadar sözleşmesel sonuçları da önemlidir.

4. Yazılım Sözleşmesinde Acceptance Criteria Nasıl Belirlenir?

Acceptance Criteria, yani kabul kriterleri, yazılımın veya belirli bir modülün kabul edilebilmesi için karşılaması gereken önceden belirlenmiş koşullardır.

Örneğin:

"Yazılım hızlı çalışacaktır."

ifadesi teknik ve hukuki açıdan belirsiz olabilir.

Bunun yerine sözleşmede belirli şartlar altında ölçülebilen performans kriterleri öngörülebilir.

Örnek kabul kriterleri

Bunlar yalnızca varsayımsal örneklerdir.

Somut projede ilgili kriterler teknik gereksinim dokümanıyla uyumlu hazırlanmalıdır.

Kabul kriterleri sözleşmenin neresinde bulunmalı?

Kabul kriterleri:

• Ana sözleşmede,

• Teknik şartnamede,

• Statement of Work (SOW) belgesinde,

• Ek kabul test planında,

• Milestone veya sprint eklerinde

düzenlenebilir.

Ancak bu belgelerin sözleşmeyle hukuken nasıl ilişkilendirildiği ve farklı belgeler arasında çelişki çıkarsa hangisinin esas alınacağı belirlenmelidir.

Yazılımın her hatadan arındırılmış olması şart mı?

Bu soruya bütün projeler için aynı yanıt verilemez.

Yazılımın niteliği ve sözleşmedeki performans taahhütleri önemlidir.

Örneğin ödeme sistemindeki tutar hatasıyla bir yönetim ekranındaki küçük görsel hizalama problemi aynı ağırlıkta olmayabilir.

Ancak hata sınıflandırması yapılmış olması, geliştiricinin kanuni sorumluluğunu her durumda ortadan kaldırmaz.

5. Bug, Defect ve Change Request Arasındaki Fark Nedir?

Yazılım sözleşmelerinde uyuşmazlıkların önemli bir bölümü, müşterinin talep ettiği işlemin hata düzeltme mi yoksa yeni geliştirme mi olduğu konusunda ortaya çıkar.

Örneğin:

Müşteri, sözleşmede bulunmasına rağmen faturaların PDF olarak dışa aktarılamadığını bildiriyorsa bu durum sözleşmeye aykırılık veya ayıp değerlendirmesine konu olabilir.

Buna karşılık müşteri, başlangıçta kararlaştırılmamış WhatsApp otomatik bildirim sistemi eklenmesini istiyorsa yeni özellik talebi söz konusu olabilir.

Bug nedir?

Bug, yazılımın beklenen davranışından sapmasına yol açan teknik hata için kullanılan genel bir kavramdır.

Ancak her teknik bug, otomatik olarak aynı hukuki ağırlıkta ayıp anlamına gelmez.

Defect nedir?

Defect, test veya kalite kontrol süreçlerinde tespit edilen kusur veya uygunsuzluğu ifade etmek amacıyla kullanılır.

Hukuki açıdan ilgili uygunsuzluğun sözleşmesel gereksinimlere veya uygulanabilir kalite yükümlülüklerine aykırı olup olmadığı önemlidir.

Change Request nedir?

Change Request, proje kapsamındaki değişikliklerin belirli usulle talep edilmesini ve değerlendirilmesini amaçlayan yöntemdir.

Yeni bir entegrasyon, raporlama özelliği veya kullanıcı rolü eklenmesi Change Request kapsamında değerlendirilebilir.

Her revizyon ücretsiz yapılmak zorunda mı?

Hayır.

İşin sözleşmeye uygun hale getirilmesi için gereken hata düzeltmeleri ile müşterinin yeni özellik talepleri aynı değildir.

Ancak “Revizyon” kelimesinin kullanılması, bütün taleplerin otomatik olarak bedelli ek iş olduğu anlamına da gelmez.

Talebin hukuki niteliği, başlangıçta üstlenilen kapsam üzerinden belirlenmelidir.

Bu ayrımı Yazılım Geliştirme Sözleşmelerinde Kapsam Kayması (Scope Creep) ve Hukuki Önlemler başlıklı makalemde ayrıca inceliyorum.

6. Yazılımda Hata Seviyeleri Nasıl Düzenlenmelidir?

UAT sürecinde tespit edilen bütün hataların projeye etkisi aynı değildir.

Bu nedenle sözleşmede veya kabul test planında hata sınıflandırması yapılması değerlendirilebilir.

Örneğin:

Critical / Blocker: Yazılımın temel işlevini kullanılamaz hale getiren veya ciddi veri bütünlüğü ve güvenlik riski doğuran hata.

High / Major: Önemli bir iş sürecini etkileyen, ancak bütün sistemi tamamen kullanılamaz hale getirmeyen hata.

Medium: Belirli işlevi etkileyen ve sınırlı geçici çözümü bulunan hata.

Low / Minor: Yazılımın temel kullanımını önemli ölçüde etkilemeyen, daha düşük etkili kusur.

Ancak bunlar kanuni ayıp kategorileri değildir.

Sözleşmesel ve teknik sınıflandırma örnekleridir.

Kritik hata varsa müşteri kabulü reddedebilir mi?

Hatanın niteliğine, sözleşmedeki kabul kriterlerine ve uygulanabilir hukuk hükümlerine göre değerlendirilir.

Örneğin ödeme sistemi yanlış tutarlar tahsil ediyorsa yazılımın sözleşmede öngörülen temel amaçla kullanılmasının mümkün olup olmadığı incelenebilir.

Ancak çok küçük ve temel kullanımı etkilemeyen bir eksikliğin bulunması, iş sahibine her durumda sınırsız biçimde kabulü erteleme yetkisi verdiği anlamına gelmez.

Minor bug varsa kabul yapılabilir mi?

Taraflar belirli düşük etkili hataların ayrı bir eksiklik listesine alınmasını ve kabul sonrasında giderilmesini kararlaştırabilir.

Bu yapı bazen Conditional Acceptance, yani şartlı kabul olarak adlandırılır.

Ancak kabul tutanağındaki çekincelerin kapsamı ve kanuni haklara etkisi açıkça belirlenmelidir.

7. Yazılımın Teslim Edilmesi İçin Kaynak Kod da Verilmeli mi?

Bu soru, yazılım geliştirme sözleşmelerinde özellikle önemlidir.

Yazılımın çalışır sürümünün teslim edilmesi ile kaynak kodların teslimi farklı yükümlülüklerdir.

Örneğin müşteri için özel geliştirilen bir yazılımda kaynak kod teslimi kararlaştırılmış olabilir.

Başka bir projede müşteri yalnızca çalışan uygulamayı kullanma lisansı edinmiş olabilir.

Kaynak kod teslimi her projede zorunlu mu?

Hayır.

Genel olarak bütün yazılım ilişkilerinde kaynak kod teslimini zorunlu kılan tek tip bir kural bulunmamaktadır.

Ancak sözleşmedeki teslim borcu, yazılımın niteliği ve diğer hukuki ilişkiler kapsamında değerlendirme yapılmalıdır.

Kaynak kod GitHub'a yüklendiyse teslim tamamlanmış olur mu?

Her durumda değil.

Örneğin sözleşmede:

• Çalışan uygulama,

• Kaynak kod,

• Kurulum talimatları,

• Veritabanı şeması,

• API dokümantasyonu,

• Test raporları

teslim konusu yapılmış olabilir.

Bu durumda yalnızca GitHub deposuna erişim verilmesi, bütün sözleşmesel teslim yükümlülüklerini karşılamayabilir.

Kaynak kod teslim edilirse telif hakları da geçer mi?

Hayır, kendiliğinden geçmez.

5846 sayılı Fikir ve Sanat Eserleri Kanunu kapsamında yazılım üzerindeki mali hakların devri veya lisanslanması, kaynak kodun teknik tesliminden ayrı değerlendirilmelidir.

FSEK m.52'nin yazılı şekil ve hakların ayrı ayrı gösterilmesine ilişkin şartları önemlidir.

Özellikle çalışanlar ve bağımsız geliştiriciler bakımından hak sahipliğini Bilişim Şirketlerinde Çalışan Buluşları ve Fikri Mülkiyet Haklarının Devri başlıklı makalemde ayrıca ele aldım.

8. Yazılım Teslim Edildikten Sonra Müşteri Hemen Kontrol Etmek Zorunda mı?

Bir yazılım geliştirme ilişkisinin eser sözleşmesi hükümlerine tabi olduğu durumlarda TBK m.474 önem taşır.

Bu madde 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 süre içinde yükleniciye bildirmek zorundadır.

Ancak kanun, bütün eser sözleşmeleri ve bütün yazılım projeleri için sabit bir “üç gün” veya “yedi gün” süresi belirlememektedir.

Ayıp bildirimi için kaç gün süre vardır?

Eser sözleşmesi bakımından TBK m.474'teki ölçüt, somut olayın özelliklerine göre uygun süredir.

Örneğin küçük bir web sitesiyle çok sayıda entegrasyonu bulunan kurumsal ERP yazılımının incelenmesi için gereken süre farklı olabilir.

Ayrıca sözleşmede belirli bir kabul prosedürü düzenlenmiş olabilir.

Bu nedenle sabit süre belirlenirken yazılımın kapsamı ve testlerin gerçekçi şekilde tamamlanabilmesi dikkate alınmalıdır.

Müşteri yazılımı hiç test etmezse ne olur?

TBK m.477, iş sahibinin gözden geçirme ve bildirimde bulunma yükümlülüğünü ihmal etmesi halinde eseri kabul etmiş sayılmasına ilişkin düzenleme içermektedir.

Ancak bu hükmün uygulanabilmesi için teslim, inceleme imkânı, ilgili ayıbın niteliği ve diğer kanuni koşullar değerlendirilmelidir.

Yalnızca geliştiricinin “Kod hazır.” demesi, her durumda teslimin ve gözden geçirme imkânının gerçekleştiğini göstermez.

9. Müşteri Sessiz Kalırsa Yazılım Kabul Edilmiş Sayılır mı?

Bu soru özellikle yazılım geliştiricilerin en sık sorduğu konulardan biridir.

Örneğin geliştirici, 1 Eylül tarihinde müşteriye teslim bildirimi göndermiş olsun.

Müşteri bir ay boyunca yanıt vermesin.

Bu durumun hukuki sonucu, sözleşme ve somut olayın koşullarına bağlıdır.

Deemed Acceptance nedir?

Deemed Acceptance, belirli şartlar gerçekleştiğinde eserin kabul edilmiş sayılmasını amaçlayan sözleşmesel mekanizmadır.

Örneğin taraflar, usulüne uygun teslim bildirimi sonrasında kararlaştırılmış test süresinde belirli nitelikte bir itiraz yapılmamasına hukuki sonuç bağlamak isteyebilir.

Ancak yalnızca sözleşmeye:

“Beş gün içinde itiraz edilmezse yazılım bütün ayıplarıyla kabul edilmiş sayılır.”

yazılması, her durumda bütün kanuni taleplerin ortadan kaldırılacağı anlamına gelmez.

TBK m.477 neyi düzenler?

TBK m.477, eserin açıkça veya örtülü kabulünden sonraki sorumluluğu düzenlemektedir.

Bu hüküm kapsamında yüklenicinin kasten gizlediği ve usulüne uygun gözden geçirmede fark edilemeyen ayıplardan doğan sorumluluğu devam edebilir.

Ayrıca ayıp sonradan ortaya çıkarsa iş sahibinin durumu gecikmeksizin yükleniciye bildirmesi gerekir.

Bu nedenle kabul tutanağı bulunması, gizli ayıpların bütün hukuki sonuçlarının otomatik olarak ortadan kalktığı anlamına gelmez.

Müşterinin üretim ortamında kullanmaya başlaması kabul sayılır mı?

Üretim ortamında gerçek kullanıcılarla hizmete başlanması, somut koşullarda örtülü kabul iddiası bakımından önem taşıyabilir.

Ancak her üretim kullanımı kesin kabul anlamına gelmez.

Örneğin müşteri, kritik bir operasyonu durdurmamak için sistemi geçici olarak kullanırken daha önce bildirdiği ayıplara ilişkin haklarını açıkça saklı tutmuş olabilir.

Bu nedenle tarafların davranışları, yazışmalar ve kabul kayıtları birlikte değerlendirilmelidir.

10. Ayıplı Yazılım Nedir?

Bir yazılımın ayıplı olup olmadığı, yalnızca müşterinin memnuniyeti üzerinden belirlenmez.

İlgili sözleşmesel yükümlülükler, yazılımın öngörülen amacı ve uygulanabilir hukuk kuralları birlikte değerlendirilmelidir.

Örneğin:

Bir e-ticaret yazılımında ödeme toplamının yanlış hesaplanması önemli bir uygunsuzluk oluşturabilir.

Ancak müşterinin başlangıçta kararlaştırılmamış yeni bir rapor ekranı istemesi aynı şekilde ayıp olarak nitelendirilemeyebilir.

Açık ayıp nedir?

Açık ayıp, eserin olağan ve usulüne uygun gözden geçirilmesi sırasında tespit edilebilecek nitelikteki ayıplarla ilgilidir.

Örneğin test sırasında temel bir kayıt oluşturma fonksiyonunun çalışmaması gündeme gelebilir.

Gizli ayıp nedir?

Gizli ayıp, usulüne uygun inceleme sırasında ortaya çıkarılamayan ve sonradan tespit edilen ayıpları ifade eder.

Örneğin belirli veri hacmine ulaşıldığında sistemin yanlış hesaplama yapması, koşullarına göre sonradan ortaya çıkan ayıp olarak değerlendirilebilir.

Ancak teknik olarak nadir rastlanan her bug'ın otomatik olarak hukuken gizli ayıp olduğu söylenemez.

Yazılımın yavaş çalışması ayıp mıdır?

Somut koşullara göre olabilir.

Örneğin sözleşmede belirli kullanıcı sayısı altında belirli işlem süresi taahhüt edilmişse buna uyulup uyulmadığı teknik testlerle değerlendirilebilir.

Ancak müşteri, belirtilmemiş koşullarda sınırsız performans bekleyemeyebilir.

Bu nedenle performans ölçütlerinin objektif biçimde belirlenmesi önemlidir.

11. Ayıplı Yazılımda Müşterinin Hakları Nelerdir?

Sözleşmenin eser sözleşmesi niteliği taşıdığı ve yüklenicinin ayıptan sorumlu olduğu durumda TBK m.475 önem taşır.

Bu madde, iş sahibine belirli şartlarla seçimlik haklar tanımaktadır.

1. Sözleşmeden dönme

Eser, iş sahibinin kullanamayacağı veya hakkaniyet gereği kabule zorlanamayacağı ölçüde ayıplı yahut sözleşmeye aynı derecede aykırıysa sözleşmeden dönme gündeme gelebilir.

Ancak küçük bir yazılım hatasının bulunması, her durumda sözleşmeden dönme hakkı doğurmaz.

2. Ayıp oranında bedel indirimi

İş sahibi, eseri alıkoyup ayıp oranında bedelden indirim isteyebilir.

Ancak indirim tutarının hangi yöntemle belirleneceği ve ayıbın ekonomik etkisi somut olayda değerlendirilmelidir.

3. Ücretsiz onarım

Aşırı masraf gerektirmemesi koşuluyla ayıbın yüklenici gideriyle giderilmesi istenebilir.

Yazılım projelerinde bu hak, uygun koşullarda hata düzeltme veya belirli teknik onarım çalışmaları biçiminde ortaya çıkabilir.

4. Tazminat

TBK m.475, iş sahibinin genel hükümlere göre tazminat isteme hakkını saklı tutmaktadır.

Ancak tazminatın koşulları, zararın varlığı, kusur ve illiyet bağı somut olayda incelenmelidir.

Müşteri dört hakkın hepsini aynı anda kullanabilir mi?

Seçimlik hakların yapısı ve birbiriyle bağdaşabilirliği değerlendirilmelidir.

Örneğin sözleşmeden dönme ile eseri alıkoyup bedel indirimi isteme aynı anda ve aynı hukuki sonuçla uygulanabilecek talepler değildir.

Buna karşılık şartları varsa tazminat talebi ayrıca gündeme gelebilir.

12. Yazılım Müşterinin Talimatı Nedeniyle Hatalı Çalışıyorsa Ne Olur?

Her yazılım hatasının doğrudan geliştiriciden kaynaklandığı varsayılamaz.

Örneğin müşteri, yazılımcının uyarısına rağmen belirli bir eski altyapının kullanılmasını veya teknik açıdan sakıncalı entegrasyonun yapılmasını istemiş olabilir.

Bu durumda TBK m.472 ve m.476 hükümleri önem taşıyabilir.

TBK m.476 neyi düzenler?

İş sahibinin açık ihtara rağmen verdiği talimattan veya kendisine yüklenebilen başka bir sebepten kaynaklanan ayıp bakımından iş sahibinin ayıba ilişkin haklarını kullanamaması gündeme gelebilir.

Ancak bunun için ayıbın gerçekten ilgili talimattan kaynaklandığı ve kanuni koşulların gerçekleştiği değerlendirilmelidir.

Teknik uyarı nasıl belgelenmeli?

Örneğin geliştirici, müşterinin istediği altyapının belirli yük altında performans sorununa neden olabileceğini teknik açıklamayla bildirebilir.

Bu uyarının:

• Hangi talimata ilişkin olduğu,

• Hangi riskleri kapsadığı,

• Ne zaman yapıldığı,

• Müşterinin nasıl yanıt verdiği

belgelendirilebilir.

Ancak genel bir “Bütün teknik riskler müşteriye aittir.” hükmü, geliştiricinin bütün kanuni özen yükümlülüklerini kendiliğinden ortadan kaldırmaz.

13. Yazılım Gecikirse Müşteri Sözleşmeden Dönebilir mi?

Yazılım geliştirme projelerinde teslim tarihinin gecikmesi ayrı bir uyuşmazlık sebebidir.

Örneğin sözleşmede üç aylık teslim süresi bulunmasına rağmen geliştirme altıncı ayda da tamamlanmamış olabilir.

Bu durumda gecikmenin sebebi ve sözleşmenin hukuki niteliği önemlidir.

TBK m.473 neyi düzenler?

TBK m.473, yüklenicinin işe zamanında başlamaması, işi sözleşmeye aykırı şekilde geciktirmesi veya iş sahibine yüklenemeyen sebeplerle işin kararlaştırılan zamanda tamamlanamayacağının açıkça anlaşılması halinde belirli koşullarla iş sahibine teslim gününü beklemeksizin sözleşmeden dönme imkânı tanımaktadır.

Ayrıca işin yapılması sırasında ayıplı veya sözleşmeye aykırı şekilde sonuçlanacağının açık olması halinde, kanunda öngörülen ihtar ve süre mekanizması gündeme gelebilir.

Her gecikme geliştiricinin sorumluluğunda mıdır?

Hayır.

Örneğin müşteri:

• Teknik gereksinimleri geç iletmiş,

• Gerekli API erişimlerini sağlamamış,

• Test verilerini paylaşmamış,

• Sürekli kapsam değişikliği istemiş,

• Kararlaştırılan onayları geciktirmiş

olabilir.

Bu durumların teslim takvimine etkisi ayrı değerlendirilmelidir.

Müşterinin gecikmesi proje süresini otomatik uzatır mı?

Her durumda değil.

Sözleşmedeki zamanlama, tarafların işbirliği yükümlülükleri, bildirimler ve gecikmenin gerçek etkisi önemlidir.

Tarafların gecikme ve değişiklikleri kayıt altına alması, uyuşmazlıkta sebep-sonuç ilişkisinin değerlendirilmesini kolaylaştırabilir.

14. Yazılım Projesinde Milestone Ödemeleri Nasıl Düzenlenmelidir?

Yazılım geliştirme projelerinde ödeme yükümlülüğü belirli proje aşamalarına bağlanabilir.

Bu aşamalar Milestone olarak adlandırılır.

Örneğin:

Bu yalnızca örnek bir ödeme planıdır.

Ancak milestone ödemelerinin hukuki olarak ne zaman doğacağı açıkça belirlenmelidir.

Milestone tamamlandığında mı ödeme yapılır, kabul edildiğinde mi?

Bu sorunun yanıtı sözleşmeye bağlıdır.

Örneğin taraflar:

• Belirli aşamanın teknik teslimini,

• Kabul testinin tamamlanmasını,

• Müşterinin yazılı onayını,

• Belirli belgenin düzenlenmesini

ödeme koşulu olarak kararlaştırmış olabilir.

Ancak müşterinin onayının tamamen sınırsız ve belirsiz biçimde düzenlenmesi uyuşmazlık yaratabilir.

TBK m.479'a göre ödeme ne zaman muaccel olur?

Eser sözleşmesi bakımından TBK m.479, iş sahibinin bedel ödeme borcunun kural olarak eserin teslimi anında muaccel olacağını düzenlemektedir.

Eserin parça parça teslimi ve bedelin parçalara göre belirlenmesi kararlaştırılmışsa, her parçanın bedeli teslimi anında muaccel olur.

Ancak tarafların ödeme ve kabul mekanizmasını nasıl kararlaştırdığı, uygulanabilir hükümlerle birlikte değerlendirilmelidir.

Fatura kesilmesi teslimi ispatlar mı?

Fatura önemli bir ticari kayıt olabilir.

Ancak tek başına bütün teknik teslimlerin yapıldığını veya işin sözleşmeye uygun şekilde tamamlandığını her durumda kanıtlamaz.

Teslim bildirimi, test kayıtları, erişim belgeleri ve diğer deliller de önemlidir.

15. Müşteri Yazılımı Kabul Etmiyorsa Ödemeyi Tamamen Durdurabilir mi?

Bu soru hem geliştiriciler hem de müşteriler açısından önemlidir.

Ancak her ayıp iddiasının ödemenin tamamını süresiz olarak durdurma hakkı verdiği söylenemez.

Öncelikle:

• Teslimin gerçekleşip gerçekleşmediği,

• Ödemenin muaccel olup olmadığı,

• Yazılımın hangi ölçüde sözleşmeye uygun olduğu,

• İleri sürülen ayıpların niteliği,

• Tarafların karşılıklı edimleri,

• Sözleşmedeki ödeme ve askıya alma hükümleri

incelenmelidir.

TBK m.97 neden önemlidir?

Karşılıklı borç yükleyen sözleşmelerde TBK m.97, karşı edimin ifasını talep eden tarafın kendi borcunu ifa etmiş veya ifasını önermiş olmasıyla ilgili düzenleme içermektedir.

Bu hüküm, ifa ve ödeme uyuşmazlıklarında somut koşullara göre önem taşıyabilir.

Ancak taraflardan birinin her durumda tek taraflı olarak bütün ödemeleri durdurabileceği anlamına gelmez.

Müşteri hangi tutara itiraz ettiğini açıklamalı mı?

Sözleşmesel ve hukuki değerlendirme açısından ihtilafın kapsamının belirlenmesi önemlidir.

Örneğin müşteri, toplam projenin küçük bir modülündeki eksiklik nedeniyle bütün ödeme yükümlülüğünün ortadan kalktığını ileri sürebilir.

Bu durumda ilgili ayıbın kapsamı ve bedel üzerindeki etkisi değerlendirilmelidir.

Uyuşmazlık çıkmaması için ihtilaflı ve ihtilafsız bedellerin nasıl ele alınacağı sözleşmede önceden düzenlenebilir.

16. Geliştirici Ödeme Yapılmadığı İçin Sunucuyu Kapatabilir mi?

Bazı yazılım geliştiricileri, müşteri kalan bedeli ödemediğinde yazılıma veya sunucuya erişimi kapatmayı düşünür.

Ancak bu işlem her durumda hukuken risksiz değildir.

Sözleşmede askıya alma hakkı varsa sistem kapatılabilir mi?

Sözleşmede belirli koşullarla hizmetin askıya alınması düzenlenmiş olabilir.

Ancak bu hakkın kapsamı, geçerliliği, uygulanma şartları ve ilgili yükümlülüklerle birlikte değerlendirme yapılmalıdır.

Örneğin müşterinin kritik veri kayıtlarının sistemde tutulması, hizmetin niteliğine göre ayrıca önem taşıyabilir.

SaaS aboneliğiyle özel yazılım geliştirme aynı mı?

Hayır.

Devam eden abonelik hizmetinin ödeme yapılmadığında askıya alınması ile müşterinin hukuken edindiği bir yazılımın üretim sistemine müdahale edilmesi farklı işlemlerdir.

Özellikle tamamlanmış ve müşterinin kontrolüne devredilmiş bir yazılıma yetkisiz biçimde müdahale edilmesi farklı hukuki sorunlar doğurabilir.

Müşteri verileri silinebilir mi?

Ödeme uyuşmazlığı bulunması, kişisel verilerin veya ticari kayıtların her durumda sınırsız biçimde silinebileceği anlamına gelmez.

Sözleşmedeki veri iadesi, veri güvenliği ve uygulanabilir saklama yükümlülükleri dikkate alınmalıdır.

Özellikle kritik SaaS hizmetlerinde sözleşmenin sona ermesi ile veri iadesi ve erişim kesilmesi süreçlerinin birlikte düzenlenmesi önemlidir.

17. Bakım ve Garanti Süresi ile Yazılımın Kabulü Aynı Şey midir?

Hayır.

Yazılımın teslim edilmesi ve kabul sürecinin tamamlanması, bakım ve destek yükümlülüklerinin de sona erdiği anlamına gelmeyebilir.

Taraflar belirli bakım veya destek hizmetleri kararlaştırmış olabilir.

Warranty Period nedir?

Warranty Period, sözleşmede belirli garanti veya hata giderme yükümlülüklerinin devam edeceği süreyi ifade etmek için kullanılan kavramdır.

Ancak sözleşmesel garanti süresi ile kanuni ayıptan sorumluluk aynı şey değildir.

Ücretsiz hata düzeltme ile yeni geliştirme nasıl ayrılır?

Örneğin teslim tarihinde mevcut bulunan ve sözleşmeye aykırı bir hesaplama hatasının giderilmesi, şartlarına göre ayıbın giderilmesi kapsamında değerlendirilebilir.

Buna karşılık müşterinin sonradan geliştirilmesini istediği yeni bir analitik panelin hazırlanması ayrı geliştirme hizmeti olabilir.

Müşteri kabulden sonra sınırsız revizyon isteyebilir mi?

Hayır, böyle genel bir sonuç doğru değildir.

Kabul sonrası bakım, destek, geliştirme ve revizyon yükümlülükleri sözleşmenin kapsamına ve ilgili kanuni hükümlere göre belirlenmelidir.

Ayrıca kanuni ayıp sorumluluğu da bu sözleşmesel ilişkilerden ayrı değerlendirilmelidir.

18. Ayıplı Yazılımda Zamanaşımı Ne Kadardır?

Bir uyuşmazlıkta yalnızca ayıbın bulunması değil, talebin süresinde ileri sürülüp sürülmediği de önemlidir.

Sözleşmenin eser sözleşmesi niteliğinde olduğu durumlarda TBK m.478 uygulanabilir.

Bu hüküm kapsamında, taşınmaz yapı dışındaki eserlerde ayıptan doğan davalar bakımından kural olarak teslim tarihinden itibaren iki yıllık zamanaşımı öngörülmüştür.

Yüklenicinin ağır kusuru halinde ise kanunda yirmi yıllık süre düzenlenmektedir.

Her yazılım uyuşmazlığında iki yıllık zamanaşımı mı uygulanır?

Hayır.

Bu süreyi bütün yazılım sözleşmelerine ve bütün hukuki taleplere otomatik olarak uygulamak doğru değildir.

Örneğin:

• Ayıptan doğan talepler,

• Ödenmemiş sözleşme bedeli,

• Sözleşmeye aykırılıktan doğan başka talepler,

• Fikri mülkiyet hakkı ihlalleri

farklı hukuki dayanak ve zamanaşımı değerlendirmeleri gerektirebilir.

Zamanaşımı ile ayıp ihbar süresi aynı mı?

Hayır.

TBK m.474 ve m.477 kapsamındaki gözden geçirme ve bildirim yükümlülükleri ile TBK m.478 kapsamındaki zamanaşımı farklı hukuki konulardır.

Dolayısıyla yalnızca zamanaşımı süresinin henüz dolmamış olması, ayıp bildirimi bakımından bütün şartların yerine getirildiği anlamına gelmez.

19. Yazılım Projesinde Müşteri Sürekli Yeni Özellik İsterse Ne Yapılabilir?

Yazılım geliştirme sözleşmelerinde başlangıçta belirlenen teknik kapsam zamanla değişebilir.

Örneğin müşteri, başlangıçta yalnızca web tabanlı CRM istemiş olabilir.

Ancak geliştirme sürecinde:

• Mobil uygulama,

• Yeni ödeme sistemi,

• Yapay zekâ entegrasyonu,

• Gelişmiş raporlama,

• Farklı veri aktarım yöntemleri

talep edebilir.

Bunlar sözleşmede kararlaştırılmış kapsamın dışında bulunuyorsa ek iş değerlendirmesi gündeme gelebilir.

Change Request mekanizması nasıl uygulanabilir?

Taraflar yeni talepleri belirli bir prosedüre bağlayabilir.

Örneğin:

1. Müşteri değişiklik talebini yazılı iletir.

2. Geliştirici teknik etki analizi hazırlar.

3. Ek süre ve bedel belirlenir.

4. Tarafların yetkili temsilcileri değişikliği onaylar.

5. Proje takvimi güncellenir.

Bu model, yeni geliştirme talepleri ile mevcut ayıpların giderilmesini birbirinden ayırmaya yardımcı olabilir.

Geliştirici ek bedeli tek taraflı belirleyebilir mi?

Her durumda değil.

Öncelikle sözleşmede işin kapsamının, bedelin ve kapsam değişikliklerinin nasıl düzenlendiği değerlendirilmelidir.

Örneğin TBK m.480 kapsamında götürü bedel kararlaştırılmışsa yüklenici, işin öngörülenden fazla emek gerektirdiğini ileri sürerek bedeli her durumda tek taraflı artırma hakkına sahip değildir.

Buna karşılık başlangıç kapsamı dışında yeni iş kararlaştırılması veya kanundaki özel şartların gerçekleşmesi farklı değerlendirmeler gerektirebilir.

20. Yazılım Projesi Tamamlanmadan Sözleşme Feshedilirse Ne Olur?

Yazılım geliştirme ilişkisi, proje tamamlanmadan sona erebilir.

Örneğin müşteri bütçesini kaybetmiş veya projeyi başka bir geliştiriciyle sürdürmek istemiş olabilir.

Ancak fesih nedenleri ve hukuki sonuçları birbirinden farklıdır.

TBK m.484 neyi düzenler?

Eser sözleşmesi bakımından TBK m.484, iş sahibinin eser tamamlanmadan önce yapılmış olan kısmın karşılığını ödemesi ve yüklenicinin bütün zararlarını gidermesi koşuluyla sözleşmeyi feshedebileceğini düzenlemektedir.

Ancak bu hükmün uygulanması için sözleşmenin hukuki niteliği ve ilgili şartlar değerlendirilmelidir.

Yüklenici sözleşmeye aykırı davranıyorsa aynı sonuç mu doğar?

Her durumda değil.

Örneğin TBK m.473 kapsamındaki gecikme veya başka borca aykırılık nedenleri farklı talepler gündeme getirebilir.

Bu nedenle iş sahibinin serbestçe projeyi sona erdirmesi ile yüklenicinin sözleşmeye aykırılığı nedeniyle başvuru yapılması birbirinden ayrılmalıdır.

Tamamlanan kodlar kime kalır?

Sözleşmenin sona ermesi, tamamlanmış yazılım üzerindeki fikri hakları ve kaynak kod teslimini kendiliğinden belirlemez.

FSEK hükümleri, mevcut devir veya lisans işlemleri, ödeme koşulları ve ilgili sözleşmeler birlikte değerlendirilmelidir.

Projeye başka yazılım şirketi devam edebilir mi?

Hukuken gerekli kullanım ve değiştirme yetkileri ile teknik materyaller mevcutsa değerlendirilebilir.

Ancak yalnızca yazılımın bir kopyasına sahip olmak, başka bir geliştiriciye bütün mali hakları devretme veya kaynak kodu değiştirtme yetkisinin bulunduğu anlamına gelmez.

Kritik yazılımlarda iş sürekliliği için kullanılan Source Code Escrow: Kaynak Kod Emanet Sözleşmesi mekanizmasını ayrı makalemde ayrıntılı biçimde inceliyorum.

21. Yazılım Teslim ve Kabul Uyuşmazlıklarında Hangi Deliller Önemlidir?

Yazılım uyuşmazlıklarında iddiaların değerlendirilmesi için teknik ve sözleşmesel kayıtların birlikte incelenmesi gerekebilir.

Örneğin:

• İmzalanmış sözleşme,

• Teknik şartname ve SOW,

• Proje takvimi,

• Milestone kayıtları,

• Jira, Trello veya benzeri görev kayıtları,

• Git commit ve sürüm geçmişi,

• Test senaryoları,

• UAT raporları,

• Hata kayıtları,

• Teslim e-postaları,

• Toplantı tutanakları,

• Ödeme dekontları,

• Faturalar,

• Sunucu ve API kayıtları

uyuşmazlığın niteliğine göre önem taşıyabilir.

Jira veya GitHub kayıtları delil olur mu?

6100 sayılı Hukuk Muhakemeleri Kanunu'nun 199. maddesi, elektronik ortamda bulunan veriler dahil olmak üzere uyuşmazlık konusu vakıaları ispata elverişli bilgi taşıyıcılarını belge kapsamında düzenlemektedir.

Ancak bir kaydın elektronik belge olması, belirli bir iddiayı tek başına kesin olarak ispatladığı anlamına gelmez.

Kayıtların doğruluğu, bütünlüğü ve uyuşmazlıkla ilişkisi ayrıca değerlendirilir.

Yazılımın ayıplı olup olmadığı bilirkişiyle incelenebilir mi?

Evet. Somut uyuşmazlıkta teknik uzmanlık gerektiren hususlar bakımından bilirkişi incelemesi gündeme gelebilir.

Örneğin yazılımın sözleşmede kararlaştırılan işlevleri yerine getirip getirmediği teknik olarak değerlendirilebilir.

Ancak bilirkişinin hangi teknik kriterleri esas alacağı önemli olduğundan, sözleşme ve teknik belgelerin açık olması incelemenin niteliğini etkileyebilir.

Delil tespiti yapılabilir mi?

HMK m.400 ve devamındaki şartlar mevcutsa delil tespiti değerlendirilebilir.

Özellikle yazılım sürümlerinin değişmesi, teknik kayıtların kaybolması veya sistemin mevcut durumunun sonradan incelenmesinin zorlaşması ihtimali önem taşıyabilir.

Ancak delil tespiti, taraflara hukuka aykırı sistem erişimi yetkisi sağlamaz.

22. Yazılım Sözleşmesinden Doğan Ödeme ve Ayıp Uyuşmazlıklarında Arabuluculuk Zorunlu mu?

Yazılım şirketleri arasındaki uyuşmazlıklar, tarafların ticari sıfatları ve uyuşmazlığın niteliğine göre ticari dava kapsamında değerlendirilebilir.

6102 sayılı Türk Ticaret Kanunu'nun 5/A maddesi, belirli ticari davalarda dava açılmadan önce arabulucuya başvurulmasını dava şartı olarak düzenlemektedir.

Bu kapsamda konusu bir miktar para olan alacak ve tazminat davaları ile kanunda belirtilen itirazın iptali, menfi tespit ve istirdat davaları önemlidir.

Yazılım geliştirme bedelinin tahsili için arabuluculuk gerekir mi?

Uyuşmazlık TTK m.5/A kapsamında ticari dava niteliği taşıyorsa, kanunda belirtilen dava şartı arabuluculuk uygulanabilir.

Ancak her yazılım sözleşmesinden doğan uyuşmazlığın mutlaka aynı dava şartına tabi olduğu söylenemez.

Tarafların sıfatları ve talebin niteliği belirlenmelidir.

Hangi mahkeme görevlidir?

Yazılım geliştirme sözleşmesinden doğan her uyuşmazlığın otomatik olarak fikri ve sınai haklar hukuk mahkemesinde veya asliye ticaret mahkemesinde görüleceği söylenemez.

Talebin:

• Sözleşmesel bedel alacağı,

• Ayıplı ifa,

• Tazminat,

• Fikri mülkiyet hakkı ihlali,

• Tüketici işlemi

niteliğinde olup olmadığına göre görev ve usul değerlendirmesi yapılmalıdır.

Örneğin yazılımın ticari kullanımıyla ilgili iki şirket arasındaki bedel uyuşmazlığı ile bir tüketicinin dijital ürün satın almasından doğan uyuşmazlık farklı hukuki rejimlere tabi olabilir.

23. Örnek Olay: CRM Yazılımı Teslim Edildi, Ancak Müşteri Son Ödemeyi Yapmıyor

Atlas Yazılım AŞ ile Nova Ticaret Ltd. Şti. arasında özel CRM sistemi geliştirilmesine ilişkin sözleşme imzalandığını düşünelim.

Taraflar toplam 400.000 TL bedel kararlaştırmış olsun.

Ödeme planı:

Atlas Yazılım AŞ, uygulamayı müşterinin test ortamına kuruyor.

Müşteri test sırasında üç konu bildiriyor:

1. Bazı faturalar belirli koşullarda yanlış hesaplanıyor.

2. Raporlama ekranında küçük bir hizalama sorunu var.

3. WhatsApp üzerinden otomatik müşteri bilgilendirme özelliği de eklenmesi isteniyor.

Ancak WhatsApp entegrasyonu başlangıç teknik şartnamesinde bulunmuyor.

Müşteri, bu üç talep tamamlanmadan kalan 150.000 TL'yi ödemeyeceğini bildiriyor.

Atlas Yazılım ise projeyi teslim ettiğini ve müşterinin haksız biçimde ödemeyi ertelediğini savunuyor.

Bu olay hukuken nasıl değerlendirilmelidir?

Birinci mesele: Teslimin gerçekten gerçekleşip gerçekleşmediği

Test ortamındaki kurulumun sözleşmede öngörülen teslim şartlarını karşılayıp karşılamadığı belirlenmelidir.

İkinci mesele: Fatura hesaplama hatasının niteliği

Fatura hesaplama hatası, yazılımın temel işlevini etkileyebilir.

Bu nedenle ilgili hatanın sözleşmesel uygunluk ve ayıp bakımından değerlendirilmesi gerekir.

Üçüncü mesele: Küçük arayüz hatası

Görsel hizalama sorununun kabulü tamamen engelleyecek ağırlıkta olup olmadığı, teknik kriterler ve sözleşme kapsamında değerlendirilmelidir.

Dördüncü mesele: WhatsApp entegrasyonu

Başlangıç kapsamına dahil olmadığı varsayılan entegrasyon, yeni geliştirme talebi olarak değerlendirilebilir.

Ancak önceki yazışmalarda bu özelliğin kararlaştırılıp kararlaştırılmadığı da incelenmelidir.

Beşinci mesele: UAT süreci

Hangi testlerin yapıldığı, sonuçların nasıl kaydedildiği ve sözleşmedeki kabul kriterlerinin ne olduğu belirlenmelidir.

Altıncı mesele: Ayıp bildirimi

Müşterinin tespit ettiği hataları hangi tarihte ve hangi içerikle bildirdiği önemlidir.

Yedinci mesele: Hata giderme yükümlülüğü

Atlas Yazılım'ın hangi hataları gidermekle yükümlü olduğu, TBK m.475 ve sözleşme hükümlerine göre değerlendirilmelidir.

Sekizinci mesele: Ödeme borcunun muacceliyeti

Son 150.000 TL'nin hangi koşulda ödenmesi gerektiği, teslim ve kabul hükümleri kapsamında incelenmelidir.

Dokuzuncu mesele: Ödeme tamamen durdurulabilir mi?

Hataların ağırlığı, karşılıklı edimler ve ilgili sözleşme hükümleri değerlendirilmelidir.

Onuncu mesele: Tarafların teknik kayıtları

Hata kayıtları, UAT sonuçları, Git sürüm geçmişi ve yazışmalar uyuşmazlığın aydınlatılmasında önem taşıyabilir.

On birinci mesele: İhtilafın çözüm yöntemi

Sözleşmeye göre tarafların hangi yükümlülükleri yerine getirmesi gerektiği ve hukuki başvuru yolları belirlenmelidir.

Bu örnekte müşterinin bildirdiği üç talebin tamamı aynı hukuki niteliğe sahip değildir. Fatura hesaplama hatası, arayüzdeki küçük kusur ve sonradan istenen yeni entegrasyon birbirinden ayrılmadan kabul ve ödeme uyuşmazlığı çözülemez.

24. Yazılım Teslim ve Kabul Sözleşmesinde Hangi Maddeler Bulunmalıdır?

Yazılım teslim ve kabul sürecinin öngörülebilir olması için sözleşmenin teknik ve hukuki hükümleri birlikte hazırlanmalıdır.

1. Teknik kapsam ve teslim edilecek ürün

Geliştirilecek yazılımın fonksiyonları, sürümü ve kapsam dışı işlemler belirlenmelidir.

2. Teslim yöntemi

Yazılımın hangi ortamda ve hangi belgelerle teslim edileceği düzenlenmelidir.

3. Teslim bildirimi

Teslimin hangi iletişim yöntemiyle bildirileceği ve bildirimin hangi bilgileri içereceği belirlenebilir.

4. UAT başlangıcı

Kabul testinin hangi şartlarda başlayacağı ve müşterinin hangi test imkânlarına sahip olması gerektiği belirlenmelidir.

5. Kabul kriterleri

Teknik ve işlevsel kriterler objektif biçimde tanımlanmalıdır.

6. Hata sınıflandırması

Kritik, yüksek, orta ve düşük etkili hataların sözleşmesel sonuçları belirlenebilir.

7. Hata düzeltme ve yeniden test

Tespit edilen uygunsuzlukların hangi usulle bildirileceği, giderileceği ve yeniden test edileceği düzenlenmelidir.

8. Şartlı kabul

Belirli düşük etkili eksikliklerle kabul yapılması düşünülüyorsa hangi hakların saklı tutulduğu açık olmalıdır.

9. Deemed Acceptance

Sözleşmede kabul edilmiş sayılma mekanizması düzenleniyorsa, geçerli teslim ve test imkânı ile kanuni sınırlar dikkate alınmalıdır.

10. Milestone ödemeleri

Hangi proje aşamasında hangi bedelin muaccel olacağı belirlenmelidir.

11. Change Request

Yeni geliştirme taleplerinin bedel ve takvim üzerindeki etkisi düzenlenmelidir.

12. Garanti ve bakım

Kabul sonrası destek, hata giderme ve yeni geliştirme hizmetleri birbirinden ayrılmalıdır.

13. Fikri mülkiyet

Kaynak kod üzerindeki hakların devri veya lisansı, FSEK'in şekil ve kapsam şartlarına uygun olarak ele alınmalıdır.

14. Sona erme ve geçiş

Projenin tamamlanmadan sona ermesi halinde kod, dokümantasyon, veri ve ödemelerin durumu belirlenmelidir.

15. Uyuşmazlık çözümü

Uyuşmazlığın niteliğine göre uygulanacak hukuk ve usul hükümleri değerlendirilmelidir.

Bu maddeler bütün projelerde aynı şekilde uygulanmak zorunda değildir. Ancak özellikle kapsamlı yazılım geliştirme projelerinde teslim ve kabul mekanizmasının açık olması hukuki belirsizlikleri azaltabilir.

25. Yazılım Teslim ve Kabul Sürecinde Sık Yapılan Hatalar

Teslimi yalnızca e-posta gönderilmesi olarak görmek: Sözleşmedeki teknik teslim kapsamı incelenmelidir.

UAT kriterlerini belirlememek: Kabulün hangi ölçütlere göre yapılacağı belirsiz kalabilir.

Her teknik hatayı kritik ayıp saymak: Hatanın etkisi ve sözleşmeyle ilişkisi değerlendirilmelidir.

Yeni özellik taleplerini ücretsiz hata düzeltmeyle karıştırmak: Başlangıç kapsamı ve ek iş mekanizması önemlidir.

Müşteriye sınırsız kabul yetkisi tanımak: Belirsiz onay mekanizmaları ödeme uyuşmazlığı yaratabilir.

Sessizliği her durumda kesin kabul saymak: TBK m.474 ve m.477 ile ilgili diğer hükümler değerlendirilmelidir.

Kaynak kod teslimini mali hak devriyle karıştırmak: Teknik teslim ile fikri mülkiyet işlemleri farklıdır.

Fatura düzenlenince işin kesin teslim edildiğini varsaymak: Teknik ve sözleşmesel teslim delilleri ayrıca incelenmelidir.

Ayıp bildirimini geciktirmek: Gözden geçirme ve bildirim yükümlülükleri hakları etkileyebilir.

Kanuni ayıp haklarını sözleşmeyle bütünüyle kaldırmaya çalışmak: Emredici hükümler ve somut sorumluluk koşulları önemlidir.

Gecikme nedenlerini belgelememek: Müşteri kaynaklı gecikmeler ile yüklenici kaynaklı gecikmeler birbirine karışabilir.

Ödeme uyuşmazlığı nedeniyle sistemi aniden kapatmak: Veri güvenliği, erişim hakları ve diğer sözleşmesel yükümlülükler önemlidir.

Projenin sona ermesi halinde tamamlanan işlerin durumunu düzenlememek: Bedel, kaynak kod ve fikri haklar konusunda yeni uyuşmazlıklar doğabilir.

Bütün yazılım uyuşmazlıklarına aynı mahkeme ve zamanaşımı kurallarını uygulamak: Sözleşmenin ve talebin hukuki niteliği belirleyicidir.

26. Yazılım Teslim ve Kabul Hakkında Sık Sorulan Sorular

Yazılım teslim ve kabul süreci nedir?

Geliştirilen yazılımın sözleşmede belirlenen koşullarla müşteriye sunulması ve uygunluğunun değerlendirilmesine ilişkin süreçtir.

UAT nedir?

User Acceptance Testing, yazılımın gelecekteki kullanıcılar tarafından belirlenen iş ihtiyaçları ve kabul kriterlerine göre değerlendirilmesini amaçlayan test sürecidir.

UAT zorunlu mu?

Bütün yazılım sözleşmeleri için genel bir UAT zorunluluğu bulunmamaktadır. Ancak taraflar sözleşmede kabul testleri kararlaştırabilir.

Yazılım teslim edilince ödeme zorunlu hale gelir mi?

Eser sözleşmesi bakımından TBK m.479'da kural olarak bedelin teslimle muaccel olması düzenlenmiştir. Ancak somut sözleşme ve uygulanabilir diğer hükümler birlikte değerlendirilmelidir.

Müşteri yazılımı kabul etmiyorsa ödeme yapmayabilir mi?

Her durumda değil. Ayıp iddiasının niteliği, teslim ve kabul şartları ile karşılıklı borçlar değerlendirilmelidir.

Müşteri yazılımı test etmezse kabul edilmiş sayılır mı?

TBK m.477 kapsamında gözden geçirme ve bildirim yükümlülüklerinin ihmal edilmesi belirli koşullarda kabul edilmiş sayılma sonucunu doğurabilir.

Yazılım üretim ortamında kullanılıyorsa kabul edilmiş midir?

Üretim kullanımı örtülü kabul değerlendirmesinde önemli olabilir. Ancak her durumda kesin kabul anlamına gelmez.

Yazılımda bug bulunması ayıplı eser anlamına mı gelir?

Her teknik hata otomatik olarak aynı hukuki sonuca yol açmaz. Hatanın sözleşmesel uygunluğa ve yazılımın kullanımına etkisi değerlendirilir.

Ayıplı yazılımda müşterinin hakları nelerdir?

Sözleşmenin eser sözleşmesi niteliğinde olduğu ve kanuni koşulların gerçekleştiği durumlarda TBK m.475 kapsamında dönme, bedelden indirim, ücretsiz onarım ve şartlarına göre tazminat talepleri gündeme gelebilir.

Yazılımda gizli ayıp sonradan ortaya çıkarsa ne olur?

TBK m.477 kapsamında sonradan ortaya çıkan ayıbın gecikmeksizin bildirilmesi önemlidir. Yüklenicinin sorumluluğu ilgili kanuni şartlara göre değerlendirilir.

Yazılımcı bütün revizyonları ücretsiz yapmak zorunda mı?

Hayır. Sözleşmeye aykırılık veya ayıbın giderilmesi ile yeni geliştirme talepleri birbirinden ayrılmalıdır.

Change Request nedir?

Projenin başlangıç kapsamındaki değişikliklerin belirli onay, bedel ve takvim mekanizmasıyla yönetilmesini amaçlayan yöntemdir.

Müşteri sürekli yeni özellik talep ederse ne olur?

Taleplerin başlangıç kapsamına dahil olup olmadığı ve değişiklik mekanizması değerlendirilmelidir. Her yeni talebin otomatik olarak ücretsiz geliştirilmesi gerektiği söylenemez.

Yazılım geliştirme gecikirse sözleşmeden dönülebilir mi?

TBK m.473 ve ilgili genel hükümler çerçevesinde, somut koşullar mevcutsa sözleşmeden dönme veya başka talepler değerlendirilebilir.

Kaynak kod teslim edilmezse ne yapılabilir?

Sözleşmesel teslim yükümlülüğü mevcutsa ifa veya diğer hukuki talepler gündeme gelebilir. Fikri mülkiyet hakları ve teknik teslim ayrı değerlendirilmelidir.

Yazılım kabul edilince bütün telif hakları müşteriye geçer mi?

Hayır. FSEK kapsamında mali hakların devri veya lisansı, teslim ve kabul işlemlerinden ayrı değerlendirilir.

Müşteri ödeme yapmazsa geliştirici sunucuyu kapatabilir mi?

Sözleşmenin niteliği, askıya alma şartları, sistem üzerindeki yetkiler ve veri koruma yükümlülükleri dikkate alınmalıdır. Her durumda sınırsız kapatma yetkisi bulunduğu söylenemez.

Ayıplı yazılım davasında zamanaşımı kaç yıldır?

Eser sözleşmesi niteliğindeki ilişkilerde TBK m.478 kapsamında taşınmaz yapı dışındaki eserlerde kural olarak iki yıl; yüklenicinin ağır kusurunda yirmi yıl düzenlenmiştir. Ancak uyuşmazlığın gerçek niteliği ayrıca değerlendirilmelidir.

Yazılım uyuşmazlığında bilirkişi incelemesi yapılabilir mi?

Evet. Yazılımın sözleşmedeki gereksinimlere uygunluğu gibi teknik uzmanlık gerektiren konular bilirkişi incelemesine konu olabilir.

Yazılım bedelinin tahsili için arabuluculuk zorunlu mu?

Uyuşmazlık TTK m.5/A kapsamında dava şartı arabuluculuğa tabi ticari dava niteliğindeyse arabulucuya başvurulması gerekebilir.

Sonuç: Yazılımın Teslim Edilmesi, Kabul Edilmesi ve Bedelinin Ödenmesi Ayrı Hukuki Aşamalardır

Yazılım geliştirme sözleşmelerinde uyuşmazlıklar çoğu zaman yazılımın teknik olarak çalışıp çalışmadığı meselesinden daha kapsamlıdır.

Özellikle işin kapsamının belirsiz olması, kabul testlerinin önceden belirlenmemesi, hata düzeltme ile yeni geliştirme taleplerinin karıştırılması ve ödeme yükümlülüğünün hangi aşamada doğacağının açık olmaması önemli sorunlar yaratabilir.

Türk hukukunda eser sözleşmesine ilişkin TBK m.470 ve devamındaki hükümler, belirli yazılım geliştirme ilişkilerinde teslim, ayıp, kabul ve bedel bakımından uygulanabilir.

Ancak bütün yazılım sözleşmelerinin otomatik olarak aynı hukuki rejime tabi olduğu kabul edilmemelidir.

Müşterinin yazılımı reddetme veya ayıptan kaynaklanan haklarını kullanma imkânı ile yazılımcının sözleşmesel bedel alacağı, somut olayın koşullarına göre değerlendirilmelidir.

UAT testleri, kabul kriterleri, Change Request mekanizmaları ve teslim belgeleri bu süreçte tarafların yükümlülüklerinin açıklığa kavuşturulmasına yardımcı olabilir.

Yazılım geliştirme projelerinde hukuki güvenliğin temel unsurlarından biri, “yazılım tamamlandı” ifadesinin teknik, sözleşmesel ve mali açıdan ne anlama geldiğinin başlangıçta belirlenmesidir.

Bu nedenle yazılım geliştirme sözleşmeleri hazırlanırken teknik gereksinimler, kabul testleri, ayıp giderme, teslim, ödeme ve sözleşmenin sona ermesinin sonuçları birbiriyle uyumlu biçimde düzenlenmelidir.

Hukuki Dayanaklar ve Resmî Kaynaklar

6098 sayılı Türk Borçlar Kanunu

• m.26–27 – Sözleşme özgürlüğü ve sınırları.

• m.97 – Karşılıklı borç yükleyen sözleşmelerde ifa.

• m.112 ve devamı – Borca aykırılığın sonuçları.

• m.117 ve devamı – Borçlunun temerrüdü.

• m.470 – Eser sözleşmesinin tanımı.

• m.471 – Yüklenicinin sadakat ve özen borcu.

• m.472 – Malzemeye ilişkin sorumluluk ve bildirim.

• m.473 – İşe başlama ve yürütme.

• m.474 – Ayıbın belirlenmesi ve gözden geçirme.

• m.475 – İş sahibinin seçimlik hakları.

• m.476 – İş sahibine yüklenebilen ayıp nedenleri.

• m.477 – Eserin kabulü.

• m.478 – Ayıptan doğan davalarda zamanaşımı.

• m.479 – Bedelin muacceliyeti.

• m.480–481 – Bedelin belirlenmesi.

• m.484 – Eser tamamlanmadan tazminat karşılığı fesih.

Diğer mevzuat

• 5846 sayılı Fikir ve Sanat Eserleri Kanunu; özellikle m.2, m.18, m.21–25 ve m.48–52.

• 6100 sayılı Hukuk Muhakemeleri Kanunu; özellikle m.199, m.266 ve m.400 ve devamı.

• 6102 sayılı Türk Ticaret Kanunu; özellikle m.4 ve m.5/A.

• 6325 sayılı Hukuk Uyuşmazlıklarında Arabuluculuk Kanunu.

• 6698 sayılı Kişisel Verilerin Korunması Kanunu.

• Somut ilişkinin tüketici işlemi niteliğinde olması halinde 6502 sayılı Tüketicinin Korunması Hakkında Kanun.

Resmî ve teknik kaynaklar

• Adalet Bakanlığı – Türk Borçlar Kanunu

• Resmî Gazete – 6098 Sayılı Türk Borçlar Kanunu

• Adalet Bakanlığı Arabuluculuk Daire Başkanlığı

• ISTQB – Resmî Yazılım Test Terminolojisi

Yazar

Av. Şenay Yağmur Efe

Bilişim hukuku, yazılım geliştirme ve teknoloji sözleşmeleri, fikri mülkiyet, startup hukuku ve ticari uyuşmazlıklara ilişkin çalışmalar yürütmektedir.

Bu makale 5 Kasım 2026 itibarıyla genel hukuki bilgilendirme amacıyla hazırlanmıştır. Yazılım teslimi, ayıplı ifa, kabul, ödeme ve sözleşmenin sona ermesinin hukuki sonuçları; tarafların sıfatları, sözleşmenin niteliği ve somut olayın özellikleri dikkate alınarak ayrıca değerlendirilmelidir.