Kaynak Kod Kime Ait Olmalı? Yazılım Projesinde Şirketinizin Elinde Kalması Gerekenler

Kısa cevap

Bir yazılım projesinin ücretini ödemeniz, kaynak kod üzerindeki bütün fikri hakların otomatik olarak şirketinize geçtiği anlamına gelmez. Türkiye’de bilgisayar programları telif hukuku kapsamında korunur; Kültür ve Turizm Bakanlığı, bilgisayar programının veya veritabanının kaynak kodunu yazan kişi ya da kişileri eser sahibi olarak tanımlar. Ücret karşılığı dışarıya yaptırılan bir yazılımda ise müşterinin hangi mali hakları kullanabileceği taraflar arasındaki sözleşmeye bağlıdır. Mali hakların devrine ilişkin sözleşmelerin yazılı olması ve devredilen hakların ayrı ayrı belirtilmesi gerekir. (Telif Hakları)

Bu nedenle yazılım projesinde üç ayrı konu birbirine karıştırılmamalıdır:

1. Kaynak koda erişebiliyor muyum?

2. Kaynak kod üzerindeki hakları kullanabiliyor muyum?

3. Sistemin çalıştığı hesapları gerçekten kontrol ediyor muyum?

Şirket açısından güvenli bir proje sonunda sadece .zip halinde kod değil; repository, deployment, cloud, domain, database, dokümantasyon ve gerekli lisans haklarıyla birlikte sürdürülebilir bir sistem kalmalıdır.

Kaynak kodu teslim almak ile kaynak kodun sahibi olmak aynı şey mi?

Hayır. Bir yazılım firması size: project-source.zip gönderebilir. Dosyalar fiziksel olarak sizdedir. Ancak sözleşmede kodu:

• değiştirme,
• çoğaltma,
• başka firmaya geliştirtme,
• farklı projede kullanma,

devretme yetkileriniz açık değilse yalnızca kaynak dosyaya sahip olmak bütün fikri hakların size geçtiğini göstermez. Kültür ve Turizm Bakanlığı da eser sahibi ile mali hakları sözleşmeyle devralan hak sahibini birbirinden ayırıyor. Ücret karşılığında geliştirilen bilgisayar programında müşteri otomatik olarak kaynak kodu yazan “eser sahibi” haline gelmez; mali hakların kullanımı sözleşme çerçevesinde belirlenir. (Telif Hakları) Tersi de mümkün Sözleşmede şirketinize geniş kullanım ve değiştirme hakları verilmiş olabilir. Ama repository: developer-personal-account/project altındaysa ve şirketin admin erişimi yoksa hukuken sahip olduğunuz hakkı operasyonel olarak kullanmak zorlaşabilir. Yani: Hukuki sahiplik ile teknik kontrol ayrı problemlerdir. İyi proje ikisini de çözer.

Türkiye'de yazılım telif açısından nasıl değerlendiriliyor?

Kültür ve Turizm Bakanlığı bilgisayar programlarını 5846 sayılı Fikir ve Sanat Eserleri Kanunu kapsamında korunan eserler arasında değerlendiriyor. Bakanlığın güncel açıklamasında bilgisayar programının/veritabanının kaynak kodunu yazan kişi veya kişilerin eser sahibi olduğu açıkça belirtiliyor. (Telif Hakları) Kanun kapsamında mali haklar arasında örneğin:

• işleme,
• çoğaltma,
• yayma,
• temsil,

umuma iletim hakları bulunuyor. Bakanlık ayrıca mali hakların devrine ilişkin sözleşmelerin yazılı olmasını ve devredilen hakların ayrı ayrı gösterilmesini şart olarak açıklıyor. (Telif Hakları) Bu nedenle sözleşmede yalnızca: “Yazılım müşteriye aittir.” cümlesine güvenmek yerine, projenin niteliğine uygun mali hakların ve kullanım kapsamının açık şekilde düzenlenmesi daha sağlıklıdır. “Parayı ben ödedim, kod zaten benim değil mi?” Bu en sık yapılan varsayımlardan biridir. Kültür ve Turizm Bakanlığı'nın bilgisayar programlarıyla ilgili SSS içeriği bu konuda oldukça nettir: Bir programın ücret karşılığı yaptırılmış olması müşteriyi otomatik olarak programın kaynak kodunu yazan eser sahibi haline getirmez; mali hakların kullanımı sözleşmeye göre belirlenir. (Telif Hakları) Dolayısıyla: Fatura ödendi ≠

