Yazılım Sözleşmesinde Kod Sahipliği ve Fikri Haklar

Yazılım sözleşmesinde kod sahipliği, para ödemekle değil yazılı devir maddesiyle geçer. 5846 sayılı FSEK'e göre bir programın eser sahibi kaynak kodu yazan kişidir; mali hakların devri yazılı olmak ve devredilen haklar ayrı ayrı gösterilmek zorundadır.

Bu cümle kulağa teknik geliyor ama faturası çok somut. Kurumsal bir web yazılımı için altı ay çalışıyorsunuz, bedeli ödüyorsunuz, sistem canlıya çıkıyor. İki yıl sonra ajansla yolunuzu ayırmak istediğinizde karşınıza iki soru geliyor: kodu başka bir ekibe verip geliştirtebilir misiniz, aynı yazılımı başka bir şirkete satabilir misiniz? Cevap teknik ekipte değil, imzaladığınız sözleşmenin fikri haklar maddesinde yazıyor.

Türk hukukunda "ücreti ödeyen sahibidir" diye bir kural yok. Kültür ve Turizm Bakanlığı Telif Hakları Genel Müdürlüğü bunu kendi resmî sorularında açıkça söylüyor: bir programı sözleşmeyle, ücreti karşılığında yaptırdıysanız eser sahibi değil hak sahibi olursunuz ve program üzerindeki mali haklar "sözleşme çerçevesinde" kullanılır (Telif Hakları Genel Müdürlüğü SSS). Yani hakkınızın sınırını kanun değil, sözleşmenizin yazdığı kadarı belirliyor.

İyi bir yazılım sözleşmesi bu sınırı genişletmez, sadece net çizer. Kötü bir yazılım sözleşmesi ise sınırı hiç çizmez ve tarafların sonradan hatırladıklarına bırakır.

Bu rehber, kurumsal web yazılımı ve özel yazılım projeleri için kod sahipliğini imza atacak işletme sahibinin gözünden anlatıyor: eser sahibi kim, hangi hak neyi veriyor, devir maddesi nasıl yazılır, açık kaynak kütüphaneler tabloyu nasıl değiştirir ve teslimde tam olarak neyi istemeniz gerekir. Mobil uygulamaya özgü senaryolar için ayrı bir rehberimiz var.

İçindekiler

• Kod Sahipliği Neden Ödemeyle Geçmez?
• Yazılımın Eser Sahibi Kim? FSEK Ne Diyor
• Mali Hak, Manevi Hak ve Lisans Arasındaki Fark
• Devir Maddesi Nasıl Yazılır? FSEK m.52 Şartı
• Henüz Yazılmamış Kodun Devri Neden Batıl?
• Yazılım Sözleşmesinde Olması Gereken 9 Madde
• Açık Kaynak Lisanslar Kod Sahipliğinizi Sınırlar
• Teslim Paketi: Repo, Dokümantasyon ve Erişimler
• Kayıt-Tescil Koruma Sağlar mı?
• Tazminat ve Üç Kat Bedel Talebi
• Sıkça Sorulan Sorular

Kod Sahipliği Neden Ödemeyle Geçmez?

Çoğu işletme, yazılım satın almayı masa satın almaya benzetir: bedelini ödediniz, eşya sizin. Fikri mülkiyette mantık tersine çalışır. Ortada bir eser vardır ve eser üzerindeki haklar, nüshanın mülkiyetinden bağımsız doğar.

FSEK'in 57. maddesi bunu tek cümleyle kuruyor: asıl veya çoğaltılmış nüshalar üzerindeki mülkiyet hakkının devri, aksi kararlaştırılmadıkça fikri hakların devrini içermez (FSEK). Sunucunuzda çalışan kod, elinizdeki ZIP dosyası, erişiminiz olan repo — hiçbiri tek başına hak sahipliği kanıtı değil.

İkinci yanılgı, ödemenin devir yerine geçtiği varsayımıdır. Mali hakların devri ayrı bir hukuki işlemdir ve şekil şartına bağlıdır. Bedeli ödemiş olmanız, geliştiricinin bu işlemi yapmış olduğunu göstermez.

