Yazılım Geliştirme Sözleşmesi: Kaynak Kod, Kabul Testi ve Fikrî Haklar

Kısa cevap: Yazılım geliştirme sözleşmesinde bedelin ödenmesi, kaynak kodun teslimi ve fikrî hakların devri aynı şey değildir. Müşteri; çalışan bir ürünün yanında depo erişimi, kurulum dosyaları, teknik doküman, bağımlılık listesi ve açıkça tanımlanmış mali hakları istiyorsa bunların her birini sözleşmeye yazmalıdır. Kabul testi, “müşteri uygun görürse” biçiminde değil; test ortamı, veri seti, başarı eşiği, hata sınıfları ve ret süresiyle ölçülebilir kurulmalıdır. Uyuşmazlıkta hangi sürümün teslim edildiği, hatanın kapsam içi olup olmadığı ve hak devrinin yazılı ve ayrı ayrı gösterilip gösterilmediği belirleyici olur. İyi bir metin, geliştirme sürecini aşamalara ve doğrulanabilir kayıtlara bağlar.

Yazılım geliştirme sözleşmesi hukuken nasıl nitelendirilir?

Müşteriye özgü, sonuç taahhüdü içeren bir yazılım projesi eser sözleşmesi hükümlerine yaklaşabilir. Sürekli ekip tahsisi, danışmanlık, bakım, barındırma ve lisans unsurları aynı ilişkide bulunuyorsa karma bir sözleşme ortaya çıkar. Hukuki nitelendirme; ayıp bildirimi, ücret, fesih, zamanaşımı ve sorumluluk hükümlerini etkileyebilir. Sözleşmenin başlığına “hizmet sözleşmesi” yazılması tek başına sonuca götürmez; tarafların fiilî edimleri incelenir.

Proje sözleşmesi ayrıca 5846 sayılı Fikir ve Sanat Eserleri Kanunu bakımından yazılım üzerindeki hakları, Türk Borçlar Kanunu bakımından teslim ve ayıbı, Türk Ticaret Kanunu bakımından tacirlerin davranış ve ticari uyuşmazlıklarını gündeme getirir. Çalışan veya dış geliştirici tarafından oluşturulan kodda hak zinciri ayrıca kurulmalıdır. Çalışan yazılımındaki özgül ayrımlar için çalışanın yazılımı ve telif hakları rehberi tamamlayıcıdır; bu yazı ise müşteri ile yazılım şirketi arasındaki proje teslimine odaklanır.

Kapsam ve kilometre taşları nasıl tanımlanır?

“Mobil uygulama geliştirilecektir” ifadesi teslim borcunu ölçmeye yetmez. Fonksiyon listesi; kullanıcı rolleri, ekran akışları, entegrasyonlar, performans hedefleri, desteklenen cihazlar, erişilebilirlik ve güvenlik gereksinimleriyle birlikte sürümlenmelidir. Teknik şartname ile teklif çelişirse hangisinin üstün olduğu yazılmalıdır.

Kilometre taşı yalnız tarih değildir. Her aşama için teslim paketi, sorumlu taraf, müşterinin sağlayacağı veri veya erişim, inceleme süresi ve ödeme oranı gösterilmelidir. Örneğin “beta sürüm” yerine çalışacak fonksiyonlar, bilinen eksikler ve test ortamı tanımlanır. Müşteri kaynaklı gecikmenin takvime etkisi otomatik ve sınırsız olmamalı; geliştirici gecikmeyi, etkisini ve yeni planı zamanında bildirmelidir.

Proje başlangıcında dondurulması gereken belgeler

• İş kapsamı ve kapsam dışı işler listesi,
• Mimari ve entegrasyon sorumluluk matrisi,
• Kilometre taşı ve ödeme planı,
• Kabul test planı ile örnek veri seti,
• Kaynak kod deposu ve erişim modeli,
• Fikrî hak, gizlilik ve açık kaynak politikası,
• Değişiklik talebi formu ve fiyat yöntemi,
• Bakım, garanti ve üretime geçiş planı.

Kabul testi ve ayıp bildirimi nasıl işletilir?

Kabul testi, müşterinin keyfî beğenisine veya geliştiricinin tek taraflı “tamamlandı” bildirimine bırakılmamalıdır. Test ortamının üretime benzerliği, kimin test verisi sağlayacağı, senaryolar, başarı yüzdesi ve hataların kritiklik sınıfı sözleşmeye eklenmelidir. Kritik hata ödeme işlemini veya veri bütünlüğünü engellerken, kozmetik bir hizalama sorunu aynı sonucu doğurmayabilir.

