Özel Yazılım Sözleşmesinde Kaynak Kod, Fikri Haklar ve Devir Teslim Nasıl Güvence Altına Alınır?

Özel Yazılım Sözleşmesi Hangi Varlıkları Kapsamalıdır?

Özel yazılım sözleşmesi, yalnızca geliştirilecek uygulamayı değil, uygulamanın çalışması ve başka bir ekip tarafından devralınması için gereken tüm teknik varlıkları tanımlamalıdır. Kaynak kod, veritabanı şeması, Git geçmişi, deployment dosyaları, bulut kaynakları, tasarım dosyaları, API bilgileri, teknik dokümantasyon ve üçüncü taraf bağımlılıklar ayrı başlıklar halinde görünür olmalıdır. Bu ayrım, proje sonunda “teslim edildi” denilen kapsam ile işletmenin gerçekten devralabildiği sistem arasındaki farkı azaltır.

Teknik varlık envanterini sözleşmeden önce oluşturun

İşletme, teklif aşamasında geliştirilecek ve kullanılacak varlıkları listeleyerek her biri için sahiplik, erişim ve devir modelini sormalıdır. özel yazılım yaptırmadan önce incelenmesi gereken kritik adımlar, kapsam ve sağlayıcı sorumluluklarını başlangıçta netleştirmek için yararlı bir kontrol zemini sağlar. Teknik sahiplik, yalnızca kodun bir kopyasını almak değil, sistemi sürdürebilecek erişimlerin ve bilgilerin de kontrol edilebilir olmasıdır.

• Kaynak kod ve tam sürüm geçmişinin teslim kapsamını belirleyin.
• Veritabanı şeması, migration dosyaları ve veri sözlüğünü ayrıca tanımlayın.
• Bulut, domain, depolama ve diğer servis hesaplarını varlık envanterine ekleyin.
• Deployment, CI/CD ve ortam yapılandırmalarının teslim edilmesini planlayın.
• Tasarım dosyaları ile teknik dokümantasyonun sahiplik ve erişim modelini yazın.

Programlar insanların okuyabilmesi için, ancak ikincil olarak makinelerin çalıştırabilmesi için yazılmalıdır. - Harold Abelson ve Gerald Jay Sussman

Kaynak Kod Sahipliği Sözleşmede Nasıl Düzenlenmelidir?

Kaynak kod sahipliği, özel geliştirilen bileşenler için kimin hangi kullanım, erişim ve devir haklarına sahip olacağını açıkça gösterecek biçimde düzenlenmelidir. Teknik açıdan kritik konu, işletmenin yalnızca proje sonunda sıkıştırılmış bir kod dosyası alması değil, güncel kod tabanına ve geliştirme geçmişine düzenli biçimde erişebilmesidir. Böylece sağlayıcı değişikliği, uyuşmazlık veya operasyonel kesinti halinde sistemin devamlılığı tek bir firmaya bağımlı kalmaz.

Sahiplik ile geliştirme yetkisini birbirinden ayırın

Müşteri kontrollü bir kod deposu kullanılması, geliştirme ekibinin günlük çalışma yetkilerini ortadan kaldırmaz. Yetkiler branch, rol ve onay seviyelerinde düzenlenebilir; ancak ana deponun kontrolü yalnızca sağlayıcının kişisel hesabında bırakılmamalıdır. Kaynak kod kontrolü, güncel kodun düzenli olarak müşteri erişimli depoda bulunması, sürüm geçmişinin korunması ve kritik erişimlerin tek kişiye bağımlı olmamasıyla güçlendirilir.

• Kodun hangi Git organizasyonunda veya kurumsal hesapta tutulacağını belirleyin.
• Müşterinin yönetici veya sahip seviyesinde erişimini proje boyunca koruyun.
• Commit geçmişi, branch yapısı ve release etiketlerinin teslim kapsamına dahil olduğunu yazın.
• Kaynak kodun yalnızca proje sonunda toplu olarak teslim edilmesine bağımlı kalmayın.
• Deployment için gerekli yapılandırmaların kod tabanından ayrı tutulduğu noktaları belgeleyin.

