Yazılım Sözleşmesinde Olması Gerekenler: Madde Madde Rehber
Kapsam, teslim, kabul, ödeme, kaynak kodu, gizlilik ve destek: Bir yazılım projesinde iki tarafı da koruyan sözleşme başlıklarını sade bir dille açıklıyoruz.
İçindekiler
Proje başında herkes iyi niyetlidir; anlaşmazlık genellikle aylar sonra, “bu da dahil değil miydi?” sorusuyla ortaya çıkar. O an elinizdeki tek dayanak, imzaladığınız sözleşmedir. Bu yazıda yazılım sözleşmesinde olması gerekenler başlığını, hem işletmeyi hem geliştiriciyi koruyacak şekilde madde madde ele alıyorum. Yazı genel bilgi amaçlıdır; sözleşmenizin hukuki geçerliliği ve size özel durumlar için mutlaka bir hukukçuya danışmanızı öneririm.
Sözleşme neden teklif dokümanından ayrı düşünülmeli?
Teklif, işin ne olduğunu ve ne kadar tutacağını anlatır. Sözleşme ise bu işin nasıl yürütüleceğini, işler yolunda gitmediğinde ne olacağını ve teslimden sonra hakların kimde kalacağını belirler. Teklifi sözleşmenin eki yapmak iyi bir yöntemdir, ama tek başına yeterli değildir.
Özellikle küçük işletmelerde sözleşme yerine yazışmalarla ilerlemek yaygındır. Bu yaklaşım küçük işlerde sorun çıkarmayabilir; ancak birkaç ay sürecek, işinizin merkezinde yer alacak bir yazılım için yazılı ve imzalı bir sözleşme iki tarafın da güvencesidir. Aşağıda yazılım sözleşmesinde olması gerekenleri, projenin akışına uygun sırayla bulacaksınız.
Yazılım sözleşmesinde olması gerekenler: temel maddeler
1. Taraflar ve işin tanımı
Tarafların açık kimlik bilgileri ve projenin kısa tanımı ilk maddedir. İşin tanımı, sözleşmenin geri kalanını yorumlarken referans alınacağı için genel ama net yazılmalıdır.
2. Kapsam ve kapsam dışı işler
Yapılacak modüller, ekranlar ve işlevler ya doğrudan sözleşmede ya da ek olarak bağlanan bir teknik dokümanda yer almalıdır. Kapsam dışı işler de en az kapsam kadar önemlidir: içerik girişi, ürün yükleme, çeviri, sunucu kiralama, üçüncü taraf hizmet ücretleri gibi kalemlerin kime ait olduğu yazılmalıdır.
3. Kapsam değişikliği prosedürü
Proje sırasında yeni talepler doğacaktır. Bu taleplerin nasıl iletileceği, süreye ve bedele etkisinin nasıl hesaplanacağı ve hangi onayla işleme alınacağı tarif edilmelidir. Yazılı onay olmadan ek iş yapılmaması, iki taraf için de en sağlıklı kuraldır.
4. Takvim ve ara teslimler
Genel teslim tarihinin yanında ara teslimler (tasarım onayı, test sürümü, yayın) belirtilmelidir. Gecikmelerin bir kısmı müşteriden beklenen içerik, onay veya erişim bilgilerinin geç gelmesinden kaynaklanır; bu yüzden müşterinin yükümlülükleri ve bunların takvime etkisi de yazılmalıdır.
5. Kabul testi
İşin “bitti” sayılması için neyin kontrol edileceği, test süresinin ne kadar olacağı ve bulunan hataların nasıl sınıflandırılacağı belirlenmelidir. Bu madde olmadan teslim anı tartışmaya açık kalır. Kabul sürecinin nasıl kurgulanacağını web projesi kabul testi yazısında ayrıntılı anlattım.
6. Ödeme planı
Ödemelerin ara teslimlere bağlanması dengeli bir yöntemdir: Başlangıçta bir avans, belirli aşamalarda ara ödemeler ve kabul sonrasında kalan tutar. Gecikmeli ödemenin sonuçları ve faturalama koşulları da bu maddede yer alır.
Kaynak kodu, mülkiyet ve lisans
Yazılım sözleşmesinde olması gerekenler arasında bu bölüm, en çok ihmal edilen ama ileride en çok önem kazanan kısmıdır. Şu sorulara açık cevap verilmelidir:
- Teslim edilen yazılımın kaynak kodu müşteriye verilecek mi, hangi aşamada?
- Müşteri yazılımı başka bir geliştiriciye geliştirtebilir mi?
- Geliştiricinin daha önce yazdığı ve projede kullandığı genel bileşenlerin durumu ne olacak?
- Projede kullanılan açık kaynak kütüphanelerin lisans koşullarına uyulacak mı?
- Sunucu, alan adı, mağaza ve servis hesapları kimin adına açılacak?
Kaynak kodunun teslim biçimi ve neden önemli olduğu konusunu kaynak kodu teslimi yazısında ayrıca ele aldım. Burada özetle şunu söyleyebilirim: Hesapların ve kodun sizin elinizde olması, işletmenizin tek bir kişiye bağımlı kalmamasını sağlar.
Gizlilik, kişisel veriler ve güvenlik
Geliştirme sürecinde geliştirici, işletmenizin müşteri listelerine, fiyat yapısına veya iş süreçlerine erişebilir. Bu bilgilerin gizli tutulacağına dair bir madde eklenmelidir. Yazılım kişisel veri işleyecekse, KVKK kapsamındaki yükümlülüklerin nasıl paylaşılacağı, verilerin nerede barındırılacağı ve erişim yetkilerinin nasıl yönetileceği de konuşulmalıdır. Bu konudaki ayrıntılar için bir hukukçudan görüş almanız önemlidir.
Garanti, bakım ve destek
Teslimden sonra ortaya çıkan hatalar için bir garanti süresi tanımlanması yaygın bir uygulamadır. Bu süre içinde, kapsam dahilindeki işlevlerde çıkan hataların ücretsiz düzeltilmesi beklenir. Garanti süresi bittikten sonra ise ayrı bir bakım anlaşması devreye girer.
Sözleşmede şu ayrımın yapılması önemlidir:
| Durum | Genellikle nasıl ele alınır? |
|---|---|
| Kapsamdaki bir işlevin hatalı çalışması | Garanti süresi içinde düzeltme |
| Yeni özellik talebi | Kapsam değişikliği olarak fiyatlanır |
| Üçüncü taraf servisin değişmesi | Bakım anlaşmasına veya ayrı işe göre ele alınır |
| Müşterinin sunucuda yaptığı değişiklikten doğan sorun | Garanti dışı kabul edilir |
Bakım anlaşmasının hangi başlıkları içermesi gerektiğini yazılım bakım ve destek anlaşması yazısında topladım.
Sorumluluğun sınırı ve fesih
Son olarak, işler beklendiği gibi gitmezse ne olacağı yazılmalıdır. Taraflardan biri yükümlülüğünü yerine getirmezse sözleşmenin nasıl sona erdirileceği, o ana kadar yapılan işin nasıl değerlendirileceği ve teslim edilmiş kodun durumu bu bölümde yer alır. Anlaşmazlık durumunda hangi yolun izleneceği de belirtilir.
Bu maddeler karamsar görünebilir, ama aslında iki tarafa da güven verir: Herkes, en kötü senaryoda bile neyle karşılaşacağını bilir.
Bu işi nasıl birlikte yaparız?
- İhtiyacı dinleme: Projenin kapsamını ve sizin için kritik noktaları (kaynak kodu, hesap sahipliği, destek süresi) baştan konuşuruz.
- Kapsam ve teklif: Teklifi, sözleşmeye ek yapılabilecek netlikte; kapsam, kapsam dışı işler, ara teslimler ve ödeme planıyla hazırlarım.
- Sözleşme ve geliştirme: Kabul testi ve kapsam değişikliği kurallarını yazılı hâle getirip geliştirmeye başlarız; her ara teslimde çalışan sürümü görürsünüz.
- Teslim ve destek: Kaynak kodu ve erişim bilgilerini sözleşmede belirlediğimiz şekilde teslim eder, garanti ve bakım sürecini başlatırım.
Projenizi bu çerçevede konuşmak isterseniz iletişim sayfasından bana ulaşabilirsiniz.
Sık sorulan sorular
Küçük bir proje için de sözleşme gerekir mi?
Kısa süreli ve küçük işlerde ayrıntılı bir teklif ile yazılı onay çoğu zaman yeterli olabilir. İşinizin merkezinde yer alacak, birkaç ay sürecek projelerde ise imzalı bir sözleşme önerilir.
Kaynak kodunu almak her zaman mümkün müdür?
Özel geliştirilen projelerde kaynak kodunun müşteriye teslimi yaygındır. Hazır bir ürünün lisanslandığı durumlarda ise kod geliştiricide kalabilir. Hangisinin geçerli olduğu sözleşmede açıkça yazılmalıdır.
Sözleşmeyi kim hazırlamalı?
Taslağı taraflardan biri hazırlayabilir, ancak imzadan önce her iki tarafın da dikkatle okuması gerekir. Önemli projelerde kesin hukuki değerlendirme için bir avukata danışmanızı öneririm.
Proje sırasında kapsam değişirse sözleşme yeniden mi yapılır?
Genellikle sözleşmeyi baştan yapmak gerekmez. Sözleşmede tanımlanan kapsam değişikliği prosedürüne göre yazılı bir ek veya onay hazırlanır ve süre ile bedel buna göre güncellenir.
Sonuç
Yazılım sözleşmesinde olması gerekenler; kapsam, takvim, kabul testi, ödeme planı, kaynak kodu ve hesap sahipliği, gizlilik, garanti ve fesih başlıklarında toplanır ve iyi yazılmış bir sözleşme iki tarafın da işini kolaylaştırır. Projenizi açık kurallarla başlatmak isterseniz bana yazabilirsiniz.