Yazılım hizmet sözleşmesi örneği: madde madde kontrol listesi

Yazılım hizmet sözleşmesi örneği arıyorsanız, indirdiğiniz metni imzalamadan önce dokuz maddenin içini projenize göre doldurmanız gerekir: kapsam ve değişiklik talebi, kabul ve test süresi, kaynak kod ve fikri haklar, garanti, bakım ve SLA, ödeme planı, gizlilik ve KVKK, fesih ve devir, sorumluluk sınırı. Hazır bir şablon bu maddelerin başlığını verir; projenize özgü içeriği vermez.

Ben Emre Aydın, UlvionTech'te kıdemli yazılım mühendisiyim; avukat değilim. Bu yazı Ekim 2026 itibarıyla mevzuat.gov.tr'de yayımlanan 6098 sayılı Türk Borçlar Kanunu (TBK) (yeni sekmede açılır), 5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK) (yeni sekmede açılır) ve 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) (yeni sekmede açılır) metinlerine dayanır ve hukuki görüş değildir. Sözleşmenizi imzalamadan önce bir avukata okutmanızı öneririm. Benim katkım işin teknik tarafı: bir maddenin yazılımda neye karşılık geldiğini ve eksik kaldığında projenin hangi aşamasında sorun çıkarabileceğini anlatmak.

Yazılım hizmet sözleşmesi hangi maddeleri içermeli?

Bir yazılım hizmet sözleşmesi en az dokuz konuyu yazılı olarak çözmelidir: ne yapılacağını, işin nasıl kabul edileceğini, kodun kime ait olacağını, hataları kimin düzelteceğini, yayından sonra sisteme kimin bakacağını, bedelin ne zaman ödeneceğini, verinin nasıl korunacağını, işin nasıl biteceğini ve bir zarar doğarsa kimin ne kadar sorumlu olacağını. Dokuz maddenin kısa özeti şöyle:

Dokuz madde aynı sırayla okunmak zorunda değildir. Okumaya kapsamdan başlayın, sonra kabule ve kaynak koda geçin; ödeme, garanti ve fesih maddelerinin anlamı bu üçüne bağlıdır. Kapsamı belirsiz bir sözleşmede kabul kriteri yazılamaz, kabul kriteri olmayan bir sözleşmede de son ödemenin ne zaman yapılacağı belirsiz kalır. Teklif aşamasında bu konuların bir kısmını konuştuysanız, yazılım tekliflerini karşılaştırma rehberimiz teklifteki boşlukları sözleşmeye taşımadan önce yakalamanıza yardım eder.

Yazılım sözleşmesinin hukuki niteliği nedir: eser, hizmet ya da vekâlet?

Yazılım sözleşmesinin hukuki niteliği, belgenin adından değil, yüklenicinin neyi üstlendiğinden anlaşılır: çalışan bir yazılımın teslim edilmesinin üstlenildiği sözleşme eser sözleşmesine, belli bir işin özenle görülmesinin üstlenildiği sözleşme vekâlet sözleşmesine yakındır. Türk Borçlar Kanunu'ndaki "hizmet sözleşmesi" ise işçi ile işveren arasındaki bağımlı çalışmayı anlatır.

TBK'nın 393. maddesine göre hizmet sözleşmesi, işçinin işverene bağımlı olarak iş görmeyi, işverenin de ona ücret ödemeyi üstlendiği sözleşmedir. Bu yüzden piyasada "yazılım hizmet sözleşmesi" diye anılan belge, iki şirket arasında yapıldığında TBK'daki anlamıyla hizmet sözleşmesi olmayabilir. TBK'nın 470. maddesi eser sözleşmesini, yüklenicinin bir eser meydana getirmeyi, iş sahibinin de bunun karşılığında bedel ödemeyi üstlendiği sözleşme olarak tanımlar. 502. maddesi ise vekâlet sözleşmesini, vekilin vekâlet verenin bir işini görmeyi üstlendiği sözleşme olarak tanımlar.