Yazılım Fikri Hakları ve Lisanslar Nasıl Ayrıştırılmalıdır?

Yazılım fikri hakları değerlendirilirken projeye özel geliştirilen kod ile açık kaynak, ticari lisanslı veya üçüncü taraf servislerden gelen bileşenler birbirinden ayrıştırılmalıdır. Her kod parçasının aynı şekilde devredilebileceği varsayımı doğru bir teknik envanter oluşturmaz. Kullanılan frameworkler, paketler, SDK’lar, temalar, kütüphaneler ve SaaS servisleri kendi lisans koşullarına sahip olabilir ve bunların projedeki rolü açıkça belgelenmelidir.

Üçüncü taraf bağımlılıkları görünür bir listeye dönüştürün

Teklif veya sözleşme ekinde kullanılan temel üçüncü taraf bileşenlerin adı, amacı, lisans türü ve varsa müşteri tarafından devam ettirilmesi gereken abonelik veya hesap bilgisi tutulabilir. Hukuki sonuçlar kullanılan lisansın koşullarına göre değişebileceği için teknik ekip lisansı yorumlamak yerine bağımlılığı doğru tanımlamalıdır. Lisans envanteri, firma değişikliğinde hangi bileşenlerin özgürce devredilebildiğini ve hangilerinin yeni hesap veya lisans gerektirdiğini anlamayı kolaylaştırır.

• Projeye özel yazılan kod ile üçüncü taraf bileşenleri ayrı listeleyin.
• Açık kaynak paketlerin lisans bilgilerini proje dokümantasyonunda tutun.
• Ticari eklenti ve servislerin hangi hesap üzerinden satın alındığını belirleyin.
• Yenileme gerektiren aboneliklerin sorumlusunu ve ödeme modelini açıklaştırın.
• Sağlayıcıya ait yeniden kullanılabilir bileşenlerin proje kapsamındaki konumunu netleştirin.
• Firma değişikliğinde yeniden lisanslanması gerekebilecek araçları önceden tespit edin.

Git Deposu Kimin Kontrolünde Tutulmalıdır?

Git deposu, özel yazılım projesinde kaynak kodun operasyonel kontrol merkezi olduğu için mümkün olduğunca müşteri tarafından kontrol edilen kurumsal bir organizasyonda tutulmalıdır. Yazılım firması gerekli yönetim veya geliştirme yetkilerini alabilir; fakat deponun yalnızca sağlayıcının kendi hesabına bağlı olması firma değişikliği sırasında erişim, geçmiş ve otomasyon kaybı yaratabilir. Repo kontrolü aynı zamanda kod inceleme, sürümleme ve CI/CD güvenliğinin de temelidir.

Repo yapısını proje yönetişiminin parçası yapın

Branch korumaları, pull request kuralları, erişim rolleri ve release süreçleri sözleşmenin teknik ekinde veya proje çalışma standardında tanımlanabilir. özel yazılım teklifinin kapsam ve karşılaştırma yapısını oluştururken kod deposu, otomasyon dosyaları ve erişim yönetimini de teslimat kalemleri arasında değerlendirmek gerekir. Repo sahipliği, kodun kopyasının bulunmasından daha geniştir; geçmiş, yetki ve geliştirme sürecinin kontrolünü de kapsar.

• Repository organizasyonunun müşteri veya proje adına açılmasını değerlendirin.
• Yönetici yetkilerini en az iki kurumsal kullanıcıyla yedekleyin.
• Branch koruması ve kod inceleme kurallarını standartlaştırın.
• CI/CD tanımlarının hangi depoda ve kimin kontrolünde tutulduğunu belirleyin.
• Eski geliştiricilerin erişimlerinin nasıl ve ne zaman kaldırılacağını planlayın.

Bulut ve Servis Hesaplarının Sahipliği Nasıl Kurulmalıdır?

