Mobil Uygulama App Store’dan Reddedildi: Yazılımcının Yayın ve Ücret Sorumluluğu

Mobil uygulamanın App Store incelemesinden geçmemesi, yazılım firmasının her durumda kusurlu olduğunu göstermez. Ancak mağaza kararının üçüncü kişiden gelmesi de firmanın sözleşmede üstlendiği yayın hazırlığı, uygun geliştirme, başvuru ve düzeltme borçlarını ortadan kaldırmaz. Ret mesajı, gönderilen uygulama sürümü ve kabul edilen iş kapsamı birlikte incelenmelidir.

Türk hukukuna tabi geliştirme sözleşmesinde belirli uygulama sonucunun üstlenilmesi bakımından TBK m. 470–477; bedelin zamanı bakımından m. 479 önem taşır. Mağazaya yalnız başvuru yapılması ile uygulamanın belirli koşullarla yayımlanmasının üstlenilmesi farklıdır. Müşterinin bakiye ödeme, düzeltme ve sona erdirme talepleri bu ayrım üzerine kurulmalıdır.

Sözleşmede kod teslimi mi, mağazada yayın mı üstlenildi?

Teklif, teknik ek, teslim takvimi ve kabul ölçütleri birlikte okunur. Çalışan bir uygulama dosyasının hazırlanması, mağaza başvurusunun yapılması ve yayının gerçekleşmesi ayrı aşamalardır. “Yayına hazır” ifadesinin hangi teknik ve hukuki işlemleri kapsadığı somutlaştırılmalıdır. Şirketin yalnız kendi cihazında test yapabilmesiyle kullanıcıların uygulamayı mağazadan indirebilmesi aynı teslim değildir.

TBK m. 19 gerçek ortak iradeyi esas alır. Satış görüşmesindeki açık yayın taahhüdüyle sözleşme eki arasında çelişki varsa belgeler değerlendirilir. Buna karşılık her geliştirme sözleşmesine sınırsız mağaza onayı garantisi eklenemez. Ana işin sonucu, başvuru desteği ve sonradan bakım ayrı edimler olarak tanımlanmışsa her birinin yerine getirilip getirilmediği ayrı belirlenir.

Ret mesajında hangi bilgi esas alınmalıdır?

Ret tarihinin yanında uygulama kimliği, gönderim numarası, sürüm ve gerekçe saklanır. Farklı sürümlere ilişkin mesajlar birbirine karıştırılmamalıdır. Mağazanın yalnız ek bilgi istemesi, başvurunun teknik nedenle ilerleyememesi ve tamamlanmış incelemede ret vermesi aynı durum değildir. Firmanın müşteriye gönderdiği kısa özet yerine gerçek inceleme yazışması görülmelidir.

Apple’ın resmî ret mesajı açıklaması, ret gerekçesinin App Store Connect üzerinden iletildiğini ve destekleyici belgelerle cevap verilebildiğini belirtir. Bazı üst veri sorunlarında düzeltmeden sonra aynı uygulama yapısı yeniden sunulabilir. Bu teknik ayrım, her ret için bütün uygulamanın yeniden yazılması gerektiği iddiasının ayrıca doğrulanmasını gerektirir.

Yazılım firmasının mesleki özeni nasıl değerlendirilir?

Eser niteliğindeki geliştirmede TBK m. 471, sadakat ve mesleki özen borcunu düzenler. Aynı alandaki basiretli yüklenicinin mesleki ve teknik kurallara uygun davranışı esas alınır. Kararlaştırılmış yayın kanalının bilinen başvuru gereksinimlerini incelemek, işi bunlara göre yürütmek ve somut engeli zamanında açıklamak bu değerlendirmede önemlidir. Sadece kodun derlenmesi bütün yayın borcunun ifası sayılmaz.

Apple App Review Guidelines, başvuru öncesinde işlevlerin test edilmesini, gerekli bilgilerin tamamlanmasını ve incelemeye erişim verilmesini açıklar. Giriş gerektiren uygulamada inceleme hesabı ve arka sistemin erişilebilirliği de teknik değerlendirme içindedir. Bu koşullar bir Türk kanun maddesi değildir; üstlenilen uygulamanın o mağazaya hazırlanmasındaki somut teknik ölçütlerdir. Sözleşmesel sorumluluğun hukuki temeli ayrıca kurulmalıdır.

