Yazılım geliştirme sözleşmesinde dikkat edilmesi gerekenler: maddeler ve kontrol listesi
Yazılım geliştirme sözleşmesinde en kritik maddeler; yazılı kapsam, kabul testi ölçütleri, kaynak kodu ve fikri mülkiyet haklarının kime ait olacağı, bakım ve SLA (Service Level Agreement, hizmet seviyesi anlaşması) koşulları ile firma ilişkisi bittiğinde verinin ve kodun nasıl teslim edileceğidir. Türkiye’de bilgisayar programları 5846 sayılı Fikir ve Sanatlar Eserleri Kanunu (FSEK) kapsamında eser olarak korunur.
Yazılım sözleşmesi neden önemli?
Arkadaşlar, önce bir uyarıyla başlayalım: bu rehber hukuki tavsiye değildir. Biz yazılım geliştiren ve sahada süreç kuran bir ekibiz; burada yıllar içinde gördüğümüz ve sözleşmede eksik kaldığında sorun çıkaran konuları paylaşıyoruz. Sözleşmenizi imzalamadan önce mutlaka bir avukata inceletin ve güncel mevzuatı kontrol edin.
Biz sahada şunu çok görüyoruz: yazılım projelerindeki anlaşmazlıkların büyük kısmı teknik değil, “bunu kastetmemiştik” cümlesiyle başlıyor. Sözleşme, iki tarafın aynı şeyi anladığını kâğıda dökmenin yoludur. İyi yazılmış bir sözleşme, sadece mahkemede değil, proje toplantısında da işe yarar.
Yazılım geliştirme sözleşmesinin hukuki niteliği nedir?
Ismarlama yazılım geliştirme sözleşmeleri uygulamada çoğunlukla 6098 sayılı Türk Borçlar Kanunu’ndaki eser sözleşmesi kapsamında değerlendirilir: yüklenici bir eser meydana getirmeyi, iş sahibi de bunun karşılığında bedel ödemeyi üstlenir. Hazır bir yazılımın kullanım hakkının verilmesi ise lisans sözleşmesidir; ikisinin hükümleri ve sonuçları farklıdır.
Ortaya çıkan programın kendisi ise FSEK’in 2. maddesine göre ilim ve edebiyat eseri sayılır; kanun “her biçim altında ifade edilen bilgisayar programları” ile, program sonucu doğurması koşuluyla, bunların hazırlık tasarımlarını da korur. Bu yüzden sözleşmenin hem borç ilişkisini hem de fikri mülkiyet haklarını ayrı ayrı düzenlemesi gerekir. Somut sözleşmenin niteliğini avukatınızla birlikte değerlendirin.
Yazılım sözleşmesinde dikkat edilmesi gereken maddeler
Bir yazılım geliştirme sözleşmesi örneğine baktığınızda en azından şu başlıkları görmelisiniz:
- 1. Kapsam ve teknik şartname: hangi ekranlar, raporlar, kullanıcı rolleri, entegrasyonlar. Sözleşmenin eki olarak imzalanmalı.
- 2. Teslim takvimi ve aşamalar: her aşamada neyin teslim edileceği ve ödemenin hangi aşamaya bağlı olduğu.
- 3. Kabul testi: teslim edilen yazılımın hangi ölçütlerle, kimin tarafından, ne kadar sürede test edilip kabul edileceği.
- 4. Değişiklik yönetimi: kapsam dışı isteklerin nasıl talep edileceği, nasıl fiyatlanacağı ve takvime etkisi.
- 5. Kaynak kodu ve fikri mülkiyet: mali hakların devri mi, yalnızca kullanım lisansı mı?
- 6. Gizlilik ve kişisel veriler: firmanın erişeceği veriler ve 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) kapsamındaki yükümlülükler.
- 7. Garanti, bakım ve SLA: teslimden sonra hataların ne kadar süre ücretsiz düzeltileceği ve destek hizmet seviyeleri.
- 8. Çıkış planı: sözleşme sona erdiğinde veri, kod ve dokümantasyonun nasıl teslim edileceği.
Kaynak kodu ve fikri mülkiyet hakları kime ait olur?
İşletmelerin en çok şaşırdığı konu bu. FSEK’in 18. maddesine göre mali hakları kullanma yetkisi kural olarak eser sahibine aittir. Aynı maddedeki istisna, işçilerin işlerini görürken meydana getirdikleri eserlerle ilgilidir; bu durumda haklar, aksi kararlaştırılmadıkça işveren tarafından kullanılır. Dışarıdaki bir yazılım firmasına yazdırılan program ise bu istisnaya girmez. Yani bedelini ödemiş olmanız, sözleşmede açıkça yazmıyorsa, kaynak kodunun ve haklarının size geçtiği anlamına gelmez.
FSEK’in 52. maddesi, mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşar. Uygulamada bu; işleme, çoğaltma, yayma, temsil ve umuma iletim haklarının tek tek sayılması, devrin ya da lisansın süre, yer ve kapsamının yazılması demektir. FSEK’in 50. maddesi, henüz meydana getirilmemiş eserler için yapılan bu tür taahhütlerin de geçerli olduğunu söyler; yani hakların devri geliştirme başlamadan sözleşmeyle kararlaştırılabilir.
Bir de firmanın daha önce yazdığı ve birçok projede kullandığı hazır bileşenler var. Bunların devri çoğu zaman mümkün olmaz; sözleşmede hangi parçanın size ait, hangisinin yalnızca kullanım lisansıyla verildiğinin ayrılması gerekir. Açık kaynak bileşenlerin lisans koşulları da ayrıca listelenmelidir.
Kabul testi nasıl tanımlanmalı?
Kabul testi (UAT, User Acceptance Test, kullanıcı kabul testi), teslim edilen yazılımın sözleşmedeki şartlara uyup uymadığının iş sahibi tarafından denendiği aşamadır. Sözleşmede şunlar yazmalıdır:
- Test senaryoları: hangi iş akışlarının, hangi örnek veriyle deneneceği.
- Test süresi: iş sahibinin kaç iş günü içinde test edip geri bildirim vereceği.
- Hata sınıfları: kritik, önemli, kozmetik hataların tanımı; hangisinin kabulü engelleyeceği.
- Sessiz kabul: süre içinde geri bildirim verilmezse ne olacağı.
- Ödeme bağlantısı: aşama ödemesinin kabule bağlı olup olmadığı.
Yazılım bakım sözleşmesi ve SLA’da nelere bakılmalı?
Yazılım bakım sözleşmesi çoğu zaman geliştirme sözleşmesinden ayrı imzalanır ve yıllarca sürer. Bu yüzden ilk sözleşme kadar dikkat ister. SLA, destek hizmetinin ölçülebilir hedeflerini tanımlar:
- Yanıt süresi: bir hata bildirimine ne kadar sürede dönüş yapılacağı.
- Çözüm süresi: hata sınıfına göre ne kadar sürede düzeltileceği.
- Erişilebilirlik: sistemin ay içinde yüzde kaç oranında çalışır olacağı ve planlı bakım saatleri.
- Destek saatleri ve kanalları: mesai içi mi, 7/24 mü; telefon mu, bildirim sistemi mi?
- Kapsam: hata düzeltme, güncelleme, küçük geliştirmeler bakıma dahil mi, ayrıca mı ücretlendiriliyor?
- Yedekleme ve geri dönüş: verinin ne sıklıkla yedeklendiği ve bir aksaklıkta ne kadar sürede geri yükleneceği.
Kaynak kod emanetçiliği (escrow) nedir, ne zaman gerekir?
Kaynak kod emanetçiliği (source code escrow), kaynak kodun ve dokümantasyonun bağımsız bir üçüncü kişide saklandığı ve sözleşmede belirlenen durumlarda, örneğin yazılım firmasının faaliyetini durdurması ya da bakım yükümlülüğünü yerine getirmemesi halinde, iş sahibine teslim edildiği düzenlemedir. Kaynak kodunun devredilmediği, ama işletmenin o yazılıma kritik derecede bağlı olduğu durumlarda düşünülmelidir.
Emanete verilen kodun güncel tutulup tutulmayacağı, hangi olayların teslimi tetikleyeceği ve kodun derlenebilir olup olmadığının nasıl doğrulanacağı sözleşmede yazmalıdır. Aksi halde emanette yıllar önceki, çalışmayan bir sürüm kalabilir.
Sık yapılan hatalar
En sık gördüğümüz hata, kapsamı sözleşmeye eklemeden “detayları sonra konuşuruz” demek. Kapsam yazılı değilse kabul testi de, değişiklik talebi de tartışmaya açık kalır. Bunun maliyete etkisini yazılım yaptırma maliyeti rehberimizde anlattık.
İkinci hata, kaynak kodunun bedel ödendiği için kendiliğinden işletmeye geçtiğini varsaymak. Üçüncüsü, çıkış planını hiç düşünmemek: ilişki iyi giderken kimse ayrılığı konuşmak istemiyor, ama verinin hangi formatta ve ne kadar sürede teslim edileceği baştan yazılmazsa sonradan çok zor konuşuluyor.
İyi sözleşme, iyi işbirliğinin başlangıcıdır
Sözleşme iki taraf arasında güvensizliğin değil, açıklığın belgesidir. Yazılımı yazan ekibin emeği de, onu her gün kullanacak arkadaşların emeği de ancak beklentiler baştan netleşirse korunur. Bu rehberdeki maddeler hukuki tavsiye yerine geçmez; sözleşmenizi bir avukata inceletin ve güncel düzenlemeyi kontrol edin.
Siz de yazılım projenizin kapsamını, kabul ölçütlerini ya da bakım beklentilerinizi sözleşmeden önce netleştirmek isterseniz bizimle iletişime geçebilirsiniz. Sormak istediğiniz her konuda gerekli desteği vermeye hazırız.
Sık sorulan sorular
Yazılım sözleşmesinde dikkat edilmesi gerekenler nelerdir?
Yazılı kapsam ve teknik şartname, teslim takvimi, kabul testi ölçütleri, değişiklik yönetimi, kaynak kodu ve fikri mülkiyet hakları, kişisel verilerin korunması, garanti, bakım ve SLA koşulları ile sözleşme bittiğinde veri ve kodun teslimi. Sözleşme imzalanmadan önce bir avukata inceletilmelidir.
Parasını ödediğim yazılımın kaynak kodu bana mı ait olur?
Sözleşmede açıkça yazmıyorsa kendiliğinden ait olmaz. FSEK’e göre mali haklar kural olarak eser sahibindedir; dışarıdaki bir firmaya yazdırılan programda hakların devri için yazılı sözleşme ve devredilen hakların ayrı ayrı gösterilmesi gerekir (FSEK madde 52). Kendi durumunuz için bir avukata danışın.
Yazılım bakım sözleşmesinde neler olmalı?
Bakımın kapsamı (hata düzeltme, güncelleme, küçük geliştirme), yanıt ve çözüm süreleri, erişilebilirlik hedefi, destek saatleri ve kanalları, yedekleme ve geri yükleme koşulları, ücretlendirme ve sözleşmenin sona ermesi halinde veri teslimi.
Kaynak kod emanetçiliği (escrow) nedir?
Kaynak kodun bağımsız bir üçüncü kişide saklandığı ve yazılım firmasının faaliyetini durdurması gibi sözleşmede belirlenen durumlarda iş sahibine teslim edildiği düzenlemedir. Kaynak kodunun devredilmediği kritik yazılımlarda kullanılır.
Yazılım geliştirme sözleşmesi ile lisans sözleşmesi arasındaki fark nedir?
Geliştirme sözleşmesinde yazılım iş sahibi için yeniden yapılır ve uygulamada çoğunlukla eser sözleşmesi olarak değerlendirilir. Lisans sözleşmesinde ise var olan bir yazılımın belirli koşullarla kullanım hakkı verilir; mülkiyet ve kaynak kodu genellikle üreticide kalır.
İlgili hizmet: İhtiyaca özgü yazılım