Yazılım Kaynak Kod Devir Sözleşmesi Nasıl Hazırlanır? 2026 Güncel Rehber

Kaynak kod, bir yazılımın kalbidir. Onu devretmek, sadece bir dosya klasörünü karşı tarafa göndermekten ibaret bir iş değildir; arkasında fikri mülkiyet devri, teknik teslim süreçleri, garanti rejimi ve çoğu zaman rekabet yasağı gibi pek çok hukuki katman bulunur. Mesleki pratikte sıklıkla karşılaştığımız bir durum şudur: Taraflar, yazılımın ekonomik değerini doğru tartışır ama Yazılım Kaynak Kod Devir Sözleşmesi'ni birkaç sayfalık bir "satış sözleşmesi" gibi hazırlar. Sonrasında kodun kısmen teslim edilmediği, üçüncü taraf kütüphane lisanslarının netleştirilmediği veya geliştiricinin başka bir projede aynı mimariyi kullandığı ortaya çıkar. İşte bu noktada iş mahkemeye taşınır.

Geçtiğimiz aylarda ofisimize gelen bir danışanın yaşadığı olay, konunun hassasiyetini iyi özetliyor: Bir SaaS ürününü satın alan şirket, devir bedelini ödedikten üç ay sonra kodun yaklaşık %20'sinin açık kaynak lisansıyla (GPL) kısıtlı kütüphaneler üzerine kurulu olduğunu fark etti. Sözleşmede "kod tamamen devredenin mülkiyetindedir" yazıyordu ama bu ifade, GPL yükümlülüklerini ortadan kaldırmaya yetmedi. 2026 itibarıyla hem yerli hem uluslararası uyum denetimleri sıkılaştığı için, bugün hazırlanacak her devir sözleşmesinin eski örneklerden çok daha titiz kurgulanması gerekiyor.

Yazılım Kaynak Kod Devir Sözleşmesi Nedir ve Hangi Hukuki Zemine Oturur?

Kaynak kod devri, özünde bir fikri hak devridir. 5846 sayılı Fikir ve Sanat Eserleri Kanunu'nun (FSEK) 2. maddesi, bilgisayar programlarını "ilim ve edebiyat eseri" kategorisinde koruma altına alır. Aynı kanunun 48. maddesi, eser sahibinin mali haklarını üçüncü kişilere devredebileceğini düzenler; 52. madde ise bu devrin yazılı şekilde ve devredilen hakların ayrı ayrı gösterilmesi suretiyle yapılmasını zorunlu kılar. Yani "kodu sana devrediyorum" demek tek başına yeterli değildir — işleme, çoğaltma, yayma, temsil ve umuma iletim gibi her bir mali hakkın açıkça sözleşmede sayılması gerekir.

Bunun yanında 6098 sayılı Türk Borçlar Kanunu'nun genel hükümleri, 6102 sayılı Türk Ticaret Kanunu'nun ticari iş niteliği ve 6698 sayılı KVKK (eğer kod içinde kişisel veri işleyen modüller varsa) devreye girer. Ticari işletme bünyesinde geliştirilen yazılımlarda TTK'nın 11. maddesi kapsamında "işletme devri" unsurları da tartışılabilir. Bu kadar çok kanunun kesiştiği bir alan, standart bir şablonla geçiştirilecek kadar basit değil.

Lisanslama ile Devir Arasındaki Kritik Fark

Danışanlarımızın en çok karıştırdığı konulardan biri de bu. Lisans verirseniz, siz hâlâ eser sahibisiniz; yalnızca kullanım izni verirsiniz. Devirde ise mali hakların mülkiyeti karşı tarafa geçer. FSEK 48/2 uyarınca manevi haklar devredilemez — yazılımı kimin yazdığı (eser sahipliği) sözleşmeyle değiştirilemez, yalnızca ekonomik kullanım hakları el değiştirir. Bu ayrımı sözleşmenin başında açıkça yapmamak, ileride ciddi yorum uyuşmazlıklarına yol açıyor.

2026 İtibarıyla Sözleşmede Mutlaka Bulunması Gereken Maddeler

Yılların getirdiği tecrübeyle söyleyebilirim: Her devir sözleşmesi farklıdır ama iskeleti değişmez. Aşağıdaki unsurlardan biri eksikse, sözleşme ya uygulamada takılır ya da uyuşmazlık halinde zayıf kalır.

