Tersine Mühendislik (Reverse Engineering) ve FSEK

1. Giriş

Tersine mühendislik, en genel tanımıyla, bir ürünün, sistemin veya yazılımın nihai halinden yola çıkarak, bunun altında yatan tasarım, yapı ve işleyiş mantığının çıkarımsal bir analizle ortaya konması sürecidir. Kavram yalnızca yazılıma özgü değildir, mekanik parçaların CAD modellemesinden kimyasal formüllerin analizine, entegre devrelerin sökülmesinden ilaç formülasyonlarının çözümlenmesine kadar mühendisliğin hemen her dalında uygulama alanı bulur. Ancak bilgisayar programları söz konusu olduğunda tersine mühendislik, kendine özgü teknik yöntemleri ve kendine özgü bir hukuki rejimi olan bağımsız bir kategori oluşturur.

Yazılım bağlamında üç temel teknik ayırt edilir. Kara kutu testi (black-box testing), programın kaynak koduna hiç erişilmeksizin, yalnızca girdi-çıktı davranışının gözlemlenmesi yoluyla işleyişinin çıkarsanmasıdır. Disassembly (ayrıştırma), çalıştırılabilir nesne kodunun (object code) makineye özgü assembly diline çevrilmesidir. Dekompilasyon (decompilation) ise nesne kodunun, insan tarafından okunabilir, üst düzey bir programlama diline yakın bir forma dönüştürülmesidir. Burada elde edilen çıktı, orijinal kaynak kodun birebir yeniden üretimi değil, işlevsel açıdan ona yakın bir yeniden yapılandırmadır. Bu üç yöntem arasındaki teknik fark, FSEK m. 38'in farklı fıkralarının farklı fiillere karşılık gelmesi bakımından doğrudan hukuki sonuç doğurur.

Pratikte tersine mühendisliğe başvurulan amaçlar da çeşitlilik gösterir: rakip veya tamamlayıcı bir ürünle birlikte çalışabilirliğin (ara işlerlik) sağlanması, güvenlik açıklarının tespiti ve sorumlu ifşa (responsible disclosure) süreçleri, akademik araştırma ve eğitim, ve nihayet hukuki uyuşmazlıklarda delil tespiti. Bu çalışmanın odağı, FSEK bağlamında yazılımların tersine mühendisliğe konu edilmesidir; donanım veya kimyasal alanlardaki tersine mühendislik faaliyetleri farklı bir hukuki rejime (patent hukuku, ticari sır hukuku) tabidir ve yalnızca ilgili olduğu ölçüde bu incelemede değerlendirilecektir.

2. Bilgisayar Programlarının FSEK Kapsamında Eser Olarak Korunması

FSEK m. 1/B(g) bilgisayar programını, "bir bilgisayar sisteminin özel bir işlem veya görev yapmasını sağlayacak bir şekilde düzene konulmuş bilgisayar emir dizgesini ve bu emir dizgesinin oluşum ve gelişimini sağlayacak hazırlık çalışmaları" olarak tanımlamaktadır. FSEK m. 2/1 ise bilgisayar programlarını, "ilim ve edebiyat eserleri" kategorisi içinde saymakta ve korumayı yalnızca nihai koda değil, akış şemaları gibi hazırlık tasarımlarına da teşmil etmektedir.

Korumanın kapsamı bakımından kritik ayrım, kaynak kodu (source code) ile nesne kodunun (object code) her ikisinin de "her biçim altında ifade edilen bilgisayar programları" ibaresi uyarınca eser olarak korunduğu, ancak fikir ile ifadenin birbirinden ayrıldığıdır. FSEK m. 2'nin son fıkrası, bir bilgisayar programının herhangi bir unsuruna arayüzüne temel oluşturan düşünce ve ilkeler dahil olmak üzere, temel oluşturan fikir ve ilkelerin eser sayılmayacağını, dolayısıyla telif korumasından yararlanamayacağını hükme bağlamaktadır. 

Algoritmalar da bu kapsamda, soyut bir çözüm yöntemi oldukları için korumanın dışında kalır. Bu fikir ve ifade ayrımı, tersine mühendisliğin teorik meşruiyetinin de temelini oluşturur: zira tersine mühendisliğin nihai amacı çoğunlukla, tam olarak bu korunmayan fikir ve ilke katmanına ulaşmaktır.