Bulut ve servis hesapları, yazılımın uzun vadeli işletimini sürdürebilecek şekilde müşteri kontrolünde veya açıkça tanımlanmış kurumsal hesap yapısında kurulmalıdır. Sunucu, veritabanı, obje depolama, e-posta, DNS, CDN, izleme, hata takip ve üçüncü taraf API servisleri yalnızca geliştirme firmasının kontrol ettiği hesaplara bağlıysa sağlayıcı değişikliği teknik erişim sorununa dönüşebilir.

Hesap sahipliği ile teknik yönetimi ayrı sorumluluklar olarak yazın

Bir yazılım firması altyapıyı tamamen yönetebilir, ancak bu durum ana hesabın ve faturalama kontrolünün zorunlu olarak firmada kalması anlamına gelmez. Hesap sahipliği erişim ve devamlılıkla; teknik yönetim ise kurulum, ölçekleme, güncelleme ve izleme görevleriyle ilgilidir. Bu iki konunun ayrı tanımlanması, müşterinin sistemi devralabilmesini kolaylaştırırken geliştirici ekibin ihtiyaç duyduğu operasyonel yetkileri de korur.

• Ana bulut hesabının kimin adına açılacağını proje başlamadan belirleyin.
• Domain, DNS ve SSL yönetim erişimlerini kurumsal hesaplarda tutun.
• İzleme, hata takip ve e-posta servislerinin sahipliğini ayrı kontrol edin.
• API anahtarlarını kişisel hesaplar yerine kurumsal yetki modeliyle yönetin.
• Faturalama hesabı ile teknik kullanıcı yetkilerini birbirinden ayırın.
• Sağlayıcı değişikliğinde erişimlerin devri ve iptali için prosedür tanımlayın.

Veri ve Veritabanı Kontrolü Nasıl Güvence Altına Alınır?

Veri ve veritabanı kontrolü, işletmenin üretim verisine erişebilmesini, yedek alabilmesini ve gerektiğinde veriyi başka bir altyapıya taşıyabilmesini sağlayacak biçimde planlanmalıdır. Uygulama koduna sahip olmak, veritabanı şeması, veriler, yedekler ve migration geçmişi erişilebilir değilse sistemi tek başına devralmak için yeterli olmayabilir. Bu nedenle veri katmanı özel yazılım sözleşmesinde ayrı bir teknik varlık olarak ele alınmalıdır.

Veri taşınabilirliğini devir teslim gereksinimi olarak tanımlayın

Veritabanı motoru, şema, ilişkiler, özel fonksiyonlar, migration dosyaları ve yedekleme prosedürü teknik dokümantasyona dahil edilmelidir. Hassas verilerin nasıl dışa aktarılacağı ve kimin hangi seviyede erişeceği kurumun güvenlik politikalarıyla uyumlu tasarlanmalıdır. Veri kontrolü, yalnızca production veritabanına sürekli yönetici erişimi vermek değildir; yetkili, denetlenebilir ve taşınabilir bir işletim modeli kurmaktır.

• Veritabanı şeması ve migration geçmişinin teslimat kapsamını yazın.
• Yedeklerin nerede tutulduğunu ve kimin erişebildiğini belirleyin.
• Geri yükleme prosedürünün dokümante edilmesini ve test edilmesini isteyin.
• Veri dışa aktarma formatlarını ve olası taşıma senaryolarını belirleyin.
• Production erişimlerinin rol bazlı ve kayıtlı biçimde yönetilmesini sağlayın.

Teknik Dokümantasyon Teslimatı Hangi İçeriği Kapsamalıdır?

Teknik dokümantasyon teslimatı, yeni bir teknik ekibin sistemi yalnızca kaynak kodu okuyarak yeniden keşfetmesini önleyecek kapsamda olmalıdır. Mimari yapı, kurulum adımları, veritabanı modeli, entegrasyonlar, ortam değişkenleri, deployment süreci, zamanlanmış görevler, kuyruk sistemleri, yedekleme ve izleme mekanizmaları temel dokümantasyon başlıklarıdır. Dokümantasyon yalnızca proje sonunda hazırlanırsa güncelliğini kaybetme riski yükselir.

Dokümantasyonu sürekli güncellenen proje çıktısı yapın