Eser ve vekâlet sözleşmesi ayrımı önemlidir, çünkü bu iki tipe farklı kurallar uygulanır. Eser sözleşmesinde bedel kural olarak eserin teslimiyle muaccel olur (md. 479), ayıplı işte iş sahibine seçimlik haklar tanınır (md. 475) ve iş sahibi, yapılan kısmın bedelini ve yüklenicinin zararını karşılayarak eser tamamlanmadan sözleşmeden dönebilir (md. 484). Vekâlette ise iki taraf da sözleşmeyi her zaman tek taraflı sona erdirebilir; uygun olmayan zamanda sona erdiren taraf, diğerinin bundan doğan zararını gidermekle yükümlüdür (md. 512). Kendi sözleşmenizin hangisine yakın olduğu içeriğine göre değerlendirilir; bu değerlendirmeyi avukatınıza bırakmanızı öneririm.

Üç sözleşme tipinin yazılım projesindeki karşılığı kabaca şöyledir:

Bir yazılım sözleşmesinin hangi tipe yaklaştığını şu işaretlerden okuyabilirsiniz:

• Eser sözleşmesine yaklaşır, eğer yazılı bir kapsam, teslim tarihi ve kabul süreci varsa ve bedel sonuca bağlanmışsa.
• Vekâlete yaklaşır, eğer firma bir sonucu değil, harcadığı zamanı ve özeni satıyorsa; saat bazlı danışmanlık ya da teknik yönlendirme gibi.
• Karma bir yapıya döner, eğer geliştirme ile süresiz bakım aynı belgede birleşiyorsa; bu durumda iki bölümü ayrı başlıklarla yazmak gerekir.

Ben geliştirme ile bakımı iki ayrı sözleşmede, en azından ayrı eklerde yazmanızı öneririm. Geliştirme bir sonuca, bakım ise süren bir işe bağlıdır. İkisini tek ödeme planına ve tek fesih maddesine sıkıştırmak, hangi kuralın uygulanacağını da bulanıklaştırır. Ayrı ekler, bakımı başka bir firmaya devretmek istediğinizde yazılım geliştirme sözleşmesine dokunmadan bunu yapmanızı da sağlar.

Kapsam, değişiklik talebi ve kabul maddeleri nasıl yazılmalı?

Kapsam maddesi neyin yapılacağını, değişiklik talebi maddesi kapsamın nasıl değişeceğini, kabul maddesi de işin ne zaman bitmiş sayılacağını yazar. Bu üç madde birbirine bağlıdır; biri boş kalınca diğer ikisi de işlemez.

Kapsam ve değişiklik talebi maddesine ne yazılır?

Kapsam maddesi tek cümlelik bir proje adı olmamalı; ekranları, kullanıcı rollerini, entegrasyonları ve özellikle kapsam dışı işleri listeleyen bir eke bağlanmalıdır. Kapsam dışı listesini sözleşmenin en ucuz sigortası olarak görüyorum: "mobil uygulama bu işe dahil değildir" gibi tek bir satır, aylar sonra çıkabilecek bir tartışmayı baştan kapatır. İlk görüşmeden önce hazırladığınız yazılım brief'i bu ekin ham maddesidir. Kapsam ekinin sözleşmenin ayrılmaz parçası olduğu ve iki belge çelişirse hangisinin geçerli sayılacağı da yazılmalıdır.

Değişiklik talebi maddesi, kapsam değiştiğinde izlenecek yolu tarif eder. Ben üç şeyin açıkça yazılmasını isterdim: değişikliğin yazılı olarak istenmesi, firmanın süre ve bedel etkisini geliştirmeye başlamadan önce yazılı olarak bildirmesi ve sizin onayınız gelmeden işe başlanmaması. Türk Borçlar Kanunu'nun 480. maddesine göre bedel götürü olarak belirlenmişse yüklenici, kural olarak eseri o bedelle meydana getirmekle yükümlüdür. Sabit fiyatlı bir web uygulaması ya da mobil uygulama projesinde neyin kapsamda olduğu, bu yüzden fiyatın kendisi kadar önemlidir.

Kabul testi, kriterleri ve test süresi nasıl tanımlanır?

Kabul maddesi, teslim edilen yazılımın hangi kabul testleriyle, ne kadar sürede ve kim tarafından onaylanacağını yazar. TBK, iş sahibine teslimden sonra eseri gözden geçirme ve ayıpları uygun bir süre içinde bildirme yükü verir (md. 474); açık ya da örtülü kabulden sonra da yüklenici, kendisi tarafından kasten gizlenen ve usulüne göre gözden geçirme sırasında fark edilemeyecek ayıplar dışında sorumluluktan kurtulur (md. 477). Test süresini ve bildirim yolunu yazmak sizin lehinizedir. Kabul süreci beş adımda kurulabilir:

1. Kriter: Her ana işlev için ölçülebilir bir kabul cümlesi yazın; "bayi, siparişini üç adımda onaylayabilir" gibi.
2. Ortam: Testin hangi ortamda ve hangi örnek veriyle yapılacağını belirleyin.
3. Süre: Teslimden sonra kaç iş günü test yapacağınızı ve bu süre sessiz geçerse ne olacağını yazın.
4. Bildirim: Hataların hangi kanaldan, hangi biçimde bildirileceğini ve hangi önem seviyesinin kabulü durduracağını tanımlayın.
5. Tutanak: Kabulün yazılı bir tutanakla mı, yoksa belirlenen sürenin sessiz geçmesiyle mi gerçekleşeceğini açıkça yazın.

Kabul tutanağı adımı atlanmamalıdır. TBK, gözden geçirmeyi ve bildirimi ihmal eden iş sahibini eseri kabul etmiş sayar (md. 477/2); test süresi yazılmamışsa "uygun süre"nin ne kadar olduğu tartışmaya açık kalır. Küçük ve işi durdurmayan hatalar için kabulün durmayacağını, bunların garanti kapsamında düzeltileceğini yazmak da iki taraf için adil bir dengedir.

Kabul maddesi için avukatınızla konuşmak üzere örnek bir ifade (hukuki metin değildir): "İş Sahibi, her teslimden sonra [x] iş günü içinde Ek-2'deki kabul kriterlerine göre test yapar ve bulduğu hataları [kanal] üzerinden yazılı olarak bildirir. Bu süre içinde bildirim yapılmazsa teslim kabul edilmiş sayılır. Kritik seviyede olmayan hatalar kabulü durdurmaz ve garanti kapsamında düzeltilir."

Kaynak kod ve fikri mülkiyet sözleşmede nasıl devredilir?

Yazılımda fikri mülkiyet, kodun dosya olarak teslim edilmesiyle değil, mali hakların yazılı olarak ve tek tek sayılarak devredilmesiyle el değiştirir; Fikir ve Sanat Eserleri Kanunu bunu bir şekil şartı olarak arar.

FSEK'in 2. maddesi, her biçim altında ifade edilen bilgisayar programlarını ve program sonucu doğuracak hazırlık tasarımlarını ilim ve edebiyat eserleri arasında sayar. Aynı madde, programın bir ögesine temel oluşturan düşünce ve ilkelerin eser sayılmadığını da söyler; yani korunan şey fikriniz değil, o fikri ifade eden koddur. FSEK'in 52. maddesi ise mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşar. "Tüm haklar müşteriye aittir" gibi genel bir cümle yerine işleme, çoğaltma, yayma, temsil ve umuma iletim haklarının (md. 21-25) tek tek sayılmasını bu yüzden öneririm.

Devir ile ruhsat arasındaki farkı da sözleşmede netleştirmek gerekir. FSEK'in 48. maddesi, mali hakların süre, yer ve içerik bakımından sınırlı ya da sınırsız olarak devredilebileceğini ya da yalnızca kullanma yetkisi, yani ruhsat verilebileceğini söyler. FSEK'in 56. maddesine göre basit ruhsatta hak sahibi aynı ruhsatı başkalarına da verebilir, tam ruhsat ise yalnız bir kişiye mahsustur. Size özel yazılan bir sistemin aynı kodla başka bir müşteriye satılıp satılamayacağı bu ayrıma bağlıdır.

Kodu yazan kişiler firmanın çalışanlarıysa, FSEK'in 18. maddesine göre aksi anlaşılmadıkça eser üzerindeki hakları onları çalıştıran firma kullanır; firma da bu hakları size sözleşmeyle devreder. Firma işin bir kısmını alt yükleniciye ya da serbest çalışana yaptırıyorsa, o kişinin haklarının da firmaya geçtiğinden emin olmanız gerekir. Bu konuyu yazılım firması seçerken sorulacak sorular arasındaki alt yüklenici sorusuyla birlikte sorun.