Teslimden sonra müşteriye makul inceleme süresi verilir. Ret bildirimi, başarısız test adımını, beklenen davranışı, gözlenen sonucu ve mümkünse ekran/log kaydını içermelidir. Geliştiriciye düzeltme süresi tanınır; tekrar testinin kapsamı belirlenir. “Süre içinde cevap verilmezse bütün yönleriyle kesin kabul” hükmü, gizli ayıp veya sonradan ortaya çıkan güvenlik açığı bakımından ayrıca sınırlandırılmalıdır. Bununla birlikte eser sözleşmesi hükümleri uygulanıyorsa sonradan ortaya çıkan gizli ayıp öğrenildiğinde gecikmeksizin bildirim yapılmaması, o ayıp bakımından kabul sonucunu doğurabilir.

Kabul, garanti ve bakım birbirinden ayrıdır. Kabul edilen sürümde garanti döneminde ortaya çıkan kapsam içi hata ücretsiz giderilebilir; yeni özellik talebi ise değişiklik sürecine girer. Her hata kaydına yeni özellik etiketi koymak da, her yeni isteği ayıp saymak da proje dengesini bozar.

Kaynak kod teslimi hangi unsurları kapsar?

Kaynak kod, yalnız sıkıştırılmış bir klasör değildir. Çalıştırılabilir ve sürdürülebilir teslim için depo geçmişi, dallar, derleme talimatı, bağımlılık sürümleri, çevre değişkeni şablonu, veritabanı şeması, dağıtım betikleri ve testler gerekebilir. Gizli anahtar ve gerçek kullanıcı parolaları teslim paketine konulmamalı; güvenli anahtar devir yöntemi kullanılmalıdır.

Müşterinin proje boyunca depoya okuma erişimi, teslim anında sürprizi azaltır. Geliştirici tüm kodu kendi hesabında tutacaksa belirli aralıklarla doğrulanabilir yedek veya emanet mekanizması kurulabilir. Kaynak kod erişimi, fikrî mülkiyet devri anlamına gelmez; tersine hak devri yapılmış olsa bile kod ve dokümana fiilen ulaşılamaması hakkın kullanımını engelleyebilir.

Kaynak kod teslim kontrolü

1. Etiketlenmiş son sürümün commit kimliği kayda alınır.
2. Temiz bir ortamda bağımsız derleme yapılır.
3. Otomatik testler ve güvenlik taraması çalıştırılır.
4. Üçüncü taraf paket listesi ile lisanslar karşılaştırılır.
5. Üretime geçiş ve geri dönüş adımı denenir.
6. Yönetici hesapları kurumsal hesaba devredilir.

Yazılım üzerindeki fikrî haklar nasıl devredilir?

FSEK uyarınca mali haklara ilişkin sözleşme ve tasarrufların yazılı olması ve devredilen ya da lisanslanan hakların ayrı ayrı gösterilmesi geçerlilik şartıdır. “Tüm telif hakları müşteriye aittir” cümlesi; işleme, çoğaltma, yayma, temsil ve umuma iletim gibi mali hakların kapsamı, süre, yer ve kullanım biçimi bakımından uyuşmazlık çıkarabilir. Manevi haklar ile mali haklar aynı şekilde ele alınmaz.

Proje başlamadan henüz meydana gelmemiş yazılımlar için hak devri kurulurken gelecekteki eserlere ilişkin ayrım gözetilmelidir. Henüz meydana getirilmemiş bir eser üzerindeki mali hak doğrudan devredilemez; buna karşılık gelecekte doğacak mali hakların devrine ilişkin yazılı bir taahhüt, kanundaki sınırlar içinde kurulabilir. Bu nedenle teslim edilen her sürüm için eser ve hak zincirini belirleyen yazılı teyit ile devir mekanizması tasarlanmalıdır. Bedelin içinde hak devri karşılığının bulunup bulunmadığı ve devrin ödeme mi yoksa kabul anında mı gerçekleşeceği açık olmalıdır.

Geliştiricinin projeden önce sahip olduğu kütüphaneler “arka plan fikrî mülkiyeti” olarak listelenebilir. Müşteriye özgü kod ile genel araçların sınırı belirlenmezse geliştirici başka projelerde temel kütüphanesini kullanamaz hâle gelebilir veya müşteri satın aldığını sandığı çekirdek bileşene bağımlı kalabilir. Müşterinin ürünü işletmek, değiştirmek ve üçüncü kişiye bakım yaptırmak için gerekli lisansı kesintisiz kullanabilmesi sağlanmalıdır.

