Yazılım Kaynak Kodu Escrow Sözleşmesi Nedir? Teslim ve Açılma Şartları | 2026

Kurumsal yazılım projelerinde en ağır operasyonel risklerden biri, işletmenin kritik sisteminin tek bir yazılım tedarikçisine bağımlı hâle gelmesidir. ERP, üretim planlama, lojistik, ödeme, müşteri yönetimi, özel entegrasyon, liman operasyonu, saha servisi veya sektörel otomasyon yazılımı yıllarca kullanılabilir. Tedarikçinin faaliyetine son vermesi, destek hizmetini kalıcı biçimde kesmesi, iflas etmesi veya sözleşmedeki kritik bakım yükümlülüğünü yerine getirmemesi hâlinde müşteri yalnızca çalışır durumdaki uygulamaya sahip olabilir; kaynak kodu, derleme araçları, bağımlılıklar ve teknik dokümantasyon olmadan sistemi sürdüremeyebilir.

Bu yazıyla ilgili genel bir sorunuz mu var? Anonim soru sor

Escrow düzenlemesinin amacı yazılım şirketinin kaynak kodunu baştan müşteriye açmak değildir. Amaç, tedarikçi faaliyetini normal sürdürürken kaynak kodunu gizli tutmak; yalnızca önceden belirlenmiş ve doğrulanabilir açılma olayında iş sürekliliğini koruyacak kontrollü erişim sağlamaktır. Bu nedenle iyi bir escrow sözleşmesi üç ayrı ilişkiyi açıkça düzenler: yazılım sahibi ile müşteri arasındaki lisans/hizmet ilişkisi, yazılım sahibi ile escrow saklayıcısı arasındaki teslim ve gizlilik ilişkisi ve açılma gerçekleştiğinde müşterinin hangi teknik ve fikrî haklarla kodu kullanabileceği.

• Kaynak kodu escrow sözleşmesinin hukuki dayanağı
• Depoya hangi dosyalar bırakılmalı?
• Kaynak kodun güncel tutulması
• Doğrulama ve derlenebilirlik testi
• Açılma şartları nasıl yazılmalı?
• İflas ve faaliyetin sona ermesi
• Destek hizmetinin kesilmesi
• Kaynak kod teslimi telif devri midir?
• Açılmadan sonra kullanım sınırı
• Üçüncü taraf ve açık kaynak bileşenleri
• Ticari sır ve bilgi güvenliği
• KVKK ve canlı veri yasağı
• Exit ve geçiş desteği
• Delil ve bildirim düzeni
• Sözleşme kontrol listesi

1. Kaynak Kodu Escrow Sözleşmesinin Hukuki Dayanağı Nedir?

6098 sayılı Türk Borçlar Kanunu m.26 uyarınca taraflar, bir sözleşmenin içeriğini kanunda öngörülen sınırlar içinde özgürce belirleyebilir. Kaynak kodu escrow sözleşmesi de bu sözleşme özgürlüğü kapsamında kurulabilir. Taraflar; saklayıcının kim olduğunu, hangi materyalin depolanacağını, güncelleme sıklığını, doğrulama yöntemini, ücretleri, gizlilik yükümlülüğünü, açılma olaylarını ve teslim sonrasındaki kullanım sınırlarını yazılı biçimde kararlaştırır.

Escrow sözleşmesi, yazılım lisans sözleşmesinden bağımsız düşünülemez. Çünkü depoda fiziksel veya dijital olarak bir kaynak kod kopyasının bulunması, müşteriye onu çoğaltma, değiştirme, uyarlama, üçüncü kişiye verme veya ticari olarak kullanma yetkisini kendiliğinden vermez. FSEK m.52 mali haklara ilişkin sözleşme ve tasarrufların yazılı olmasını ve sözleşmeye konu hakların ayrı ayrı gösterilmesini zorunlu kılar. Bu nedenle açılma sonrasında müşteriye hangi mali hakların hangi amaç, süre, yer ve kişi çevresi için kullandırılacağı açık biçimde yazılmalıdır.

Örneğin “kaynak kod müşteriye teslim edilir” cümlesi teknik teslimi düzenler; fakat bu cümle tek başına müşterinin kodu başka ürünlerde kullanabileceği, üçüncü kişiye satabileceği veya yazılımı sınırsız çoğaltabileceği anlamına gelmez. Teknik teslim ile fikrî hak yetkisi iki ayrı başlık altında kurulmalıdır.