Firma mağazanın onay riskini üstlenmiş olabilir mi?

Sonucun üçüncü kişi kararına bağlı olması, tarafların bu riskin mali sonucunu sözleşmede paylaşmasına engel değildir. TBK m. 26 kapsamında kabul edilen garanti, iade veya başarıya bağlı ücret düzeni incelenir. TBK m. 128 ise üçüncü kişinin fiilini başkasına karşı üstlenenin, fiilin gerçekleşmemesinden doğan zararı giderme yükümlülüğünü düzenler. Hükmün uygulanması için gerçekten böyle bir üstlenme bulunmalıdır.

“Başvuruyu yönetiriz” sözüyle “ret hâlinde bedeli iade ederiz” taahhüdü aynı değildir. Genel tanıtım ifadesi, belirsiz kapsamlı bir üçüncü kişi fiili garantisine dönüştürülmemelidir. Onay riskinin belirli ülke, sürüm veya süre için üstlenilip üstlenilmediği açıklanır. Üstlenmenin koşulları ve varsa yazılı başvuru düzeni kendi metniyle değerlendirilir. Mağazanın tarafı olmadığı müşteri sözleşmesi, mağazayı onay vermekle yükümlü kılmaz.

Ret nedeni hangi tarafa ait işten kaynaklanıyor?

Uygulamanın çalışmaması, açıklamasının eksikliği, müşterinin sunacağı izin belgesinin bulunmaması ve işletme modelinin mağaza şartlarına aykırılığı ayrı sebeplerdir. Her gerekçe, sözleşmede ilgili işi üstlenen tarafla eşleştirilir. Birden fazla ret gerekçesi varsa yalnız kolay giderilen hata kapatılarak diğerlerinin görmezden gelinmesi doğru değildir. Tam ret listesinin hangi bölümünün ne zaman çözüldüğü izlenmelidir.

Müşterinin hesabı veya belgesiyle ilgili sorun bulunması, yazılımcının bağımsız teknik hatasını ortadan kaldırmaz. Yazılımcının hata yapması da müşterinin kendi borcunu yerine getirmediği süreyi otomatik ona yüklemez. Gecikmenin her aşaması için etkili sebep gösterilir. Bu ayrım, düzeltme masrafını, teslim tarihini ve olası zarar hesabını aynı somut veriler üzerinde tartışmayı sağlar.

Müşteri sorunlu işlevde ısrar etmişse sonuç nedir?

TBK m. 472, eserin gereği gibi veya zamanında meydana getirilmesini tehlikeye düşüren durumun hemen iş sahibine bildirilmesini düzenler. Firma, müşterinin istediği işlevin yayın kanalında somut engel oluşturduğunu tespit etmişse riski açıklaştırmalıdır. Teknik yazışmalarda belirsiz bir “sıkıntı çıkabilir” notu yerine hangi şartın hangi özellik nedeniyle karşılanmadığı gösterilmelidir.

TBK m. 476, açık uyarıya rağmen verilen talimattan doğan veya iş sahibine yüklenebilen ayıp bakımından iş sahibinin ayıp haklarını sınırlar. Her ret müşteriye yüklenemez; talimat, uyarı ve sonuç arasındaki bağlantı belirlenir. Müşterinin ekran tasarımını onaylaması, açıklanmamış mağaza engelinin bütün riskini üstlendiği anlamına gelmez. Firmanın kendi mesleki hataları ayrıca değerlendirilir.

Geliştirici hesabı ve başvuru yetkisi neden önemlidir?

Uygulamanın hangi hesap altında hazırlanacağı, başvuruyu kimin yapacağı ve müşterinin hangi bilgileri sağlayacağı belirlenmelidir. Kullanılan hesapta gerekli yetki bulunmaması, kodun ayıplı olmasıyla aynı sorun değildir. Hesap sahibi şirket, başvuruyu yöneten firma ve teknik geliştiricinin görevleri ayrılır. Müşterinin erişimi yoksa ret mesajı ve başvuru geçmişi firma tarafından eksiksiz aktarılmalıdır.