Pratikte bu iki yanılgı üç yerde patlar: ajans değiştirirken, şirketi satarken ya da yazılımı ürünleştirip başkalarına satmaya karar verdiğinizde. Üçünde de karşı taraf aynı soruyu sorar — devir maddesini gösterin.

Bir yazılım sözleşmesinin hukuki niteliği genelde eser sözleşmesidir: yüklenici belirli bir sonucu teslim etmeyi taahhüt eder. Ancak eser sözleşmesi teslimi düzenler, hak sahipliğini düzenlemez. Kod üzerindeki haklar FSEK rejimine tabidir ve ayrı bir maddeyle ele alınmaları gerekir.

Bu ayrımı görmek, sözleşme okurken işinizi kolaylaştırır. Kapsam, takvim, kabul kriterleri ve ödeme planı eser sözleşmesinin gövdesidir. Fikri haklar maddesi ise bambaşka bir konuyu, kodun kime ait olacağını düzenler. İkisini aynı paragrafta geçiştiren bir yazılım sözleşmesi, genelde ikincisini eksik bırakır.

Yazılımın Eser Sahibi Kim? FSEK Ne Diyor

FSEK'in 2. maddesi bilgisayar programlarını, "bir sonraki aşamada program sonucu doğurması koşuluyla" hazırlık tasarımlarıyla birlikte ilim ve edebiyat eseri sayar. Koruma tescille değil, eserin yaratılmasıyla kendiliğinden doğar.

Aynı maddenin son fıkrası önemli bir sınır çizer: bir bilgisayar programının herhangi bir ögesine temel oluşturan düşünce ve ilkeler, arayüzün temelindeki fikirler de dahil, eser sayılmaz. Yani projenin fikri sizden çıkmış olsa bile korunan şey fikir değil, o fikri hayata geçiren koddur.

Peki o kodun sahibi kim? Telif Hakları Genel Müdürlüğü'nün cevabı net: "Bilgisayar programının ve/veya veritabanının eser sahibi, onun kaynak kodlarını yazan kişi ya da kişilerdir." Eser sahibi her zaman gerçek kişidir; şirket, ancak kendi bünyesinde iş akdiyle çalışan kişiler programı iş saatleri içinde üretmişse eser sahibi sıfatıyla hareket edebilir.

Buradan çıkan sonuç, sözleşme yazarken en çok işe yarayan bilgidir. FSEK'in 18. maddesine göre aralarındaki özel sözleşmeden veya işin mahiyetinden aksi anlaşılmadıkça, işçilerin işlerini görürken meydana getirdikleri eserler üzerindeki hakları onları çalıştıranlar kullanır. Ajansın kadrolu geliştiricisi için zincir böyle kurulur.

Zincirin kırıldığı yer freelance ve alt yüklenici kullanımıdır. Projenin bir modülünü dışarıdan bir geliştirici yazdıysa, o kişi işçi değildir ve hakları kendiliğinden ajansa geçmez. Ajans sizin sözleşmenizde devir taahhüdü verirken aslında elinde olmayan bir hakkı devrediyor olabilir.

Bu yüzden yazılım sözleşmesine tek satır eklemek işinizi kurtarır: yüklenici, projede çalışan tüm gerçek kişilerle ve alt yüklenicilerle gerekli yazılı devir sözleşmelerini yaptığını beyan ve tekeffül eder. FSEK 53 ve 54. maddeler, hakkın mevcut olmaması ve devir yetkisinin bulunmaması hallerinde devredenin sorumluluğunu düzenler — ama bu sorumluluğu işletebilmek için beyanı sözleşmeye yazmış olmanız gerekir.

Küçük ekiplerle çalışırken bu zinciri sormak garip gelebilir. Oysa soru teknik değil, idari: "projede kimler kod yazacak ve onlarla aranızdaki hak devri nasıl kurulu?" Cevabı yazıya geçen bir yazılım sözleşmesi, ekip üyesi ayrıldığında da geçerliliğini korur.

Mali Hak, Manevi Hak ve Lisans Arasındaki Fark

Kod sahipliği tartışmalarının yarısı terim karışıklığından çıkar. "Haklar bize geçecek" cümlesi, aşağıdaki dört satırdan hangisini kastettiğinizi söylemediği sürece hiçbir şey ifade etmez.

