Ankara’da Özel Yazılımın Kabulü Yapıldı, Kaynak Kod Teslim Edilmedi: Depo Erişimi, Sözleşme ve Delil

Uyuşmazlığın ayırıcı noktası: çalışan sistem ile kaynak kod aynı değildir

Ankara’da özel yazılım geliştirme hizmeti alan bir şirket, uygulamanın çalışır hâlde teslim edilmesi ve kabul testinin yapılması sonrasında kaynak kod deposuna erişemediğini fark edebilir. Bunun üzerine yazılımın hiç teslim edilmediği, eksik teslim edildiği veya sözleşmeye uygun şekilde tamamlandığı iddiaları gündeme gelebilir. Öncelikle canlı çalışan hizmet, kurulabilir uygulama dosyası, kaynak kod, yapılandırma dosyası, test veri seti ve yönetici hesapları birbirinden ayrılmalıdır. Bunların hukuki teslim yükümlülüğü aynı değildir.

Bazı sözleşmeler yalnız kullanım hakkı ve işletilen hizmeti, bazıları kaynak kodun da iş sahibine bırakılmasını düzenler. Kaynak kodun teslim edilmemesi bu iki ilişki bakımından farklı sonuç doğurabilir. “Sistem çalışıyor” ifadesi, her koşulda kodun da teslim edildiğinin ispatı sayılmaz; fakat sözleşme kaynak kod teslimini hiç öngörmüyorsa yalnız bu eksiklik nedeniyle kesin ihlal sonucu da kurulamaz.

İlk kontrol: sözleşmede hangi çıktılar teslim edilecek?

Sözleşmenin teknik şartname, iş tanımı, sprint planı, kabul protokolü ve eklerinde kaynak kod veya sürüm deposu erişimi açıklanmış olabilir. Teslim listesi hazırlanırken depo adresi, hangi dalın teslim edileceği, sürüm etiketi, bağımlılıklar, derleme talimatları, veri modeli, bakım dokümantasyonu ve yetki hesapları ayrı başlıklarda gösterilir. Ödeme takvimi ve kapsam değişikliği belgeleri de bu listeyle eşleştirilir. Bir dosyanın teknik şartnamede yer almaması, başka bir ek sözleşmede hiç düzenlenmediği anlamına gelmez.

Yazılım geliştiricisi ile müşteri arasındaki yazılı talimatlar, proje yönetimi sistemi ve daha sonra yapılan sözleşme değişiklikleri karşılaştırılır. Yanlışlıkla yalnız proje sunumunda sözü edilen bir beklenti, üzerinde anlaşılmış teslim borcu gibi sunulmamalıdır. Uyuşmazlığın maddi temeli, hangi belirli dosyanın veya erişim hakkının hangi tarihte ve hangi koşullarda verileceğinin taraflarca üstlenildiğidir.

TBK 470: eser sözleşmesi niteliği otomatik değildir

Türk Borçlar Kanununun 470. maddesi eser sözleşmesini yüklenicinin eser meydana getirmeyi, iş sahibinin bunun karşılığında bedel ödemeyi üstlendiği sözleşme olarak tanımlar. Bir yazılımın sipariş üzerine geliştirilmesi somut şartlara göre eser sözleşmesi kapsamında değerlendirilebilir. Fakat sürekli sunucu işletme, abonelik, lisans, danışmanlık veya destek unsurları baskınsa sözleşme ilişkisi karma nitelik gösterebilir. Her teknoloji sözleşmesinin sırf “yazılım projesi” adıyla aynı hükümlere tabi olduğu varsayılmamalıdır.

Bu ayrım kaynak kodun mülkiyeti, sözleşmenin sona ermesi, teslim ve ücretin muacceliyeti bakımından önem kazanır. İş sahibinin yalnız belirli sonucun ortaya çıkarılmasını mı, yoksa devamlı işletme hizmetini mi satın aldığı açıklığa kavuşturulur. Genel hükümler, özel lisans koşulları ve somut sözleşmenin asıl edimleri birlikte incelenmelidir. Hukukî nitelendirme, belgenin kapağındaki başlığa değil, gerçek karşılıklı yükümlülüklere dayanır.