Kaynak kod maddesinde şunlar yazılı olmalıdır:

• Teslim biçimi: Kodun, sizin adınıza açılmış bir kod deposunda, değişiklik geçmişiyle birlikte teslim edilmesi.
• Hesaplar: Sunucu, alan adı, uygulama mağazası ve üçüncü taraf servis hesaplarının sizin adınıza açılması.
• Açık kaynak bileşenler: Kullanılan açık kaynak kütüphanelerin ve lisanslarının listesi; bunlar size devredilmez, kendi lisanslarına göre kullanılır.
• Firmanın hazır parçaları: Firmanın başka projelerde de kullandığı kendi araçları varsa, bunlar için size süresiz bir kullanma hakkı tanınması.
• Dokümantasyon: Kurulum ve devir için gereken teknik dokümanın teslim kapsamında sayılması.

Avukatınızla konuşmak için örnek bir ifade şöyle olabilir; bu hukuki metin değildir, yalnızca tartışmaya başlamak içindir: "Yüklenici, bu sözleşme kapsamında geliştirdiği yazılımın kaynak kodu ve dokümanları üzerindeki işleme, çoğaltma, yayma, temsil ve umuma iletim haklarını süre ve yer bakımından sınırsız olarak İş Sahibine devreder. Yüklenicinin önceden var olan araçları ve açık kaynak bileşenler bu devrin dışındadır ve Ek-3'teki koşullarla kullanılır."

Özel yazılımın hazır programa göre somut üstünlüklerinden biri kaynak kod ve fikri haklar maddesinde görünür. Abonelikli bir hazır programda kod ve sunucu sağlayıcıda kalır, sözleşme de sağlayıcının standart koşullarıdır; özel yazılımda ise kodun, sunucunun ve alan adının sizin adınıza olmasını, kendi entegrasyonlarınızı ve değişiklik hızını sözleşmeye yazdırabilirsiniz. Bu üstünlüğün bedeli daha uzun bir ilk sürüm ve sistemi sahiplenecek birinin gerekmesidir; hangi durumda hangisinin mantıklı olduğunu özel yazılım mı hazır yazılım mı rehberinde ayrıca ele aldık. Teknik ortakla ya da serbest çalışanla ilerliyorsanız fikri hakların devrini yazılımcı ortak arıyorum yazısı ayrıntılı anlatıyor.

Teslimden sonra çıkan hataları garanti maddesi nasıl karşılar?

Garanti maddesi, kabulden sonra ortaya çıkan hataların hangi süre içinde, hangi koşulla ve ücretsiz olarak düzeltileceğini yazar; madde yazılmazsa ve sözleşme eser sözleşmesi sayılıyorsa TBK'nın ayıp kuralları (md. 474-478) uygulanır.

TBK'nın 475. maddesi ayıplı eserde iş sahibine üç seçimlik hak tanır: eser, iş sahibinin kullanamayacağı veya hakkaniyet gereği kabule zorlanamayacağı ölçüde ayıplıysa sözleşmeden dönme, eseri alıkoyup bedelden indirim isteme ya da aşırı masraf gerektirmiyorsa ücretsiz onarım isteme; genel hükümlere göre tazminat hakkı da saklıdır. TBK'nın 478. maddesi, ayıp nedeniyle açılacak davalar için teslimden başlayan zamanaşımı süreleri öngörür: taşınmaz yapılar dışındaki eserlerde iki yıl, yüklenicinin ağır kusuru varsa yirmi yıl. Eserdeki ayıp sonradan ortaya çıkarsa iş sahibinin bunu gecikmeksizin bildirmesi gerekir (md. 477/3).

Yazılımda "ayıp" kavramını somutlaştırmak sözleşmeye düşer. Ben olsam garanti maddesinde üç durumu birbirinden ayırırdım: kabul kriterlerine aykırı hata (garanti kapsamında, ücretsiz), sizin altyapınızdan ya da bir üçüncü taraf servisten kaynaklanan sorun (garanti dışı, ama tespiti destek kapsamında) ve yeni bir istek (değişiklik talebi). Bu ayrım yazılmazsa teslimden sonraki her hata bildirimi bir sınıflandırma tartışmasıyla başlar. Garanti süresinin uzunluğu projeye göre değişir; asıl önemli olan sürenin ve başlangıç anının, yani teslimden mi kabulden mi işlediğinin açıkça yazılmasıdır.