Eser sahipliği bakımından FSEK m. 8 uyarınca kural, eseri fiilen meydana getiren gerçek kişinin eser sahibi sayılmasıdır; bir hizmet ilişkisi çerçevesinde geliştirilen yazılımlarda ise FSEK m. 18 uyarınca mali hakların işverene ait olacağı kabul edilir. Koruma süresi, FSEK m. 27 uyarınca eser sahibinin yaşamı boyunca ve ölümünden itibaren 70 yıl devam eder; bu sürenin sona ermesiyle program kamuya mal olur ve serbestçe çoğaltılıp işlenebilir hale gelir.

3. Şahsen Kullanma Hükmünün Bilgisayar Programlarına Özgü Rejimi

Tersine mühendisliğin yazılımlar bakımından hukuki çerçevesi, Fikir ve Sanat Eserleri Kanunu’nun (FSEK) 38. maddesinde düzenlenmiştir. Madde, 1995 yılında yapılan değişiklikle bugünkü ayrıntılı halini almış olup, özünde Avrupa Birliği Yazılım Direktifi’nin iç hukuka aktarılmasına dayanmaktadır. Doktrinde, çeviri sürecinden kaynaklanan bazı ifade ve iç tutarlılık sorunları eleştirilse de uygulamada her fıkranın amaçsal bir yorumla ayrı ayrı ele alınması gerekmektedir.

Maddenin ilk fıkrasında yer alan genel şahsen kullanma istisnası, uluslararası telif hukukunda "üç adım testi" olarak bilinen kümülatif unsurları barındırır. Bu test, istisnanın hak sahibinin meşru menfaatlerine zarar vermemesini ve eserden normal yararlanmayla çelişmemesini şart koşar. Ancak kanunun gerekçesinde, bilgisayar programları için daha dar bir rejim öngörüldüğünden bu genel istisnanın yazılımlara uygulanmayacağı belirtilmiştir. Doktrinde bir kesim bu gerekçeye sadık kalırken, diğer bir kesim ise uluslararası sözleşmelerin bağlayıcılığı nedeniyle bu genel denetim mekanizmasının bilgisayar programlarını da kapsaması gerektiğini savunmaktadır.

Yazılımın amaca uygun kullanımı, hata düzeltilmesi ve işlenmesi gibi haklar ise taraflar arasındaki sözleşme hükümlerine bırakılmıştır. Bu hüküm tamamlayıcı nitelikte olduğundan, piyasadaki Son Kullanıcı Lisans Sözleşmelerinde (EULA) yer alan "değişiklik yapma yasağı" gibi maddeler hukuki geçerlilik kazanmaktadır. Buradaki en kritik nokta, bu serbestinin yalnızca yazılımı yasal yollardan edinen kişilere tanınmış olmasıdır; korsan veya lisanssız kopyalar üzerinde bu hak hiçbir şekilde doğmaz.

Kullanıcının yatırımını ve verilerini korumayı amaçlayan yedekleme kopyası hakkı ise tamamen emredici bir hükümle korunmuştur. Sözleşmelerle ya da lisans anlaşmalarıyla kullanıcının bir adet yedek kopya alması engellenemez. Teknik bir arıza nedeniyle orijinal kopyanın yok olması riskine karşı getirilen bu kural, bir önceki fıkranın aksine tarafların iradesiyle ortadan kaldırılamaz.

Yazılım dünyasında "kara kutu testi" olarak adlandırılan gözlemleme, tetkik ve sınama faaliyetleri de kanunen serbest bırakılmıştır. Kullanıcı, yazılımı yükleme, çalıştırma veya depolama gibi yasal haklarını icra ettiği sırada programın işleyiş mantığını inceleyebilir. Kaynak koda müdahale edilmeksizin, sadece girdi ve çıktı ilişkilerinin gözlemlenmesine dayanan bu süreç, kod üzerinde bir çoğaltma fiili içermediği için telif hakkı ihlali riskinden uzak ve geniş kapsamlı bir istisnadır.