Kabul testi ile teslim tutanağının kapsamını okumak

Yazılım kabul tutanağında hangi sürümün, hangi test senaryosuyla ve hangi kullanıcı yetkisiyle incelendiği yazılmalıdır. Ekran üzerinden işlevsel bir kabul yapılmış olması, kaynak kod deposunun teslimine ilişkin ayrı borcun gerçekleştiği anlamına kendiliğinden gelmez. Tutanağın “tüm işler eksiksiz tamamlandı” gibi genel bir ifade içermesi durumunda tarafların o anda gerçekten hangi belgeleri teslim aldığı da araştırılır. Sözleşme ekleri ve sonradan yapılan yazışmalar önem taşıyabilir.

Kabul testlerinde hatalar bulunduysa bunların seviyesi, düzeltilme taahhüdü ve kabulün şarta bağlanıp bağlanmadığı ayrı kaydedilir. Kullanıcı kabul testi, bilgi güvenliği testi ve kod teslimi farklı işlemler olabilir. İş sahibinin test ortamına erişiminin bulunması depo yönetim hakkını otomatik vermez. Tutanak, somut hak ve borçları anlama bakımından diğer belgelerle birlikte yorumlanmalıdır.

Kaynak kod deposu erişimi hangi teknik unsurdan oluşur?

Git veya benzeri sürüm kontrol sistemlerinde depo adresinin paylaşılması yeterli olmayabilir. İş sahibine salt okuma yetkisi, katkı yetkisi veya tüm yönetim yetkisi verilmiş olabilir. Kapsam belirlenirken ilgili projenin depoları, alt modüller, etiketler, tüm geçmişin sunulup sunulmayacağı, CI/CD tanımları, test kaynakları ve erişimi sağlayan kişilerin kimliği açıklanmalıdır. Bunlar güvenlik ve sözleşme bakımından farklı meselelerdir.

Geliştirici yalnız en son kaynak paketini göndermişse bu işlemin depoya tam erişim borcunu karşılayıp karşılamadığı sözleşmeye bakılarak belirlenir. Kaynak kodun çalışabilmesi için gereken bağımlılıkların, lisansların ve yapılandırma bilgileri gibi bileşenlerin durumu teknik uzman tarafından incelenebilir. Teslim edilmeyen şeyin yalnız kullanıcı parolası mı yoksa sözleşmenin esaslı çıktısı mı olduğu doğru tarif edilmelidir.

Emanet hesap, depo sahibi ve alt yüklenici sorunu

Yazılım şirketinin projeyi kendi kurumsal hesabında geliştirmesi, başka geliştiricinin hesabını kullanması veya alt yükleniciye devretmesi sonucu erişim sorunu doğabilir. İş sahibinin talebinde gerçek depoyu işleten kişi, kod üzerindeki erişim yetkisi ve sözleşme ilişkisi birbirine karıştırılmamalıdır. Ana yüklenicinin teslim borcunu üstlenmiş olması, alt yüklenicinin hesabında bulunması nedeniyle kendiliğinden ortadan kalkmaz; ancak uygulamada üçüncü kişi hakları ve teknik erişim sınırları ayrı değerlendirilir.

Projeyi geliştiren çalışan veya taşeronun ticaret sicili, yetkisi, taahhütleri ve varsa fikrî hak düzenlemeleri incelenebilir. Şirketin bir kullanıcı hesabının şifresini istemesi, bütün üçüncü taraf hesaplarına izinsiz girme hakkı doğurmaz. Teknik devrin güvenli ve hukukî şekilde nasıl yapılacağı, işlem protokolü ve yetkilendirme ile çözümlenmelidir. Taraflardan hiçbiri kaynağı koruma gerekçesiyle başka kişilerin hesaplarını hukuk dışı erişime açmaya zorlanamaz.

TBK 471: yüklenicinin işin görülmesindeki borçları

