Open Source Licenses and Restrictions

1) Why OSS in iGaming and where are the risks

OSS accelerates platform development (game front/back, payment integrations, anti-fraud, analytics), but licensing errors lead to closed code disclosure, release blocking and disputes with providers. We need: a clear policy, a registry of dependencies (SBOM), audit processes and the correct selection of licenses.

2) License map: types and meaning

2. 1 Permissive

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

The primary responsibility is to keep the notice/copyright Apache-2. 0 also patent grant + "defensive termination."

Suitable for: UI frameworks, utilities, SDK clients, logging/HTTP libraries.

2. 2 Weak copyleft

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

Require opening changes within the library/module itself, but not the entire project.
Dynamic linking with LGPL is usually allowed if the conditions are met (user replaceability, notifications).

2. 3 Strong copyleft

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

When "connecting" with your code, the obligation arises to disclose the derivative work under the same license (the conditions "tivoization," "SaaS closure" close AGPL).
Risk for closed modules of the game core, anti-fraud, payment gateways.

3) Linking and "derivative product" (simplified)

Static linking with GPL → a high risk of "infection."

Dynamic linking with LGPL → is usually allowed subject to conditions (replaceability, notifications).
IPC/REST/gRPC, individual processes → reduce the risk of performance, but do not cancel the analysis (AGPL treats "over the network" as "connection").
Plugins/scripts are → evaluated by actual integration (API stability, loading into the address space).

4) Patents and disclaimers

Apache-2. 0 gives licensing of the author's patents → reduces the risk of patent claims.
GPL-3. 0/AGPL-3. 0 have anti-patent/anti-circumvention positions.
If your module is patent-significant (RNG mathematics, anti-fraud algorithms), avoid licenses without a patent grant or add separate patent covenants to commercial agreements.

5) OSS responsibilities: what exactly to do

Save notifications/NOTICE (permisisve).
Reveal the modifications of the copyleft components (MPL/LGPL/GPL) and the reassembly method.
Provide sources when distributing binaries for GPL/LGPL (and network access for AGPL).
Specify the license in the About box/OSS Credits page.
Track third-party licenses in shipments (game vendors/SDKs/mobile builds).

6) Platform OSS policy (recommended minimum)

1. Classification of licenses: green (MIT/BSD/Apache/MPL), yellow (LGPL under conditions), red (GPL/AGPL/SSPL for closed parts).
2. Component admission process: request → legal and technical evaluation → record in SBOM → periodic audit.
3. Copyleft isolation: separate process/microservice, gRPC/HTTP border, no static linking.
4. Build SBOM: for each prod/stage release.
5. Notifications and sources: automatic generation of NOTICE/THIRD-PARTY and publication of sources where necessary.
6. Contributions (upstream): CLA/DCO, lack of secrets/patents, coordination with Legal.
7. Security: scanning vulnerabilities, patch policy, banning "pin" vulnerable versions without waiver.

7) OSS in typical iGaming zones (best practice)

Game Math/RNG: Avoid GPL/AGPL; prefer your own code or permissive libraries.
UI/client: React/Vue/bundlers - permissive → ok, monitor licenses and fonts.
Payments/CCM: SDK of vendors with strict ToS; do not mix with copyleft.
Observability/DevOps: Prometheus/Grafana/Elastic - take into account their licenses (part of non-OSS modules); read "server side" conditions.
Antifraud/scoring: model/rules - proprietary; third-party libs - permissive/MIT/Apache.

8) Compatibility Matrix (in brief)

9) Risk Matrix (RAG)

10) Checklists

Before adding a library

• Library license in the green/yellow list.
• Link compatibility (static/dynamic/IPC) verified.
• SBOM + version + source.
• Generated notifications (LICENSE/NOTICE).

Before Release

• SBOM per assembly saved (prod/stage).
• Vulnerability scan passed; critical - closed or waiver.
• The required source/patches are ready to be issued (if needed).
• "OSS Credits "/About page updated.

For contributions

• CLA/DCO signed.
• Review for lack of secrets/patents.
• Copyright/copyright is correct.

11) OSS Policy (snippets)

11. 1 Classification

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 Admission process

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

11. 3 Isolation of copyleft

Separate service, network interface, no combination of binaries, no static linking.
Library Build and Upgrade Documentation (LGPL/MPL).

12) Registers (YAML templates)

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 sources for disclosure

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 Deposit register (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) Safety and compliance

SCA/SAST in CI, autoscan of new dependencies.
Patch policy: P1 vulnerabilities - ≤72 hours, P2 - ≤14 days.
Artifact Cache: Keep the original LICENSE/NOTICE; check integrity (hashes).
Export/sanction: Do not use components/mirrors from banned countries; log checks.

14) Playbooks (operational scenarios)

P-OSS-01: GPL detected in closed module

Link inventory → isolation/replacement option → legal opinion → release fix → retro on process.

P-OSS-02: Source requirement

Determine the scope of obligations → prepare archives and NOTICE → transfer on time → update documentation.

P-OSS-03: Critical vulnerability in dependence

Backport/update → extraordinary release → notification of interested → post-sea and pinning rules.

15) Mini-FAQ

Can I use LGPL? Yes, with dynamic linking/IPC and compliance with conditions (replaceability, notifications).
AGPL on the server without distributing the binary - is it safe? No: AGPL requires providing source code to users interacting with the service over the network.
Do I need a patent grant? Desirable for modules with algorithmic innovations; Apache-2. 0 is preferable.
Is it enough to specify OSS on the site? No, follow all the requirements: notifications, sources, instructions.

16) Conclusion

Working with OSS is a process, not a one-time check: admission standards, copyleft isolation, automated notifications, and a full SBOM per assembly. By following this article, you will maintain the speed of development and avoid legal traps - from "network copyleft" to patent claims.