Gönderim için gereken müşteri işlemi açıkça istenmiş ve yapılmamışsa bunun takvime etkisi gösterilir. Buna karşılık firma gerekli yetkinin bulunmadığını teslim gününde ilk kez açıklıyorsa zamanında planlama ve uyarı borcu incelenir. Paylaşılan bir şifrenin varlığı, bütün işlemler için sınırsız temsil yetkisi anlamına gelmez. Sözleşme şartlarını kabul etme ve ücretli işlem yapma yetkisi ayrıca belirlenmelidir.

Müşterinin test kabulü mağaza reddini kapatır mı?

İç test, teknik kabul ve mağazada yayın farklı aşamalardır. Kabul tutanağının hangi sürümü ve hangi edimleri kapsadığı görülmelidir. Eserin tesliminden sonra TBK m. 474 kapsamındaki gözden geçirme ve ayıp bildirimi yükümlülüğü gündeme gelir. Yazılımda kabul ve ayıp bildirimi değerlendirmesi, mağaza başvurusunun kapsamını açıklayan sözleşmeyle birlikte yapılır.

TBK m. 477 kabulün sonuçlarını ve kasten gizlenen veya usulüne uygun incelemede fark edilemeyen ayıplar için devam eden sorumluluğu düzenler. Sonradan ortaya çıkan ayıp gecikmeksizin bildirilmelidir. “Test tamamlandı” belgesi, henüz yapılmamış başvuru işleminin kendiliğinden kabulü değildir. Aynı şekilde açıkça kabul edilen bir teknik özelliğin sonradan nasıl bir ret sebebi oluşturduğu delillendirilmelidir.

Ret sonrası her düzeltme için yeni ücret istenebilir mi?

Kararlaştırılmış işin ayıpsız ve sözleşmeye uygun hâle getirilmesi ile müşteri tarafından eklenen yeni özellik ayrılır. TBK m. 475, yüklenicinin ayıptan sorumlu olduğu durumda aşırı masraf gerektirmeyen ücretsiz onarımı seçimlik haklar arasında düzenler. Her ret yeni sipariş değildir. Firmanın daha önce yerine getirmesi gereken teknik şartı düzeltmesi, yalnız ek çalışma saati yazıldığı için yeni ücret borcuna dönüşmez.

Gerçek ek kapsam varsa hangi özellik, bedel ve süreyle kabul edildiği belgelenir. TBK m. 480 kapsamında götürü bedelli işte öngörülenden fazla emek ve masraf, tek başına bedel artışı sebebi değildir. Kanuni özel uyarlama koşulları ayrı incelenir. Retten sonra bütün uygulama mimarisinin değiştirilmesi öneriliyorsa bunun eski taahhüdün giderimi mi yoksa yeni iş modeli mi olduğu teknik olarak açıklanmalıdır.

Düzeltme ve yeniden başvuru nasıl belgelenmelidir?

Hangi ret maddesinin hangi değişiklikle giderildiği yazılmalıdır. Değişiklik listesi, kaynak sürümü, test sonucu, gönderilen yapı ve yeni başvuru tarihi birbirini izlemelidir. Müşterinin kendisine gösterilen sürümle mağazaya gönderilen sürümün aynı olduğunu doğrulaması önemlidir. Ret mesajı dururken yeni sürümün başarıyla yüklendiğini söylemek, incelemenin kabul edildiğini göstermez.

Apple’ın resmî inceleme açıklamaları, ret sonrasında iletişim ve uygun hâllerde itiraz yollarını ayrı ele alır. Yeniden başvuru, açıklama gönderme ve itiraz başvurusunun hangisinin seçildiği kaydedilir. Müşteri sözleşmesindeki destek borcu bu işlemlerden hangilerini kapsıyorsa firma onları gereği gibi yürütmelidir. Başvuru yapılmış olması sonuç garantisi değildir; hiçbir başvuru yapmadan yalnız beklemek de üstlenilen işi tamamlamaz.

Bir platformda yayınlanması diğer platformun borcunu kapatır mı?

