Licențiere software și API

1) De ce contează pentru iGaming

Platforma se bazează pe codul de proprietate, biblioteci terțe, SDK-uri ale furnizorilor de jocuri/plăți și API-uri publice/private. Erorile de licență conduc la revendicări, blocuri de integrare, scurgeri de informații IP și riscuri de reglementare (confidențialitate/sancțiuni/exporturi de cripto). Scopul este de a construi o schiță transparentă a drepturilor: ce puteți publica, integra, transfera către parteneri și cum să vă protejați propriile API-uri.

2) Modele de licențiere software (prezentare generală)

Drepturi de proprietate (licență închisă): drepturi exclusive din partea vânzătorului; pentru B2B (operatori, studiouri, PSP).

• Permisiv: MIT, BSD, Apache-2. 0 (acordarea brevetului).
• Copyleft: GPL/LGPL/AGPL - compatibilitate „infectare”; cu atenție în module închise.
• Dual/Multi-licențiere: gratuit OSS sucursală + licență comercială cu drepturi extinse/suport.
• Acordarea de licențe SaaS: acces ca serviciu; codul nu este transmis, drepturile - pentru utilizare.

Reguli de selecție: servicii critice (motor de joc, antifraudă, calcule) - evitați copyleft; Biblioteci UI - permisive; instrumente interne - GPL este posibil în timpul izolării.

3) Drepturi și restricții: ce să vedeți în licențe

Domeniu de aplicare: teritorii, date, utilizatori/instalații, medii (prod/stage/dev).
Modificări și derivate: este posibilă furculița, schimbarea, distribuirea.
Sublicențiere/transfer: este permis pentru afiliați/etichetă albă.
Acordarea brevetelor și încetarea defensivă (Apache-2. 0, MPL): riscuri de brevete și licențe încrucișate.
Audit și raportare: dreptul vânzătorului de a efectua audituri de licențiere.
Securitate/export: restricții de criptografie, țări/sancțiuni.
Despăgubiri și răspundere: cine acoperă cererile/daunele IP.

4) Open Source: Politică și control

Lista albă: MIT/BSD/Apache-2. 0, MPL-2. 0.
Galben: LGPL-3. 0 (în cazul în care legătura dinamică și condițiile sunt îndeplinite).
Red: AGPL/GPL-3. 0 în servicii închise dacă nu există izolare (limite de serviciu, copyleft de rețea).
Software Bill of Materials (SBOM) - Lista solicitată de dependențe cu versiuni/licențe.
Procedura OSS: solicitarea → evaluarea legală/tehnică a compatibilității → înregistrarea în registru → auditul periodic.
Contribuția la OSS (în amonte): CLA/DCO, revizuirea informațiilor IP, concomitent cu Legal.

5) licențe SDK și furnizor (jocuri, plăți, KYC)

Cerințe tipice: interzicerea ingineriei inverse, interzicerea cachingului în afara condițiilor, controlul logo-urilor/brandingului, versiuni minime, audit-right.
Date: frontiere „date operator” vs „date furnizor” care deține valori și date derivate.
Restricții de export/sancțiuni: geo-blocuri, liste de PEP/sancțiuni - verificare obligatorie în ToS/licențe.
Suport/actualizări: SLA pentru patch-uri, modificări de rupere, termene de migrare.

6) API: termeni legali de acces (pentru partners/affiliates/B2B)

• Acces și autentificare: OAuth2/HMAC/mutual-TLS; interzicerea transferului de chei către terți.
• Limite de tarif și cote: SPR/minute/zi; „utilizare corectă”; politica de explozie.
• SLA și suport: disponibilitate (ex. 99. 9%), ferestre de întreținere, plan de incidente/comunicații.
• Versioning/epuizare: SemVer, date EOL (de exemplu, ≥ 9-12 luni), trimiterea de notificări.

• Date generate de servicii (jurnale, valori) - proprietarul API;
• Customer/Player Data - la client/operator;
• Date derivate - prin contract (permis/limitat, anonimizare).
• Cache și stocare: ce și cum pot fi cache (TTL, interzicerea stocării câmpurilor personale/sensibile).
• Confidențialitate/AML/KYC: roluri (controler/procesor), DPA/DSA, transmisii transfrontaliere, DPIA pentru scenarii cu risc ridicat.
• Securitate: criptare tranzit/în repaus, gestionare secretă, cerințe SOC2/ISO 27001 (dacă este cazul).
• Interdicții: inginerie inversă, răzuire, măsurare/evaluare comparativă fără consimțământ, modificarea răspunsurilor API.
• Audit și jurnale: dreptul de a verifica, cerințe pentru jurnalele de cerere.
• Sancțiuni și export: interzicerea utilizării în țări/cu utilizatori din liste, screening.
• Excluderea garanțiilor și limita răspunderii: plafon (de exemplu, 12 × greutate medie. plata).
• Încetarea accesului: imediat în caz de amenințare/lege privind securitatea; planul de ieșire.

7) Politica de versioning și compatibilitate