Kodun çözülmesi ve formunun çevrilmesi anlamına gelen asıl dekompilasyon (tersine mühendislik) faaliyeti ise yasada üç kümülatif şarta bağlanmıştır. Bu işlemin yetkili bir kişi tarafından yapılması, birlikte çalışabilirliği (araişlerliği) sağlamak için gerekli teknik bilginin piyasada hazır bulunmaması ve incelemenin sadece zorunlu olan küçük program parçalarıyla sınırlı tutulması gerekir. Bu üç şarttan herhangi birinin eksik olması, yapılan faaliyeti doğrudan telif hakkı ihlaline dönüştürür.

Dekompilasyon sonucunda elde edilen bilgilerin kullanımı da çok sıkı sınırlara tabidir. Bu bilgiler, uyumluluk sağlama amacı dışında kullanılamayacağı gibi, ifade ediliş bakımından "esastan benzer" yeni bir yazılımın üretilmesinde veya pazarlanmasında asla kullanılamaz. Sektörde bu hukuki sınırı aşmamak adına, analiz ekibi ile yeni ürünü geliştiren yazılım ekibinin birbirinden tamamen izole edildiği "temiz oda" (clean room) disiplini uygulanmaktadır.

4. Avrupa Birliği Yazılım Direktifi

FSEK m. 38'in bilgisayar programlarına ilişkin fıkraları, doğrudan doğruya Avrupa Birliği'nin (önce 91/250/EEC, halihazırda kodifiye edilmiş haliyle 2009/24/EC sayılı) Bilgisayar Programlarının Hukuki Korunmasına Dair Direktifi'nin iç hukuka aktarılmasının ürünüdür. Direktifin 5(3). maddesi, FSEK'teki "gözlemleme, tetkik ve sınama" serbestisinin; 6. maddesi ise dekompilasyona ilişkin üç şart ve üç kullanım yasağının doğrudan kaynağıdır. Nitekim FSEK m. 38'in ilgili fıkralarının, Direktif metninin neredeyse birebir -kimi zaman çeviri kaynaklı ifade bozukluklarıyla birlikte- aktarılmış hali olduğu doktrinde de kabul görmektedir.

Direktifin 9(1). maddesi, dekompilasyon istisnasına (m. 6) ve gözlem/tetkik/sınama serbestisine (m. 5/2-3) aykırı her türlü sözleşme hükmünün batıl (null and void) sayılacağını açıkça hükme bağlamaktadır; buna karşılık madde 5(1)'deki genel hata düzeltme/amaca uygun kullanım serbestisi sözleşmeyle bertaraf edilebilir. FSEK'te bu açıklıkta, "sözleşme hükmü batıldır" ifadesini içeren ayrı bir hüküm bulunmamakla birlikte, FSEK m. 38'in yedekleme kopyasına ilişkin fıkrasının açıkça "sözleşme ile önlenemez" ifadesini taşıması ve maddenin bütününün Direktif'in birebir aktarımı niteliğinde olması, doktrinde dekompilasyon ve kara kutu testi haklarının da -Direktif'le uyumlu yorum ilkesi gereği- sözleşmeyle geçerli biçimde bertaraf edilemeyeceği görüşünü desteklemektedir. Direktifin temel amacı, yazılım pazarında rekabeti ve pazara girişi kolaylaştırmak, hâkim durumdaki platform sahiplerinin teknik bilgiyi tekelinde tutarak rakiplerini pazardan dışlamasının ("vendor lock-in") önüne geçmektir.

5. Amerikan Fair Use Doktrini 

Kıta Avrupası hukuk ailesinin bir parçası olan Türkiye ile Avrupa Birliği, yazılımlarda tersine mühendisliği önceden belirlenmiş ve kümülatif şartlara bağlanmış kapalı bir istisna rejimiyle düzenlemektedir. Bu ex ante(kural bazlı) yaklaşımda hukuki sınırlar kanun koyucu tarafından net bir şekilde çizilirken, Amerikan hukuku meseleyi tamamen farklı bir felsefeyle ele almaktadır. ABD sistemi, federal telif hukuku kanununun (17 U.S.C. § 107) düzenlediği dört faktörlü, esnek ve ucu açık bir "adil kullanım" (fair use) standardı üzerinden, dava bazlı (ex post) bir yargısal değerlendirme metodunu benimser. Her iki ekolün ulaştığı pratik sonuçlar ve piyasa dengeleri pratik anlamda birbiriyle büyük ölçüde örtüşse de sağladıkları hukuki belirlilik dereceleri ve metodolojileri bakımından iki sistem taban tabana zıttır.