yazılım şirketiyle kurumsal özel yazılım projesinin planlanması, teslimatların geliştirme süreci boyunca tanımlanmasının önemini gösteren destekleyici bir çerçevedir. Yaşayan dokümantasyon, mimari veya entegrasyon değiştikçe güncellenmeli ve güncel sürümü müşteri erişiminde bulunmalıdır. Böylece bilgi yalnızca projedeki belirli kişilerin hafızasında kalmaz ve devir teslim daha öngörülebilir hale gelir.

• Sistem mimarisi ve modül ilişkilerini açıklayan doküman isteyin.
• Yerel, test ve production ortamlarının kurulum adımlarını belgeleyin.
• API ve entegrasyon noktalarının kimlik doğrulama yöntemlerini açıklayın.
• Queue, cron ve arka plan işlerinin çalışma mantığını dokümante edin.
• Deployment, rollback, yedekleme ve izleme prosedürlerini kayıt altına alın.
• Dokümantasyon güncellemesini proje değişiklik sürecinin parçası haline getirin.

Firma Değişikliğinde Hangi Teknik Materyaller Teslim Edilmelidir?

Yazılım firma değişikliği sırasında teslim edilmesi gereken materyaller kaynak kodun çok ötesindedir. Tam Git deposu, veritabanı şeması, yedekler, mimari dokümantasyon, deployment tanımları, CI/CD yapılandırmaları, bulut hesap erişimleri, entegrasyon bilgileri, tasarım kaynakları ve açık teknik işler kontrollü bir devir listesi üzerinden aktarılmalıdır. Sistem yalnızca eski ekibin bildiği manuel adımlara bağlıysa geçiş riski artar.

Devir listesini yeni ekibin sistemi çalıştırabileceği şekilde hazırlayın

Devir teslim başarı kriteri “dosyalar gönderildi” değil, yetkili yeni ekibin sistemi kurabilmesi, yayınlayabilmesi, izleyebilmesi ve bakım yapabilmesi olmalıdır. özel yazılım firması seçim kriterleri değerlendirilirken sağlayıcının devir ve dokümantasyon yaklaşımının baştan sorgulanması bu riski azaltabilir. Teknik devir, dosya transferi ile bilgi aktarımını birlikte kapsamalıdır.

• Tam kaynak kod deposunu ve sürüm geçmişini devralın.
• Veritabanı, yedek ve migration materyallerini kontrol listesine ekleyin.
• Bulut ve üçüncü taraf servis hesaplarının yetkilerini yeniden düzenleyin.
• Mimari, entegrasyon ve operasyon dokümanlarının güncel sürümünü teslim alın.
• Açık hata, teknik borç ve bekleyen geliştirme listesini yeni ekibe aktarın.
• Teknik bilgi aktarımı için kayıtlı veya dokümante edilmiş devir oturumları planlayın.

Devir Teslim Yükümlülükleri Nasıl Önceden Tanımlanmalıdır?

Devir teslim yükümlülükleri, ilişkinin sona ermesini beklemeden özel yazılım sözleşmesi ve teklif aşamasında tanımlanmalıdır. Teslim edilecek varlıkların listesi, teslim formatı, erişim değişiklikleri, bilgi aktarımı, açık işlerin durumu ve varsa geçiş desteğinin kapsamı önceden belirlenirse tarafların beklentileri daha görünür olur. Böylece firma değişikliği acil bir teknik kurtarma operasyonuna dönüşmeden yönetilebilir.

Çıkış planını proje başlangıcındaki teslim modeliyle ilişkilendirin

Devir sürecinin kolay olması için kod, dokümantasyon ve hesap sahipliği proje boyunca düzenli tutulmalıdır. Proje sonunda ilk kez depo erişimi açmak veya hesapları taşımaya çalışmak, mevcut bağımlılıkları görünür hale getirmekte geç kalınmasına neden olabilir. Devir yükümlülüğü bir kapanış maddesi olmanın yanında günlük çalışma modelini de etkileyen bir gereksinim olarak ele alınmalıdır.