2. Escrow Deposuna Hangi Dosyalar Bırakılmalıdır?

Yalnızca kaynak kod klasörünü depoya yüklemek çoğu projede iş sürekliliği sağlamaz. Sözleşmenin ekinde depo kapsamı dosya türleri itibarıyla sayılmalıdır. Kaynak kodun tamamı, derleme ve paketleme betikleri, bağımlılık listeleri, sürüm kilit dosyaları, veritabanı şemaları, migration dosyaları, yapılandırma şablonları, API tanımları, entegrasyon belgeleri ve gerekli kurulum dokümantasyonu ayrı kalemler hâlinde gösterilmelidir.

Canlı sistem parolaları, özel anahtarlar ve müşteri kişisel verileri depo paketine gelişigüzel konulmamalıdır. İşletmenin yazılımı yeniden ayağa kaldırabilmesi için gerekli olan teknik yapı ile canlı ortama ait sır ve kişisel veri birbirinden ayrılmalıdır. Gerekli sırların ayrıca güvenli bir anahtar yönetim sistemiyle teslimi öngörülebilir; ancak sözleşme “kaynak kod deposu” bahanesiyle gerçek kullanıcı verilerinin kopyalanmasına dönüşmemelidir.

Depoya bırakılacak her bileşenin sürüm numarası ve checksum/hash değeri kayıt altına alınırsa, daha sonra hangi paketin hangi tarihte teslim edildiği ispatlanabilir. Böylece yalnızca “bir dosya bırakıldı” değil, üretimde kullanılan belirli sürümün saklandığı gösterilebilir.

3. Kaynak Kod Nasıl Güncel Tutulur?

Escrow düzenlemesinin değeri, depodaki kodun güncelliğine bağlıdır. Üretim sistemi v12 ile çalışırken depoda v7 bulunması, sözleşmenin temel amacını boşa çıkarabilir. Bu nedenle güncelleme olayı takvime veya sürüme bağlanmalıdır. Örneğin her majör sürümden sonra belirli gün içinde, her üç ayda bir veya üretime geçen her kritik güncellemede yeni depo paketi teslim edileceği kararlaştırılabilir.

Güncelleme yükümlülüğü yalnız yazılım sahibine bırakılmamalı; escrow saklayıcısının teslimi aldığına ve paketin temel bütünlük kontrolünü yaptığına ilişkin kayıt üretmesi de düzenlenmelidir. Müşteri, ticari sır niteliğindeki kaynak kodu görmeden “son depo tarihi”, “sürüm numarası”, “paket büyüklüğü”, “hash” ve “doğrulama sonucu” gibi meta bilgileri izleyebilmelidir.

TBK m.112, borcun hiç veya gereği gibi ifa edilmemesinden doğan zararın tazmini çerçevesini düzenler. Depo güncelleme yükümlülüğü sözleşmede açık bir edim hâline getirilirse, yerine getirilmemesi yalnız teknik eksiklik değil sözleşmeye aykırılık olarak da ele alınabilir. Bununla birlikte tazminat hükmü, iş sürekliliğini tek başına sağlamaz; asıl amaç güncel materyalin gerçekten depoda bulunmasıdır.

4. Doğrulama ve Derlenebilirlik Testi Neden Gereklidir?

Kaynak kod paketinin var olması, paketin çalışır yazılıma dönüştürülebileceğini kanıtlamaz. Eksik kütüphane, özel build aracı, unutulmuş environment tanımı veya üçüncü taraf bağımlılık nedeniyle kod derlenemeyebilir. Bu nedenle escrow hizmeti “saklama” ve “doğrulama” olarak iki seviyeye ayrılabilir.

Temel doğrulamada dosya bütünlüğü, virüs taraması, arşivin açılabilirliği ve belge listesinin varlığı kontrol edilir. İleri doğrulamada ise izole bir ortamda yazılımın sözleşmede tarif edilen adımlarla derlenmesi, test paketinin çalıştırılması ve belirli çıktının üretilmesi denenebilir. Hangi seviyenin uygulanacağı sözleşmede net biçimde yazılmalıdır; “escrow agent uygun görürse kontrol eder” gibi belirsiz ifade kritik projelerde yeterli değildir.

