Licence logicielle et API

1) Pourquoi est-ce important pour iGaming

La plate-forme s'appuie sur son propre code, des bibliothèques tierces, des SDK des fournisseurs de jeux/paiements et des API publiques/privées. Les erreurs dans les licences entraînent des réclamations, des blocs d'intégration, des fuites de propriété intellectuelle et des risques réglementaires (privacy/sanctions/cryptographie d'exportation). L'objectif est de construire un contour transparent des droits : ce qui peut être publié, intégré, transmis à des partenaires et comment protéger vos propres API.

2) Modèles de licences logicielles (aperçu)

Propriété (licence fermée) : droits exclusifs du vendeur ; pour B2B (opérateurs, studios, PSP).

• Permissive: MIT, BSD, Apache-2. 0 (délivrance de brevets).
• Copyleft : GPL/LGPL/AGPL - compatibilité « infectante » ; attention dans les modules fermés.
• Dual/Multi-licensing : Une branche OSS gratuite + une licence commerciale avec des droits/support étendus.
• Licence SaaS : accès en tant que service ; le code n'est pas transmis, les droits d'utilisation.

Règles de sélection : services critiques (moteur de jeu, antifrod, calculs) - éviter le copyleft ; Bibliothèques UI - permissive ; tulses internes - GPL possible en cas d'isolement.

3) Droits et restrictions : Ce qu'il faut regarder dans les licences

Étendue des droits (scope) : territoires, durée, utilisateurs/installations, environnements (prod/stage/dev).
Modifications et dérivés : peut-on forcer, changer, distribuer.
Sous-licence/transfert : est-il autorisé pour les affiliés/white-label.
Délivrance de brevets et terminaison défensive (Apache-2. 0, MPL) : risques de brevets et licences croisées.
Vérification et établissement de rapports : droit du vendeur de procéder à des vérifications de permis.
Sécurité/exportation : restrictions sur la cryptographie, pays/sanctions.
Indemnity et responsabilité : qui couvre les réclamations de PI/dommages.

4) Open Source : Politique et contrôle

Liste blanche : MIT/BSD/Apache-2. 0, MPL-2. 0.
Jaune : LGPL-3. 0 (avec link dynamique et conditions).
Rouge : AGPL/GPL-3. 0 dans les services fermés s'il n'y a pas d'isolation (service-frontière, réseau copyleft).
SBOM (Software Bill of Materials) : liste obligatoire des dépendances avec versions/licences.
Procédure de dépôt d'OSS : demande → jure/évaluation de la compatibilité → inscription au registre → audit périodique.
Contribution à l'OSS (upstream) : CLA/DCO, vérification de la divulgation de la PI, harmonisation avec Legal.

5) SDK et licences des fournisseurs (jeux, paiements, KYC)

Exigences typiques : interdiction du développement rétroactif, interdiction du cashing en dehors des conditions, contrôle des logos/marques, versions minimales, droit d'audit.
Données : limites « données d'opérateur » vs « données du fournisseur », qui possède les métriques et les données dérivées.
Restrictions à l'exportation/sanctions : blocs géographiques, listes de RER/sanctions - vérification obligatoire dans les ToS/licences.
Support/mises à jour : SLA sur patchs, breaking-changes, délais de migration.

6) API : conditions légales d'accès (pour les partenaires/affiliés/B2B)

• Accès et authentification : OAuth2/HMAC/Mutual-TLS ; interdiction de transmettre les clés à des tiers.
• Limites de taux et quotas : RPS/minutes/par jour ; « utilisation équitable » ; la politique burst.
• SLA et support : accessibilité (par exemple, 99. 9 %), fenêtres de service, plan d'incident/communication.
• Versioning/Déportation : BouVer, délais EOL (par exemple, ≥ 9-12 mois), envoi de notifications.

• Service-Generated Data (logs, métriques) - chez le propriétaire de l'API ;
• Customer/Player Data - chez le client/opérateur ;
• Données dérivées - par contrat (autorisé/limité, anonymisation).
• Cache et stockage : quoi et comment vous pouvez mettre en cache (TTL, interdiction de stocker des champs personnels/sensibles).
• Vie privée/AML/KYC : rôles (contrôleur/processeur), DPA/DSA, transferts transfrontaliers, DPIA pour les scénarios à risque élevé.
• Sécurité : cryptage en transit/at-rest, gestion des secrets, exigences de SOC2/ISO 27001 (le cas échéant).
• Interdictions : ingénierie inverse, scraping, mesure/benchmarking sans consentement, modification des réponses API.
• Audit et logs : droit de vérification, exigences pour les journaux de demandes.
• Sanctions et exportations : interdiction d'utilisation dans les pays/avec les utilisateurs des listes, screening.
• Exclusion des garanties et limite de responsabilité : cap (par exemple, 12 × de taille moyenne. paiement).
• Arrêt de l'accès : immédiat lorsque la sécurité/la loi est menacée ; plan de sortie des données.

