Yazılım geliştirme sözleşmesinde hangi maddeler bulunmalı?
Bir yazılım geliştirme sözleşmesinde en az on iki konu yazılı olmalıdır: kapsam ve ekler, kabul testleri, değişiklik yönetimi, ödeme takvimi, teslim süresi ve gecikme, fikri mülkiyet ve kaynak kod, gizlilik, kişisel veri hükümleri, garanti ve hata düzeltme süresi, bakım, fesih ve uyuşmazlık çözümü. Bunlardan biri eksik kaldığında sorun genellikle proje ortasında, taraflar aynı cümleyi farklı anladığında ortaya çıkar.
Hukuken bakıldığında, ortaya çıkacak bir yazılımı belirli bir bedelle teslim etmek çoğu durumda Türk Borçlar Kanunu'ndaki eser sözleşmesi çerçevesinde değerlendirilir. 6098 sayılı Borçlar Kanunu'nun 470. maddesi bu sözleşmeyi, yüklenicinin bir eser meydana getirmeyi, iş sahibinin de karşılığında bir bedel ödemeyi üstlendiği sözleşme olarak tanımlar. Aylık bakım, danışmanlık ya da ekip kiralama gibi kalemler ise başka bir sözleşme türüne girebilir. Bu yüzden tek bir projede karma bir yapı çıkması olağandır ve hangi hükmün hangi kısma uygulanacağı sözleşmede açıkça yazılmalıdır.
Kanundaki hükümlerin birçoğu tamamlayıcıdır: sözleşmede yazmayan konularda devreye girer. Kanuna bırakmak çoğu zaman proje ortasında tartışılacak bir boşluk bırakmak demektir. Aşağıdaki liste, "yazılım geliştirme sözleşmesi örneği" arayan bir iş sahibinin taslağı avukatıyla birlikte okurken kullanabileceği bir kontrol listesidir. Hukuk görüşünün yerini tutmaz; ama hangi soruların sorulacağını gösterir.
12 maddenin her biri neden önemli, tipik hata nedir?
| Madde | Neden önemli | Tipik hata |
|---|---|---|
| 1. Kapsam ve ekler | Neyin teslim edileceğini sabitler | Kapsam "teklif ekinde" kalır, ek yoktur |
| 2. Kabul testleri | Ödeme ve sorumluluk kabule bağlanır | Ölçüt yazılmaz, "memnun kalınca" denir |
| 3. Değişiklik yönetimi | Ek istekler fiyatı ve süreyi etkiler | Değişiklikler sözlü ve kayıtsız yapılır |
| 4. Ödeme takvimi | Nakit akışını ve riski dengeler | Tüm bedel teslimden sonraya bırakılır |
| 5. Teslim süresi ve gecikme | Tarihi ve gecikmenin sonucunu belirler | Müşteriden gelecek girdilerin tarihi yazılmaz |
| 6. Fikri mülkiyet ve kaynak kod | Yazılımı kimin, nasıl kullanacağını belirler | "Tüm haklar" yazılır, hakların türü ayrılmaz |
| 7. Gizlilik | İş sırrını ve verileri korur | Süre ve sözleşme sonrası yükümlülük unutulur |
| 8. Kişisel veri (KVKK) | Tarafların rolü ve güvenlik yükümlülüğü netleşir | Roller yazılmaz, testte gerçek veri kullanılır |
| 9. Garanti ve hata düzeltme | Teslimden sonra düzeltme süresini belirler | "Hata" tanımlanmaz, süre açık bırakılır |
| 10. Bakım ve destek | Canlıdaki yazılımın devamlılığını sağlar | Bakım sözleşmeye hiç girmez |
| 11. Fesih | Çıkış kurallarını ve devri belirler | Fesihte yapılan işin akıbeti yazılmaz |
| 12. Uyuşmazlık | Çözüm yolunu ve yetkiyi önceden seçer | Önce görüşme adımı konmaz, yetki belirsiz kalır |
Kapsam, kabul ve değişiklik maddeleri nasıl yazılır?
Üç maddenin birlikte çalışması gerekir. Kapsam neyin yapılacağını, kabul testi bunun yapılıp yapılmadığını, değişiklik yönetimi ise sözleşme yazıldıktan sonra çıkan yeni isteklerin nasıl ele alınacağını belirler.
- Kapsam: Ekranlar, kullanıcı rolleri, entegrasyonlar, desteklenen cihazlar ve kapsam dışı kalanlar listelenir. Teknik şartname ya da gereksinim belgesi sözleşmenin eki olur. Kapsamı nasıl belirleyeceğinizi yapay zekâ proje kapsamı belirleme rehberimizde anlattık; aynı mantık her yazılım projesi için geçerlidir.
- Kabul testleri: Hangi senaryoların, hangi veriyle, kimin önünde çalıştırılacağı ve neyin "hata" sayılacağı yazılır. Hataların önem derecesi (engelleyici, yüksek, düşük) ve hangi derecedeki hataların kabulü engelleyeceği belirlenir.
- Değişiklik yönetimi: Her değişiklik yazılı bir talep formuyla gelir; tedarikçi etkisini süre ve bedel olarak yanıtlar, iki taraf onaylamadan iş başlamaz.
Kabulün hukuki ağırlığını bilmek gerekir. Borçlar Kanunu'nun 474. maddesi, iş sahibinin eseri teslimden sonra olağan akışa göre imkân bulur bulmaz gözden geçirmesini ve ayıpları uygun sürede bildirmesini ister. 477. madde ise eserin açıkça ya da örtülü olarak kabulünden sonra yüklenicinin sorumluluktan kurtulduğunu, gözden geçirme ve bildirimin ihmal edilmesi hâlinde eserin kabul edilmiş sayılacağını söyler; yüklenicinin kasten gizlediği ve gözden geçirmede fark edilemeyecek ayıplar bunun dışındadır. Kısacası, teslimi sessizce karşılamak iş sahibinin haklarını zayıflatabilir. Sözleşmede kabul süresi ve bildirim biçimi açıkça yazılırsa tartışma azalır.
Ödeme, teslim süresi ve gecikme nasıl düzenlenir?
Kanundaki varsayılan kural, iş sahibinin bedel ödeme borcunun eserin teslimi anında muaccel olmasıdır (Borçlar Kanunu m.479). Uzun bir yazılım projesinde genellikle bunun yerine bedel aşamalara bölünür. Her aşamanın karşılığında somut bir çıktı ve kabul koşulu yazılır. Böylece tedarikçi tüm riski tek başına taşımaz, iş sahibi de çalışmayan bir ürün için peşin ödeme yapmaz.
Bedelin türü de yazılmalıdır. Götürü bedelde (m.480) yüklenici, işin öngörülenden fazla emek gerektirmesi hâlinde bile bedelin artırılmasını kural olarak isteyemez; yalnızca öngörülemeyen ve işi son derece güçleştiren durumlarda uyarlama ya da dönme gündeme gelir. Bu nedenle sabit fiyatlı sözleşmede kapsamın ve değişiklik yönetiminin netliği daha da önem kazanır. Başlangıçta yaklaşık bir bedel belirlenmişse ve bu bedel iş sahibinin kusuru olmadan aşırı ölçüde aşılacaksa m.482 iş sahibine sözleşmeden dönme imkânı tanır.
Teslim süresi için tek tarih yazmak yeterli değildir. Aşama tarihleri, iş sahibinin sağlaması gereken girdilerin (erişim, veri, onay) son günleri ve bu girdiler geç gelirse sürenin uzayacağı açıkça yazılmalıdır. Gecikme için kanun, yüklenici işi geciktirirse ya da işin zamanında bitmeyeceği açıkça anlaşılırsa iş sahibine teslim gününü beklemeden sözleşmeden dönme imkânı verir (m.473). Sözleşmeyle ayrıca cezai şart da konabilir. Ancak m.182'ye göre hâkim aşırı gördüğü cezayı kendiliğinden indirir; bu yüzden cezayı makul ve üst sınırlı yazmak hem daha adil hem daha savunulabilirdir.
Fikri mülkiyet ve kaynak kod kime ait olur?
Sözleşmede yazmıyorsa bu soru tartışmaya açıktır; en çok anlaşmazlığa yol açan madde de budur. 5846 sayılı Fikir ve Sanat Eserleri Kanunu, 1/B maddesinde bilgisayar programını tanımlar ve yazılımı eser olarak kapsama alır. 48. madde mali hakların süre, yer ve muhteva bakımından sınırlı ya da sınırsız devredilebileceğini; 52. madde ise mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koştuğunu belirtir. Aynı 48. maddenin son fıkrası, henüz meydana getirilmemiş eserlere ilişkin bu türden tasarrufları batıl sayan bir hüküm içerir. Bu, "yazılımın tüm hakları müşteriye aittir" gibi tek satırlık bir hükmün tek başına yeterli olmayabileceği anlamına gelir. Maddenin nasıl kurgulanacağı bir avukatla birlikte değerlendirilmelidir.
Pratikte şu ayrımı sözleşmeye yazın:
- Size özel geliştirilen kod: Hangi hakların (çoğaltma, uyarlama, yayma gibi) hangi süre ve bölge için devredildiği ya da lisanslandığı.
- Tedarikçinin önceden var olan kodu ve kütüphaneleri: Tedarikçide kalır; size kullanım lisansı verilir. Açık kaynak bileşenler kendi lisanslarına tabidir ve listelenmelidir.
- Kaynak kod: Teslim edilecek mi, hangi biçimde (depo erişimi, doküman, derleme talimatı), ne zaman? Teslim edilmeyecekse kaynak kodun üçüncü bir tarafa emanet edilmesi (escrow) gibi bir yol yazılabilir.
Gizlilik ve kişisel veri hükümleri neleri içermeli?
Gizlilik maddesi iş sırrını, kaynak kodu, fiyatları ve müşteri verisini kapsar; sözleşme bittikten sonra da sürecek bir süre yazılır ve istisnalar (kamuya açık bilgi, yasal zorunluluk) belirtilir. Kişisel veri için ayrı bir madde gerekir, çünkü proje sırasında test, destek ya da bakım nedeniyle tedarikçi, çalışanlarınızın ya da müşterilerinizin verisine dokunabilir.
6698 sayılı KVKK m.12'ye göre veri sorumlusu, uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri almak zorundadır; kişisel verilerin kendi adına başka bir kişi tarafından işlenmesi hâlinde bu tedbirler konusunda o kişilerle müştereken sorumludur. Aynı maddenin dördüncü fıkrası, veri sorumlusu ve veri işleyenin öğrendikleri kişisel verileri işleme amacı dışında kullanamayacağını ve bu yükümlülüğün görevden ayrıldıktan sonra da süreceğini belirtir. Tedarikçi bulut hizmeti veya yurt dışındaki bir sunucu kullanacaksa m.9'daki aktarım şartları da gündeme gelebilir. Sözleşmede şunlar bulunmalıdır: tarafların rolü (veri sorumlusu, veri işleyen), işlenen veri türleri ve amaç, güvenlik tedbirleri, alt yüklenici kullanımı, veri ihlalinde bildirim süresi, test ortamında gerçek veri kullanılıp kullanılmayacağı ve sözleşme sonunda verinin silinmesi ya da iadesi.
Garanti, bakım ve fesih maddeleri nasıl kurulur?
Garanti süresi, teslimden sonra çıkan hataların tedarikçi tarafından ücretsiz düzeltileceği dönemdir. Kanundaki ayıp hükümleri bunun için bir çerçeve çizer: 475. madde ayıplı eser için sözleşmeden dönme, bedelden indirim ya da ücretsiz onarım seçeneklerini sayar; 478. madde ayıp sebebiyle açılacak davalar için teslimden başlayan zamanaşımı süreleri koyar (taşınmaz yapılar dışındaki eserlerde iki yıl, yüklenicinin ağır kusuru varsa yirmi yıl). Yazılımda bu hükümlerin nasıl uygulanacağı tartışmalı olabilir; bu yüzden hata tanımını, bildirim yöntemini, düzeltme süresini ve garanti süresini sözleşmede açıkça yazmak daha güvenlidir.
Bakım ayrı bir konudur. Garanti, teslim edilen üründeki hataları kapsar; bakım ise güncelleme, güvenlik yaması, işletim sistemi ve kütüphane uyumu, izleme ve yeni sürümleri. Bakım kapsamını, yanıt süresi hedeflerini (örneğin kritik hatada kaç saat içinde yanıt verileceğini) ve bakımın ne zaman başlayıp biteceğini yazın.
Fesih maddesinde şunları belirleyin: hangi hâllerde ve hangi ihtar süresiyle fesih yapılabileceği, fesih hâlinde o ana kadar yapılan işin ve kaynak kodun akıbeti ve ödenecek bedel. Kanun iş sahibine, yapılmış kısmın karşılığını ödemek ve yüklenicinin bütün zararlarını gidermek koşuluyla eser tamamlanmadan sözleşmeyi feshetme imkânı tanır (m.484). Sözleşme bu konuda daha ayrıntılı ve dengeli olabilir. Uyuşmazlık maddesinde ise önce yetkili kişiler arasında görüşme adımı, ardından yetkili mahkeme ya da seçilecek başka bir çözüm yolu yazılır.
Örnek: altı aylık bir proje için maddeler nasıl çalışır?
Örneğin 1.000.000 TL'lik varsayımsal bir müşteri portalı projesini düşünelim. Sözleşme bedeli üç aşamaya bölünür: analiz ve tasarım tesliminde %30, çalışan sürümün kabul testini geçmesinde %40, canlıya alma ve 30 günlük gözlemden sonra %30. Teslim süresi altı aydır; iş sahibinin eski sistemden veri aktarım dosyasını ilk ayın sonuna kadar vermesi bir yükümlülük olarak yazılmıştır.
Dördüncü ayda müşteri yeni bir raporlama ekranı ister. Değişiklik maddesi gereği tedarikçi bir hafta içinde "iki hafta ek süre ve belirli bir ek bedel" yanıtı verir. Müşteri onaylamazsa kapsam aynı kalır. Ayrıca veri dosyası iki hafta geç geldiği için tedarikçi teslimin iki hafta uzayacağını yazılı bildirir; sözleşmede bu durum zaten öngörüldüğünden gecikme cezası doğmaz. Kabul testinde iki engelleyici hata bulunur; kabul ancak bunlar düzeltilince verilir ve ikinci ödeme o zaman yapılır. Bu akıştaki hiçbir adım yeni bir hukuki icat değildir; tek fark, her adımın baştan yazılı olmasıdır. Rakamlar, oranlar ve süreler yalnızca anlatım içindir.
Sözleşmelerde en sık yapılan hatalar nelerdir?
- Kapsamı "teklifte yazdığı gibi" diye bırakmak ve teklifi sözleşmeye ek olarak eklememek.
- Kabul ölçütünü yazmamak; ödemeyi ve sorumluluğu belirsiz bir "memnuniyete" bağlamak.
- Fikri mülkiyeti tek cümleyle geçmek; hakların türünü, süresini ve kaynak kod teslimini ayırmamak.
- Test ortamında gerçek müşteri verisi kullanmak ve tarafların KVKK rolünü yazmamak.
- Garanti ile bakımı karıştırmak ve bakımı hiç sözleşmeye koymamak.
- Hazır şablonu okumadan imzalamak. Borçlar Kanunu'nun 20. ve devamı maddeleri, karşı tarafın menfaatine aykırı genel işlem koşullarının belirli şartlar sağlanmadan sözleşme kapsamına girmeyeceğini düzenler; yine de imzadan önce okumak en sağlam yoldur.
Hatson Tech bu konuda nasıl yardımcı oluyor?
Hatson Tech sözleşmenin teknik tarafını yazmanıza yardım eder: kapsamı ve kabul testlerini netleştirir, aşama planını ve bakım kapsamını çıkarır. İlk görüşme ve keşif ücretsizdir; sabit fiyat yayımlamayız, fiyat kapsam netleştikten sonra çıkar. Hukuki hükümlerin son hâlini sizin avukatınız belirler. Sürecin nasıl ilerlediğini özel yazılım geliştirme hizmetimizde görebilirsiniz.
Sözleşme inceleme ve durum tespiti işini hukuk ekipleri için geliştirdiğimiz ürün Caseon yapıyor; ayrıntı için Caseon sayfasına bakabilirsiniz. Tedarikçi seçerken yapay zekâ tedarikçi seçimi rehberimizdeki soruları, eski bir sistemi yenilemeden önce de uygulama modernizasyonu karar rehberini kullanabilirsiniz.