Yazılımda hak sahipliği ve lisanslama: Kod, çalışan, yüklenici ve açık kaynak zinciri

Ürün kararından hak zincirine

Bir yazılımın ticari değeri, çalışan ürünle birlikte o ürünü geliştirme, müşteriye sunma, değiştirme ve devretme yetkisine dayanır. Bu rehber, Türkiye hukuku bakımından kodun korunmasından çalışan ve yüklenici katkılarına, geliştirme sözleşmesinden lisans ve açık kaynak kullanımına kadar bu yetkinin nasıl kurulduğunu açıklar. Hedef okuyucu; yazılım şirketinin yöneticisi, kurucusu, satın alma ekibi, kurumsal müşteri ve yatırımcıdır. Temel işlem sonucu, piyasaya çıkan sürüm ile onu destekleyen sözleşme ve izinlerin eşleşmesidir.

İnceleme tarihi 22 Ekim 2026'dır. Rehber yeni bir kanunun duyurusu olarak değil, yürürlükteki Fikir ve Sanat Eserleri Kanunu, Türk Borçlar Kanunu ve ilgili koruma rejimlerinin ürünün yaşam döngüsüne uygulanması için hazırlanmıştır. Açık kaynak bakımından lisansın belirtilen sürümü esas alınır; yurt dışına lisanslama veya dağıtımda hedef ülkenin kuralları ayrıca incelenmelidir. Her soru, hukuki dayanağı ve somut sözleşme sonucuyla birlikte okunabilir.

1. Yazılımda hangi unsurlar telif hakkıyla korunur?

Yazılımda koruma, sahibinin hususiyetini taşıyan somut ifade üzerinde kurulur. 5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK) m. 1/B ve m. 2/1-1, her biçimde ifade edilen bilgisayar programlarını ve sonraki aşamada program sonucu doğurması koşuluyla hazırlık tasarımlarını ilim ve edebiyat eserleri arasında sayar. Kaynak kodu ile nesne kodu bu incelemenin merkezindedir. Programın herhangi bir unsuruna, arayüz dahil, temel oluşturan düşünce ve ilkeler ise m. 2 uyarınca eser sayılmaz. Dolayısıyla aynı müşteri ihtiyacını karşılayan iki ürünün benzer işlevleri bulunması ile korunan kodun veya tasarım ifadesinin çoğaltılması farklı hukuki sorulardır. FSEK m. 1/B, 2

Ürün dosyası bu ayrımı bileşenler üzerinden göstermelidir. Teknik dokümantasyon, grafikler ve ekran tasarımları kendi eser niteliği şartlarıyla; veritabanının seçme ve düzenleme yapısı ise m. 6/11 kapsamında ayrıca incelenir. Veritabanının derleme olarak korunması, içerdiği her veri üzerinde telif hakkı sağlamaz. Mevcut bir programın uyarlanması veya değiştirilmesi bakımından m. 6/10 ve asıl eser üzerindeki haklar da dikkate alınır. Bu nedenle yeni kod yazılmış olması, dayanak programın kullanım ve değiştirme izinlerini inceleme ihtiyacını ortadan kaldırmaz. FSEK m. 4, 6

Yatırım veya lisans işleminde ilk çalışma, ürün adının yanına tek bir hak sahibi yazmak yerine korunan çıktıları, bunların geliştiricilerini ve kullanılan dış bileşenleri eşleştirmektir. Depo geçmişi, tasarım dosyaları, sürüm tarihleri ve teslim kayıtları bu eşleştirmenin delilini oluşturur. Böylece bir ihlal iddiasında hangi ifadenin kopyalandığı, bir satışta hangi mali hakların devredilebildiği ve hangi bileşenlerin mevcut lisanslarıyla kullanılacağı somutlaşır.

2. Yazılımın kayıt ve tescili ile geliştirme kayıtları hangi delil işlevini görür?

Eser niteliği taşıyan yazılımda koruma kayıt ve tescille kurulmaz; kayıt işlemi hak sahipliğinin belirlenmesinde ispat kolaylığı ve mali haklardan yararlanma yetkilerinin takibi için kullanılır. FSEK m. 13, korunan eserlerin talep üzerine kayıt ve tesciline imkan verir; başvurunun beyana dayanmasını ve Bakanlığın bu beyanlardan sorumlu tutulamamasını da düzenler. Fikir ve Sanat Eserlerinin Kayıt ve Tescili Hakkında Yönetmelik m. 1 ve m. 4/ğ aynı ispat işlevini tanımlar. Dolayısıyla kayıt belgesi, kapsamı belirlenmiş bir eserin belirli kişi tarafından kayıt işlemine konu edildiğini gösteren hukuki dosyanın parçasıdır. FSEK m. 13; Kayıt ve Tescil Yönetmeliği m. 1, 4

Delil dosyası kayıt belgesindeki eserle piyasaya çıkan sürümü ilişkilendirmelidir. Depo geçmişi, katkı sahiplerinin kimliği, görev kartları, tasarım belgeleri, teslim ve kabul kayıtları birlikte korunur. Bir commit kaydı, belirli hesap üzerinden depoya kaydedilen değişikliğin izini verir; hesabın gerçek kullanıcıya aidiyeti, önceki kodun kaynağı ve kayıt geçmişinin bütünlüğü ayrıca araştırılabilir. Dosya özeti ve zaman damgası ise kullanılan sistemin niteliğine göre içerik bütünlüğü ve zaman bakımından destek sağlar. Bunların teknik işlevi, kodun eser niteliği ile eser sahipliği ve mali hak yetkisinin hukuki değerlendirmesinden ayrı tutulmalıdır.

Yatırım incelemesinde veya uyuşmazlık hazırlığında her önemli sürüm için başvuruya verilen örnek, kaynak kodu arşivi ve sözleşme ekindeki eser tanımı eşleştirilmelidir. Kimin neyi hangi tarihte ürettiği ile şirketin o çıktıyı hangi yetkiyle kullandığı iki ayrı delil sorusudur. Bu nedenle teknik kayıtlar, çalışan görevi veya geçerli devir ve ruhsat belgeleriyle tamamlanmalıdır. Kayıt-tescil belgesine veya zaman kaydına, eser sahipliği uyuşmazlığını otomatik çözen ya da bütün ispat yükünü karşı tarafa geçiren sonuç yüklenmemesi, dava ve işlem stratejisinin doğru belgeye dayanmasını sağlar.