Dört satırı birlikte okuduğunuzda yazılım sözleşmesinde ne aradığınız netleşir: mali hakların tek tek sayıldığı bir devir, manevi hakların kullanımına ilişkin düzenleme ve nüsha teslimiyle devrin karıştırılmadığı bir metin.

Tablodaki en pahalı satır üçüncüsü. Sözleşmenizde "kullanım hakkı verilir" yazıyorsa ve türü belirtilmemişse, kanun bunu basit ruhsat kabul eder. Aynı altyapıyı yarın rakibinize kurmasının önünde hukuki bir engel kalmaz.

İkinci sırada 55. madde gelir: aksi kararlaştırılmadıkça mali bir hakkın devri veya bir ruhsatın verilmesi, eserin tercüme veya sair işlenmelerine şamil değildir. İşleme hakkını ayrıca saymazsanız, kodu başka bir ekibe güncelletme yetkiniz tartışmaya açılır. Yazılımda "işleme" demek, yeni modül yazmak, refactor etmek, sürüm yükseltmek demektir.

Üçüncüsü 49. madde: bir mali hakkı veya ruhsatı devralan kişi, bunu ancak eser sahibinin yazılı muvafakatiyle başkasına devredebilir. İşleme hakkının devrinde de aynı muvafakat aranır. Şirket satışı veya grup içi devir planınız varsa, bu yetkiyi baştan almanız gerekir.

Devir Maddesi Nasıl Yazılır? FSEK m.52 Şartı

FSEK'in 52. maddesi iki şart koyar: mali haklara dair sözleşme ve tasarrufların yazılı olması ve konuları olan hakların ayrı ayrı gösterilmesi. İkinci şart, uygulamada en çok atlanan yerdir.

"Tüm fikri ve sınai mülkiyet hakları devredilmiştir" gibi toplu bir cümle, hakları ayrı ayrı göstermediği için tartışmaya açıktır. Devir maddesi, yazılım için anlamlı olan mali hakları tek tek saymalıdır: işleme, çoğaltma, yayma, temsil ve işaret-ses-görüntü nakline yarayan araçlarla umuma iletim.

Yanına üç ayar daha koyun: devir süresizdir, yer bakımından sınırsızdır ve münhasırdır. Üçünü yazmazsanız karşı taraf süreli ya da bölgesel bir devir iddia edebilir.

Bir de sözleşmede bulunması gereken küçük ama kritik bir nokta var: alt devir ve işleme hakkının üçüncü kişilere aktarılması yetkisi. Bunu 49. madde nedeniyle açıkça yazmanız gerekir.

Devrin bedelle ilişkisini de kurun. Çoğu yazılım sözleşmesi devri kayıtsız şartsız yazar; daha dengeli kurgu, her fazın bedeli ödendikçe o faza ait hakların geçmesidir. Bu, iki tarafın da işine gelen bir fren mekanizmasıdır ve ödeme uyuşmazlığında kodun rehin tutulmasını önler.

Son olarak uygulanacak hukuk ve yetkili mahkemeyi atlamayın. Yurt dışındaki bir ekiple çalışıyorsanız, FSEK'in yazılılık ve ayrı ayrı gösterme şartları sözleşmeye uygulanacak hukuka göre değişebilir. Türkiye'de icra edilecek bir devir için Türk hukukunu seçmek en öngörülebilir yoldur.

Henüz Yazılmamış Kodun Devri Neden Batıl?

Burada çoğu sözleşme örneğinin gözden kaçırdığı bir ayrım var. FSEK'in 48. maddesinin son fıkrası, henüz vücuda getirilmemiş veya tamamlanacak olan bir esere ilişkin tasarruf muamelelerini batıl sayar. Yani proje başlamadan imzalanan bir "haklar şimdiden devredilmiştir" cümlesi, tek başına devri gerçekleştirmez.

Kanun bu kapıyı 50. maddeyle açık bırakır: 48 ve 49. maddelerde sayılan tasarruf muamelelerine dair taahhütler, eser henüz vücuda getirilmemiş olsa dahi muteberdir. Fark incedir ama sonucu değiştirir — baştaki metin bir taahhüttür, devrin kendisi sonra yapılır.