Bütün telif hakları otomatik devredildi

Peki özel yazılımda kaynak kod mutlaka müşteriye mi devredilmeli?

Her projede değil. Burada yazılımın ticari modeli önemlidir. Model 1 — Şirkete özel sıfırdan geliştirilen yazılım Örneğin:

• şirket içi operasyon sistemi,
• özel CRM,
• müşteri portalı,
• özel SaaS ürünü,

şirketin temel dijital ürünü. Bu tür projelerde müşteri açısından güçlü model genellikle: Projeye özgü geliştirilen kod üzerinde gerekli mali hakların şirkete devredilmesi veya şirketin sistemi bağımsız biçimde kullanmasına, değiştirmesine ve geliştirtmesine izin veren çok geniş ve sürekli bir lisans verilmesidir. Hangisinin uygun olduğu sözleşme ve ticari modele göre değişir. Model 2 — Hazır SaaS ürünü satın alıyorsunuz Örneğin: Salesforce HubSpot Notion Microsoft 365 gibi bir hizmet aldığınızda kaynak kodun size ait olmasını beklemezsiniz. Burada satın aldığınız: Source code ownership ❌ Software usage right ✅ dır. Aynı durum yerel bir SaaS sağlayıcısı için de geçerli olabilir. Model 3 — White-label veya ortak platform Yazılım firması aynı altyapıyı 20 müşteride kullanıyor olabilir. Örneğin: Core Platform + Customer-specific branding + Customer-specific modules Bu durumda bütün platformun fikri haklarının tek müşteriye devredilmesi ticari olarak mantıklı olmayabilir. Daha doğru ayrım: Background IP Yazılım firmasının proje öncesinden sahip olduğu veya genel olarak tekrar kullandığı:

• framework,
• ortak kütüphane,
• generic component,

altyapı modülü. Project-Specific IP Sizin şirketiniz için özel geliştirilen:

• iş kuralları,
• özel workflow,
• özel modüller,

entegrasyon kodları. Sözleşmede bu iki kategori ayrı tanımlanabilir.

“Bütün kod bana ait olsun” neden bazen gereksiz veya imkânsız?

Çünkü modern yazılımın tamamı tek firma tarafından sıfırdan yazılmaz. Örneğin projeniz: Next.js React PostgreSQL driver UI library Open-source packages Payment SDK Cloud SDK kullanabilir. Yazılım firması size React'in veya kullanılan açık kaynak kütüphanelerin telif hakkını devredemez. Bunlar kendi lisans koşulları altında kullanılmaya devam eder. Open Source Initiative de açık kaynak yazılımın kullanım, değiştirme ve dağıtım haklarının ilgili açık kaynak lisansı tarafından belirlendiğini; bazı copyleft lisanslarının dağıtım halinde ek yükümlülükler oluşturabileceğini açıkça belirtiyor. (Open Source Initiative) Dolayısıyla sözleşmede: “Projedeki bütün yazılımın tüm fikri hakları müşteriye geçer.” gibi sınırsız bir cümle teknik olarak üçüncü taraf bileşenleri doğru şekilde yansıtmayabilir. Daha doğru yaklaşım: Üçüncü taraf bileşenleri ayırın Örneğin teslimat: CUSTOM CODE → sözleşmedeki hak rejimi OPEN-SOURCE → kendi lisansları COMMERCIAL SDK → ilgili sağlayıcının lisansı VENDOR BACKGROUND IP → sözleşmedeki özel lisans CUSTOMER DATA → ayrı veri/sözleşme hükümleri şeklinde ayrılabilir. Şirketinizin elinde kalması gereken 10 şey Kaynak kod önemli. Ancak tek başına yeterli değil.

1. Açık bir fikri haklar maddesi

Sözleşmede en azından şu sorular cevaplanmalıdır:

Projeye özgü kodun hak rejimi nedir?