Amerikan telif hukuku içtihadında yazılım tersine mühendisliğinin temel taşı ve dönüm noktası, Dokuzuncu Bölge Federal İstinaf Mahkemesi tarafından karara bağlanan Sega Enterprises Ltd. v. Accolade, Inc. (1992) davasıdır. Oyun üreticisi Accolade, Sega’nın ünlü Genesis konsoluyla tam uyumlu bağımsız oyunlar geliştirmek amacıyla, Sega’ya ait oyun kartuşlarındaki nesne kodunu (object code) kod sökme (disassembly) yöntemiyle kaynak koda dönüştürerek çözümlemiştir. Bu süreçte konsolun kilitli arayüz gerekliliklerini tespit eden Accolade, Sega tarafından telif hakkı ihlali iddiasıyla dava edilmiştir. Federal Mahkeme; telif hakkıyla korunmayan fonksiyonel unsurlara ve arayüz gereksinimlerine ulaşmanın tek yolunun kod sökme olduğu, ayrıca bu erişimin arkasında uyumlu yeni bir ürün geliştirmek gibi meşru bir ticari amaç bulunduğu hallerde, sürecin zorunlu bir parçası olarak yapılan geçici "ara kopyalamaların" (intermediate copying) adil kullanım (fair use) teşkil edeceğine hükmetmiştir.

Aynı federal mahkeme, sekiz yıl sonra yazılım dünyasındaki dengeleri daha da netleştiren Sony Computer Entertainment, Inc. v. Connectix Corp. (2000) kararında bu içtihadi ilkeyi güçlü bir şekilde teyit etmiştir. Davalı Connectix şirketi, Sony PlayStation oyunlarının bilgisayarlarda da çalıştırılabilmesini sağlayan bir emülatör yazılımı (Virtual Game Station) geliştirmek amacıyla Sony’nin tescilli BIOS yazılımını tersine mühendisliğe tabi tutmuştur. Connectix, araştırma ve geliştirme sürecinde Sony BIOS kodunun RAM üzerinde sayısız geçici kopyasını oluşturmuş, ancak pazara sunduğu nihai ticari emülatör ürününde Sony’ye ait hiçbir kod satırına yer vermemiştir. Mahkeme, fikri mülkiyet hukuku korumasından dışlanmış olan işlevsel unsurlara erişebilmek için bu tür ara kopyalamaların teknik bir zorunluluk olduğunu belirterek, rakip bir platform yaratılsa dahi eylemin adil kullanım kapsamında kaldığına karar vermiştir.

Her iki tarihi kararın da felsefi merkezinde yer alan ve Amerikan hukukunu Kıta Avrupası yaklaşımına yaklaştıran ortak payda, tersine mühendisliğin yalnızca korunmayan fikir, mantık ve işlevsel unsurlara ulaşmak amacıyla yapılmış olmasıdır. ABD içtihadındaki bu zorunluluk ve amaca bağlı sınırlılık kriteri, Türk hukukundaki FSEK m. 38'in aradığı "orantılılık ve ikame imkânsızlığı" şartının tam olarak işlevsel ve küresel karşılığını oluşturmaktadır. Amerikan sisteminin sağladığı bu esneklik, teknolojik inovasyonun ve platformlar arası rekabetin önünü açarken; Kıta Avrupası ve Türk hukuku ise yazılımcılara önceden öngörülebilir, güvenli ama daha dar sınırları olan yasal bir oyun alanı sunmaktadır.

6. Yargı Uygulamasında Tersine Mühendislik