Pratik çözüm iki aşamalıdır. Yazılım sözleşmesinin fikri haklar maddesi devir taahhüdünü ve bedelini kurar; her teslim veya faz kabulünde ise ayrı bir devir beyanı imzalanır. Beyan, teslim edilen sürümü, repo adresini ve commit referansını isimle sayar.

Bu ikinci kâğıt, ajans değiştirme senaryosunda elinizdeki en güçlü belgedir. Üç satırlık bir metni teslim tutanağının altına eklemek, sonradan açılacak bir davadan ucuzdur.

Beyanın içeriği de sade kalabilir. Hangi sürümün teslim edildiği, hangi repo ve commit'in esas alındığı, hangi mali hakların devredildiği ve devrin bedelle ilişkisi — dört satır yeter. Tarafların kaşesi ve imzası altına geldiğinde, bu metin sözleşmedeki taahhüdü fiilen tamamlayan tasarruf işlemine dönüşür.

Fazlı projelerde her kabul toplantısının gündemine bu imzayı da ekleyin. Altı ayda bir hatırlanan bir devir beyanı, proje sonunda toplu imzalanacak bir belgeden daha güvenilir bir kayıt bırakır ve ekip değişikliklerinde boşluk oluşmasını engeller.

Yazılım Sözleşmesinde Olması Gereken 9 Madde

Aşağıdaki tablo, kurumsal yazılım projelerinde kod sahipliğini gerçekten güvenceye alan maddeleri ve atlandığında ne olduğunu gösteriyor.

Beşinci satır, iyi niyetli ajanslarla bile en sık tartışılan maddedir. Hiçbir ekip her projeye sıfırdan başlamaz; kendi yetkilendirme modülünü, form kütüphanesini, dağıtım şablonunu getirir. Bunların devrini istemek genelde gerçekçi değildir — ama süresiz ve devredilebilir bir kullanım lisansı istemek gerçekçidir.

Altıncı satırı yazarken somut olun. "Üçüncü taraf bileşen kullanılmamıştır" gibi bir cümle gerçekçi değildir ve ilk denetimde çürür. Bunun yerine listelenmiş bileşenler, lisansları ve kullanım amacınıza uygunluk tekeffülü isteyin.

Dokuzuncu satır ise projenin ortasında ayrılma senaryosunu çözer. Fesih maddesine "o tarihe kadar üretilmiş ve bedeli ödenmiş kod, 15 gün içinde devredilir" cümlesini eklemek, çıkışı pazarlık konusu olmaktan çıkarır. Firma seçerken bu maddeye nasıl yaklaştıklarını sormak da iyi bir filtredir; yazılım firması seçiminde kullanılacak kriterleri ayrı bir yazıda topladık.

Açık Kaynak Lisanslar Kod Sahipliğinizi Sınırlar

Sözleşmede her şey tam yazılmış olsa bile, devredilen kodun tamamı geliştiricinin yazdığı kod değildir. Modern bir web yazılımının büyük bölümü hazır açık kaynak bileşenlerden gelir ve o bileşenler kendi lisanslarıyla gelir.

Black Duck'ın 2026 OSSRA raporu, Kasım 2024-Ekim 2025 arasında denetlenen 947 kod tabanını inceledi. Sonuçlar iki noktada çarpıcı: kod tabanlarının yalnızca %2'si hiç açık kaynak bileşen içermiyordu ve %68'inde lisans çatışması bulundu — bir önceki yıl bu oran %56'ydı (OSSRA 2026). Tek bir kod tabanında 2.675 ayrı lisans çatışması tespit edilmişti.

Rapordaki iki ayrıntı, sözleşme yazarken işinize yarar. Bileşenlerin %17'si paket yöneticisi dışından geliyor, yani klasik manifest taramasıyla görünmüyor. Ve kuruluşların yalnızca %54'ü yapay zekayla üretilmiş kodu fikri mülkiyet riski açısından değerlendiriyor.

Riskin kendisi lisans türünde. MIT, BSD ve Apache 2.0 gibi izin veren lisanslar ticari kullanımda rahat çalışır. GPL gibi copyleft lisanslar ise türev eseri dağıtırken aynı lisansla yayımlama yükümlülüğü doğurur (GNU copyleft açıklaması). Yazılımınızı müşterilerinize dağıtıyorsanız veya ürünleştirmeyi planlıyorsanız, tek bir copyleft bağımlılık ticari modelinizi kısıtlayabilir.