Devir mi yapılıyor, lisans mı veriliyor?

Lisans varsa süresi nedir?

Münhasır mı?

Şirket başka bir firmaya geliştirme yaptırabilir mi?

Kod değiştirilebilir mi?

Haklar ne zaman geçiyor?

Background IP kapsamı ne?

Open-source bileşenler nasıl ele alınıyor?

Türkiye’de mali hak devrinde yazılı sözleşme ve hakların ayrı ayrı belirtilmesi gerektiği için bu bölüm özellikle önemlidir. (Telif Hakları) Hakların ne zaman geçtiği de yazılmalı Örneğin taraflar: Sözleşme imzalandığında veya: İlgili proje bedelinin tamamı ödendiğinde gibi farklı bir model kararlaştırabilir. Bu ticari bir sözleşme kararıdır. Belirsiz bırakılmamalıdır.

2. Git repository

Kod yalnızca son sürüm .zip olarak teslim edilmemelidir. Mümkünse: Git repository +

commit history

+ branches/tags + release history korunmalıdır.

Neden?

Çünkü Git history:

• hangi değişiklik ne zaman yapıldı,
• eski sürüm nasıldı,

hangi bug ne zaman geldi gibi önemli bilgileri içerir.

Repository kimin hesabında olmalı?

Şirket için geliştirilen kritik bir özel yazılımda güçlü operasyon modeli:

Company GitHub Organization ↓ Repository ↓ Software vendor = collaborator/team şeklinde olabilir. GitHub’da kişisel hesaba ait repository’nin tek sahibi kişisel hesabın sahibidir; organization repository’leri ise granular rollerle birden fazla kişi ve takım tarafından yönetilebilir. GitHub ayrıca repository’nin başka bir kullanıcı veya organization hesabına transfer edilmesini destekliyor. (GitHub Docs) Bu nedenle şirketin kritik ürünü: developer123/private-project altında yıllarca bırakılmamalıdır.

Neden organization hesabı daha sağlıklı?

Çünkü çalışan veya tedarikçi değiştiğinde:

Vendor access → remove New vendor → add yapabilirsiniz. Repository sizin organizasyonunuzda kalır. GitHub organization repository’lerinde erişimin role göre yönetilebildiğini ve kullanıcıların gerektiğinde organizasyondan/repository’den çıkarılabildiğini belgeliyor. (GitHub Docs)

3. Cloud hesabı

Sistem:

• AWS,
• Azure,
• Google Cloud,
• Vercel,

Cloudflare üzerinde çalışabilir.

Kritik soru:

Bu hesabın en üst düzey sahibi kim?

Örneğin yazılım firması kendi AWS hesabında sizin production sisteminizi çalıştırıyorsa:

Contract ends ↓ Production infrastructure vendor account'ta problemi oluşabilir. Daha güçlü model Customer Cloud Account ↓ Vendor gets delegated access şeklindedir. Yani hesabın kök sahipliği şirketinizde; yazılım firması gerekli teknik rollerle sisteme erişir. AWS, business hesabı oluşturulurken root user için bireysel çalışan e-postası yerine şirket tarafından yönetilen kurumsal distribution list kullanılmasını özellikle öneriyor; gerekçesi çalışan değişse veya ayrılsa bile şirketin hesap erişimini koruyabilmesi. (AWS Dokümantasyonu) Bu prensip yalnızca AWS için değil, genel cloud sahipliği açısından da güçlü bir örnektir.

Cloud şifresini bütün ekiple paylaşmak mı?

Hayır. Örneğin AWS: root password üzerinden günlük çalışma yapılmasını önermiyor. Bunun yerine ayrı kullanıcı/roller ve least-privilege erişimler kullanılması öneriliyor. (AWS Dokümantasyonu) Yani: Company owns account Vendor gets access demek: Vendor root password'ı biliyor demek değildir.

4. Domain ve DNS

Web sitenizin adı:

company.com işletmenin en kritik dijital varlıklarından biridir. Domain yazılım geliştiricinin kişisel hesabında kayıtlı olmamalıdır. ICANN'a göre domain registrant, domain'i kaydeden gerçek kişi veya tüzel kişidir ve registrar ile domain kayıt sözleşmesini yapan taraftır; domain ayarları registrar üzerinden bu registrant tarafından yönetilir. (ICANN) Bu nedenle ideal olarak: Registrant → Şirket Registrar account → Şirket kontrolünde Vendor → gerektiği kadar teknik erişim olmalıdır.