Yazılım bakım sözleşmesi ve SLA neleri kapsamalı?

Yazılım bakım sözleşmesi, yayından sonra sistemin çalışır kalması için hangi işlerin, hangi sürelerle ve hangi bedelle yapılacağını yazar. SLA (hizmet seviyesi anlaşması) ise bu sürelerin ölçülebilir kısmıdır: bir arızaya ne kadar sürede yanıt verileceği ve ne kadar sürede çözüleceği.

Bakım tek bir iş değildir. Bakım kapsamını dört başlıkta yazmak işinizi kolaylaştırır: hata düzeltme; uyum, yani işletim sistemi, tarayıcı, kütüphane ve üçüncü taraf servis güncellemelerine uyum; önleyici işler, yani güvenlik yamaları, yedeklerin ve izlemenin kontrolü; ve geliştirme, yani yeni özellikler. İlk üçü bakımın konusudur. Dördüncüsünü ise bakım bedelinin içine gömmek yerine ayrı fiyatlanan bir değişiklik talebi olarak yazmanızı öneririm; aksi halde bakım saatlerinin nereye gittiği izlenemez.

SLA nedir, sözleşmede nasıl yazılır?

SLA, yani hizmet seviyesi anlaşması, bakım sözleşmesinin ölçülebilir kısmıdır ve her arıza türü için yanıt ve çözüm sürelerini tanımlar. SLA'yı öncelik seviyelerine göre kurmak, her arızaya aynı süreyi yazmaktan daha adildir. Saat değerleri projeye ve bütçeye göre sizinle firma arasında belirlenir; seviyeler şöyle tanımlanabilir:

Yanıt süresi ile çözüm süresi ayrı yazılmalıdır. Yanıt, firmanın arızayı gördüğünü ve üzerinde çalıştığını bildirmesidir; çözüm ise sistemin yeniden çalışır hale gelmesidir. Tek bir "müdahale süresi" yazılırsa, kısa sürede gelen bir "inceliyoruz" mesajı da maddeyi yerine getirmiş sayılabilir. Sürelerin hangi saatlerde işlediği (7/24 mü, mesai saatleri mi), bildirimin hangi kanaldan yapılacağı ve süreler aşılırsa ne olacağı da aynı maddede durmalıdır.

Bakım bedelini belirleyen şey kapsamın kendisidir: sürelerin kısalığı, mesai dışı kapsam, izlenen sistem sayısı, üçüncü taraf entegrasyonlar ve kullanılmayan saatlerin bir sonraki aya devredip devretmediği. Kısa süreler ve geniş saat kapsamı bedeli yukarı iter; net bir kapsam dışı listesi ise sürprizleri azaltır. Kapsam dışı listesine sizin tarafınızdaki değişiklikleri, örneğin başka bir firmanın koda müdahalesini ya da sunucu ayarlarının sizin tarafınızdan değiştirilmesini yazmak da makuldür, çünkü bunlar bakımı veren firmanın kontrolünde değildir.

Ödeme planı teslim ve kabule nasıl bağlanmalı?

Ödeme planı, her ödemeyi bir takvim tarihine değil, bir teslime ya da kabule bağladığında iki tarafı da korur; Türk Borçlar Kanunu da eser sözleşmesinde bedeli kural olarak teslime bağlar.

TBK'nın 479. maddesine göre iş sahibinin bedel ödeme borcu eserin teslimi anında muaccel olur. Eserin parça parça teslimi kararlaştırılmış ve bedel parçalara göre belirlenmişse, her parçanın bedeli o parçanın teslimiyle muaccel olur. Sözleşmede aşamalı bir plan yazarak bu kuralı projenize uyarlayabilirsiniz. Ben olsam ödeme aşamalarını şu bağlantılarla kurardım:

• Ön ödeme: Kapsam dokümanının ve teslim planının onayından sonra; firmanın ekibi projeye ayırmasının karşılığı.
• Ara ödemeler: Test ortamında açıp deneyebileceğiniz çalışan bir sürümün tesliminde; takvim tarihinde değil.
• Son ödeme: Kabul tutanağına ve kaynak kodun, hesapların ve dokümanların tesliminin tamamlanmasına bağlı.
• Değişiklikler: Onaylanan her değişiklik talebi, kendi bedeli ve ödeme anıyla ayrıca yazılır.

Ödeme planında en çok önemsediğim bağlantı, son ödemenin kaynak kod ve hesap teslimine bağlanmasıdır; devir eksik kaldığında elinizde bir kaldıraç kalır. Para birimi, KDV'nin fiyata dahil olup olmadığı ve gecikme halinde ne olacağı da bu maddede yazılmalıdır. Farklı tekliflerdeki ödeme planlarının aynı ölçüyle nasıl okunacağını yazılım yaptırma maliyeti rehberinde ayrıntılı ele aldık.

Gizlilik ve KVKK maddesinde yazılım firması veri işleyen midir?

Yazılım firması sizin adınıza ve sizin verdiğiniz yetkiye dayanarak kişisel veri işliyorsa KVKK'daki tanımıyla veri işleyendir; işleme amaçlarını ve vasıtalarını siz belirlediğiniz için veri sorumlusu sizsiniz. Rolün her projede ayrıca değerlendirilmesi gerekir, çünkü firmanın kendi amacıyla veri işlediği bir kurgu bu dengeyi değiştirir.

KVKK'nın 3. maddesi veri işleyeni, veri sorumlusunun verdiği yetkiye dayanarak onun adına kişisel verileri işleyen gerçek veya tüzel kişi olarak tanımlar. 12. madde veri sorumlusuna uygun güvenlik düzeyini sağlamak için gerekli teknik ve idari tedbirleri alma yükümlülüğü verir ve verilerin veri sorumlusu adına başka bir gerçek veya tüzel kişi tarafından işlenmesi hâlinde veri sorumlusunun birinci fıkradaki tedbirlerin alınması hususunda bu kişiyle birlikte müştereken sorumlu olduğunu söyler. Aynı madde, işlenen verilerin kanuni olmayan yollarla başkalarınca elde edilmesi halinde veri sorumlusunun durumu en kısa sürede ilgilisine ve Kurula bildirmesini öngörür.

Yazılım sözleşmesindeki gizlilik maddesini iki parçaya ayırmanızı öneririm. Birinci parça ticari gizliliktir: iş fikriniz, müşteri listeniz, fiyatlarınız ve kodun kendisi. İkinci parça kişisel verilerdir: firmanın hangi verilere, hangi ortamda ve hangi amaçla erişeceği, hangi tedbirlerin alınacağı, bir ihlal fark edildiğinde size ne kadar sürede bildirileceği ve sözleşme bitince verinin iade edilip silineceği. Firmaya bu konuda sorulacak sorular, yazılım firması seçme rehberindeki KVKK başlığında listeleniyor.

Test ortamında canlı müşteri verisi yerine anonimleştirilmiş ya da örnek veri kullanılmasını da sözleşmeye yazın; firmanın canlı veriye hiç dokunmadığı bir kurulum iki tarafın riskini birden azaltır. Yurt dışında barındırılan bir sunucu ya da servis kullanılacaksa bu ayrı bir KVKK konusudur ve avukatınızla birlikte ele alınmalıdır.

Fesih, devir ve sorumluluk sınırı nasıl yazılmalı?

Fesih maddesi, iş yarıda kalırsa neyin, ne zaman ve hangi bedelle teslim edileceğini; sorumluluk maddesi de bir zarar doğduğunda kimin ne kadarını karşılayacağını yazar. İkisi de iyi giden bir projede okunmaz, kötü gidende ise belirleyici olur.

Fesih ve devir maddesinde ne olmalı?

Fesih maddesi fesih hallerini, o güne kadar yapılan işin bedelini ve devrin içeriğini birlikte yazmalıdır. Türk Borçlar Kanunu eser sözleşmesinde iş sahibine, eser tamamlanmadan önce yapılan kısmın bedelini ödeyip yüklenicinin bütün zararını gidererek sözleşmeden dönme imkânı tanır (md. 484). Sözleşme bu sonucu öngörülebilir kılmalıdır: "yapılan kısım" nasıl ölçülecek, hangi belgeyle kanıtlanacak? Ben olsam fesih anında teslim edilecekleri şöyle listelerdim:

• Kod: O güne kadar yazılan kodun tamamı, kod deposunun değişiklik geçmişiyle birlikte.
• Hesaplar: Sunucu, alan adı, uygulama mağazası ve servis hesaplarına erişimin size devri.
• Veri: Veritabanının okunabilir bir biçimde dışa aktarımı.
• Doküman: Kurulum adımları, gerekli ayarların listesi ve mimari notları; şifreler ve anahtarlar güvenli bir kanaldan ayrıca.
• Geçiş süresi: Yeni ekibin soru sorabileceği, süresi ve ücreti önceden belli kısa bir devir dönemi.

Sorumluluk sınırı maddesinde nelere dikkat edilmeli?

Sorumluluk sınırı, yüklenicinin tazminat borcuna bir üst sınır koyar; Türk Borçlar Kanunu ise bu sınırın her duruma uzanamayacağını söyler. TBK'nın 115. maddesine göre borçlunun ağır kusurundan sorumlu olmayacağına ilişkin önceden yapılan anlaşma kesin olarak hükümsüzdür. Firmanın bir üst sınır istemesi anlaşılır bir taleptir, çünkü sınırsız sorumluluk özellikle küçük bir ekip için ağır bir risk olabilir. Sizin açınızdan önemli olan, sınırın dışında kalacak halleri yazdırmaktır: kasıt ve ağır kusur, gizlilik ve kişisel veri ihlalleri, üçüncü kişilerin fikri hak iddiaları. Sınırın tutarı projenin riskine bağlı bir pazarlık konusudur; bu maddeyi avukatınız yazmalıdır.

Sorumluluk maddesi için tartışmaya başlamak üzere örnek bir ifade (hukuki metin değildir): "Yüklenicinin bu sözleşmeden doğan toplam sorumluluğu [tutar ya da sözleşme bedelinin belirli bir oranı] ile sınırlıdır. Kasıt ve ağır kusur, gizlilik ve kişisel veri ihlalleri ile üçüncü kişilerin fikri hak iddiaları bu sınırın dışındadır."

İmzadan önce yazılım sözleşmesi nasıl kontrol edilir?

İmzadan önce bir yazılım hizmet sözleşmesi örneğini ya da yazılım geliştirme sözleşmesi taslağını kontrol etmenin en kısa yolu, metni kapsam, kabul, kaynak kod, garanti, bakım ve SLA, ödeme, KVKK, fesih ve sorumluluk sınırı maddeleriyle karşılaştırmak ve her maddeye "bu yazmıyorsa ne olur?" sorusunu sormaktır. Avukat görüşmesine ya da firmayla son toplantıya şu kontrol listesini götürebilirsiniz:

• Kapsam eki sözleşmeye bağlı mı, kapsam dışı listesi var mı?
• Değişiklik talebi yazılı mı, bedeli işe başlamadan onaylanıyor mu?
• Kabul kriterleri ölçülebilir mi, test süresi ve bildirim kanalı yazılı mı?
• Mali haklar tek tek sayılmış mı, açık kaynak bileşenler ve firmanın hazır parçaları ayrılmış mı?
• Garanti süresi ve başlangıç anı belli mi?
• Bakım kapsamı yazılı mı, SLA'da yanıt ve çözüm süresi ayrı mı?
• Son ödeme kabule ve devre bağlı mı?
• Veri işleyen rolü, güvenlik tedbirleri ve ihlal bildirimi yazılı mı?
• Fesihte teslim edilecekler ve sorumluluk sınırının istisnaları yazılı mı?

Yazılım sözleşmesi hazırlanırken hangi hatalar yapılır?

Yazılım sözleşmesi hazırlanırken beş hata öne çıkar: şablonu olduğu gibi imzalamak, kapsamı teklif e-postasında bırakmak, "tüm haklar" cümlesiyle yetinmek, bakımı sözlü bırakmak ve kabul tutanağını hata listesi olmadan imzalamak.

