Yazılımı yaptırdım ama kaynak kodu alamıyorum: Haklar kime ait?

Kısa cevap

Bir yazılımcıya uygulama yaptırdınız, ücretini ödediniz ve ürünü kullanmaya başladınız. Bir süre sonra başka bir ekiple devam etmek istediniz. İlk geliştirici kaynak kodunu vermiyor; “Size programı kullanma hakkı sattım, kodu satmadım” diyor. Ya da bu kez yazılımcı sizsiniz: Müşteri, bedelini ödediği için aynı altyapıyı başka bir projede kullanamayacağınızı ileri sürüyor.

Kısa cevap: Ücretini ödemek ve kaynak kodu almak, yazılımın bütün mali haklarını tek başına size geçirmez. Başka ekiple devam edebilmek için gerekli kod ve teknik belgelere erişiminizin yanında, yapılacak değişiklik ve kullanımın hukuki dayanağı da bulunmalıdır. Sözleşmede açık bir telif maddesi olmaması ise müşterinin yazılımı kullanma ve kararlaştırılan teslimi isteme haklarının hiç olmadığı anlamına gelmez.

Sonuç; işi kimin yaptığına, neyin sipariş edildiğine, hangi kullanımın kararlaştırıldığına ve hakların nasıl düzenlendiğine göre değişir. Çalışan geliştirici, freelancer, ajans ve şirket kurulmadan önce kod yazmış kurucu bu nedenle ayrı ele alınmalıdır.

Parasını ödedim. Yazılım artık benim değil mi?

“Benim” sözcüğü burada birkaç farklı beklentiyi gizler. Yazılımı işletmenizde kullanmak, kopyalarını müşterilere satmak, kodu değiştirmek ve bütün hakları başka bir şirkete devretmek aynı yetki değildir. Örneğin bir muhasebe programının yıllık lisansını alan şirket programı kullanabilir; bu satın alma, programın kaynak kodunu rakip bir ürün çıkarmak için kullanma yetkisi vermez. Size özel yazılım yaptırdığınızda da hangi yetkilerin edinildiği açıklığa kavuşturulmalıdır.

5846 sayılı Fikir ve Sanat Eserleri Kanunu'nun 52. maddesi, mali haklara ilişkin sözleşme ve işlemlerde yazılı şekil ve hakların ayrı ayrı gösterilmesini arar. Bu nedenle yalnız fatura, banka dekontu veya “proje tamamlandı” mesajından sınırsız hak devri sonucu çıkarılmaz. Devir yerine belirli kapsamda kullanım izni, yani lisans verilmiş olabilir. FSEK, m.48 ve 52

Şirketin ihtiyacı her zaman bütün hakları satın almak değildir. Hazır bir hizmeti kullanacak işletme için uygun lisans yeterli olabilir. Ürünü kendi markasıyla piyasaya sürecek, değiştirecek ve ileride başka bir şirkete devredecek girişimin ihtiyacı daha geniştir. Aynı fiyat teklifi bu iki kullanım için yeterli olmayabilir.

İyi bir anlaşma şu farkı görünür kılar: Müşteriye özel geliştirilen bölümde hangi mali haklar devredilecek; geliştiricinin daha önce hazırladığı genel araçlarda hangi kullanım izni verilecek? Böylece müşteri ürününü sürdürebilirken geliştirici de bütün mesleki birikimini tek projede devretmiş sayılmaz.

Kaynak kod teslim edilmezse başka yazılımcıyla devam edebilir miyim?

Kaynak kod, geliştiricinin okuyup değiştirdiği program metnidir. Çalışan uygulamanın kurulum dosyasını almak veya yönetim paneline erişmek, kaynak kodunu almakla aynı değildir. Başka ekibin projeyi sürdürebilmesi için çoğu zaman kodun yanında derleme, kurulum ve bağımlılık bilgilerinin de bulunması gerekir.

