Açık Kaynak Lisanslar ve Kısıtlamalar
1) Neden iGaming'de OSS ve riskler nerede
OSS, platform geliştirmeyi hızlandırır (oyun önü/arkası, ödeme entegrasyonları, sahtekarlık önleme, analitik), ancak lisanslama hataları kapalı kod açıklamasına, serbest bırakma engellemesine ve sağlayıcılarla anlaşmazlıklara yol açar. İhtiyacımız olan: açık bir politika, bağımlılıkların kaydı (SBOM), denetim süreçleri ve doğru lisans seçimi.
2) Lisans haritası: türleri ve anlamı
2. 1 İzin verici
MIT, BSD-2/3-Clause, Apache-2. 0
Birincil sorumluluk bildirimi/telif hakkı Apache-2 tutmaktır. 0 ayrıca patent hibesi + "savunma feshi".
Aşağıdakiler için uygundur: UI çerçeveleri, yardımcı programlar, SDK istemcileri, günlük kaydı/HTTP kitaplıkları.
2. 2 Zayıf copyleft
MPL-2. 0, LGPL-2. 1/3. 0
Tüm projenin değil, kütüphanenin/modülün kendisinde değişikliklerin açılmasını gerektirir.
LGPL ile dinamik bağlantıya genellikle koşullar yerine getirildiğinde izin verilir (kullanıcı değiştirilebilirlik, bildirimler).
2. 3 Güçlü copyleft
GPL-2. 0/3. 0, AGPL-3. 0
Kodunuzla "bağlantı" kurarken, türev çalışmanın aynı lisans altında açıklanması zorunluluğu doğar ("tivoizasyon", "SaaS kapatma" koşulları AGPL'yi kapatır).
Oyun çekirdeğinin kapalı modülleri, dolandırıcılıkla mücadele, ödeme ağ geçitleri için risk.
3) Bağlama ve "türev ürün" (basitleştirilmiş)
GPL ile statik bağlantı - yüksek bir "enfeksiyon" riski.
LGPL ile dinamik bağlantıya genellikle koşullara (değiştirilebilirlik, bildirimler) tabi olarak izin verilir.
IPC/REST/gRPC, bireysel süreçler performans riskini azaltır, ancak analizi iptal etmez (AGPL "ağ üzerinden" "bağlantı'olarak davranır).
Eklentiler/komut dosyaları gerçek entegrasyon (API kararlılığı, adres alanına yükleme) ile değerlendirilir.
4) Patentler ve feragatnameler
Apache-2. 0, yazarın patentlerinin lisanslanmasını sağlar - patent talepleri riskini azaltır.
GPL-3. 0/AGPL-3. 0 anti-patent/anti-atlatma pozisyonlarına sahiptir.
Modülünüz patent açısından önemliyse (RNG matematiği, dolandırıcılık önleme algoritmaları), patent hibesi olmadan lisanslardan kaçının veya ticari sözleşmelere ayrı patent sözleşmeleri ekleyin.
5) OSS sorumlulukları: tam olarak ne yapmalı
Bildirimleri/NOTICE (permisisve) kaydedin.
Copyleft bileşenlerinin (MPL/LGPL/GPL) modifikasyonlarını ve yeniden birleştirme yöntemini ortaya çıkarın.
GPL/LGPL için ikili dosyaları (ve AGPL için ağ erişimi) dağıtırken kaynak sağlayın.
Lisansı Hakkında kutusunda/OSS Kredileri sayfasında belirtin.
Gönderilerdeki üçüncü taraf lisansları takip edin (oyun satıcıları/SDK'lar/mobil yapılar).
6) Platform OSS politikası (önerilen minimum)
1. Lisansların sınıflandırılması: yeşil (MIT/BSD/Apache/MPL), sarı (koşullar altında LGPL), kırmızı (kapalı parçalar için GPL/AGPL/SSPL).
2. Bileşen kabul süreci: talep - yasal ve teknik değerlendirme - SBOM'da kayıt - periyodik denetim.
3. Copyleft izolasyonu: ayrı işlem/mikro servis, gRPC/HTTP kenarlığı, statik bağlantı yok.
4. Build SBOM: Her bir prod/stage sürümü için.
5. Bildirimler ve kaynaklar: NOTICE/THIRD-PARTY'nin otomatik olarak oluşturulması ve gerektiğinde kaynakların yayınlanması.
6. Katkılar (upstream): CLA/DCO, sır/patent eksikliği, Legal ile koordinasyon.
7. Güvenlik: güvenlik açıklarını tarama, yama politikası, savunmasız sürümleri feragat etmeden "pin" yasaklama.
7) Tipik iGaming bölgelerinde OSS (en iyi uygulama)
Oyun Matematiği/RNG: GPL/AGPL'den kaçının; Kendi kodunuzu veya izin verilen kütüphaneleri tercih edin.
UI/client: React/Vue/bundlers - permissive - tamam, lisansları ve yazı tiplerini izleyin.
Ödemeler/CCM: Sıkı ToS ile satıcıların SDK; copyleft ile karıştırmayın.
Gözlemlenebilirlik/DevOps: Prometheus/Grafana/Elastic - lisanslarını dikkate alın (OSS dışı modüllerin bir parçası); "Sunucu tarafı" koşullarını okuyun.
Antifraud/puanlama: model/kurallar - tescilli; Üçüncü taraf libs - izin verici/MIT/Apache.
8) Uyumluluk Matrisi (kısaca)
9) Risk Matrisi (RAG)
10) Kontrol listeleri
Kütüphane eklemeden önce
- Yeşil/sarı listedeki kütüphane lisansı.
- Bağlantı uyumluluğu (statik/dinamik/IPC) doğrulandı.
- SBOM + sürüm + kaynak.
- Oluşturulan bildirimler (LICENSE/NOTICE).
Yayınlanmadan Önce
- Montaj başına SBOM kaydedildi (prod/stage).
- Güvenlik açığı taraması geçti; kritik - kapalı veya feragat.
- Gerekli kaynak/yamalar (gerekirse) verilmeye hazırdır.
- "OSS Credits "/Sayfa hakkında güncellendi.
Katkılar için
- CLA/DCO imzaladı.
- Sır/patent eksikliği için gözden geçirme.
- Telif/telif hakkı doğrudur.
11) OSS Politikası (snippet'ler)
11. 1 Sınıflandırma
green: [MIT, BSD-2, BSD-3, Apache-2. 0, MPL-2. 0]
amber: [LGPL-2. 1, LGPL-3. 0] # speaker only/IPC + conditions red: [GPL-2. 0, GPL-3. 0, AGPL-3. 0, SSPL] # disallow for closed modules11. 2 Kabul süreci
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 Copyleft izolasyonu
Ayrı servis, ağ arayüzü, ikili dosya kombinasyonu yok, statik bağlantı yok.
Kütüphane Oluşturma ve Yükseltme Belgeleri (LGPL/MPL).
12) Kayıtlar (YAML şablonları)
12. 1 SBOM/üçüncü taraf
yaml component: "rng-core-utils"
version: "1. 8. 2"
license: "Apache-2. 0"
source: "maven:com. example:rng-core:1. 8. 2"
linkage: "dynamic"
notices: ["apache-2. 0. txt"]
security:
cvEs: []
owner: "Engineering"
approved_by: ["Legal","Security"]
approved_at: "2025-11-05"12. Açıklama için 2 OSS kaynağı
yaml package: "lgpl-math-lib"
our_version: "2. 3. 1-gamblehub"
license: "LGPL-3. 0"
modified_files: ["matrix. c","fft. c"]
public_src_url: "https://example. com/oss/lgpl-math-lib-2. 3. 1-src. zip"
build_instructions: "BUILD. md"12. 3 Depozito kaydı (yukarı akış)
yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"13) Güvenlik ve uyumluluk
CI'da SCA/SAST, yeni bağımlılıkların otoskanı.
Yama politikası: P1 güvenlik açıkları - ≤72 saat, P2 - ≤14 gün.
Artifact Cache: Orijinal LICENSE/NOTICE tutun; Bütünlüğü kontrol et (karma).
İhracat/yaptırım: Yasaklı ülkelerden gelen bileşenleri/aynaları kullanmayın; Kayıt kontrolleri.
14) Playbook'lar (operasyonel senaryolar)
P-OSS-01: Kapalı modülde GPL algılandı
Bağlantı envanteri - izolasyon/değiştirme seçeneği - yasal görüş - serbest bırakma düzeltmesi - süreçte retro.
P-OSS-02: Kaynak gereksinimi
Yükümlülüklerin kapsamını belirleyin - arşivleri hazırlayın ve NOTICE - zamanında aktarın - belgeleri güncelleyin.
P-OSS-03: Bağımlılıkta kritik kırılganlık
Backport/update - extraordinary release - ilgilenen - deniz sonrası ve sabitleme kurallarının bildirimi.
15) Mini-SSS
LGPL kullanabilir miyim? Evet, dinamik bağlantı/IPC ve koşullara uygunluk (değiştirilebilirlik, bildirimler) ile.
İkili dağıtmadan sunucuda AGPL - güvenli mi? Hayır: AGPL, ağ üzerinden hizmetle etkileşime giren kullanıcılara kaynak kodu sağlamayı gerektirir.
Patent desteğine ihtiyacım var mı? Algoritmik yeniliklere sahip modüller için arzu edilir; Apache-2. 0 tercih edilir.
Sitede OSS'yi belirtmek yeterli mi? Hayır, tüm gereksinimleri takip edin: bildirimler, kaynaklar, talimatlar.
16) Sonuç
OSS ile çalışmak bir kerelik bir kontrol değil, bir süreçtir: kabul standartları, copyleft izolasyonu, otomatik bildirimler ve montaj başına tam bir SBOM. Bu makaleyi takip ederek, geliştirme hızını koruyacak ve "ağ copyleft'ten patent iddialarına kadar yasal tuzaklardan kaçınacaksınız.