3. Çalışanın geliştirdiği kod üzerindeki hakları işveren hangi koşullarda kullanır?

Çalışanın işini görürken oluşturduğu yazılımda eser sahipliği ile mali hakları kullanma yetkisi ayrılır. FSEK m. 8 eseri meydana getireni eser sahibi olarak belirler; m. 18/2 ise özel sözleşmeden veya işin niteliğinden aksi anlaşılmadıkça, memur, hizmetli ve işçilerin işlerini görürken meydana getirdikleri eserler üzerindeki mali hakların çalıştıran veya tayin eden tarafından kullanılmasını sağlar. Bu düzenleme, koşulları gerçekleştiğinde işverenin ayrıca bir devir belgesi almadan dayanabileceği kanuni kullanım yetkisinin temelidir. Yetkinin konusu, çalışanın görevini yerine getirirken ürettiği eserdir. FSEK m. 8, 18

Somut kapsamı iş sözleşmesi, görev tanımı, proje görevlendirmeleri ve geliştirme kayıtları belirler. Aynı kişinin işe girmeden önce geliştirdiği kütüphane, işverene sunduğu yan proje ve görevi kapsamında yazdığı ürün modülü ayrı değerlendirilmelidir. Evden veya mesai saatleri dışında yazılan kodun durumu da yalnız saat ve cihaz üzerinden çözülemez; üretimin görevle bağlantısı incelenir. İş ilişkisinin sona ermesi sonrasındaki yeni geliştirmeler ile önceden tamamlanmış sürümlere ilişkin yetki de ayrı kayda geçirilmelidir.

Bu nedenle iş sözleşmesi ekinde görev kapsamı, önceden mevcut eserler ve bunların ürüne katılma izinleri açıklanmalı; proje kayıtları hangi sürümün bu kapsamda üretildiğini göstermelidir. Eser sahibinin adının belirtilmesi ve eserde değişiklik yapılması gibi manevi haklarla ilgili kullanım düzeni ayrıca ele alınır. FSEK m. 14-16 kapsamında değerlendirilmesi gereken bu alan, mali hak devri başlığı altındaki genel bir cümleyle kapatılmamalıdır. Ayrılma sürecinde kaynak kodu, erişimler ve teknik belgelerin teslimi de hak yetkisini işletilebilir hale getirir. FSEK m. 14-16

4. Kurucunun veya şirket ortağının yazdığı kod şirkete nasıl kazandırılır?

Kurucu veya ortak tarafından geliştirilen yazılımda, şirketin hakları kişinin hangi sıfatla ve ne zaman üretim yaptığına göre belirlenir. Şirket kurulmadan önce oluşturulan kod ile kuruluş sonrasında şirket görevi kapsamında geliştirilen kod aynı hukuki temele bağlanamaz. FSEK m. 18/2, çalışanlar yanında tüzel kişilerin organları hakkında da uygulanır. Bu nedenle şirket organı sıfatıyla görevini yerine getirirken yazılım üreten kişinin konumu değerlendirilirken bu hüküm mutlaka incelenmelidir; yalnız pay sahipliği ise üretimin organ görevi kapsamında gerçekleştiğini göstermez. FSEK m. 8, 18/2

Kuruluş öncesi ürün çekirdeği, kurucunun başka müşterileri için geliştirdiği araçlar ve şirkete özgü yeni modüller ayrı bir envantere bağlanmalıdır. Şirketin bunlardan hangisini devralacağı, hangisini lisansla kullanacağı ve kurucunun hangi genel araçlarını kullanmaya devam edeceği sözleşmede gösterilir. Mevcut eserler üzerindeki mali hak tasarrufu FSEK m. 48 ve m. 52'ye uygun kurulmalıdır. Kurucunun kodu önceki bir işverende veya müşteriye verilen bir proje kapsamında geliştirmiş olması halinde, onun imzasından önce önceki ilişkinin hak düzeni araştırılır. FSEK m. 48, 52, 54

Yatırım öncesinde kurucu beyanının somut eser ve sürüm listesiyle desteklenmesi, eksik devirlerin kapanış koşulu yapılması uygun olur. Kurucunun şirketten ayrılması, mevcut müşterilere verilen izinleri ve şirketin ürün geliştirme planını etkileyebileceği için devam eden lisansın süresi, değişiklik yapma yetkisi ve sonraki devir izinleri önceden belirlenmelidir. Böylece pay devri belgesiyle yazılım üzerindeki mali hak tasarrufu arasındaki bağlantı kurulmuş ve farklı hukuki işlemlerin kapsamı belgelenmiş olur.

5. Ajansa veya bağımsız geliştiriciye ödeme yapılması hangi hakları sağlar?

Bağımsız geliştiriciye veya ajansa sipariş verilmesi halinde müşterinin kullanım ve devir yetkisi, teslim edilen eser ve sözleşmede kurulan hak düzeni üzerinden belirlenir. FSEK m. 18/2'deki işveren yetkisi bağımsız yüklenici ilişkisine doğrudan taşınamaz. Mevcut yazılım üzerindeki mali hakkın devri veya kullanım ruhsatı m. 48'e; bu işlemin yazılı ve hakları ayrı ayrı gösteren biçimde kurulması m. 52'ye tabidir. Kod nüshasının mülkiyetinin devri ile fikri hakların devri arasındaki ayrım da m. 57'de düzenlenir. Bedel, fatura ve teslim, sözleşmenin ifasını kanıtlayabilir; hak kapsamı ayrıca bu kurallara göre kurulmalıdır. FSEK m. 18, 48, 52, 57

Ajansın kendi çalışanları ve bağımsız alt yüklenicileri yönünden ayrı bir hak zinciri vardır. Ajans çalışanının görev kapsamında oluşturduğu kod için m. 18/2 incelenirken bağımsız alt yüklenicinin katkısında sözleşmesel yetki araştırılır. Ajansın daha önce devraldığı bir hakkı veya ruhsatı müşteriye aktarmasında m. 49'un eser sahibi veya mirasçılarının yazılı muvafakatine ilişkin koşulu gözetilir. Müşteriye verilen kapsamlı bir garanti, ajansın sahip olmadığı hakkı kazandırmaz; m. 54, yetkisiz kişiden iyi niyetle iktisabı dahi korumaz. FSEK m. 49, 54

