Open Source Lizenzen und Einschränkungen

1) Warum OSS in iGaming und wo die Risiken sind

OSS beschleunigt die Entwicklung der Plattform (Gaming Front/Back, Payment Integrationen, Fraud, Analytics), aber Fehler in der Lizenzierung führen zur Offenlegung von geschlossenem Code, Veröffentlichungsblockaden und Streitigkeiten mit Anbietern. Wir brauchen: eine klare Richtlinie, ein Abhängigkeitsregister (SBOM), Audit-Prozesse und die richtige Auswahl der Lizenzen.

2) Lizenzkarte: Typen und Bedeutung

2. 1 Permissive (permissive)

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

Die Hauptpflicht besteht darin, die Benachrichtigung/das Urheberrecht im Apache-2 aufzubewahren. 0 auch Patentzuschuss + „defensive Termination“.
Geeignet für: UI-Frameworks, Utilities, SDK-Clients, Logging/NTTR-Bibliotheken.

2. 2 Weak copyleft (schwaches Copyleft)

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

Sie müssen Änderungen innerhalb der Bibliothek/des Moduls selbst öffnen, aber nicht das gesamte Projekt.
Dynamisches Linking mit LGPL ist in der Regel zulässig, wenn die Bedingungen erfüllt sind (Möglichkeit, die Version durch den Benutzer zu ersetzen, Benachrichtigungen).

2. 3 Starkes Copyleft (starkes Copyleft)

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

Wenn Sie sich mit Ihrem Code „verbinden“, besteht die Pflicht, das abgeleitete Werk unter derselben Lizenz offenzulegen (die Bedingungen „tivoization“, „SaaS-closing“ schließen die AGPL).
Risiko für geschlossene Spielkernmodule, Betrugsbekämpfung, Zahlungsgateways.

3) Link und „abgeleitetes Produkt“ (vereinfacht)

Statische Verknüpfung mit der GPL → ein hohes Risiko einer „Infektion“.
Dynamisches Linking mit LGPL → ist in der Regel unter Bedingungen (Austauschbarkeit, Benachrichtigungen) zulässig.
IPC/REST/gRPC, einzelne Prozesse → reduzieren das Risiko der Produktion, aber heben die Analyse nicht auf (AGPL interpretiert „über das Netzwerk“ als „Verbindung“).
Plugins/Skripte werden → nach der tatsächlichen Integration (API-Stabilität, Upload in den Adressraum) bewertet.

4) Patente und Vorbehalte

Apache-2. 0 gibt Lizenzierung von Patenten des Autors → reduziert das Risiko von Patentansprüchen.
GPL-3. 0/AGPL-3. 0 haben Anti-Patent-/Anti-Circumvention-Bestimmungen.
Wenn Ihr Modul patentrelevant ist (RNG-Mathematik, Betrugsbekämpfungsalgorithmen), vermeiden Sie Lizenzen ohne Patentzuschuss oder fügen Sie einzelne Patentverträge zu kommerziellen Vereinbarungen hinzu.

5) OSS-Verantwortlichkeiten: Was genau zu tun ist

Benachrichtigungen speichern/NOTICE (permisisve).
Offenlegung von Modifikationen von Copyleft-Komponenten (MPL/LGPL/GPL) und Verfahren zur Neumontage.
Bereitstellung von Quellen bei der Verteilung von GPL/LGPL-Binärdateien (und Netzwerkzugriff unter AGPL).
Geben Sie die Lizenz im Fenster "Info "/Seite" OSS Credits' an.
Verfolgen Sie Third-Party-Lizenzen in Lieferungen (Spieleanbieter/SDKs/mobile Bilds).

6) OSS-Richtlinie für die Plattform (empfohlenes Minimum)

1. Lizenzklassifizierung: grün (MIT/BSD/Apache/MPL), gelb (LGPL unter Bedingungen), rot (GPL/AGPL/SSPL für geschlossene Teile).
2. Zulassungsprozess der Komponente: Antrag → rechtliche und technische Bewertung → Eintrag in SBOM → periodisches Audit.
3. Copyleft-Isolation: separater Prozess/Microservice, gRPC/HTTP-Grenze, keine statische Verknüpfung.
4. SBOM nach Build: für jede prod/stage-Version.
5. Benachrichtigungen und Quellen: Automatische Generierung von NOTICE/THIRD-PARTY und Veröffentlichung der Quellen, wo nötig.
6. Beiträge (Upstream): CLA/DCO, Überprüfung auf fehlende Geheimnisse/Patente, Abstimmung mit Legal.
7. Sicherheit: Scan von Schwachstellen, Patchrichtlinie, Verbot von „Pin“ anfälligen Versionen ohne Waiver.