Kendi kullanımınız için çalıştırdığınız bir kurumsal yazılımda copyleft riski düşüktür, çünkü yükümlülüğün çoğu dağıtımla doğar. Riski büyüten senaryo, aynı yazılımı başka şirketlere kurmaya ya da lisanslamaya karar vermenizdir. Bu planı yazılım sözleşmesinin kapsam maddesine baştan yazmak, bileşen seçimini de etkiler.

İstemeniz gereken şey basit: teslimle birlikte bileşen listesi (SBOM), her bileşenin lisansı ve yüklenicinin "bu lisanslar müşterinin bildirdiği kullanım amacına uygundur" tekeffülü. Yapay zekayla üretilen kod için de ayrı bir beyan isteyin, çünkü insan katkısı olmayan çıktının telif korumasından yararlanıp yararlanmadığı dünya genelinde hâlâ tartışmalı.

Teslim Paketi: Repo, Dokümantasyon ve Erişimler

Hukuki devir, teknik devir olmadan işe yaramaz. Elinizde hakların tamamı olsa bile kodu derleyip canlıya çıkaramıyorsanız, pratikte hâlâ ajansa bağlısınız.

Teslim paketini sözleşmeye şu başlıklarla yazın:

• Repo sahipliği: Depo, ilk günden sizin şirket hesabınızdaki organizasyonda açılır. Ajans ekibi katkıcı olarak eklenir, sahip olarak değil.
• Hesaplar: Alan adı, DNS, hosting, bulut, mağaza ve ödeme sağlayıcı hesapları sizin kurumsal kimliğinizle açılır.
• Build ve deploy talimatı: Sıfır bilgiyle sistemi ayağa kaldıracak adımlar, ortam değişkeni listesi, çalışma zamanı sürümleri.
• Mimari ve veri dokümanı: Modül şeması, veritabanı modeli, entegrasyon haritası, API dokümantasyonu.
• Gizli bilgi yönetimi: Anahtar ve token'ların nerede tutulduğu, teslimde nasıl rotasyona sokulacağı.
• Devir beyanı: Teslim edilen sürümü ve commit referansını içeren imzalı belge.

Bu listedeki ilk maddeyi ciddiye alın. Repo'nun ajansın hesabında açılması, sözleşmedeki devir maddesi ne kadar iyi yazılmış olsa da devri fiilen geciktirir. Kendi organizasyonunuzda açılan bir depoda devir, yetki ayarından ibarettir.

Kritik iş süreçleri tek bir yazılıma bağlıysa bir adım daha atabilirsiniz: kaynak kod emaneti. Kod, bağımsız bir üçüncü tarafta şifreli saklanır ve yalnızca sözleşmede yazan şartlar gerçekleştiğinde size açılır. Türkiye'de bu hizmeti veren kurumsal yapılar mevcuttur. Emanet, devir maddesinin yerine geçmez; onu tamamlar.

Emanet sözleşmesinde iki ayrıntı belirleyicidir: hangi olayların kodu serbest bırakacağı ve deponun gerçekten derlenip derlendiğinin kontrol edilip edilmeyeceği. "Firma faaliyetini durdurursa" gibi muğlak bir tetikleyici, ihtiyaç anında tartışma çıkarır.

Teslimden sonrasını düzenleyen ayrı bir belge daha gerekir. Hakların devri bakım yükümlülüğü yaratmaz; destek, yanıt süreleri ve ücretler için yazılım bakım sözleşmesi gerekir. Mobil tarafta kodun fiilen teslim edilmediği senaryoları ise kaynak kod teslimi rehberimizde örneklerle anlattık.

Kayıt-Tescil Koruma Sağlar mı?

Kısa cevap: hayır, koruma zaten doğmuştur; tescil ispatı kolaylaştırır. FSEK kapsamında koruma eserin yaratılmasıyla kendiliğinden başlar, tescil şartına bağlı değildir.