Doğrulama raporunun tarihi, kullanılan paket, test edilen bileşenler, başarısız adımlar ve istisnalar kayıt altına alınmalıdır. Üretim verisi kullanılmadan sentetik test verisiyle yapılan doğrulama, hem bilgi güvenliği hem KVKK bakımından daha güvenli bir yöntemdir.

5. Açılma Şartları Nasıl Yazılmalıdır?

Escrow sözleşmesinin en kritik bölümü release event yani açılma olayıdır. Şart, objektif olarak doğrulanabilir nitelikte kurulmalıdır. “Tedarikçiye güven kalmaması” veya “müşterinin hizmetten memnun olmaması” gibi subjektif ifadeler uyuşmazlığı büyütür. Bunun yerine hukuki veya teknik olay açıkça tanımlanmalıdır.

Faaliyetin tamamen sona ermesi, belirli ürüne ilişkin destek hizmetinin kalıcı olarak durdurulması, kesinleşmiş iflas kararı, tasfiye nedeniyle ürün desteğinin yapılamaması veya sözleşmede tanımlanan kritik destek ihlalinin ihtara rağmen belirli sürede giderilmemesi gibi olaylar ayrı ayrı yazılabilir. Bir olayın varlığını hangi belgeyle kimin doğrulayacağı da belirlenmelidir.

Şart gerçekleştiğinde yazılım sahibine bildirim ve itiraz süresi tanınacaksa bunun kaç gün olduğu, hangi kanaldan bildirim yapılacağı ve itirazın teslimi durdurup durdurmayacağı açık olmalıdır. Acil iş sürekliliği ihtiyacı ile tedarikçinin ticari sırrının korunması dengelenmelidir.

6. İflas veya Faaliyetin Sona Ermesi Otomatik Açılma Sebebi midir?

Ancak sözleşmede bu şekilde tanımlanmışsa açılma sebebi olur. Escrow mekanizmasında amaç, tarafların “iflas” kelimesini kullanması değil, müşterinin bakım ve sürdürülebilirlik hizmetini artık alamadığı hukuki olayın açıkça saptanmasıdır. İflas başvurusu, geçici mühlet, konkordato, tasfiye kararı ve fiilen ürün desteğinin kesilmesi aynı hukuki olay değildir.

Bu nedenle “şirket mali güçlüğe girerse kod açılır” hükmü yerine, hangi resmî kararın veya hangi fiilî hizmet kesintisinin release event oluşturacağı yazılmalıdır. Sözleşmenin amacı tedarikçinin her finansal sorununda kaynak kodunu ifşa etmek değil, yazılımın sürdürülebilirliğinin gerçekten ortadan kalktığı durumda müşteriyi korumaktır.

7. Destek Hizmetinin Kesilmesi Nasıl Ölçülür?

Destek kesintisi açılma nedeni yapılacaksa SLA ile escrow hükmü birbiriyle uyumlu olmalıdır. Kritik seviye arızanın tanımı, ilk yanıt süresi, çözüm veya workaround süresi, müşteri tarafındaki bağımlılıklar ve mücbir sebep istisnaları belirlenmelidir. Tek bir gecikme nedeniyle kaynak kodun açılması ile aylarca hizmet verilememesi aynı ağırlıkta değerlendirilmemelidir.

Pratikte release olayı; “kritik üretim arızasının sözleşmedeki giderme süresinin aşılmasından sonra yazılı ihtara rağmen ek düzeltme süresinde giderilmemesi” veya “bakım hizmetinin haklı neden olmadan tamamen durdurulması” gibi çok aşamalı kurulabilir. Bu düzenleme, tarafların hangi olayın kod açılmasına yol açacağını önceden bilmesini sağlar.

8. Kaynak Kodun Teslimi Telif Hakkının Devri midir?

Hayır. Bir USB disk, arşiv dosyası veya Git deposu erişiminin müşteriye verilmesi, yazılım üzerindeki mali hakların tamamını kendiliğinden devretmez. FSEK’te mali haklar ayrı haklar olarak düzenlenmiştir ve FSEK m.52 mali haklara ilişkin sözleşmelerin yazılı olmasını, hakların ayrı ayrı gösterilmesini şart koşar.

