Software and API licensing

1) Why it matters to iGaming

The platform relies on proprietary code, third-party libraries, game/payment provider SDKs, and public/private APIs. License errors lead to claims, integration blocks, IP leaks, and regulatory risks (privacy/sanctions/crypto exports). The goal is to build a transparent outline of rights: what you can publish, integrate, transfer to partners and how to protect your own APIs.

2) Software licensing models (overview)

Proprietary (closed license): exclusive rights from the vendor; for B2B (operators, studios, PSP).

• Permissive: MIT, BSD, Apache-2. 0 (patent grant).
• Copyleft: GPL/LGPL/AGPL - "infecting" compatibility; carefully in closed modules.
• Dual/Multi-licensing: free OSS branch + commercial license with extended rights/support.
• SaaS licensing: access as a service; code is not transmitted, rights - for use.

Selection rules: critical services (game engine, anti-fraud, calculations) - avoid copyleft; UI libraries - permissive; internal tools - GPL is possible during isolation.

3) Rights and restrictions: what to see in licenses

Scope: territories, dates, users/installations, environments (prod/stage/dev).
Modifications and derivatives: is it possible to fork, change, distribute.
Sublicense/transfer: is it allowed for affiliates/white-label.
Patent grant and defensive termination (Apache-2. 0, MPL): patent risks and cross-licenses.
Audit and reporting: the vendor's right to conduct licensing audits.
Security/export: cryptography restrictions, countries/sanctions.
Indemnity and liability: who covers IP claims/damages.

4) Open Source: Politics and Control

White list: MIT/BSD/Apache-2. 0, MPL-2. 0.
Yellow: LGPL-3. 0 (if dynamic link and conditions are met).
Red: AGPL/GPL-3. 0 in closed services if there is no isolation (service boundaries, network copyleft).
Software Bill of Materials (SBOM) -Required list of dependencies with versions/licenses.
OSS procedure: request → legal/tech-assessment of compatibility → registration in the registry → periodic audit.
Contribution to OSS (upstream): CLA/DCO, IP disclosure review, concurrence with Legal.

5) SDK and provider licenses (games, payments, KYC)

Typical requirements: prohibition of reverse engineering, prohibition of caching outside the conditions, control of logos/branding, minimum versions, audit-right.
Data: borders "operator data" vs "provider data" who owns metrics and Derived Data.
Export/sanctions restrictions: geo-blocks, lists of PEP/sanctions - mandatory verification in ToS/licenses.
Support/updates: SLA for patches, breaking-changes, migration deadlines.

6) API: legal terms of access (for partners/affiliates/B2B)

• Access and authentication: OAuth2/HMAC/mutual-TLS; prohibiting the transfer of keys to third parties.
• Rate limits and quotas: RPS/minutes/per day; "fair use"; burst policy.
• SLA and support: availability (e.g. 99. 9%), maintenance windows, incident/communications plan.
• Versioning/depletion: SemVer, EOL dates (for example, ≥ 9-12 months), sending notifications.

• Service-Generated Data (logs, metrics) - the owner of the API;
• Customer/Player Data - at the client/operator;
• Derived Data - by contract (allowed/limited, anonymization).
• Cache and storage: what and how can be cached (TTL, prohibition of storing personal/sensitive fields).
• Privacy/AML/KYC: roles (controller/processor), DPA/DSA, cross-border transmissions, DPIA for high-risk scenarios.
• Security: transit/at-rest encryption, secret management, SOC2/ISO requirements 27001 (if applicable).
• Prohibitions: reverse engineering, scraping, measurement/benchmarking without consent, modification of API responses.
• Audit and logs: right to check, requirements for request logs.
• Sanctions and export: prohibition of use in countries/with users from lists, screening.
• Exclusion of warranties and limit of liability: cap (for example, 12 × average weight. payment).
• Termination of access: immediate in case of security threat/law; output plan.

7) Versioning and compatibility policy

SemVer: MAJOR (breaking), MINOR (features), PATCH (fix).
Schema contracts: JSON Schema/OpenAPI; contract tests for clients.
Deviation procedure: announcement → compatibility period (≥ 6 months) → EOL → removal; migration guide.
Feature flags: for "soft" rolling.

8) Export control, sanctions, cryptography

Cryptography export: checking local rules; notifications/ECC code/bit lengths.
Sanctions: prohibition to serve/give access to residents of sub-sanction jurisdictions/persons; periodic rescreening.
Resiliency of legislation: clauses on suspension of service at regulatory risk.

9) Risk Matrix (RAG)

10) Pre-release/integration checklist

• SBOM assembled; licenses checked (no incompatible).
• Vendor/SDK licenses are signed; data and brand rights.
• DPA/DSA issued; supervisor/processor roles are defined.
• Terms/EULA APIs updated; rate limits/SLA/depletion are prescribed.
• Sanction/export screening in processes.
• Security: keys, rotation, encryption, logging.
• Incident Plan and Access Recall (killswitch) ready.

11) Registries and artifacts (recommended formats)

11. 1 SBOM/License Register

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/Vendors

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) Templates (fragments)

12. 1 EULA (internal fragment)

12. 2 API Terms (internal fragment)

12. 3 Sample Code/Dock Licensing

13) Privacy and Data (API/SDK)

Minimization: do not give extra fields (PII), use "translucent" identifiers.
Cache TTL: strictly fixed; Prohibit local copying of full dumps.
Rights of data subjects: routing requests (access/erasure) through the operator; logging.
Pseudonymization/anonymization: for analytics/Derived Data - before publication.

14) Playbooks

P-LIC-01: Copyleft detected in production service

SBOM audit → migration/isolation option → JUR → release plan → retrospective.

P-API-02: API Key Leak

Key revocation → client notification → forensics → secret rotation → policy update.

P-SDK-03: Vendor breaks compatibility

Transition adapter → temporary API branch → negotiations to extend the window → distribution to customers.

P-XPORT-04: Sanction flag

Autoblock access → match confirmation → legal assessment → documents for the regulator.

15) KPI/Metrics

SBOM Coverage% and percentage of approved components.
The closing time of the license incident (copyleft/incompatibility).
Rejection Compliance% (clients on the current version).
Time-to-Revoke leaked key and MTTR for API incidents.
Proportion of customers with a signed DPA/DSA and sledge screening passed.

16) Mini-FAQ

Can I embed LGPL? Yes, with a dynamic link and compliance with the conditions, we fix it in SBOM.
Who owns API analytics? By default - the owner of the API (Service-Generated), the client - a limited license.
Can I train ML on API data? Only on anonymized/aggregated and if allowed by ToS/DPA.
How much to hold EOL? Recommended 9-12 months with migration guide.

17) Conclusion

Software and API licensing is not a "one-time signed," but a constant cycle: the choice of compatible licenses, SBOM maintenance, clear API Terms (data/quotas/SLA/depletion), DPA/sanctions, and operational playbooks. Standardize rosters and templates - and you'll reduce legal risks, simplify integrations and protect players "own IP and data.