Birleşme ve devralma (M&A) durum tespiti talebi Salı sabahı geliyor: Cuma gününe kadar tüm yazılımlar için eksiksiz açık kaynak lisans uyumluluk raporu. Hukuk ekibinin, tüm ürün kod tabanındaki her açık kaynak bileşeninin, geçerli olan her lisansın ve satın alanın hukuki incelemesinden önce yerine getirilmesi gereken her yükümlülüğün envanterini çıkarmak için üç günü var. Lisans uyumluluğunu periyodik manuel inceleme egzersizi olarak ele alan kuruluşlar için, o Salı sabahı kurumsal yazılımda en pahalı acil durum tatbikatlarından birinin başlangıcıdır. Olgun bağımlılık analizi altyapısına sahip kuruluşlar için ise, bir rapor çalıştırmakla başlar.
Yazılım çoğunlukla yazılır değil, bir araya getirilir. Black Duck 2026 OSSRA raporu, ticari kod tabanlarının %98'inin açık kaynaklı bileşenler içerdiğini, %87'sinin en az bir bilinen güvenlik açığına sahip olduğunu ve kod tabanı başına ortalama güvenlik açığı sayısının yıldan yıla iki katından fazla arttığını ortaya koymuştur. Lisans uyumluluğu denetimi, farklı ancak ilgili bir soruyu yanıtlayan bir disiplindir: yalnızca hangi bileşenlerin güvenlik açığı içerdiği değil, aynı zamanda hangi bileşenlerin yazılımın nasıl dağıtılabileceği, değiştirilebileceği veya ticarileştirilebileceği konusunda yasal yükümlülükler getirdiği de. Tescilli bir ticari üründe gözden kaçan bir GPL-2.0 bağımlılığı bir güvenlik olayı değildir. Bu, kaynak kodunun açıklanmasını, yasal uzlaşmayı veya ürünün geri çekilmesini gerektirebilecek bir lisans ihlalidir.
Lisans uyumluluğu denetiminin temeli, bağımlılık analizidir; bu, bir kod tabanının doğrudan veya dolaylı olarak bağlı olduğu her yazılım bileşeninin sistematik olarak tanımlanması ve her bileşeni yöneten lisansın eksiksiz olarak belirtilmesidir. Bağımlılık analizi, paket bildiriminin taranması değildir. Bu, yazılımın derleme ve çalışma zamanında gerçekte neleri içerdiğinin, bu eklemelerin beyan edilmiş, geçişli, satıcı tarafından sağlanan veya örtük olup olmadığına bakılmaksızın, tam bir yapısal incelemesidir.
Lisans Değişikliği mi? Etkilerini Bilin.
SMART TS XL Standart SBOM oluşturucularının ulaşamadığı ana bilgisayar yazılımları için bileşen envanterini oluşturur.
DAHA FAZLASINI ÖĞRENİN…Bağımlılık Analizi Neden Temeldir?
Lisans uyumluluğu, yasal bir sorundan önce bir bağımlılık sorunudur. Bir yazılım ürününün lisans yükümlülüklerini, öncelikle o ürünün neyden oluştuğunu, her bileşenini, her kütüphanesini, her kopyalanmış kod parçasını bilmeden değerlendiremezsiniz. Lisans analizi, bağımlılık envanterinin bir sonucudur. Envanteri yanlış yaparsanız, lisans analizi eksik bir tablo üzerine kurulmuş olur.
Bağımlılık analizinin lisans uyumluluğu için cevaplaması gereken üç soru:
Hangi bileşenler dahildir? Sadece belirtilen doğrudan bağımlılıklar değil package.json or pom.xmlAncak getirdikleri her geçişli bağımlılık, kaynak ağacına kopyalanan her tedarikçi kütüphanesi, ikili dosyaya derlenen her statik olarak bağlantılı bileşen ve çalışma zamanında çağrılan her dinamik olarak yüklenen modül de buna dahildir. İyi bir SCA motoru, bu bileşenleri NVD gibi güvenlik açığı veritabanlarıyla çapraz referanslar, lisans meta verilerini kontrol eder ve dağıtım hattınızı etkilemeden önce bilinen istismarları veya yasal riskleri işaretler. Lisans analizine güvenilebilmesi için aynı motorun, yazılımda gerçekten ne olduğu konusunda da envanter düzeyinde doğru olması gerekir.
Hangi lisanslara tabidirler? Bir bileşenin tek bir beyan edilmiş lisansı, seçenekli çift lisansı, farklı dosyalara uygulanan birden fazla lisansı veya sürümler arasında değişen bir lisansı olabilir. FOSSA'nın lisans tespit motoru %99.8 doğruluk iddiasında bulunuyor; bu da hukuk ekibinizin güvenlik envanteriyle birlikte açık kaynak yükümlülüklerini doğrulaması gerektiğinde önemlidir. Bileşen düzeyinde lisans tanımlaması gerekli ancak yeterli değildir; farklı dosyaların farklı lisanslar taşıdığı bileşenler için dosya veya kod parçacığı düzeyinde tanımlama gereklidir.
Bu lisanslar hangi yükümlülükleri getiriyor? İzin verici bir lisans (MIT, Apache-2.0) kaynak belirtme zorunluluğu getirir. Zayıf bir copyleft lisansı (LGPL), bileşenin dinamik veya statik olarak bağlanmasına bağlı olarak farklı yükümlülükler getirir. Güçlü bir copyleft lisansı (GPL-2.0, GPL-3.0), birleştirilmiş çalışmanın tamamının kaynak kodunun dağıtılmasını gerektirebilir. Yükümlülüğü anlamak, yalnızca lisans tanımlayıcısını değil, lisans koşullarını da anlamayı gerektirir.
Lisans Riskine Yol Açan Dört Bağımlılık Türü
Tüm bağımlılıklar eşit derecede görünür veya mevcut araçlar tarafından eşit derecede yönetilmez. Lisans riskine maruz kalma durumu, her biri farklı keşif yöntemleri gerektiren dört farklı bağımlılık türünden kaynaklanır:
1. Paket Yöneticisi Bağımlılıkları (bildirilmiş ve geçişli)
En görünür katman: bildirim dosyalarında tanımlanan bağımlılıklar (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) ve bunların derleme zamanında çözdüğü geçişli bağımlılıklar. Paket yöneticisi bağımlılıkları en iyi kapsanan kategoridir; SCA araçları bunları listelemek için bildirimleri, kilit dosyalarını ve derleme yapıtlarını tarar.
En önemli ayrım doğrudan ve geçişli bağımlılık arasındadır. Doğrudan bağımlılık, geliştiricinin seçtiği bağımlılıktır. Geçişli bağımlılık ise doğrudan bağımlılığın gerektirdiği bağımlılıktır. Tek bir bağımlılık ekleyen bir geliştirici, react-data-grid Bir Node.js projesine eklenen bir paket, her birinin kendi lisansı olan düzinelerce dolaylı bağımlılığı içe aktarabilir. Geliştirici bu lisansları seçmemiştir. Bunlar, bağımlılık ağacında her halükarda mevcuttur.
json
// package.json: 1 direct dependency declared
{
"dependencies": {
"react-data-grid": "^7.0.0"
}
}// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.Geçişli lisans tuzağı: Lisans riski, sizin beyan ettiğinizde değil, bağımlılıklarınızın beyan ettiği ve onların bağımlılıklarının beyan ettiği şeylerdedir. İzin verici lisanslara sahip temiz ve doğrudan bir bağımlılık ağacı, üç seviye derinliğe kadar uzanan ve tüm dağıtıma copyleft yükümlülükleri getiren GPL lisanslı geçişli bir bağımlılığı gizleyebilir.
2. Tedarikçi Tarafından Sağlanan ve Kopyalanan Kaynak Kod
Harici projelerden alınan kaynak kodlar doğrudan depoya kopyalanır; bu, C/C++ projelerinde, modül içermeyen Go projelerinde ve eski kod tabanlarında yaygın bir kalıptır. Tedarikçi tarafından sağlanan kod, bağımlılık yöneticisi aracılığıyla değil, kopyala-yapıştır yöntemiyle eklendiği için paket yöneticisi bildirimlerinde görünmez.
SCANOSS'un kod parçacığı düzeyindeki taraması, manifest tabanlı tespitin çok ötesine geçerek, kaynak kod parçalarını OSSKB'deki 100 milyondan fazla açık kaynak dosyasıyla eşleştirir. Kod parçacığı düzeyinde tarama, manifest bağımlılığı bildirmeyen ancak bileşen açıkça dahil edilmiş gibi tam lisans yükümlülüklerini taşıyan, tedarikçi tarafından sağlanan kodları ve kopyalanmış işlevleri tanımlamak için gereklidir.
GPL lisanslı koddan kaynaklanan bir Stack Overflow yanıtından kopyalanan, tedarikçi tarafından sağlanan bir yardımcı fonksiyon, doğrudan GPL bağımlılığıyla aynı copyleft yükümlülüğünü taşır, ancak paket bildiriminde, kilit dosyasında veya yalnızca beyan edilen bağımlılıkları okuyan herhangi bir otomatik taramada hiçbir yerde görünmez.
3. Statik Bağlantılı Kütüphaneler
Derleme sırasında doğrudan uygulama ikili dosyasına derlenen kütüphaneler. Çalışma zamanında ayrı dosyalar olarak bulunan dinamik olarak bağlantılı kütüphanelerin aksine, statik olarak bağlantılı kütüphaneler yürütülebilir dosyaya gömülüdür. Paket yöneticisi bildirimlerinde görünmezler, derleme yapılandırmalarında görünürler (Makefile, CMakeLists.txt(bağlayıcı komut dosyalarında) ve derlenmiş ikili dosyanın kendisinde.
Özellikle LGPL lisanslı kütüphaneler için, statik ve dinamik bağlantı ayrımı lisans yükümlülüğünü belirler. LGPL, copyleft yayılımı olmadan dinamik bağlantıya izin verir; statik bağlantı, birleştirilmiş çalışmada copyleft gereksinimlerini tetikleyebilir. Statik olarak bağlantılı bileşenleri ve lisanslarını belirlemek için, yalnızca kaynak manifestini değil, derlenmiş yapıyı da inceleyen bir ikili analiz aracı gereklidir.
4. Çalışma Zamanında Yüklenen Bağımlılıklar
Kütüphaneler, eklenti mimarileri, geç bağlama veya betik motoru entegrasyonları aracılığıyla çalışma zamanında dinamik olarak yüklenir. Bu bağımlılıklar, yalnızca kaynak kod analiziyle çözülemeyebilir; çalışma zamanı ortamına, yapılandırmaya ve yürütme yoluna bağlıdırlar. Yansıma yoluyla yüklenen veritabanı sürücüleri, hizmet yükleyici mekanizmaları aracılığıyla keşfedilen ayrıştırıcı eklentileri ve başlangıçta dosya sistemi yollarından yüklenen betik uzantıları, potansiyel lisans etkileri olan çalışma zamanı bağımlılıklarıdır.
Lisans Risk Kategorileri ve Yükümlülükleri
Açık kaynak lisansları, izin verici ile kısıtlayıcı arasında değişen bir yelpazede yer alır. Her lisansın bu yelpazede nerede konumlandığını anlamak, yarattığı uyumluluk yükümlülüğünü belirler:
İzin verici lisanslar (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)
Yükümlülük: Dağıtımlarda kaynak belirtme, lisans metni ve telif hakkı bildirimini ekleme zorunluluğu vardır. Kaynak kodunun açıklanması zorunlu değildir. Ticari kullanım kısıtlama olmaksızın serbesttir. Tescilli ürünlere entegrasyon serbesttir.
Ticari yazılımlar için risk seviyesi: Düşük. Sorumluluk ataması otomatik olarak kolayca gerçekleştirilebilir.
Zayıf copyleft lisansları (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)
Yükümlülük: Lisanslı bileşene yapılan atıf ve değişikliklerin paylaşılması zorunludur. Özellikle LGPL için: dinamik bağlantı genellikle çağıran kodda copyleft'i tetiklemeden lisansı karşılar; statik bağlantı karşılamayabilir.
Ticari yazılımlar için risk seviyesi: Orta. Bağlantı yöntemine bağlıdır. Dinamik bağlantı genellikle güvenlidir; statik bağlantı ise dikkatli bir hukuki inceleme gerektirir.
Güçlü copyleft lisansları (GPL-2.0, GPL-3.0, AGPL-3.0)
Yükümlülük: GPL bileşenini içeren tüm birleşik çalışma ve kaynak kodunun açıklanması GPL şartları altında sunulmalıdır. AGPL bunu ağ üzerinden erişilen yazılımlara da genişletir.
Ticari yazılımlar için risk seviyesi: Yüksek. Tescilli bir ticari ürüne statik olarak bağlanan veya ondan türetilen GPL lisanslı bir bileşen, tescilli kaynak kodunun açıklanmasını gerektirebilir. Bu, en büyük yasal tazminatlara yol açan lisans riskidir.
Ağ kopyalama hakkı (AGPL-3.0)
Yükümlülük: GPL-3.0'ın tüm yükümlülüklerine ek olarak: yazılımla ağ üzerinden etkileşim kuran kullanıcılar, yazılımı alan kişiler olarak kabul edilir ve bu durum, ikili dosyaları asla dağıtmayan SaaS ürünleri için bile kaynak kodunu açıklama yükümlülüğünü tetikler.
SaaS ürünleri için risk seviyesi: Çok yüksek. AGPL, özellikle GPL'deki "SaaS açığını" kapatmak için tasarlanmıştır. AGPL bileşeni içeren ticari bir SaaS ürünü, ağ üzerinden onunla etkileşim kuran her kullanıcıya kaynağını açıklamak zorundadır.
Tescilli ve ticari lisanslar
Yükümlülük: Lisans sözleşmesiyle tanımlanır ve "yeniden dağıtım yok"tan "birim başına telif hakkı"na ve "kurumsal kullanıcı lisansı"na kadar değişir. Bunlar açık kaynaklı değildir, ancak ticari bileşenler kullanıldığında bağımlılık ağaçlarında görünürler.
Risk seviyesi: Şartlara göre değişir. Genellikle birleşme ve devralma süreçlerinde, devralınan ürünlerin lisans ücreti yükümlülükleri belirlenirken ortaya çıkar.
Lisans Uyumluluğu: Önemli Olan Matris
Farklı lisanslara sahip bileşenler tek bir yazılım ürününde birleştirildiğinde, lisansların uyumlu olması gerekir. Uyumsuz lisans kombinasyonları, yalnızca atıfta bulunarak çözülemeyen yasal riskler yaratır; kombinasyonun kendisi bir veya her iki lisansı da ihlal edebilir.
| Birlikte | İLE | Apaçi-2.0 | LGPL-2.1 | GPL-2.0 | GPL-3.0 | PLFA-3.0 |
|---|---|---|---|---|---|---|
| İLE | Uyumlu | Uyumlu | Uyumlu | Uyumlu | Uyumlu | Uyumlu |
| Apaçi-2.0 | Uyumlu | Uyumlu | Uyumlu | Uyumsuz | Uyumlu | Uyumlu |
| LGPL-2.1 | Uyumlu | Uyumlu | Uyumlu | Uyumlu | Uyumsuz | Uyumsuz |
| GPL-2.0 | Uyumlu | Uyumsuz | Uyumlu | Uyumlu | Uyumsuz | Uyumsuz |
| GPL-3.0 | Uyumlu | Uyumlu | Uyumsuz | Uyumsuz | Uyumlu | Uyumlu |
| Özel | Uyumlu | Uyumlu | Dikkat | Uyumsuz | Uyumsuz | Uyumsuz |
Ticari yazılımlar için en önemli uyumsuzluk: Apache-2.0 ve GPL-2.0 uyumsuzdur. Apache-2.0 lisanslı bir kütüphane, aynı çalışmada GPL-2.0 lisanslı bir bileşenle birleştirilemez. Birçok temel açık kaynak bileşeni (Linux çekirdek modülleri, bazı eski Java kütüphaneleri) GPL-3.0 yerine GPL-2.0 lisanslı olduğundan, bu uyumsuzluk karma bağımlılık ağaçlarında gerçek bir uyumluluk riski yaratır.
AGPL-3.0 lisansı, SaaS (Hizmet Olarak Yazılım) için en kısıtlayıcı olanıdır: Temelde hiçbir şey, ağ telif hakkı yükümlülüğünü tetiklemeden ticari bir üründe AGPL-3.0 ile sorunsuz bir şekilde bir araya gelemez.
CI/CD'de Lisans Politikasının Uygulanması
Periyodik denetimlere dayanan lisans uyumluluğu, uygulamaya konulduğu anda başarısız olur: Birinin geçen sprintte eklediği GPL bağımlılığı, üç haftalık üretim sürecinin ardından üç aylık denetim tarafından yakalanır. Uyumsuz bağımlılıkların kod tabanına girmesini engelleyen tek yaklaşım, birleştirme aşamasında sürekli denetim uygulamaktır.
tatlım
# GitHub Actions: license compliance gate on every PR
name: License Compliance Check
on:
pull_request:
jobs:
license-audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install license checker
run: npm install -g license-checker fossa-cli
- name: Scan dependency licenses
run: |
license-checker --summary --excludePrivatePackages \
--out license-report.json
- name: Enforce license policy
run: |
# Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
FORBIDDEN=$(license-checker --failOn \
"GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
--excludePrivatePackages 2>&1 || true)
if echo "$FORBIDDEN" | grep -q "FAIL"; then
echo "Forbidden license detected in dependencies"
echo "$FORBIDDEN"
exit 1
fi
- name: Generate SBOM artifact
run: |
# Generate CycloneDX SBOM for audit trail
npx @cyclonedx/cyclonedx-npm \
--output-file sbom-$(date +%Y%m%d).json
- name: Upload SBOM as artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom-*.jsonDikkat: Lisans politikası kuruluşa özgüdür. Yukarıdaki örnekte yer alan yasaklılar listesi yaygın bir ticari politikayı yansıtmaktadır, ancak kuruluşunuzun hukuk ekibi, belirli ürün türünüz, dağıtım modeliniz ve müşteri sözleşmeleriniz için hangi lisansların izin verildiğini, hangilerinin inceleme için işaretlendiğini ve hangilerinin yasaklandığını belirlemelidir. Dahili bir araçta izin verilen bir kütüphane, müşteriye dağıtılan bir üründe yasaklanmış olabilir.
SBOM Oluşturma ve Biçimlendirme Standartları
Yazılım Malzeme Listesi (SBOM), lisans uyumluluğunu denetlenebilir, paylaşılabilir ve makine tarafından doğrulanabilir hale getiren yapılandırılmış bir belgedir. SBOM bu verileri sağladığında, uyumluluk ekipleri manuel denetimlere gerek kalmadan lisans yükümlülüklerini doğrulayabilir. Piyasada iki format hakimdir:
OWASP tarafından geliştirilen CycloneDX , güvenlik ve tedarik zinciri kullanım durumları için tasarlanmıştır. Bileşenleri, hizmetleri, güvenlik açıklarını (VEX), formülleri ve makine öğrenimi modeline dayalı malzeme listelerini destekler. Güvenlik odaklı SBOM'lar için tercih edilen format olup, çoğu modern SCA aracı entegrasyonunun gerektirdiği formattır.
SPDXLinux Vakfı tarafından sürdürülen ISO/IEC standardı (ISO 5962:2021). EO 14028'in bazı yönleri de dahil olmak üzere bazı devlet satın alma standartları tarafından gereklidir. Güvenlikten ziyade lisans uyumluluğuna daha fazla odaklanmıştır ve daha zengin bir lisans ifade dili (SPDX ifadeleri karmaşık çoklu lisans senaryolarını yakalayabilir) içerir. GPL-2.0-only AND MIT OR Apache-2.0).
EO 14028 zaten SBOM dışı tedarikçilerin federal sözleşmelere katılmasını engelliyor, CRA Eylül 2026'da güvenlik açığı raporlamasını uygulamaya koyuyor ve PCI DSS 4.0 zaten denetçilerin elinde. Ya SBOM'lar gönderiyorsunuz ya da anlaşmaları kaybediyorsunuz.
Kurumsal yazılım ürünleri için, her iki formatı da üretmek, aynı bağımlılık analizinden yola çıkmanın ötesinde çok az maliyet gerektirir. Her birinin hedef kitlesi farklıdır: güvenlik ekipleri ve güvenlik açığı yönetimi iş akışları CycloneDX'i kullanırken; hukuk ekipleri, satın alma ve mevzuat uyumluluğu iş akışları genellikle SPDX'i tercih eder.
Eski Kod Tabanı Sorunu: Paket Yöneticisi Yok, Bildirim Dosyası Yok
Yukarıda açıklanan bağımlılık analizi araçları (SCA tarayıcıları, kilit dosyası ayrıştırıcıları, SBOM oluşturucuları), yazılım bağımlılıklarının paket yöneticileri aracılığıyla yönetildiği ve bildirim dosyalarında belirtildiği varsayımına dayanmaktadır. Bu varsayım, modern Java, JavaScript, Python, Go ve Rust projeleri için geçerlidir. Ancak COBOL, JCL ve ana bilgisayar platformları üzerine kurulu eski kurumsal ortamlar için geçerli değildir.
Ana bilgisayar ortamında, üçüncü taraf yazılım bağımlılığı, standart SCA araçlarının tespit edemediği üç şekilde kendini gösterir:
Lisanslı sıralama ve yardımcı ürünler. JCL iş akışları, kendi lisans koşulları, bakım sözleşmeleri ve uyumluluk gereksinimlerine sahip lisanslı ticari yazılımlar olan yardımcı programları, sıralama ürünlerini (DFSORT, SyncSort/şimdi Precisely olarak bilinen Syncsort, CA Sort), rapor yazıcılarını (SAS, EASYTRIEVE) ve veri dönüştürme araçlarını çağırır. Bunlar JCL'de şu şekilde görünür: PGM=SORT, PGM=IEBGENER, PGM=ICETOOLProgram adları, paket tanımlayıcıları değil. Hiçbir SCA aracı bunu okuyamaz. package.json or pom.xml onları bulacak.
Satıcı tarafından sağlanan COBOL copybook'ları. Üçüncü taraf yazılım satıcıları, lisanslı yazılım olan COBOL copybook'ları sağlar. Ödeme işlemleri için COBOL programları sağlayan bir fintech yazılım satıcısı, kendi özel veri yapılarını tanımlayan copybook'lar sağlayabilir. Bu copybook'ları içeren her COBOL programı, lisanslı yazılım kullanmaktadır. Lisans yükümlülükleri gerçektir; paket yöneticisi girişi mevcut değildir.
Lisanslı kaynaklardan gömülü algoritmalar. COBOL sistemleri kullanan finans kuruluşları, lisanslı algoritmaları, aktüeryal hesaplama rutinlerini, kriptografik uygulamaları, sayısal analiz kütüphanelerini doğrudan COBOL kaynak koduna entegre etmiş olabilirler. Bunlar, kod tabanına derlenmiş ve paket yöneticilerinden tespit edilemeyen lisanslı kaynaklar olabilir.
Bu bileşenler için keşif yöntemi kaynak kod analizidir: çağrılan programları belirlemek için CALL ifadelerinin izlenmesi, dahil edilen üyeleri belirlemek için COPY ifadelerinin incelenmesi ve program adlarının bilinen üçüncü taraf bileşenlerinin bir kaydıyla eşleştirilmesi. Çıktı aynı lisans uyumluluğu iş akışına beslenir, ancak yalnızca modern paket bildirim formatlarını değil, COBOL ve JCL semantiğini de anlayan bir araç gerektirir.
Denetime Hazır Uyumluluk Paketinin Oluşturulması
Hukuk, uyumluluk veya harici bir denetçi lisans uyumluluğu kanıtı istediğinde, tarama raporu gereklidir ancak yeterli değildir. Denetime hazır uyumluluk paketi şunları içerir:
- Eksiksiz bağımlılık envanteriÜrün ve sürüme göre düzenlenmiş, geçişli bağımlılıklar da dahil olmak üzere her bileşen, sürüm ve lisans.
- Lisans yükümlülüğü matrisiMevcut her lisans kategorisi için, belirli yükümlülükler (atıf, kaynak açıklaması, değişiklik bildirimi) ve bunların nasıl yerine getirildiği.
- Atıf bildirimleri dosyasıAtıf gerektiren tüm bileşenler için, her lisansın gerektirdiği formatta (Apache-2.0 için NOTICE dosyası, MIT için LICENSE dosyası vb.) yasal bildirimler derlendi.
- Uyumsuzluk analiziBirleştirilmiş üründe uyumsuz lisans kombinasyonlarının bulunmadığına dair belgeler ve olası istisnai durumlar için yasal gerekçeler.
- SBOM yapıtıMevcut CycloneDX veya SPDX dosyası, imzalı ve zaman damgalı olmalı ve kapsam dahilindeki tüm bileşenleri içermelidir.
- Politika belgeleriKuruluşun yazılı açık kaynak lisans politikası, yeni lisansların onay sürecini de içermektedir.
- Onay kayıtlarıDahil edilmeden önce yasal inceleme gerektiren her türlü lisans için, belgelenmiş onay ve iş gerekçesi gereklidir.
- İyileştirme geçmişiDaha önce tespit edilen ihlallerin belgelendirilmesi ve bunların çözümü için alınan önlemler.
Özellikle birleşme ve devralma durum tespiti için: Alıcılar, teknik durum tespitinin bir parçası olarak bu paketi giderek daha fazla talep etmektedir. Çözülmemiş ihlaller içermeyen temiz bir uyumluluk paketi, durum tespiti sürecini hızlandırır. Tescilli bir üründe çözülmemiş GPL ihlallerini ortaya çıkaran bir paket, genellikle kapanış koşulu olarak fiyat ayarlaması, emanet hesabı gereksinimleri veya düzeltme ile sonuçlanır; bunların hepsi, bunları önleyecek uyumluluk programından daha pahalıdır.
Ne kadar SMART TS XL Kurumsal kod tabanlarında lisans uyumluluğunu destekler.
SMART TS XL'S uygulama bağımlılık eşlemesi Bu araç, özellikle standart yapısal bağımlılık analizi (SCA) araçlarının sınırlarına ulaştığı eski sistemlerde, kurumsal kod tabanları için yapısal bağımlılık analizi katmanını sağlar.
Ana bilgisayar ortamları için, bağımlılık haritası, her programın diğer her programı çağırmasını (JCL ve COBOL'a gömülü üçüncü taraf yardımcı program çağrılarını ortaya çıkararak), her programın dahil ettiği her copybook'u (tedarikçi tarafından sağlanan copybook bağımlılıklarını ortaya çıkararak) ve her programın eriştiği her veri kümesini (lisanslı veritabanı ürünlerine ilişkin veri katmanı bağımlılıklarını ortaya çıkararak) tanımlar. Bu analiz, paket yöneticisinin bulunmadığı ortamlarda lisans uyumluluğu denetimi için ön koşul olan bileşen envanterini üretir.
Statik kod analizi özelliği, belirli üçüncü taraf bileşenlerle ilişkili kod kalıplarını tanımlar: tescilli API çağrı imzaları, satıcıya özgü veri yapısı kuralları ve özel COBOL kaynak koduna gömülü lisanslı algoritma uygulamaları. Bu bulgular, manifest taramasının ulaşamadığı kod düzeyindeki bağımlılıklarla manifest tabanlı envanteri tamamlar.
Etki analizi özelliği, lisans politikası değişikliklerini uygulanabilir hale getirir: bir bileşenin lisansı değişirse, bir bağımlılık MIT'den AGPL-3.0'a yeniden lisanslanırsa veya bir tedarikçi şartlarını değiştirirse, etki analizi, doğrudan veya dolaylı olarak bu bileşene bağımlı olan portföydeki her programı belirler. Bu, bir lisans değişikliği olayını bilinmeyen bir riskten tanımlanmış bir çözüm kapsamına dönüştürür.
Kurumsal arama özelliği, uyumluluk amacıyla bağımlılık envanterini sorgulanabilir hale getirir: belirli bir yardımcı programı çağıran her programı, belirli bir tedarikçi tarafından sağlanan üyeyi içeren her copybook'u, belirli bir lisanslı bileşene bağımlı olan her programı saniyeler içinde, tüm eski portföy genelinde bulun. Bu arama özelliği, Salı sabahı birleşme ve devralma denetim talebi için pratik bir araçtır: manuel inceleme yerine sorgulama.
Hem modern hem de eski sistemleri kapsayan kapsamlı bir SBOM (Ürün Yönetim Planı) oluşturmak isteyen kuruluşlar için, SMART TS XL Bu araç, standart SBOM oluşturucularının üretemediği eski bileşen envanterini sağlar ve Syft, FOSSA ve Dependency-Track gibi modern teknoloji yığınına yönelik araçları tamamlar.
Asla Sürpriz Olmaması Gereken Denetim
Lisans uyumluluğu denetimi, uyumsuzluğun cezasının genellikle bir düzenleyici kurum tarafından değil, lisans şartlarını okuyan ve uyumluluk kanıtı isteyen bir iş ortağı, alıcı, müşterinin hukuk ekibi veya dağıtıcı tarafından keşfedildiği az sayıdaki düzenleyici disiplinden biridir. Bu keşfin maliyeti, ihlalin ciddiyetine ve işlemin aşamasına bağlı olarak, rahatsız edici olmaktan varoluşsal olmaya kadar değişebilir.
Bu keşfin sürpriz olmasını önleyen bağımlılık analizi programı, azalttığı riske kıyasla pahalı değildir. Yazılımda ne olduğunu, her bileşeni, her geçişli bağımlılığı, her tedarikçi kod parçasını, her eski yardımcı programı bilmeyi ve bunların her birini periyodik olarak değil, sürekli olarak kuruluşun lisans politikasına göre kontrol etmeyi gerektirir. Araçlar mevcut. Standartlar (SBOM, SPDX, CycloneDX) mevcut. Yasal zorunluluk (EO 14028, CRA, PCI-DSS 4.0) mevcut. Çoğu kuruluş için eksik olan tek parça, bağımlılık analizini bir denetim çalışması olarak değil, altyapı olarak ele alma disiplinidir.
Yangın tatbikatı yerine bir raporla başlayan salı sabahı, bağımlılık analizi altyapısının mümkün kıldığı salı sabahıdır.