Hukuki tarafta ise teslim yükümlülüğü ile değişiklik yapma yetkisi birlikte değerlendirilir. Sözleşme kaynak kodun teslimini açıkça öngörüyorsa, yalnız çalışan uygulamayı vermek kararlaştırılan teslimi karşılamayabilir. Sözleşme bu konuda susuyorsa teklif, teknik şartname, yazışmalar ve işin amacı incelenir. Her yazılım satın alımında kaynak kodun mutlaka teslim edileceği şeklinde genel bir kural kurulamaz; “metinde kaynak kod yazmıyor, hiçbir şekilde isteyemezsiniz” demek de somut anlaşmayı incelemeden fazla kesin olur.

Kod elinizde olsa bile, yeni ekibin yapacağı değişiklik ve yeni kullanım mevcut yetkinin kapsamında olmalıdır. FSEK m.38'de hukuka uygun edinilmiş programın amaçlanan kullanımı, hata düzeltme ve belirli teknik ihtiyaçları bakımından özel hükümler vardır. Bunlar bütün yazılımı dilediğiniz gibi değiştirip başka pazarda satma izni olarak okunmamalıdır. FSEK, m.38

Yeni sözleşme yapıyorsanız çözüm nettir: Kaynak kod, gerekli teknik belgeler, şirket adına açılacak hesaplar ve değişiklik yetkisi açıkça kararlaştırılsın. Hakların hangi sürümü kapsadığı ve üçüncü kişi bileşenlerinin sınırları da gösterilsin. Böylece başka ekibe geçiş yalnız geliştiricinin sonradan vereceği kişisel izne bağlı kalmaz.

Ajansın kullandığı hazır parçalar da bana mı geçer?

Bir mobil uygulama; arka uç kodu, telefon uygulaması, arayüz tasarımı, ikonlar, yazı tipleri, fotoğraflar, sesler, dokümantasyon ve veri tabanı düzeninden oluşabilir. Her parçanın kaynağı farklı olabilir. Ajansın uygulamanın tamamını teslim etmesi, kullandığı stok görselin veya ücretli yazı tipinin sınırsız kullanımını devredebildiğini göstermez.

Ajans sadece kendisinin sahip olduğu veya size kullandırmaya yetkili olduğu hakları sağlayabilir. Örneğin bir yazı tipinin lisansı yalnız ajansın bilgisayarındaki tasarım çalışmasını kapsıyorsa, aynı dosyanın uygulamanın içine gömülmesi için ayrıca izin gerekebilir. Sözleşmede “üçüncü kişi giderleri dahildir” yazması, ilgili lisansın böyle bir kullanıma gerçekten izin verip vermediği sorusunu tek başına çözmez.

“Önceden var olan kod”, geliştiricinin projeden önce oluşturduğu ve başka işlerinde de kullandığı modüllerdir. “Projeye özel çıktı” ise bu iş için hazırlanan parçadır. Bu ayrım düzgün kurulursa geliştirici kendi araçlarını tamamen kaybetmez; şirket de satın aldığı ürünün çalışması için gerekli kullanım haklarından mahrum kalmaz.

Örneğin ajansın genel raporlama motoru kendisinde kalabilir. Ancak şirketin uygulaması bu motor olmadan çalışmıyorsa, kullanımın süresi, kapsamı, bedeli, değişiklik imkânı ve ilişki sona erdiğinde ne olacağı açık olmalıdır. Her parçanın şirkete devri zorunlu çözüm değildir; ihtiyaca uygun lisans da çözüm olabilir.

Çalışanın yazdığı kod kime ait?

Kural olarak, özel sözleşmeden veya işin niteliğinden aksi anlaşılmadıkça çalışanların işlerini yaparken meydana getirdikleri eserlerde mali hakları kullanma yetkisi işverene aittir. Bu düzenleme FSEK m.18/2'de yer alır. Ancak bu kuralı “çalışanın hayatı boyunca yazdığı bütün kod şirkete aittir” şeklinde genişletmek doğru değildir. Eser sahipliği ile işverenin hakları kullanma yetkisi de aynı kavram değildir.