Sözleşmede müşteriye özgü çıktılar, yüklenicinin önceden mevcut araçları ve üçüncü kişi bileşenleri ayrılmalıdır. Müşteri ürünü başka bir geliştiriciye bakım için verecekse kaynak koduna erişim, değiştirme ve bu çalışma için gerekli izinler açıkça karşılanmalıdır. Teslim paketi de yalnız çalışan uygulamadan oluşmamalı; kararlaştırılan kaynak kodu, derleme bilgisi, bileşen lisansları ve hak zincirini doğrulayan belgeleri içermelidir. Bu kapsamın teslim ve ödeme aşamalarıyla eşleştirilmesi, eksik yetkinin ürün yayına çıktıktan sonra fark edilmesi riskini azaltır.

6. Ortak geliştiriciler ve manevi haklar yazılımın kullanımını nasıl etkiler?

Birden çok kişinin geliştirdiği yazılımda önce katkıların hukuki niteliği belirlenir. FSEK m. 9 uyarınca ayrı parçalara bölünebilen eserde her kişi kendi kısmının sahibidir; aksi kararlaştırılmadıkça bütün eserin değiştirilmesi veya yayımlanması için diğerlerinin katılımı istenebilir ve haklı sebep olmaksızın katılmayan kişi bakımından mahkemeden izin alınabilir. Mali hakların kullanılmasında da aynı düzen uygulanır. Katkılar ayrılmaz bir bütün oluşturuyorsa m. 10'daki eser sahipleri birliği ve adi şirket hükümleri gündeme gelir; salt teknik hizmet ve ayrıntı yardımı ortak eser sahipliği kurmaz. Aynı maddenin son fıkrası, sözleşme, hizmet koşulları veya eser yaratılırken yürürlükte olan kanun aksini öngörmüyorsa, bu ayrılmaz bütün üzerindeki hakların eser sahiplerini bir araya getiren gerçek veya tüzel kişi tarafından kullanılmasını düzenler. Bu nedenle ekip çalışmasında yetki yalnız imza sayılarak belirlenemez. FSEK m. 9-10

Mali hak düzeni kurulduktan sonra eserin kamuya sunulması, geliştiricinin adının belirtilmesi ve yazılımda değişiklik yapılması bakımından manevi haklar incelenir. FSEK m. 14, kamuya sunma ve yayımlama zaman ve biçimine; m. 15, ad veya takma adla ya da adsız sunuma; m. 16 ise eserde veya eser sahibinin adında yapılacak değişikliklere ilişkin yetkileri düzenler. Kanun veya eser sahibinin izniyle işleyen, çoğaltan veya yayan kişinin ilgili tekniğin zorunlu kıldığı değişiklikler için özel izin aranmayan alanı m. 16/2'de ayrıca korunur. İzin düzeni ürünün sürüm çıkarması, bakım görmesi ve müşteri için uyarlanması gibi somut kullanım ihtiyaçlarına bağlanmalıdır. FSEK m. 14-16

Sözleşmede genel bir manevi hak devri veya bütün itirazlardan feragat yerine hangi sürümün nasıl yayımlanacağı, adlandırma tercihi ve izin verilen değişikliklerin kapsamı açıklanmalıdır. Bu izinlerin sınırı da kanunda belirlenmiştir: m. 14/3, şeref ve itibarı zedeleyen kamuya sunma veya yayımlamayı; m. 16/3 ise şeref ve itibarı zedeleyen yahut eserin nitelik ve özelliklerini bozan değişiklikleri önleme yetkisinden vazgeçmeyi geçersiz sayar. Yazılı ve kapsamlı izin alınmış olması da bu korumayı kaldırmaz. Bu nedenle ürünün normal bakımını mümkün kılan izinler somutlaştırılırken, vazgeçilemez men yetkisini ortadan kaldırdığını ileri süren hükümler kullanılmamalıdır. FSEK m. 14/3, 16/3

7. Henüz yazılmamış kod ve gelecek sürümler için geçerli hak düzeni nasıl kurulur?

Gelecekte geliştirilecek yazılım için önce hak devri veya ruhsat verme taahhüdü, eser tamamlandığında da buna uygun mali hak tasarrufu kurulmalıdır. FSEK m. 48/3 henüz oluşturulmamış veya tamamlanacak eser üzerindeki doğrudan tasarrufu geçersiz sayarken, m. 50/1 bu tasarruflara ilişkin taahhütlerin eser oluşmadan önce yapılmasına imkan verir. Ayrım, geliştirme sözleşmesinin yapılabilmesi ile henüz mevcut olmayan eser üzerindeki hakkın o anda geçirilmesi arasındadır. Sözleşme, mevcut ürün çekirdeği ile sonraki geliştirmeler bakımından farklı hükümler kurabilir. FSEK m. 48, 50

Uygulamada siparişin konusu, teslim ölçütleri ve ileride devredilecek mali haklar başlangıçta belirlenir; tamamlanan sürüm, depo etiketi veya teslim listesindeki belirlenebilir eserlerle ilişkilendirilerek yazılı tasarrufa bağlanır. Bu ikinci belgenin kabul tutanağıyla birlikte düzenlenmesi yararlı bir işlem kurgusudur; kanunun her yazılım teslimi için belirlediği özel adlı bir tutanak zorunluluğu değildir. Teknik kabulün hangi tarihte gerçekleştiği ile mali hakkın hangi şartta devredildiği sözleşmede ayrılmalı; kabul tartışmasının devir kapsamını belirsiz bırakması önlenmelidir.

Bütün gelecek eserleri veya belirli bir türdeki gelecek eserlerin tamamını kapsayan uzun süreli taahhütlerde FSEK m. 50/2 ayrıca önem taşır: taraflardan her biri, ihbardan bir yıl sonra sonuç doğurmak üzere bu kapsamdaki taahhüdü feshedebilir. Bu bir yıllık düzenleme bütün yazılım sözleşmelerinin genel fesih süresi olarak uygulanamaz. Aynı maddenin eser tamamlanmadan önce ölüm, tamamlama kabiliyetinin kaybı, kusursuz imkansızlık ve karşı tarafın iflası gibi durumlara ilişkin sona erme hükümleri de sürekli geliştirme ilişkisinin devam planında dikkate alınmalıdır. FSEK m. 50

8. Mali hak devri hangi içerik ve belgelerle güvenilir hale gelir?