Escrow sözleşmesi açılma hâlinde yalnız bakım ve iş sürekliliği için sınırlı ruhsat verebilir. Örneğin müşteriye kendi işletmesindeki kurulumları sürdürmek, hatayı düzeltmek ve zorunlu uyarlamayı yapmak için kullanım yetkisi tanınırken; kaynak kodu üçüncü kişilere satmak, yeni bir ticari ürün çıkarmak veya rakip işletmelere lisanslamak açıkça yasaklanabilir.

FSEK m.52 hakkında daha ayrıntılı açıklama için telif sözleşmesinde yazılı şekil ve hakların ayrı ayrı gösterilmesi rehberi incelenebilir.

9. Açılmadan Sonra Müşteriye Hangi Kullanım Yetkisi Verilmelidir?

Yetki, projenin iş sürekliliği ihtiyacına göre sınırlandırılmalıdır. Kullanımın yalnız müşterinin kendi sistemleri için mi yoksa grup şirketlerini de kapsayacak şekilde mi yapılacağı; bakımın müşteri personeli tarafından mı yoksa seçilecek üçüncü taraf bakım şirketi tarafından mı yürütülebileceği; kaç kurulumun destekleneceği ve değiştirilen kodun kime ait olacağı sözleşmede yazılmalıdır.

Üçüncü taraf bakım şirketine kod gösterilecekse, bu şirketin gizlilik yükümlülüğü, erişim yetkisi, alt yüklenici yasağı, kopya sayısı ve iş bitiminde silme yükümlülüğü ayrıca düzenlenmelidir. Müşterinin “bakım için üçüncü kişiden yardım alabilmesi” ile “kodu dilediği üçüncü kişiye devredebilmesi” aynı hak değildir.

10. Açık Kaynak ve Üçüncü Taraf Bileşenler Nasıl Ele Alınır?

Kurumsal yazılımların önemli bölümü açık kaynak kütüphaneler, ticari SDK’lar, veritabanı sürücüleri, harita servisleri, ödeme API’leri veya başka üçüncü taraf bileşenlerle çalışır. Escrow deposunda bu bileşenlerin tamamının kopyasını bulundurmak her zaman lisans bakımından mümkün olmayabilir.

Sözleşmede Software Bill of Materials veya en azından bileşen listesi, sürüm, lisans türü ve edinme adresi tutulmalıdır. Müşteri, açılma gününde yazılım sahibinin devredemeyeceği bir üçüncü taraf lisansına bağımlı kalırsa kaynak kodu elinde olsa bile sistemi çalıştıramayabilir. Bu nedenle “teslim edilebilir materyal” ile “müşterinin ayrıca lisanslaması gereken bileşen” ayrılmalıdır.

Açık kaynak kullanımı otomatik olarak sınırsız hak anlamına gelmez. Kullanılan lisansın bildirim, kaynak kod sağlama, türev çalışma veya yeniden dağıtım şartları ayrı değerlendirilmelidir. Sitenin yazılımın telif hakkıyla korunması rehberi genel fikrî hak çerçevesini açıklamaktadır.

11. Ticari Sır ve Gizlilik Nasıl Korunmalıdır?

Kaynak kod çoğu yazılım şirketi için en değerli ticari varlıklardan biridir. Escrow saklayıcısı koda yalnız hizmetin gerektirdiği ölçüde erişmeli, yetkili personel listesi sınırlı tutulmalı ve erişimler loglanmalıdır. Depolama alanında güçlü şifreleme, çok faktörlü kimlik doğrulama, rol bazlı erişim ve yedekleme uygulanmalıdır.

Saklayıcının kodu analiz, eğitim, ürün geliştirme veya başka müşteri projeleri için kullanamayacağı açıkça yazılmalıdır. Alt hizmet sağlayıcı kullanılacaksa bunun hangi koşullarda mümkün olduğu ve aynı gizlilik/güvenlik yükümlülüklerinin alt sağlayıcıya nasıl aktarıldığı düzenlenmelidir.

12. KVKK Açısından Kaynak Kod Deposunda Ne Olmamalıdır?

Kaynak kod deposuna gerçek müşteri veritabanı, üretim yedeği, kullanıcı kimlik bilgileri veya test için kopyalanmış kişisel veri konulması çoğu durumda gerekli değildir. 6698 sayılı KVKK m.4 gereği kişisel veri belirli, açık ve meşru amaçla; amaçla bağlantılı, sınırlı ve ölçülü işlenmelidir. KVKK m.12 veri güvenliği tedbirlerini de veri sorumlusu bakımından açık bir yükümlülük hâline getirir.