Eser sözleşmesi nitelendirmesi uygun olduğunda TBK 471, yüklenicinin işi özenle yapma borcu ve işin görülmesindeki diğer yükümlülükler bakımından değerlendirilir. Özel yazılımın geliştirme sözleşmesinde yalnız ekranın açılması değil, kararlaştırılmış teknik teslimlerin de yerine getirilmesi gündeme gelebilir. Ancak kodun bir standartta yazılacağı, belli güvenlik kontrollerinden geçeceği veya belirli dokümantasyonla teslim edileceği iddiası somut şartnameyle desteklenmelidir.

Teknik rapor, yüklenicinin vaat ettiği çözümle gerçek teslimi karşılaştırmalıdır. Eksik kaynak kod ifadesi belirsiz bırakılmamalı; hangi modül, sürüm veya dokümanın bulunmadığı gösterilmelidir. Müşterinin sağlamak zorunda olduğu altyapı veya test erişimi verilmemişse bunun yüklenicinin ifasını etkileyip etkilemediği ayrıca incelenir. Yüklenicinin kusur veya sorumluluk değerlendirmesi yalnız proje yöneticisinin genel açıklamasına dayanamaz.

TBK 473: tamamlanmadan önce süreçteki sorunların ayrımı

TBK 473, yüklenicinin işe zamanında başlamaması, işi sözleşmeye aykırı biçimde geciktirmesi veya belirli şartlarda sözleşmeye aykırı iş meydana geleceğinin anlaşılması gibi hâllerle ilgili özel kurallar düzenler. Ancak kabul testi tamamlanmış ve yazılımın bir kısmı teslim edilmiş dosyada bu maddeyi doğrudan “kaynak kodu geri alma” hükmü gibi kullanmak doğru değildir. Öncelikle uyuşmazlığın hâlâ ifa aşamasında mı, yoksa ayıp veya eksik teslim aşamasında mı olduğu belirlenmelidir.

Takvime bağlı son teslim günü, kısmi teslimler ve tarafların yazışmaları incelenerek hangi borcun ne zaman muaccel olduğu açıklanır. Geliştiricinin geçici erişim vermesi veya bazı depoları paylaşması, bütün borcu yerine getirdiği anlamına gelmeyebilir. İş sahibinin teknik gereklilikleri sonradan değiştirmesi de değerlendirilir. Hukukî yolun seçiminde fiilî aşama doğru belirlenmelidir.

TBK 474: teslim sonrası inceleme ve ayıp bildirimi

TBK 474, eser teslim edildikten sonra iş sahibinin işlerin olağan akışına göre imkân bulur bulmaz eseri gözden geçirmesi ve ayıp varsa uygun süre içinde yükleniciye bildirmesi gerektiğini düzenler. Taraflardan her biri giderini karşılayarak eserin bilirkişi tarafından gözden geçirilmesini isteyebilir. Yazılım bakımından kabul testleri, erişim denemeleri ve eksiklik bildirimleri somut zaman çizelgesine konulmalıdır. Ancak bir kaynak kod teslim borcunun hiç yerine getirilmemesiyle mevcut teslimdeki ayıp aynı nitelendirme değildir.

Açık hata, gizli hata, kısmi ifa ve farklı sürüm teslimi birbirinden ayrılır. Uygulama çalışıyor olsa bile sözleşmedeki belirli rapor veya kod arşivinin eksik bırakılması ayrıca değerlendirilir. Bildirim yalnız “program kötü” şeklinde değil, tekrarlanabilen teknik sorun ve sözleşme maddesiyle ilişkilendirilmiş olmalıdır. Kanunî süre etkileri somut olayla belirlenir.

TBK 475: seçimlik hakları koşulsuz kazanım gibi sunmamak