Geçerli bir mali hak düzeninde hem yazılı şekil hem de sözleşmeye konu hakların ayrı ayrı gösterilmesi gerekir. FSEK m. 52 bu iki koşulu birlikte arar. Yazılım bakımından m. 21-25'teki işleme, çoğaltma, yayma, temsil ve umuma iletim hakları, işlemin ihtiyacına göre ayrı ayrı ele alınır; devir mi ruhsat mı kurulduğu, süre, ülke ve kullanım kapsamı belirlenir. Mevcut bir hakkın belirli teknolojiyle kullanılması ile ileride çıkarılacak mevzuatın yaratabileceği yeni mali haklar da ayrılmalıdır: m. 51, ikinci gruptaki hakların devrine veya kullanımına ilişkin sözleşmeleri geçersiz sayar. FSEK m. 21-25, 48, 51-52

Yetki incelemesi imza yetkilisi kontrolünden daha geniştir. İmzalayan şirketin hangi gerçek kişinin eserine hangi hukuki temelle dayanabildiği, önceki devir ve ruhsatların kapsamı, m. 49 kapsamındaki yazılı muvafakat ve önceki münhasır düzenlemeler araştırılır. FSEK m. 54 gereği devredenin yetkisi bulunmuyorsa alıcının iyi niyeti hak kazanımını korumaz. Aynı madde yetkisiz tasarruftan doğan zarar bakımından devredenin sorumluluğunu, karşı tarafın yetkisizliği bilmesi veya bilmesinin gerekmesi istisnasıyla düzenler. Bu nedenle tazminat güvencesi ile ürünün kullanılmasını sağlayan gerçek yetki ayrı değerlendirilmelidir. FSEK m. 49, 54

İnceleme sonunda eser veya sürüm listesi, katkı sahibi, iş ilişkisi ya da devir dayanağı, devredilen haklar ve sonraki kullanım izinleri birbirine bağlanmalıdır. Eksiklik saptanırsa doğru hak sahibinden tamamlayıcı tasarruf veya gerekli muvafakat alınması; giderilemeyen bileşenin değiştirilmesi ya da işlem kapsamından çıkarılması seçenekleri tartışılır. Özellikle varlık satışında müşterilere lisans vermeye ve başka bir şirkete aktarmaya elverişli kapsam kapanıştan önce kurulmalıdır. Bu belgelerle teknik depo kayıtlarının aynı sürümü göstermesi, sözleşmedeki hak kapsamını gerçekten teslim edilen ürüne bağlar.

9. Yazılım lisansının kapsamı ve münhasırlığı nasıl belirlenir?

Lisans, yazılım üzerindeki belirli mali hakların kararlaştırılan kapsamda kullanılmasına izin verir; hak devrinde ise sözleşmede belirlenen mali haklar devralanın malvarlığına geçer. FSEK m. 48 bu iki işlem biçimini ayırır; m. 52 mali haklara ilişkin sözleşme ve tasarrufların yazılı olmasını ve hakların ayrı ayrı gösterilmesini arar. Bu nedenle kurulum ve çalıştırma, uyarlama, çoğaltma, dağıtım veya müşteriye erişim sağlama yetkilerinden hangilerinin verildiği, ürünün gerçek kullanım biçimi esas alınarak yazılmalıdır. Kaynak koduna erişim ve kodu değiştirme yetkisi de ayrıca tanımlanmalıdır. FSEK m. 48 ve 52

Münhasırlık, kapsamı yazılmadığında tarafların farklı beklentiler geliştirdiği başlıca alandır. FSEK m. 56, ruhsatın başkalarına da verilebildiği basit ruhsat ile yalnız bir kişiye mahsus tam ruhsatı ayırır; kanun veya sözleşmeden aksi anlaşılmadıkça ruhsat basit sayılır. Belirli bir sektör veya ülke için münhasırlık veriliyorsa geliştiricinin kendi kullanımının, mevcut müşterilerinin, grup şirketlerinin ve sonraki sürümlerin durumu sözleşmede çözülmelidir. Müşteriye özgü bir eklenti üzerindeki münhasırlığın genel ürün platformuna taşması, yazılım şirketinin sonraki satışlarını sınırlayabilir. FSEK m. 56

Ticari ölçüler de hukuki kapsamla eşleştirilmelidir: adlandırılmış kullanıcı, eşzamanlı kullanıcı, cihaz, işlem hacmi, ortam veya tüzel kişi esaslı ücretlendirme farklı kullanım sınırları yaratır. Test, felaket kurtarma ve dış hizmet sağlayıcı kullanımları ile şirket birleşmesi, varlık devri ve alt lisans ihtiyacı baştan kararlaştırılmalıdır. FSEK m. 49 bakımından devralınan mali hakkın veya ruhsatın yeniden aktarılmasında eser sahibinin yazılı muvafakati meselesi ayrıca kontrol edilir. Bu nedenle lisans verenin zincirde sahip olduğu yetki ile müşteriye vaat ettiği devredilebilirlik aynı inceleme tablosunda karşılaştırılmalıdır. FSEK m. 49

10. SaaS aboneliği ile kurulum lisansı sözleşmede nasıl ayrılır?

SaaS modelinde müşteri, sağlayıcının işlettiği uygulamaya belirli süre ve koşullarla erişir; müşterinin kendi ortamına kurduğu modelde ise program kopyasının kullanımı ve bu kullanım için gerekli mali hak izinleri öne çıkar. Sözleşmenin adı yerine kodun nerede çalıştığı, müşteriye hangi kopyaların verildiği ve tarafların hangi işlemleri yaptığı esas alınmalıdır. FSEK m. 22, programın yüklenmesi, görüntülenmesi, çalıştırılması, iletilmesi ve depolanmasının gerektirdiği geçici çoğaltmaları da çoğaltma hakkı kapsamında ele alır. Tarayıcıya indirilen bileşen, masaüstü istemci veya müşteriye teslim edilen konteyner bu nedenle ayrıca incelenmelidir. FSEK m. 22

Hizmet sözleşmesi erişim süresi, kapasite, kullanılabilirlik ölçümü, planlı bakım, destek ve güvenlik yükümlülüklerini somutlaştırmalıdır. Örneğin hizmet seviyesi hesabında kesintinin başlangıç ve bitişi, müşterinin bildirim yükümlülüğü, ölçüm kaynağı ve telafi yöntemi belirlenmelidir. Bunlar işlem için önerilen sözleşme hükümleridir; her SaaS için kanunun belirlediği tek bir hizmet seviyesi bulunuyormuş gibi sunulmamalıdır. Müşterinin sağladığı veriler, sağlayıcının genel yazılımı ve müşteriye özel geliştirmeler ayrı hak kategorileri olarak düzenlenirse abonelik bedeliyle hangi menfaatin edinildiği anlaşılır hale gelir.