Bu nedenle işe girişte yalnız gizlilik sözleşmesi imzalatmakla yetinmeyin. Görev tanımı, geliştirilen ürünler, çalışma sırasında kullanılabilecek önceki çalışmalar ve üçüncü kişi bileşenleri açıklığa kavuşturulsun. Çalışanın önceki işvereninden getirdiği kod için “kendisi yazmış” açıklaması yeterli kabul edilmesin. Önceki ilişkinin sözleşmeleri ve hakları da etkili olabilir.

Ayrılışta erişimleri güvenli biçimde kaldırmak gerekir. Bunun yanında hangi sürümlerin teslim edildiği, açık işler, şirket hesapları, dokümantasyon ve önceden var olan modüllerin listesi de devredilsin. Çalışanın kişisel hesabına veya cihazına yetkisiz erişmek, hak eksikliğini gidermenin yolu değildir.

Freelancer ve ajans için çalışanla aynı kural mı uygulanır?

Bağımsız geliştiriciyi, işverenin çalışanına ilişkin hükmün otomatik kapsamındaymış gibi değerlendiremezsiniz. Bağımsız geliştiricinin faturası hizmetin bedelini gösterir. Hangi mali hakların devredildiği veya hangi kullanım lisansının verildiği ayrıca belirlenmelidir. Sözleşmenin başlığının “hizmet”, “danışmanlık” veya “eser” olması, ilişkinin bütün hukuki niteliğini tek başına çözmez. Üstlenilen iş ve gerçek çalışma biçimi önemlidir. Türk Borçlar Kanunu, m.19 ve eser sözleşmesine ilişkin m.470 ve devamı

Ajansla çalışırken bir halka daha vardır: Ajans, işi kendi çalışanına mı, bağımsız alt yükleniciye mi yaptırıyor? Ajansın size vereceğini söylediği yetkileri kendisi edinmiş mi? Sözleşmede hakları sağlama taahhüdü bulunması önemlidir; fakat fiilî katkıcı listesi ve uygun devir veya lisans belgeleri de kontrol edilmelidir.

Her katkıcının özel verilerini müşteriye taşımak gerekmez. Ajansın hak zincirini gösteren ölçülü belge sunma, eksikliği giderme ve üçüncü kişi iddiasında işbirliği yükümlülüğü düzenlenebilir. Ticari sır ve çalışan verisi korunurken, sadece genel bir “sorun yoktur” beyanına dayanılmayan bir doğrulama yöntemi seçilir.

Alt yüklenici değiştiğinde bu kontrol de yenilensin. Özellikle projenin son haftasında dışarıdan alınan bir modül, ilk sözleşmede öngörülen ekip tarafından üretilmemiş olabilir. Teslimde kod taramasının yanında katkıcı ve bileşen listesi karşılaştırması yapılması bu yüzden işe yarar.

Daha kod yazılmadan hakları devralmak için anlaşabilir miyiz?

Evet, gelecekte hak devrini sağlama yükümlülüğü için anlaşılabilir. Fakat henüz meydana gelmemiş veya tamamlanacak bir eser üzerindeki doğrudan tasarruf işlemi, FSEK m.48/3 uyarınca geçersizdir. Gelecekte yapılacak devri sağlama taahhüdü ise m.50 çerçevesinde kurulabilir. “Bundan sonra yazılacak her şey bugünden devredildi” cümlesiyle bu ayrımı yok saymamak gerekir.