SemVer: MAJOR (rupere), MINOR (caracteristici), PATCH (fix).
Contracte schemă: Schema JSON/OpenAPI; testele contractuale pentru clienți.
Procedura de abatere: anunțarea perioadei → compatibilitate (≥ 6 luni) → eliminarea → EOL; ghid de migrare.
Caracteristică steaguri: pentru „moale” de rulare.

8) Controlul exportului, sancțiuni, criptografie

Exportul de criptografie: verificarea regulilor locale; notificări/cod ECC/lungimi de biți.
Sancțiuni: interdicția de a servi/da acces rezidenților din jurisdicțiile/persoanele de sub sancțiune; anularea periodică.
Reziliența legislației: clauze privind suspendarea serviciului cu risc de reglementare.

9) Matrice de risc (OAR)

10) Lista de verificare pre-lansare/integrare

• SBOM asamblate; licențe verificate (fără incompatibilitate).
• Sunt semnate licențele furnizor/SDK; date și drepturi de marcă.
• DPA/DSA emise; rolurile supervizor/procesor sunt definite.
• Termeni/API-uri EULA actualizate; limitele de rată/SLA/epuizare sunt prescrise.
• Sancțiune/screening-ul de export în procese.
• Securitate: chei, rotație, criptare, logare.
• Planul de incidente și acces rechemare (killswitch) gata.

11) Registre și artefacte (formate recomandate)

11. 1 Registru SBOM/licență

yaml component: "payment-gateway-sdk"
version: "4. 2. 1"
license: "Apache-2. 0"
source: "maven"
usage: "runtime"
notes: "requires notice file"
dependencies:
- name: "okhttp"
version: "4. 12. 0"
license: "Apache-2. 0"
- name: "commons-io"
version: "2. 16. 1"
license: "Apache-2. 0"
owner: "Engineering"

11. 2 API Client Register

yaml client_id: "aff-778"
app_name: "AffTrack"
scopes: ["reports:read","players:read_limited"]
rate_limit_rps: 5 quota_daily: 50_000 dpa_signed: true sanctions_screened_at: "2025-11-05"
status: "active"
owner: "API Ops"

11. 3 Registry SDK/Furnizori

yaml vendor: "GameProviderX"
agreement: "SDK-License-2025-10"
audit_rights: true brand_rules: true data_rights:
provider_metrics: "vendor"
operator_metrics: "shared"
derived_data: "anonymized_allowed"
sla:
incidents: "P1:2h,P2:8h"
updates: "quarterly"

12) Șabloane (fragmente)

12. 1 EULA (fragment intern)

12. 2 Termeni API (fragment intern)

12. 3 Codul de probă/Dock licențiere

13) Confidențialitate și date (API/SDK)

Minimizare: nu dați câmpuri suplimentare (PII), utilizați identificatori „translucizi”.
Cache TTL: strict fixat; Interziceți copierea locală a haldelor complete.
Drepturile persoanelor vizate: cereri de rutare (acces/ștergere) prin intermediul operatorului; logare.
Pseudonimizare/anonimizare: pentru analiză/date derivate - înainte de publicare.

14) Playbooks

P-LIC-01: Copyleft detectat în serviciul de producție

SBOM audit migrație/izolare opțiune JUR plan de lansare retrospectivă.

P-API-02: API cheie scurgere

Revocarea cheie → notificarea clientului → criminalistică → rotație secretă → actualizarea politicii.

P-SDK-03: Furnizorul întrerupe compatibilitatea

Adaptor de tranziție → filială API temporară → negocieri pentru a extinde fereastra → distribuția către clienți.

P-XPORT-04: Pavilion sancțiune

Accesul prin autoblocare → corespunde confirmării → evaluării legale → documentelor pentru autoritatea de reglementare.

15) KPI/Metrics

SBOM Acoperire% și procentul de componente aprobate.
Ora închiderii incidentului de licență (copyleft/incompatibilitate).
Respingere Conformitate% (clienți pe versiunea curentă).
Time-to-Revoke scurgeri cheie și MTTR pentru incidente API.
Proporția de clienți cu un semnat DPA/DSA și sanie screening trecut.

16) Mini-Întrebări frecvente

Pot încorpora LGPL? Da, cu o legătură dinamică și respectarea condițiilor, o reparăm în SBOM.
Cine deține API analytics? În mod implicit - proprietarul API (Service-Generated), clientul - o licență limitată.
Pot antrena ML pe datele API? Numai pe anonimizat/agregat și dacă este permis de către ToS/DPA.
Cât de mult să dețină EOL? Recomandat 9-12 luni cu ghid de migrare.

17) Concluzie

Licențierea software și API nu este un „ciclu unic semnat”, ci un ciclu constant: alegerea licențelor compatibile, întreținerea SBOM, Termeni clari API (date/cote/SLA/epuizare), DPA/sancțiuni și registre operaționale. Standardizați listele și șabloanele - și veți reduce riscurile juridice, veți simplifica integrările și veți proteja propriile IP și date ale jucătorilor.