Eserin ayıplı olması ve yüklenicinin sorumluluğunun doğması şartlarında TBK 475, eserin niteliğine ve ayıbın ağırlığına göre sözleşmeden dönme, bedelden indirim veya aşırı masraf gerektirmeyen ücretsiz onarım gibi seçimlik hakları düzenler. Genel hükümlere göre tazminat hakkı saklıdır. Ancak tüm kod teslim edilmedi iddiasının her zaman otomatik olarak bedelin tamamının iadesi sonucuna götüreceği söylenemez. Eksik teslim ile ayıp ayrımı ve şartlar incelenir.

İş sahibinin tüm sistemi kullanmaya devam etmesi, hangi seçimlik hakkın uygun olacağını etkileyebilecek fiilî durum yaratabilir. Yüklenicinin gerekli modülü tamamlayıp teslim etmesi mümkünse hangi yöntemin sözleşmeye uygun olduğu değerlendirilmelidir. Teknik düzeltme masrafları, alternatif sağlayıcıya geçiş ve ödeme belgeleri ayrı listelenir. Talepler somut hukukî gerekçeyle seçilmelidir.

TBK 479: ücretin muaccel olması ve teslimin etkisi

TBK 479, eser sözleşmesinde iş sahibinin bedel ödeme borcunun kural olarak eserin teslimi anında muaccel olduğunu; parça parça teslim kararlaştırılmış ve bedel parçalara göre belirlenmişse her parçanın bedelinin o parçanın tesliminde muaccel olacağını düzenler. Yazılımda siparişe özgü ödeme planı bulunabilir. Bu durumda sözleşmenin kısmi kabul, sürüm teslimi ve ödeme zamanına ilişkin maddeleri ayrıca incelenmelidir.

Kaynak kod deposu teslimi bir kilometre taşı olarak kararlaştırılmışsa ilgili ödeme diliminin şartı araştırılır. Buna karşılık yazılı sözleşme yalnız hizmet aboneliği ödemesi öngörüyorsa TBK 479’un doğrudan bütün faturaları belirlediği düşünülmemelidir. Hangi bedelin hangi somut teslim karşılığında istendiği tablo hâline getirilmelidir. Şirketlerin cari hesap veya avans kayıtları teslim belgelerinin yerine kullanılmamalıdır.

Kaynak kod hakkı ile telif ve kullanım lisansını ayırmak

Bir yazılımın kaynak kod dosyalarını fizikî veya dijital olarak teslim almak, o kod üzerindeki bütün mali hakların otomatik devredildiği anlamına gelmez. Fikir ve Sanat Eserleri Kanunu kapsamındaki hak ve lisans ilişkileri, sözleşmenin niteliği ve özel hükümlere göre ayrıca incelenmelidir. Kodun deposuna erişen kişi, kendi yazılımı üzerinde dilediği her ticari tasarrufu yapmaya yetkili olmayabilir. Tersinden, belirli kullanım hakkı verilmiş olması da her hâlde kaynak dosyanın teslim edilmesini gerektirmez.

Teslim borcu ile mali hak devri, kaynak kod güncelleme, değişiklik yapma ve üçüncü geliştiriciye aktarma izinleri ayrı kalemlerde belirlenir. Açık kaynak bağımlılıklarının lisans şartları da teknik teslim belgesinde gösterilebilir. Yüklenicinin başka müşteriler için geliştirdiği genel modüller ile bu proje için sözleşmeyle özel olarak meydana getirilen çıktılar birbirinden ayrılmalıdır. Genel “tüm haklar müşterinindir” cümlesi özel mevzuatın şekil ve kapsam şartları olmadan tek başına yorumlanmamalıdır.

Sürüm kontrol günlükleri teknik olarak nasıl incelenir?

Kod deposu erişim kaydında hangi kullanıcının hangi dalı, sürüm etiketini ve commit geçmişini görebildiği belirlenir. Projenin kabul edilen sürümü ile bugün sunulan paket arasında farklılık varsa yazılımın gerçekten hangi tarihte oluşturulduğu ve değiştirildiği teknik yöntemlerle araştırılabilir. Dosya adı ve klasör yapısı tek başına içerik bütünlüğünü kanıtlamaz. Hash ve sürüm kayıtları, değerlendirilen paketin kimliğini göstermek için kullanılabilir.

