Yazılım bedelini ödediniz, sistem canlıya alındı, ekipleriniz her gün kullanıyor. Peki bir gün geliştirici firmayla yolları ayırmak ya da sistemi başka bir ekibe devretmek isterseniz, kaynak kodu elinizde olacak mı? Birçok şirket bu soruyla ilk kez iş işten geçtikten sonra karşılaşıyor. Özel yazılımda fikri mülkiyet hakları sözleşmede açıkça düzenlenmediğinde, ödediğiniz bedel size beklediğiniz sahipliği vermeyebilir.
Bu yazıda kaynak kodunun varsayılan hukuki durumunu, devir ile lisans arasındaki farkı, sözleşmeye yazılması gereken maddeleri ve teslim sırasında kullanabileceğiniz bir kontrol listesini bulacaksınız. Amacımız size hukuki hüküm vermek değil, doğru soruları doğru zamanda sormanızı sağlamak. Nihai metinler için mutlaka bir hukukçuyla çalışmanızı öneririz.
Kaynak Kodu Varsayılan Olarak Kime Aittir?
Türkiye'de bilgisayar programları, Fikir ve Sanat Eserleri Kanunu (FSEK) kapsamında eser olarak korunur. Kanun, eser sahibini eseri meydana getiren kişi olarak kabul eder. Yani kodu yazan kişi ya da kurum, aksi sözleşmeyle düzenlenmedikçe haklarını elinde tutar. Sadece bir yazılım için ödeme yapmış olmak, bu hakların otomatik olarak size geçtiği anlamına gelmez.
Burada iki kavramı ayırmak gerekir:
- Manevi haklar: Eser sahibinin eserle bağını koruyan haklardır ve devredilemez.
- Mali haklar: Çoğaltma, uyarlama, yayma ve kullanıma sunma gibi ekonomik haklardır. Bunlar sözleşmeyle devredilebilir veya lisanslanabilir.
Mali hakların devri genel olarak yazılı şekle tabidir ve devredilen hakların sözleşmede tek tek belirtilmesi beklenir. "Yazılım müşteriye teslim edilir" gibi genel bir cümle çoğu zaman bu şartı karşılamaz ve ileride yorum tartışması doğurur.
Çalışan ile bağımsız yüklenici arasındaki fark da önemlidir. İş ilişkisi içinde geliştirilen programlarda mali haklara ilişkin işveren lehine özel kurallar bulunur. Dışarıdan hizmet aldığınızda ise yazılımı yapan firma bağımsız bir yüklenicidir ve haklar, devir yapılmadıkça onda kalır. Bu yüzden iç ekibinizin ürettiği kodla ajans ya da yazılım şirketinin ürettiği kodu aynı kefeye koymayın.
Devir mi, Lisans mı? Üç Temel Model
"Kaynak kodu bizim olsun" demek tek başına bir model tarif etmez. Pratikte üç farklı yapı görürüz ve her birinin maliyeti, esnekliği ve riski farklıdır.
| Model | Ne anlama gelir? | Avantajı | Dikkat edilecek nokta |
|---|---|---|---|
| Tam hak devri | Mali haklar müşteriye devredilir; kod müşterinin malı olur. | Yazılımı dilediğiniz ekiple geliştirebilir, satabilir veya ürüne dönüştürebilirsiniz. | Genellikle daha yüksek bedelle gelir; önceden var olan bileşenler istisna olarak ayrılmalıdır. |
| Münhasır olmayan lisans | Yazılımı kullanma hakkınız vardır, mülkiyet geliştiricide kalır. | Başlangıç maliyeti düşüktür, geliştirici ürünü başka müşterilere de sunabilir. | Süre, kapsam, kullanıcı sayısı ve kod erişimi sınırları net yazılmalıdır. |
| Kısmi devir / ortak model | Özel modüller müşteriye geçer; ortak çekirdek geliştiricide kalır ve lisanslanır. | Hem özelleştirme hem maliyet dengesi sağlanır. | Hangi parçanın kime ait olduğu ekli bir bileşen listesiyle belgelenmelidir. |
Doğru model yazılımın amacına bağlıdır. Yalnızca kendi operasyonunuzu yürüten bir iç sistem için tam devir genellikle mantıklıdır. Başkalarına satmayı planladığınız bir ürün söz konusuysa, hakları baştan net biçimde elinizde tutmak daha da önemli hale gelir. SaaS platform geliştirme projelerinde bu nokta özellikle kritiktir; çünkü ürünün kendisi şirketin değerini belirler.
Sözleşmede Bulunması Gereken Fikri Mülkiyet Maddeleri
Çalışma modelini (sabit fiyat, adam/saat) belirlemek tek başına yetmez. Hak devri ayrı ve açık bir maddeyle düzenlenmelidir. Çalışma modellerinin farklarını yazılım sözleşme modelleri rehberimizde anlattık; burada ise fikri mülkiyet açısından sözleşmede aramanız gereken başlıkları sıralıyoruz:
- Devredilen hakların kapsamı: Çoğaltma, uyarlama, yayma, işleme gibi hakların tek tek yazılması.
- Zaman ve coğrafya: Devrin süresiz ve yurt dışını da kapsayıp kapsamadığı.
- Devrin zamanlaması: Haklar imza anında mı, yoksa son ödemenin yapıldığı anda mı geçer? Ödeme şartına bağlı devir yaygındır ve makuldür.
- Teslim edilecek materyaller: Kaynak kod, veritabanı şeması, API dokümantasyonu, kurulum betikleri, tasarım dosyaları.
- Önceden var olan bileşenler: Geliştiricinin projeden bağımsız ürettiği kütüphane ve çerçevelerin ayrı bir listede tanımlanması.
- Üçüncü taraf ve açık kaynak bileşenler: Kullanılan paketlerin lisans türleriyle birlikte raporlanması.
- Gizlilik ve rekabet sınırları: Geliştiricinin sizin iş sırlarınızı ve verilerinizi nasıl koruyacağı; benzer bir ürünü başkasına yapıp yapamayacağı.
- Garanti ve tazmin: Teslim edilen kodun üçüncü kişilerin haklarını ihlal etmediğine dair beyan.
- Bakım dönemi ve kod erişimi: Destek bittikten sonra kod ve ortam erişimlerinin kimde olacağı.
Bu listeyi sözleşme imzalanmadan önce, teknik kapsamla birlikte ele almanızı öneririz. Özel yazılım projesine başlamadan önce sorulacak 12 soru yazımızdaki başlıklar, bu görüşmeye iyi bir zemin hazırlar.
Önceden Var Olan Bileşenler ve Açık Kaynak Kütüphaneler
Geliştiricinin "hazır çekirdeği" sizin kodunuzun parçası mı?
Çoğu yazılım şirketi, projeler arasında tekrar kullandığı iç kütüphaneler, kimlik doğrulama modülleri veya yönetim paneli iskeletleri taşır. Bunlar sizin projeniz başlamadan önce vardır ve geliştirici bunları yalnızca size lisanslamak isteyebilir. Bu meşru bir talep olabilir; ancak sözleşmede açıkça yazılmazsa "kodun yarısı kimin?" tartışmasına dönüşür.
Pratik çözüm basit: sözleşmeye ek olarak bir bileşen listesi koyun. Listede her bileşenin adı, kime ait olduğu ve size hangi kapsamda (süresiz, devredilebilir, ürünle birlikte) kullanım hakkı verildiği yer alsın. Süresiz ve geri alınamaz lisans, kaynak kodunun sizde çalışmaya devam etmesi için en kritik ifadedir.
Açık kaynak lisansları sessiz bir risk olabilir
Modern yazılımların büyük kısmı açık kaynak paketlere dayanır. MIT ve Apache gibi izin verici lisanslar ticari kullanımda genelde sorun çıkarmaz. Buna karşılık bazı "copyleft" lisanslar, kodu dağıttığınızda kendi kaynak kodunuzu da aynı lisansla paylaşmanızı gerektirebilir. Bu, özellikle yazılımı bir ürün olarak satmayı ya da müşterilere dağıtmayı planlıyorsanız önemlidir.
Teslimde istemeniz gereken şey, kullanılan tüm paketlerin lisanslarıyla birlikte listelendiği bir bağımlılık raporudur. Bu rapor, ileride yatırımcı incelemesi (due diligence) veya şirket satışı gibi süreçlerde de işinize yarar.
Yapay zekâ destekli kod yazımı
Geliştirme ekiplerinin kod asistanlarını kullanması artık yaygın. Bu araçlarla üretilen kodun hukuki statüsü ve lisans riskleri konusunda uygulama hâlâ oturmuş değil. Sözleşmenizde, geliştiricinin yapay zekâ araçlarını kullanıp kullanmadığını, müşteri verisinin bu araçlara gönderilip gönderilmediğini ve üretilen kodun gözden geçirilme yöntemini açıkça sormanızı tavsiye ederiz.
Senaryo: Ödeme Tamam, Kod Teslim Edilmedi
Gerçekçi bir örnek düşünelim. Orta ölçekli bir lojistik firması, sevkiyat takibi için özel bir web uygulaması yaptırıyor. Sözleşmede yalnızca "yazılımın teslimi" yazıyor; kaynak kod, hak devri ve altyapı erişimi hakkında hiçbir hüküm yok. Üç yıl sonra firma, sistemi yeni bir ekiple büyütmek istiyor.
Eski geliştirici, yalnızca derlenmiş uygulamanın ve kullanım hakkının teslim edildiğini, kaynak kodunun ise kendi mülkiyetinde kaldığını söylüyor. Sunucu ve alan adı da geliştiricinin hesabında duruyor. Sonuç: şirket ya yüksek bir bedelle kod satın almak ya da sistemi sıfırdan yeniden yazdırmak zorunda kalıyor.
Bu senaryodaki sorunların hiçbiri teknik değil; hepsi baştan yazılabilecek sözleşme maddeleriyle önlenebilirdi. Benzer riskleri azaltmanın bir diğer yolu da teknik kapsamı baştan netleştirmektir. Özel yazılım geliştirme sürecimizde bu konuları, teklif aşamasında masaya yatırıyoruz.
Teslim Günü Kontrol Listesi
Hak devri sözleşmede yazılı olsa bile, fiilî teslim yapılmadıkça hak kâğıt üzerinde kalır. Proje kapanışında aşağıdakileri tek tek doğrulayın:
- Kaynak kod deposuna (Git) sizin adınıza açılmış hesapla tam erişim ve commit geçmişinin eksiksiz aktarımı.
- Derleme ve dağıtım adımlarını anlatan dokümantasyon ile CI/CD yapılandırma dosyaları.
- Veritabanı şeması, örnek veri ve yedekleme/geri yükleme prosedürü.
- Sunucu, bulut, alan adı, SSL sertifikası, e-posta servisi ve üçüncü taraf API hesaplarının sizin adınıza olması.
- Mobil uygulamalarda Apple Developer ve Google Play hesaplarının sizin kurumsal hesabınız altında yürütülmesi.
- Gizli anahtarlar, ortam değişkenleri ve parolaların güvenli ortamda teslimi.
- Bağımlılık ve lisans raporu; önceden var olan bileşen listesinin güncel hali.
- Tasarım kaynak dosyaları, font ve görsel lisansları.
- Bakım döneminde geliştiricinin hangi ortamlara hangi yetkiyle eriştiğinin kayıt altına alınması.
Teknik bir bağımsızlık testi de yapabilirsiniz: teslim edilen kodu, projeyi daha önce görmemiş bir geliştiricinin kendi ortamında ayağa kaldırıp kaldıramadığına bakın. Kurulum yalnızca eski ekibin bilgisiyle yapılabiliyorsa, teslim eksiktir.
Kod Escrow Ne Zaman Anlamlı?
Her projede tam devir mümkün ya da gerekli olmayabilir. Örneğin geliştirici ortak bir ürün çekirdeğini lisanslıyor ve sizin işiniz bu çekirdeğe bağlıysa, firmanın kapanması ya da hizmeti sonlandırması ciddi bir iş sürekliliği riski yaratır. Bu durumda "kaynak kod emaneti" (escrow) yaklaşımı gündeme gelir: kod, tarafsız bir üçüncü tarafta saklanır ve önceden tanımlanmış tetikleyici olaylarda (iflas, bakım yükümlülüğünün ihlali gibi) size açılır.
Bu yapı daha çok kritik iş süreçlerinde, kurumsal ölçekte ve lisans modeliyle çalışılan yazılımlarda anlamlıdır. Küçük bir iç araç için genellikle doğrudan devir daha sade ve ucuz bir çözümdür.
Sık Sorulan Sorular
Yazılımın bedelini ödedim, kaynak kodu otomatik olarak benim olur mu?
Hayır, otomatik olmaz. FSEK uyarınca mali hakların devri için yazılı bir sözleşme ve devredilen hakların açıkça belirtilmesi gerekir. Sözleşmede devir hükmü yoksa, çoğu durumda yalnızca sözleşme amacı kadar kullanım hakkına sahip olursunuz.
Kaynak kodu teslimi ile hak devri aynı şey mi?
Değil. Kodu teslim almak, onu değiştirme, çoğaltma veya satma hakkını vermez. Teslim fiilî bir durumdur; hak devri ise hukuki bir işlemdir. İkisinin de sözleşmede ayrı ayrı düzenlenmesi gerekir.
Geliştirici firma, yaptığı yazılımı başka müşterilere de satabilir mi?
Haklar tamamen size devredilmişse ve sözleşmede aksi yazılmamışsa satamaz; ancak ortak çekirdek veya önceden var olan bileşenler ona ait kalabilir. Bu nedenle rekabet yasağı, gizlilik ve bileşen listesi maddelerinin netleştirilmesi gerekir.
SaaS veya abonelik modelinde kaynak kodu kimde olur?
Genellikle yazılımı sunan firmada kalır; siz yalnızca kullanım lisansı alırsınız. Bu model işinizin sürekliliği için kritikse, veri dışa aktarma hakkı, hizmet seviyesi taahhüdü ve gerekirse kod emaneti gibi güvenceleri sözleşmeye ekletmelisiniz.
Açık kaynak kütüphaneler kullanılması mülkiyet hakkımı etkiler mi?
Lisansa bağlıdır. Çoğu izin verici lisans kendi kodunuzun mülkiyetini etkilemez. Bazı copyleft lisanslar ise dağıtım durumunda kodunuzu paylaşma yükümlülüğü getirebilir. Teslimde lisans raporu istemek bu riski görünür kılar.
Hak devri sözleşmesini kim hazırlamalı?
Teknik kapsamı yazılım ekibiyle, hukuki metni ise bir avukatla birlikte hazırlamanız en sağlıklı yoldur. Yazılım ekibi teslim edilecek bileşenleri ve riskleri doğru tarif eder, avukat ise bunu bağlayıcı bir metne dönüştürür.
Sonuç: Sahipliği Baştan Yazın
Özel yazılımda fikri mülkiyet hakları, proje bittikten sonra değil, teklif aşamasında çözülmesi gereken bir konudur. Kaynak kodunun kime ait olacağını, hangi bileşenlerin lisanslı kalacağını ve teslimde neleri alacağınızı baştan yazdığınızda, hem bütçenizi hem de ileride yazılımı büyütme özgürlüğünüzü korursunuz.
Yeni bir yazılım yatırımı planlıyorsanız, fikri mülkiyet ve teslim kriterlerini ilk görüşmede birlikte netleştirelim. Projenizin kapsamını ve sahiplik modelini konuşmak için iletişim sayfamız üzerinden bizimle görüşebilir ve teklif talep edebilirsiniz.