7) OSS in typischen iGaming-Zonen (Best Practice)

Spielmathematik/RNG: GPL/AGPL vermeiden; Bevorzugen Sie Ihren eigenen Code oder permissive-Bibliotheken.
UI/Client: React/Vue/Bandler - permissive → ok, achten Sie auf Lizenzen und Schriftarten.
Zahlungen/CUS: SDK von Anbietern mit strengen ToS; Nicht mit Copyleft mischen.
Observability/DevOps: Prometheus/Grafana/Elastic - Berücksichtigung ihrer Lizenzen (Teil der Nicht-OSS-Module); „Server-Seite“ Bedingungen zu lesen.
Anti-Fraud/Scoring: Modell/Regeln - proprietär; Drittanbieter-Libs - permissive/MIT/Apache.

8) Kompatibilitätstabelle (in Kürze)

9) Risikomatrix (RAG)

10) Checklisten

Vor dem Hinzufügen einer Bibliothek

• Bibliothekslizenz in der „Grün/Gelb“ -Liste.
• Linking Kompatibilität geprüft (statisch/dynamisch/IPC).
• Eintrag in SBOM + Version + Quelle.
• Generierte Benachrichtigungen (LICENSE/NOTICE).

Vor der Veröffentlichung

• SBOM pro Baugruppe gespeichert (prod/stage).
• Scan der Schwachstellen bestanden; kritisch - geschlossen oder waiver.
• Die benötigten Quellen/Patches sind bereit zur Auslieferung (falls erforderlich).
• "OSS Credits'/Über Seite aktualisiert.

Für Beiträge (Beiträge)

• CLA/DCO unterzeichnet.
• Überprüfung auf fehlende Geheimnisse/Patente.
• Urheberrechte/Urheberrechte sind korrekt hinterlegt.

11) OSS-Richtlinie (Fragmente)

11. 1 Klassifizierung

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 Zulassungsprozess

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

11. 3 Isolierung von Copyleft

Separater Service, Netzwerkschnittstelle, keine binäre Kombination, keine statische Verknüpfung.
Dokumentation zur Montage und Aktualisierung von Bibliotheken (LGPL/MPL).

12) Register (YAML-Vorlagen)

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-Quellen zur Offenlegung

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 Einlagenregister (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) Sicherheit und Compliance

SCA/SAST in CI, Autoscan neuer Abhängigkeiten.
Patch-Richtlinie: P1 Verwundbarkeit - ≤72 h, P2 - ≤14 Tage.
Artefakt-Cache: Speichern Sie die ursprüngliche LICENSE/NOTICE; Überprüfen Sie die Integrität (Hashes).
Export/Sanktionen: Verwenden Sie keine Komponenten/Spiegel aus verbotenen Ländern; protokollieren Sie die Prüfungen.

14) Playbooks (Betriebsszenarien)

P-OSS-01: GPL in geschlossenem Modul entdeckt

Linkinventar → Isolations-/Ersatzvariante → Rechtsgutachten → Release-Fix → Retro durch den Prozess.

P-OSS-02: Anforderung von Quellen

Bestimmen Sie den Umfang der Verpflichtungen → erstellen Sie Archive und NOTICE → übertragen Sie innerhalb der gesetzlichen Frist → aktualisieren Sie die Dokumentation.

P-OSS-03: Kritische Verwundbarkeit in Abhängigkeit

Backport/Update → außerordentliche Veröffentlichung → Benachrichtigung von interessierten Post-Sea- → und Pinning-Regeln.

15) Mini-FAQ

Kann LGPL verwendet werden? Ja, mit dynamischem Link/IPC und Einhaltung der Bedingungen (Austauschbarkeit, Benachrichtigungen).
AGPL auf einem Server ohne Binärverteilung - sicher? Nein: Die AGPL verlangt, dass die Quellen den Benutzern zur Verfügung gestellt werden, die über das Netzwerk mit dem Dienst interagieren.
Brauche ich einen Patentzuschuss? Wünschenswert für Module mit algorithmischen Neuerungen; Apache-2. 0 ist vorzuziehen.
Reicht es, OSS auf der Website anzugeben? Nein, erfüllen Sie alle Anforderungen: Benachrichtigungen, Quellen, Anweisungen.

16) Schlussfolgerung

Die Arbeit mit OSS ist ein Prozess, keine einmalige Überprüfung: Toleranzstandards, Copyleft-Isolation, automatisierte Benachrichtigungen und ein vollständiges SBOM für jede Baugruppe. Wenn Sie diesem Artikel folgen, behalten Sie die Entwicklungsgeschwindigkeit bei und vermeiden rechtliche Fallen - vom „Netzwerk-Copyleft“ bis hin zu Patentansprüchen.