İş sahibinin talebi gerçekten kaynak kodun tamamına erişimse yalnız ekran görüntüsü verilmesi yeterli görünmeyebilir; fakat hangi borcun ifa edildiği yine sözleşmeye bağlıdır. Teknik inceleme, kodun bağımsız derlenip derlenemediğini, eksik modül ve bağımlılıkları, depo izinlerini, dokümantasyonu ve teslim edilen paketlerin bütünlüğünü karşılaştırmalıdır. Değerleme yapılmadan sistemin bilerek kilitlendiği iddiası kesin olgu kabul edilmemelidir.

Şirket verileri ile uygulama kaynak kodu aynı şey değildir

Kurumsal veritabanı yedeği, müşteri kayıtları, işlem günlükleri ve özel yazılımın kaynak kodu farklı hukukî ve teknik nesnelerdir. Kaynak kodun verilmemesiyle, hizmet sağlayıcının işletmenin kişisel verilerini veya muhasebe kayıtlarını iade etmemesi aynı sözleşme ihlali olmayabilir. Hangi verinin kime ait olduğu, sözleşmedeki veri sorumluluğu ve saklama yükümlülükleri ayrı incelenmelidir.

Örneğin müşteri tablosunun dışa aktarılması, yazılımın başka sunucuda yeniden kurulabileceği anlamına gelmez. Kod depo devri yapılmış ancak gerekli ortam değişkenleri verilmemişse uygulama çalışmayabilir. Teknik rapor bu eksiklikleri ayrı ayrı açıklamalıdır. KVKK kapsamındaki kişisel veriler üçüncü geliştiriciye aktarılırken yetki ve güvenlik şartları gözetilir. Hizmet değişikliği amacıyla veri talebinde bulunulması, başkasının ticari sırlarına sınırsız erişim izni oluşturmaz.

HMK 199: elektronik belge ve kod deposu delilleri

HMK 199, elektronik verileri vakıaları ispata elverişli belge kavramı içerisinde değerlendirir. Sürüm kontrol günlüğü, e-posta, proje yönetimi kaydı, kabul tutanağı ve teslim bağlantıları somut şartlarda belge niteliği taşıyabilir. Ancak belge olarak dosyaya sunulmaları, içeriklerinin gerçek ve değişmez olduğu konusunda kesin sonuç oluşturmaz. Alınma yöntemi, kaynağı, sistem saatleri ve bütünlük doğrulaması uzman incelemesinde önem kazanabilir.

Kod tesliminin yapıldığı iddiasında gönderilen bağlantının gerçek yetkileri, süresi ve karşı tarafça açılıp açılmadığı incelenebilir. Bağlantı oluşturulması tek başına tüm kodu teslim etme fiilinin gerçekleştiğini göstermez. İçerik başka kişilerin telif, güvenlik veya kişisel veri haklarını etkiliyorsa mahkemeye sunulma biçimi dikkatle seçilmelidir. İspat ihtiyacı hukuk dışı sistem erişimini meşrulaştırmaz.

HMK 219–220: karşı taraftaki belgelerin ibrazı

Hukuk Muhakemeleri Kanununun 219. maddesi, tarafların kendilerinin veya karşı tarafın delil olarak dayandığı ve ellerinde bulunan belgeleri mahkemeye ibraz etme yükümlülüğünü düzenler. Elektronik belgeler gerektiğinde incelemeye elverişli biçimde elektronik ortama kaydedilerek sunulur. Kodun teslim edilip edilmediği uyuşmazlığında ilgili sözleşme, teslim kayıtları, proje yönetim raporları ve depo erişim evrakı bu hüküm açısından değerlendirilebilir.

HMK 220 ibrazına karar verilen belgenin sunulmamasına ilişkin özel şart ve sonuçları düzenler. Ancak mahkeme kararı bulunmadan her şirketin karşı tarafın tüm sunucusuna koşulsuz erişim hakkı olduğu ileri sürülmemelidir. Talep edilen belgenin belirli ve ispat yönünden gerekli olması önemlidir. Ticari sırların gereksiz açıklanmasını önlemek için ölçülü ibraz ve inceleme yöntemleri değerlendirilebilir. Kanundaki koşullar oluşmadan aleyhe ispat sonucu otomatik varsayılmamalıdır.

