Open Source lisenziyalar və məhdudiyyətlər
1) Niyə iGaming-də OSS və harada risklər
OSS platformanın inkişafını sürətləndirir (oyun cəbhəsi/geri, ödəniş inteqrasiyaları, antifrod, analitika), lakin lisenziyalaşdırmadakı səhvlər qapalı kodun açılmasına, buraxılışların bloklanmasına və provayderlərlə mübahisələrə səbəb olur. Dəqiq siyasət, asılılıq reyestri (SBOM), audit prosesləri və lisenziyaların düzgün seçilməsi lazımdır.
2) Lisenziya kartı: növləri və mənası
2. 1 Permissive (icazə)
MIT, BSD-2/3-Clause, Apache-2. 0
Əsas vəzifə bildiriş/kopyasını Apache-2 saxlamaqdır. 0 həmçinin patent qrantı + «defensive termination».
Üçün uygundur: UI frameworks, utilit, SDK-müştərilər, log kitabxanaları/NTTR.
2. 2 Weak copyleft (zəif kopileft)
MPL-2. 0, LGPL-2. 1/3. 0
Bütün layihənin deyil, kitabxananın/modulun daxilində dəyişikliklərin açılması tələb olunur.
LGPL ilə dinamik link adətən şərtlər yerinə yetirildikdə icazə verilir (versiyanı istifadəçi tərəfindən dəyişdirmək imkanı, bildirişlər).
2. 3 Strong copyleft (güclü kopileft)
GPL-2. 0/3. 0, AGPL-3. 0
Kodunuzla «əlaqə» zamanı törəmə məhsulun eyni lisenziya altında açıqlanması öhdəliyi yaranır («tivoization», «SaaS-qapanma» şərtləri AGPL-i bağlayır).
Oyun nüvəsinin qapalı modulları, antifrod, ödəniş şlüzləri üçün risk.
3) Linkovka və «törəmə» (sadələşdirilmiş)
GPL → yüksək «yoluxma» riski ilə statik linking.
LGPL → ilə dinamik link adətən şərtlərə riayət edildikdə icazə verilir (əvəzedilebilirlik, bildirişlər).
IPC/REST/gRPC, fərdi proseslər → istehsal riskini azaldır, lakin təhlili ləğv etmir (AGPL «şəbəkə vasitəsilə» «əlaqə» kimi şərh edir).
Plugin/script → faktiki inteqrasiya ilə qiymətləndirilir (API sabitlik, ünvan məkanına yükləmə).
4) Patent və şərtlər
Apache-2. 0 müəllifin patent lisenziya verir → patent iddiaları riskini azaldır.
GPL-3. 0/AGPL-3. 0 anti-patent/anti-circumvention mövqeləri var.
Modulunuz - patent əhəmiyyətli (RNG-riyaziyyat, antifrod alqoritmləri) - patent qrantı olmadan lisenziyalardan qaçın və ya kommersiya müqavilələrinə ayrı-ayrı patent kovenantları əlavə edin.
5) OSS öhdəlikləri: tam olaraq nə etmək lazımdır
Bildirişləri/NOTICE (permisisve) saxla.
Kopileft komponentlərinin modifikasiyalarını (MPL/LGPL/GPL) və yenidən yığma üsulunu aşkar edin.
GPL/LGPL (və AGPL altında şəbəkə girişi) altında binarniklərin yayılması zamanı mənbələri təmin edin.
Lisenziyanı «Proqram haqqında «pəncərəsində/« OSS Credits »səhifəsində göstərin.
Təchizatda üçüncü tərəf lisenziyalarını izləyin (oyun satıcıları/SDK/mobil siyahılar).
6) Platforma üçün OSS siyasəti (tövsiyə olunan minimum)
1. Lisenziyaların təsnifatı: yaşıl (MIT/BSD/Apache/MPL), sarı (şərtlər altında LGPL), qırmızı (qapalı hissələr üçün GPL/AGPL/SSPL).
2. Komponent qəbul prosesi: sorğu → hüquqi və texniki qiymətləndirmə → SBOM-da qeyd → dövri audit.
3. Kopileft izolyasiyası: ayrıca proses/mikroservis, gRPC/HTTP sərhəd, statik link yoxdur.
4. SBOM montaj: hər buraxılış prod/stage üçün.
5. Bildirişlər və mənbələr: NOTICE/THIRD-PARTY-nin avtomatik generasiyası və mənbələrin lazım olduğu yerdə dərc edilməsi.
6. Depozitlər (upstream): CLA/DCO, sirlərin/patentlərin yoxlanılması, Legal ilə razılaşdırılması.
7. Security: həssaslıq taraması, yamaq siyasəti, waiver olmadan həssas versiyaların «pin» qadağan.
7) Tipik iGaming zonalarında OSS (ən yaxşı practice)
Oyun riyaziyyatı/RNG: GPL/AGPL qarşısını almaq; öz kodu və ya permissive-kitabxana üstünlük.
UI/müştəri: React/Vue/Bandlers - permissive → ok, lisenziyalar və şriftləri izləmək.
Ödənişlər/KUS: SDK satıcıları ilə ciddi ToS; kopileft ilə qarışdırmayın.
Observability/DevOps: Prometheus/Grafana/Elastic - onların lisenziyalarını nəzərə almaq (OSS olmayan modulların bir hissəsi); oxu «server side» şərtlər.
Antifrod/skoring: model/qaydalar - proprietar; üçüncü tərəf libas - permissive/MIT/Apache.
8) Uyğunluq cədvəli (qısaca)
9) Risk matrisi (RAG)
10) Çek vərəqləri
Kitabxana əlavə edilməzdən əvvəl
- «Yaşıl/sarı» siyahıda kitabxana lisenziyası.
- Sınaq uyğunluğu (static/dynamic/IPC).
- SBOM + versiyası + mənbə qeyd.
- Bildirişlər yaradıldı (LICENSE/NOTICE).
Buraxılışdan əvvəl
- SBOM montaj saxlanılır (prod/stage).
- Həssaslıq skan keçdi; kritik - bağlı və ya waiver.
- Tələb olunan mənbələr/yamalar verilməyə hazırdır (lazım olduqda).
- «OSS Credits »/About səhifəsi yenilənib.
Əmanətlər üçün (contributions)
- CLA/DCO imzalanmışdır.
- Sirlərin/patentlərin olmaması haqqında Review.
- Müəllif hüquqları/kopyası düzgün qoyulmuşdur.
11) OSS siyasəti (fraqmentlər)
11. 1 Təsnifat
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 Qəbul prosesi
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 Kopileftin izolyasiyası
Ayrı xidmət, şəbəkə interfeysi, binar birləşməsi, statik link yoxdur.
Kitabxanaların yığılması və yenilənməsi sənədləri (LGPL/MPL).
12) Reyestrlər (YAML şablonları)
12. 1 SBOM / third-party
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. 2 OSS-mənbələri açıqlamaq üçün
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 Depozit reyestri (upstream)
yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"13) Təhlükəsizlik və uyğunluq
CI-də SCA/SAST, yeni asılılıqların avto-skan edilməsi.
Yamaq siyasəti: P1 zəifliklər - ≤ 72 saat, P2 - ≤ 14 gün.
Cache artefaktları: orijinal LICENSE/NOTICE saxlayın; bütövlüyü yoxlayın (hash).
İxrac/sanksiyalar: qadağan olunmuş ölkələrdən komponentlər/güzgülər istifadə etməyin; yoxlamalar loqot.
14) Playbook (əməliyyat ssenariləri)
P-OSS-01: Qapalı modulda GPL aşkar
Əlaqələrin inventarlaşdırılması → təcrid/dəyişdirmə variantı → hüquqi nəticə → azad fiks → proses üzrə retro.
P-OSS-02: Mənbə tələbi
Öhdəliklərin həcmini müəyyən edin → arxivləri hazırlayın və NOTICE → vaxtında köçürün → sənədləri yeniləyin.
P-OSS-03: Asılı kritik zəiflik
Backport/update → fövqəladə release → maraqlı bildiriş → post-dəniz və pinning qaydaları.
15) Mini-FAQ
LGPL istifadə edilə bilərmi? Bəli, dinamik link/IPC və şərtlərə riayət edərkən (əvəzedilebilirlik, bildirişlər).
AGPL bir binar yaymadan server - təhlükəsiz? Yox: AGPL şəbəkə xidməti ilə qarşılıqlı əlaqədə olan istifadəçilərə mənbələrin verilməsini tələb edir.
Patent qrantı lazımdırmı? Alqoritmik yenilikləri olan modullar üçün arzu olunur; Apache-2. 0 üstünlük verilir.
Saytda OSS göstərmək kifayətdir? Yox, bütün tələbləri yerinə yetirin: bildirişlər, mənbələr, təlimatlar.
16) Nəticə
OSS ilə işləmək birdəfəlik yoxlama deyil, bir prosesdir: qəbul standartları, kopileft izolyasiyası, avtomatlaşdırılmış bildirişlər və hər bir montaj üçün tam SBOM. Bu məqalədən sonra siz inkişaf sürətini saxlayacaqsınız və hüquqi tələlərdən - «şəbəkə kopileftindən» patent iddialarına qədər qaçacaqsınız.