Licențe și restricții Open Source
1) De ce OSS în iGaming și unde sunt riscurile
OSS accelerează dezvoltarea platformei (front/back joc, integrarea plăților, anti-fraudă, analiză), dar erorile de licențiere conduc la divulgarea codului închis, blocarea eliberării și disputele cu furnizorii. Avem nevoie de: o politică clară, un registru al dependențelor (SBOM), procese de audit și selectarea corectă a licențelor.
2) Harta licenței: tipuri și semnificații
2. 1 Permisiv
MIT, BSD-2/3-Clause, Apache-2. 0
Principala responsabilitate este de a păstra notificarea/drepturile de autor Apache-2. 0, de asemenea, grant de brevet + „încetare defensivă”.
Potrivit pentru: cadre UI, utilități, clienți SDK, biblioteci logare/HTTP.
2. 2 Copyleft slab
MPL-2. 0, LGPL-2. 1/3. 0
Necesită modificări de deschidere în bibliotecă/modul în sine, dar nu întregul proiect.
Conectarea dinamică cu LGPL este de obicei permisă dacă sunt îndeplinite condițiile (înlocuirea utilizatorului, notificări).
2. 3 Copyleft puternic
GPL-2. 0/3. 0, AGPL-3. 0
Atunci când „conectarea” cu codul dvs., apare obligația de a dezvălui lucrarea derivată sub aceeași licență (condițiile „tivoization”, „SaaS închidere” închide AGPL).
Risc pentru modulele închise ale nucleului jocului, anti-fraudă, gateway-uri de plată.
3) Legarea și „produsul derivat” (simplificat)
Legătura statică cu LPG → un risc ridicat de „infecție”.
Conectarea dinamică cu → LGPL este de obicei permisă sub rezerva condițiilor (înlocuire, notificări).
IPC/REST/gRPC, procese individuale → reduce riscul de performanță, dar nu anulează analiza (AGPL tratează „prin rețea” ca „conexiune”).
Plugin-urile/scripturile sunt evaluate → prin integrarea efectivă (stabilitatea API, încărcarea în spațiul de adrese).
4) Brevete și declinări
Apache-2. 0 oferă licențierea brevetelor autorului → reduce riscul cererilor de brevet.
GPL-3. 0/AGPL-3. 0 au pozitii anti-brevet/anti-eludare.
Dacă modulul dvs. este semnificativ pentru brevete (matematica RNG, algoritmi anti-fraudă), evitați licențele fără o subvenție pentru brevete sau adăugați legături de brevete separate la acordurile comerciale.
5) responsabilitățile OSS: ce anume să faceți
Salvați notificări/NOTIFICARE (permisisisve).
Dezvăluie modificările componentelor copyleft (MPL/LGPL/GPL) și metoda de reasamblare.
Furnizați surse atunci când distribuiți binare pentru GPL/LGPL (și acces la rețea pentru AGPL).
Specificați licența în pagina Despre caseta/OSS Credite.
Urmăriți licențele terților în expedieri (furnizori de jocuri/SDK/mobile build-uri).
6) Politica OSS platformă (minim recomandat)
1. Clasificarea licențelor: verde (MIT/BSD/Apache/MPL), galben (LGPL în condiții), roșu (GPL/AGPL/SSPL pentru piese închise).
2. Procesul de admitere a componentelor: cerere → evaluare juridică și tehnică → înregistrare în SBOM → audit periodic.
3. Izolarea copyleft: proces separat/microservice, frontieră gRPC/HTTP, fără legături statice.
4. Construiți SBOM: pentru fiecare lansare prod/etapă.
5. Notificări și surse: generarea automată de NOTIFICARE/TERȚĂ PARTE și publicarea surselor, dacă este necesar.
6. Contribuții (în amonte): CLA/DCO, lipsa secretelor/brevetelor, coordonarea cu Legal.
7. Securitate: scanarea vulnerabilităților, politica de patch-uri, interzicerea versiunilor vulnerabile „pin” fără renunțare.
7) OSS în zonele tipice iGaming (cele mai bune practici)
Matematica jocului/RNG: Evitați GPL/AGPL; prefera propriul cod sau biblioteci permisive.
UI/client: React/Vue/bundlers - permisiv → ok, monitor licențe și fonturi.
Plăți/CCM: SDK de vânzători cu ToS stricte; nu se amestecă cu copyleft.
Observabilitate/DevOps: Prometheus/Grafana/Elastic - luați în considerare licențele lor (parte a modulelor non-OSS); citiți condițiile „partea serverului”.
Antifraudă/scoring: model/reguli - proprietate; terțe părți libs - permisiv/MIT/Apache.
8) Matrice de compatibilitate (pe scurt)
9) Matrice de risc (OAR)
10) Liste de verificare
Înainte de a adăuga o bibliotecă
- Licența bibliotecii în lista verde/galben.
- Compatibilitate legătură (static/dinamic/IPC) verificat.
- SBOM + versiune + sursă.
- Notificări generate (LICENȚĂ/NOTIFICARE).
Înainte de lansare
- SBOM pe ansamblu salvat (prod/etapă).
- Scanarea vulnerabilității a trecut; critică - închisă sau renunțare.
- Sursa/patch-uri necesare sunt gata pentru a fi emise (dacă este necesar).
- „OSS Credite „/Despre pagina actualizată.
Pentru contribuții
- CLA/DCO semnat.
- Revizuire pentru lipsa secretelor/brevetelor.
- Drepturile de autor/drepturile de autor sunt corecte.
11) Politica OSS (fragmente)
11. 1 Clasificare
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 Procesul de admitere
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 Izolarea copyleft-ului
Serviciu separat, interfață de rețea, nici o combinație de binare, nici o legătură statică.
Biblioteca Construirea și actualizarea documentației (LGPL/MPL).
12) Registre (șabloane YAML)
12. 1 SBOM/terță parte
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 surse OSS pentru divulgare
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 Registrul depozitelor (amonte)
yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"13) Siguranță și conformitate
SCA/SAST în CI, autoscan de noi dependențe.
Politica de patch-uri: P1 vulnerabilități - ≤72 ore, P2 - ≤14 zile.
Artefact Cache: Păstrați originalul LICENȚĂ/NOTIFICARE; verificați integritatea (hash-uri).
Export/sancțiune: Nu utilizați componente/oglinzi din țări interzise; verificări jurnal.
14) Playbooks (scenarii operaționale)
P-OSS-01: GPL detectat în modul închis
Link inventar → izolare/înlocuire opțiune → opinie legală → eliberare fix → retro pe proces.
P-OSS-02: Cerință sursă
Determinați domeniul de aplicare al obligațiilor → pregătirea arhivelor și NOTĂ → transferul la timp → documentația actualizată.
P-OSS-03: Vulnerabilitate critică în dependență
Backport/actualizare → eliberare extraordinară → notificarea regulilor → post-maritime și de fixare.
15) Mini-Întrebări frecvente
Pot folosi LGPL? Da, cu conectare dinamică/IPC și respectarea condițiilor (înlocuibilitate, notificări).
AGPL pe server fără distribuirea binarului - este sigur? Nu: AGPL necesită furnizarea de cod sursă pentru utilizatorii care interacționează cu serviciul prin rețea.
Am nevoie de un brevet? De dorit pentru module cu inovații algoritmice; Apache-2. 0 este de preferat.
Este suficient să specificați OSS pe site? Nu, urmați toate cerințele: notificări, surse, instrucțiuni.
16) Concluzie
Lucrul cu OSS este un proces, nu o verificare unică: standarde de admitere, izolare copyleft, notificări automate și un SBOM complet pe ansamblu. Urmând acest articol, veți menține viteza de dezvoltare și veți evita capcanele legale - de la "copyleft' la cererile de brevete.