Yazılım Uyuşmazlıklarının Çoğu Tek Bir Eksik Maddeden Çıkıyor

Bir yazılım uyuşmazlığı dosyası açıldığında taraflar genellikle şunu tartışıyor. Yazılım çalışıyor mu çalışmıyor mu.

Bu tartışmanın çözülememesinin sebebi teknik değil. Sözleşmede "çalışıyor" kelimesinin ne anlama geldiği yazmıyor. Kabul ölçütü yoksa, geliştirici teslim ettiğini, müşteri almadığını söylüyor ve ikisi de kendi ölçütüne göre haklı.

Bu tek eksiklik, gördüğüm yazılım uyuşmazlıklarının ortak paydası.

Kabul ölçütü nasıl yazılmalı

Kabul, teslimin hukuki sonucunu doğuran an. Ayıp sorumluluğunun süresi de buradan işlemeye başlıyor. Yani bu tarihin belirsiz olması, sorumluluğun ne zaman biteceğinin de belirsiz olması demek.

Çalışan bir kabul maddesi şunları içeriyor. Kabul testinin listesi, testin koşulacağı ortam, testi kimin koşacağı, itiraz süresi ve süre içinde itiraz gelmezse kabulün gerçekleşmiş sayılacağı hükmü.

En çok atlanan kalem test ortamı. Geliştiricinin makinesinde çalışan yazılım, müşterinin ortamında çalışmayabiliyor ve o noktada kimin sorumlu olduğu tartışılıyor. Ortam sözleşmede tanımlanmışsa bu tartışma çıkmıyor.

Kabul ölçütünü beğeniye bağlamak ise en kötü seçenek. "Müşterinin memnuniyetine" bağlanan bir kabul, süresiz bir yükümlülük yaratıyor ve geliştiricinin işi hiç bitmiyor.

Fikri haklar kendiliğinden geçmiyor

İkinci sık hata mülkiyet varsayımı. Müşteri, ödediği bedelin karşılığında kodun sahibi olduğunu düşünüyor. Hukuken durum böyle değil.

Bilgisayar programları 5846 sayılı Kanun kapsamında eser olarak korunuyor ve aksi kararlaştırılmadıkça mali haklar eser sahibinde kalıyor. Devir açıkça düzenlenmeli, yazılı yapılmalı ve devredilen haklar tek tek gösterilmeli. "Tüm haklar devredilmiştir" biçimindeki genel bir ifade tartışmaya açık.

Bunun yanında üç kategorinin ayrılması gerekiyor. Müşteriye özgü olarak yazılan kod genellikle devrediliyor. Geliştiricinin önceden var olan bileşenleri devredilmiyor, lisanslanıyor ve lisansın kapsamı ile süresi ayrıca yazılıyor. Açık kaynak bileşenler kendi lisanslarına tabi ve kullanılanların listesi sözleşme ekinde verilmeli.

Bu üçü ayrılmadığında ortaya şu çıkıyor. Müşteri kodun tamamına sahip olduğunu sanıyor, geliştirici kendi kütüphanesini başka projede kullanmaya devam ediyor ve mesele ancak bir uyuşmazlıkta fark ediliyor.

Değişiklik yönetimi olmayan sözleşme yürümez

Kapsam metni ne kadar iyi yazılırsa yazılsın, proje sırasında değişiklik talebi geliyor. Sözleşmede bu talebin nasıl ele alınacağı yazmıyorsa her talep bir pazarlığa dönüşüyor.

Çalışan bir düzenleme şu soruları cevaplıyor. Talep kime, hangi biçimde iletilir. Etki analizi kim tarafından, kaç gün içinde yapılır. Fiyat ve takvim etkisi nasıl hesaplanır. Onay kimin imzasıyla verilir. Onaylanmayan talep ne olur.

Bu beş soru cevaplandığında değişiklik bir kriz olmaktan çıkıp bir süreç hâline geliyor.

Veri işleyen sıfatı fark edilmeden doğuyor

Geliştirici, müşterinin kişisel verilerine erişiyorsa 6698 sayılı Kanun anlamında veri işleyen konumuna geliyor. Bu sıfat çoğu zaman farkında olunmadan kazanılıyor.

En yaygın hâli test ortamında gerçek veri kullanılması. Üretim veritabanının bir kopyası test ortamına alınıyor, geliştiriciler onunla çalışıyor ve o andan itibaren bir veri işleme ilişkisi doğmuş oluyor. Sözleşmede buna dair hüküm yoksa, ilişki hukuki dayanaktan yoksun yürüyor.

En temiz çözüm bu durumu hiç doğurmamak. Maskelenmiş veya sentetik veriyle test yapmak teknik olarak zor değil ve riski büyük ölçüde ortadan kaldırıyor. Gerçek veriye erişim gerçekten zorunluysa, işlemenin konusu, süresi ve amacı, geliştiricinin talimatla bağlılığı, alt işleyen kullanımı, güvenlik tedbirleri ve sözleşme sonunda verinin iadesi veya imhası yazılı olarak düzenlenmeli.

Bakım ayrı bir sözleşmedir

Son olarak bakım ve destek. Bu, geliştirmeden ayrı bir edim ve ayrı düzenlenmesi gerekiyor.

Yazılması gereken şey müdahale süresi değil, arıza sınıflandırması. Hangi arızanın hangi sınıfa gireceği tanımlanmazsa, her arıza en yüksek öncelikte talep ediliyor. Sınıf tanımlandıktan sonra her sınıf için müdahale ve çözüm süresi ayrı ayrı yazılıyor.

Bir de ölçüm meselesi var. Hizmet seviyesi taahhüdü, ölçülebilir değilse ihlal edildiğinde yaptırımsız kalıyor. Ölçümün nasıl yapılacağı ve kimin kaydına göre yapılacağı sözleşmede olmalı.

Sözleşmeyi kim yazmalı

Bu maddelerin tamamı, hukuk ile mühendisliğin birlikte karar vermesini gerektiriyor. Kabul ölçütünü avukat tek başına yazamaz, çünkü neyin test edilebilir olduğunu bilmez. Fikri hak devrini mühendis tek başına yazamaz.

Sözleşme müzakeresine teknik ekip olmadan giden taraf, sonradan uygulanamayacak hükümler kabul ediyor. Uygulanamayan hüküm, uyuşmazlık çıktığında hiç yokmuş gibi davranıyor.