Escrow doğrulaması için sentetik veya anonim test verisi tercih edilmelidir. Kişisel veri bulunması zorunlu teknik bir sebebe dayanıyorsa veri kategorisi, işleme şartı, saklama süresi, erişim yetkisi ve silme prosedürü ayrıca belirlenmelidir. Yabancı ülkedeki escrow hizmeti kullanılıyorsa KVKK m.9 kapsamındaki yurt dışına aktarım rejimi ayrıca değerlendirilir. Bu konuda yabancı bulut ve SaaS kullanımında KVKK yurt dışına aktarım rehberi incelenebilir.

13. Exit ve Geçiş Desteği Escrow’dan Ayrı mı Yazılmalıdır?

Evet. Kaynak kodun açılması, yeni ekibin sistemi ertesi gün sorunsuz devralacağı anlamına gelmez. Sözleşmede belirli bir geçiş döneminde mimari açıklama, build süreci, deploy adımları, veritabanı şeması, API dokümantasyonu ve kritik konfigürasyon bilgilerine ilişkin handover yükümlülüğü düzenlenebilir.

Escrow, tedarikçi tamamen ortadan kalktığında son güvenlik ağıdır. Normal sözleşme sona ermesinde kaynak kodun açılmasına gerek kalmadan veri ihracı, konfigürasyon teslimi, yönetici hesaplarının devri ve yeni tedarikçiye makul geçiş desteği sağlanması daha sağlıklı bir exit modelidir.

14. Bildirim, İtiraz ve Delil Düzeni Nasıl Kurulmalıdır?

Release talebi yazılı ve ispatlanabilir kanaldan yapılmalıdır. Talebin hangi sözleşme maddesine dayandığı, release event’in hangi belgeyle doğrulandığı ve teslim edilecek paket sürümü kayda geçirilmelidir. Tedarikçiye itiraz hakkı tanınmışsa itiraz süresi ve itiraz merciinin rolü net olmalıdır.

Saklayıcı her depo güncellemesinde teslim makbuzu, hash değeri ve doğrulama sonucu üretmelidir. Açılma hâlinde de hangi dosyaların hangi tarihte kim tarafından indirildiği loglanmalıdır. Bu kayıtlar daha sonra “eski sürüm verildi”, “kod eksikti” veya “yetkisiz üçüncü kişiye aktarıldı” iddialarının incelenmesinde önem taşır.

15. Escrow Sözleşmesinde Bulunması Gereken Asgari Başlıklar

• Tarafların ve bağımsız saklayıcının açık kimliği,
• Escrow’a konu yazılım ve sürümlerin tanımı,
• Kaynak kod, build script, bağımlılık ve dokümantasyon listesi,
• İlk teslim ve periyodik güncelleme takvimi,
• Hash/bütünlük kontrolü ve doğrulama seviyesi,
• Açılma olaylarının objektif tanımı,
• Bildirim ve itiraz prosedürü,
• Açılma sonrasında müşterinin kullanım yetkisinin kapsamı,
• FSEK m.52’ye uygun mali hak/ruhsat düzeni,
• Üçüncü taraf bakım şirketine erişim şartları,
• Açık kaynak ve ticari üçüncü taraf lisanslarının listesi,
• Gizlilik, erişim logu ve bilgi güvenliği hükümleri,
• KVKK kapsamında kişisel veri bulunmaması veya zorunluysa işleme düzeni,
• Exit ve teknik geçiş desteği,
• Sözleşme sona erdiğinde saklanan kopyaların silinmesi veya iadesi.

16. Site İçindeki İlgili Rehberler

Yazılım ve fikrî haklar açısından Yazılımın Telif Hakkıyla Korunması, lisans ve mali hak şekli için FSEK m.52 Yazılı Şekil Rehberi, yasal kullanıcı hakları için FSEK m.38 Yazılım Yedek Kopya Rehberi ve uluslararası SaaS sözleşmeleri için SaaS Sözleşmesi Kontrol Rehberi birlikte incelenebilir.

17. Resmî Kaynaklar

• 6098 sayılı Türk Borçlar Kanunu – özellikle m.26 ve m.112
• T.C. Kültür ve Turizm Bakanlığı Telif Hakları Genel Müdürlüğü – Telif Hakkı Nedir?
• Telif Hakları Genel Müdürlüğü – Güncel Mevzuat
• Kişisel Verileri Koruma Kurumu – 6698 sayılı KVKK