Çıkış düzeni, abonelik kurulurken kararlaştırılmalıdır. Veri dışa aktarımının biçimi ve süresi, geçiş desteği, ücretler, yedeklerin saklanması ve erişimin kapatılması birbirine bağlanmalıdır. Süreli erişim taahhüdüyle süresiz kullanım beklentisi aynı sipariş formunda bırakılmamalıdır. Sağlayıcının hizmeti durdurması halinde iş sürekliliği isteyen müşteri için yedek hizmet, veri kurtarma veya kaynak kodu emaneti farklı çözümler sunar; seçilen çözüm teknik olarak denenmeli ve gerekli üçüncü kişi izinleriyle tamamlanmalıdır.

11. Geliştirilen yazılımda teslim, kabul ve ayıp sorumluluğu nasıl düzenlenir?

Belirli özellikleri taşıyan bir yazılım sonucunun bedel karşılığı meydana getirilmesi üstlenilmişse, ilişkinin içeriğine göre TBK m. 470 ve devamındaki eser sözleşmesi hükümleri gündeme gelebilir. Sürekli erişim, işletim, bakım ve danışmanlık içeren SaaS veya karma sözleşmelerde ise her edim kendi niteliğiyle incelenmelidir. FSEK bakımından eser korumasına elverişlilik ile TBK bakımından eser sözleşmesinin varlığı farklı hukuki sorulardır. Bu nedenle teslim yükümlülüğü; çalışır sürüm, fonksiyonlar, entegrasyonlar, performans ölçütleri ve dokümantasyon üzerinden kurulmalı; sonradan istenen yeni geliştirmeler için değişiklik yönetimi düzenlenmelidir. TBK m. 470

Eser hükümlerinin uygulandığı ilişkide TBK m. 474, teslim sonrasında olağan akışta imkan bulunur bulunmaz inceleme ve ayıpların uygun sürede bildirilmesini ister. Sözleşmedeki kabul testi bu incelemeyi uygulanabilir kılmalıdır: test verisi ve ortamı, beklenen sonuç, hata sınıfları, yeniden test ve kabul tutanağı belirlenebilir. Müşterinin canlı kullanıma geçmesiyle kabulün ilişkisi de düzenlenmelidir. TBK m. 477 uyarınca inceleme ve bildirimin ihmal edilmesi kabul sonucu doğurabilir; sonradan ortaya çıkan ayıp gecikmeksizin bildirilmelidir. Kasten gizlenen veya usulüne uygun incelemede fark edilemeyen ayıplara ilişkin sorumluluğun sürmesi, açık kabulün sonuçlarıyla birlikte dikkate alınmalıdır. TBK m. 474 ve 477

Yüklenicinin sorumlu olduğu ayıplarda TBK m. 475, koşullarına göre sözleşmeden dönme, ayıp oranında bedel indirimi veya aşırı masraf gerektirmeyen ücretsiz onarım seçeneklerini düzenler; genel hükümlere göre tazminat talebi saklıdır. Dönme için ayıbın kullanılamama veya hakkaniyet gereği kabule zorlanamama düzeyine ulaşması gerekir. TBK m. 476 bakımından, yüklenicinin açık uyarısına rağmen verilen müşteri talimatından doğan veya müşteriye yüklenebilen ayıplar da ayrıca incelenir. Bu yüzden hata kayıtları, müşteri gereksinimleri, uyarılar ve sürüm değişiklikleri; teknik arızanın nedeni ile seçilen hukuki talep arasındaki bağı kuracak biçimde saklanmalıdır. TBK m. 475–476

TBK m. 478 kapsamındaki ayıplı eser davalarında süre teslimle başlar. Eser sözleşmesine konu, taşınmaz yapı dışındaki bir yazılım tesliminde iki yıllık zamanaşımı; yüklenicinin ağır kusuru varsa eserin niteliğine bakılmaksızın yirmi yıllık süre dikkate alınır. Bu süreler bütün yazılım, lisans veya SaaS taleplerine topluca uygulanamaz; talebin dayanağı ve sözleşmenin niteliği belirlenmelidir. Ayrıca zamanaşımı, inceleme ve ayıp bildirim yükümlülüğünden farklıdır: müşteri iki yıllık süreyi bekleyerek bildirimini ertelememelidir. Sözleşmedeki garanti veya destek süresi de bu ayrı hukuki takvimlerle karşılaştırılmalıdır. TBK m. 478

12. MIT, Apache, GPL ve AGPL bileşenleri ticari üründe hangi yükümlülükleri doğurur?

Açık kaynak bileşen incelemesi, kullanılan sürümün lisansını ve ürün içindeki işlevini eşleştirir. MIT, geniş kullanım ve ticari dağıtım iznini telif ve izin bildirimlerinin korunmasına bağlar. Apache-2.0; lisans kopyası, değişiklik ve atıf bildirimleri ile varsa NOTICE koşullarını düzenler; ayrıca kapsamı tanımlı patent lisansı ve belirli patent davalarında sona erme hükmü içerir. Bu nedenle dağıtılan paketin bildirim dosyaları lisans envanteriyle karşılaştırılmalıdır. MIT lisans metni; Apache-2.0, bölümler 2–4

GPLv3 kapsamında program kopyasının aktarılması, lisansın 5 ve 6. bölümlerindeki kaynak ve lisans koşullarını gündeme getirir. Kopya aktarımı olmaksızın ağ etkileşimi ise 0. bölümde aktarım dışında bırakılmıştır. AGPLv3 m. 13, program değiştirilmişse bu sürümle ağ üzerinden etkileşen kullanıcılara ilgili kaynak kodunu edinme fırsatı sunulmasını ayrıca ister. Dolayısıyla müşteriye kurulan sürüm ile sunucuda hizmet olarak sunulan sürüm ayrı değerlendirilir. GPLv3, bölümler 0, 5–6; AGPLv3, bölüm 13

Bir bileşenin etkisini yalnız paket adına göre belirlemek teknik incelemeyi eksik bırakır. İncelemede doğrudan ve dolaylı bağımlılıklar, değiştirilen dosyalar, bağlama ve iletişim biçimi, dağıtılan istemci parçaları ve lisans istisnaları izlenmelidir. Kaynak sunma kapsamına ilişkin sonuç, gerçek lisans metniyle ürün mimarisinin birlikte incelenmesinden çıkarılmalıdır. SBOM veya otomatik tarama bu çalışmanın envanterini sağlar; hukuki sınıflandırma için geliştiricinin bileşeni nasıl kullandığı da açıklanmalıdır. Uyum sağlanamayan bağımlılık için sürüm öncesinde değiştirme, ayrı ticari lisans edinme veya mimariyi yeniden kurma seçeneklerinden uygulanabilir olanı seçilmelidir.