Açık kaynak ve üçüncü taraf bileşenler nasıl yönetilir?

Modern yazılım çok sayıda açık kaynak paket içerir. “Açık kaynak kullanılmıştır” demek yeterli değildir. Yazılım bileşen listesi, sürüm, lisans türü, değişiklik yapılıp yapılmadığı ve dağıtım biçimi kaydedilmelidir. Bazı lisanslar bildirim veya kaynak kod sunma yükümlülüğü doğurabilir; bazı ticari paketler ise müşteri başına ek ücret ister.

Geliştirici, lisans uyumluluğunu ve bilinen kritik açıkların takibini üstlenebilir; müşteri de sonradan kendi eklediği bileşenlerden sorumlu olur. Üçüncü taraf servisinin kapanması hâlinde kimin alternatif sağlayacağı ve fiyat değişikliğini kimin taşıyacağı sözleşmede gösterilmelidir. Bileşenlerin güncel envanteri, hem fikrî hak hem siber güvenlik delilidir.

Yazılım geliştirme sözleşmesi ve KVKK rolleri nasıl ayrılır?

Geliştirme, kabul testi, hata incelemesi, depo veya destek ortamında kişisel veri kullanılıyorsa kaynak kodun ya da mali hakların devri bu işlemeyi kendiliğinden hukuka uygun hâle getirmez. Amaç ve vasıtaları fiilen belirleyen taraf ile talimatla veri işleyen taraf somut akışa göre belirlenmelidir. Üretim verisi yerine anonim veya sentetik test verisi kullanılması, yetkilerin sınırlandırılması ve loglarda gereksiz kişisel verinin maskelenmesi öncelikli olmalıdır.

Veri işleme eki; veri kategorisini, test ve destek amacını, saklama süresini, alt geliştiricileri, olay bildirimini ve proje sonunda iade veya silmeyi düzenlemelidir. Yurt dışındaki kod deposu, hata takip sistemi veya destek ekibine erişim varsa 6698 sayılı Kanun’un güncel yurt dışı aktarım mekanizması ayrıca kurulmalıdır. Fikrî hak devri, gizlilik hükmü veya müşterinin genel onayı bu mekanizmanın yerine geçmez.

Değişiklik talebi ve ek iş ayrımı

Proje sırasında ihtiyaç değişebilir. Her değişiklik sözlü toplantı notuyla yürütülürse teslim tarihi, ücret ve kabul kapsamı belirsizleşir. Değişiklik talebinde yeni ihtiyacın açıklaması, etkilenen modüller, tahmini efor, güvenlik ve veri etkisi, fiyat ve takvim bulunmalıdır. Yetkili kişiler onay vermeden çalışma başlamamalıdır.

Başlangıç şartnamesinde bulunan bir fonksiyonun sonradan “ek iş” diye fiyatlandırılması ile gerçekten yeni bir entegrasyonun ücretsiz istenmesi farklıdır. Önce kapsamın sürümü ve teklif varsayımları karşılaştırılır. Acil değişikliklerde dahi sonradan geriye dönük fiyat yaratmak yerine kısa bir elektronik onay akışı kullanılabilir. Güvenli elektronik imza ve ticari elektronik kayıtlar, ispat düzeni gözetilerek yapılandırılmalıdır.

Ödeme, gecikme ve fesih hükümleri

Peşin bedelin tamamını takvim tarihine bağlamak müşteri açısından, bütün ödemeyi son kabule bırakmak geliştirici açısından risklidir. Ölçülebilir kilometre taşı ile ödeme ilişkilendirilmelidir. İhtilaflı teslim tutarı ile kabul edilmiş işin bedeli ayrılabilir. Fatura düzenlenmesi tek başına teknik kabulün gerçekleştiğini göstermeyebilir; tarafların süregelen uygulaması da incelenir.

Gecikmede önce neden ve sorumluluk belirlenir. Müşterinin API anahtarını geç vermesi, geliştiricinin personel eksikliği ve üçüncü taraf onayının gecikmesi aynı değildir. Gecikme cezasının üst sınırı, tek çözüm olup olmadığı ve daha fazla zarar talebiyle ilişkisi açıkça yazılır.