“Domain bizim adımıza ama giriş geliştiricide” yeterli mi?

Tam olarak değil. Kontrol edilmesi gerekenler:

• registrar hesabı,
• kayıtlı e-posta,
• MFA,
• recovery yöntemi,
• DNS hesabı,

yenileme ödemesi. Şirketin bunlara erişebilmesi gerekir.

5. Database ve business data

Uygulamanın kodu sizde olabilir. Ama bütün müşteri ve operasyon verisi vendor'ın erişemediğiniz database hesabındaysa bağımsızlık hâlâ eksiktir.

Şirket en azından şunları bilmelidir:

Database nerede?

Backup nerede?

Kim erişebilir?

Nasıl export edilir?

Recovery nasıl yapılır?

Veri export edilebilir olmalı

Firma değiştirirken:

“Verilerinizi sistemden çıkaramayız.” sonucuyla karşılaşmak ciddi vendor lock-in yaratır. Kritik business sistemlerinde: Database backup + document storage export + business-data export planı bulunmalıdır. Veriye erişim = herkese production DB şifresi vermek değil Şirketin sistem üzerinde kontrol sahibi olması: CEO → production DB password anlamına gelmez. Doğru model:

• şirket kurumsal hesabı kontrol eder,
• erişimler role göre dağıtılır,
• teknik personel gerekli seviyede yetkilendirilir,

credentials gerektiğinde revoke/rotate edilir.

6. Deployment ve CI/CD

Kaynak kodu aldınız. Ama sistemi nasıl yayınlayacağınızı bilmiyorsunuz. Örneğin deploy için: developer'ın laptopu gerekliyse gerçek bağımsızlık hâlâ yoktur. Şirketin elinde bulunması gerekenler:

• build/deploy pipeline,
• environment listesi,
• deployment configuration,
• gerekli platform hesapları,

secret'ları yeniden oluşturma/rotate etme imkânı.

Secret'ların kendisi dokümana yazılmalı mı?

Hayır. Şu belge: production-passwords.txt iyi handover değildir.

Daha sağlıklı:

Secret nerede tutuluyor?

Kim erişebilir?

Nasıl rotate edilir?

dokümante edilmelidir.

7. Teknik dokümantasyon

Kaynak kod tek başına yeni ekibe her şeyi anlatmaz. Minimum dokümantasyon: Architecture Setup Environment Deployment Database Integrations Scheduled jobs Storage Monitoring Backup başlıklarını kapsayabilir.

README neden küçümsenmemeli?

Yeni firma:

git clone

↓

?

aşamasında kalmamalıdır. İyi README en azından:

• local setup,
• gerekli runtime,
• dependency install,
• environment variable adları,
• test,

build bilgisini açıklamalıdır.

8. Tasarım kaynakları

Örneğin:

• Figma,
• logo source,
• icon,
• illustration,

design system. Yazılım kaynak kodu müşteride olup tasarım dosyaları tasarımcının kişisel hesabında kalırsa sonraki geliştirmeler yine bağımlı hale gelebilir. Tasarım hizmetinde de kullanılan:

• font,
• stock image,
• icon,

commercial asset lisansları ayrıca kontrol edilmelidir.

9. Third-party hesaplar ve lisans envanteri

Sisteminiz şunları kullanıyor olabilir:

Stripe Twilio SendGrid OpenAI Mapbox Cloudinary Sentry Benzer birçok servis bulunabilir. Bilmeniz gereken:

Servis

Hesap kimin?

Ödeme kimin?

Kullanım amacı

E-mail

