Görüntülediğiniz mahkeme kararı henüz kesinleşmemiştir. Yararlı olması amacıyla eklenmiştir.

T.C. BAKIRKÖY 3. ASLİYE TİCARET MAHKEMESİ

ESAS NO : 2016/523 Esas
KARAR NO : 2019/1109

DAVA : Alacak (Ticari Satımdan Kaynaklanan)
DAVA TARİHİ : 31/05/2016
KARAR TARİHİ : 15/11/2019
K. YAZIM TARİHİ : 27/11/2019
Mahkememizde görülmekte olan Alacak (Ticari Satımdan Kaynaklanan) davasının yapılan açık yargılaması sonunda,
GEREĞİ DÜŞÜNÜLDÜ:
Davacı vekili dava dilekçesi ve duruşmadaki beyanlarında özetle; müvekkilinin hak sahibi olduğu lisanslı …… Hastane Bilgi Yönetim sisteminin dava dışı …… Sağ- lık Tesisleri A.Ş.’nin sahibi olduğu … Hastanesi ile davalının sahibi olduğu ….Hos- pital ….. Hastanesi’nde kullanılmak üzere kullanım hakkının verilmesine ilişkin sözleşme ya- pıldığını, sözleşmede tarafların sorumluluklarının açıkça belirlendiğini ,ayrıca sözleşmenin 13. Mad- desinde hastanenin ruhsat alma sürecinin tamamlanmasından sonra ödemelerin başlayacağının karar- laştırıldığını, ancak dava konusu ürünün …. Hospital …. Hastanesi’nin davalı firma ….. ve Medikal Sağlık Hizmetleri A.Ş. ve ….. Group arasında yapılan mutabakat so- nucu ….. Hospital’a satıldığının öğrenildiğini, ne şekilde adlandırılırsa adlandırılsın satış ve devirin müvekkili açısından aynı sonucu doğurduğunu, mevcut fiili durumun müvekkili şirket tarafından davalıya verilen hizmetten doğan alacağını ortadan kaldırmayacağını,aynı konuda Bakırköy ….. Asliye Ticaret mahkemesi’nde açılan …. Esas sayılı davanın açılmamış sayılmasına karar verildiğini beyanla faturaya dayalı 251.526,60 Tl alacağın fatura tebliğ tarihinden itibaren işleyecek avans faizi ile birlikte tahsilini talep ve dava etmiştir.
Davalı vekili cevap dilekçesi ve duruşmadaki beyanlarında özetle ; Bakırköy …… Asliye Ti- caret Mahkemesi’nde açılan ve açılmamış sayılmasına karar verilen …. Esas sayılı dava iti- bariyle derdestlik itirazında bulunduğu, davada 5 yıllık zaman aşımı süresinin dolduğunu,taraflar ara- sında hayata geçmiş bir sözleşme ilişkisi olmadığından davanın yasal dayanağının bulunmadığını, 07/ 03/2007 tarihli sözleşmenin eser sözleşmesi olduğunu, müvekkilinin hisselerini devredildiği süreçte devredilen varlıklar arasında 07/03/2007 tarihli yazılım proğramının bulunmadığını , 07/03/2007 ta- rihli yazılım sözleşmesinin müvekkili açısından hiç bir şekilde hayata geçmediğini , davacıya hiç bir zaman konfirmasyon dahi verilmediğini, davacının akdi ilişkinin varlığına yada yazılım programının müvekkiline ait donanımlara gereği gibi kurulumun yapılıp teslim edildiğine dair delil sunmadığını, yazılım programının sözde tesliminden çok uzun süre sonra fatura düzenlenmesinin kanuna açıkça aykırı olduğunu , davacı tarafça TTK ve VUK ‘na aykırı şekilde düzenlenen faturanın iade edildiğini beyanla davanın reddini savunmuştur.
Dava, taraflar arasındaki yazılım sözleşmesinden kaynaklanan alacağın tahsili talebine ilişkindir.
Her ne kadar davalı taraf cevap dilekçesinde, “dava konusu uyuşmazlığın Bakırköy …. Asliye Ticaret Mahkemesi’nin ….. Esas sayılı dosyasında da dava konusu edildiği”nden bahisle der- destlik itirazında bulunmuş ise de, celp olunan dosyanın tetkikinde, ….. Sistemleri A.Ş tara- fından davalı ….. Sağık Hizm. A.Ş. aleyhine dava konusu 06/11/2012 tarih Seri …… nolu 251.526,60 TL tutarlı faturaya dayanarak alacağın tahsili talebinde bulunulmuş ise de , söz konusu dosyanın takipsiz bırakılması nedeniyle işlemden kaldırıldığı, üç aylık süre içinde yenilen- mediği ve 24/05/2016 tarihi itibariyle davanın açılmamış sayılmasına karar verildiği tespit edilmekle derdestlik itirazına itibar edilmemiştir.
Zamanaşımı def’ine gelince ticari satış ve eser sözleşmesi unsurlarını birlikte barındıran dava konusu sözleşme kapsamında düzenlenen fatura tarihine göre dava tarihi itibariyle borçlar kanununda öngörülen dava sürelerinin dolmadığı anlaşılmakla zamanaşımı def’i de yerinde görül memiştir.
Esasa ilişkin savunmalara gelince, dava konusu uyuşmazlık, taraflar arasında hayata geçmiş yazılım programına ilişkin bir sözleşme ilişkisinin mevcut olup olmadığı, yazılım proğramının davalı tarafa teslim edilip edilmediği, davacıya ait proğramın davalıya ait donanım kurulumun yapılıp yapılmadığı, bu sözleşme kapsamında davacı tarafça düzenlenmiş fatura nedeniyle davacının davalı taraftan alacaklı olup olmadığı, alacağın varlığı ve miktarının tespiti hususunda toplanmaktadır.
Dava konusu sözleşmenin her iki tarafın da ıslak imzasını taşıyan örneği dosyaya sunulmamış olup, davalı taraf bu sözleşmenin kendileri bakımından geçersiz olduğunu iddia etmektedir. Kanunda aksine hüküm olmadıkça sözleşmeler için şekil şartı öngörülmediğinden yazılı olmayan veya imzasız bir sözleşmenin de varlığı mümkündür. Ayrıca taraflar arasında varlığı inkâr edilemeyen (örneğin …..) adreslerine gönderilen yazışmalar ile tarafların kabul ettiği sözleşmeye dair açıklamalar da sözleşmenin eki ve parçasıdır. Bu mahiyette herhangi bir e-mail yazışması olmadığı gibi taraflar arasında uyuşmazlık konusu yazılımın üretimi ve teslimi hususlarında bir sözleşmenin varlığını destekleyecek görüşme tutanakları, proje analizi, proje teslim tutanağı, proje eksiklerinin geri bildirimi, düzeltme ve güncelleme konulu yazışma ve tutanaklar, sunucuya programın yüklendiğini gösteren log kayıtlan vb. deliller de ibraz edilmemiştir.
Burada atipik sözleşmelerden alan yazılım sözleşmelerinin satış ve eser sözleşmeleri ile benzerlik ve farklılıklarını teknik anlamda açıklamakta fayda vardır.
Yazılım piyasasında özel yazılımlar ve paket yazılımlar şeklinde genel bir ayrım yapıl- maktadır.
Özel yazılımlar, yalnızca tek bir müşterinin kullanımına özel olarak, müşterilerin ihtiyaçları ve beklen- tileri ölçüsünde hazırlanır. Burada terzi işi(tailor-made) kavramı güzel bir karşılık sağlamaktadır. Nasıl ki özel dikim kıyafetlerde kumaş hazır ise, özel yazılımlarda hazır kütüphaneler kullanılabilir. Ancak buradaki asıl amaç alıcının kendi ticari yapısı, çalışanları, alışkanlıkları ve beklentilerinin tatmin edilmesidir. Bu nedenle genellikle özel yazılımlarda paket yazılımlarda olduğu gibi kullanılmayacak fazla işlevler bulunmaz. Böylece hem gereksiz işlevler için üretim süresi ve maliyet harcanmamış olur, hem de işlev olarak hafifleyen yazılım daha yüksek performans ile çalışır. Zira özel üretildiği için kapsamlı programlarda oldukça büyük maliyetler ortaya çıkabilmektedir.
Paket Yazılımlar ise, genel kullanım için hazırlanmış, içerisinde programın konusu işi yapan herkes için işlevler barındıran yazılımlardır. Bunlara örnek olarak, ….. gibi yazılımları verebiliriz. Bu yazılımlarda kullanıcılar, ayarlar ve parametrik özelliklerden kendisine göre özel- leştirmeler yapabilir. Kullanıcılar (istisnalar hariç) üreticiden kendisi için özel bir çalışma yapmasını isteyemez. Kullanıcılara bu işlemler için kılavuzluk yapacak dokümanlar sunulabilir, hatta uzaktan destek gibi ayrıcalıklı destek hizmetleri sunulabilir. Paket programlar çok sayıda işletmenin kullanabileceği yapıda hazırlandığı ve tümünün taleplerine cevap vermek üzere tasarlandıkları için maliyetleri özel yazılan programlara göre daha ucuzdur ve kapsam olarak çok daha fazla fonksiyon içerirler. Bu programların negatif yönü ise gereksiz özelliklere de sahip olmaları nedeniyle daha karışık olabilmeleri, genel taleplere özgü bir tasarıma sahip olma- ları ve özellikle muhasebe ve tedarik yönetiminde entegrasyon ve müşterinin mevcut sistemine uyum için özelleştirme gerektirmesidir.
Özel yazılımlar ise konusu bakımından eser sözleşmeleri içerisinde sayılmaktadır. Burada önemli bir detay, bazı özel yazılımların hazır paket yazılımların özelleştirilmesi şeklinde sunulmasıdır. O halde, bu sözleşmede hem bir paket yazılım hem de bunun üzerine bina edilen bir eser söz konusu olmaktadır. Eğer böyle bir durum söz konusu ise, sözleşmede paket yazılım veya lisans (veya benzeri ifadelerle) adı altında bunun açıkça belirtilmesi beklenmelidir. Eğer bu sözleşmede yazılmamış ancak müşterinin bu durumu bildiği anlaşmıyorsa, örneğin program sözleşme öncesinde Tübitak vb. proje desteklerine kayıtlı ise, internet veya bayi kanallarından yaygın olarak satılıyor ise veya müşteriye sözleşme öncesinde yapılan tanıtımlarda hazır program gösterilmiş veya bahsedilmiş ise yine paket yazılımın lisansının da sözleşmede yer aldığını kabul etmek gerekir.
Paket yazılımların maliyetinin düşük olması, çok işlevli olması ve birçok kez denenerek testlerinin tamamlanmış olması şüphesiz satış kolaylığı ve müşterilerce tercih sebebi olacaktır. Ancak bazı müşterilerin beklediği kabiliyetlerin bulunmaması bu yazılımlarda hata olduğu anlamına gelmemektedir. Özel yazılımların aksine proje başında çıktılar müşteriye özel olarak tanımlanmadığı için müşterilerin yazılımın genel kabi- liyetlerini kabul etmesi beklenmektedir. Bu nedenle satın alma yapılmadan önce paket programların demo (deneme) sürümlerinin dikkatlice incelenmesi ve ileride gerekli olabilecek özelliklerin programa dahil edilip edilmeyeceğinin yazılı bir cevapla öğrenilmesi yerinde olacaktır. Zira paket programlarda geliştirme süreçleri yalnızca bir müşteri için değil, genel talebe yönelik yapıldığından dolayı, bir müşteri için hayati önem taşıyan bir güncelleme genel talep göz önüne alındığında öncelikli görülmeyebilir ve uzun bir süre güncelleme gerçekleşmeyebilir.
Burada teknik kabiliyetlerde eksiklik olması halinde, programın amacı göz önüne alınarak bu eksiliğin yarattığı ayıp oranı belirlenmelidir.
Özel yazılımların üretim sürecinin doğru planlanması nihai başarı için son derece önemlidir. Başarılı bir programlama süreci ilk başta yapılan analizin ne kadar detaylı ve sağlıklı yapıldığına bağlıdır. Sözleşmenin ekinde yer alması gereken analiz dokümanının tüm senaryo, gereksinim ve riskleri içermesi beklenmelidir.
Yazılım projeleri dört temel süreçten oluşmaktadır;
İhtiyaç Analizi
•Yazılım projesinin ihtiyaç duyduğu ana işlevler, müşterinin beklentileri, yazılımın kullanılacağı işin senaryoları analiz edilmeli, (….) proje amaçlan ve hedefleri detay- landırılmalıdır.
•Proje varsayımları ve ön gereksinimler ve riskler belirlenmelidir.
•Projede zaman kaybı yaratacak önemsiz veya etkisiz özellikler bir sonraki faza aktarılabilmesi için B planı yani kötü zaman senaryoları üretilmelidir.
• Kullanılacak en doğru yanlım dili, yazılım mimarisi, sunucu gereksinimleri belirlenmelidir.
Tasarım
•Oluşturmak istenilen projenin web tabanlı, mobll veya masaüstü olmasına göre bu platformlara veya cihazlara uygun olması gerekmektedir.
•Web arayüz tasarımı yapılırken genel standartlara uyulmalı, arama motorları tarafından anlaşıla- bilecek şekilde düzenlenmelidir.
• İhtiyaç duyulan modüller tasarlanmalı ve kullanışlılık olarak kolaylığı analiz edilmelidir.
• Kullanıcıyı istediği sayfaya veya sonuca az tıklama ile ulaşması hedeflenmelidir.
• Tasarımların sade ve kullanıcıya güven veren tasarımlar olmasına özen gösterilmelidir.
Kodlama
•Güçlü bir yazılım mimarisi ile çalışılmalı ve sonradan çıkabilecek tüm isteklere kolaylıkla cevap verebilecek şeklide kodlama yapılmalıdır.
•Projenin ekip tarafından bir takım çalışması halinde yönetilebilmesi, raporlanabilmesi, izlenebilmesi sağlanmalıdır.
•Dışarıdan gelmesi beklenen yazılım ve hizmetlerin çok iyi takip edilebilmesi, yaşanan aksaklıklardan müşterilerin bilgilendirilmesi için gerekli iletişim kanalları oluşturulmalıdır.