Sözleşmede birden fazla işletim sistemi veya dağıtım kanalı üstlenilmişse her teslimin kapsamı belirlenir. Bir sürümün yayımlanması diğer sürümdeki eksikliği kendiliğinden gidermez. Bununla birlikte başarıyla teslim edilen bağımsız bölümün ekonomik değeri de yok sayılmaz. Ortak altyapı kullanılması, bütün sürümlerin teknik ve hukuki durumunun aynı olduğunu göstermez. Reddedilen başvurunun hangi platform ve ülke dağıtımını etkilediği açıklanmalıdır.

Parça teslimi ve ayrı bedel düzeni varsa TBK m. 479 bunun muacceliyete etkisini belirler. Tek bütün sonuç kararlaştırılmışsa değerlendirme o sonuç üzerinden yapılır. Firma, çalışan başka bir sürümü göstererek reddedilen sürümün düzeltme borcunu açıklamasız sona erdiremez. Müşteri de kullanılabilir kısmı fiilen kullanırken tüm çalışmanın değerini sıfır sayan bir hesap kurmamalıdır.

Mağaza reddi sürerken bakiye ücret muaccel olur mu?

TBK m. 479 eser bedelinin teslim anında muacceliyetini; parça teslimi ve parçalara göre bedel kararlaştırılmışsa her parçanın teslimini düzenler. Tarafların özel ödeme takvimi ayrıca değerlendirilir. Kod teslimine bağlı taksit ile mağazada yayına bağlanan son taksit aynı değildir. Firmaya bütün kalan bedelin ödenip ödenmeyeceği, yalnız faturanın düzenlenmesine göre belirlenmez.

Ödeme gerçekten gelecekteki belirsiz yayın olayına bağlanmışsa TBK m. 170 kapsamında koşulun niteliği incelenir. Müşterinin karşılıklı edimi ve TBK m. 97 bakımından ifa sırası da göz önünde tutulur. Henüz yerine getirilmemiş yayın borcuyla teslim edilmiş bağımsız işin değeri ayrılmalıdır. Bir bölümde uyuşmazlık bulunması, bütün diğer edimlerin hiç yapılmamış sayılması sonucunu doğurmaz.

Vaat edilen lansman tarihinin kaçması neyi değiştirir?

Takvimde kod bitişi, mağazaya gönderim ve kamuya açılma tarihleri ayrı yazılmışsa hangisinin kaçırıldığı gösterilir. Mağaza incelemesinin süresi ile firmanın eksik başvuru nedeniyle kaybettiği süre aynı değildir. Başvurunun kararlaştırılmış tarihten sonra yapılması, dış inceleme gerekçesiyle kendiliğinden açıklanamaz. Firmanın hangi riski ne zaman bildirdiği ve takvimin değişip değişmediği araştırılır.

TBK m. 117 ve m. 123–125 temerrüt ve seçimlik hakları düzenler. m. 124’teki süre vermeyi gerektirmeyen hâller, her lansman tarihine otomatik uygulanmaz. İfanın gecikmeyle gerçekten yararsız kaldığı veya belirli zamanda gerçekleşmezse kabul edilmeyeceği sözleşmeden anlaşıldığı gösterilmelidir. Planlanmış bir reklam tarihi bulunması ile hukuken kesin vade sonucu doğması aynı değerlendirme değildir.

Mağaza kuralları proje sırasında değişirse risk kime aittir?

Değişikliğin tarihi, içeriği ve hangi başvuruyu etkilediği belirlenir. Sözleşme kurulurken zaten var olan gereksinim sonradan değişmiş gibi sunulmamalıdır. Sürüm yenileme ve uyarlama taahhüdü varsa kapsamı okunur. Yeni şartın hangi çalışmayı gerektirdiği, daha önce yapılan işin kullanılabilirliği ve alternatif uyum yolu teknik olarak gösterilmelidir.

Her politika değişikliği TBK m. 136 kapsamında kusursuz imkansızlık veya m. 138 kapsamında uyarlama sebebi değildir. İlgili maddenin bütün koşulları gerçekleşmelidir. İşin daha pahalı veya zahmetli olması tek başına ifanın imkansızlaştığını göstermez. Firmanın kendi gecikmesi nedeniyle yeni kurala tabi hâle gelen başvuru ayrıca değerlendirilir. Riskin sözleşmede geçerli biçimde kime bırakıldığı da bu incelemeye dahildir.

Düzeltme başka yazılımcıya yaptırılabilir mi?