Şirket Şirket Transactional mail AI Şirket Şirket Document analysis Monitoring Şirket Şirket Error tracking Mümkün olduğu ölçüde kritik servisler müşterinin kurumsal hesabında tutulabilir ve vendor'a role-based erişim verilebilir. Open-source envanteri de tutulmalı Kaynak kodu devraldığınızda: “Artık bütün kod bizim.” diyemezsiniz. Açık kaynak paketler kendi lisansları altında kalır. Bazı lisanslar attribution ister; bazı copyleft lisansları ise yazılımın nasıl dağıtıldığına bağlı ek yükümlülükler doğurabilir. (Open Source Initiative) Bu nedenle özellikle büyük ürünlerde: dependency version license envanterinin bulunması faydalıdır.

10. Mobil uygulama mağaza hesapları

Mobil uygulama varsa:

• Apple Developer / App Store Connect,

Google Play Console gibi yayın hesaplarının da şirket kontrolünde olması tercih edilmelidir. Vendor: admin/developer access alabilir. Ancak ürünün mağaza kaydı yalnızca ayrılan geliştiricinin veya ajansın hesabında kalırsa sağlayıcı değişiminde gereksiz operasyon ortaya çıkabilir. Yazılım projesi sonunda ideal sahiplik yapısı Pratik bir model: Varlık Önerilen ana kontrol Domain Şirket DNS Şirket Git Organization Şirket Custom source code rights Sözleşmeyle açık Cloud Şirket Database Şirket hesabındaki altyapı Business data Şirketin erişebildiği/export edebildiği App Store / Play Şirket Figma / tasarım Sözleşmeye göre şirket erişimi Open-source code İlgili lisans Vendor reusable framework Vendor + müşteriye gerekli lisans Documentation Şirkete teslim Bu tablo InoviqLab'ın operasyonel önerisidir.

“Kaynak kod bizim olsun” tek başına neden yeterli değil?

Çünkü şu senaryo mümkündür:

Code ✅ Domain ❌ AWS ❌ Database backup ❌ App Store ❌ Deployment docs ❌ Bu durumda şirket teknik olarak hâlâ tedarikçiye bağımlıdır. Gerçek kontrol: IP Rights + Source + Accounts + Data + Documentation birlikte oluşur.

Vendor lock-in nedir?

Vendor lock-in en basit haliyle:

Sisteminizi başka bir ekibe taşımak istediğinizde teknik, hukuki veya operasyonel olarak bunu makul biçimde yapamamanızdır. Lock-in her zaman kötülük sonucu oluşmaz. Bazen proje başında:

• hesap sahipliği düşünülmez,
• dokümantasyon yapılmaz,

kod kişisel repository'de kalır. Yıllar sonra problem ortaya çıkar. Vendor lock-in testi

Yazılım firmanız yarın projeden ayrılırsa:

Kod sizde mi?

Repository çalışıyor mu?

Cloud'a girebiliyor musunuz?

Domain sizde mi?

Database backup var mı?

Deployment yapılabiliyor mu?

Third-party hesapları biliyor musunuz?

Başka bir geliştirici sistemi kurabilir mi?

Bu soruların çoğunun cevabı:

Hayır ise tedarikçi bağımlılığı yüksektir.

Yazılım firması kendi altyapısını hiç kullanmamalı mı?

Hayır. Örneğin erken MVP aşamasında ajans kendi:

• staging,
• preview,

development hesaplarını kullanabilir. Problem: production sistemin uzun vadeli sahipliğinin belirsiz olmasıdır. İdeal olarak canlı sistem olgunlaştığında kritik üretim varlıkları müşteri kontrolündeki hesaplarda konumlandırılabilir.

Kaynak kodu proje başından itibaren müşterinin repository'sinde tutmak mümkün mü?

Evet. Model: Customer creates GitHub Organization ↓ Vendor team is invited ↓ Development happens there olabilir. Bunun avantajı:

• kod sürekli müşterinin kontrolündedir,
• handover anı beklenmez,

geçmiş kaybolmaz.

GitHub organization modelinin granular repository rolleri sunması bu tür çalışma için uygundur. (GitHub Docs)

Ama müşteri her developer'a admin mi vermeli?

Hayır. GitHub organization repository rolleri: Read Triage Write Maintain Admin gibi farklı seviyeler sunuyor ve GitHub kullanıcıya görevini yapmak için uygun, gereksiz yüksek olmayan rol verilmesini öneriyor. (GitHub Docs) Örneğin geliştiricilerin çoğu: Write yetkisiyle çalışabilir. Admin birkaç yetkili kişide kalabilir.