Türk yargı pratiğinde tersine mühendislik veya kaynak kod kopyalama iddialarının ispatı, neredeyse istisnasız biçimde teknik bilirkişi incelemesine dayanır. Mahkemeler; kaynak kod, nesne kodu, veri tabanı yapısı, veri tabanına erişim mantığı ve genel yazılım mimarisi arasında karşılaştırmalı bir analiz yaptırarak, iddia edilen benzerliğin rastlantısal/bağımsız gelişim mi yoksa hukuka aykırı yararlanma mı olduğunu tespit etmeye çalışır.

Yargıtay 11. Hukuk Dairesi'nin 2015/1510 E., 2015/8419 K. sayılı ve 17.06.2015 tarihli kararı bu yöntemin somut bir uygulamasını gösterir: davalı tarafından geliştirilen bir üniversite otomasyon yazılımı ile davacıya ait yazılımın kaynak ve nesne kodları, veri tabanı yapıları ve erişim mantığı, bilirkişi incelemesi sonucunda tamamen farklı bulunmuş ve eşleşen hiçbir dosyaya rastlanmamıştır; arayüz tasarımları arasındaki benzerlik ise ayrı bir güzel sanat eseri koruması bulunmadığından FSEK kapsamında bir hak ihlali olarak değerlendirilmemiştir. Karar, kod düzeyinde doğrudan kopyalamanın yokluğunun, tersine mühendislik veya bağımsız geliştirme iddialarının değerlendirilmesinde belirleyici bir kriter olarak işlev gördüğünü göstermektedir.

Bu noktada, Amerikan hukukundaki "yapı-sıra-organizasyon" (structure-sequence-organization) doktrini ve soyutlama-ayıklama-karşılaştırma (abstraction-filtration-comparison) testiyle paralel bir mantık, Türk uygulamasında da bilirkişi raporları aracılığıyla fiilen işletilmektedir: kod satırlarının birebir örtüşmediği hallerde dahi, program mimarisinin ve iş mantığının esastan devralınması, "esastan benzerlik" temelinde bir ihlal iddiasına konu olabilir. Tersine mühendislik yoluyla ulaşılan bilginin FSEK m. 38'in öngördüğü sınırları aşarak böyle bir esastan benzer ürün geliştirmede kullanılması halinde, FSEK m. 71 uyarınca bir yıldan beş yıla kadar hapis veya adli para cezası gündeme gelebilir; bu tür uyuşmazlıklarda görevli mahkeme FSEK m. 76 uyarınca fikri ve sınai haklar hukuk/ceza mahkemeleridir.

7. FSEK m. 72 ve Tersine Mühendislik

FSEK m. 72, eser sahiplerinin haklarını korumak amacıyla kullanılan teknolojik koruma önlemlerini (TPM) etkisiz kılmaya yönelik fiilleri cezalandıran bir hükümdür. 25.12.2021 tarihli ve 31700 sayılı Resmî Gazete'de yayımlanan 7346 sayılı Kanun'la kapsamı önemli ölçüde genişletilmiş; madde eski haliyle yalnızca "bir bilgisayar programının hukuka aykırı çoğaltılmasını önleyen ilave programları etkisiz kılma" fiilini kapsarken, güncel haliyle erişim kontrolü, şifreleme veya çoğaltım kontrol mekanizması gibi araçlarla sağlanan tüm etkili teknolojik önlemleri -yalnızca yazılımlarla sınırlı olmaksızın, eser, icra, fonogram, yapım ve yayınlar bakımından da- kapsayacak şekilde genişletilmiştir. Bu düzenleme, WIPO Telif Hakları Anlaşması m. 11 ile Amerikan hukukundaki DMCA'nın "anti-circumvention" (etrafından dolanmayı önleme) rejimiyle paralellik taşır ve altı aydan iki yıla kadar hapis cezası öngörür.