İş devam ederken yüklenicinin kusuruyla ayıplı veya sözleşmeye aykırı sonucun açıkça ortaya çıkması hâlinde TBK m. 473/2’nin uygun süre ve ihtar düzeni incelenir. Genel yapma borcunda TBK m. 113 kapsamında hâkim izniyle başkasına ifa ayrı yoldur. Her reddin hemen ardından istenilen bedelle yeni firmaya iş verilip bütün faturanın eskisine yüklenmesi doğru değildir.

Yeni firmanın hangi hatayı gidereceği, mevcut kodu kullanma yetkisi ve giderin zorunluluğu belgelenir. Yazılımın telif koruması bakımından FSEK m. 49 ve m. 52 kapsamında hak zinciri ayrıca kontrol edilir. Düzeltme ihtiyacı, bütün kaynak kod mali haklarının kendiliğinden müşteriye geçtiği anlamına gelmez. Teslim yükümlülüğü ve yetki kapsamı sözleşmeyle karşılaştırılır.

Yayınlanmayan uygulamada zarar nasıl ispatlanır?

TBK m. 112 kapsamında ihlal, zarar ve nedensellik ortaya konur; borçlu kendisine kusur yüklenemeyeceğini ispat etmedikçe sorumludur. Başlangıç iş planındaki kullanıcı veya satış hedefi doğrudan gerçekleşmiş kayıp değildir. Boşa çıkan gider, zorunlu düzeltme masrafı ve kanıtlanabilir kazanç kaybı birbirinden ayrılır. Sonradan kullanılabilen reklam veya üretim çıktısının bütün bedeli zarar yazılmaz.

HMK m. 199 kapsamında gönderim kayıtları, ret yazışmaları, test raporları ve sözleşme ekleri belge olarak değerlendirilir. Kaybolma veya sonradan ileri sürmenin önemli ölçüde zorlaşması tehlikesinde HMK m. 400 uyarınca delil tespiti incelenir. Teknik bilirkişi hangi sürümün hangi sebeple reddedildiğini açıklar; hukuki sorumluluğa ilişkin değerlendirme mahkemenin görevindedir.

Çözüm anlaşması veya sona erme nasıl tamamlanmalıdır?

Devam edilecekse ret maddeleri, düzeltme kapsamı, gerekli müşteri belgeleri ve yeni gönderim takvimi belirlenir. Yayın sonucu için yeni garanti verilip verilmediği ve bedel hesabının nasıl işleyeceği açık yazılır. Sadece yeni tarih belirlemek, önceki gecikme veya zarar iddialarını kendiliğinden kapatmaz. Kabul belgesi yayınla ilgili açık kalan edimleri göstermelidir.

Sona ermede ihlale dayanan haklarla müşterinin serbest iptal tercihi ayrılmalıdır; ikinci durumda eser ilişkisinde TBK m. 484’ün farklı mali sonuçları vardır. Tacirler arasında temerrüt, fesih ve dönme bildirimlerinde TTK m. 18/3 ve uygun bildirim usulü gözetilir. Güncel kod, gönderim geçmişi, mevcut ret durumu ve kullanım yetkileri teslim tutanağında somutlaştırılmalıdır.

Sık sorulan sorular

App Store reddi yazılım firmasının kusurunu kesin kanıtlar mı?

Hayır. Ret nedeni, sözleşmedeki görev dağılımı ve gönderilen sürüm birlikte incelenir. Teknik hata, müşteri belgesinin eksikliği ve mağazanın bağımsız değerlendirmesi aynı değildir. Firmanın kendi başvuru ve özen borçları ayrıca sürer.

Firma yalnız başvuru yapmayı üstlendiyse yayın garantisi var mıdır?

Sırf başvuru desteği sınırsız sonuç garantisi değildir. TBK m. 19 kapsamında gerçek anlaşma belirlenir. Açık iade veya üçüncü kişi fiilini üstlenme düzeni varsa TBK m. 26 ve şartlarına göre m. 128 ayrıca değerlendirilir.

Müşterinin test onayı bütün mağaza retlerini kapatır mı?