Genel sorumluluk tavanı; ücret, veri kaybı, gizlilik ve fikrî hak risklerini aynı kefeye koymamalıdır. Türk Borçlar Kanunu uyarınca borçlunun ağır kusurundan sorumlu olmayacağına ilişkin önceden yapılan anlaşma kesin hükümsüzdür. Alt geliştirici veya başka bir yardımcı kişinin fiilinden doğan sorumluluğun sınırlandırılması ise yardımcı kişilere ilişkin ayrı kurallara tabidir; özellikle uzmanlık gerektiren ve ancak kanun ya da yetkili makam izniyle yürütülebilen hizmetlerde kanuni sınırlamalar ayrıca gözetilmelidir.

Fesihte tamamlanmış iş, yarım kod, müşteri verisi, hesaplar ve lisanslar için teslim protokolü gerekir. Haklı fesih yapan tarafın kaynak koda erişememesi projenin bütün değerini yok edebilir. Buna karşılık müşteri de kabul edilmiş aşamanın bedelini ve üçüncü taraf lisans giderlerini somut hesaba göre ödemek durumunda kalabilir.

İhtar, zamanaşımı ve dava şartı arabuluculuk

Ayıp veya gecikme fark edildiğinde sözleşmedeki bildirim yöntemi izlenmeli; hata, sürüm, tarih ve talep açıkça yazılmalıdır. Ticari ilişkilerde bazı ihbar ve ihtarların şekli özel önem taşır. Sessizce başka geliştiriciye geçip aylar sonra bütün gideri istemek, karşı tarafa düzeltme imkânı verilmediği savunmasına yol açabilir. Acil güvenlik açığında ise zararı büyütmemek için derhâl müdahale gerekebilir.

Zamanaşımı, sözleşmenin hukuki niteliğine ve talebe göre belirlenir. Eser sözleşmesindeki ayıp talepleri ile genel sözleşmeye aykırılık veya fikrî hak ihlali aynı süreye tabi olmayabilir. Başlangıç tarihi de teslim, kabul, ayıbın öğrenilmesi veya ihlalin devamı bakımından değişebilir. Bu nedenle tek bir genel süreye güvenilmemelidir.

Ticari nitelikteki para alacağı ve tazminat talepleri için dava öncesinde arabuluculuk kural olarak zorunludur. Kaynak kodun teslimi, ihlalin durdurulması veya hak sahipliğinin tespiti gibi talepler ayrıca değerlendirilir. Sürecin genel çerçevesi için ticari alacak davası ve arabuluculuk yazısı incelenebilir.

Görevli ve yetkili mahkeme

Tarafların ticari işletmesiyle ilgili proje uyuşmazlığı çoğunlukla asliye ticaret mahkemesinde görülür. Fikrî hak ihlali veya hak sahipliğine ilişkin taleplerde fikrî ve sınai haklar hukuk mahkemesinin görevi gündeme gelebilir. Aynı dosyada sözleşme alacağı ile telif talebi birleştiğinde görev, taleplerin hukuki dayanağına göre dikkatle kurulmalıdır.

Genel yetkinin yanında sözleşmenin ifa yeri ve tacirler arasında geçerli biçimde kurulan yetki şartı incelenir. Tahkim maddesi varsa kapsamının ücret, ayıp ve fikrî hak taleplerinin tamamını içerip içermediği kontrol edilir. Yurt dışı geliştiricide hukuk seçimi, delile erişim ve kararın tenfizi daha proje başında değerlendirilmelidir.

İspat yükü ve belge matrisi

Müşteri ayıplı veya eksik teslimi; geliştirici ise kapsam dışılık, kabul veya ödeme savunmasını somut kayıtlarla ortaya koymalıdır. Sürüm kontrol sistemi proje günlüğüdür; ancak tek başına işlevin çalıştığını kanıtlamaz. Test sonucu, dağıtım kaydı ve kullanıcı kabul tutanağıyla birlikte değerlendirilir.

Tedbir, delil tespiti ve kaynak kod emaneti

Geliştiricinin depoyu sileceği, erişimi kapatacağı veya sürüm geçmişinin kaybolacağına ilişkin somut risk varsa delil tespiti ve ihtiyati tedbir değerlendirilebilir. Tedbir talebi hangi depo, sürüm, hesap veya dosyanın korunacağını açıkça göstermelidir. Rakibin bütün sistemine erişim isteyen ölçüsüz talepler, ticari sırları gereksiz yere etkileyebilir.