• Tarafların kesin tanımı: Gerçek kişi geliştirici mi, şirket mi? Şirketse yetkili imza sirküleri ekli mi?
• Devir konusunun teknik kapsamı: Hangi repository, hangi branch, hangi commit hash, hangi dokümantasyon?
• Mali hakların tek tek sayımı: İşleme, çoğaltma, yayma, temsil, işaret-ses-görüntü nakline yarayan araçlarla umuma iletim.
• Üçüncü taraf bileşen beyanı: Açık kaynak lisansları, ticari kütüphaneler, API bağımlılıkları.
• Teslim yöntemi ve tutanağı: Git deposu mu, şifreli arşiv mi, fiziksel ortam mı?
• Garanti süresi ve kapsamı: Gizli ayıba karşı sorumluluk süresi.
• Rekabet ve gizlilik yükümlülükleri: Geliştiricinin benzer ürünü ne kadar süre yapamayacağı.
• Bedel, ödeme planı ve vergisel yaklaşım: Stopaj, KDV, fatura kesme yükümlülüğü.
• Uyuşmazlık çözümü: Yetkili mahkeme veya tahkim şartı.

Teknik Teslim Tutanağının Gücü

Sözleşmeye ek olarak hazırlanacak bir "Teknik Teslim Tutanağı", ileride çıkacak "eksik teslim" iddialarının önünü büyük ölçüde keser. Tutanakta teslim edilen dosyaların SHA-256 hash değerleri, repository URL'si, erişim kimlik bilgilerinin aktarıldığı tarih ve derleme (build) ortamının başarıyla ayağa kaldırıldığına dair teyit yer almalı. Yargıtay 11. Hukuk Dairesi'nin 2024 tarihli bir kararında, teslim tutanağı olmayan bir devirde ispat yükü devralan aleyhine değerlendirilmiş ve bedel iadesi talebi reddedilmiştir. Bu yüzden tutanak, "formalite" değil hukuki bir kalkandır.

Eğer hâlâ kendi şablonunuzu sıfırdan hazırlamayı düşünüyorsanız, hukuka uygun ve 2026 mevzuatına güncellenmiş hazır bir iskelet üzerinden ilerlemek size hem zaman hem de risk anlamında büyük avantaj sağlar. Platformumuzda yer alan Yazılım Kaynak Kod Devir Sözleşmesi şablonu, yukarıda saydığımız tüm zorunlu unsurları içerir ve her maddeyi kendi projenize göre özelleştirebilirsiniz.

Devir Bedeli, Vergi ve Harç Yükümlülükleri

Kaynak kod devrinden elde edilen gelirin vergilendirilmesi, tarafların statüsüne göre değişir. Gerçek kişi bir geliştirici kodunu devrediyorsa, 193 sayılı Gelir Vergisi Kanunu'nun 18. maddesi kapsamında serbest meslek kazancı istisnasından yararlanıp yararlanamayacağı değerlendirilmelidir. Şirketten şirkete devirde ise gelir, ticari kazanç olarak Kurumlar Vergisi'ne tabidir ve KDV Kanunu'nun 1. maddesi gereği %20 KDV uygulanır. Damga vergisi açısından 488 sayılı Damga Vergisi Kanunu'nun bağlı (I) sayılı tablosu uyarınca 2026 yılı oranı binde 9,48'dir.

Kalem	2026 Oranı / Tutarı	Dayanak
KDV	%20	3065 sayılı KDV Kanunu m.1
Damga Vergisi	Binde 9,48 (sözleşme bedeli üzerinden)	488 sayılı Kanun (I) sayılı tablo
Stopaj (GVK 18 kapsamında)	%17 (telif kazançlarında)	193 sayılı GVK m.94
Kurumlar Vergisi (şirket ise)	%25	5520 sayılı KVK m.32
FSEK kapsamında devir şekli	Yazılı, haklar tek tek sayılarak	5846 sayılı FSEK m.52
Gizli ayıptan sorumluluk	2 yıl (aksi kararlaştırılmadıkça)	6098 sayılı TBK m.231

Uygulamada gördüğümüz yaygın bir hata, damga vergisinin unutulmasıdır. Sözleşme üzerindeki bedel yüksekse damga vergisi de ciddi bir rakama ulaşabilir; 488 sayılı Kanun'un 14. maddesi gereği 2026 yılı için azami damga vergisi tutarı her yıl Hazine ve Maliye Bakanlığı tarafından yeniden değerleme oranında güncellenmekte olup güncel tutar için gelir idaresi başkanlığının resmi sitesinden (gib.gov.tr) kontrol etmenizi öneririm.

Kaynak Kod Devrinde Dikkat Edilmesi Gereken Riskler

