Oyun Outsourcing Sözleşmesi Nasıl Hazırlanır? IP, Milestone ve Revenue Share Rehberi
Oyun stüdyoları dış geliştirme ekipleriyle çalışırken hangi sözleşmeleri yapmalı? Fikri mülkiyet hakları, milestone ödemeleri, gelir paylaşımı, teslim ve fesih süreçlerini Türk hukuku kapsamında inceliyorum.
Bir oyun stüdyosunun bütün geliştirme süreçlerini kendi ekibiyle yürütmesi her zaman mümkün değildir. Özellikle bağımsız oyun geliştiricileri ve yeni kurulan oyun şirketleri; yazılım geliştirme, oyun tasarımı, karakter modelleme, animasyon, ses tasarımı, kalite kontrol ve porting gibi faaliyetleri dış ekiplerden hizmet alarak gerçekleştirebilir.
Ancak bir oyunun geliştirilmesini başka bir ekibe bırakmak, yalnızca teslim tarihi ve ücret konusunda anlaşmak anlamına gelmez.
Dış geliştirme ekibinin ürettiği oyunun fikri mülkiyet hakları kime ait olacak? Proje tamamlanmadan ekip ayrılırsa mevcut kaynak kodlar kullanılabilecek mi? Milestone ödemeleri hangi koşullarda yapılacak? Revenue share modeliyle çalışan bir ekip oyunun haklarına ortak olur mu?
Bu soruların yanıtları, geliştirici ekip ile oyun stüdyosu arasında kurulacak sözleşmenin hukuki niteliğine ve hükümlerine bağlıdır.
Özellikle yatırım almayı veya uluslararası bir yayıncıyla çalışmayı planlayan oyun şirketleri açısından dış geliştiricilerle kurulan ilişkiler, şirketin fikri mülkiyet zincirini (chain of title) doğrudan etkileyebilir.
Bu yazıda oyun outsourcing sözleşmelerinin Türk hukukundaki niteliğini, fikri mülkiyet haklarını, milestone ve revenue share modellerini, kaynak kod teslimini, fesih hükümlerini ve uygulamada karşılaşılan sözleşmesel riskleri ayrıntılı olarak inceliyorum.
1. Oyun Outsourcing Nedir?
Oyun outsourcing, bir video oyununun geliştirilmesine ilişkin belirli faaliyetlerin veya projenin tamamının şirket dışındaki bağımsız kişilere ya da ekiplere yaptırılmasıdır.
Oyun sektöründe dış kaynak kullanımı yalnızca teknik işlerin devredilmesi amacıyla yapılmaz. Bazı yayıncılar veya oyun şirketleri, oyunun fikrini ve ticari stratejisini kendileri belirlerken geliştirme faaliyetinin tamamını bağımsız bir ekibe bırakabilir.
Örneğin bir oyun şirketi:
Oyun fikrini ve hedef kitlesini kendisi belirleyebilir.
Oyunun geliştirilmesini dışarıdaki bir stüdyoya yaptırabilir.
Prototip veya vertical slice aşamasında finansman sağlayabilir.
Geliştirme tamamlandığında oyunu kendi markası altında yayımlayabilir.
Elde edilen geliri geliştirme ekibiyle sözleşmede kararlaştırılan oranlarda paylaşabilir.
Bu tür ilişkiler, tek bir hizmet alımından daha kapsamlı bir ticari yapıya sahip olabilir.
Oyun outsourcing, co-development ve publishing aynı şey midir?
Hayır. Birbirine benzeyen yönleri bulunsa da bu modellerin hukuki ve ticari yapıları farklıdır.
Outsourcing: Belirli geliştirme işlerinin veya ürünün tamamının dışarıdan bir kişiye ya da ekibe yaptırılmasıdır.
Co-development: Birden fazla ekibin oyun geliştirme sürecine birlikte katıldığı modeldir. Ancak co-development ifadesi tek başına ortak eser sahipliği veya şirkette ortaklık kurulduğu anlamına gelmez.
Publishing: Oyunun yayımlanması, dağıtılması, pazarlanması ve bazen finanse edilmesiyle ilgili ticari faaliyetlerin bir yayıncı tarafından üstlenilmesidir.
Work-for-hire: Özellikle yabancı hukuk sistemlerinde karşılaşılan ve belirli koşullarda sipariş üzerine veya iş ilişkisi kapsamında üretilen çalışmaların hak sahipliğini düzenleyen bir kavramdır. Bu ifadenin Türk hukukunda her durumda aynı hukuki sonucu doğurduğu kabul edilemez.
Dolayısıyla sözleşmenin başlığında "Game Development Agreement", "Outsourcing Agreement" veya "Work-for-Hire Agreement" yazması tek başına hak sahipliğini belirlemez.
Önemli olan, tarafların üstlendikleri yükümlülükler ve uygulanacak hukuktur.
2. Oyun Geliştirme Sözleşmesinin Türk Hukukundaki Niteliği Nedir?
Türk hukukunda bütün oyun outsourcing ilişkilerini doğrudan düzenleyen, "oyun geliştirme sözleşmesi" adıyla özel bir sözleşme türü bulunmamaktadır.
Bu ilişkiler, somut sözleşmenin içeriğine göre Türk Borçlar Kanunu'nun farklı hükümleri kapsamında değerlendirilebilir.
Oyun geliştirme sözleşmesi eser sözleşmesi midir?
6098 sayılı Türk Borçlar Kanunu'nun (TBK) 470. maddesi uyarınca eser sözleşmesinde yüklenici, bir eser meydana getirmeyi; iş sahibi ise bunun karşılığında bir bedel ödemeyi üstlenir.
Belirli teknik özelliklere sahip bir oyunun veya yazılım modülünün tamamlanarak teslim edilmesi yükümlülüğü, somut olayın şartlarına göre eser sözleşmesi niteliğinde olabilir.
Örneğin bir geliştirici ekibin:
Belirli özelliklere sahip mobil oyun üretmesi,
Mevcut bir oyuna çok oyunculu mod geliştirmesi,
Oyunun konsol sürümünü hazırlaması,
Belirli bir oyun sistemi veya yazılım bileşeni teslim etmesi
eser meydana getirme borcu kapsamında değerlendirilebilir.
Buna karşılık yalnızca belirli süre boyunca yazılım geliştirme desteği verilmesi veya aylık personel kapasitesi sağlanması farklı bir hukuki değerlendirme gerektirebilir.
Sözleşme; eser, hizmet, vekâlet, lisans ve gelir paylaşımına ilişkin unsurları birlikte içeriyorsa karma veya isimsiz sözleşme niteliği de gündeme gelebilir.
Bu ayrım özellikle teslim, ayıp, sorumluluk ve fesih hükümlerinin uygulanmasında önemlidir.
Geliştirme ekibinin özen borcu
TBK m.471, eser sözleşmesindeki yüklenicinin üstlendiği edimleri iş sahibinin haklı menfaatlerini gözeterek sadakat ve özenle yerine getirmesini düzenler.
Bir oyun geliştirme projesinde bu borcun kapsamı; teknik şartnameye uygun çalışma, kararlaştırılan geliştirme standartlarına uyma, üçüncü taraf lisanslarının gözetilmesi ve sözleşmedeki teslim yükümlülüklerinin yerine getirilmesi bakımından önem kazanabilir.
Ancak her teknik aksaklık kendiliğinden sözleşmeye aykırılık veya tazminat sorumluluğu doğurmaz.
Geliştirme sürecindeki değişiklik talepleri, tarafların iş birliği yükümlülükleri ve sözleşmeyle belirlenen risk dağılımı birlikte değerlendirilmelidir.
3. Dış Ekip Tarafından Geliştirilen Oyunun Fikri Mülkiyet Hakları Kime Aittir?
Oyun outsourcing sözleşmelerinin en önemli konusu, fikri mülkiyet haklarının hangi tarafta bulunacağıdır.
Bir oyun şirketinin geliştirme hizmeti satın alması ve bütün ödemeleri gerçekleştirmesi, ortaya çıkan kaynak kod, görsel tasarım ve müzikler üzerindeki bütün mali hakların kendiliğinden şirkete geçtiği anlamına gelmez.
5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK) bakımından eser sahipliği ile mali hakların devri veya kullanım yetkisi birbirinden ayrılmalıdır.
Oyunun ücretini ödeyen şirket hakların da sahibi olur mu?
Her durumda hayır.
Örneğin A Oyun Şirketi, B Geliştirme Ekibi ile 200.000 TL karşılığında bir mobil oyun geliştirilmesi konusunda anlaşmış olsun.
B Ekibi kaynak kodu yazmış, karakterleri tasarlamış ve oyunu tamamlamış olabilir.
A Şirketi sözleşme bedelini ödemiş olsa bile, hangi mali hakları ne kapsamda edindiği ayrıca incelenmelidir.
FSEK m.52 uyarınca mali haklara ilişkin sözleşme ve tasarrufların yazılı olması ve sözleşmeye konu hakların ayrı ayrı gösterilmesi gerekmektedir.
Bu nedenle yalnızca:
"Proje kapsamında üretilen bütün çalışmalar müşteriye aittir."
şeklinde bir ifade kullanılması, hakların kapsamı ve devrin geçerliliği bakımından uyuşmazlık yaratabilir.
Sözleşmede hangi fikri mülkiyet hakları düzenlenmelidir?
Somut çalışmanın niteliğine göre özellikle şu mali haklar değerlendirilmelidir:
İşleme hakkı (FSEK m.21): Oyunun uyarlanması, değiştirilmesi ve yeni sürümlerinin hazırlanmasıyla ilgili kullanımlar.
Çoğaltma hakkı (FSEK m.22): Korunan yazılım veya diğer eser unsurlarının çoğaltılmasını gerektiren faaliyetler.
Yayma hakkı (FSEK m.23): Eser nüshalarının hukuken ilgili dağıtım ve satış biçimleri.
Temsil hakkı (FSEK m.24): Somut eserin ve kullanımın niteliğine göre önem taşıyabilecek faaliyetler.
İşaret, ses veya görüntü nakline yarayan araçlarla umuma iletim hakkı (FSEK m.25): Dijital erişim ve iletim faaliyetleri bakımından gündeme gelebilecek kullanımlar.
Bu hakların tamamı her eser ve her geliştirme faaliyetinde aynı şekilde uygulanmaz.
Sözleşmenin konusu, ortaya çıkan eser türleri ve planlanan kullanımlar dikkate alınarak gerekli hakların belirlenmesi gerekir.
Mali hakların devri ile belirli kullanım yetkilerinin lisans yoluyla verilmesi de birbirinden farklıdır.
Daha kapsamlı açıklamalar için Oyun Geliştirirken Fikri Mülkiyetinizi (IP) Nasıl Korursunuz? Telif Hakları ve Lisanslama Rehberi başlıklı makalemi inceleyebilirsiniz.
Henüz geliştirilmemiş oyunun hakları şimdiden devredilebilir mi?
Burada gelecekte meydana getirilecek eserler ile mevcut eserler arasında ayrım yapılmalıdır.
FSEK m.48 ve m.50 birlikte değerlendirildiğinde, henüz meydana getirilmemiş veya tamamlanmamış eserler üzerindeki mali hakların doğrudan tasarrufa konu edilmesi ile bunların ileride devredilmesine yönelik taahhüt kurulması aynı değildir.
Bu nedenle uzun süreli oyun geliştirme projelerinde yalnızca gelecekte oluşturulacak bütün içeriklerin bugünden kesin biçimde devredildiğinin yazılması yeterli olmayabilir.
Sözleşme mimarisinde ileride ortaya çıkacak eserlerin belirlenmesi, gerekli mali hak taahhütlerinin kurulması ve hukuken gerekli devir veya lisans işlemlerinin gerçekleştirilmesi ayrı aşamalar olarak ele alınmalıdır.
Özellikle milestone bazlı geliştirme sözleşmelerinde bu konunun ödeme ve teslim mekanizmasıyla uyumlu düzenlenmesi önem taşır.
4. Geliştirme Ekibindeki Herkesle Ayrı Fikri Hak Sözleşmesi Gerekir mi?
Oyun şirketi çoğu zaman dış geliştirici ekibin lideri veya kurduğu şirketle sözleşme yapar.
Ancak oyun üzerinde fiilen çalışan kişiler farklı olabilir.
Örneğin:
Kaynak kodu bir yazılımcı,
Karakterleri bir 3D artist,
Arayüzü bir UI/UX tasarımcısı,
Müzikleri bağımsız bir besteci,
Animasyonları başka bir freelancer
hazırlayabilir.
Bu durumda ana yükleniciyle sözleşme yapılmış olması, bütün üçüncü taraf haklarının eksiksiz biçimde temin edildiğini tek başına göstermez.
Chain of Title nedir?
Chain of Title, bir oyun veya diğer fikri ürün üzerindeki hakların kimlerden hangi hukuki işlemlerle geçtiğinin izlenebilmesini sağlayan hak sahipliği zinciridir.
Örneğin bağımsız müzisyenin bestelediği bir parça, oyun stüdyosunun uluslararası dağıtımında kullanılacaksa bu kullanımın hukuki dayanağı ortaya konulabilmelidir.
Dış geliştirici şirketin çalışanları bakımından FSEK m.18 çerçevesinde mali hakların kullanımı gündeme gelebilir. Ancak bağımsız çalışanlar bakımından aynı sonucun kendiliğinden doğduğu varsayılamaz.
Bu nedenle ana yüklenicinin:
Kendi çalışanları ve alt yüklenicileriyle gerekli hukuki düzenlemeleri yapması,
Teslim ettiği ürünlerdeki üçüncü taraf haklarını açıklaması,
Müşteriye vaat ettiği hakları sağlamaya yetkili olması,
Lisans sınırlamalarını ve istisnaları bildirmesi,
Gerekli belgeleri sunması
sözleşmesel yükümlülük olarak düzenlenebilir.
Alt yüklenici kullanımı yasaklanabilir mi?
Taraflar, hukuken mümkün olduğu ölçüde alt yüklenici kullanımını sınırlayabilir veya belirli işlerin önceden yazılı onaya tabi tutulmasını kararlaştırabilir.
Ancak TBK m.471'in yüklenicinin işi bizzat gerçekleştirmesine ilişkin düzenlemesi ve somut işin niteliği birlikte değerlendirilmelidir.
Özellikle müşteri tarafından sağlanan kaynak kodların veya gizli teknik belgelerin üçüncü taraflara aktarılması söz konusuysa alt yüklenici kullanımının sınırları açıkça düzenlenmelidir.
5. Background IP ve Foreground IP Ayrımı Neden Önemlidir?
Oyun geliştirme sözleşmelerinde en sık karşılaşılan sorunlardan biri, geliştiricinin önceden sahip olduğu yazılım bileşenleri ile proje kapsamında yeni oluşturduğu içeriklerin birbirine karıştırılmasıdır.
Bu ayrım sözleşmelerde çoğu zaman Background IP ve Foreground IP kavramlarıyla açıklanır.
Background IP, tarafların proje başlamadan önce sahip olduğu veya proje dışında geliştirdiği fikri ürünleri ifade etmek üzere kullanılabilir.
Örneğin geliştirici ekibin daha önce hazırladığı bir envanter sistemi, yapay zekâ davranış modülü veya editör aracı bu kapsamda değerlendirilebilir.
Foreground IP ise belirli proje kapsamında ortaya çıkarılan fikri ürünleri ifade etmek için kullanılır.
Ancak bu kavramların kullanılması tek başına hak sahipliğini belirlemez. Sözleşmede her iki grubun kapsamı ve kullanım yetkileri ayrıca tanımlanmalıdır.
Örnek: Aynı oyun motoru modülü farklı projelerde kullanılabilir mi?
Bir dış ekip, oyun stüdyosu için geliştirdiği oyunda kendi hazırladığı bir kamera kontrol sistemi kullanmış olsun.
Taraflar bu modülü sözleşmede hiç düzenlememişse şu sorular ortaya çıkabilir:
Modülün mali hakları kime aittir?
Müşteri, modülü oyunun gelecekteki sürümlerinde kullanabilir mi?
Kaynak kodu başka geliştiricilere verebilir mi?
Dış ekip aynı modülü başka projelerinde kullanmaya devam edebilir mi?
Modülün güncellenmesi için eski geliştiricinin izni gerekir mi?
Bu soruların yanıtları, geliştiricinin önceden sahip olduğu haklar ve müşteriye verilen lisans kapsamına göre değişir.
Bu nedenle Background IP için ayrı bir ek liste hazırlanması ve müşterinin oyunu sürdürebilmesi için gerekli lisansların belirlenmesi faydalı olabilir.
6. Milestone Payment Nedir? Oyun Geliştirme Ödemeleri Nasıl Planlanır?
Oyun geliştirme süreçlerinde sözleşme bedelinin tek seferde ödenmesi her zaman tercih edilmeyebilir.
Özellikle uzun süreli projelerde ödeme, belirli geliştirme aşamalarının tamamlanmasına bağlanabilir.
Bu modele Milestone Payment, yani aşama bazlı ödeme denir.
Örneğin bir oyun geliştirme sözleşmesinde şu aşamalar kararlaştırılabilir:
| Aşama | Teslim edilecek çalışma | Örnek ödeme oranı |
|---|---|---|
| Milestone 1 | Oynanabilir prototip | %15 |
| Milestone 2 | Vertical slice | %20 |
| Milestone 3 | Alpha sürümü | %25 |
| Milestone 4 | Beta sürümü | %20 |
| Milestone 5 | Final build ve proje devri | %20 |
Bu tablo yalnızca örnek bir ticari modeldir. Bütün oyun projeleri bakımından uygulanması gereken standart bir oran bulunmamaktadır.
Milestone tamamlandı demek ne anlama gelir?
Sözleşmede yalnızca "Alpha tamamlandığında ödeme yapılır." denmesi yeterli olmayabilir.
Çünkü taraflar alpha sürümünden farklı şeyler anlayabilir.
Bunun yerine ilgili milestone için:
Tamamlanması gereken özellikler,
Desteklenecek cihaz ve platformlar,
Performans kriterleri,
Teslim edilecek dosya ve belgeler,
Test yöntemi,
Kabul süresi,
Hata giderme prosedürü
tanımlanabilir.
Örneğin "Oynanabilir prototip teslimi" yerine belirli oyun mekaniklerinin çalıştığı, sözleşmede tanımlanan ortamda test edilebilen bir sürümün teslimi şart koşulabilir.
Milestone ödemesi teslimle mi yoksa kabulle mi yapılmalı?
Bu konuda farklı modeller oluşturulabilir.
Ödeme, geliştiricinin belirli materyalleri teslim etmesine bağlanabileceği gibi müşteri tarafından sözleşmede kararlaştırılan kabul kriterlerinin karşılandığının tespit edilmesine de bağlanabilir.
Ancak müşteriye hiçbir süreye veya objektif kritere bağlı olmaksızın kabulü reddetme imkânı tanınması, geliştirici açısından belirsizlik yaratabilir.
Diğer taraftan yalnızca dosyanın yüklenmesiyle bütün ödeme ve kabul koşullarının gerçekleşmiş sayılması da müşteri açısından riskli olabilir.
Bu nedenle teslim, inceleme, ret, düzeltme ve yeniden test aşamalarının açıkça düzenlenmesi önemlidir.
7. Oyun Geliştirme Sözleşmesinde Teslim ve Kabul Testleri Nasıl Düzenlenmelidir?
Oyun geliştirme faaliyetlerinin teknik niteliği, teslim ve kabul mekanizmasını sözleşmenin en önemli bölümlerinden biri haline getirir.
Özellikle eser sözleşmesi niteliği taşıyan ilişkilerde TBK m.474 ve devamındaki ayıp hükümleri önem kazanabilir.
Ancak tarafların kendi sözleşmelerinde ayrıntılı test ve kabul prosedürü belirlemesi de mümkündür.
User Acceptance Testing (UAT) nedir?
User Acceptance Testing, teslim edilen yazılımın belirli kullanım senaryolarına ve kabul kriterlerine göre değerlendirilmesini ifade eder.
Bir oyun projesinde UAT yalnızca oyunun açılıp açılmadığının kontrolünden ibaret değildir.
Örneğin:
Oyunun ana menüsünün çalışması,
Kayıt sisteminin veri kaybına yol açmaması,
Satın alma sistemlerinin beklenen işlemleri gerçekleştirmesi,
Belirli performans hedeflerinin karşılanması,
Kritik oyun mekaniklerinin çalışması,
Sözleşmeyle belirlenen cihazlarda testlerin tamamlanması
kabul kriteri olarak kullanılabilir.
Her bug teslimin reddedilmesini haklı kılar mı?
Her zaman değil.
Bir oyunda kritik düzeyde çökme hatası bulunması ile kullanıcı arayüzündeki küçük bir hizalama sorunu aynı nitelikte değildir.
Taraflar sözleşmede hata seviyelerini belirleyebilir:
Critical: Oyunun veya temel sistemlerin çalışmasını ciddi biçimde engelleyen hata.
Major: Önemli bir fonksiyonu etkileyen ancak bütün sistemi kullanılamaz hale getirmeyen hata.
Minor: Temel işlevi büyük ölçüde etkilemeyen, daha sınırlı kapsamlı hata.
Bu seviyelerin teknik tanımlarının proje ekinde yapılması ve her birinin kabul sürecine etkisinin belirlenmesi gerekir.
Örneğin kritik hata bulunan build'in kabul edilmeyeceği; belirli sayıdaki küçük hatanın ise kayıt altına alınarak sonraki güncellemede giderilebileceği kararlaştırılabilir.
Müşteri süresinde cevap vermezse teslim kabul edilmiş sayılır mı?
Taraflar sözleşme serbestisinin sınırları içerisinde belirli kabul mekanizmaları düzenleyebilir.
Ancak yalnızca "Beş gün içinde cevap verilmezse her şey kusursuz kabul edilir." şeklinde genel bir hükmün bütün ayıp sorumluluğunu ortadan kaldıracağı varsayılmamalıdır.
TBK m.474, m.475 ve m.477 hükümleri ile somut sözleşmenin içeriği birlikte değerlendirilmelidir.
Özellikle gizli ayıplar, ağır kusur ve kanunen sınırlandırılamayan sorumluluklar ayrıca önem taşır.
8. Revenue Share ile Oyun Geliştirme Sözleşmesi Yapılabilir mi?
Oyun sektöründe dış geliştirme ekipleri her zaman sabit ücret karşılığında çalışmaz.
Bazı projelerde geliştiriciye ilk aşamada sınırlı ödeme yapılır veya hiç sabit ücret ödenmez; buna karşılık oyunun gelecekteki gelirlerinden belirli bir pay verilmesi kararlaştırılır.
Bu model Revenue Share, yani gelir paylaşımı olarak adlandırılır.
Türk hukukunda bu tür bir ticari yapının kurulması prensip olarak mümkün olabilir. Ancak somut ilişkinin niteliği, tarafların yükümlülükleri, vergi sonuçları ve emredici hükümler ayrıca değerlendirilmelidir.
Revenue Share ile şirkette ortak olmak aynı şey midir?
Hayır.
Bir geliştiricinin oyunun gelirlerinden %20 pay alması, kendiliğinden yayıncı veya oyun şirketinin %20 pay sahibi olduğu anlamına gelmez.
Şirket ortaklığı ile sözleşmeden doğan gelir paylaşımı farklı hukuki ilişkilerdir.
Aynı şekilde geliştiriciye revenue share verilmesi, oyunun kaynak kodu üzerindeki fikri hakların otomatik olarak devredildiği anlamına da gelmez.
Bu nedenle sözleşmede üç ayrı konu düzenlenmelidir:
Oyun üzerindeki fikri mülkiyet haklarının durumu.
Geliştiriciye yapılacak sabit veya değişken ödemeler.
Geliştiricinin şirket üzerinde pay sahipliği veya yönetim hakkı bulunup bulunmadığı.
Gelir paylaşımı brüt gelirden mi net gelirden mi hesaplanmalı?
Revenue share sözleşmelerindeki temel sorunlardan biri "gelir" kavramının yeterince açık tanımlanmamasıdır.
Örneğin geliştiriciye oyunun gelirlerinin %30'unun verileceği kararlaştırılmış olsun.
Bu oran şu tutarlardan hangisine uygulanacak?
Oyunun tüketiciye satış bedeline mi?
Platform komisyonlarından sonraki tahsilata mı?
İadeler ve vergiler düşüldükten sonraki gelire mi?
Pazarlama giderleri mahsup edildikten sonraki tutara mı?
Yayıncının kendi payını aldıktan sonra kalan bedele mi?
Bu sorunun yanıtı sözleşmede açıkça verilmelidir.
Örnek hesaplama
Tamamen varsayımsal bir senaryoda oyunun bir dönemde 100.000 USD brüt satış hasılatı oluşturduğunu düşünelim.
Vergi, iade ve diğer kesintilerle ilgili bütün varsayımların sadeleştirildiği bu örnekte:
Brüt satış tutarı: 100.000 USD
Varsayımsal platform kesintisi: 30.000 USD
Kalan tutar: 70.000 USD
Geliştirici gelir payı: %30
Geliştiriciye hesaplanan pay: 21.000 USD
Ancak sözleşmede ayrıca 20.000 USD tutarında mahsup edilebilir pazarlama gideri bulunduğu kararlaştırılmışsa ve bu giderin tamamı aynı döneme yükleniyorsa hesaplama değişebilir.
Bu durumda paylaşıma esas tutar, örnek varsayımlar altında 50.000 USD'ye; geliştiricinin %30 payı ise 15.000 USD'ye düşebilir.
Aradaki 6.000 USD fark, gelir tanımının ne kadar önemli olduğunu gösterir.
Bu örnek, herhangi bir platformun gerçek komisyon oranını veya bir sözleşmenin zorunlu muhasebe yöntemini göstermemektedir. Gerçek hesaplama, platform raporları, vergiler, iadeler ve sözleşmede izin verilen giderlere göre yapılmalıdır.
Revenue Share ne kadar süre devam eder?
Bir oyunun piyasaya sürülmesinden yıllar sonra da satış geliri elde edilmesi mümkündür.
Bu nedenle gelir paylaşımının süresi önemlidir.
Örneğin:
Belirli bir süre için gelir paylaşımı,
Belirli bir tutara ulaşılıncaya kadar gelir paylaşımı,
Oyunun belirli sürümleri için gelir paylaşımı,
Belirli platformlardan elde edilen gelirlerle sınırlı paylaşım,
Oyunun ticari faaliyetinin devamına bağlı paylaşım
modelleri değerlendirilebilir.
Süre ve kapsam belirlenmediğinde, projenin sona ermesinden sonra dahi taraflar arasında gelir paylaşımı uyuşmazlıkları ortaya çıkabilir.
Gelirlerin doğru hesaplandığı nasıl denetlenir?
Revenue share sözleşmelerinde raporlama ve denetim hakkı (audit rights) düzenlenmesi önemlidir.
Geliştiriciye yalnızca "Bu ayki payın 5.000 USD." şeklinde bildirim yapılması, hesaplamanın hangi verilere dayandığını ortaya koymayabilir.
Sözleşmede hangi platform raporlarının paylaşılacağı, ödeme dönemleri, mahsup edilen giderler, itiraz süreleri ve gerektiğinde bağımsız denetim mekanizması belirlenebilir.
Bu konuyu daha ayrıntılı olarak Publisher Sözleşmelerinde Audit Rights: Oyun Gelirleri Nasıl Denetlenir? başlıklı yazımda inceliyorum.
9. Sabit Ücret, Revenue Share ve Hibrit Ödeme Modelleri Nasıl Karşılaştırılır?
Bir dış geliştirme ilişkisinde hangi ödeme modelinin kullanılacağı; projenin riskine, tarafların finansman kapasitesine ve ticari hedeflerine bağlıdır.
| Model | Temel yapı | Dikkat edilmesi gereken konu |
|---|---|---|
| Fixed Fee | Belirli geliştirme işi karşılığında sabit ücret | Kapsam değişiklikleri ve ek işlerin bedeli |
| Milestone Payment | Geliştirme aşamalarına bağlı ödeme | Objektif teslim ve kabul kriterleri |
| Revenue Share | Oyunun gelirinden sözleşmesel pay | Gelir tanımı, süre ve denetim |
| Hybrid | Sabit ödeme ve gelir paylaşımının birlikte kullanılması | Sabit ücretin gelir paylaşımından mahsup edilip edilmeyeceği |
Hibrit model nasıl kurulabilir?
Örneğin oyun stüdyosu, geliştirici ekibe üretim süresince toplam 50.000 USD sabit ödeme ve oyun yayımlandıktan sonra belirli gelirler üzerinden %10 revenue share vermeyi kararlaştırabilir.
Ancak burada iki farklı model mümkündür.
Birinci model: 50.000 USD kesin geliştirme bedelidir. Gelir paylaşımı bu bedele ilave olarak ödenir.
İkinci model: 50.000 USD, ileride doğacak gelir paylarından mahsup edilecek geri kazanılabilir bir avanstır.
Bu iki model aynı ekonomik sonucu doğurmaz.
Bu nedenle avansın geri kazanılabilir olup olmadığı, mahsup sırası, mahsup edilebilecek gelirler ve olası bakiye yükümlülüğü açıkça düzenlenmelidir.
10. Oyun Geliştiricisi Projeyi Yarıda Bırakırsa Ne Olur?
Oyun outsourcing sözleşmelerinin en önemli risklerinden biri, geliştirme sürecinin tamamlanamamasıdır.
Bir dış ekip başlangıçta çalışmalarını düzenli biçimde yürütürken sonradan faaliyetini durdurabilir, gerekli personeli sağlayamayabilir veya projeyi bırakmak isteyebilir.
Böyle bir durumda yalnızca tazminat talep edilip edilemeyeceği değil, oyunun geliştirilmesine başka bir ekiple devam edilip edilemeyeceği de önem taşır.
Proje tamamlanmadan sözleşme feshedilebilir mi?
Bu sorunun yanıtı sözleşmenin hukuki niteliğine, sona erme nedenine ve uygulanabilir kanun hükümlerine bağlıdır.
Örneğin eser sözleşmesi niteliğindeki bir ilişkide TBK m.473, m.484 ve ilgili diğer hükümler farklı koşullar altında önem kazanabilir.
Taraflar ayrıca sözleşmeye:
Esaslı ihlal,
Teslimin gecikmesi,
İhlalin giderilmesi için süre verilmesi,
Kritik geliştirme personelinin projeden ayrılması,
Sözleşmeye aykırı alt yüklenici kullanımı,
Gizlilik veya fikri hak yükümlülüklerinin ihlali
gibi sona erme nedenleri ekleyebilir.
Ancak sözleşmeye yazılan her fesih hükmünün diğer kanuni sonuçları kendiliğinden ortadan kaldıracağı kabul edilmemelidir.
Fesih halinde tamamlanan çalışmalar kime ait olur?
Sözleşmenin sona ermesi ile o tarihe kadar oluşturulmuş çalışmalar üzerindeki fikri hakların durumu ayrı konulardır.
Örneğin dış ekip oyunun %60'ını tamamlamış olabilir.
Bu aşamada:
Tamamlanan kaynak kodlar,
Tasarım dosyaları,
Teknik belgeler,
Kullanılan lisanslar,
Geliştirme hesapları,
Kabul edilmiş milestone çalışmaları,
Henüz tamamlanmamış çalışmalar
bakımından farklı sonuçlar gündeme gelebilir.
Bu nedenle sözleşmede fesih sonrasında teslim yükümlülüğünün kapsamı, ödeme ve hak sahipliği hükümleriyle birlikte düzenlenmelidir.
Başka bir geliştirici ekiple projeye devam edilebilir mi?
Teknik olarak mümkün olması, her durumda hukuken yetkili olunduğu anlamına gelmez.
Yeni geliştirici ekibin mevcut kodu değiştirmesi, uyarlaması veya çoğaltması gerekiyorsa ilgili fikri hakların kapsamı önem kazanabilir.
Bu nedenle sözleşmede devam ettirme ve gerekli hallerde üçüncü kişilere geliştirme yaptırma yetkisinin hukuki sınırları açıkça belirlenmelidir.
11. Kaynak Kod, GitHub ve Geliştirme Hesapları Kimin Kontrolünde Olmalı?
Oyun geliştirme projelerinde fikri hakların sözleşmeyle düzenlenmesi tek başına yeterli olmayabilir.
Şirketin kaynak kodlara fiilen erişememesi veya teknik hesapların tamamının dış ekipte bulunması, ticari süreklilik açısından sorun oluşturabilir.
Örneğin oyunun bütün geliştirme süreci, dış ekibin kendi GitHub organizasyonunda yürütülüyor olabilir.
Proje sona erdiğinde müşteri kaynak kodların güncel sürümüne, geliştirme geçmişine veya teknik belgelere ulaşamayabilir.
Bu nedenle sözleşmede:
GitHub veya GitLab depo sahipliği,
Kodlara erişim yetkileri,
Commit ve sürüm yönetimi,
Geliştirme belgelerinin teslimi,
Build ve deployment süreçleri,
Hesapların ve lisansların yönetimi,
Erişimlerin sona erme sonrası devri
düzenlenebilir.
Kaynak kodu teslim etmek fikri hakları devretmek midir?
Hayır.
Bir şirketin kaynak kod dosyalarına sahip olması, kod üzerindeki bütün mali haklara sahip olduğu anlamına gelmez.
Benzer şekilde fikri hakların kullanımı yönünden gerekli yetkilere sahip olmak da sistemin çalıştırılabilmesi için gerekli bütün teknik materyallere fiilen erişilebildiğini göstermez.
Bu nedenle hukuki yetki ve teknik teslim birlikte planlanmalıdır.
Source Code Escrow kullanılabilir mi?
Bazı projelerde kaynak kod ve ilgili teknik belgelerin bağımsız bir saklayıcıya teslim edilmesi kararlaştırılabilir.
Bu model Source Code Escrow olarak adlandırılır.
Ancak escrow sistemi her oyun projesi bakımından zorunlu veya uygun değildir. İlişkinin ölçeği, projenin kritikliği ve tarafların riskleri dikkate alınmalıdır.
Bu mekanizmanın hukuki yapısını Source Code Escrow Nedir? Kaynak Kod Emanet Sözleşmesi ve Hukuki Şartları başlıklı makalemde ayrıca inceliyorum.
12. Dış Ekibin Geliştirdiği Oyuna Publisher ile Anlaşma Yapılabilir mi?
Bir oyun şirketi, geliştirme faaliyetlerini dışarıdan hizmet alarak yürütürken oyunun yayıncılığını kendisi üstlenebilir.
Başka bir modelde ise geliştirme tamamlandıktan sonra uluslararası bir yayıncıyla anlaşabilir.
Ancak bu durumda geliştirici ekip ile oyun şirketi arasındaki sözleşmenin, publisher ile yapılacak sözleşmede üstlenilen yükümlülüklerle uyumlu olması gerekir.
Örneğin publisher, oyunun belirli platformlarda yayımlanması için münhasır lisans talep edebilir.
Oyun şirketinin bu lisansı verebilmesi için gerekli mali haklara veya alt lisans verme yetkisine sahip olması gerekir.
Dış geliştirme ekibiyle yapılan sözleşmede bu yetkilerin kapsamı belirsizse publisher sözleşmesi bakımından da sorun doğabilir.
Özellikle:
Alt lisans verme yetkisi,
Porting ve uyarlama hakları,
Oyunun devam sürümleri,
DLC ve ek içerikler,
Yerelleştirme çalışmaları,
Oyun markası ve karakterlerin kullanımı
gibi konular iki sözleşme arasındaki bağlantı bakımından önem taşır.
Oyunların farklı platformlara uyarlanmasındaki hukuki riskleri Oyun Porting Sözleşmesi: PC'den Konsola Uyarlamada IP ve Teslim Hakları başlıklı makalemde ayrıca ele aldım.
13. Gizlilik, Rekabet ve Geliştirici Ekibin Portföy Kullanımı
Oyun geliştirme projelerinde ticari sır niteliğindeki bilgiler dış ekiple paylaşılabilir.
Örneğin:
Henüz yayımlanmamış oyun fikirleri,
Geliştirme yol haritaları,
Kaynak kodlar,
Oyun içi ekonomi tasarımları,
Oyuncu analitiği,
Finansal öngörüler,
Yayıncı görüşmeleri
gizlilik sözleşmesi kapsamında korunması değerlendirilebilecek bilgiler arasındadır.
Ancak gizlilik yükümlülüğünün kapsamı ve süresi belirlenirken tarafların meşru menfaatleri ve uygulanabilir hukuk dikkate alınmalıdır.
Geliştirici ekip oyunu portföyünde gösterebilir mi?
Dış geliştirici ekibin, tamamladığı oyunu kendi internet sitesinde veya sosyal medya hesaplarında referans olarak kullanmak istemesi mümkündür.
Ancak oyun henüz yayımlanmamış olabilir veya sözleşmede gizlilik yükümlülüğü bulunabilir.
Bu nedenle portföy kullanımının:
Hangi tarihten itibaren mümkün olduğu,
Hangi görsellerin paylaşılabileceği,
Müşterinin önceden onayının gerekip gerekmediği,
Yayımlanmamış içeriklerin açıklanıp açıklanamayacağı
açıkça düzenlenebilir.
Geliştirici ekibin başka oyunlar yapması yasaklanabilir mi?
Bir geliştirici ekibin rakip projelerde çalışması veya benzer türde oyunlar üretmesi, sözleşmesel sınırlamaların konusu olabilir.
Ancak geniş ve belirsiz rekabet yasaklarının her koşulda geçerli olacağı varsayılmamalıdır.
Özellikle işçi niteliğindeki kişiler bakımından TBK m.444 ve devamındaki rekabet yasağı hükümleri ayrıca önem taşır. Bağımsız ticari sözleşmeler bakımından ise somut hukuki yapı ve ilgili emredici sınırlar değerlendirilmelidir.
14. Geliştirme Sürecinde Kişisel Veriler ve Yapay Zekâ Kullanımı
Oyun outsourcing sözleşmeleri çoğu zaman yalnızca yazılım ve fikri mülkiyet konularıyla ilişkilendirilir.
Ancak dış ekibin gerçek oyuncu verilerine erişmesi veya üçüncü taraf yapay zekâ hizmetlerinden yararlanması halinde farklı yükümlülükler ortaya çıkabilir.
Geliştirici ekip oyuncu verilerine erişirse ne olur?
Örneğin dış ekip, canlı bir oyuna yeni özellik geliştirmek amacıyla kullanıcı hesaplarına veya oyuncu davranış verilerine erişiyor olabilir.
Bu durumda kişisel veri işleme faaliyetlerinin hukuki dayanağı, tarafların veri sorumlusu ve veri işleyen sıfatları, erişim sınırları ve gerekli güvenlik tedbirleri değerlendirilmelidir.
Bazı ilişkilerde ayrıca veri işleme anlaşması (Data Processing Agreement – DPA) hazırlanması gerekli veya uygun olabilir.
Geliştirici ekip yapay zekâ ile kod veya görsel üretebilir mi?
Sözleşme kapsamında üretken yapay zekâ araçlarının kullanımı tamamen yasaklanabileceği gibi belirli koşullara bağlanabilir.
Örneğin:
Hangi yapay zekâ araçlarının kullanılabileceği,
Müşterinin gizli bilgilerinin dış sistemlere aktarılıp aktarılamayacağı,
Üretilen içeriğin hukuki kullanım sınırları,
Üçüncü taraf fikri hak risklerinin nasıl yönetileceği,
Kullanılan araçların ve lisansların nasıl belgeleneceği
düzenlenebilir.
Yapay zekâ sağlayıcısının ticari kullanım izni vermesi, üretilen her içeriğin otomatik olarak telif korumasından yararlandığı veya üçüncü taraf haklarını ihlal etmediği anlamına gelmez.
15. Örnek Olay: Oyun Şirketi, Üniversiteli Bir Ekibe Oyun Geliştirtiyor
Bir oyun yayıncılık şirketinin yeni bir mobil oyun fikri geliştirdiğini düşünelim.
Şirket, geliştirme sürecini dışarıdaki üç kişilik bir ekibe bırakmak istiyor.
Ekipte iki yazılımcı ve bir tasarımcı bulunuyor. Ekip üyelerinin henüz bir şirketi bulunmuyor.
Tarafların görüşmelerinde şu ticari model üzerinde anlaşılmış olsun:
Oyunun fikri ve temel konsepti yayıncı tarafından belirlenecek.
Geliştirme ekibi oynanabilir prototip ve ardından tam sürümü hazırlayacak.
Geliştirme sürecinde belirli milestone ödemeleri yapılacak.
Oyun yayımlandıktan sonra ekibe %15 gelir paylaşımı verilecek.
Oyunun ticari kullanım ve dağıtım haklarının yayıncı şirket tarafından kullanılabilmesi amaçlanacak.
İlk bakışta tarafların temel konularda anlaştığı düşünülebilir.
Ancak hukuki açıdan cevaplanması gereken çok sayıda soru bulunmaktadır.
Birinci sorun: Sözleşmenin tarafı kim olacak?
Ekip üyelerinin şirketi bulunmadığı için sözleşmenin yalnızca ekip adına hareket eden tek kişiyle imzalanması, diğer kişilerin hak ve yükümlülüklerini kendiliğinden düzenlemez.
Bu nedenle ekip üyelerinin sözleşmeye hangi sıfatla taraf olacakları, kimin hangi edimleri üstleneceği ve gerekli fikri hak işlemlerinin kimlerle yapılacağı belirlenmelidir.
İkinci sorun: Oyunun fikri mülkiyet hakları nasıl düzenlenecek?
Yayıncının oyun fikrini geliştirmiş olması, ortaya çıkan bütün korunabilir eser unsurlarının sahibinin mutlaka yayıncı olacağı anlamına gelmez.
Kaynak kodu, tasarımlar ve diğer çalışmalar bakımından hak sahipliği ayrı değerlendirilmelidir.
Yayıncının oyunu farklı platformlarda yayımlaması, güncellemesi ve gerekli durumlarda başka ekiplere geliştirtmesi amaçlanıyorsa buna uygun hak devir veya lisans yapısının kurulması gerekir.
Üçüncü sorun: Milestone ödemelerinin koşulları ne olacak?
Örneğin "Prototip tamamlandığında 5.000 USD ödeme yapılır." hükmü tek başına yeterli olmayabilir.
Prototipin hangi özellikleri taşıması gerektiği, nasıl test edileceği ve eksikliklerin nasıl giderileceği belirlenmelidir.
Dördüncü sorun: %15 revenue share ne üzerinden hesaplanacak?
Oyunun brüt satış gelirleri mi, platform kesintileri sonrası tahsilatlar mı, yoksa sözleşmede tanımlanan diğer giderlerin düşülmesinden sonraki gelirler mi esas alınacak?
Ayrıca gelir paylaşımının ne kadar süre devam edeceği ve oyunun sonraki sürümlerini kapsayıp kapsamayacağı değerlendirilmelidir.
Beşinci sorun: Ekip oyunu tamamlamazsa ne olacak?
Yayıncının tamamlanan çalışmalar üzerindeki kullanım yetkisi, ödenmiş milestone tutarları, kaynak kod teslimi ve projeye başka bir ekiple devam edilmesi ayrı düzenlenmelidir.
Altıncı sorun: Ekip sonradan şirket kurarsa sözleşme nasıl devam edecek?
Sözleşmenin taraflarının değişmesi, borçların üstlenilmesi veya sözleşmenin devri kendiliğinden gerçekleşen işlemler değildir.
Tarafların hak ve yükümlülüklerinin yeni şirkete hangi hukuki yöntemle aktarılacağı, mevcut sözleşmeler ve ilgili mevzuat çerçevesinde değerlendirilmelidir.
Bu örnekte görüldüğü üzere revenue share ile oyun geliştirme modeli, tek başına gelir oranının belirlenmesinden çok daha kapsamlı bir sözleşme mimarisi gerektirir.
16. Oyun Outsourcing Sözleşmesinde Bulunması Gereken Temel Hükümler
Oyun geliştirme sözleşmelerinde her proje için aynı hükümlerin kullanılması doğru olmayabilir.
Bununla birlikte kapsamlı bir sözleşmede aşağıdaki başlıkların değerlendirilmesi yararlı olacaktır.
1. Taraflar ve sözleşmenin konusu
Hizmetin kim tarafından, hangi hukuki sıfatla ve hangi kapsamda yürütüleceği belirlenmelidir.
2. Teknik şartname ve teslim edilecek çalışmalar
Oyunun özellikleri, platformları, geliştirme aşamaları ve teslim materyalleri tanımlanmalıdır.
3. Proje takvimi ve milestone düzeni
Teslim tarihleri, revizyon süreçleri ve kabul kriterleri kararlaştırılmalıdır.
4. Ücret ve ödeme hükümleri
Sabit ücret, milestone ödeme, avans, revenue share veya hibrit modelin hesaplama yöntemi açık olmalıdır.
5. Fikri mülkiyet hakları
Mevcut ve gelecekte oluşturulacak eserler, mali haklar, lisanslar, Background IP ve üçüncü taraf hakları ayrı değerlendirilmelidir.
6. Alt yükleniciler ve ekip değişiklikleri
Kimlerin projede çalışabileceği, üçüncü kişilerin erişim yetkileri ve gerekli onay mekanizmaları düzenlenmelidir.
7. Teslim, test ve kabul
Hata seviyeleri, inceleme süreleri, düzeltme yükümlülükleri ve kabul sonuçları açıklanmalıdır.
8. Gizlilik ve veri güvenliği
Kaynak kod, ticari sırlar ve kişisel verilere ilişkin yükümlülükler belirlenmelidir.
9. Raporlama ve denetim
Özellikle revenue share modellerinde gelir hesaplarının ve ödeme belgelerinin hangi yöntemle incelenebileceği düzenlenmelidir.
10. Sorumluluk ve tazminat
Sözleşmeye aykırılık, fikri hak ihlalleri, üçüncü taraf talepleri ve sorumluluğun kanunen mümkün sınırları değerlendirilmelidir.
11. Sona erme ve proje devri
Sözleşme sona erdiğinde tamamlanmış çalışmaların, kaynak kodların, hesapların ve belgelerin nasıl teslim edileceği belirlenmelidir.
12. Uygulanacak hukuk ve uyuşmazlık çözümü
Özellikle yabancı geliştirici veya yayıncı bulunan ilişkilerde hukuk seçimi, yetkili merci ve uyuşmazlık çözüm mekanizması ayrıca ele alınmalıdır.
17. Oyun Outsourcing Sözleşmelerinde Sık Yapılan Hatalar
Oyun geliştirme projelerinde hukuki riskler çoğu zaman tarafların kötü niyetinden değil, üzerinde anlaşılmış olduğu düşünülen konuların yazılı ve yeterince açık düzenlenmemesinden kaynaklanabilir.
Özellikle şu hatalara dikkat edilmelidir:
Sözleşmenin yalnızca ekip lideriyle yapılması: Diğer geliştiricilerin fikri hakları ve yükümlülükleri belirsiz kalabilir.
Fikri hakların yalnızca genel bir cümleyle düzenlenmesi: FSEK'in mali haklara ilişkin şekil ve kapsam şartları bakımından sorun doğabilir.
Milestone kriterlerinin yazılmaması: Teslimin tamamlanıp tamamlanmadığı konusunda uyuşmazlık yaşanabilir.
Revenue share oranının tanımsız bırakılması: Gelir paylaşımına esas tutarın hesaplanması tartışmalı hale gelebilir.
Kaynak kodun yalnızca dış ekipte bulunması: Projenin devamlılığı tehlikeye girebilir.
Sözleşmenin sona erme sonuçlarının düzenlenmemesi: Tamamlanan çalışmalar, ödemeler ve erişim yetkileri tartışma konusu olabilir.
Üçüncü taraf lisanslarının kontrol edilmemesi: Oyun piyasaya sürüldüğünde fikri mülkiyet veya lisans uyuşmazlıkları ortaya çıkabilir.
Bu konuları daha geniş bir şirket denetimi çerçevesinde Bir Oyun Stüdyosunun Hukuki Check-Up'ı: Global Pazara Çıkmadan Önce Yapmanız Gerekenler başlıklı yazımda da ele alıyorum.
18. Oyun Outsourcing Sözleşmeleri Hakkında Sık Sorulan Sorular
Oyun geliştirme outsourcing sözleşmesi nedir?
Oyun geliştirme outsourcing sözleşmesi, bir oyunun tamamının veya belirli geliştirme faaliyetlerinin bağımsız kişi ya da ekiplere yaptırılmasına ilişkin hak ve yükümlülükleri düzenleyen sözleşmedir. Hukuki niteliği somut ilişkinin içeriğine göre belirlenir.
Dış ekibe yaptırılan oyunun telif hakları kime aittir?
Hak sahipliği, eseri meydana getiren kişiler, taraflar arasındaki hukuki ilişki ve mevcut sözleşmeler dikkate alınarak belirlenir. Geliştirme bedelinin ödenmesi bütün mali hakların otomatik olarak devredildiği anlamına gelmez.
Oyun geliştirme sözleşmesinde IP devri zorunlu mu?
Her sözleşmede tam mali hak devri zorunlu değildir. Taraflar hukuken mümkün olduğu ölçüde belirli hakların devrini veya lisans verilmesini kararlaştırabilir. Ancak öngörülen ticari kullanım için gerekli yetkilerin sağlanması önemlidir.
Revenue share ile oyun geliştirilebilir mi?
Taraflar sözleşme serbestisinin sınırları içerisinde gelir paylaşımına dayalı geliştirme modelleri oluşturabilir. Ancak gelirin tanımı, paylaşım süresi, ödeme koşulları, fikri haklar ve ilişkinin hukuki niteliği ayrıca düzenlenmelidir.
Revenue share alan geliştirici şirket ortağı olur mu?
Hayır. Yalnızca sözleşmeye dayalı gelir paylaşımı hakkı bulunması, kendiliğinden şirket pay sahipliği veya yönetim hakkı vermez.
Milestone ödemesi nedir?
Milestone ödemesi, proje bedelinin önceden belirlenen geliştirme aşamalarının teslimi veya kabulü gibi koşullara bağlanarak ödenmesidir. Somut sözleşmede ödeme koşulları açıkça düzenlenmelidir.
Geliştirici ekip oyunu tamamlamazsa kaynak kod alınabilir mi?
Kaynak kod teslimine ilişkin sözleşme hükümleri, tamamlanan çalışmalar, ödeme durumu ve uygulanacak kanuni düzenlemeler birlikte değerlendirilmelidir. Dosyalara erişim ile fikri hakların kullanılması birbirinden farklıdır.
Üniversite öğrencileriyle oyun geliştirme sözleşmesi yapılabilir mi?
Üniversite öğrencisi olmak tek başına sözleşme kurulmasına engel değildir. Ancak kişilerin fiil ehliyeti, sözleşmenin tarafları, fiilen kurulan çalışma ilişkisi, vergi ve sosyal güvenlik yükümlülükleri ayrıca değerlendirilmelidir.
Oyun geliştirme ekibinin şirket kurması zorunlu mu?
Her durumda değil. Ancak faaliyetin ticari niteliği, sürekliliği, vergisel sonuçları ve tarafların ilişkisi dikkate alınarak uygun hukuki yapı belirlenmelidir.
Dış geliştirici ekibin başka projelerde çalışması engellenebilir mi?
Sözleşmesel sınırlamalar düzenlenmesi mümkün olabilir. Ancak bunların geçerliliği, ilişkinin niteliğine, kapsamına ve uygulanabilir emredici hükümlere bağlıdır.
Oyun geliştirici sözleşmesi İngilizce hazırlanabilir mi?
Tarafların niteliğine, sözleşmenin konusuna ve uygulanabilir dil zorunluluklarına göre değerlendirme yapılmalıdır. Özellikle Türkiye'deki tarafların işlemleri bakımından 805 sayılı Kanun'un uygulanabilirliği ayrıca incelenmelidir.
Oyun outsourcing sözleşmesi ile publisher sözleşmesi birlikte yapılabilir mi?
Evet. Ancak iki sözleşmenin fikri mülkiyet, gelir paylaşımı, teslim, lisans ve fesih hükümleri arasında çelişki bulunmamasına dikkat edilmelidir.
Sonuç: Oyun Geliştirme Sözleşmesinde Yalnızca Ücret Değil, Hak Sahipliği ve Projenin Devamlılığı da Düzenlenmelidir
Oyun geliştirme faaliyetlerinin dış ekiplere bırakılması, oyun şirketleri bakımından teknik kapasiteyi artıran ve farklı ticari modellerin kurulmasını sağlayan bir yöntem olabilir.
Ancak outsourcing ilişkisinde fikri mülkiyet haklarının, teslim kriterlerinin, ödeme modellerinin ve sözleşmenin sona ermesinin yeterince açık düzenlenmemesi, projenin ileri aşamalarında ciddi uyuşmazlıklara neden olabilir.
Özellikle milestone ve revenue share modellerinin birlikte kullanıldığı projelerde tarafların geliştirme yükümlülükleri ile oyunun ticari gelirinden doğan hakları birbirinden ayrılmalıdır.
Ayrıca geliştirici ekibin ürettiği kodların ve görsel içeriklerin hangi haklarla kullanılabileceği, projeye başka bir ekibin devam edip edemeyeceği ve yayıncılarla yapılacak sonraki sözleşmeler için gerekli yetkilerin mevcut olup olmadığı değerlendirilmelidir.
Oyun outsourcing sözleşmesinde temel amaç yalnızca oyunun tamamlanmasını sağlamak değil; geliştirme sürecindeki hakların, yükümlülüklerin ve ticari risklerin öngörülebilir bir hukuki yapıya kavuşturulmasıdır.
Hukuki Dayanaklar ve Kaynaklar
5846 sayılı Fikir ve Sanat Eserleri Kanunu; özellikle m.8, m.18, m.21–25, m.48, m.50 ve m.52.
6098 sayılı Türk Borçlar Kanunu; özellikle m.26, m.27, m.112, m.117, m.470–478 ve m.484.
6102 sayılı Türk Ticaret Kanunu; özellikle ticari faaliyetler, şirketler ve ticari kayıtların tutulmasına ilişkin hükümler.
6698 sayılı Kişisel Verilerin Korunması Kanunu.
5718 sayılı Milletlerarası Özel Hukuk ve Usul Hukuku Hakkında Kanun.
805 sayılı İktisadi Müesseselerde Mecburi Türkçe Kullanılması Hakkında Kanun.
Av. Şenay Yağmur Efe
Oyun geliştirme süreçleri, yazılım ve teknoloji sözleşmeleri, fikri mülkiyet hakları, şirketleşme ve startup yatırımlarının hukuki boyutları üzerine çalışmalar yürütmektedir.
Bu makale genel hukuki bilgilendirme amacıyla hazırlanmıştır. Oyun geliştirme sözleşmelerinin hukuki niteliği ve sonuçları, tarafların ilişkisi, sözleşme hükümleri ve uygulanacak mevzuat dikkate alınarak somut olay özelinde değerlendirilmelidir.