18. Sık Sorulan Sorular

Kaynak kodu escrow Türkiye’de zorunlu mu?

Genel nitelikte bütün yazılım sözleşmeleri için kanundan doğan bir escrow zorunluluğu yoktur. Taraflar TBK m.26 kapsamında sözleşmeyle escrow mekanizması kurabilir.

Kaynak kod escrow’a bırakılınca müşteri kodun sahibi olur mu?

Hayır. Depoya bırakma teknik saklama işlemidir. Mali hak devri veya kullanma yetkisi ayrıca ve FSEK m.52’ye uygun biçimde düzenlenmelidir.

Escrow paketinde yalnız kaynak kod yeterli mi?

Çoğu projede yeterli değildir. Derleme betikleri, bağımlılıklar, veritabanı şemaları, migration dosyaları ve kurulum dokümantasyonu da iş sürekliliği için gerekli olabilir.

Her sürüm escrow’a bırakılmalı mı?

Sözleşmede güncelleme olayı belirlenmelidir. Majör sürüm, kritik üretim sürümü veya periyodik takvim esas alınabilir; depodaki sürüm ile üretimdeki sürüm arasında kontrol edilemeyen fark bırakılmamalıdır.

İflas başvurusu olunca kod otomatik açılır mı?

Yalnız sözleşmede açıkça tanımlanan release event gerçekleşirse açılır. Başvuru, geçici hukuki koruma, kesin iflas ve fiilî hizmet kesilmesi ayrı olaylardır.

Müşteri kodu üçüncü bir yazılım şirketine verebilir mi?

Bu yetki sözleşmede açıkça tanımlanmalıdır. Bakım amacıyla belirli üçüncü kişiye erişim verilmesi ile mali hakkın üçüncü kişiye devri aynı işlem değildir.

Escrow saklayıcısı kodu test edebilir mi?

Sözleşmede doğrulama yetkisi verilmişse belirlenen kapsamda test edebilir. Testin dosya bütünlüğü seviyesinde mi yoksa derleme/çalıştırma seviyesinde mi olacağı açıkça yazılmalıdır.

Depoya canlı müşteri veritabanı konulmalı mı?

Kural olarak hayır. Kaynak kodun doğrulanması için gerçek kişisel veri gerekli değilse sentetik veya anonim test verisi kullanılmalıdır. KVKK m.4’teki sınırlılık ve ölçülülük ilkesi uygulanır.

Yurt dışındaki escrow şirketi kullanılabilir mi?

Kullanılabilir; ancak depoda kişisel veri bulunuyorsa KVKK m.9 yurt dışına aktarım rejimi ayrıca kurulmalıdır. Ticari sır ve erişim güvenliği de sözleşmede düzenlenmelidir.

Escrow sözleşmesi bakım ve destek sözleşmesinin yerine geçer mi?

Hayır. Escrow son güvenlik ağıdır. SLA, bakım, güncelleme, exit ve geçiş desteği ana yazılım sözleşmesinde ayrıca düzenlenmelidir.

19. Uygulamada İzlenecek Net Yol

Önce işletme açısından kritik yazılımlar belirlenir. Her yazılım için kaynak koda erişememenin iş sürekliliği etkisi, üçüncü taraf bağımlılıklar ve tedarikçi riski çıkarılır. Escrow gerekli ise depoya girecek teknik materyal ek listede tek tek yazılır; güncelleme takvimi ve doğrulama seviyesi belirlenir. Ardından release event’ler objektif belgeler ve sürelerle tanımlanır. Son olarak açılma hâlinde müşteriye verilecek kullanım yetkisi FSEK m.52’ye uygun biçimde yazılır ve gereksiz kişisel veri depoya sokulmaz.

Bakırcı & Keskin Hukuk Bürosu, yazılım geliştirme, SaaS, lisans, escrow, fikrî hak devri, KVKK ve teknoloji tedarik sözleşmelerini sözleşme metni ile gerçek teknik akışı birlikte inceleyerek değerlendirmektedir. Türkiye genelindeki dosyalar Mersin’deki İstanbul ve Mersin’deki fiziksel ofislerden koordine edilir.

Av. Halil Bakırcı tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

Avukat Halil BAKIRCI, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Av. Halil Bakırcı profilini inceleyin →