7) Politique de versioning et d'interopérabilité

SemVer: MAJOR (breaking), MINOR (features), PATCH (fix).
Contrats de schémas : JSON Schema/OpenAPI ; tests de contrat pour les clients.
Procédure de suppression : annonce → période de compatibilité (≥ 6 mois) → EOL → suppression ; hyde migratoire.
Feature flags : pour les rouleaux « doux ».

8) Contrôle des exportations, sanctions, cryptographie

Exportation de cryptographie : vérification des règles locales ; notifications/code ESS/longueur de bits.
Sanctions : interdiction de servir/donner accès aux résidents des sous-juridictions/personnes ; recréation périodique.
Tolérance aux pannes de la législation : clauses de suspension du service en cas de risque réglementaire.

9) Matrice des risques (RAG)

10) Chèque avant sortie/intégration

• SBOM assemblé ; licences validées (non incompatibles).
• Licence vendeuse/SDK signée ; droits sur les données et la marque.
• Les DPA/DSA sont formalisées ; les rôles du contrôleur/processeur sont définis.
• API Terms/EULA mises à jour ; les limites de taux/SLA/dépréciation sont prescrites.
• Contrôle des sanctions et des exportations dans les processus.
• Sécurité : clés, rotation, cryptage, journalisation.
• Plan d'incident et révocation d'accès (killswitch) prêt.

11) Registres et artefacts (formats recommandés)

11. 1 SBOM/Registre des licences

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 Registre des clients API

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 SDK registry/vendeurs

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) Modèles (fragments)

12. 1 EULA (fragment interne)

12. 2 API Terms (fragment interne)

12. 3 Licences de code/docks exemplaires

13) Vie privée et données (API/SDK)

Minimisation : ne donnez pas de champs supplémentaires (PII), utilisez des identifiants « translucides ».
Cache TTL : strictement fixe ; interdiction de copier localement les vides complets.
Droits des personnes concernées : acheminement des requêtes (accès/erasure) via l'opérateur ; le protocole.
Pseudonymisation/anonymisation : pour l'analyse/Données dérivées - avant publication.

14) Pleybooks

P-LIC-01 : Découverte de copyleft dans le service pro

Audit SBOM → option migration/isolement → jure-evaluation → plan de sortie → rétrospective.

P-API-02 : Fuite de clé API

La révocation de la clé → la notification du client → du forenseur → la rotation des secrets → l'update de la stratégie.

P-SDK-03 : Le vendeur brise la compatibilité

L'adaptateur transitoire → la branche temporaire de l'API → les négociations pour prolonger la fenêtre → envoyer aux clients.

P-XPORT-04 : Drapeau des sanctions

L'accès automatique → la confirmation des matchs → l'évaluation juridique → les documents pour le régulateur.

15) KPI/métriques

SBOM Coverage % et part des composants approuvés.
Heure de fermeture de l'incident de licence (copyleft/incompatibilité).
Deprecation Compliance % (clients à jour).
Time-to-Revoke de la clé volée et MTTR sur les incidents API.
Proportion de clients ayant signé un DPA/DSA et ayant subi un examen préalable.

16) Mini-FAQ

Puis-je intégrer une LGPL ? Oui, avec un lien dynamique et le respect des conditions, nous fixons dans le SBOM.
Qui possède l'analyse API ? Par défaut, le propriétaire de l'API (Service-Generated), le client est une licence limitée.
Puis-je entraîner ML sur des données API ? Seulement sur anonymisé/agrégé et si autorisé par ToS/DPA.
Combien tenir EOL ? Il est recommandé de 9 à 12 mois avec une hayde migratoire.

17) Conclusion

Les licences logicielles et API ne sont pas « signées une fois pour toutes », mais un cycle constant : sélection de licences compatibles, gestion de SBOM, API Terms claires (données/quotas/SLA/dépréciation), DPA/sanctions, et playbooks opérationnels. Normalisez les registres et les modèles - et vous réduirez les risques juridiques, simplifiez les intégrations et protégez vos propres données IP et joueurs.