Çoğu işletme sahibi sözleşmeyi bir formalite sanır. Fiyat konuşulmuş, demo görülmüş, ödeme planı netleşmiştir; kalan iki sayfa da nezaketen okunur gibi yapılıp altı imzalanır. Oysa e-pin işinde sözleşme, sistemin kendisinden daha uzun ömürlü bir belgedir. Kod bozulur, sunucu değişir, sürüm eskir; ama bir uyuşmazlık çıktığında herkesin döneceği tek metin o iki sayfadır.
Burada anlatacağım şey hukuk dersi değil. Sahada gördüğüm, işletmeye gerçekten para ve zaman kaybettiren madde boşluklarıdır. Bir e-pin scripti alırken ticari olarak en kritik nokta, satın aldığın hakkın tam olarak nerede başlayıp nerede bittiğinin yazılı olmasıdır. Aşağıdaki dokuz başlığı sözleşmede aradığında, satıcının ciddiyetini de kendi risk seviyeni de ilk yirmi dakikada anlarsın.
Madde 1: Sana verilen hak lisans mı, mülkiyet mi?
Bu ayrım her şeyin temelidir. Lisans, kodu belirli koşullarda kullanma iznidir; mülkiyet ise kod üzerindeki hakların tamamıdır. Piyasada satılan dijital ürün satış scripti ürünlerinin büyük bölümü lisans modelidir ve bu kendi başına bir sorun değildir. Sorun, sözleşmede "satış" kelimesi kullanılırken ekte lisans kısıtları sıralandığında ortaya çıkar. İki kavram karışırsa, sistemi ikinci bir markaya taşımak istediğin gün karşına beklemediğin bir fatura çıkar.
İstediğin cümle çok basittir: verilen hakkın türü, süresi ve coğrafi kapsamı tek paragrafta yazılı olmalı. Süresiz lisans alıyorsan "süresiz" kelimesi metinde geçmeli; yıllık yenilemeli bir haksa yenileme koşulu ve ücret artış üst sınırı belirtilmeli. Sözlü verilen "tabii ki süresiz" güvencesi, uyuşmazlık anında hiçbir işe yaramaz.
Madde 2: Kaynak kodu erişimi ve şifrelenmiş dosyalar
Birçok e-pin satış yazılımı paketinde çekirdek dosyalar şifrelenmiş olarak teslim edilir. Bu, satıcının ürününü korumak için kullandığı meşru bir yöntemdir; ancak senin için anlamı şudur: o dosyalarda bir hata olduğunda düzeltmeyi yalnızca satıcı yapabilir. Sözleşmede şifreli dosyaların listesi, bu dosyalarda çıkan hataların hangi sürede giderileceği ve satıcının faaliyeti sona ererse ne olacağı yazılı olmalı.
Bu son nokta çoğu metinde hiç yer almaz ve en can yakıcı olandır. Basit bir çözümü var: faaliyetin sona ermesi halinde şifresiz kodun teslim edilmesini öngören bir madde. Buna itiraz etmeyen satıcı, uzun vadeli düşünen satıcıdır.
| Madde başlığı | Riskli ifade | Olması gereken ifade | Risk seviyesi |
|---|---|---|---|
| Hak türü | "Yazılım satılmıştır" | "Süresiz, tek alan adı kullanım lisansı" | Yüksek |
| Kaynak kod | Hiç bahsedilmemiş | Şifreli dosya listesi + acil durum teslimi | Yüksek |
| Güncelleme | "Gerekli güncellemeler yapılır" | "12 ay boyunca tüm sürüm güncellemeleri" | Yüksek |
| Destek | "Destek sağlanır" | Kanal, çalışma saati, yanıt süresi | Orta |
| Devir | "Devredilemez" | "Yazılı bildirimle bir kez devredilebilir" | Orta |
| Veri | Hiç bahsedilmemiş | "Tüm veri talep halinde dışa aktarılır" | Yüksek |
| Fesih | Tek taraflı, sebepsiz | Karşılıklı, 30 gün ihbarlı | Orta |
Madde 3: Güncelleme kapsamı ile hata giderme aynı şey değil
Sözleşmelerde en sık karıştırılan iki kavram bunlar. Hata giderme, teslim edilen sürümün vaat edilen şekilde çalışmamasının düzeltilmesidir ve makul bir süre boyunca bedelsiz olmalıdır. Güncelleme ise yeni özellik, yeni entegrasyon ve mevzuat uyumu getiren geliştirmedir; bunun ücretli olması normaldir. Metinde bu iki kalem ayrı ayrı tanımlanmıyorsa, her hata talebine "bu güncelleme kapsamında" cevabı gelme riski vardır.
Pratik çözüm şudur: hata gideriminin süresini ve kapsamını tek cümleyle yaz, güncellemeyi ayrı bir bakım ekine bağla. Böylece iki taraf da neyi beklediğini bilir. Pinova gibi lisanslı bir epin yazılım çözümünü değerlendirirken de ilk sorman gereken şey bu ayrımın nasıl kurulduğudur.
Madde 4: Devir, ikinci alan adı ve büyüme senaryoları
Bugün tek markayla başlıyorsun, iki yıl sonra ikinci bir alan adı açmak isteyebilirsin ya da işi satmak gündeme gelebilir. Lisansın devredilebilirliği, işletmenin değerini doğrudan etkileyen bir unsurdur. Devredilemez lisansla çalışan bir işi satmak istediğinde, alıcı sıfırdan lisans almak zorunda kalır ve bu pazarlıkta doğrudan senin aleyhine bir kalem olur.
Makul talep şudur: yazılı bildirim şartıyla, işletmenin tamamının devri halinde lisansın da devredilebilmesi. Ek alan adı için ise önceden belirlenmiş, sabit bir ek lisans bedeli. İkisi de sözleşme anında iki satırla çözülür.
Sözleşme kaynaklı uyuşmazlıkların dağılımı
- Güncelleme ve destek kapsamı 40%
- Lisans kapsamı ve alan adı 30%
- Devir ve fesih koşulları 20%
- Veri ve teslim yükümlülüğü 10%
Madde 5: Verinin sahibi kim, çıkış kapısı nerede?
Müşteri kayıtları, sipariş geçmişi, bakiye hareketleri ve fatura verisi senin ticari varlığındır. Buna rağmen pek çok sözleşmede verinin kime ait olduğu ve ilişki sona erdiğinde nasıl teslim edileceği yazmaz. Sunucu senin elindeyse risk düşüktür; ancak satıcı barındırmalı bir kurulumda çalışıyorsan bu madde hayati hale gelir.
Şunu ara: verinin işletmeye ait olduğunun açıkça belirtilmesi, talep halinde standart bir formatta eksiksiz dışa aktarılması ve bu işlemin ücretsiz ya da önceden belirlenmiş bir bedelle yapılması. Çıkış kapısı olmayan bir sisteme girmek, ne kadar iyi çalıştığından bağımsız olarak stratejik bir zayıflıktır.
Sözleşmeyi okurken her maddenin yanına "bu cümle mahkemede ne anlatır?" sorusunu sor. Cevabı belirsiz olan her ifadeyi sayı, süre veya liste haline getirmesini iste; itiraz gelmeyen her düzeltme iyi bir işarettir.
Madde 6-9: Destek, fesih, gizlilik ve sorumluluk sınırı
Destek maddesinde tek başına "destek sağlanır" ifadesi hiçbir şey söylemez. Kanal, çalışma saatleri, ilk yanıt süresi ve kapsam dışı işler tek paragrafta yer almalı. Fesih maddesinde ise tek taraflı ve sebepsiz fesih hakkı yalnızca satıcıya verilmişse dengesiz bir metinle karşı karşıyasın; karşılıklı ve ihbar süreli fesih standarttır.
Gizlilik maddesi iki yönlü olmalı: sen kodun detaylarını paylaşmayacaksın, satıcı da müşteri ve ciro verilerini kullanmayacak. Son olarak sorumluluk sınırı maddesine dikkat et; satıcının sorumluluğunu tamamen kaldıran ifadeler yaygındır ama makul olan, ödenen bedelle sınırlı bir sorumluluk tanımıdır. Bu dört başlık, iyi bir dijital ürün satış yazılımı sözleşmesini vasat olandan ayıran kısımdır.
| İmza öncesi kontrol | Nasıl doğrularsın | Kırmızı bayrak | Durum |
|---|---|---|---|
| Hak türü net yazılı | Metinde "lisans/süresiz" ara | Sözlü güvence verilmesi | Zorunlu |
| Güncelleme süresi ay cinsinden | Sayı geçiyor mu bak | "Gerektiğinde" ifadesi | Zorunlu |
| Destek yanıt süresi | Saat/iş günü belirtilmiş mi | Kanal adı verilmemesi | Zorunlu |
| Veri dışa aktarımı | Format ve ücret yazılı mı | Maddenin hiç olmaması | Zorunlu |
| Devir koşulu | Bildirim usulü var mı | Mutlak devir yasağı | Önerilir |
| Fesih dengesi | İki taraf için de geçerli mi | Tek taraflı sebepsiz fesih | Zorunlu |
| Teslim listesi | Dosya ve modüller ek olarak | Genel "tüm sistem" ifadesi | Önerilir |
Şeffaf kapsam, kısa sözleşme demektir
Pinova'nın lisans, güncelleme ve destek kapsamını madde madde gör; kontrol listenle karşılaştır.
Sözleşmeyi okuma sırası: yirmi dakikada nasıl tarar?
Metni baştan sona okumak yerine şu sırayı izle. Önce hak türü ve süre, sonra güncelleme ve destek, ardından veri ve teslim, en son fesih ve sorumluluk. Bu sıra riski büyükten küçüğe tarar; ilk iki blokta ciddi bir boşluk görürsen kalanını okumaya bile gerek kalmaz, doğrudan düzeltme talep edersin. Özellik listesiyle sözleşme ekini yan yana koymak da işe yarar: vaat edilen her özelliğin teslim listesinde karşılığı olmalı.
Sözleşmede değişiklik istemek satıcıyı rahatsız eder mi?
Profesyonel bir satıcıyı etmez. Netleştirme talebi, uzun vadeli çalışmak isteyen alıcının işaretidir. İtiraz eden taraf genelde belirsizlikten faydalanmayı planlayan taraftır.
Kaynak kodu şifreli teslim edilmesi kabul edilebilir mi?
Evet, yaygın ve meşru bir uygulamadır. Ancak şifreli dosyaların listesi, hata giderme süresi ve satıcının faaliyeti sona ererse ne olacağı yazılı olmalıdır.
Lisansın devri neden bu kadar önemli?
İşini satmak veya ikinci bir markaya taşımak istediğinde devredilemez lisans doğrudan değer kaybı yaratır. Bildirim şartlı devir hakkı bu riski ortadan kaldırır.
Sözleşme imzalamadan sistemi test edebilir miyim?
Edebilmelisin. Demo veya test ortamında sipariş, stok ve ödeme akışını denemek, sözleşme müzakeresinde neyi talep edeceğini de netleştirir.
Sözleşme, satın alma sürecinin en sıkıcı ama en yüksek getirili yirmi dakikasıdır. Yukarıdaki dokuz başlığı tek tek sorduğunda hem riskini düşürür hem de karşı tarafın ne kadar kurumsal çalıştığını görürsün. Pinova'nın panel yapısını, sipariş ve bakiye akışını sözleşme müzakeresine girmeden önce kendi gözünle görmek istersen canlı demo üzerinden dolaşabilir, ardından fiyat ve kapsam bilgisini kontrol listenle eşleştirebilirsin.

