Licences et restrictions Open Source
1) Pourquoi OSS dans iGaming et où les risques
L'OSS accélère le développement de la plate-forme (avant/arrière-plan de jeu, intégration de paiement, antifrod, analyse), mais les erreurs de licence conduisent à la divulgation du code fermé, le blocage des versions et les litiges avec les fournisseurs. Vous avez besoin d'une politique claire, d'un registre des dépendances (SBOM), de processus d'audit et d'un bon choix de licence.
2) Carte des licences : types et sens
2. 1 Permissive (permissive)
MIT, BSD-2/3-Clause, Apache-2. 0
L'obligation principale est de conserver la notification/copirate, en Apache-2. 0 ainsi qu'une bourse de brevet + « terminaison défensive ».
Convient pour : Cadres UI, utilitaires, clients SDK, librairies logiques/NTR.
2. 2 Weak copyleft (copyleft faible)
MPL-2. 0, LGPL-2. 1/3. 0
Vous devez ouvrir les modifications à l'intérieur même de la bibliothèque/module, mais pas tout le projet.
Un linkage dynamique avec LGPL est généralement autorisé lorsque les conditions sont remplies (possibilité de remplacer la version par l'utilisateur, notification).
2. 3 Strong copyleft (fort copyleft)
GPL-2. 0/3. 0, AGPL-3. 0
Lorsque vous « connectez » à votre code, vous avez l'obligation de divulguer un produit dérivé sous la même licence (les conditions « tivoization », « SaaS-fermeture » ferme l'AGPL).
Risque pour les modules fermés du noyau de jeu, antifrod, passerelles de paiement.
3) Linkovka et « produit dérivé » (simplifié)
Linkage statique avec GPL → risque élevé de « contamination ».
Un linkage dynamique avec LGPL → est généralement autorisé sous réserve de conditions (remplaçabilité, notifications).
IPC/REST/gRPC, les processus individuels → réduisent le risque de production, mais n'annulent pas l'analyse (AGPL traite « via le réseau » comme « connexion »).
Les plugins/scripts sont → évalués en fonction de l'intégration réelle (stabilité API, chargement dans l'espace d'adresse).
4) Brevets et réserves
Apache-2. 0 accorde une licence aux brevets de l'auteur → réduit le risque de revendications de brevet.
GPL-3. 0/AGPL-3. 0 ont des positions anti-brevet/anti-circulation.
Si votre module est breveté (mathématiques RNG, algorithmes antifrod), évitez les licences sans délivrance de brevet ou ajoutez des covenants de brevet individuels aux accords commerciaux.
5) Responsabilités de l'OSS : exactement ce qu'il faut faire
Enregistrer les notifications/NOTICE (permisisve).
Divulguer les modifications des composants copyleft (MPL/LGPL/GPL) et la méthode de recalage.
Fournir des sources lors de la distribution de binaires sous GPL/LGPL (et l'accès réseau sous AGPL).
Spécifiez la licence dans la fenêtre À propos/la page Crédits OSS.
Surveillez les licences d'approvisionnement (fournisseurs de jeux/SDK/tickets mobiles).
6) Politique OSS pour la plateforme (minimum recommandé)
1. Classification des licences : vertes (MIT/BSD/Apache/MPL), jaunes (LGPL sous conditions), rouges (GPL/AGPL/SSPL pour les parties fermées).
2. Processus d'admission du composant : demande → évaluation juridique et technique → entrée dans le SBOM → audit périodique.
3. Isolation de copileft : processus/microservis séparé, frontière gRPC/HTTP, pas de linge statique.
4. SBOM par assemblage : pour chaque version prod/stage.
5. Notifications et sources : génération automatique de NOTICE/THIRD-PARTY et publication des sources là où vous voulez.
6. Contributions (upstream) : CLA/DCO, vérification de l'absence de secrets/brevets, alignement avec Legal.
7. Sécurité : scan de vulnérabilités, politique de patchs, interdiction des versions vulnérables « pin » sans waiver.
7) OSS dans les zones iGaming typiques (meilleures pratiques)
Jeux mathématiques/RNG : éviter la GPL/AGPL ; préférer son propre code ou bibliothèque permissive.
UI/client : React/Vue/bandlers - permissive → ok, suivre les licences et les polices.
Paiements/CUS : SDK des vendeurs avec des ToS strictes ; ne pas mélanger avec du copyleft.
Observability/DevOps : Prometheus/Grafana/Elastic - prendre en compte leurs licences (une partie des modules non-OSS) ; lire « côté serveur » des conditions.
Antifrod's/scoring : modèle/règles - propriétaires ; les tierces parties sont permissives/MIT/Apache.
8) Tableau de compatibilité (en résumé)
9) Matrice des risques (RAG)
10) Chèques-feuilles
Avant d'ajouter une bibliothèque
- Licence de bibliothèque dans la liste « vert/jaune ».
- La compatibilité du linge (statique/dynamique/IPC) a été testée.
- Entrée dans SBOM + version + source.
- Notifications générées (LICENSE/NOTICE).
Avant la sortie
- SBOM par assemblage enregistré (prod/stage).
- Le scan des vulnérabilités est passé ; critique - fermé ou waiver.
- Les sources/patchs requis sont prêts à être délivrés (si nécessaire).
- « Crédits OSS »/À propos de la page mise à jour.
Pour les contributions
- CLA/DCO signé.
- Examen de l'absence de secrets/brevets.
- Les droits d'auteur/copyright sont correctement apposés.
11) Politique OSS (fragments)
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 modules11. 2 Processus d'admission
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 Isolation du copyleft
Service séparé, interface réseau, pas de combinaison de binaires, pas de linkage statique.
Documentation sur l'assemblage et la mise à jour des bibliothèques (LGPL/MPL).
12) Registres (modèles 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 sources OSS pour la divulgation
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 Registre des dépôts (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) Sécurité et conformité
SCA/SAST dans CI, auto-scan des nouvelles dépendances.
Politique de patch : Vulnérabilité P1 - ≤72 h, P2 - ≤14 jours.
Cache d'artefacts : Stockez la LICENCE/NOTIFICATION originale ; vérifier l'intégrité (hashi).
Exportations/sanctions : n'utilisez pas les composants/miroirs des pays interdits ; Loger les vérifications.
14) Pleybooks (scénarios opérationnels)
P-OSS-01 : Découverte de la GPL dans le module fermé
Inventaire des liens → option d'isolement/remplacement → avis juridique → sortie-fix → rétro sur le processus.
P-OSS-02 : Exigence des sources
Définir le volume des obligations → préparer les archives et NOTICE → transmettre au délai légal → renouveler la documentation.
P-OSS-03 : Vulnérabilité critique selon la dépendance
Backport/mise à jour → sortie extraordinaire → notification des → intéressés par l'après-mer et les règles de pinning.
15) Mini-FAQ
Puis-je utiliser LGPL ? Oui, avec linkage dynamique/IPC et respect des conditions (remplaçabilité, notifications).
AGPL sur un serveur sans distribution binaire - sûr ? Non : L'AGPL exige que les sources soient fournies aux utilisateurs qui interagissent avec le service sur le réseau.
Ai-je besoin d'une bourse de brevet ? Souhaitable pour les modules avec des innovations algorithmiques ; Apache-2. 0 est préférable.
Il suffit d'indiquer l'OSS sur le site ? Non, répondez à toutes les exigences : notifications, sources, instructions.
16) Conclusion
Travailler avec OSS est un processus, pas une vérification unique : normes de tolérance, isolation de copileft, notifications automatisées et SBOM complet pour chaque assemblage. En suivant cet article, vous garderez la vitesse de développement et éviterez les pièges juridiques - de la « copie en ligne » aux revendications de brevet.