Kodun "temiz" olup olmadığı meselesi, işin belki de en hassas noktası. Son dönemde artan başvurularda gördüğümüz üzere, devralan taraf çoğu zaman kodun lisans uyumunu yeterince sorgulamadan imzayı atıyor. Oysa ki bir tek GPL lisanslı kütüphane, tüm kapalı kaynak ürününüzü açık kaynak yapmaya zorlayabilir.

Açık Kaynak Kütüphane Denetimi

Devir öncesinde mutlaka bir SBOM (Software Bill of Materials) çıkarılması gerekir. Bu belge, projede kullanılan tüm üçüncü taraf bileşenleri ve lisanslarını listeler. MIT, Apache 2.0 gibi izin verici lisanslarda sorun çıkmaz; ancak GPL, AGPL, LGPL gibi copyleft lisanslar özel incelemeyi gerektirir. Bu konuda sözleşme analiz aracımız, yüklediğiniz sözleşmedeki lisans risklerini otomatik tarayarak size yapay zekâ destekli bir risk raporu sunar.

Eser Sahipliği Zinciri

Kodu yazanın sadece bir kişi olduğu çok nadir bir durumdur. Şirket bünyesinde yazılmış kodlarda 5846 sayılı FSEK'in 18. maddesi uyarınca eser sahipliği, işveren-işçi ilişkisinin niteliğine göre değerlendirilir. Eğer yazılım bir çalışan tarafından iş sözleşmesi kapsamında üretildiyse mali haklar kural olarak işverene ait olur; ama freelance bir geliştirici söz konusuysa ayrı bir hak devri sözleşmesi aranır. Devralan taraf, "eser sahipliği zincirinin" bozulmadığını mutlaka kontrol etmelidir. Ankara Bölge Adliye Mahkemesi 20. Hukuk Dairesi'nin 2025 tarihli bir kararında, şirketin eski bir freelance geliştiriciden gerekli hak devrini almadan üçüncü tarafa yaptığı devir geçersiz sayılmış ve tazminata hükmedilmiştir.

Kaynak Kod Emanet Mekanizması (Escrow)

Büyük bütçeli devirlerde taraflar çoğu zaman bedelin tamamının peşin ödenmesini istemez, satıcı da tüm kodu önceden teslim etmek istemez. Bu ikilemi çözmek için kod emanet (source code escrow) mekanizması kullanılır. Güvenilir bir üçüncü taraf (genellikle noter veya yetkili bir teknoloji saklama kuruluşu), kodu geçici olarak muhafaza eder; ödeme tamamlandığında emanetçi kodu devralana teslim eder. 1512 sayılı Noterlik Kanunu'nun 60. maddesi kapsamında noterlerin bu tür elektronik belge saklama hizmetlerini sunma yetkisi bulunmaktadır.

Sözleşmeyi İmzalamadan Önce Son Kontrol Listesi

İmza aşamasına gelmeden önce mutlaka şu kontrolleri yapın:

1. Devredilen mali hakların FSEK 21-25 kapsamında tek tek sayıldığından emin olun.
2. Repository tam URL'si, son commit hash'i ve branch adı sözleşmeye veya ekine işlenmiş olmalı.
3. Üçüncü taraf lisans listesi (SBOM) ek olarak sözleşmeye iliştirilmeli.
4. Geliştiricinin rekabet etmeme süresi makul (genellikle 1-2 yıl) ve coğrafi sınırlı olmalı; TBK 445. madde sınırlarını aşmamalı.
5. Gizli ayıp bildirim süresi açıkça belirlenmeli (TBK m.223 uyarınca ayıp derhal bildirilmelidir).
6. KVKK uyumu için varsa kişisel veri işleyen modüllerde veri sorumlusu değişikliği prosedürü tanımlanmalı.
7. Damga vergisinin kimin tarafından ödeneceği belirtilmeli.
8. Teslim sonrası destek/bakım süresi ve kapsamı netleştirilmeli.

Bu listeyi tamamladıktan sonra sözleşmeyi son kez bir hukuk profesyoneline gözden geçirtmenizi öneririm. Kendi kendine hazırlanan sözleşmelerin uyuşmazlık aşamasında yarattığı maliyetler, baştan alınacak danışmanlık ücretinin katbekat üstünde olabiliyor. Platformumuzun fiyatlandırma sayfamız üzerinden uygun pakedi seçerek sözleşmenizi hem hazırlayıp hem de analiz ettirebilirsiniz. Benzer nitelikte diğer içerikler için blog yazılarımız bölümünü takip etmenizi tavsiye ederim.