Pratik çözüm, geliştirme sözleşmesinde üretilecek işi ve gerekli hakları sağlama borcunu tanımlamak; eser tamamlandıkça ilgili çıktı ve sürüm üzerinde gerekli devir işlemlerini yerine getirmektir. Bedel, kabul ve hak geçişi koşulları birbiriyle uyumlu kurulmalıdır. Bakım kapsamında eklenen yeni özelliklerin de bu düzende nasıl ele alınacağı açıklanabilir.

Burada amaç her küçük hata düzeltmesi için anlaşılmaz bir evrak yığını yaratmak değildir. Teslim edilen çalışmanın hangi sözleşmeye ve hangi hak düzenine bağlı olduğunun sonradan gösterilebilmesidir. Toplu dönemsel teslim veya sürüm bazlı ek kullanılacaksa kapsamı belirsiz bırakılmamalıdır.

Yazılı şekil gerektiren işlemler açısından sıradan e-posta, sohbet mesajı, tıklama onayı ve güvenli elektronik imza aynı kabul edilmemelidir. İmza yönteminin ilgili işlem için yeterliliği ayrıca değerlendirilmelidir. TBK m.14-15, yazılı şekil ve güvenli elektronik imza bakımından temel hükümler içerir.

“Bütün haklar müşterinindir” yazmak yeterli olur mu?

Bu tek cümleyle yetinmek önemli belirsizlikler bırakır. FSEK m.52 hakların ayrı ayrı gösterilmesini ister. Ayrıca teslim edilecek çalışma ve kapsam anlaşılmalıdır. Sözleşmenin neyi sağlaması gerektiğini, ürünü nasıl kullanacağınız üzerinden anlatmak daha yararlıdır.

Mali hakları adıyla ve ihtiyaç duyulan kapsamıyla ele almak gerekir. İşleme hakkı, mevcut eserden uyarlama ve değişiklikle yararlanma bakımından; çoğaltma hakkı kopya oluşturma bakımından önemlidir. Yayma, temsil ve umuma iletim hakları da ürünün nasıl dağıtıldığı veya sunulduğuna göre gündeme gelir. Her hakkın anlamı ve ürünle ilişkisi ayrı belirlenmeli; yalnız “kullanabilir” sözcüğüne bütün ticari faaliyetler yüklenmemelidir. Kaynak kod teslimi, bu hakların sayılmasından ayrı bir sözleşme borcu olarak da açıkça düzenlenir.

“Uygulamayı müşterilerin telefonuna yükleteceğiz” ifadesi, çoğaltma ve dağıtım boyutunun incelenmesini gerektirir. “Yeni ekip kodu değiştirip yeni sürüm çıkaracak” ifadesi, işleme ve değişiklik yetkisini gündeme getirir. “Yatırımcı şirket ürünü devralabilir” ifadesi, sonraki devir ve izin zincirinin incelenmesini gerektirir.

Ayrıca şu konular karara bağlansın:

• Devir mi, lisans mı; lisanssa münhasır mı, başkalarına da verilebilir mi?
• Süre ve ülke sınırı nedir?
• Müşterilere ve grup şirketlerine kullandırma hangi kapsamda mümkündür?
• Kaynak kodla birlikte kurulum ve derleme belgeleri teslim edilecek mi?
• Önceden var olan parçalar ile üçüncü kişi lisansları nasıl listelenecek?
• Hak iddiası gelirse kim belge sunacak, kim teknik inceleme yapacak?
• Sözleşme sona erdiğinde mevcut müşterilere hizmet nasıl sürdürülecek?

Ürünü ileride başka bir şirkete devretmek istiyorsanız FSEK m.49 ayrıca önemlidir: Eser sahibi veya mirasçılarından mali hak ya da kullanma ruhsatı edinen kişinin bunu başkasına devredebilmesi, onların yazılı muvafakatine bağlıdır. Dolayısıyla şirketin hakkı edinmesi ile sonraki devre yetkili olması farklı sorulardır. Bu izin ve kapsam ilk sözleşmede açıkça ele alınırsa yatırım veya satış sırasında eksik onayın tamamlanmasına bağımlılık azalır.

