Yazılım projelerinde uyuşmazlıkların çoğu tek bir sorudan doğar: teslim edilen şey sözleşmede kararlaştırılan şey miydi? Türk hukukunda yazılım geliştirme kural olarak eser sözleşmesidir; yüklenici sonucu taahhüt eder, teslim ettiği eserin ayıplarından sorumlu olur. Buna karşılık kaynak kod üzerindeki haklar ayrı bir rejime, Fikir ve Sanat Eserleri Kanunu’na tabidir. Bu rehber, iki katmanı mevzuat maddeleriyle anlatır. Ankara’daki dosyanız için bize 0554 648 37 15 numarasından ulaşabilirsiniz.
Beş cümlede özet
- Yazılım geliştirme sözleşmesi kural olarak eser sözleşmesidir; yüklenici sonucu meydana getirmeyi taahhüt eder (TBK m.470).
- Yüklenici, meydana getirilen eserin ayıplarından sorumludur; iş sahibi seçimlik haklarını kullanır (TBK m.474-478).
- Bilgisayar programları FSEK’te ilim ve edebiyat eseri sayılır; koruma kaynak koda ve arayüz dışı ifade biçimine yöneliktir.
- Mali hak devri yazılı olmalı ve devredilen haklar ayrı ayrı gösterilmelidir; bedel ödenmesi tek başına devir sağlamaz.
- SaaS ilişkisinde kullanıcıya mülkiyet değil kullanım hakkı verilir; hizmet seviyesi, veri sahipliği ve çıkış hükümleri sözleşmenin çekirdeğidir.
Hangi sözleşme tipi? Eser mi, hizmet mi?
Yazılım ilişkilerinde ilk belirlenmesi gereken, sözleşmenin tipidir; çünkü uygulanacak hükümler buna göre değişir. Belirli bir çıktının teslimi taahhüt ediliyorsa eser sözleşmesi söz konusudur: yüklenici sonucu borçlanır, teslim edilmezse ya da ayıplı teslim edilirse sorumluluk doğar. Buna karşılık belirli bir süre boyunca geliştirici kaynağı tahsis ediliyor ve çıktının kendisi taahhüt edilmiyorsa ilişki hizmet sözleşmesine yaklaşır; burada borçlanılan özenli çalışmadır, sonuç değil.
Uygulamada bu ayrım, ücretlendirme modeliyle örtüşür: sabit bedelli ve kapsamı tanımlı projeler eser sözleşmesi; adam-gün esaslı ve kapsamı esnek çalışmalar hizmet sözleşmesi karakteri taşır. Sözleşmenin başlığı belirleyici değildir; hâkim, tarafların gerçek iradesini ve ilişkinin işleyişini esas alır. Bu nedenle sözleşmede teslim edilecek çıktının, kabul kriterlerinin ve kapsam değişikliği usulünün açıkça yazılması, sonradan çıkacak tartışmayı baştan çözer. Eser sözleşmesinde ayıba karşı tekeffülün genel çerçevesini eser sözleşmesinde ayıba karşı tekeffül yazımızda ele aldık.
Kapsam, kabul ve teslim
Yazılım projelerinde en sık yaşanan uyuşmazlık kapsam tartışmasıdır: iş sahibi sözleşmede olduğunu düşündüğü bir özelliğin teslim edilmediğini, yüklenici ise bunun ek iş olduğunu ileri sürer. Bu tartışmanın çözümü, sözleşme ekindeki teknik şartname ve kabul kriterleridir. Kabul kriterleri ölçülebilir yazılmalıdır: “hızlı çalışacak” değil, “belirlenen senaryoda yanıt süresi şu eşiğin altında kalacak” gibi.
| Konu | Sözleşmede olması gereken | Eksikse sonuç |
|---|---|---|
| Kapsam | Teknik şartname, modül listesi | Ek iş tartışması |
| Kabul | Ölçülebilir kabul kriterleri ve test süreci | Teslim edildi mi tartışması |
| Değişiklik | Yazılı değişiklik usulü ve fiyatlandırma | Sözlü taleplerin ispatı güçleşir |
| Fikri haklar | Yazılı mali hak devri, hakların tek tek sayılması | Devir geçersiz sayılabilir |
| Kaynak kod | Teslim ya da emanet düzeni | Bağımlılık ve devamlılık riski |
| Gecikme | Cezai şart ve üst sınır | Zararın ispatı gerekir |
| Garanti ve bakım | Süre, kapsam, müdahale süreleri | Ücretsiz destek tartışması |
Tabloyu yana kaydırarak tüm sütunları görebilirsiniz.
Kabul, hukuki sonuç doğuran bir işlemdir: iş sahibi eseri kabul ettiğinde, açık ayıplardan doğan hakları kural olarak sona erer. Bu nedenle kabul tutanağı imzalanmadan önce test sonuçlarının kayıt altına alınması ve varsa eksikliklerin tutanağa çekince olarak yazılması gerekir. Gizli ayıplar bakımından ise durum farklıdır; bunlar sonradan ortaya çıktığında derhâl bildirilmelidir.
Ayıplı teslim ve seçimlik haklar (TBK m.474-478)
Türk Borçlar Kanunu, eserin ayıplı olması hâlinde iş sahibine seçimlik haklar tanır. Eser, iş sahibinin kullanamayacağı veya hakkaniyet gereği kabule zorlanamayacağı ölçüde ayıplıysa sözleşmeden dönebilir. Ayıp bu ağırlıkta değilse bedelden indirim isteyebilir ya da aşırı masraf gerektirmiyorsa eserin ücretsiz onarılmasını talep edebilir. Ayrıca yüklenicinin kusuru varsa zararın giderilmesi istenebilir.
Yazılımda “onarım”, hata giderme ve güncelleme anlamına gelir; bu nedenle en sık kullanılan yol ücretsiz düzeltme talebidir. İş sahibi, ayıbı öğrendiğinde gecikmeksizin bildirmelidir; bildirimin yazılı yapılması ve hata kayıtlarının eklenmesi ispat bakımından önemlidir. Yüklenicinin makul sürede düzeltmemesi hâlinde iş sahibi diğer seçimlik haklarına dönebilir ya da işi başkasına yaptırıp masrafı isteyebilir. Ayıbın, iş sahibinin verdiği talimattan veya sağladığı malzemeden kaynaklandığı hâllerde ise yüklenicinin sorumluluğu sınırlanır; ancak yüklenicinin uyarma yükümlülüğü vardır.
Kaynak kod, mali haklar ve devir
Bedelin ödenmiş olması, yazılım üzerindeki hakların iş sahibine geçtiği anlamına gelmez. FSEK, mali hak devrinin yazılı olmasını ve devredilen hakların ayrı ayrı gösterilmesini arar. Bu şekil şartına uyulmadığında, iş sahibi yazılımı kullanabilir ancak çoğaltma, işleme ve yayma haklarına sahip olmayabilir; bu da yazılımı başka bir geliştiriciye devrederek geliştirmesini engeller.
Sözleşmede belirlenmesi gereken noktalar şunlardır: hangi mali hakların devredildiği (çoğaltma, işleme, yayma, umuma iletim), devrin münhasır olup olmadığı, süre ve coğrafi kapsam, alt lisans verilip verilemeyeceği, kaynak kodun teslim edilip edilmeyeceği ve yüklenicinin projede kullandığı kendi kütüphanelerinin durumu. Son nokta önemlidir: yükleniciler çoğu zaman kendi geliştirdikleri altyapıyı birden çok müşteride kullanır; bu hâlde iş sahibine münhasır devir yerine kullanım lisansı verilir ve bunun sözleşmede açıkça yazılması gerekir. Telif rejiminin genel çerçevesini internette telif hakkı ihlali yazımızda ele aldık.
Kaynak kod emaneti ve süreklilik riski
Yazılımın kaynak kodu iş sahibine teslim edilmediğinde ortaya bir bağımlılık çıkar: yüklenici faaliyetini durdurur, iflas eder ya da ilişki bozulursa iş sahibi kendi iş süreçlerini yürüten yazılımı geliştiremez, hatta bakımını yaptıramaz. Bu risk özellikle işletmenin çekirdek süreçlerini yöneten yazılımlarda ciddidir. Çözüm ya kaynak kodun doğrudan teslimi ya da emanet düzenidir.
Emanet düzeninde kaynak kod, güncel sürümüyle bağımsız bir üçüncü kişiye teslim edilir ve yalnızca sözleşmede sayılan tetikleyici hâllerde iş sahibine verilir. Tetikleyici hâller açıkça yazılmalıdır: yüklenicinin faaliyetini durdurması, iflası, bakım yükümlülüğünü belirli süre yerine getirmemesi ya da sözleşmenin haklı nedenle feshi. Emanet sözleşmesinde ayrıca kodun hangi sıklıkla güncelleneceği, dokümantasyon ve derleme talimatlarının da emanete dâhil olup olmadığı belirlenmelidir; yalnızca kodun bulunduğu ancak derlenemeyen bir emanet işe yaramaz. Kod teslim edilse dahi, hakların devredilmemiş olması hâlinde iş sahibi kodu geliştiremez; bu nedenle kaynak kod teslimi ile mali hak devri ayrı ayrı düzenlenmelidir. İki hüküm birlikte bulunmadığında, iş sahibi elinde kullanamayacağı bir kodla kalır.
Ekip, alt yüklenici ve personel devamlılığı
Yazılım projelerinde çıktının kalitesi büyük ölçüde ekibe bağlıdır; bu nedenle sözleşmelerde anahtar personel hükümleri yaygındır. İş sahibi, projede belirli kişilerin çalışmasını ve bu kişilerin onayı olmadan değiştirilmemesini kararlaştırabilir. Değişiklik zorunlu hâle gelirse, yerine gelecek kişinin en az aynı yetkinlikte olması ve devir süresince ek ücret talep edilmemesi öngörülür.
Alt yüklenici kullanımı da düzenlenmelidir. Kural olarak yüklenici, işi bizzat yapmak ya da kendi yönetimi altında yaptırmakla yükümlüdür; ancak sözleşmede aksi kararlaştırılabilir. Alt yüklenici kullanılacaksa, yüklenicinin onların fiillerinden kendi fiili gibi sorumlu olacağı, gizlilik ve fikri hak yükümlülüklerinin alt yüklenicilere de yansıtılacağı yazılmalıdır. Aksi hâlde, alt yüklenici tarafından üretilen kod üzerindeki haklar zincirin bir yerinde kopar ve iş sahibine ulaşmaz. Üçüncü konu, çalışan ayartma yasağıdır: taraflar, proje süresince ve sonrasında belirli bir süre boyunca birbirlerinin çalışanlarına iş teklifi götürmemeyi kararlaştırabilir. Bu tür kayıtların süresi ve kapsamı orantılı olmalıdır; aşırı sınırlamalar geçerlilik tartışması doğurur ve çalışanın kendi iradesiyle yaptığı başvurular bakımından uygulanması güçtür.
Açık kaynak bileşenler ve lisans uyumu
Modern yazılımların neredeyse tamamı açık kaynak kütüphaneler içerir. Bu kütüphaneler ücretsiz olabilir ancak lisanssız değildir: her biri, kullanım şartlarını belirleyen bir lisansa tabidir. Bazı lisanslar yalnızca atıf yapılmasını isterken, bazıları türetilmiş çalışmanın da aynı lisansla dağıtılmasını zorunlu kılar. İkinci gruptaki bir kütüphanenin, kapalı kaynak olarak satılacak bir ürüne dâhil edilmesi, lisans ihlali doğurur ve ürünün kaynak kodunun açılması talebine kadar giden sonuçlar yaratabilir.
Bu risk, sözleşmeyle yönetilir. Yükleniciye, kullandığı üçüncü taraf bileşenlerin listesini ve lisanslarını bildirme yükümlülüğü getirilmeli; ürünün ticari kullanım modeliyle uyumlu olmayan lisansların kullanılmayacağı kararlaştırılmalıdır. Ayrıca yüklenicinin, üçüncü kişilerin fikri haklarını ihlal etmediğine dair taahhüt ve bu nedenle iş sahibine yöneltilecek taleplere karşı koruma yükümlülüğü sözleşmeye konulmalıdır. Teslim aşamasında bileşen listesinin güncel hâlinin alınması, sonraki denetimlerde işletmeyi korur.
Yapay zekâ araçlarıyla üretilen kod
Geliştirme süreçlerinde yapay zekâ destekli kod üretim araçlarının kullanılması, sözleşmelerde yeni bir başlık açtı. İlk soru hak sahipliğidir: Türk hukukunda eser, sahibinin hususiyetini taşıyan fikir ve sanat ürünüdür; hususiyet insan yaratıcılığına bağlandığından, tamamen otomatik üretilen çıktının eser sayılıp sayılmayacağı tartışmalıdır. Buna karşılık geliştiricinin yönlendirme, seçim, düzenleme ve bütünleştirme katkısı bulunduğunda hususiyet şartının sağlandığı kabul edilir. Pratik sonuç şudur: araç kullanımı hakkı ortadan kaldırmaz, ancak katkının belgelenmesi önem kazanır.
İkinci soru risktir. Üretilen kodun, eğitim verisindeki lisanslı kaynaklarla benzeşmesi ihtimali, üçüncü kişi hak ihlali iddialarını gündeme getirebilir. Bu nedenle sözleşmelerde iki hüküm önerilir: yüklenicinin, teslim ettiği kodun üçüncü kişilerin haklarını ihlal etmediğine dair taahhüdü ve bu iddialara karşı iş sahibini koruma yükümlülüğü. Üçüncü soru gizliliktir: proje kodunun ya da iş sahibine ait verilerin, harici bir yapay zekâ hizmetine girilmesi, gizlilik yükümlülüğünün ve duruma göre kişisel veri mevzuatının ihlali sonucunu doğurabilir. Bu nedenle sözleşmede hangi araçların kullanılabileceği, hangi verilerin bu araçlara girilemeyeceği ve kurum içi barındırılan çözümlerin tercih edilip edilmeyeceği açıkça düzenlenmelidir. Bu düzenleme yapılmadığında, ihlal ortaya çıktığında sorumluluğun kimde olduğu tartışmalı hâle gelir.
SaaS ve bulut hizmet sözleşmeleri
Hizmet olarak yazılım modelinde kullanıcıya bir kopya teslim edilmez; uzaktan erişimle kullanım hakkı verilir. Bu, ilişkiyi eser sözleşmesinden uzaklaştırıp sürekli edimli bir hizmet ilişkisine yaklaştırır. Sözleşmenin çekirdeğini üç konu oluşturur.
- Hizmet seviyesi: Erişilebilirlik oranı, planlı bakım pencereleri, arıza müdahale ve çözüm süreleri ile bunlara uyulmaması hâlinde uygulanacak indirim veya cezai şart.
- Veri sahipliği ve güvenlik: Verinin müşteriye ait olduğunun açıkça yazılması, sağlayıcının veri işleyen sıfatı, güvenlik tedbirleri, alt işleyen kullanımı ve ihlal bildirimi süresi.
- Çıkış ve veri taşınabilirliği: Sözleşme sona erdiğinde verilerin hangi formatta, hangi sürede teslim edileceği ve sağlayıcının sistemlerinden ne zaman silineceği.
Üçüncü başlık en çok ihmal edilendir. Çıkış hükmü bulunmayan sözleşmelerde müşteri, hizmeti bırakmak istediğinde verilerini kullanılabilir biçimde alamaz ve fiilen sağlayıcıya bağlı kalır. Ayrıca sağlayıcının sunucuları yurt dışındaysa kişisel veri aktarımı rejimi devreye girer; bu boyutu işyerinde kişisel verilerin korunması yazımızda ele aldık.
Gecikme, fesih ve tasfiye
Yazılım projelerinde gecikme neredeyse kuraldır; sorun, gecikmenin sonuçlarının düzenlenmemiş olmasıdır. Sözleşmede kilometre taşları ve her biri için cezai şart belirlenmesi, hem yükleniciyi disiplin altına alır hem de iş sahibini zarar ispatı yükünden kurtarır. Cezai şartın toplam bedele oranla bir üst sınıra bağlanması ise yüklenici bakımından öngörülebilirlik sağlar; her iki taraf için de dengeli çözüm budur.
Fesih hâlinde asıl mesele tasfiyedir: yapılan işin bedeli, teslim edilen kısmın kullanılabilirliği, kaynak kodun ve dokümantasyonun devri ile üçüncü taraf hizmet hesaplarının aktarımı. Sözleşmede “fesih hâlinde yüklenici, o ana kadar üretilen tüm çıktıları ve kaynak kodu teslim eder” hükmünün bulunması, projenin ortada kalmasını önler. İş sahibinin haksız feshi hâlinde ise yüklenici, yaptığı işin bedeli yanında kanunda öngörülen şartlarla zararının giderilmesini isteyebilir. Bu nedenle fesih iradesinin, sözleşmedeki usule uygun ve yazılı olarak açıklanması gerekir.
Uyuşmazlık çözümü, bilirkişi ve delil düzeni
Yazılım uyuşmazlıkları teknik yoğunluğu nedeniyle bilirkişi incelemesine dayanır; bu yüzden dosyanın kaderi çoğu zaman sunulan kayıtların düzenine bağlıdır. Toplanması gereken deliller şunlardır: sözleşme ve tüm ekleri, teknik şartname sürümleri, kabul tutanakları ve çekinceler, hata kayıt sistemi çıktıları, sürüm kontrol sistemindeki commit geçmişi, toplantı notları ve elektronik yazışmalar. Sürüm kontrol kayıtları özellikle değerlidir: hangi işin ne zaman ve kim tarafından yapıldığını tarihli biçimde gösterir ve kapsam tartışmasını büyük ölçüde çözer.
Uyuşmazlık çözüm yolu bakımından sözleşmeye konulacak hüküm de sonucu etkiler. Ticari nitelikteki alacak davalarında arabuluculuk dava şartıdır; bu aşama atlandığında dava usulden reddedilir. Taraflar tahkim şartı da kararlaştırabilir: teknik uyuşmazlıklarda, alanında uzman hakemlerle yürütülen tahkim daha hızlı ve isabetli sonuç verebilir, ancak maliyeti yüksektir ve tahkim şartının geçerli biçimde yazılması gerekir. Ayrıca sözleşmede kademeli çözüm mekanizması kurulabilir: önce proje yöneticileri düzeyinde görüşme, ardından üst yönetim, sonra arabuluculuk ya da tahkim. Bu kademeler, ilişkiyi tamamen koparmadan çözüm imkânı sağlar. Son olarak yetkili mahkeme ve uygulanacak hukuk maddesi, özellikle yurt dışı sağlayıcılarla yapılan sözleşmelerde ihmal edilmemelidir; aksi hâlde hak arama, öngörülmeyen bir ülkenin usulüne tabi kalabilir.
Sözleşmeye aykırılık ihtarnamesi örneği
İHTARNAME
KEŞİDECİ: …… Ltd. Şti. (iş sahibi), Vergi No, Adres
MUHATAP: …… Ltd. Şti. (yüklenici), Adres
KONU: Ayıplı teslim nedeniyle eksikliklerin giderilmesi, kaynak kodun teslimi ve gecikme cezasının uygulanması ihtarıdır.
AÇIKLAMALAR
1. Taraflar arasında ……/……/…… tarihinde …… yazılımının geliştirilmesine ilişkin sözleşme imzalanmıştır. Sözleşme bedeli …… TL, teslim tarihi ……/……/…… olarak kararlaştırılmıştır.
2. Teslim tarihi geçmesine rağmen …… modülleri teslim edilmemiş; teslim edilen kısımlar ise sözleşme ekindeki teknik şartnamede yer alan kabul kriterlerini karşılamamaktadır. Test raporları ve hata kayıtları ektedir.
3. Tespit edilen eksiklikler ……/……/2026 tarihinde tarafınıza yazılı olarak bildirilmiş; verilen süre içinde giderilmemiştir.
4. Sözleşmenin …… maddesi uyarınca mali hakların devri kararlaştırılmış olmasına rağmen kaynak kod ve teknik dokümantasyon tarafımıza teslim edilmemiştir.
5. İşbu ihtarnamenin tebliğinden itibaren …… gün içinde eksikliklerin giderilmesini, kaynak kod ve dokümantasyonun teslimini talep ederiz.
6. Aksi hâlde sözleşmenin …… maddesindeki gecikme cezasının uygulanacağı, bedelden indirim ya da sözleşmeden dönme haklarımızın kullanılacağı ve doğan zararın tazmini için dava açılacağı ihtar olunur.
HUKUKİ SEBEPLER: 6098 sayılı Türk Borçlar Kanunu m.470 vd., 474-478; 5846 sayılı Fikir ve Sanat Eserleri Kanunu ve ilgili mevzuat.
……/……/2026
Keşideci Vekili
Ad Soyad – İmza
Yazılım sözleşmesi kontrol listesi
- Teknik şartnameyi sözleşme eki yapın; kapsamı yazılı belirleyin.
- Kabul kriterlerini ölçülebilir yazın; kabul tutanağına çekince koymayı unutmayın.
- Değişiklik taleplerini yazılı usule bağlayın ve fiyatlandırmayı baştan belirleyin.
- Mali hak devrini yazılı yapın ve devredilen hakları tek tek sayın.
- Kaynak kodun teslimi ya da emanet düzenini karara bağlayın.
- Üçüncü taraf ve açık kaynak bileşen listesini teslimde alın; lisans uyumunu kontrol edin.
- Gecikme için kilometre taşı bazlı cezai şart ve üst sınır belirleyin.
- SaaS’ta hizmet seviyesi, veri sahipliği ve çıkış hükümlerini mutlaka düzenleyin.
Sık sorulan sorular
Yazılım geliştirme sözleşmesi hangi tiptir?
Belirli bir çıktı taahhüt ediliyorsa eser sözleşmesidir; yalnızca geliştirici kaynağı tahsis ediliyorsa hizmet sözleşmesine yaklaşır.
Bedeli ödedim, yazılım benim mi oldu?
Hayır. Mali hak devri yazılı olmalı ve devredilen haklar ayrı ayrı gösterilmelidir; aksi hâlde devir geçerli sayılmaz.
Kaynak kodu istemek zorunda mıyım?
Sözleşmede kararlaştırılmadıkça yüklenici teslim etmek zorunda değildir; bu nedenle teslim ya da emanet düzeni baştan yazılmalıdır.
Teslim edilen yazılım hatalıysa ne yapabilirim?
Ücretsiz onarım, bedelden indirim ya da ağır ayıpta sözleşmeden dönme; kusur varsa ayrıca zararın giderilmesi.
Kabul tutanağı imzaladım, hakkım bitti mi?
Açık ayıplar bakımından kural olarak evet; gizli ayıplar sonradan ortaya çıktığında derhâl bildirilmek şartıyla ileri sürülebilir.
Ayıbı ne zaman bildirmeliyim?
Öğrenildiğinde gecikmeksizin; bildirimin yazılı yapılması ve hata kayıtlarının eklenmesi gerekir.
Kapsam tartışmasında ne esas alınır?
Sözleşme eki teknik şartname ve kabul kriterleri; sözlü talepler ispatlanamadığında ek iş sayılır.
Açık kaynak kütüphane kullanmak risk mi?
Lisans şartlarına uyulmazsa evet. Bazı lisanslar türetilmiş çalışmanın da aynı lisansla dağıtılmasını zorunlu kılar.
SaaS’ta verilerim kime ait?
Verinin müşteriye ait olduğu sözleşmede açıkça yazılmalı; sağlayıcı veri işleyen sıfatıyla güvenlik ve bildirim yükümlülüğü altına alınmalıdır.
Hizmeti bırakırsam verilerimi alabilir miyim?
Çıkış hükmü yoksa güçleşir. Formatı, süresi ve silme taahhüdü sözleşmede düzenlenmelidir.
Gecikme cezası koymak şart mı?
Şart değil ama işlevlidir: zarar ispatı gerektirmez. Toplam bedele oranla üst sınır konulması dengeyi sağlar.
Fesih hâlinde yarım kalan iş ne olur?
Tasfiye yapılır: yapılan işin bedeli, teslim edilen kısmın durumu ve kaynak kod ile dokümantasyonun devri değerlendirilir.
Uyuşmazlıkta hangi deliller belirleyici?
Sözleşme ekleri, kabul tutanakları, hata kayıtları ve sürüm kontrol sistemindeki commit geçmişi; sonuncusu kapsam tartışmasını tarihli biçimde çözer.
Yapay zekâ ile üretilen kodun hakları kime ait?
Geliştiricinin yönlendirme, seçim ve düzenleme katkısı bulunduğunda hususiyet şartı sağlanır. Araç kullanımı sözleşmede düzenlenmeli, gizlilik ve üçüncü kişi hakları taahhüde bağlanmalıdır.
Kaynak kod emaneti nedir, gerekli mi?
Kodun bağımsız üçüncü kişiye teslim edilip yalnızca sayılan hâllerde iş sahibine verilmesidir. Çekirdek iş süreçlerini yöneten yazılımlarda süreklilik riskini karşılar.
Yüklenici ekibi değiştirebilir mi?
Anahtar personel hükmü konulmadıysa evet. Konulduğunda değişiklik onaya bağlanır ve yerine gelecek kişinin aynı yetkinlikte olması aranır.
Yüklenici üçüncü kişinin hakkını ihlal ederse sorumluluk kimde?
Sözleşmeye taahhüt ve koruma hükmü konulmalıdır; aksi hâlde talepler iş sahibine yöneltildiğinde rücu tartışması doğar.
İlgili Rehberler
Bu yazı genel bilgilendirme amaçlıdır; 6098 sayılı Türk Borçlar Kanunu m.470 vd. ile 5846 sayılı Fikir ve Sanat Eserleri Kanunu ve 6698 sayılı Kanun hükümlerine dayanır. Somut dosyanız için Hukukçular Evi Ankara ile 0554 648 37 15 numaralı telefondan iletişime geçin.