HMK 400–403: silinebilecek depo geçmişinde delil tespiti

Kaynak kod deposunun silinme veya yeniden yazılma riski, sürüm geçmişinin kaybolması yahut teslim anındaki teknik durumun sonradan incelenemeyecek olması hâlinde HMK 400–403 kapsamında delil tespiti düşünülebilir. Hukukî yarar ve somut risk açıklanmalıdır. Dilekçede hangi depo, tarih, sürüm, erişim yetkisi ve inceleme sorusunun bulunduğu belirli olmalıdır. Dava öncesi tespit esas dava hükmü değildir.

HMK 401 görev ve yetkiyi, 402 dilekçeyi ve gider avansını, 403 zorunlu acele hâllerin usulünü düzenler. Tarafların erişim hakkı, ticari sırlar ve üçüncü kişi kişisel verileri korunmalıdır. Delil tespiti teknik bir inceleme için hukukî yöntemdir; rakip şirketin veya yüklenicinin bütün sistemlerini istenildiği gibi kopyalamaya yönelik sınırsız yetki değildir. Erişim kayıtları güvenli uzman incelemesiyle tespit edilebilir.

Özel yazılımdan çıkış ve ikame geliştiriciye devir

İş sahibi mevcut geliştiriciyle çalışmayı bitirmeyi planlıyorsa kaynak kodun devri yanında derleme ve çalıştırma talimatları, lisanslar, uygulama alan adları, sunucu ve otomasyon hesapları, müşteri verileri ve kritik parola değişim süreçleri listelenmelidir. Ancak bu teknik çıkış planı, uyuşmazlığın hukukî sonucunu önceden belirlemez. Sözleşmede erişim devrine ilişkin koşullar, gizlilik ve üçüncü kişi lisansları ayrıca ele alınır.

İkame geliştiricinin çalışmaya başlaması gerektiğinde yetkili aktarım tutanağı düzenlenebilir. Çalışan sistemin kullanımı sırasında üçüncü kişilerin verilerinin zarar görmesi önlenmelidir. Mevcut yüklenicinin teslim etmeyi reddettiği belirli nesneler açıkça kaydedilmelidir. Bütün kaynak kod üzerindeki hakların otomatik kazanıldığı veya her durumda başka şirkete serbestçe lisans verilebileceği varsayılmamalıdır.

İhtiyati koruma ve ifa talepleri birbirinden farklıdır

Kod deposunun silinmesi veya değişmesi tehlikesi, tazminat ve ifa iddialarından ayrı olarak geçici koruma ihtiyacını gündeme getirebilir. HMK 389 ve devamındaki ihtiyati tedbir koşulları, somut hak ve zarar tehlikesine göre değerlendirilir. Ancak sadece ticari anlaşmazlık bulunması, bütün yüklenici sistemlerine sınırsız müdahale kararı verileceği anlamına gelmez. Tedbirin konusu, ileri sürülen hakkın korunması için gerekli ve ölçülü olmalıdır.

Sözleşmeye uygun ifa, eksik teslimin tamamlanması, bedel iadesi veya tazminat talepleri farklı unsurlara sahip olabilir. Talep edilen işlem teknik olarak mümkün mü, mevcut sözleşmeye dayanıyor mu ve üçüncü kişilerin haklarını etkiliyor mu soruları açıklanmalıdır. Hukukî başvuru öncesi delil ve ticari iş sürekliliği birlikte değerlendirilir. Haksız tedbir sebebiyle tazminat sorumluluğu ihtimali de göz ardı edilmemelidir.

Teslim ve ödeme takvimine ilişkin farazî örnek