Manevi haklar için de özensiz bir “tamamından vazgeçilmiştir” kalıbı kullanılmamalıdır. Adın belirtilmesi, kamuya sunma ve değişikliklerle ilgili hükümler, kanunun izin verdiği sınırlar içinde somut kullanım ihtiyacına göre ele alınır. Yazılımın yeni sürümünü çıkarma ihtiyacı ile geliştiricinin kanunen korunan hakları birlikte değerlendirilir.

Kurucu ortak ayrılırsa kodu da yanında götürebilir mi?

Varsayımsal bir örnek düşünelim. İki kişi bir uygulama geliştiriyor. Biri kodu yazıyor, diğeri satış ve ürün tasarımıyla ilgileniyor. Altı ay sonra şirket kuruluyor. Kod şirketin deposuna taşınıyor, fakat önceki üretimler için belge hazırlanmıyor. İki yıl sonra kodu yazan kurucu ortaklıktan ayrılmak istiyor.

İlk yapılacak iş, “payını satın alınca kod da gelir” varsayımıyla ilerlememektir. Şirket payı, şirketin malvarlığı ve kurucunun önceden sahip olduğu haklar ayrı konulardır. Hangi parçanın kuruluş öncesinde üretildiği, kimlerin katkı sunduğu ve sonradan hangi işlemlerin yapıldığı çıkarılır.

Çözüm çalışması üç parçaya ayrılabilir. Önce mevcut belgeler ve sürüm geçmişi korunur. Sonra şirketin ihtiyaç duyduğu kullanım, değişiklik ve sonraki devir yetkileri belirlenir. Son olarak eksik hak düzeni, gerçek hak sahipleriyle ve doğru imza yöntemiyle tamamlanır. Pay devri anlaşmasına genel bir cümle eklemek yerine ilgili yazılım ve haklar açıkça ilişkilendirilir.

Ortaklar anlaşamıyorsa şirketin tek taraflı belge hazırlaması hak zincirini düzeltmez. Mevcut kullanımın hukuki dayanağı, tedbir ihtiyacı, uzlaşma seçenekleri ve ürünün alternatif bileşenle sürdürülmesi birlikte değerlendirilebilir. Ayrılan kişinin hesabına izinsiz girmek veya geçmiş kayıtları değiştirmek yeni sorunlar yaratır.

Ajansın teslim ettiği uygulamada başkasının ücretli kodu çıkarsa ne olur?

İkinci varsayımsal örnekte bir ajans, şirket için rezervasyon uygulaması teslim ediyor. Yeni ekip devraldığında ana takvim bileşeninin ücretli bir ürün olduğunu, ajansın lisansının yalnız kendi hesabı için düzenlendiğini fark ediyor. Şirket, müşterilerine uygulamayı kendi markalarıyla sunmak istiyor.

Bu olayda bütün uygulamanın kullanılamaz olduğu sonucu hemen çıkarılmamalıdır. Önce bileşenin sürümü, lisansı, ürün içindeki rolü ve gerçek dağıtım biçimi belirlenir. Lisans beyaz etiketli kullanım veya müşteri sunucusuna kurulum için ek izin istiyor olabilir. Lisans bedelini ajansın ödemiş olması, şirketin planladığı kullanımın kapsandığını kanıtlamaz.

Lisans beyaz etiketli kullanıma ek bedelle izin veriyorsa, uygun lisansın kim tarafından alınacağı ve bedelinin kimde kalacağı çözülebilir. Ajans taahhüt ettiği kapsamı sağlamamışsa, eksikliği giderme ve bunun giderlerini karşılama talebi sözleşmeye göre gündeme gelebilir. Böyle bir lisans hiç verilmiyorsa bileşenin değiştirilmesi veya ürünün kullanım modelinin daraltılması gerekir. Müşteriye verilmiş taahhütler ve geçişte oluşabilecek zararlar da hesaba katılır; ajansın tazminat sorumluluğu ihlal, zarar ve diğer koşullar üzerinden değerlendirilir.