13. Yasal kullanıcı hata düzeltme, yedekleme ve birlikte çalışabilirlik için ne yapabilir?

FSEK m. 38, programı hukuka uygun edinen kişinin kullanımı için özel serbestiler tanır. Sözleşmede belirleyici hüküm bulunmadığında, programın amacına uygun kullanımı için gerekli çoğaltma ve işleme hata düzeltmeyi de kapsar. Aynı madde, yasal edinenin yükleme, çalıştırma ve hata düzeltme imkanının; kullanım için gerekli olduğu sürece kullanım hakkı sahibinin bir adet yedekleme kopyası yapmasının sözleşmeyle önlenemeyeceğini ayrıca düzenler. Sözleşme hazırlanırken bu hükümler arasındaki farklı koşullar korunmalı, bütün teknik müdahaleler aynı genel yasağın altına konulmamalıdır. FSEK m. 38

Kullanım hakkı sahibi, yapmaya yetkili olduğu yükleme, görüntüleme, çalıştırma, iletme veya depolama sırasında programın altında yatan düşünce ve ilkeleri gözlemleyebilir, inceleyebilir ve sınayabilir. Bağımsız yaratılmış bir programın diğer programlarla birlikte çalışabilirliği için kod çoğaltılması ve kod biçiminin çevrilmesi ise daha dar koşullara bağlıdır: işlemi yetkili kişi veya onun adına yetkili kişi yapmalı, gerekli bilgi başka şekilde sunulmamış olmalı ve işlem gerekli program parçalarıyla sınırlı kalmalıdır. Bu ayrım, API incelemesi ile kaynak elde etmeye yönelik tersine mühendislik planının aynı hukuki dosyada ayrı gerekçelendirilmesini gerektirir. FSEK m. 38

Elde edilen bilgi bağımsız programın birlikte çalışabilirlik amacıyla kullanılmalı; bu amaç için gerekli durumlar dışında başkalarına aktarılmamalı ve ifade bakımından esastan benzer program üretimine veya başka bir fikri hak ihlaline yöneltilmemelidir. Bu birlikte çalışabilirlik serbestisi programdan normal yararlanmayla çelişecek veya hak sahibinin meşru yararlarına makul olmayan müdahale oluşturacak biçimde yorumlanamaz. Uygulamada inceleme talebi, mevcut dokümantasyonun neden yetersiz kaldığı, erişilen parçalar ve yeni programın bağımsız geliştirme kayıtları saklanmalıdır. Bu kayıtlar kanundaki şartların gerçekleştiğini göstermeye yardımcı olur; ticari sır, kişisel veri veya yetkisiz sistem erişimi gibi diğer hukuk alanları için ayrıca izin ve risk incelemesi yapılmalıdır. FSEK m. 38, birlikte çalışabilirlik koşulları ve kullanım sınırları

14. Kaynak kodu teslimi ve escrow iş sürekliliğini nasıl güvenceye alır?

Kaynak kodu tesliminde teknik paketin yeterliliği ile kullanma yetkisinin kapsamı birlikte kurulmalıdır. FSEK m. 57, eser nüshası üzerindeki mülkiyet aktarımını fikri hak aktarımından ayırır; m. 52 ise mali hak işlemlerinin yazılı biçimini ve hakların ayrı gösterilmesini düzenler. Bu nedenle depo erişimi veya bir arşiv dosyasının teslimiyle birlikte çoğaltma, değiştirme ve bakım için gerekli izinler de kararlaştırılmalıdır. Teslim kapsamındaki üçüncü kişi bileşenleri için geliştiricinin sağlayabildiği yetki ayrıca gösterilmelidir. FSEK m. 52 ve 57

Escrow düzeninde kod bağımsız emanetçiye bırakılır ve tarafların belirlediği olay gerçekleşince müşteriye açılır. Önerilen sözleşme; hangi sürümün yatırılacağını, güncelleme sıklığını, emanetçinin doğrulama görevini, masrafları ve serbest bırakma itiraz usulünü belirlemelidir. Destek hizmetinin belirli süre verilmemesi veya faaliyetin durması gibi tetikleyiciler ölçülebilir yazılmalıdır. Serbest bırakma sonrasındaki kullanım, müşterinin kendi işini sürdürmesi ve belirlediği bakım sağlayıcısının çalışması için gerekli kapsamla eşleştirilmelidir; her sözleşmeye aynı genişlikte yetki konulması tarafların ticari amacını bozabilir.

Doğrulama, teslim edilen paketin bağımsız bir ortamda derlenip çalıştırılmasını içermelidir. Derleme talimatları, bağımlılık sürümleri, yapılandırma şablonları, veri şemaları ve gerekli teknik dokümantasyon eksikse kaynak dosyaları işletmeyi ayağa kaldırmaya yetmeyebilir. Özellikle SaaS sistemlerinde veri dışa aktarımı, altyapı kurulumu ve lisanslı bulut hizmetleri ayrıca ele alınmalıdır. Emanete canlı sistem parolaları veya kişisel verilerin kontrolsüz kopyaları konulmamalı; gerekli sırların güvenli aktarımı ayrı protokolle çözülmelidir. Kabul şartı, arşivin varlığı yerine kararlaştırılan kurtarma senaryosunun başarıyla denenmesine bağlanmalıdır.

15. Yazılım için patent ve ticari sır koruması nasıl seçilir?

Yazılımın koruma stratejisi, kodun ifadesi ile üründe uygulanan teknik çözümün ayrı incelenmesiyle kurulur. 6769 sayılı Sınai Mülkiyet Kanunu m. 82, bilgisayar programlarının kendisini patentlenebilirliğin dışında bırakırken buluşlar için yenilik, buluş basamağı ve sanayiye uygulanabilirlik koşullarını arar. Bilgisayarla gerçekleştirilen bir çözümde inceleme, kodun ticari değerinden hareketle değil, istemlerle tanımlanacak buluş ve bu koşullar üzerinden yapılır. Bu nedenle telif dosyasının yanında, teknik çözümün ne olduğu ve mevcut teknikten nasıl ayrıldığı ayrı belgelenmelidir. Sınai Mülkiyet Kanunu m. 82–83