Kaynak kod emaneti, projenin kritikliği yüksekse önleyici bir çözümdür. Kodun güvenilir üçüncü kişiye bırakılması tek başına yetmez; emanet sürümünün düzenli güncellenmesi, derlenebilirliğinin doğrulanması ve açılma koşullarının nesnel olması gerekir. Sağlayıcının iflası, uzun süreli destek kesintisi veya ağır ihlal tetikleyici olarak belirlenebilir. Gizli bilgiler için erişim protokolü kurulmalıdır.

Üç proje uyuşmazlığı senaryosu

Senaryo 1: Uygulama çalışıyor, kaynak kod verilmiyor

Müşteri son taksiti ödemiş, uygulama mağazada çalışmaktadır; geliştirici depoyu “şirket altyapısı” diyerek devretmez. Önce sözleşmedeki teslim paketi ile hak devri ayrılır. Kaynak kod, derleme belgeleri ve hesap devri açıkça vaat edilmişse aynen ifa talebi güçlenir. Yalnız kullanım lisansı kararlaştırılmışsa müşterinin bütün depo geçmişini istemesi aynı ölçüde mümkün olmayabilir. Silinme riski bulunuyorsa sürümün korunması için hızlı başvuru düşünülür.

Senaryo 2: Kabul süresi sessiz geçiyor

Geliştirici beta sürümü e-postayla iletir; müşteri yoğunluk nedeniyle yirmi gün test etmez. Sözleşmede on günlük zımni kabul vardır. Daha sonra ödeme akışını durduran kritik hata bulunur. Dosyada teslimin sözleşmeye uygun kanaldan yapılıp yapılmadığı, test hesabının çalışıp çalışmadığı, zımni kabul hükmünün gizli ayıba etkisi ve hatanın teslimde mevcut olup olmadığı incelenir. Sessizlik otomatik olarak her türlü gelecekteki ayıbı temizlemeyebilir.

Senaryo 3: Açık kaynak lisansı nedeniyle ürün dağıtılamıyor

Kurumsal müşteri, kapalı kaynak satmayı planladığı üründe geliştiricinin güçlü karşılıklılık koşulu taşıyan bir bileşen kullandığını öğrenir. Bileşen listesi sözleşmede istenmiş ancak verilmemiştir. Lisansın gerçekten hangi yükümlülüğü doğurduğu, kullanım ve dağıtım biçimi, alternatif bileşenin maliyeti ve geliştiricinin taahhüdü teknik-hukuki birlikte incelenir. Hızlıca kodu silmek yerine bağımlılık ve sürüm kanıtları korunur.

Yazılım geliştirme sözleşmesinde sık yapılan on hata

1. Kapsamı satış sunumuna bırakmak: Sunum, ölçülebilir kabul kriterinin yerini tutmaz.
2. Kabul testini öznel yazmak: Taraflardan biri sebepsiz reddeder, diğeri eksik ürünü tamamlanmış sayar.
3. Zımni kabulü sınırsız kurmak: Gizli ayıp ve güvenlik açığı için belirsizlik doğar.
4. Kaynak kod ile telif hakkını karıştırmak: Fiziksel teslim ve hukuki yetki ayrı ayrı düzenlenmelidir.
5. Mali hakları ayrı göstermemek: Genel bir “tüm haklar” cümlesi devir kapsamını tartışmalı bırakır.
6. Önceden var olan kütüphaneleri listelememek: Müşteri bağımlı, geliştirici de kullanım yasağı altında kalabilir.
7. Açık kaynak envanteri almamak: Lisans ve güvenlik yükümlülükleri teslimden sonra ortaya çıkar.
8. Sözlü ek iş yürütmek: Ücret, takvim ve kabul kapsamı sonradan kanıtlanamaz.
9. Bütün ödemeyi takvime bağlamak: İşlevsel teslim ile ücret arasındaki denge kaybolur.
10. Fesih teslim protokolü yazmamak: Yarım kod, bulut hesabı, veri ve anahtarlar ortada kalır.

Kanun yolu ve dosya stratejisi

İlk derece kararına karşı istinaf ve gerektiğinde temyiz, karar türü ile güncel parasal sınırlara göre belirlenir. Değişken tutarlar nedeniyle sözleşmeye veya bu yazıya sabit sınır yazmak güvenli değildir. İhtiyati tedbir kararlarına ilişkin itiraz ve kanun yolu, esas hükümden farklı süre ve usule tabi olabilir.

Dosya stratejisinin ilk adımı, tek bir “proje başarısız oldu” anlatısı yerine her kilometre taşını ayırmaktır. Hangi modül teslim edildi, hangisi reddedildi, hangi ödeme yapıldı, hangi hak devredildi ve hangi veri halen karşı tarafta tutuluyor soruları ayrı cevaplanmalıdır. Ticari sır riski bulunan kaynak kod ve müşteri listeleri için ticari sırların korunmasına ilişkin rehber de ilgili olabilir.

