Licenze e vincoli Open Source

1) Perché OSS nel iGaming e dove i rischi

OSS accelera lo sviluppo della piattaforma (gioco/back, integrazione dei pagamenti, antifrode, analisi), ma gli errori di licenza portano alla divulgazione del codice chiuso, al blocco dei comunicati e alle controversie con i provider. Sono necessari criteri chiari, registro delle dipendenze (SBOM), processi di verifica e una selezione corretta delle licenze.

2) Mappa licenze: tipi e significato

2. 1 Permissive

MIT, BSD-2/3-Clause, Apache-2. 0

L'obbligo principale è di salvare la notifica/copia in Apache-2. 0 è anche una borsa di studio brevetti + «defensive termination».
Adatto per: framework UI, utility, client SDK, librerie di loging/NTTR.

2. 2 Weak copyleft (copileft debole)

MPL-2. 0, LGPL-2. 1/3. 0

Richiede di aprire le modifiche all'interno della libreria/modulo stessa, ma non dell'intero progetto.
Il lincaggio dinamico con l'LGPL è generalmente valido quando vengono soddisfatte le condizioni (sostituibilità utente, notifica).

2. 3 Strong copyleft (forte copileft)

GPL-2. 0/3. 0, AGPL-3. 0

Quando si «connette» con il codice, si crea l'obbligo di divulgare un pezzo derivato con la stessa licenza (condizioni «tivoization», «SaaS-Circuito» chiude AGPL).
Rischio per moduli di gioco chiusi, antifrode, passerelle di pagamento.

3) Linkup e «pezzo derivato» (semplificato)

La linciatura statica con GPL è ad alto rischio di infezione.
Il lincaggio dinamico con LGPL è generalmente consentito in base alle condizioni (sostituibilità, notifiche).
, i singoli processi riducono il rischio di produzione, ma non annullano l'analisi (AGPL interpreta «tramite rete» come «connessione»).
I plugin/script sono valutati in base all'effettiva integrazione (API, download nello spazio direzionale).

4) Brevetti e riserve

Apache-2. 0 concede le licenze per i brevetti dell'autore, riducendo il rischio di reclami per brevetti.
GPL-3. 0/AGPL-3. 0 hanno posizioni anti-brevetto/anti-circumvation.
Se il modulo è rilevante per brevetti (matematica RNG, algoritmi antifrode), evitare licenze senza una borsa di studio per brevetti o aggiungere singoli covenanti a contratti commerciali.

5) Responsabilità di OSS: esattamente cosa fare

Salva notifiche/NOTICE (permisisive).
Espandi le modifiche al copileft (MPL/LGPL/GPL) e il metodo di sovrapposizione.
Fornire sorgenti per la distribuzione di binari con GPL/LGPL (e accesso di rete con AGPL).
Specifica la licenza nella finestra Informazioni o nella pagina Credits OSS.
Tracciare le licenze third-party nelle consegne (giochi vendor/SDK/mobile bild).

6) Criteri OSS per la piattaforma (minimo consigliato)

1. Classificazione delle licenze: verde (MIT/BSD/Apache/MPL), giallo (TGL in condizioni), rosso (GPL/AGPL/SSPL per le parti chiuse).

2. Processo di tolleranza del componente - Richiesta di valutazione legale e tecnica, scrittura su SBOM

3. Isolamento copileft: processo/microservice separato, bordo gRPC/HTTP, nessuna linfa statica.
4. SBOM di assemblaggio per ogni release prod/stage.
5. Notifiche e sorgenti - Generare automaticamente NOTICE/THIRD-PARTY e pubblicare i sorgenti dove si desidera.
6. Depositi (upstream): CLA/DCO, verifica della mancanza di segreti/brevetti, coerenza con Legale.
7. Sicurezza: scan di vulnerabilità, politica di patch, divieto di versioni vulnerabili pin senza waiver.