Patent başvurusu düşünülüyorsa tanıtım ve kaynak yayımlama takvimi araştırmayla birlikte yönetilmelidir. Kanunun 83. maddesi, başvurudan önce dünyanın herhangi bir yerinde toplumca erişilebilir hale gelen bilgileri tekniğin bilinen durumuna dahil eder. Ürünün teknik sunumu, herkese açık depo ve yayın, açıklanan içeriğe göre bu incelemeyi etkileyebilir. İşlem için önerilen yaklaşım, kamuya açıklamadan önce buluşun ve hedef ülkelerdeki başvuru imkanlarının incelenmesidir; açıklama sonrasında istisnalardan yararlanma olasılığı, somut açıklama ve ülke rejimiyle ayrıca doğrulanır. Sınai Mülkiyet Kanunu m. 83–84

Ticari sır yaklaşımında ise korunacak bilgi, ona erişen kişiler ve izin verilen kullanım belirlenir. 6102 sayılı Türk Ticaret Kanunu m. 55/1-b-3, çalışanları ve yardımcı kişileri üretim ve iş sırlarını açıklamaya veya ele geçirmeye yöneltmeyi; m. 55/1-c ve d ise belirtilen koşullarla başkasının iş ürününden yetkisiz yararlanmayı ve sırları hukuka aykırı kullanıp açıklamayı haksız rekabet kapsamında düzenler. 6098 sayılı Türk Borçlar Kanunu m. 396, çalışanın sır saklama yükümlülüğünü hizmet sırasında ve işverenin haklı menfaatinin korunması için gerekli ölçüde iş ilişkisi sonrasında da sürdürür. Bu çerçeve, gizlilik sözleşmesi, erişim sınırları ve ayrılma prosedürüyle işletilir. Türk Ticaret Kanunu m. 55; Türk Borçlar Kanunu m. 396

Şirket, kamuya sunduğu kodu, müşteriyle paylaştığı teknik belgeleri ve erişimi sınırlı tuttuğu algoritma veya işletme bilgisini aynı envanterde farklı koşullarla izlemelidir. Yatırımcıya yapılan teknik açıklamada gizlilik ve kullanım amacı belirlenmeli; patent araştırması sürerken yapılacak açıklamalar ayrıca onaylanmalıdır. Hak zinciri dosyası da patent başvurusu veya sır koruması bakımından gerekli katkıcı ve yetki belgelerini içermelidir. Böylece telif, başvuru ve gizlilik kararları ürünün gerçek mimarisi ve pazara çıkış takvimiyle uyumlu yürütülür.

16. Yapay zeka destekli kod ve müşteri verisi hak zincirine nasıl dahil edilir?

Yapay zeka yardımıyla geliştirilen kodda koruma ve kullanım incelemesi, insanın somut katkısı ile araçtan alınan çıktının kaynağı üzerinden yürütülmelidir. FSEK m. 1/B'deki hususiyet koşulu ve m. 8'deki eseri meydana getiren kişi ölçütü, ürün dosyasında hangi yaratıcı tercihlerin geliştiriciye ait olduğunun gösterilmesini gerektirir. İnsan tarafından kurulan mimari, seçilen ve yeniden yazılan bölümler ile otomatik öneriler ayrılmalıdır. Bu yaklaşım kanundaki genel ölçütlerin somut geliştirme sürecine uygulanmasıdır; her yapay zeka çıktısının koruma statüsünü belirleyen özel bir kanuni karineye dayanmamaktadır. FSEK m. 1/B ve 8

Kullanılan aracın sözleşmesi, çıktının ticari kullanımı, sağlayıcının sunduğu izin ve güvenceler, girdilerin saklanması ve eğitimde kullanılması bakımından ayrıca okunmalıdır. Bunlar seçilen sağlayıcının işlem tarihindeki koşullarıdır. Üçüncü kişi kodu veya açık kaynak bildirimi içeren öneriler, normal bileşen incelemesinden geçirilmelidir. Geliştirme dosyasında kullanılan araç ve sürüm, önemli girdiler, insanın yaptığı değişiklikler ve gözden geçirme kaydı tutulması önerilir. Müşteriye verilecek hak taahhüdü bu kayıtların doğruladığı kapsamla eşleştirilirse belirsiz kaynaklı bir öneri bütün ürün için sınırsız hak garantisine dönüştürülmemiş olur.

Müşteri verisinin araca gönderilmesi ayrıca veri işleme ve aktarım incelemesi gerektirir. 6698 sayılı Kişisel Verilerin Korunması Kanunu m. 5 ve 6, genel ve özel nitelikli kişisel veriler için işleme şartlarını; m. 9 ise yurt dışına aktarım koşullarını düzenler. Veri içeren istem, hata kaydı veya depo parçası için hangi verinin hangi sağlayıcıya ve ülkeye gittiği belirlenmelidir. Araç sözleşmesindeki ticari kullanım izniyle birlikte, uygulanabilir işleme şartı, gerektiğinde aktarım mekanizması ve müşteri gizlilik yükümlülükleri de karşılanmalıdır. Bu nedenle onaylı araç listesi; kullanım amacı, gönderilebilecek veri, saklama ayarları ve insan incelemesiyle tamamlanmalıdır. Kişisel Verilerin Korunması Kanunu m. 5, 6 ve 9 — Kurumun güncel kanun açıklaması

17. Yatırım veya şirket satışında yazılım hak zinciri nasıl incelenir?

Yatırım incelemesi, şirketin piyasaya sunduğu ürünü hangi yetkilerle geliştirdiğini, kullandığını ve müşterilerine sunduğunu doğrulamalıdır. FSEK m. 8 eser sahipliğini yaratıcı kişiye bağlar; m. 18/2, çalışanların işleri sırasında meydana getirdiği eserler üzerindeki mali hakları kullanma yetkisini özel sözleşme ve işin niteliğine ilişkin sınırlarla düzenler. Kurucu, çalışan, eski işveren ve bağımsız yüklenici katkıları bu nedenle ürünün sürüm geçmişine işlenmelidir. Her sözleşmenin imzası, ilgili kişinin katkı tarihini ve gerçekten teslim edilen modülü kapsayıp kapsamadığıyla birlikte incelenir. FSEK m. 8 ve 18