Yazılım şirketi background framework'ünü korumak isteyebilir mi?

Evet. Bu mutlaka kötü niyet değildir. Örneğin InoviqLab benzeri bir firma yıllar içinde: authentication framework audit framework UI library deployment tooling generic SaaS modules geliştirmiş olabilir. Her müşteri projesinde bunların bütün fikri haklarını devretmek şirketin kendi ürün altyapısını kaybetmesi anlamına gelebilir. Daha doğru model: Vendor Background IP → Vendor retains ownership → Customer gets required license Customer-specific development → Separate rights regime olabilir.

Müşteri açısından kritik olan nedir?

Şu yetkinin korunması:

Yarın başka bir yazılım firmasıyla çalışmak istersem kendi sistemimi sürdürebilir miyim?

Eğer background component lisansı:

Vendor sözleşmesi biter ↓ Uygulama artık çalıştırılamaz diyorsa ciddi bağımlılık vardır. Lisans kapsamı buna göre incelenmelidir.

Kaynak kod lisansı nasıl tanımlanmalı?

Bu hukukçu tarafından somut projeye göre hazırlanmalıdır.

Ancak ticari görüşmede en az şu sorular konuşulabilir:

Süresiz mi?

Türkiye ile mi sınırlı?

Dünya çapında mı?

Değiştirme hakkı var mı?

Başka yükleniciye geliştirtilebilir mi?

Şirket grubu kullanabilir mi?

Satış/devir halinde ne olur?

White-label kullanım var mı?

Kaynak kod paylaşılabilir mi?

Kültür ve Turizm Bakanlığı da mali hak sözleşmelerinde hakların açık belirtilmesine ek olarak sözleşmelerde süre, yer ve kullanım sınırları belirlenebildiğini açıklıyor. (Telif Hakları)

Proje biterken ayrıca “devir teslim” yapılmalı mı?

Evet. Proje kapatma checklist'i oldukça değerlidir. Teknik Devir Teslim Kontrol Listesi Kod Git repository şirkette.

Commit history mevcut.

Production branch belli. Release/tag yapısı biliniyor. Altyapı Cloud hesabı şirkette. Şirketin admin erişimi var. MFA/recovery kontrol edildi. Vendor erişimleri listelendi. Domain Registrant kontrol edildi. Registrar hesabı şirket kontrolünde. DNS erişimi mevcut. Renewal bilgisi biliniyor. Veri Database erişim modeli biliniyor. Backup mevcut. Restore süreci biliniyor. Dosya storage erişilebilir. Export yöntemi mevcut. Deploy CI/CD çalışıyor. Environment listesi var. Build komutları dokümante. Secret yönetimi açıklanmış. Üçüncü taraflar Tüm servisler listelenmiş. Account owner belirli. Faturalandırma belirli. Lisanslar belirli. Dokümantasyon README. Architecture. Deployment. Integration docs. Backup/recovery. Known issues. Hukuki Devir Teslim Kontrol Listesi Projeye özgü kod tanımlı. Background IP tanımlı. Third-party code tanımlı. Mali haklar açık yazılmış. Devir/lisans modeli belli. Hakların başlangıç zamanı belli. Süre belli. Coğrafi kapsam belli. Değişiklik/geliştirme hakkı belli. Başka firmayla çalışma hakkı belli. Alt yüklenicilerle ilgili hak zinciri düzenlenmiş. Proje bitişinde handover maddesi var. Son maddelerin somut hukuki geçerliliği sözleşmeye göre değerlendirilmelidir.

Yazılım firmasındaki freelancer kod yazdıysa ne olur?

Bu, müşterinin mutlaka kontrol etmek zorunda olduğu her çalışan sözleşmesini istemesi anlamına gelmez. Ama tedarikçi sözleşmede: Size verdiği hakları gerçekten verme yetkisine sahip olduğunu taahhüt etmelidir. Çünkü vendor'ın çalışanı, freelancer'ı veya alt yüklenicisi ile yaşadığı hak problemi daha sonra müşteri projesini de etkileyebilir. Bu nedenle enterprise sözleşmelerde sıklıkla:

• ownership warranty,
• third-party IP disclosure,

subcontractor obligations gibi maddeler bulunur. Bu bölüm özellikle hukukçu tarafından hazırlanmalıdır.

Açık kaynak kullanılması kötü mü?

Hayır. Modern yazılımlar yoğun biçimde open-source ekosisteminden yararlanır. Mesele açık kaynak kullanmak değil: Hangi lisansla ne kullandığınızı bilmek. OSI, açık kaynak lisanslarının ticari kullanıma izin verdiğini ancak lisansa bağlı olarak dağıtım ve türev eserler konusunda farklı yükümlülükler oluşabileceğini açıklıyor. (Open Source Initiative) Dolayısıyla: Open Source ≠ Sahipsiz Kod ve: Ücretsiz ≠

Lisans Şartsız

GitHub'da public olması kodu serbestçe kullanabileceğiniz anlamına gelir mi?

Hayır. GitHub'ın resmi dokümantasyonu da açık: Bir repository'nin gerçekten open source olarak kullanılabilmesi için uygun bir lisansa sahip olması gerekir. Lisans yoksa varsayılan telif kuralları geçerlidir ve başkalarının kodu çoğaltma, dağıtma veya türev çalışma oluşturma hakları otomatik doğmaz. (GitHub Docs) Bu nedenle geliştiricinin: “GitHub'dan aldım, ücretsiz.” demesi lisans kontrolünün yerine geçmez.

Sistem başka firmaya devredilebilir olmalı mı?

Şirket açısından çoğu custom software projesinde evet, en azından teknik olarak mümkün olmalıdır. Örneğin: Vendor A ↓ 3 yıl ↓ Vendor B geçişi gerekebilir. Yeni firma için gerekenler: Repository Accounts Data Docs Access Rights mevcutsa geçiş yönetilebilir. Yoksa şirket yazılımı sıfırdan yaptırmak zorunda bile kalabilir. Kaynak kod devri ile support sözleşmesi ayrılmalı Kaynak kodun veya gerekli kullanım haklarının şirkete ait olması: yazılım firmasının ücretsiz ve sonsuz destek vermesi anlamına gelmez. İki konu ayrıdır: Ownership / License Yazılımı kullanma ve geliştirme hakları. Maintenance / Support Firma tarafından verilen teknik hizmet. Şirket kod üzerinde güçlü hak sahibi olabilir ve yine aynı firmadan aylık bakım hizmeti satın alabilir. “Kod müşteriye aitse firma aynı çözümü başka projede hiç kullanamaz mı?” Bu sözleşmeye bağlıdır. Burada yine: Generic know-how Vendor libraries Project-specific code Customer confidential logic ayrılmalıdır. Örneğin: generic pagination component ile: müşterinin özel fiyatlama algoritması aynı şekilde değerlendirilmeyebilir. İyi sözleşme bu sınırı görünür hale getirir. Yazılım projesinde şirketin sahip olması gerekenler — özet tablo

Varlık

Neden önemli?

Hakları düzenleyen sözleşme

Kodun nasıl kullanılacağını belirler

Repository kontrolü Kaynak kodun sürekli erişilebilir olması Cloud hesabı Production altyapısı Domain/DNS Dijital kimlik Database & backup Business continuity CI/CD Sistemi tekrar yayınlayabilme Third-party hesaplar Servis sürekliliği Dokümantasyon Yeni ekibin sistemi anlayabilmesi Tasarım kaynakları UI geliştirme sürekliliği Lisans envanteri Third-party kullanım haklarını bilmek Kırmızı bayraklar Aşağıdaki durumlardan birkaçı varsa proje sahipliği yeniden değerlendirilmelidir:

“GitHub erişimi veremiyoruz.”

Neden?

“Kod sadece bizim sunucumuzda.”

Custom proje için gerekçesi anlaşılmalı.

“Domain'i biz aldık, siz kullanıyorsunuz.”

Registrant kim?

“AWS bizim hesabımızda, taşıyamayız.”