Örnek olarak Ankara’da şirketin özel siparişle geliştirdiği yazılımın uygulama testini 1 Eylül’de kabul ettiğini, kaynak kod deposu devri için ayrı 15 Eylül tarihi kararlaştırıldığını, ancak yüklenicinin bu tarihte yalnız ekran görüntüsü gönderdiğini varsayalım. Bu tamamen farazî bir yöntem örneğidir. Önce sözleşmenin 1 Eylül kabulünü neyi kapsadığı, sonra 15 Eylül’deki teslimin hangi dosyayı ifade ettiği ve son olarak depoya gerçekten erişim sağlanıp sağlanmadığı incelenir.

Teknik açıdan bağlantı, izin düzeyi, teslim edilen paket, sürüm ve gerekli bağımlılıklar eşleştirilir. Hukukî açıdan teslim, ayıp ve ücret hükümleri ayrı uygulanabilir. İş sahibinin gereksiz beklemeye sebebiyet verip vermediği veya yüklenicinin teslimi niçin yapmadığı da araştırılır. Örnek tarihler gerçek dava, resmi karar veya kesin süre iddiası değildir.

İlk görüşmede tamamlanacak belge ve soru listesi

Avukatın incelemesi için ana sözleşme, şartname, ek işler, kabul testleri, proje yönetimi kayıtları, ödeme ve fatura belgeleri, depo izinleri, sürüm etiketleri, teknik yazışmalar, teslim talepleri, yüklenicinin cevapları ve varsa güvenlik uzmanı raporu dosyalanır. Her belgenin hangi teknik gerekliliği veya hukukî iddiayı desteklediği yazılır. Eksik kayıtla ilgili mahkeme başvurusu yapılabilecekse hukuki yarar ve belgenin varlığı açıklanır.

Başvurunun kapsamı belirlenmeden “kaynak kodumuz verilmedi” gibi genel anlatıma dayanılmamalıdır. Sözleşmenin gerçekten kaynak kod devri öngörüp öngörmediği en başta kontrol edilir. Uyuşmazlık bir lisans kullanım hakkı meselesiyse eser sözleşmesi için öngörülmüş haklar otomatik uygulanmamalıdır. Hukukî güvence yerine doğrulanabilir belgeler üzerinden karar verilir. Soru listesi gelecekteki dava veya arabuluculuk işlemleri için temel oluşturabilir.

Ankara bağlantısı, avukat bilgisi ve tek fiziksel büro

Bu metin Ankara’da faaliyet yürüten bir iş sahibinin özel yazılım kabul ve kaynak kod teslim uyuşmazlığına ilişkin olası hukukî incelemeyi anlatır. İş sahibinin Ankara’da bulunması, yüklenicinin veya sunucunun bulunduğu yeri tek başına mahkeme yetkisi olarak belirlemez. Görev ve yetki, sözleşme türü, tarafların sıfatı ve uygulanacak özel hükümlerle birlikte değerlendirilmelidir. Kamu ihalesi içeren özel sözleşmelerde ayrıca 4734 ve 4735 sayılı kanunların uygulanabilirliği araştırılmalıdır.

Av. Halil Bakırcı’nın bağlı bulunduğu Bakırcı & Keskin Hukuk Bürosunun Mersin’de tek fiziki çalışma adresi bulunmaktadır. Ankara ve Türkiye’nin diğer şehirlerindeki hukukî işler Mersin’den koordine edilir. Bu rehber mevcut olmayan Ankara şubesini tanıtmaz, davanın veya bedel tahsilinin kesin sonucunu vaat etmez.

Resmî mevzuat ve ilgili yazılar

Adalet Bakanlığı UYAP – 6098 sayılı Türk Borçlar Kanunu · Çalışma Bakanlığı – 6098 sayılı Türk Borçlar Kanunu · Adalet Bakanlığı UYAP – 6100 sayılı HMK.

Diğer içerikler: Yazılımcı projeyi yarım bırakırsa · SaaS sözleşmesi bitince veriler teslim edilmezse · Yazılımda onaylanmamış ek iş faturası · Büro iletişim kayıtları.

Sık sorulan sorular