Telif Hakları Genel Müdürlüğü'nün isteğe bağlı kayıt-tescil işlemi, kendi ifadesiyle "korumaya yönelik olmayıp, sadece meydana gelen eserin eser sahibini belirlemeye kolaylık sağlayan beyana dayalı" bir işlemdir. Beyana dayalı olması önemli: kurum kodu incelemez, hak sahipliğini onaylamaz. Yani tescil belgesi, mahkemede tek başına hak sahipliği kanıtı olarak değerlendirilmez; yalnızca beyanın tarihini ve içeriğini kayda geçirir.

Başvuruyu kimin yapabileceği de sınırlıdır. Yalnız eser sahipleri başvurabilir; bir programı sözleşmeyle ücreti karşılığında yaptırdıysanız hak sahibi sayıldığınız için isteğe bağlı kayıt-tescil başvurusu yapamazsınız. Genel Müdürlük bunun hak kaybı olmadığını, mali hakların sözleşme çerçevesinde kullanılacağını ayrıca belirtiyor.

Tüzel kişi başvurusu için tek yol, programı kendi iş akdiyle çalıştırdığı kişilerin iş saatleri içinde üretmiş olmasıdır. İşlem ücreti bu yazının hazırlandığı tarihte 1.970 TL (Kayıt-Tescil Başvuru Ücreti).

Buna rağmen tescil belgesi işe yarar bir yan etki üretir: tarih damgası. Bir yazılım sözleşmesi uyuşmazlığında "bu kod şu tarihte bu kişiler tarafından yazıldı" beyanının kayda geçmiş olması, delil tartışmasını kısaltır. Kurum kodu onaylamasa da başvuru tarihini onaylar.

Pratik sonuç şu: tescili kendi geliştirici ekibiniz olan şirketler için düşünün. Dışarıdan yaptırdığınız projede enerjinizi tescile değil, sözleşmedeki devir maddesine ve teslim belgelerine harcayın.

Tazminat ve Üç Kat Bedel Talebi

Hak sahibi olduğunuzu yazılı olarak kurduysanız, ihlal halinde elinizde güçlü bir araç var. FSEK'in 68. maddesi, eseri hak sahiplerinden yazılı izin almadan işleyen, çoğaltan, yayan veya umuma iletenlerden sözleşme yapılmış olması halinde istenebilecek bedelin ya da rayiç bedelin en çok üç kat fazlasının talep edilebileceğini söyler.

Bu maddenin işlemesi için iki belgeye ihtiyaç duyarsınız: hak sahipliğinizi kuran yazılım sözleşmesi ve devrin yapıldığını gösteren teslim beyanı. İkisi yoksa tartışma, bedelin üç katından çok daha temel bir noktaya, hak sahibi olup olmadığınıza kayar.

Bu madde iki yöne de çalışır. Ajansınızın size devrettiği kodda izinsiz kullanılmış üçüncü taraf bileşen varsa, talep size yönelir. Sözleşmedeki açık kaynak beyanı ve tekeffül hükmü tam bu yüzden önemlidir.

Kullanıcı açısından iyi haber, 38. maddenin kesin hükmüdür: bilgisayar programını yasal yollardan edinen kişinin programı yüklemesi, çalıştırması ve hataları düzeltmesi sözleşmeyle önlenemez. Kullanım için gerekli olduğu sürece bir adet yedekleme kopyası yapma hakkı da sözleşmeyle kaldırılamaz. Yani en kötü senaryoda bile sistemi çalıştırma ve basit hata düzeltme alanınız kanunla korunur — ama yeni modül yazdırmak bu kapsamda değildir.

Son bir uyarı: bu yazı genel bilgilendirme amaçlıdır, hukuki görüş değildir. Madde numaraları ve alıntılar birincil kaynaklardan alınmıştır; somut bir sözleşme veya uyuşmazlık için fikri mülkiyet alanında çalışan bir avukatla görüşün. Fikri mülkiyet maddelerini şablondan kopyalamak, projenin en pahalı tasarrufudur.

Sıkça Sorulan Sorular

Ödemeyi yaptım, kod otomatik olarak benim olmaz mı?