Yeni teslimlerde aynı sorun yaşanmasın diye yalnız kaynak kod değil, üçüncü kişi bileşen listesi ve lisans dosyaları da kabul ölçütüne bağlanır. Teknik kabul ile hak kabulü aynı tutanakta ayrı başlıklar halinde gösterilebilir.

Yazılımcı kaynak kodu vermiyorsa hangi haklarımı kullanabilirim?

Önce talebinizin dayanağını ayırın. Kaynak kod teslimi açıkça kararlaştırılmış ama yerine getirilmemişse, sözleşmenin ifası ve aykırılığın giderilmesi gündeme gelebilir. Yazılım teslim edilmiş fakat kararlaştırılan özellikleri taşımıyorsa, uygulanabilir sözleşme hükümlerine göre ayıp veya eksik ifa tartışılır. Hak devri vaat edilmiş ama gerekli işlem yapılmamışsa, devri sağlama yükümlülüğü ayrıca ele alınır. Bunlar aynı talep değildir.

Sipariş üzerine geliştirmede eser sözleşmesi hükümlerinin uygulanabildiği durumlarda TBK m.474-475, gözden geçirme, bildirim ve ayıptan doğan haklar bakımından önemlidir. Koşullarına göre düzeltme, bedel indirimi veya sözleşmeden dönme gibi seçenekler doğabilir; her küçük hata bütün bedelin iadesini sağlamaz. Kabul, gizli ayıp ve bildirim zamanı hakların kullanılmasını etkileyebileceğinden sorunu yalnız destek mesajı olarak bekletmemek gerekir. Türk Borçlar Kanunu, m.474-477

Sözleşme, teklif, sürüm, teslim mesajları ve hata örneklerini koruyun. Ne istediğinizi açıklaştırın: Kodun teslimi mi, eksik modülün tamamlanması mı, hak devrinin yapılması mı, yoksa sözleşmenin sona ermesi mi? İhtar ve uyuşmazlık yolu bu talebe göre şekillenir. Delilin kaybolma veya erişimin kesilme riski varsa delil tespiti ve geçici hukuki koruma ihtiyacı gecikmeden değerlendirilir. Karşı tarafın hesabına izinsiz girmek veya kodu gizlice kopyalamak bu yolların yerine geçmez.

Yazılımcıyım; müşteri ödeme yapmıyor. Uygulamayı kapatabilir miyim?

Ödeme yapılmaması, canlı sistemi silme, verileri yok etme veya müşteriyi aniden hizmet dışı bırakma konusunda sınırsız yetki vermez. Barındırma hizmetini askıya alma hakkı, bildirim ve düzeltme süresi sözleşmede kararlaştırılmış olabilir. Buna rağmen hangi hizmetin durdurulabileceği, veri ve üçüncü kişi etkileri, dürüstlük kuralı ve sorumluluk ayrıca incelenir.

Hak devri bedelin ödenmesine bağlanmışsa bu koşul önemlidir; fakat “haklar bende” demek her teknik müdahaleyi hukuka uygun yapmaz. Daha güvenli yol, muaccel alacağı ve sözleşmedeki yetkileri belirleyip uygun bildirim ve hukuki takip yöntemini kullanmaktır. Mevcut kayıtları bozmak hem delili zayıflatabilir hem de ayrı sorumluluk doğurabilir.

Başlangıç sözleşmesinde aşamalı ödeme, teslim ve hak geçişi birlikte düzenlenirse uyuşmazlıkta tarafların konumu daha anlaşılır olur. Geliştirici açısından bütün kodu ilk gün teslim etmek zorunda kalmadan işin aşamalarını güvenceye almak; müşteri açısından ödenmiş ve teslim edilmiş bölümü kullanmaya devam edebilmek mümkündür. Bunun koşulları açıkça yazılmalıdır.

