Kısa cevap: Yazılım veya script takasında kaynak kodun gerçekten devredilebilir olduğu, lisansların aktarılabildiği, bağımlılıkların ve güvenlik açıklarının bilindiği, ürünün temiz ortamda kurulabildiği ve teslim kapsamının yazılı olduğu doğrulanmalıdır. Çalışan demo tek başına yeterli değildir; kod, hak sahipliği, veri erişimi, dokümantasyon, bakım yükü ve geri alma koşulları birlikte incelenmelidir.
Web scripti, mobil uygulama, bot, masaüstü yazılımı, API servisi veya otomasyon projesi takas edilirken görünmeyen teknik borç büyük risk yaratır. Bir ürün bugün çalışsa bile lisansı devredilemiyor, kritik paketleri terk edilmiş veya yalnız geliştiricinin kişisel hesabına bağlıysa yeni sahibi ürünü sürdüremeyebilir. Aşağıdaki çerçeve güvenli ve ölçülebilir bir inceleme sağlar.
Yazılım takası, bir kod tabanı veya kullanım hakkının başka bir yazılım, dijital varlık, hizmet ya da ek ödeme karşılığında devredilmesidir. İşlem yalnız ZIP dosyası göndermek değildir. Fikrî haklar, kaynak kod, derleme süreci, veritabanı şeması, alan adları, hesaplar, lisanslar ve destek yükümlülükleri ayrı ayrı belirlenmelidir.
Teslim kapsamı ilk teklifin parçası olmalıdır: tam kaynak kodu, Git geçmişi, veritabanı, tasarım dosyaları, testler, kurulum komutları, dokümantasyon, dağıtım yapılandırması, mağaza hesabı, domain ve müşteri sözleşmeleri dahil mi? Dahil olmayan unsurlar da açıkça yazılmalıdır.
Takası sunan kişi kodu kendisi geliştirmiş olabilir; fakat çalışanlar, freelancerlar veya ajanslar katkı yaptıysa hakların yazılı devredildiği kontrol edilmelidir. Git geçmişi, sözleşmeler, faturalar ve katkı kayıtları sahiplik zincirini destekler. İnternetten alınmış veya açık kaynak bir proje yeni adla özel ürün gibi sunulmamalıdır.
Herkese açık bir GitHub deposunu kopyalayabilmek, onu istediğiniz koşulla satma veya kapalı kaynak hâle getirme hakkı vermez. GitHub belgeleri açık kaynak lisanslarının kullanma, değiştirme ve dağıtma haklarını tanımladığını; kamuya açık deponun ayrıca platform içinde görüntüleme ve fork izni verdiğini açıklar. Depodaki LICENSE dosyası ve her bağımlılığın lisansı incelenmelidir.
MIT, Apache-2.0, GPL ve AGPL gibi lisansların bildirim, kaynak sunma, patent veya aynı lisansla paylaşma yükümlülükleri farklıdır. “Açık kaynak” telifsiz veya koşulsuz demek değildir. Projede lisanssız kod bulunması da otomatik olarak serbest kullanım anlamına gelmez.
Lisans envanteri ana kod, bağımlılıklar, fontlar, ikonlar, görseller, SDK’lar ve ticari modülleri kapsamalıdır. Alıcının planladığı kullanım lisanslarla uyumlu değilse yazılımın değeri düşer. Karmaşık veya yüksek değerli projelerde uzman hukuk görüşü alınmalıdır.
Dosya yapısı, kod standardı, tekrar, hata yönetimi, test kapsamı, günlükleme ve yapılandırma ayrımı incelenmelidir. Sabit yazılmış parola, API anahtarı, müşteri verisi veya kişisel e-posta bulunmamalıdır. Ürün temiz bir cihazda yalnız dokümantasyla kurulup çalıştırılabilmelidir.
Demo ile teslim edilen sürümün aynı commit veya sürüm etiketi olduğu doğrulanmalıdır. Minify edilmiş veya şifrelenmiş dosyalar varsa kaynak sürümü istenmelidir. Tek geliştiricinin bildiği manuel adımlar, bakım maliyetini ve operasyon riskini artırır.
Güvenlik incelemesi otomatik tarama, bağımlılık denetimi ve kritik akışların manuel gözden geçirilmesini birleştirmelidir. Kimlik doğrulama, yetkilendirme, parola saklama, oturum, dosya yükleme, sorgular, API erişimi ve yönetici işlemleri test edilmelidir. Şüpheli dış bağlantılar, gizli uzaktan komut ve veri sızdırma davranışı aranmalıdır.
OWASP Software Component Verification Standard; envanter, SBOM, derleme ortamı, paket yönetimi, bileşen analizi ve köken doğrulaması gibi kontrol aileleri önerir. Risk düzeyi yükseldikçe daha ayrıntılı doğrulama gerekir. Tarama sonucunda açık bulunmaması yazılımın kesin güvenli olduğu anlamına gelmez.
Software Bill of Materials, üründeki yazılım bileşenlerinin ve sürümlerinin makinece okunabilir envanteridir. CISA kaynakları SBOM’un tedarik zinciri şeffaflığına yardımcı olduğunu belirtir. Alıcı, yeni bir güvenlik açığı yayımlandığında hangi projelerin etkilendiğini daha hızlı belirleyebilir.
SBOM; üretici, bileşen adı, sürüm, kimlik ve bağımlılık ilişkisi gibi bilgileri içerebilir. Ancak tek başına kodun temiz veya lisansların uyumlu olduğunu garanti etmez. Güncel olması, teslim edilen sürümle eşleşmesi ve güvenlik sürecine bağlanması gerekir.
package.json, lock dosyaları, container imajları, mobil SDK’lar ve harici API’ler envanterlenmelidir. Terk edilmiş veya bilinen açığı bulunan paketler, düzeltilmesi zor teknik borç yaratır. Sürüm sabitleme ve güncelleme politikası kontrol edilmelidir.
Ödeme, e-posta, SMS, harita, depolama ve yapay zekâ servislerinin hesap sahipliği, kota ve fiyatı bilinmelidir. Bazı hesaplar devredilemez; yeni sahibin kendi hesabını açıp anahtarları değiştirmesi gerekir. Ücretsiz kotaya dayanan demo üretim maliyetini gizleyebilir.
Botun kullandığı platformun hizmet şartları, API kuralları ve hız limitleri incelenmelidir. Erişim kontrolünü aşan, sahte hesap oluşturan, spam gönderen, kimlik bilgisi toplayan veya güvenlik önlemlerini etkisizleştiren araçlar ciddi hukuki ve teknik risk taşır.
Meşru kullanım amacı açıkça tanımlanmalı; veri kaynağı ve kullanıcının yetkisi belgelenmelidir. CAPTCHA aşma, izinsiz scraping veya çalıntı token gerektiren script alınmamalıdır. Otomasyonun hata durumunda işlemi durdurma, kayıt tutma ve geri alma mekanizması bulunmalıdır.
Demo verisi ile gerçek kullanıcı verisi ayrılmalıdır. Müşteri kayıtları, kimlik, ödeme, mesaj, IP adresi ve kullanım günlükleri KVKK kapsamına girebilir. Hukuki temel olmadan veritabanını kopyalamak veya takas paketine eklemek doğru değildir.
Gereksiz veriler temizlenmeli, test için anonimleştirilmiş örnek veri kullanılmalı ve aktarım şifreli kanaldan yapılmalıdır. Yedeklerin kimde kaldığı, ne zaman silineceği ve veri ihlalinde sorumluluk yazılı olmalıdır. Parolalar güçlü hash ile saklanmalı; erişim anahtarları devir sonrası döndürülmelidir.
Demo yalnız satıcının kontrolündeki sunucuda izlenmemeli; mümkünse alıcıya ayrılmış test ortamında kurulmalıdır. Ana kullanıcı akışı, hata durumları, yetki seviyeleri, mobil kullanım, performans ve dış servis kesintileri denenmelidir. Örnek verilerle sonuçların tekrarlanabilir olması önemlidir.
Yönetici panelinde gizli kullanıcı, lisans sunucusu bağımlılığı veya zaman sınırlaması bulunup bulunmadığı kontrol edilmelidir. Kaynak kod ile çalışan derleme arasında hash, sürüm etiketi veya tekrar üretilebilir build bağlantısı kurulabilir.
Değer yalnız yazılan kod satırı veya harcanan saat değildir. Çözülen problem, aktif kullanıcı, doğrulanmış gelir, fikrî hakların temizliği, kod kalitesi, testler, dokümantasyon, güvenlik, bakım maliyeti ve pazar talebi birlikte değerlendirilir. Yeniden yazma maliyeti değer için üst sınır olmayabilir.
Sürdürülebilir gelir abonelik iptalleri, destek yükü, sunucu ve API giderleri düşüldükten sonra incelenmelidir. Tek müşteriye, tek platforma veya değiştirilemeyen geliştirici hesabına bağımlılık değer indirimi gerektirir. Gelecek gelir vaatleri doğrulanmış geçmiş gelir gibi fiyatlanmamalıdır.
Kaynak kodun tamamı kamuya açık mesajla gönderilmemeli; alıcı da inceleme için aldığı kodu anlaşma dışında kullanmamalıdır. Teslim kanıtları ve sürüm hashleri saklanmalıdır.
Devredilen haklar, kaynak ve varlık listesi, üçüncü taraf lisanslar, ödeme farkı, teslim tarihi, kabul testi, garanti sınırı, hata düzeltme ve destek süresi yazılmalıdır. Kodun zararlı işlev içermediği ve satıcının devretme yetkisi bulunduğu beyan edilmelidir.
Eksik kaynak, çalışmayan build, lisans ihlali, güvenlik açığı veya devredilemeyen hesap ortaya çıkarsa geri alma ve tazmin adımları belirlenmelidir. Vergi, kişisel veri ve fikrî hak sonuçları için uzman desteği alınması gerekebilir.
Bu, projenin lisansına ve sizin katkılar üzerindeki haklarınıza bağlıdır. Kamuya açık olmak sınırsız yeniden lisanslama hakkı vermez. Lisans ve katkı geçmişi incelenmelidir.
Yalnız kullanım lisansı takas edilebilir, fakat bakım ve doğrulama imkânı sınırlanır. Teslimin kaynak mı, derlenmiş ürün mü, yoksa hesap erişimi mi olduğu açıkça yazılmalıdır.
Hayır. Antivirüs bilinen zararlı örnekleri yakalayabilir; yetkilendirme hatası, veri sızıntısı ve mantıksal açıklar için kod ve davranış incelemesi gerekir.
Destek kapsamı, yanıt süresi ve ürün ya da şirket ömrünün nasıl tanımlandığı yazılı değilse vaat belirsizdir. Somut süre ve hizmet seviyesi tercih edilmelidir.
Güvenli yazılım takası, çalışan dosya alışverişinden çok daha fazlasıdır. Hak sahipliği, lisans, kaynak kod, tedarik zinciri, güvenlik ve kabul testi birlikte doğrulandığında alıcı sürdürülebilir bir ürün, satıcı ise sınırları açık bir teslim yapar. Kritik projelerde bağımsız teknik ve hukuki inceleme maliyeti, sonradan çıkacak sorundan daha düşüktür.
Web scripti, mobil uygulama, bot, masaüstü yazılımı, API servisi veya otomasyon projesi takas edilirken görünmeyen teknik borç büyük risk yaratır. Bir ürün bugün çalışsa bile lisansı devredilemiyor, kritik paketleri terk edilmiş veya yalnız geliştiricinin kişisel hesabına bağlıysa yeni sahibi ürünü sürdüremeyebilir. Aşağıdaki çerçeve güvenli ve ölçülebilir bir inceleme sağlar.
Yazılım ve script takası nedir?
Yazılım takası, bir kod tabanı veya kullanım hakkının başka bir yazılım, dijital varlık, hizmet ya da ek ödeme karşılığında devredilmesidir. İşlem yalnız ZIP dosyası göndermek değildir. Fikrî haklar, kaynak kod, derleme süreci, veritabanı şeması, alan adları, hesaplar, lisanslar ve destek yükümlülükleri ayrı ayrı belirlenmelidir.Teslim kapsamı ilk teklifin parçası olmalıdır: tam kaynak kodu, Git geçmişi, veritabanı, tasarım dosyaları, testler, kurulum komutları, dokümantasyon, dağıtım yapılandırması, mağaza hesabı, domain ve müşteri sözleşmeleri dahil mi? Dahil olmayan unsurlar da açıkça yazılmalıdır.
Kodun sahibinin kim olduğu nasıl doğrulanır?
Takası sunan kişi kodu kendisi geliştirmiş olabilir; fakat çalışanlar, freelancerlar veya ajanslar katkı yaptıysa hakların yazılı devredildiği kontrol edilmelidir. Git geçmişi, sözleşmeler, faturalar ve katkı kayıtları sahiplik zincirini destekler. İnternetten alınmış veya açık kaynak bir proje yeni adla özel ürün gibi sunulmamalıdır.Herkese açık bir GitHub deposunu kopyalayabilmek, onu istediğiniz koşulla satma veya kapalı kaynak hâle getirme hakkı vermez. GitHub belgeleri açık kaynak lisanslarının kullanma, değiştirme ve dağıtma haklarını tanımladığını; kamuya açık deponun ayrıca platform içinde görüntüleme ve fork izni verdiğini açıklar. Depodaki LICENSE dosyası ve her bağımlılığın lisansı incelenmelidir.
Açık kaynak lisansları neden önemlidir?
MIT, Apache-2.0, GPL ve AGPL gibi lisansların bildirim, kaynak sunma, patent veya aynı lisansla paylaşma yükümlülükleri farklıdır. “Açık kaynak” telifsiz veya koşulsuz demek değildir. Projede lisanssız kod bulunması da otomatik olarak serbest kullanım anlamına gelmez.Lisans envanteri ana kod, bağımlılıklar, fontlar, ikonlar, görseller, SDK’lar ve ticari modülleri kapsamalıdır. Alıcının planladığı kullanım lisanslarla uyumlu değilse yazılımın değeri düşer. Karmaşık veya yüksek değerli projelerde uzman hukuk görüşü alınmalıdır.
Kaynak kod incelemesinde nelere bakılmalı?
Dosya yapısı, kod standardı, tekrar, hata yönetimi, test kapsamı, günlükleme ve yapılandırma ayrımı incelenmelidir. Sabit yazılmış parola, API anahtarı, müşteri verisi veya kişisel e-posta bulunmamalıdır. Ürün temiz bir cihazda yalnız dokümantasyla kurulup çalıştırılabilmelidir.Demo ile teslim edilen sürümün aynı commit veya sürüm etiketi olduğu doğrulanmalıdır. Minify edilmiş veya şifrelenmiş dosyalar varsa kaynak sürümü istenmelidir. Tek geliştiricinin bildiği manuel adımlar, bakım maliyetini ve operasyon riskini artırır.
Yazılım güvenliği nasıl kontrol edilir?
Güvenlik incelemesi otomatik tarama, bağımlılık denetimi ve kritik akışların manuel gözden geçirilmesini birleştirmelidir. Kimlik doğrulama, yetkilendirme, parola saklama, oturum, dosya yükleme, sorgular, API erişimi ve yönetici işlemleri test edilmelidir. Şüpheli dış bağlantılar, gizli uzaktan komut ve veri sızdırma davranışı aranmalıdır.OWASP Software Component Verification Standard; envanter, SBOM, derleme ortamı, paket yönetimi, bileşen analizi ve köken doğrulaması gibi kontrol aileleri önerir. Risk düzeyi yükseldikçe daha ayrıntılı doğrulama gerekir. Tarama sonucunda açık bulunmaması yazılımın kesin güvenli olduğu anlamına gelmez.
SBOM nedir, takasta neden istenmeli?
Software Bill of Materials, üründeki yazılım bileşenlerinin ve sürümlerinin makinece okunabilir envanteridir. CISA kaynakları SBOM’un tedarik zinciri şeffaflığına yardımcı olduğunu belirtir. Alıcı, yeni bir güvenlik açığı yayımlandığında hangi projelerin etkilendiğini daha hızlı belirleyebilir.SBOM; üretici, bileşen adı, sürüm, kimlik ve bağımlılık ilişkisi gibi bilgileri içerebilir. Ancak tek başına kodun temiz veya lisansların uyumlu olduğunu garanti etmez. Güncel olması, teslim edilen sürümle eşleşmesi ve güvenlik sürecine bağlanması gerekir.
Bağımlılıklar ve üçüncü taraf servisler nasıl incelenir?
package.json, lock dosyaları, container imajları, mobil SDK’lar ve harici API’ler envanterlenmelidir. Terk edilmiş veya bilinen açığı bulunan paketler, düzeltilmesi zor teknik borç yaratır. Sürüm sabitleme ve güncelleme politikası kontrol edilmelidir.Ödeme, e-posta, SMS, harita, depolama ve yapay zekâ servislerinin hesap sahipliği, kota ve fiyatı bilinmelidir. Bazı hesaplar devredilemez; yeni sahibin kendi hesabını açıp anahtarları değiştirmesi gerekir. Ücretsiz kotaya dayanan demo üretim maliyetini gizleyebilir.
Bot ve otomasyon scriptlerinde hangi riskler vardır?
Botun kullandığı platformun hizmet şartları, API kuralları ve hız limitleri incelenmelidir. Erişim kontrolünü aşan, sahte hesap oluşturan, spam gönderen, kimlik bilgisi toplayan veya güvenlik önlemlerini etkisizleştiren araçlar ciddi hukuki ve teknik risk taşır.Meşru kullanım amacı açıkça tanımlanmalı; veri kaynağı ve kullanıcının yetkisi belgelenmelidir. CAPTCHA aşma, izinsiz scraping veya çalıntı token gerektiren script alınmamalıdır. Otomasyonun hata durumunda işlemi durdurma, kayıt tutma ve geri alma mekanizması bulunmalıdır.
Veritabanı ve kişisel veriler nasıl devredilmeli?
Demo verisi ile gerçek kullanıcı verisi ayrılmalıdır. Müşteri kayıtları, kimlik, ödeme, mesaj, IP adresi ve kullanım günlükleri KVKK kapsamına girebilir. Hukuki temel olmadan veritabanını kopyalamak veya takas paketine eklemek doğru değildir.Gereksiz veriler temizlenmeli, test için anonimleştirilmiş örnek veri kullanılmalı ve aktarım şifreli kanaldan yapılmalıdır. Yedeklerin kimde kaldığı, ne zaman silineceği ve veri ihlalinde sorumluluk yazılı olmalıdır. Parolalar güçlü hash ile saklanmalı; erişim anahtarları devir sonrası döndürülmelidir.
Çalışan demo nasıl doğrulanır?
Demo yalnız satıcının kontrolündeki sunucuda izlenmemeli; mümkünse alıcıya ayrılmış test ortamında kurulmalıdır. Ana kullanıcı akışı, hata durumları, yetki seviyeleri, mobil kullanım, performans ve dış servis kesintileri denenmelidir. Örnek verilerle sonuçların tekrarlanabilir olması önemlidir.Yönetici panelinde gizli kullanıcı, lisans sunucusu bağımlılığı veya zaman sınırlaması bulunup bulunmadığı kontrol edilmelidir. Kaynak kod ile çalışan derleme arasında hash, sürüm etiketi veya tekrar üretilebilir build bağlantısı kurulabilir.
Yazılımın değeri nasıl belirlenir?
Değer yalnız yazılan kod satırı veya harcanan saat değildir. Çözülen problem, aktif kullanıcı, doğrulanmış gelir, fikrî hakların temizliği, kod kalitesi, testler, dokümantasyon, güvenlik, bakım maliyeti ve pazar talebi birlikte değerlendirilir. Yeniden yazma maliyeti değer için üst sınır olmayabilir.Sürdürülebilir gelir abonelik iptalleri, destek yükü, sunucu ve API giderleri düşüldükten sonra incelenmelidir. Tek müşteriye, tek platforma veya değiştirilemeyen geliştirici hesabına bağımlılık değer indirimi gerektirir. Gelecek gelir vaatleri doğrulanmış geçmiş gelir gibi fiyatlanmamalıdır.
Güvenli teslim sırası nasıl olmalı?
- Taraf kimliği ve sahiplik belgeleri doğrulanır.
[/*] - NDA gerekiyorsa imzalanır; salt okunur kod ve belge incelemesi yapılır.
[/*] - Lisans, SBOM, güvenlik ve çalışma testi tamamlanır.
[/*] - Takas kapsamı, fark ödemesi, kabul ölçütü ve destek yazılır.
[/*] - Güvenilir aracı veya aşamalı teslim yöntemi belirlenir.
[/*] - Depo, dosyalar, hesap rolleri ve belgeler aktarılır.
[/*] - Alıcı temiz ortamda build ve kabul testini yapar.
[/*] - Parola, token, anahtar ve eski erişimler yenilenir veya kapatılır.
[/*]
Kaynak kodun tamamı kamuya açık mesajla gönderilmemeli; alıcı da inceleme için aldığı kodu anlaşma dışında kullanmamalıdır. Teslim kanıtları ve sürüm hashleri saklanmalıdır.
Takas sözleşmesinde neler bulunmalı?
Devredilen haklar, kaynak ve varlık listesi, üçüncü taraf lisanslar, ödeme farkı, teslim tarihi, kabul testi, garanti sınırı, hata düzeltme ve destek süresi yazılmalıdır. Kodun zararlı işlev içermediği ve satıcının devretme yetkisi bulunduğu beyan edilmelidir.Eksik kaynak, çalışmayan build, lisans ihlali, güvenlik açığı veya devredilemeyen hesap ortaya çıkarsa geri alma ve tazmin adımları belirlenmelidir. Vergi, kişisel veri ve fikrî hak sonuçları için uzman desteği alınması gerekebilir.
Yazılım ve script takası kontrol listesi
- Geliştirici ve hak sahipliği zinciri doğrulandı mı?
[/*] - Kaynak kod, Git geçmişi, doküman ve testler dahil mi?
[/*] - Açık kaynak ve ticari lisans envanteri çıkarıldı mı?
[/*] - SBOM, bağımlılık ve güvenlik taraması güncel mi?
[/*] - Ürün temiz ortamda tekrar kurulup derlenebiliyor mu?
[/*] - API, mağaza, domain ve servis hesapları devredilebilir mi?
[/*] - Kişisel veriler ayrıştırıldı ve güvenli aktarım planlandı mı?
[/*] - Değer, gelir, gider ve bakım yükü kanıtlandı mı?
[/*] - Kabul testi, destek, geri alma ve erişim kapatma yazılı mı?
[/*]