• Devir teslimde verilecek varlıkların tam listesini sözleşme ekine yazın.
• Dosya ve veri teslim formatlarını önceden belirleyin.
• Hesap erişimlerinin aktarım ve iptal sırasını tanımlayın.
• Bilgi aktarımı toplantılarının kapsamını ve katılımcılarını belirleyin.
• Geçiş dönemindeki hata düzeltme ve destek sorumluluğunu netleştirin.
• Devir tamamlanmasının hangi teknik kontrolle kabul edileceğini tanımlayın.

Özel Yazılım Teklifi Sahiplik Açısından Nasıl Karşılaştırılır?

Özel yazılım teklifi karşılaştırılırken fiyat ve fonksiyon kapsamının yanında sahiplik modeli de ayrı bir değerlendirme başlığı olmalıdır. Bir teklif müşteriye kod deposu, bulut hesapları ve dokümantasyon üzerinde sürekli kontrol sağlarken başka bir teklif kritik varlıkları sağlayıcı hesabında bırakabilir. İlk bakışta benzer görünen iki teklif bu nedenle uzun vadeli bağımlılık, bakım ve firma değiştirme maliyeti açısından farklı riskler taşıyabilir.

Teklif satırlarını sahiplik ve devir sorularıyla eşleştirin

yazılım firması tekliflerini karşılaştırırken kapsam, sorumluluk ve bakım kalemlerine ek olarak her teknik varlığın kontrol modelini de not etmek gerekir. Sahiplik matrisi kaynak kod, veri, Git, bulut, domain, üçüncü taraf lisanslar, tasarım dosyaları ve dokümantasyon için ayrı ayrı hazırlanabilir. Böylece satın alma kararı yalnızca geliştirme bedeline değil, sistemin gelecekte ne kadar bağımsız işletilebileceğine de dayanır.

• Kaynak kod erişimini ve depo sahipliğini teklif karşılaştırmasına ekleyin.
• Bulut ve servis hesaplarının kimin kontrolünde olacağını ayrı değerlendirin.
• Üçüncü taraf lisansları ve devam eden abonelikleri görünür hale getirin.
• Dokümantasyon ve devir teslim işlerini somut teslimatlar olarak yazdırın.
• Bakım hizmeti sona erdiğinde işletmenin hangi varlıkları kullanmaya devam edebileceğini sorun.

Özel Yazılım Sözleşmesi İçin Son Kontrol Nasıl Yapılmalıdır?

Son kontrol, sözleşmedeki ticari hükümler ile teknik teklifin aynı sahiplik ve teslim modelini tarif edip etmediğini karşılaştırarak yapılmalıdır. Kaynak kod devri yazılıyken Git deposu erişimi belirtilmiyorsa, bulut hizmeti dahil görünürken hesabın sahibi tanımlanmıyorsa veya dokümantasyon teslimi kapsamı belirsizse proje sonunda yorum farkları oluşabilir. Teknik ekip bu maddelerin uygulanabilirliğini, hukuk uzmanı ise sözleşmesel sonuçlarını kendi uzmanlık alanı içinde değerlendirmelidir.

Satın alma kararını teknik bağımsızlık açısından tamamlayın

İmza öncesinde kod, veri, hesaplar, lisanslar, dokümantasyon ve devir teslim için tek bir kontrol listesi oluşturmak farklı maddelerin birbirini tamamlayıp tamamlamadığını görmeyi kolaylaştırır. Sürdürülebilir sahiplik modeli, işletmenin sağlayıcıyla çalışmaya devam ederken güçlü bir iş birliği kurmasını engellemez; yalnızca kritik teknik varlıkların tek taraflı erişim bağımlılığına dönüşmesini önlemeyi amaçlar.

• Kaynak kod, veri ve dokümantasyon maddelerinin birbiriyle uyumunu kontrol edin.
• Git, bulut ve servis hesaplarının sahiplik modelini son kez doğrulayın.
• Üçüncü taraf lisans listesinin teklif ve teknik envanterle eşleşmesini inceleyin.
• Firma değişikliğinde uygulanacak devir teslim sürecini adım adım kontrol edin.
• Teknik ekibin ve hukuki danışmanın kendi alanlarındaki belirsizlikleri imza öncesinde kapatmasını sağlayın.