Yazılım geliştirme sözleşmesi, bir projenin en az kod kadar önemli parçasıdır. İşler yolunda giderken kimse sözleşmeyi açıp okumaz; ancak bir gecikme, kapsam anlaşmazlığı ya da firma değişikliği gündeme geldiğinde her şey bu metne bağlıdır. Bu yazıda yazılım geliştirme sözleşmesinde dikkat edilecek başlıca maddeleri, özellikle kaynak kod mülkiyeti, bakım ve SLA konularını genel hatlarıyla ele alıyoruz.
Önemli not: Bu içerik genel bilgilendirme amaçlıdır ve hukuki danışmanlık yerine geçmez. Sözleşmenizi imzalamadan önce mutlaka bilişim hukuku alanında deneyimli bir avukata inceletmenizi öneririz.
Yazılım geliştirme sözleşmesinin temel yapısı
İyi bir sözleşme genellikle iki katmandan oluşur: tarafların genel hak ve yükümlülüklerini düzenleyen bir çerçeve sözleşme ve her proje ya da faz için hazırlanan, kapsamı ayrıntılandıran ekler (iş tanımı, teknik şartname, proje planı). Bu yapı, yeni bir faz başladığında tüm sözleşmeyi yeniden müzakere etmeden sadece eki güncellemeyi sağlar.
Sözleşmenin dili de önemlidir. Teknik terimlerin tanımlandığı bir "tanımlar" bölümü, "teslim", "hata" veya "kabul" gibi kavramların iki taraf için aynı anlama gelmesini sağlar. Yabancı bir firmayla çalışıyorsanız sözleşmenin hangi dilde hazırlanacağı, uygulanacak hukuk ve yetkili mahkeme de baştan kararlaştırılmalıdır.
Dikkat edilmesi gereken 8 madde
1. Kapsam ve iş tanımı
Neyin yapılacağı kadar neyin yapılmayacağı da yazılmalıdır. Platformlar, özellik listesi, entegrasyonlar, desteklenecek cihaz ve tarayıcılar ile teslim edilecek dokümanlar açıkça belirtilmelidir. Belirsiz bir kapsam, anlaşmazlıkların en yaygın kaynağıdır.
2. Kaynak kod mülkiyeti ve fikri haklar
Sözleşmenin belki de en kritik maddesidir. Geliştirilen yazılımın kaynak kodu, tasarımları ve dokümantasyonu üzerindeki hakların kime ait olacağı açıkça düzenlenmelidir. Türk hukukunda bilgisayar programları Fikir ve Sanat Eserleri Kanunu kapsamında korunur ve mali hakların devrine ilişkin sözleşmelerin yazılı yapılması ve devredilen hakların ayrı ayrı gösterilmesi gerekir. Bu nedenle "tüm haklar müşteriye aittir" gibi genel bir ifade yerine hangi hakların, hangi kapsamda ve ne zaman devredildiği avukatınızla birlikte netleştirilmelidir.
Dikkat edilmesi gereken bir diğer nokta, firmanın daha önce geliştirdiği ve birçok projede kullandığı hazır bileşenler ile açık kaynak kütüphanelerdir. Bunlar genellikle devredilmez, size kullanım lisansı verilir. Hangi parçaların devredildiğini ve hangilerinin lisanslandığını sözleşmede görmek önemlidir.
3. Kabul testleri ve teslim kriterleri
Bir işin "bitti" sayılması için hangi koşulların sağlanması gerektiği tanımlanmalıdır. Test süresi (örneğin teslimden sonraki belirli bir iş günü), hata bildirimi yöntemi ve bu süre içinde geri bildirim verilmezse ne olacağı yazılmalıdır.
4. Ödeme planı
Ödemelerin aşamalara (milestone) bağlanması her iki taraf için de dengeli bir yapıdır. Hangi teslimatın hangi ödemeyi tetiklediği, faturalandırma para birimi ve kur farkı gibi konular açıkça yazılmalıdır.
5. Değişiklik yönetimi
Proje sırasında kapsam neredeyse her zaman değişir. Değişiklik taleplerinin nasıl iletileceği, nasıl fiyatlandırılacağı ve takvime etkisinin nasıl onaylanacağı baştan tanımlanmalıdır.
6. Bakım, destek ve garanti süresi
Teslimden sonraki belirli bir süre boyunca, firmanın kendi hatalarından kaynaklanan sorunları ücretsiz düzeltmesi yaygın bir uygulamadır. Bu garanti süresinden sonra devreye girecek bakım hizmetinin kapsamı, yani güncellemeler, güvenlik yamaları, küçük geliştirmeler ve aylık saat kotası ayrı bir bakım sözleşmesinde ya da ekte tanımlanmalıdır.
7. SLA (hizmet seviyesi anlaşması)
SLA, bir sorun yaşandığında firmanın ne kadar sürede yanıt vereceğini ve çözüm için ne kadar süre çalışacağını tanımlar. Aşağıdaki tablo yalnızca yapıyı göstermek için hazırlanmış bir örnektir; gerçek süreler projenin kritikliğine ve bütçeye göre belirlenir:
| Öncelik | Tanım | Örnek yanıt süresi |
|---|---|---|
| Kritik | Sistem tamamen çalışmıyor, iş duruyor | Birkaç saat içinde |
| Yüksek | Önemli bir özellik çalışmıyor, geçici çözüm yok | Aynı iş günü |
| Orta | Hata var ama geçici çözüm mevcut | Birkaç iş günü |
| Düşük | Görsel ya da küçük iyileştirme talepleri | Planlı bakım döngüsünde |
SLA'da yanıt süresi ile çözüm süresinin farklı kavramlar olduğunu, hangi saatlerin (mesai içi mi, 7/24 mü) kapsandığını ve sürelere uyulmazsa ne olacağını açıkça yazdırın.
8. Gizlilik, kişisel veriler ve fesih
Gizlilik maddesi, iki tarafın da paylaştığı ticari bilgileri korur. Yazılım kişisel veri işliyorsa KVKK kapsamında tarafların rolleri ve alınacak teknik ve idari tedbirler düzenlenmelidir. Fesih maddesinde ise sözleşmenin hangi durumlarda sonlandırılabileceği, o ana kadar yapılan işin nasıl ödeneceği ve kaynak kod, dokümantasyon ve erişim bilgilerinin nasıl teslim edileceği yer almalıdır.
Sözleşme süreci nasıl ilerler?
Pratikte sözleşme süreci çoğunlukla firmanın standart metniyle başlar. Bu metni doğrudan imzalamak yerine kendi ihtiyaçlarınız açısından okuyun ve değişiklik taleplerinizi yazılı olarak iletin. Makul bir yazılım firması, kaynak kod, kabul süreci ve bakım gibi konulardaki taleplerinizi müzakere etmeye açık olmalıdır.
- Teklif ve kapsam dokümanı üzerinde mutabakat sağlanır.
- Çerçeve sözleşme ve ilk iş tanımı taslağı paylaşılır.
- Her iki tarafın hukuk danışmanları metni inceler ve değişiklikler konuşulur.
- Gerekirse gizlilik ve kişisel verilerin işlenmesine ilişkin ek protokoller hazırlanır.
- Sözleşme imzalanır ve proje başlangıç toplantısı yapılır.
Bu süreç birkaç günden birkaç haftaya kadar sürebilir. Projeye başlama baskısı nedeniyle sözleşmeyi aceleye getirmek, ileride çok daha uzun sürecek anlaşmazlıklara kapı açabilir.
Sık yapılan sözleşme hataları
- Kapsamı yalnızca toplantı notlarına ya da e-postalara bırakmak
- Fikri hakları tek cümlelik genel bir ifadeyle geçiştirmek
- Bakım ve destek koşullarını proje bittikten sonra konuşmaya bırakmak
- Fesih halinde neyin, nasıl teslim edileceğini hiç yazmamak
Sözleşmeyi imzalamadan önce kontrol listesi
- Kod deposu ve sunucu hesapları kimin adına açılacak?
- Devredilen ve lisanslanan bileşenler ayrı ayrı belirtilmiş mi?
- Kabul süreci ve süresi tanımlı mı?
- Garanti süresi ve bakım kapsamı yazılı mı?
- SLA süreleri ve kapsadığı saatler net mi?
- Fesih halinde teslim edilecekler listelenmiş mi?
- Bir avukat metni inceledi mi?
Uzun soluklu bir dış ekip çalışması planlıyorsanız bu maddelerin nasıl kurgulandığını outsource yazılım ekibi sayfamızda, proje bazlı işler için ise web yazılım geliştirme sayfamızda inceleyebilirsiniz.
BernSoftware olarak projelerimizde kaynak kodun müşterinin kontrolündeki depolarda tutulmasını, kapsamın ve bakım koşullarının yazılı olarak netleştirilmesini önemsiyoruz. Projenizi konuşmak için bize ulaşın.
Sıkça sorulan sorular
Kaynak kod teslimi ile kaynak kod mülkiyeti aynı şey mi?
Hayır. Kaynak kodun size teslim edilmesi, onu değiştirme, çoğaltma veya başka bir firmaya geliştirtme hakkına sahip olduğunuz anlamına gelmeyebilir. Hangi hakların devredildiğinin ya da lisanslandığının sözleşmede açıkça yazması gerekir.
Kaynak kod emaneti (escrow) nedir, gerekli mi?
Escrow, kaynak kodun bağımsız bir üçüncü tarafta saklandığı ve firmanın faaliyetini durdurması gibi belirli durumlarda müşteriye teslim edildiği bir düzenlemedir. Kod zaten müşterinin kendi deposunda tutuluyorsa genellikle ihtiyaç azalır; kodun firmada kaldığı modellerde değerlendirilebilir.
Hazır sözleşme şablonu kullanmak yeterli mi?
Şablonlar iyi bir başlangıç noktası olabilir ama her projenin kapsamı, riskleri ve tarafların beklentileri farklıdır. Şablonu projenize göre uyarlamak ve bir avukata inceletmek, ileride çıkabilecek anlaşmazlıkları önlemenin en güvenli yoludur.
Böyle bir proje mi planlıyorsun?
10 adımda planla