Burada gerçek bir doktrinsel gerilim noktası ortaya çıkar: bir yazılımın ara işlerlik bilgisine dekompilasyon yoluyla ulaşılırken, aynı zamanda o yazılımın bir lisans doğrulama mekanizmasını veya erişim kontrolünü de aşmak zorunlu hale gelirse, FSEK m. 38'in izin verdiği fiil ile m. 72'nin yasakladığı fiil aynı olayda çakışabilir. FSEK m. 38/6-7'nin özel (lex specialis) niteliği, dekompilasyonun kendisini -yani kodun çoğaltılması ve çevrilmesi fiilini- şartları dahilinde hukuka uygun kılsa da, bu sürecin bir teknik koruma önlemini fiilen etkisiz kılmayı gerektirdiği hallerde m. 72'nin ayrıca ihlal edilip edilmeyeceği, kanun metninde açıkça çözümlenmiş değildir ve bu, Türk fikri mülkiyet doktrininde henüz yerleşik bir çözüme kavuşmamış açık bir tartışma alanıdır. Somut olayın koşullarına göre değerlendirme yapılması gerektiği söylenebilir.

8. Sözleşmesel Kısıtlamalar

Piyasada dağıtılan hemen her son kullanıcı lisans sözleşmesi (EULA), tersine mühendisliği, dekompilasyonu ve disassembly'yi açıkça yasaklayan hükümler içerir. Bu tür hükümlerin Türk hukuku bakımından geçerliliği, FSEK m. 38'in hangi fıkralarının emredici, hangilerinin dispositif olduğu ayrımına bağlıdır. "Amaca uygun çoğaltma ve işleme" serbestisi -madde metninin kendisinde "sözleşmede belirleyici hükümlerin yokluğu durumunda" ifadesiyle açıkça belirtildiği üzere- sözleşmeyle geçerli olarak bertaraf edilebilir; dolayısıyla bir EULA'nın hata düzeltme veya uyarlama serbestisini kısıtlaması kural olarak hukuka uygundur.

Buna karşılık yedekleme kopyası hakkı madde metninde açıkça "sözleşme ile önlenemez" denilerek emredici kılınmıştır. Kara kutu testi (gözlemleme/tetkik/sınama) ve dar anlamda dekompilasyon hakları bakımından FSEK'te AB Direktifi m. 9/1'deki kadar açık bir "aksine sözleşme hükümleri batıldır" ifadesi yer almasa da, doktrinde -Direktifle uyumlu yorum ilkesi ve maddenin bütününün Direktif'in aktarımı olması gerekçeleriyle- bu hakların da sözleşmeyle geçerli biçimde bertaraf edilemeyeceği görüşü ağırlık kazanmaktadır. Bu çerçevede, bir EULA'da yer alan "her türlü tersine mühendislik mutlak surette yasaktır" biçimindeki genel ve istisnasız bir hükmün, en azından ara işlerlik amaçlı dekompilasyon bakımından FSEK m. 38'in emredici çekirdeğiyle çatıştığı ve bu ölçüde geçersiz sayılabileceği ileri sürülebilir. Yazılım şirketlerinin gerek kendi EULA'larını hazırlarken gerek üçüncü taraf yazılımların lisans şartlarını değerlendirirken bu inceliği gözetmesi önerilir.

9. Ticari Sır, Haksız Rekabet ve Patent Hukuku Boyutuyla Sınır Çizgileri

Tersine mühendisliğin hukuki sonuçları FSEK ile sınırlı değildir; konu, Türk Ticaret Kanunu'nun ("TTK") haksız rekabete ilişkin m. 54 vd. hükümleri ve 6769 sayılı Sınai Mülkiyet Kanunu'nun ("SMK") patent hükümleriyle birlikte, üç katmanlı bir çerçevede değerlendirilmelidir. TTK bakımından belirleyici olan, bilginin ediniliş biçimidir: piyasada hukuka uygun yollarla edinilmiş bir üründen yola çıkılarak yapılan, dürüstlük kuralına aykırı bir unsur taşımayan tersine mühendislik, klasik ticari sır hukukunda "bağımsız keşif" (independent discovery) savunmasının bir türevi olarak kural olarak meşru kabul edilir. Buna karşılık bir gizlilik sözleşmesi (NDA) veya lisans sözleşmesiyle tersine mühendislik açıkça yasaklanmışsa, bu yasağın ihlali -FSEK bağlamındaki analizden bağımsız olarak- ayrıca bir sözleşmeye aykırılık ve haksız rekabet zemini oluşturabilir.