7) OSS nelle tipiche zone di iGaming (best practice)

Matematica del gioco/RNG: evitare GPL/AGPL; preferire il codice personalizzato o la libreria permissiva.
UI/client: React/Vide/Bandlers - permissive →, controllare licenze e caratteri.
Pagamenti/CUS: venditori SDK con ToS rigorosi; Non mescolare con copileft.
Abilità/DevOps: Prometheus/Grafana/Elastic - tenere conto delle loro licenze (parte dei moduli non OSS); leggere «server side» condizioni.
Antifrode/scorciatoia: modello/regole - propedeutico; laterale - permissive/MIT/Apache.

8) Tabella di compatibilità (in breve)

9) Matrice di rischio

10) Assegno fogli

Prima di aggiungere una libreria

• Licenza libreria nell'elenco verde/giallo.
• È stata verificata la compatibilità con il filetto (static/dynamic/IPC).
• Scrittura in SBOM + versione + origine.
• Notifiche generate (LICENSE/NOTICE).

Prima del lancio

• SBOM di assieme salvato (prod/stage).
• Scan di vulnerabilità superato; critico: chiuso o waiver.
• I sorgenti/patch richiesti sono pronti per il rilascio (se necessario).
• «OSS Credits »/About pagina aggiornata.

Per i depositi

• CLA/DCO firmato.
• Review sulla mancanza di segreti/brevetti.
• Copyright/copyright correttamente impostati.

11) Criteri OSS (sezioni)

11. 1 Classificazione

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 modules

11. 2 Processo di tolleranza

request → legal+tech review → approve/deny → SBOM entry → periodic audit

11. 3 Isolamento copileft

Servizio separato, interfaccia di rete, nessuna combinazione di binari, nessun filetto statico.
Documentazione per l'assemblaggio e l'aggiornamento delle librerie (WOLFPL/MPL).

12) Registri (modelli YAML)

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 sorgenti OSS per l'apertura

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 Registro dei depositi (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) Sicurezza e conformità

SCA/SAST in CI, scansione automatica di nuove dipendenze.
Politica di patch: P1 vulnerabilità - ≤72 h, P2 - ≤14 giorni.
Cache degli artefatti: memorizza i LICENSE/NOTICE originali; Verificare l'integrità (hash).
Esportazione/sanzioni: non utilizzare componenti/mirror da paesi proibiti; logica i controlli.

14) Playbook (script operativi)

P-OSS-01 Trovato GPL in un modulo chiuso

L'inventario delle relazioni l'opzione di isolamento/sostituzione, il parere legale, il feedback, il retro del processo.

P-OSS-02 Requisito dei sorgenti

Determinare l'entità dell'impegno, preparare gli archivi e NOTICE, consegnare entro la data di scadenza legale e aggiornare la documentazione.

P-OSS-03 Vulnerabilità critica a seconda

Backport/aggiornamento un comunicato straordinario, una notifica agli interessati per il post-mare e le regole del pinning.

15) Mini FAQ

È possibile utilizzare l'LGPL? Sì, in caso di allineamento dinamico/IPC e condizioni (sostituibilità, notifiche).
AGPL sul server senza distribuzione binario - sicuro? No: AGPL richiede di fornire i sorgenti agli utenti che interagiscono con il servizio sulla rete.
Serve una borsa di studio per brevetti? Desiderabile per i moduli con modifiche algoritmiche; Apache-2. 0 è preferibile.
È sufficiente specificare l'OSS sul sito? No, attenersi a tutti i requisiti: notifiche, sorgenti, istruzioni.

16) Conclusione

Il funzionamento con OSS è un processo, non un controllo monouso: standard di tolleranza, isolamento del copileft, notifiche automatizzate e SBOM completo per ogni assieme. In base a questo articolo, si mantiene la velocità di sviluppo e si evitano le trappole legali, dal «copileft di rete» alle rivendicazioni di brevetti.