• Şablonu olduğu gibi imzalamak: İnternetten indirilen bir yazılım sözleşmesi örneği sizin kapsamınızı, verinizi ve ödeme planınızı bilmez.
• Kapsamı teklif e-postasında bırakmak: Teklif sözleşmeye ek olarak bağlanmazsa, iki belge çeliştiğinde hangisinin geçerli olduğu tartışma konusu olur.
• "Tüm haklar" cümlesiyle yetinmek: Fikir ve Sanat Eserleri Kanunu mali hakların ayrı ayrı gösterilmesini ister (md. 52).
• Bakımı sözlü bırakmak: Yayından sonraki ilk arızada kimin, ne kadar sürede bakacağı yazılı olmaz.
• Kabul tutanağını hata listesi olmadan imzalamak: Kabulden sonra yüklenici, kasten gizlenen ve usulüne göre gözden geçirmede fark edilemeyecek ayıplar dışında sorumluluktan kurtulur (md. 477).

Bu beş hata iyi niyetli iki taraf arasında da yapılabilir; risk kötü niyetten çok ayrıntının sonradan unutulmasından doğabilir. Bu yüzden maddeleri, iki taraf da işin ayrıntısını hatırlarken, yani kapsam yeni yazılmışken yazmanızı öneririm.

UlvionTech'te yazılım sözleşmesi neye dayanır?

UlvionTech olarak İstanbul'daki ekibimizle yazılım sözleşmesini koddan önce yazılan kapsamın üzerine kuruyoruz. Keşif aşamasını yazılı kapsam, teslim planı ve sabit fiyatla bitiriyoruz; kapsam sonradan değişirse değişikliği geliştirmeden önce fiyatlıyoruz. Bu belgeyi sözleşmeye ek olarak bağlıyoruz; böylece kapsam, kabul ve ödeme maddeleri birbirine atıf yapar.

Geliştirmeyi iki haftalık döngülerle planlıyoruz; her döngü, test ortamında açıp deneyebileceğiniz çalışan bir sürümle biter, bu da ara ödemeleri teslimlere bağlamayı kolaylaştırır. Kod deposunu, bulut hesaplarını, alan adlarını ve üçüncü taraf servisleri ilk günden şirketiniz adına açıyoruz. Dokümantasyonu, devir toplantısını ve süresi belli destek dönemini sözleşmeye taahhüt olarak yazıyoruz. Bu çalışma biçimini hakkımızda sayfasında da anlatıyoruz.

Ben olsam dokümantasyon, devir ve destek taahhütlerinin teklif sunumunda değil, sözleşmeye yazılmasını isterdim ve sizin de aynısını görüştüğünüz her firmadan istemenizi öneririm. Bir firmanın sözlü olarak söylediği her şeyi yazıya geçirmeyi kabul etmesi, imzadan önce alabileceğiniz somut bir güvence işaretidir.

Hangi durumlarda bizimle çalışmamalısınız?

UlvionTech ile çalışmak her proje için gerekli değildir; şu durumlarda bizimle çalışmanızı önermeyiz, çünkü başka bir yol daha mantıklıdır:

• İş çok küçükse: Tek sayfalık bir tanıtım sitesi ya da birkaç günlük bir düzeltme için dokuz maddelik bir pazarlık gereksizdir; kısa ve yazılı bir iş tanımı yeterli olabilir.
• Hazır bir program ihtiyacınızı karşılıyorsa: Abonelikli bir hazır programın sözleşmesi sağlayıcının standart koşullarıdır ve pazarlık alanı dardır; ihtiyacınız standartsa bu kabul edilebilir bir ödünleşimdir.
• Hukuki görüş arıyorsanız: Biz yazılım ekibiyiz; sözleşmenizin hukuken yeterli olup olmadığını bir avukat söyler, biz söyleyemeyiz.
• Şirket içinde kendi ekibiniz varsa: Kendi yazılımcılarınızla çalışıyorsanız ilişki bir iş sözleşmesine dayanır ve bu kontrol listesinin önemli bir kısmı size uymaz.

Elinizde bir sözleşme taslağı varsa ve kapsam ekini, kabul kriterlerini, SLA tablosunu ya da devir listesini teknik açıdan birlikte okumak isterseniz, projenizi iletişim sayfasından kısaca yazın; hukuki değerlendirmeyi avukatınıza, maddelerin yazılımda neye karşılık geldiğini bize bırakabilirsiniz.