Patent hukuku cephesinde ise SMK m. 85/3(a) ve (b), sınai veya ticari amaç taşımayan ve özel maksatla sınırlı kalan fiiller ile patent konusu buluşu içeren deneme amaçlı fiillerin, patent hakkının kapsamı dışında kaldığını düzenlemektedir. Bu istisna, patentli bir ürünün işleyişini anlamaya yönelik araştırma ve deneme amaçlı analizler için bir hukuki zemin sunar; ancak elde edilen bilginin ticari üretim veya pazarlamaya konu edilmesiyle birlikte istisnanın koruması sona erer. Sonuç olarak tersine mühendislik, tek bir kanun maddesiyle değil, FSEK–TTK–SMK üçgeninde değerlendirilmesi gereken, disiplinler arası bir hukuki meseledir; bir faaliyetin FSEK m. 38 bakımından hukuka uygun olması, onu otomatik olarak haksız rekabet veya sözleşme hukuku bakımından da risksiz kılmaz.

10. Uygulamada Tersine Mühendislik

Türkiye'deki yazılım şirketlerinin ve teknoloji hukuku uygulamasının en sık karşılaştığı kritik senaryolar ile bunlara ilişkin risk yönetimi ilkeleri şu şekildedir:

Ara İşlerlik ve API Uyumluluğu: İki yazılım arasında eklenti, entegrasyon veya köprü geliştirme amacıyla dekompilasyon yapılması durumunda, FSEK m. 38’in üç şartı sıkı bir teste tabi tutulur. Özellikle aranan teknik bilginin kamuya açık dokümanlar veya API şartnameleri gibi başka bir yoldan edinilmesinin imkânsız olduğu ve analiz faaliyetinin sadece entegrasyon için zorunlu olan kısımlarla sınırlı tutulduğu somut verilerle ispatlanmalıdır. Bu sürecin her aşamasının şirket içinde belgelenmesi, ileride doğabilecek bir telif hakkı ihtilafında en güçlü yasal savunma zeminini oluşturur.

Eski Çalışanların Kaynak Koda Erişimi ve Ticari Sır İhlalleri: FSEK m. 18 uyarınca, bir iş ilişkisi içinde geliştirilen yazılımların mali hakları doğrudan işverene aittir. İşten ayrılan bir yazılımcının, eski şirketinde edindiği teknik bilgiyi, algoritmaları veya kaynak kod parçalarını kullanarak rakip bir ürün geliştirmesi çok katmanlı bir ihlal yaratır. Bu durum yalnızca telif hukuku kapsamında bir fikri mülkiyet ihlali değil, aynı zamanda bilginin iş ilişkisindeki güven yükümlülüğü kötüye kullanılarak edinilmesi nedeniyle, Türk Ticaret Kanunu uyarınca haksız rekabet ve İş Kanunu uyarınca hizmet sözleşmesine aykırılık zemininde ağır hukuki ve cezai yaptırımlara tabidir.

Güvenlik Denetimi ve Sorumlu İfşa (Responsible Disclosure): Bir yazılımın veya donanımın siber güvenlik açıklarını tespit etmek amacıyla analiz edilmesi, kaynak koda dokunulmadığı sürece "kara kutu testi" serbestisi ve Sınai Mülkiyet Kanunu’ndaki "deneme amaçlı kullanım" istisnalarıyla yasal olarak korunur. Beyaz şapkalı hacker’lar veya siber güvenlik şirketleri tarafından yürütülen bu sızma testlerinde asıl hukuki risk, tespit edilen zafiyetlerin üçüncü taraflarla veya kamuoyuyla paylaşılma biçiminde ortaya çıkar. Sistem sahibine zarar vermeyecek şekilde, önceden belirlenmiş "sorumlu ifşa" protokollerine uyulması ve açıkların kapatılması için makul bir süre tanınması, cezai sorumlulukların ve haksız rekabet iddialarının önüne geçilmesi için zorunludur.