İncelemenin ikinci ekseni gelir modelidir. Müşteri sözleşmelerinde genel platform üzerinde verilmiş münhasırlık, geniş kaynak teslimi, yeniden satış yetkisi veya müşteriye özgü geliştirmelerin aidiyeti şirketin tekrar satış kabiliyetini etkileyebilir. Üçüncü kişi lisanslarında kullanım sınırları, fesih koşulları, devir ve kontrol değişikliği hükümleri ayrı okunmalıdır. Pay devrinde sözleşme tarafı şirketin devam etmesi ile lisansın başka kişiye aktarılması farklı olaylardır; buna rağmen kontrol değişikliği kaydı pay işlemini ayrıca etkileyebilir. Açık kaynak envanteri ise inceleme tarihindeki depoyla ve fiilen dağıtılan sürümle karşılaştırılmalıdır.

Bulgular işlem belgesine sonuçlarına göre yansıtılmalıdır. Eksik bir mali hak işlemi için, ilk işlem geçersizse ilgili hak sahibinden eksikliği gideren yeni ve geçerli, kapsamı belirli yazılı devir veya lisans alınması; uyumsuz bağımlılık için değiştirme veya ticari lisans edinilmesi; devre bağlı bir üçüncü kişi izni için kapanış öncesi muvafakat sağlanması kararlaştırılabilir. Hak zincirini tamamlayacak kişi artık erişilemiyorsa, genel garanti maddesinin yanı sıra ürünün yeniden geliştirilmesi, belirli kullanımın durdurulması veya bedel ve tazminat mekanizması müzakere edilir. Böylece inceleme raporu, belgeleri sayan bir arşiv yerine kapanıştan önce giderilecek eksiklikleri, kapanış sonrası işleri ve fiyatlandırılmış kalan riskleri gösteren bir işlem aracına dönüşür.

18. Kodun izinsiz kullanılması halinde hangi talepler ve deliller önem taşır?

İhlal incelemesi, korunan eser, hak sahibi ve izin dışındaki kullanımın birlikte belirlenmesiyle başlar. FSEK m. 66 gerçekleşen tecavüzün giderilmesini, m. 69 ise muhtemel tecavüzün veya devam ve tekrar tehlikesinin önlenmesini düzenler. Şirket kendi hak zincirini, karşı tarafın kullandığı sürümü ve bu kullanımın hangi mali hakkı etkilediğini ortaya koymalıdır. İşlev benzerliği, ortak açık kaynak bileşeni ve korunan ifadenin kopyalanması aynı iddia olarak ileri sürülmemelidir. Teknik karşılaştırma bu farklılıkları incelemeye elverişli hazırlanır. FSEK m. 2, 66 ve 69

Parasal talep seçimi ihlalin ve ispatın niteliğine bağlıdır. FSEK m. 68, kanuna uygun yazılı izin olmaksızın belirtilen mali hak kullanımlarında, sözleşme yapılsaydı istenebilecek bedelin veya rayiç bedelin kanundaki ifadeyle “en çok üç kat fazlasını” isteme imkanını düzenler. FSEK m. 70 ise mali hak ihlalinde kusura bağlı tazminatı ve sağlanan karın istenmesini ayrıca ele alır; kar talebinde m. 68 uyarınca istenen bedelin indirilmesini öngörür. Dolayısıyla talep, otomatik bir zarar çarpanı gibi kurulamaz. Kullanım süresi, kapsamı, lisans emsalleri, gelir bağlantısı ve talep türlerinin birlikte uygulanma koşulları dosyada açıklanmalıdır. FSEK m. 68 ve 70

Delil dosyasında özgün depo geçmişi, erişim kayıtları, imzalı sözleşmeler, teslim ve kabul belgeleri, ilgili ürün kopyaları ve teknik karşılaştırma yöntemi bir araya getirilmelidir. Kaybolabilecek delil ve devam eden kullanım için acil koruma ihtiyacı ayrıca incelenir. FSEK m. 77 uyarınca ihtiyati tedbir, maddede öngörülen zarar veya tehlike koşulları ve iddiaların kuvvetle muhtemel görülmesi üzerinden mahkemece değerlendirilir. Talep, ihlali ve delil kaybını önlemek için gerekli işlemi somutlaştırmalı; hangi kod veya kopyanın hangi tedbire konu olacağını göstermelidir. FSEK m. 77

Ceza yolu bakımından FSEK m. 71'deki fiiller ve m. 75'teki şikayet ile hak sahipliğini kanıtlayan belgelerin süresinde sunulması koşulları ayrı incelenir. Sözleşme bedelinin ödenmemesi, teslim tartışması ve izin dışı mali hak kullanımı farklı olgular taşıyabileceğinden başvuru konusu somutlaştırılmalıdır. İhlal iddiasıyla karşılaşan şirket de hangi izin ve yetkiye dayandığını aynı sürüm üzerinden gösterebilmelidir; m. 76, belirli delil koşullarında mahkemenin izin belgelerini veya yararlanılan eser listesini istemesini düzenler. Bu nedenle sürüm bazlı hak dosyası hem dava açarken hem savunma hazırlanırken temel çalışma aracıdır. FSEK m. 71, 75–76

Aktay ve isteğe bağlı DETAI desteği

Aktay, ürünün sürümünü çalışan ve kurucu katkıları, yüklenici zinciri, mali hak belgeleri ve bileşen lisanslarıyla eşleştiren hukuki inceleme yapabilir. İnceleme sonucuna göre geliştirme ve kabul belgeleri, devir veya lisans kapsamı, açık kaynak yükümlülükleri ve yatırım kapanış koşulları yapılandırılır. İlk çalışma için ürünün güncel sürüm tanımı, katkıcı listesi, temel geliştirme sözleşmeleri ve bileşen envanteri yeterli bir başlangıç kapsamı oluşturur; gerekli ek belgeler gerçek boşluklara göre belirlenir.

DETAI, ayrı ve isteğe bağlı teknoloji hizmeti olarak depo, sözleşme ve lisans kayıtları arasındaki eşleşmeleri ve eksikleri inceleme ekibine gösterecek bir iş akışına destek olabilir. Hukuki hak sahipliği, sözleşme yorumu ve ihlal sonucu avukat incelemesiyle belirlenir. Hukuk hizmeti ile teknoloji desteği ayrı kapsamlandırılır.

Bu rehber genel bilgilendirme amacı taşır. Belirli bir işlem veya uyuşmazlığın sonucu, sözleşmeler, katkı tarihleri, ürün mimarisi ve uygulanacak hukuk birlikte incelenerek belirlenir.