Hayır. Türk hukukunda bedeli ödemek mali hakların devrini sağlamaz. Devir için FSEK m.52 uyarınca yazılı bir sözleşme gerekir ve devredilen hakların ayrı ayrı gösterilmesi şarttır. Ödeme yalnızca eseri sözleşme amacıyla kullanma yetkisi verir.

Yazılım sözleşmesinde hangi haklar tek tek sayılmalı?

İşleme, çoğaltma, yayma, temsil ve işaret-ses-görüntü nakline yarayan araçlarla umuma iletim hakları ayrı ayrı yazılmalıdır. Devrin süresiz, yer bakımından sınırsız ve münhasır olduğunu da belirtin. İşleme hakkını atlarsanız kodu başka bir ekibe güncelletme yetkiniz tartışmaya açılır.

Ajans kendi hazır kütüphanesini kullandıysa ne olur?

O kütüphane ajansın arka plan fikri mülkiyetidir ve devri genelde gerçekçi değildir. Çözüm, sözleşmede bu bileşenler için süresiz, devredilebilir, bedelsiz ve alt lisans verilebilir bir kullanım lisansı almaktır. Ayrıca hangi modüllerin bu kapsamda olduğunu listelettirin.

Açık kaynak kütüphane kullanılması kod sahipliğimi bozar mı?

Projeye özgü kodun hakları sizde kalır, ancak açık kaynak bileşenler kendi lisanslarına tabi olmaya devam eder. Risk, GPL gibi copyleft lisanslarda dağıtım yükümlülüğü doğmasıdır. Teslimde bileşen listesi, lisans dökümü ve kullanım amacınıza uygunluk tekeffülü isteyin.

Yazdırdığım yazılımı kendi adıma tescil ettirebilir miyim?

Hayır. Telif Hakları Genel Müdürlüğü'ne isteğe bağlı kayıt-tescil başvurusunu yalnızca eser sahipleri, yani kaynak kodu yazan kişiler yapabilir. Sözleşmeyle ücreti karşılığında yaptırdığınız programda siz hak sahibisiniz. Bu durum hak kaybı değildir; haklarınız sözleşme çerçevesinde kullanılır.

Sözleşmede devir maddesi yoksa ne yapabilirim?

Geriye dönük bir devir sözleşmesi imzalamayı deneyebilirsiniz; eser meydana geldikten sonra yapılan yazılı devir geçerlidir. Pazarlık gücünüz varsa bunu bakım sözleşmesi yenilemesine bağlayın. Bu arada yasal olarak edinilmiş programı çalıştırma, hata düzeltme ve yedek alma haklarınız FSEK m.38 uyarınca sözleşmeyle engellenemez.

Yapay zekayla üretilen kodun sahibi kim?

İnsan katkısı olmadan üretilen çıktının telif korumasından yararlanıp yararlanmayacağı tartışmalıdır; korunan kısım genelde insanın yarattığı bölümlerdir. Bu yüzden sözleşmeye yapay zeka kullanımının beyanını ve üretilen kodun lisans kaynağına ilişkin tekeffülü ekleyin. Beyan, devir zincirindeki boşluğu görünür kılar.

Son bir hatırlatma: yazılım sözleşmesini imzalamadan önce fikri haklar maddesini yüksek sesle okuyun. Hangi hakların sayıldığını, devrin ne zaman gerçekleştiğini ve teslim paketinde ne olduğunu tek okumada anlayamıyorsanız, madde yeterince açık değildir.

Kod sahipliği, projenin teknik kalitesinden bağımsız bir konudur. İyi çalışan bir yazılımı kötü bir sözleşmeyle teslim almak mümkündür ve fark genelde iki yıl sonra, ajans değiştirme anında ortaya çıkar. Devir maddesini tek tek sayılmış haklarla yazmak, teslim beyanını imzalamak ve açık kaynak dökümünü istemek — üçü birlikte bu riski ortadan kaldırır.

Kurumsal yazılım projelerinde sözleşme ve teslim süreçlerini şeffaf yürütüyoruz: web yazılım hizmetlerimizi inceleyebilir, fikri mülkiyet ve teslim maddelerini projenize göre netleştirmek için bizimle iletişime geçebilirsiniz. Fikrinizin sözleşme öncesi korunması konusundaysa uygulama fikrini koruma rehberimiz iyi bir başlangıç noktası.