Emülatörler ve Geriye Dönük Uyumluluk Yazılımları: Amerikan hukukundaki Sega v. Accolade ve Sony v. Connectix davalarına konu olan emülatör geliştirme süreçleri, Türkiye'de retro oyun projelerinde, donanım sürücüsü (driver) uyumluluk yazılımlarında veya eski endüstriyel sistemlerin modern bulut platformlarına taşınması süreçlerinde karşımıza çıkmaktadır. Eski bir platformun işleyiş mantığını çözmek için yapılan tersine mühendislik faaliyetlerinde, nihai üründe orijinal yazılıma ait hiçbir kod satırının bulunmaması şarttır. Amerikan içtihatlarında olduğu gibi, Türk hukukunda da bu süreçlerin hukuka uygun kabul edilebilmesi için analiz ve kodlama ekiplerinin birbirinden tamamen ayrıldığı "temiz oda" disiplininin uygulandığının ve nihai ürünün tamamen bağımsız yazıldığının ispatlanması gerekir.

11. Yapay Zekâ Modelleri ve Tersine Mühendislik

Büyük dil modellerinin yaygınlaşmasıyla birlikte, tersine mühendislik kavramı yeni bir teknolojik nesneyle -eğitilmiş model ağırlıkları (model weights) ve bunların davranışsal gözlem yoluyla "damıtılması" (distillation) ile- karşı karşıyadır. Bir modelin API çıktıları üzerinden sistematik biçimde sorgulanarak benzer bir modelin eğitilmesi ya da model dosyalarının doğrudan analiz edilmesi, FSEK'in "bilgisayar programı" tanımının bu tür unsurları ne ölçüde kapsadığı sorusunu gündeme getirmektedir; zira eğitilmiş bir model ağırlıklar matrisi, klasik anlamda bir "emir dizgesi" (kaynak kod) olmaktan ziyade istatistiksel bir çıktıdır ve FSEK m. 38'in dekompilasyona ilişkin ayrıntılı rejiminin bu yapıya doğrudan uygulanıp uygulanamayacağı henüz doktrinde tartışılmamış, yerleşik bir görüşe kavuşmamış bir alandır.

Bu tartışma yalnızca fikri mülkiyet hukukuyla da sınırlı değildir; büyük ölçekli yapay zekâ modellerinin tersine mühendisliği, güncel jeopolitik gündemde ihracat kontrolü ve ulusal güvenlik mevzuatıyla da kesişmektedir. Önümüzdeki dönemde, FSEK'in bilgisayar programı rejiminin bu yeni teknolojik nesnelere ne şekilde uygulanacağının -gerekirse mevzuat düzeyinde bir müdahaleyle- netleşmesi beklenmelidir; bu, Türk fikri mülkiyet hukukunun izlemeye devam etmesi gereken açık bir alandır.

12. Sonuç

Tersine mühendislik, Türk hukukunda ne mutlak bir yasak ne de sınırsız bir serbestidir; aksine, FSEK m. 38’in katı ve kümülatif şartlarına tabi, dar yorumlanması zorunlu yasal bir istisnadır. Bu faaliyetin sınırları yalnızca telif hukukuyla çizilmemiştir; sürecin hukuka uygunluğu FSEK m. 72’deki teknolojik koruma önlemleriyle, Türk Ticaret Kanunu’nun haksız rekabet hükümleriyle, Sınai Mülkiyet Kanunu’nun patent istisnalarıyla ve sözleşme hukukunun genel ilkeleriyle çok katmanlı bir biçimde çevrelenmiştir. Bu nedenle, her somut olayda bilginin ediniliş yöntemi, faaliyetin nihai amacı, kapsamı ve elde edilen verilerin sonraki kullanım biçimi ayrı birer hukuki teste tabi tutulmalıdır.

Yazılım şirketleri için bu karmaşık tablonun pratik sonucu son derece nettir: Ara işlerlik, güvenlik denetimi veya rakip analizi gibi hangi amaçla olursa olsun, bir tersine mühendislik sürecine başlanmadan önce koruyucu adımların atılması hayati önem taşır. Şirketler, FSEK m. 38’in aradığı üç şartın (yetki, zorunluluk ve orantılılık) karşılandığını yazılı olarak belgelemeli, mevcut lisans sözleşmelerindeki kısıtlamaları titizlikle gözden geçirmeli ve olası telif hakkı ihlali iddialarını bertaraf etmek için "temiz oda" (clean room) disiplinini eksiksiz şekilde kurmalıdır.