Production bağımlılığı oluşabilir. “Kod sizin ama başka geliştirici değiştiremez.” Hak kapsamı incelenmeli. “Kaynak kodu proje bitince konuşuruz.” Başlangıçta konuşmak daha güvenlidir. “Kullandığımız paketlerin lisanslarını bilmiyoruz.” Supply-chain/lisans riski olabilir.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab'ın proje ve sahiplik yaklaşımıdır. Özel yazılım satın alan bir şirketin en önemli hedeflerinden biri: Tek bir yazılım firmasına mecbur kalmadan ürününü sürdürebilecek yapıya sahip olmasıdır. Bu, vendor'ın kolayca değiştirileceği anlamına gelmez. Ama değiştirilebilmesi mümkün olmalıdır. Birinci prensip: Kaynak kod sahipliği tek başına yeterli değildir Gerçek formül: Legal Rights + Technical Access + Infrastructure Control + Data + Documentation = Operational Ownership olmalıdır. İkinci prensip: Production varlıkları kişisel hesaplarda tutulmamalı Örneğin: personal Gmail personal GitHub personal AWS personal domain account şirket için gereksiz business-continuity riski oluşturur. AWS'in kurumsal root hesabı için bireysel e-posta yerine şirket tarafından yönetilen dağıtım listesi önerisinin temel nedeni de budur: kişi ayrıldığında şirket erişimi devam eder. (AWS Dokümantasyonu) Aynı düşünce GitHub organization ve domain registrar kontrolüne de uygulanabilir. (GitHub Docs) Üçüncü prensip: Vendor erişmeli, vendor sahip olmak zorunda değil Örneğin: AWS account → Company Vendor → IAM role GitHub → Company Organization Vendor → Team Domain → Company Vendor → DNS permissions modeli hem vendor'ın rahat çalışmasını hem şirketin kontrolü korumasını sağlar. Dördüncü prensip: Her şeyi müşteriye devretmek de doğru model değildir Vendor'ın:

• reusable framework,
• pre-existing modules,

internal tooling gibi önceden sahip olduğu varlıkları olabilir. Bunların tamamının devrini istemek yerine müşterinin kendi ürününü:

• çalıştırabilmesi,
• değiştirebilmesi,

başka ekiple geliştirebilmesi için gerekli hakları güvence altına almak daha önemli olabilir. Beşinci prensip: Devir teslim proje sonunda değil proje başında tasarlanmalı

Şu soru kickoff sırasında sorulmalıdır:

Bir gün birlikte çalışmayı bırakmamız gerekirse sistem nasıl devredilecek?

Bu negatif bir soru değildir. Business continuity sorusudur. İyi tedarikçi bu sorudan rahatsız olmamalıdır. Altıncı prensip: En güçlü vendor ilişkisi zorunlu bağımlılık üzerine kurulmaz Müşteri: “Başka yere gidersem sistem çöker.”

• diye kaldığı için değil;

hizmetten memnun olduğu için aynı yazılım firmasıyla devam etmelidir. Uzun vadede daha sağlıklı müşteri-tedarikçi ilişkisi budur.

Sonuç

Özel yazılım projesinde:

“Kaynak kod kimin?” önemli bir sorudur. Ama tek başına yeterli değildir. Şunların tamamı birlikte değerlendirilmelidir: Fikri Haklar ↓ Repository ↓ Cloud ↓ Domain ↓ Database ↓ Deployment ↓ Third-party Accounts ↓ Documentation Türkiye'de bilgisayar programının kaynak kodunu yazan kişi veya kişiler eser sahibi olarak kabul edilir; dışarıya ücret karşılığı yaptırılmış bir yazılımda müşterinin mali haklarının kapsamı sözleşmeye göre belirlenir. Mali hak devri yazılı yapılmalı ve devredilen haklar ayrı ayrı belirtilmelidir. (Telif Hakları) Bu nedenle özel yazılım satın alırken: “Kod bize teslim edilecek mi?” sorusuna ek olarak şunu sorun: “Bu yazılımı yarın başka bir teknik ekiple hiçbir tedarikçiye bağımlı kalmadan çalıştırabilir, geliştirebilir ve yayınlayabilir miyiz?” Bu soruya verilen cevap, yazılımın gerçek anlamda şirketinizin dijital varlığı haline gelip gelmediğini çok daha iyi gösterir.