Çevrim içi ön inceleme için hazırlanacak paket

Türkiye’nin her yerinden yapılabilecek ön inceleme için imzalı sözleşme ve ekleri, teklif sürümleri, depo erişim özeti, test raporları, hata kayıtları, değişiklik talepleri, faturalar, ödeme dekontları, lisans envanteri ve fesih yazışmaları hazırlanmalıdır. İlk görüşmede kaynak kod gönderilmeden önce gizlilik ve erişim yöntemi belirlenebilir. İncelemenin amacı sonuca dair garanti vermek değil; teslim, ayıp, ücret ve fikrî hak taleplerini ispat durumuyla eşleştirmektir.

Yazılım geliştirme sözleşmesi hakkında sık sorulan sorular

1. Yazılım bedelini ödemek telif haklarını otomatik geçirir mi?

Her durumda hayır. Mali hak devrinin yazılılığı, ayrı ayrı gösterilmesi ve kapsamı incelenmelidir.

2. Kaynak kod teslim edilmediyse proje hiç teslim edilmemiş sayılır mı?

Sözleşmedeki teslim paketine bağlıdır. Kaynak kod açıkça vaat edilmişse eksik ifa olabilir; yalnız hizmet erişimi kararlaştırılmışsa sonuç farklılaşır.

3. E-postayla yapılan kabul geçerli midir?

Sözleşmedeki şekil şartı ve e-postayı gönderen kişinin yetkisi önemlidir. İçeriğin hangi sürümü kabul ettiği açık olmalıdır.

4. Zımni kabul gizli ayıp taleplerini bitirir mi?

Otomatik olarak değil. Hükmün kapsamı, ayıbın niteliği, öğrenme ve bildirim zamanı ayrıca değerlendirilir.

5. Geliştirici kendi genel kütüphanesini projede kullanabilir mi?

Önceden var olan bileşenler listelenip müşteriye gerekli kullanım ve değiştirme lisansı verilirse dengeli bir çözüm kurulabilir.

6. Açık kaynak yazılım kullanmak yasak mıdır?

Hayır. Ancak ilgili lisansın bildirim, dağıtım ve kaynak kod koşulları ürün modeline uygun olmalıdır.

7. Müşteri her yeni isteği ücretsiz yaptırabilir mi?

Hayır. Başlangıç kapsamı dışındaki istekler değişiklik talebiyle ücret ve takvime bağlanabilir; kapsam içi eksik ise ek iş sayılmayabilir.

8. Geciken proje hemen feshedilebilir mi?

Gecikmenin ağırlığı, sözleşmedeki takvim, ihtar ve ek süre hükümleri incelenir. Bazı ağır durumlarda ek süre beklenmeyebilir.

9. Yazılım uyuşmazlığında bilirkişi gerekir mi?

Teknik ayıp, kod kapsamı ve maliyet çoğu dosyada uzman incelemesi gerektirebilir. Bilirkişinin değerlendireceği ölçütün sözleşmede bulunması önemlidir.

10. Para alacağı için önce arabulucuya gidilir mi?

Ticari para alacağı ve tazminat talebinde kural olarak evet. Kaynak kod teslimi veya hak ihlalinin durdurulması ayrıca sınıflandırılır.

11. Kaynak kod emaneti geliştirici iflas edince otomatik açılır mı?

Ancak emanet sözleşmesindeki nesnel açılma şartı gerçekleşirse. Kodun güncel ve derlenebilir olması da düzenli doğrulanmalıdır.

Resmî kaynaklar

• 5846 sayılı Fikir ve Sanat Eserleri Kanunu
• 6098 sayılı Türk Borçlar Kanunu
• 6102 sayılı Türk Ticaret Kanunu
• 6100 sayılı Hukuk Muhakemeleri Kanunu
• 5070 sayılı Elektronik İmza Kanunu
• 6698 sayılı Kişisel Verilerin Korunması Kanunu

Son kontrol tarihi: 19 Eylül 2026

Yazar: Av. Emirhan Keskin

Bu metin genel bilgilendirme içindir. Projenin kapsamı, kodun üretim biçimi, kabul kayıtları ve taraf sıfatları görülmeden kesin hukuki sonuç çıkarılamaz; içerik sonuç garantisi oluşturmaz.