Test
• Önceden belirlenen senaryoların karşılanıp, karşılanmadığı doğru çıktıyı üretip, üretmediği testleri yapılmalıdır.
* Güvenlik testleri yapılarak, sistemdeki açıklıklar kapatılmalıdır.
• Stres testleri ile sistemin dayanıklılığı test edilmeli, gerekli yerlerde sorgular optimize edilmelidir.
• Yeni oluşan ihtiyaçlar için ek senaryo ve geliştirme gereksinimleri oluşturulmalı, bunlar somut maliyet verileriyle beraber müşteriye bildirilmelidir.
Ticari kaygılarla veya süre kısıtlaması nedeniyle geçiştirilerek yapılan yetersiz analizler üzerine bina edilen proje geliştirme süreçleri tahmin edilen sürelerin kat be kat aşılmasıyla sonuçlanmakta, bunun sonucunda üretici firmaların ödemelerini alamamasına yol açmakta, müşterileri belirsizlik içerisine büyük yatırım kayıpları ile karşı karşıya bırakabilmektedir.
Projelerin tesliminde birden fazla kabul aşaması bulunur. Öncelikle gereksinim analizi (bazı projelerde ekran tasarımlarını da içeren detaylı analizler) taraflarca kabul edilir ve sözleşmeye eklenir. İhtiva ettiği çözüm, yani üretilecek yazılımın analizi bulunmayan bir sözleşme eksik kalacaktır. Çünkü tüm idari ve mali konular sözleşmede belirtilse dahi, sözleşmenin ana unsuru yani konusu belirsizdir. Kapsamı henüz bilinmeyen bir yazılım için sözleşmede belirtilen fiyatın geçerli olduğu kabul edilir ise, kapsamı istediği gibi değiştirme imkânı olan taraf için haksız bir avantaj ortaya çıkacaktır. Bu nedenle özel bir yazılım üretimi sözleşmesinde, yazılımın kapsamı ve analizi sözleşmenin ana unsurlarından biri olmalıdır.
İkinci olarak üretim hattındaki yazılımın test ve onayı yapılır. Burada yazılım halen yazılımcı firmanın sunucularında tutulmaktadır. Ancak sağlanan erişim ile müşteri bu yazılımı görebilmekte ve test edebil- mektedir.Gerçeğe yakın bir sanal ortam kurulmuş, burada entegrasyon, yük ve hız testleri gerçekleştirilmektedir.
Test aşaması bittikten sonra hazırlanan özel yazılım canlıya alınır. Yani gerçekte çalışacağı asıl sunu- cusuna taşınır. Canlı ortama alınan yazılım, müşterilerin gerçek işlerinde zarara neden olabileceğinden, müm- kün olduğunca ana unsurlarında faaliyette olmalı, bir hata ortaya çıktığında ise en kısa zamanda gideri- lebilmelidir. Daha önceki test ortamlarında verilebilecek düzeltme süresinin canlıya geçildikten sonra çok daha kısa olarak öngörülmesi doğal olandır.
Günümüzün hızla gelişen koşullarında güncelleme ve hatadan arındırılmış bir yazılım düşü- nülememektedir. Hatta en bilindik yazılımların dahi, büyük ekipler tarafından özenle üretilmelerine ve farklı senaryolar altında test edilmelerine rağmen defalarca güncellenmeleri gerekmektedir. Bu nedenle her hata veya güncelleme ihtiyacı yazılımın ayıplı olduğu anlamına gelmemektedir. Burada önemli olan temel işlevlerin yerine getirilmesi ve sonradan karşılaşılan hatalara makul bir sürede çözüm sunabilmesidir.
Yazılım üreticileri testlerini daha yazılımın tasarlanması aşamasından itibaren planlanan senaryolara göre yaparlar. Sahada yaşanan farklı durumlar bu senaryoların aşılmasına ve yeni durumların oluşmasına neden olabilir. Ayrıca uyumsuz üçüncü parti yazılım ve donanımlardan kaynaklanan hatalar da oluşabilmektedir.
Tüm bu hataların giderilebilmesi için üreticiye gelen geri dönüşler(feedback) büyük önem taşımaktadır. Geri dönüşlerin mümkün olduğunca oluşan durumun teknik detaylarım, kullanılan sistemi ve hata/ihtiyacın nasıl oluştuğunu tanımlaması gerekmektedir.
Bildirimler telefonla yapıldığında yanlış anlaşılmalar yaşanabilmekte ve gerekli ekran görün- tüleri vb. teknik bilgiler aktarılamadığı için destek beklentileri çoğu zaman karşılamamaktadır. Mail yolu ile yapıldığı zaman ise takibi zor olmakta, konular birbiriyle karışabilmekte, ayrıca bildirimi yapan, bunu ileten ve destek tarafında bununla ilgilenen görevli kişilerin kim olduğu anlaşılamamaktadır.
Sayılan bu sıkıntıların giderilmesi için gerek özel üretilmiş gerekse paket yazılımların güncellenmesi ve geliştirilmesi için günümüzde sıklıkla başvurulan çözüm Yardım Masası(HelpDesk) uygulamalarıdır.
Yardım Masası (HelpDesk) uygulamaları kurum içi ve/veya dışı tüm isteklerin/ sorunların süreçlerin yönetilerek takip edildiği, web tabanlı bir yazılım çözümler olup günümüzde birçok kurumsal hizmet sağlayıcı ve yazılım üreticileri tarafından yaygın olarak kullanılmaktadır. Bu yazılımlar ile hizmet kalitesi devamlılığı için destek ekip personellerinin işlerinin kolaylaştırılması, talep ve isteklerin kategorize edilmesi, ölçüm- lenebilmesi, personel performanslarının ölçümlenebilmesi ve tüm işlemlerin raporlanabilmesi sağlanmaktadır. Yardım masası yazılımları alanında çok sayıda firmanın üretmiş olduğu farklı alternatifler mevcut olup, bu alanda açık ara lider pozisyonda bir yazılım bulunmamaktadır, bu nedenle işlevini gerçekleştirdiği sürece bunlardan herhangi biri kullanılabilmektedir.
Yazılım sözleşmesindeki ayıp ile ilgili değerlendirmeye gelince; genel olarak ayıp, sözleşme konusu şeyin vaat edilen veya dürüstlük kuralı gereği beklenmesi haklı görülen maddi, hukuki veya ekonomik özellikleri taşımamasıdır. Uyuşmazlık konusu yazılım sözleşmelerinde ayıp daha çok ekonomik ayıp olarak karşımıza çıkmaktadır. Borçlar Kanunu m.219’a göre, satıcı varlığını bilmese dahi, kullanım amacı bakımından değerini ve alıcının ondan beklediği faydalan ortadan kaldıran veya önemli ölçüde azaltan ayıplardan da sorumludur.
TBK 219-Satıcı, alıcıya karşı herhangi bir surette bildirdiği niteliklerin satılanda bulunmaması sebe- biyle sorumlu olduğu gibi, nitelik veya niteliği etkileyen niceliğine aykırı olan, kullanım amacı bakımından değerini ve alıcının ondan beklediği faydaları ortadan kaldıran veya önemli ölçüde azaltan maddi, hukuki ya da ekonomik ayıplarının bulunmasından da sorumlu olur.
Burada satıcı tarafından tamamlanmış olan yazılım kısmı, eksik bölüm olmasa da kendi başına kullanılabilir ve alıcı bakımından kabul edilebilirse temerrütten bahsedilebilir. Ancak yazılımın tamamlanan bölümü kullanım için yeterli değilse, alıcının bu haliyle kabul etmesi beklenemez. Diğer bir deyişle, buradaki eksiklik nitelik bakımından da eksiklik oluşturuyorsa ayıbın varlığı söz konusu olacaktır.
O halde, uyuşmazlık konusu olayda öncelikle vaat edilen özellikler, buradan belirlenemeyenler için beklenmesi haklı görülen özelikler dikkate alınmalıdır.
Vaat edilen özellikler bakımından, özellikle yazılım gibi çok teknik bir konuda satıcının bilgilendirme yükümlülüğünü de unutmamak gerekir. Alıcının alım kararım etkileyebilecek, ona ileride büyük masraf ve ek yük getirecek konularda, satıcının mutlaka gerekli bilgilendirmeyi yapması gerekir. Bu bilgilendirmeyi yaptığını ispat yükü satıcıya aittir. Gelişmiş ülkelerde satılan ürünlerle ilgili en basit konularda dahi kullanım kılavuzlarında detaylıca uyan ve bilgilerin verilmesinin sebebi işte bu yükümlülükten kaynaklanmaktadır.
Yazılım sözleşmeleri özelinde değerlendirildiğinde; geliştirmeye ve hatta sözleşmenin akdinden önce yazılımın ihtiyaç(gereksinim) analizinin, kullanım senaryolarının, ekran tasarımlarının, test prosedürü ve kabul şartlarının hazırlanması büyük önem taşır. Ayrıca, yazılımın kullanıcı ve işlem sınırları, üzerinde çalışacağı donanımın özellikleri, gerekli ek kütüphane ve diğer yazılım lisansları mutlaka belirtilmelidir. Ancak bunlar üzerinde bir mutabakat sağlanır ise yazılımın toplam geliştirme süresi ve maliyetinden bahsedilebilir. Diğer türlü son derece belirsiz ve ileriki aşamalarda sözleşmenin her iki tarafı için de sakıncalı sonuçlar doğuracak bir proje söz konusu olur.
Piyasada yazılım firmaları tarafından, maliyetler ve diğer rakipler bahane edilerek yukarıda belirtilen süreçlerin yapılmasından imtina edildiğini görülmektedir. İşi kaçırmamak adına bu tür risklere giren yazılım firması (satıcı), yeterli bilgilendirme yapılmamasının sonucu olarak ortaya çıkan her türlü zarar ziyanı da üstlenmeyi kabul etmelidir.
Sonuç olarak, bir yazılım sözleşmesinde sadece işin finansal boyutuna yer verilmesi yeterli değildir. Bu yazılım hakkında yukarıda sayılan şekilde bilgilendirmenin yapılması, sözleşme öncesinde teknik belgelerin oluşturularak sözleşmenin ekine (veya taraflarca kabul edilen başka bir iletişim kanalına) konulması büyük önem taşır.
İkinci olarak, tüm analizlere ve planlamalara rağmen eğer sözleşmede belirtilmeyen konular var ise, dürüstlük kuralına uygun olarak beklenmesi gereken asgari nitelikler belirlenmelidir. Burada beklentiden kasıt, alıcı tarafında sözleşmenin kurulması anında var olan beklentidir. Eğer yazılımın geliştirilmesi sırasında yeni talep ve gereksinimler ortaya çıkmış, her iki tarafın da kabulü ile bu yeni gereksinimler de sözleşmeye eklenmiş ise, bu eklere bağlı beklentiler de değerlendirmeye alınır. Sözleşmelerde şekil şartı bulunmadığından yazılım üretimi sırasında oluşan bu tür yeni durumların mutlaka özel yazılı imzalı bir belgeye dayanması gerekmez. Taraflar sözlü olarak yeni durumu onaylar ve bir irade buluşması oluşur ise ortada geçerli bir sözleşme vardır. Ayrıca, bir taraf sessiz kalır ama eylemleri ile bu yeni duruma uyduğunu açık bir şekilde ortaya koyarsa, yine bir geçerli bir irade buluşmasının var olduğu söylenebilecektir.
Genel olarak yazılımlar için beklenebilecek asgari koşullar şunlar olabilir:
I.Yazılımın uyumlu olduğu beyan edilmiş bir donanım üzerinde kurulabilir/yüklenebilir olması veya satıcı tarafından tüm bileşenleriyle kurulmuş olması,
II.Yazılım üzerindeki komponentler(araçlar) kullanıldığında (örneğin bir butona basıldığında) olması beklenen işlemlerin makul bir sürede gerçekleşmesi, arayüzlerin ekran üzerinde kullanımı engellemeyecek şekilde açılabilmesi,
III.Yazılımın, veri alışverişi yaptığı diğer bileşenler ile makul bir süre içerisinde, kullanıcı tarafından baş edilemeyecek hatalarla karşılaşmadan ve veri kaybı yaşanmadan entegre olarak çalışması,
IV.Yazılımın çalışması sırasında esaslı sayılabilecek şekilde güvenlik sorunları oluşturmaması (örneğin, bir kullanıcının şifresini kullanmadan giriş yapamaması veya yetkisi olmayan bir bölüme girememesi, yetkisiz bir işlemi yapamaması),
V. Yazılım ile kaydedilen verilerin veritabanında kayıpsız bir şekilde saklanması,
VI. Banka, muhasebe, üretim gibi üçüncü parti sfstem/yazılımlara entegrasyon planlanmış ise, yazılımın bunların işlevlerini hatalı bir şekilde önlemeyecek/durdurmayacak/kesmeyecek şekilde madde lll’e uygun olarak çalışabilmesi,
VII. Sistem üzerinden alınacak raporların ilgili tablolardaki tüm başlıklara (sütunlara) var olan tüm bilgileri aktarabilecek şekilde çalışması, raporlama araçlarının II nolu maddeye uygun olarak çalışması ve raporların makul bir sürede alınabilmesi.
Bu koşullar belirlenirken unutulmaması gereken konu, yazılımı kullanan tarafın (alıcı) yazılımın teknik alanında büyük bilgi ve tecrübeye sahip olması gerekmediğidir. Teknik bilgiyi ve tecrübeyi sağlaması gereken bu konuda uzmanlaşmış olan yazılım firması(satıcı)dır. Eğer istisnai olarak yazılımın kullanımında özel teknik bir bilgi gerekiyorsa, bu konuda yazılım firması tarafından mutlaka sözleşme zamanında uyarılması ve aksi karartaştırılmamışsa eğitiminin verilmesi gerekir. Burada teknik bilgiden kasıt yazılım ve donanım bilgisidir. Örneğin, bir muhasebe programını kullanacak kişinin beyanname nedir ve nasıl doldurulur gibi bilgilere zaten sahip olması beklenebilir. Ancak yazılımın kullanımı sırasında hatalı beyannamenin silinmesi için veritabanına erişim sağlanıp buradan SQL kodu yazılarak silinme yapılacaksa, muhasebe programının satıcısı olan yazılım firması, veritabanı yazılımını sağlayan kendisi olmasa dahi, bu konuda baştan uyanlarını yapmalı, gerekli eğitimleri vermelidir. Zira bu bilgi programın konusu olan muhasebe isterine ait bir bilgi değildir. Bu yazılıma özgü teknik bir bilgidir.
Yazılım firması “A veri tabanı veya X sunucusunu ben tedarik etmemiştim, bunlar üzerinde bir yetkim de yok” savunması ile sorumluluktan kaçamaz. Zira bunlar, analiz ve sözleşme aşamasında daha en baştan belirlenebilir teknik konulardır. Eğitim ihtiyacı da kolaylıkla öngörülebilen ve bedeli faturalanchnlabilen bir konudur. Eğer ileride bir yetki veya kapasite problemi doğabilecekse bu risklerin sözleşme öncesinde bildirilmesi gerekir.
Entegrasyondan doğabilecek sorunlarda, satıcı ancak bunları açık ve net bir şekilde açıkladığı ölçüde sorumluluktan kurtulabilir. Örneğin, web sunucusu yazılım firmasının uhdesinde değilse, “yazılımın verileri göndereceği web sunucusunda bekleme süresi min. 120 saniye olmalıdır. ABC portlarından gelecek veriler için yetkilendirme yapılmalıdır. Satıcı sunucu üzerindeki yapılandırma hatasından sorumlu olmaz.” şeklindeki bir madde hakkaniyete uygun ve alıcıyı gerekli şekilde uyaran bir hükümdür. Bu yaklaşımla, “Entegrasyondan doğacak her türlü sorunlar satıcının sorumluluğunda değildir.” şeklindeki bir sözleşme maddesi de uygun olmaz. Meğer ki alıcı bu sorunların ne olabileceği hakkında öngörüde bulunabilecek niteliklere sahip olsun. Diğer türlü alıcı tam olarak ne olduğunu bilemediği bir yükün altına girmiş olur ki, burada bir iade uyuşmasından bahsetmek zordur. Bu durumda yanılma veya özel işlem şartı hükümlerine başvurulduğunu görmekteyiz. İleride böyle sorunların yaşanmaması için en doğrusu daha analiz yapılırken ileride sorun çıkması muhtemel her türlü entegrasyon hataları için uyanları yapmak olacaktır. Başta kısa bir zaman kaybıyla geçilebilen bu süreç, ileride sorun yaşandığında içerisinden çıkılamayacak zaman, emek ve maddi kayıplara neden olabilmektedir.
Zaten hukuki uyuşmazlık anlamında en büyük sorunlar karma yazılımlarda ortaya çıkmaktadır. Zira paket yazılımlarda alman ürün baştan bellidir, müşterinin bunu deneyip görme şansı da bulunmaktadır, özel yazılımlarda ise somut vaat gerçekleşmemiş ve alıcı tatmin edilememişse projenin başarısız olduğu açıktır. Oysa karma projelerde üretici kadar partner de büyük önem taşır. Başta analiz doğru yapılmaz, müşteri bilgilendirilmez veya süreç doğru yürütülmez ise, dünyanın en başarılı yazılımı dahi olsa projenin başarısız olması kaçınılmaz olur. Bu durumda, üretici için birçok yerde çalışan yazılımın bu tek müşteride çalışmaması olağan dışı bir durum iken, müşteri gözünde önceki başarıların hiçbir önemi yoktur. Sonuçta, kendi işyerinde yazılım gerektiği gibi çalışmıyorsa veya beklenen işlevlere haiz değilse, bunun partnerden mi yoksa üreticiden mi kaynaklandığıyla ilgilenmek istemez.
Alıcı yazılımın arayüzü ve buradaki işlevlerle ilgilenmelidir. Örneğin, bir butona tıkladığında ilgili işin yapılmasını bekler. O iş yazılımsal bir hatadan mı, yoksa hatalı bir entegrasyondan mı kaynaklanmıştır, bu alıcının çözmesi gereken bir sorun değildir. Gerçekten de yazılımın nihai kullanıcısı-tüketicisi konumundaki alıcıdan, yazılımlar-arasındaki veri alışveriş protokolünü, hataların gerçekleşme nedenlerini, veritabanı yapısını veya sunuculardaki teknik detayları bilmesini beklemek hakkaniyete uygun olmayacaktır. Bu açıklamalar genel prensipler olup, aksine yükümlülükler sözleşme ile alıcıya verilebilir.
Yazılımın analizinin doğru yapılması, gereksinimlerin doğru belirlenmesi için bu alanda daha önce defalarca projeler üreten yazılım firmasının tecrübesi ön plândadır. Kendisine iletilen beklentileri çözecek tüm işlevleri analize koymalıdır. Teknik analiz tamamlandıktan sonra bu artık yapılacak yazılımın anayasası haline gelmektedir. Eğer analiz sırasında müşteri ihtiyacını saklamış veya ihmalle söylemeyi unutmuş ise elbette bundan yazılım firması sorumlu tutulamaz. Ancak kendisine iletilen ihtiyacı analize koymayan yazılım firması projenin kapsamını hatalı belirlediğinden sorumluluk alır.
Yazılımın geliştirilmesi sırasında alıcının pek bir etkisi olduğunu söyleyemeyiz. Tasarım ağırlıklı işlerde, alıcının kurumsal kimlik ve görseller gibi bazı bilgileri verme yükümlülüğü vardır. Ancak bunların dışında yazılımın geliştirildiği platform ve diğer her türlü teknik detay yazılım firmasının sorumluluğundadır.
Yazılım geliştirildikten sonra, test ortamına alınmalı ve analiz sırasında belirlenen test senaryolarına tabi tutulmalıdır. Eğer bu aşamaya kadar testle ilgili alıcıya bilgi verilmemişse, başta senaryolar oluşturulmamış veya test ortamı hazırlanmamışsa, yaşanacak mağduriyetten yine yazılım firmasının sorumluluğu doğar.
Piyasada test etme işi genellikle alıcıya bırakılıyorsa da, bu hatalı bir uygulamadır. Test etme de ciddi tecrübe ve bilgi gerektirir. Profesyonel yazılım firmaları ….. isimli personeller barındırır, hatta genel için yapılan bir yazılım var ise beta testleri için yazılımı halka ücretsiz sunar. Testin doğru yapılması üreticinin esas sorumluluklarından biridir. Alıcı testleri gerektiği gibi yapmadı bahanesiyle bu sorumluluktan kurtulmak mümkün değildir.
Test ve sonrasında canlı ortama alınan yazılımın kurulması ve canlı ortamdaki ilk testlerin yapılması da (aksi sözleşme ile belirtilmediyse) yazılım firmasının sorumluluğundadır. Burada paket yazılımlar ile özel yazılımlar arasında bir fark vardır.
Paket yazılımlarda kurulum genellikle setup ismi verilen standart kurulum dosyalarından yapılır. Kurulum aşamasında kullanıcıya kılavuzluk edecek doküman ve videolar üretici tarafından sağlanır. Eğer diğer müşterileri etkilemeyen özel bir talep var ise, bunun için ek destek ücreti talep edilebilir.
Özel yazılımlarda ve karma yazılımlarda ise genellikle bir kurulum (setup) dosyası olmaz. İşin teknik doğasından dolayı, aksi belirtilmedikçe kurutumu yapan yazılımı tedarik edendir.
Yazılımın diğer yazılım ve sistemlerle entegrasyonu nihai test aşamasında değil, daha en başta analiz aşamasında düşünülmesi ve planlanması gereken bir konudur. Entegrasyonla ilgili bilgiler, riskler ve ileride yapılması muhtemel giderler alıcıya sözleşme öncesinde bildirilmelidir. Diğer türlü teknik konulara hakim olmadığı için sözleşmedeki maddeleri dahi tam olarak anlayamayan alıcı, öngöremediğl riskler ile karşı karşıya kalacak, projelerin başarısız olması kaçınılmaz hale gelecektir. Kendisine aktarılan kadar tekniğe hakim olabilen alıcının, ancak bu bilgiler ışığında sözleşmeyi imzalayacağı açıktır. Burada neden basiretli tüccar gibi davranıp sözleşmeyi imzadan kaçınmadığı gibi bir sorgulama da doğru olmaz, böyle geniş bir sorumluluk, her alıcının, her yazılım alışverişinden önce bu alanda ciddi bir bilgi edinmesini gerektirecektir. Bu durum, örneğin, ticari araç alan kişiden hava yastığının, motor ve şanzımanın detaylıca çalışma prensibini bilmesini beklemek gibidir. Veya ….. tezgahı alacak kişinin, içerisindeki tornanın teknik toleransını bilmesi gibidir. Kullanıcı bu tolerans katsayısı, işleme yapan metalin sertliği vb. ile ilgilenmez, bilgisayardan gönderdiği tasarımın makinadan nasıl çıktığına bakar.
Yazılımcı firma tarafında ise, yazılım sözleşmeye uygun hazırlanıp teslim edildikten sonra, müşterinin yazılımı kullanıp kullanmadığı önem taşımaz. Yazılım firması üretim sırasında personel, sistem, işletme vb. maliyetlerin tamamını karşıladığından dolayı, yazılım hiç kullanılmasa dahi buna dayanarak indirim talep edilmesi hakkaniyete uygun olmaz.
Sonuç olarak; alınan yazılımın tipine göre, işin hukuki niteliği bir satış sözleşmesi, eser sözleşmesi veya karma tip sözleşme olabilmektedir. Uyuşmazlığın değerlendirilmesinde öncelikle yazılımın tipi belirlen- melidir. İkinci olarak, bu tip bir yazılımda tarafların yükümlülüklerinin net bir şekilde ortaya konması gerekir. Yukarıda detaylıca anlatıldığı gibi, teknik doğasından dolayı satıcının bilgilendirme, doğru yönlendirme ve süreci gereği gibi takip etme yükümlülüğü vardır. Sözleşmede açıkça belirtilmediği ve gerekli bilgilendirme yapılmadığı sürece satıcı işin teknik kapsamındaki konulan alıcıya bırakamaz. Alıcının asli yükümlülüğü, ihtiyaçlarını en başta belirleyip satıcıya iletmek, satıcının analizlerinde belirtmiş olduğu donanım ve diğer yazılım gereksinimlerini sağlamak, yazılımın bedellerini ödemek ve yazılımı kullanım kılavuzuna uygun olarak kullanmak olabilir. Bunun dışında kalan, aksi sözleşmeyle açıkça belirtilmediği sürece, senaryo ve analizlerin oluşturulması, yazılımın kodlanması, kurulması ve test edilmesi tamamıyla yazılım firmasının sorumlu- luğundadır. Yazılım firmalarının işi hızlı yapma veya maliyetleri düşürme gibi gerekçelerle analiz ve bilgilen- dirmeyi eksik yapma hakkı bulunmamaktadır. Eğer yazılım sözleşmeye uygun hazırlanıp teslim edilmiş ise, müşterinin yazılımı kullanıp kullanmadığı önem taşımaz. Yazılım hiç kullanılmasa dahi buna dayanarak indirim talep edilmesi hakkaniyete uygun olmaz.
Bu hususlar, genel olarak her sözleşmede uygulanması gereken ilkeler olup konunun irdelenmesi ve ideali ortaya koyma amacıyla belirtilmiştir.
Dava konusu somut olaya dönüldüğünde; taraflar arasında akdedildiği beyan olunan sözleşme incelendiğinde, davalı için özel olarak hazırlanacak bir yazılımdan bahsedildiği anlaşılmaktadır. Davacı yazılım firması bu yazılımın paket yazılım vasfında olup olmadığı hakkında herhangi bir beyanda bulunmadığı gibi, dosyaya bunu gösteren bir delil sunmamıştır.
Sözleşmenin içerisinde yazılımın konusunun ve başlıklarının belirtildiği ancak işlevlerinin net olarak anlaşılabileceği bir analizin eklenmediği görülmektedir. Davacı belirtilen şekilde bir analizi dilekçelerinde de sunmamıştır. Bu durumda davacının bilgi verme yükümlülüğünü tam olarak yerine getirdiğini söylemek mümkün değildir.
Yazılımın davalıya teslim edildiğine ilişkin herhangi bir tutanak bulunmadığı gibi, bunu gösterecek herhangi bir yazışma da sunulmamıştır.
Yazılımın hazırlandığı ve gerçekten teslim edilmek istendiği ancak yazılım alacaklısı duru- mundaki davalının bundan kaçınarak temerrüde düştüğüne dair iddia ve delil de ileri sürülmemiştir. Böyle bir temerrüt halinde, mahkemece belirlenecek bir yere veya yazılımın o tarihteki halinin değiş- tirilemeyeceği tarafsız bir sunucu yer sağlayıcı üzerine veya bir sistem kopyasının noter/iadeli taahhütlü posta kanalıyla yazılımın saklanması mümkündür. Dosyada bu yönde de iddia ve beyan bulunmamaktadır.
Şu durumda, uyuşmazlık konusu yazılımın dava tarihinde (günümüzde) hazır olması bir anlam ifade etmeyecektir. Zira olayın üzerinden geçen uzun zaman zarfında yazılımın üretilmesi veya hataların giderilmesi mümkündür.
Mahkememizce verilen ara karar üzerine davacının ticari defter ve kayıtları üzerinde Ankara ….. Asliye Ticaret Mahkemesi aracılığıyla yapılan bilirkişi incelemesi hususunda SMMM …… tarafından ibraz olunan 02/08/2018 tarihli raporda; davacının ibraz olunan yevmiye, kebir ve envanter defterlerine göre dava tarihi itibariyle davalıdan şüpheli duruma düşen 251.526,60 TL alacak kaydının bulunduğu tespit edilmiştir.
Yukarıda yapılan açıklamalar çerçevesinde, davalının ticari defter-belgeleri ve tüm dosya üzerinde mahkememizce atanan Bilgisayar Mühendisi …… ve SMMM …… tarafından bilirkişi incelemesi sonucu düzenlenen raporda;
”Dava konusu itilafın davacının davalı adına düzenlediği 06/11/2012 tarih, Seri: ….. nolu 251.526,60 TL tutarlı faturaya dayalı alacak talebinden kaynaklandığı, sahibi lehine delil teşkil eden davalının 2012, 2013, 2014, 2015 ve 2016 yılları ticari defterlerine göre dava tarihi itibariyle davalının davacıya borcunun bulunmadığı, taraflar arasında akdedildiği beyan edilen sözleşme incelendiğinde davalı için özel olarak hazırlanacak bir yazılımdan bahsedildiği, davacı yazılım firmasının bu yazılımın paket yazılım vasfında olup olmadığı hakkında herhangi bir beyanda bulunmadığı gibi, dosyaya bunu gösteren bir delil sunmadığı, sözleşmenin içerisinde yazılımın konusunun ve başlıklarının belirtildiği ancak işlevlerinin net olarak anlaşılabileceği bir analizin eklenmediği, davacının belirtilen şekilde bir analizi dilekçelerinde de sunmadığı, bu nedenle davacının bilgi verme yükümlülüğünü tam olarak yerine getirdiğinin söylenemeyeceği, yazılımın davalıya teslim edildiğine ilişkin herhangi bir tutanak bulunmadığı gibi, bunu gösterecek herhangi bir yazışmanın da sunulmadığı, yazılımın hazırlandıktan sonra gerçekten teslim edilmek istendiği ancak yazılım alacaklısı davalının bundan kaçınarak alacaklının temerrüdüne düştüğünü, uyuşmazlık konusu yazılımın, uyuşmazlık tarihinde, gerçekten davacı tarafından tamamlanıp davalıya sunulduğunu gösteren delillerin sunulmadığı, bu durumda davacının dava konusu fatura nedeniyle davalıdan alacaklı olduğu hususunun ispata muhtaç olduğu” hususu45 değerlendirilmiştir.
Davacının dava dilekçesinde açıkça yemin deliline dayandığı görülmekle 13/09/2019 tarihli celsede davacı tarafa HMK 225 md. gereğince yemin delili hatırlatılarak yemin deliline başvurup başvurmayacakları hususunda beyanda bulunmaları, yemin deliline başvurulacak ise yemin metnini hazırlayıp dosyaya sunmak üzere 1 haftalık kesin süre verilmiş ve bu süre içinde ara karar gereği yerine getirilmediği takdirde yemin deliline dayanmaktan vazgeçmiş sayılacakları ihtar olunmuştur.
Mahkemece verilen kesin süre ve yapılan ihtarata rağmen davacı taraf verilen süre içinde yemin deliline başvurmamıştır.
09/10/2019 tarihli dilekçe ekinde sunduğu e-maillerinde davalı şirket ile herhangi bir ilgisinin olmadığı anlaşılmıştır.
Her ne kadar davacı davalı adına düzenlediği 06/11/2012 tarih Seri ….. nolu 251.526,60 TL tutarlı faturaya dayanarak davalı taraftan alacak talebinde bulunmuş ise de; söz konusu faturanın davalı tarafça yasal süre içinde noter ihtarnamesi ile itirazen iade olunduğu, ayrıca fatura düzenlenmesinin alacağın varlığını ve miktarını ispata tek başına yeterli olmadığı, davacı tarafça fatura içeriği yazılımın davalıya teslim edildiği, kullanıma hazır hale getirildiğine dair yasal delil sunulmadığı gözetilerek sübuta ermeyen davanın reddine karar verilip aşağıdaki şekilde hüküm kurulmuştur.