Kabulün hangi sürüm ve edimi kapsadığı belirlenir. TBK m. 474 ve m. 477 uygulanırken henüz yapılmamış başvuru borcu ile teslim edilmiş iş ayrılır. Kasten gizlenen ve uygun incelemede fark edilemeyen ayıpların düzeni ayrıca korunur.

Her ret sonrası yeni geliştirme ücreti ödenir mi?

Hayır. Kararlaştırılmış işin giderimi ile yeni özellik ayrılır. TBK m. 475 şartlarında ücretsiz onarım hakkı bulunur. Götürü bedelli işte fazla çalışma tek başına fiyat artışı değildir; TBK m. 480 ve özel koşullar incelenir.

Müşteri riskli işlevde ısrar ederse firma sorumluluktan kurtulur mu?

TBK m. 476 için açık uyarı, talimat ve ayıp arasındaki ilişki veya başka biçimde müşteriye yüklenebilirlik belirlenmelidir. Genel tasarım onayı yeterli değildir. Firmanın bağımsız teknik hatası da müşterinin talimatına otomatik yüklenmez.

Bakiye ödeme her durumda mağazada yayına mı bağlıdır?

Hayır. TBK m. 479 ve kabul edilen ödeme takvimi incelenir. Kod teslimi, parça teslimi veya yayına bağlanan ödeme farklıdır. Yayın olayı koşul yapılmışsa TBK m. 170 ayrıca uygulanır; fatura tek başına tüm koşulları karşılamaz.

Yeni mağaza kuralı otomatik mücbir sebep midir?

Hayır. TBK m. 136 veya m. 138 için kendi kanuni koşulları gerçekleşmelidir. Sadece maliyet artışı yeterli değildir. Değişikliğin tarihi, sözleşmesel risk dağılımı ve firmanın önceki gecikmesinin etkisi ayrıca incelenir.

Düzeltme hemen başka firmaya yaptırılıp bedeli istenebilir mi?

Her durumda doğrudan böyle bir sonuç yoktur. TBK m. 473/2 kapsamında uygun süre ve ihtar; genel yapma borcunda m. 113 kapsamında hâkim izni ayrılır. Yeni işin gerekliliği, kapsamı ve kod kullanım yetkisi belgelenmelidir.

Lansman için beklenen bütün satışlar zarar sayılır mı?

Hayır. TBK m. 112 kapsamında gerçek zarar ve nedensellik ortaya konur. İş planındaki hedefler kendiliğinden gerçekleşmiş kazanç değildir. Düzeltme gideri, boşa çıkan masraf ve kanıtlanabilir kazanç kaybı ayrı değerlendirilir.

Mağaza reddine ilişkin hangi kayıtlar saklanmalıdır?

Uygulama kimliği, gönderim ve sürüm bilgisi, tam ret mesajı, teknik testler, cevaplar ve yeniden başvuru kayıtları saklanır. Farklı sürümlerin kararları karıştırılmaz. HMK m. 199 ve şartları varsa m. 400 bu kayıtların değerlendirilmesinde önemlidir.

İstanbul ve Mersin ofislerinde mobil uygulama yayın uyuşmazlığı değerlendirilirken sözleşmedeki teslim tanımı, ödeme takvimi, gönderilen sürüm ve tam ret yazışması birlikte incelenir. Teknik engelin hangi tarafın işine ait olduğu belirlenmeden bütün bedelin iadesi veya bütün bakiyenin ödenmesi sonucu kurulmaz. Talep, yayın taahhüdü, düzeltme borcu ve kanıtlanan ekonomik sonuç üzerinden hazırlanır.

Kanun maddeleri ve resmî kaynaklar

• 6098 sayılı Türk Borçlar Kanunu — güncel resmî UYAP metni: m. 19, 26, 97, 112–113, 117, 123–125, 128, 136, 138, 170, 470–480 ve 484
• 6102 sayılı Türk Ticaret Kanunu — güncel resmî UYAP metni: m. 18/3
• 6100 sayılı Hukuk Muhakemeleri Kanunu — güncel resmî UYAP metni: m. 199, 266 ve 400
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu — güncel resmî UYAP metni: m. 49 ve 52
• Apple Developer — App Review Guidelines: Başvuru öncesi hazırlık ve inceleme bölümleri
• Apple Developer — Reply to App Review messages: Ret mesajı ve inceleme yazışması

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 →