İlk müşteri ücret ödedi diye aynı altyapıyı başkasına satamaz mıyım?

Tek başına ücret ödemesi müşteriye münhasırlık, yani yalnız kendisine ait kullanım alanı sağlamaz. Ancak devredilen haklar, lisansın münhasır olup olmadığı, projeye özel çıktı, gizlilik ve rekabet hükümleri sınırlama getirebilir. FSEK m.56'da basit ve tam ruhsat ayrımı vardır; sözleşmede ve kanunda aksi anlaşılmadıkça ruhsat basit sayılır.

Örneğin randevu uygulaması geliştiren freelancer, önceden oluşturduğu genel takvim modülünü başka projede kullanmak isteyebilir. Müşterinin özel iş kuralları, tasarımı ve gizli bilgileriyle aynı şey olmayan bu modül başlangıçta ayrılmışsa uyuşmazlık daha kolay çözümlenir. Buna karşılık müşteriye ait özgün kodu, veriyi veya tasarımı alıp yeni projeye koymak “ben yazdım” açıklamasıyla meşru hâle gelmez. Yeniden kullanılabilecek parçaların sınırını işe başlarken belirlemek her iki tarafı korur.

Sık sorulan sorular

Uygulama fikri bana aitse yazılımın telifi de benim midir?

Fikri ortaya atmak ve geliştirme ücretini ödemek ile eseri meydana getirmek farklıdır. FSEK m.2, programın unsurlarına temel olan soyut düşünce ve ilkeleri eser saymaz. Kod, tasarım ve diğer üretimlerdeki somut katkılar ile sözleşmeler belirleyicidir. Bu yüzden fikir sahibi, geliştiriciyle hangi hakları edineceğini açıkça kararlaştırmalıdır.

Telif koruması için mutlaka tescil yaptırmalı mıyım?

Telif korumasının doğumu ile kayıt ve tescilin ispat veya özel mevzuat işlevi ayrıdır. Bakanlık, eser niteliğini taşıyan üretimlerde korumanın yaratımla başladığını açıklar. Bilgisayar oyunları gibi özel kayıt düzeni bulunabilecek ürünler ayrıca incelenmelidir. Telif Hakları Genel Müdürlüğü açıklamaları

Her müşteriye kaynak kod vermek zorunda mıyız?

Bu, hizmet modeline, sözleşmeye ve kullanılan üçüncü kişi lisanslarına bağlıdır. SaaS erişimi, müşteriye kaynak kod teslimiyle aynı değildir. Ancak açık kaynak bileşenlerinin doğurduğu yükümlülükler ve özel müşteri taahhütleri ayrıca kontrol edilir.

Yeni bir geliştirme işine başlarken neyi açıkça konuşmalısınız?

Ücret teklifini kabul etmeden önce şu üç konuyu açıklaştırın: Çalışan uygulamanın yanında kaynak kod ve teknik belgeler de teslim edilecek mi? Ürün başka geliştiriciye değiştirilebilecek ve müşterilere kullandırılabilecek mi? Geliştiricinin yeniden kullanabileceği hazır parçalar hangileri? Bu cevaplar sözleşmeye ve teslim kapsamına yansıdığında, tarafların aynı sözcükten farklı şeyler anlaması önemli ölçüde azalır.

Genel lisans çerçevesi için yazılım telifi ve lisans sözleşmeleri, çalışma başlıkları için teknoloji ve SaaS alanı incelenebilir. İlk iletişimde kaynak kod, erişim anahtarı veya gereksiz kişisel veri göndermeyin.

Bu yazı genel bilgilendirme ve hazırlık amacı taşır. Somut sözleşme, üretim geçmişi ve güncel mevzuat incelenmeden kişiye özel hukuki görüş veya sonuç güvencesi oluşturmaz.