H Ü K Ü M : Yukarıda açıklanan nedenlerle;

1-DAVANIN REDDİNE,

2-Harçlar Kanunu’na göre hesaplanan ve tahsili gereken 44,40 TL karar ve ilam harcının peşin alınan 4.295,45 TL harçtan mahsubu ile Hazine’ye irat kaydına, bakiye 4.251,05 TL harcın karar kesin- leştiğinde ve istek halinde davacıya iadesine,

3- Davacı tarafından sarf olunan yargılama giderinin kendi üzerinde bırakılmasına,
Davalı tarafça sarf olunmuş yargılama gideri bulunmadığından bu hususta karar tesisine yer olmadığına,
Sarf olunmayan gider/delil avanslarının karar kesinleştiğinde ilgili tarafa iadesine ,

4-Kendisini vekil ile temsil ettiren davalı lehine red olunan dava değerine göre hüküm tari- hinde yürürlükte bulunan Av. Kan. ve AAÜT gereğince takdir olunan 21.041,60 TL vekalet ücre- tinin davacıdan tahsil edilerek davalı tarafa ödenmesine dair,

5235 sayılı Kanunun geçici 2’nci maddesine göre, Bölge Adliye Mahkemeleri’nin kurulmasına ve 20 Temmuz 2016 tarihinde göreve başlamalarına dair kararların 07/11/2015 tarih ve 29525 sayılı Resmî Gazete’de ilan edildiği anlaşılmakla; 6100 sayılı Hukuk Muhakemeleri Kanununun 341 ilâ 360’ncı madde hükümleri uyarınca, mahkememize veya aynı sıfattaki başka bir mahkemeye verilecek dilekçe ile kararın tebliğinden itibaren iki hafta içerisinde veya istinaf dilekçesi kendisine tebliğ edilen taraf,başvuru hakkı bulunmasa veya başvuru süresini geçirmiş olsa bile, mahkememize veya aynı sıfattaki başka bir mahkemeye vereceği cevap dilekçesi ile iki hafta içerisinde istinaf yolu açık olmak üzere davacı vekili ile davalı vekilinin yüzüne karşı verilen karar açıkça okunup, usulen anlatıldı . 15/11/2019

Katip …

Hakim …