ADR-0101 : politique de licences de la distribution

• Statut : accepté par l'équipe plateforme, chaque exception en attente d'approbation par le client
• Date : 2026-10-30
• Exigences : FOUN-011, FOUN-012, FOUN-013, MANA-005, MANA-006, LICE-008
• Version anglaise : en/ADR-0101-licence-policy.md

Contexte

La plateforme est livrée au client sous la forme d'une distribution composée de composants open source, de services plateforme écrits par l'éditeur et de services fournis par le client (BYO). Le kit (section 3) exige que le cœur de chaque composant soit sous MIT ou Apache-2.0, et que toute autre licence soit enregistrée, justifiée et approuvée par le client avant la livraison. La licence d'un composant dépend de sa version exacte : Redis 7.0.15 est sous BSD-3-Clause, Redis 7.4 sous RSALv2 ou SSPLv1, Redis 8.0 sous RSALv2, SSPLv1 ou AGPL-3.0. Une licence est donc toujours enregistrée pour une version épinglée.

Décision

1. Cœur des composants (programme principal d'une capacité : serveur, opérateur, chart, CLI livrée au client) : MIT ou Apache-2.0. Le code interne de l'éditeur est sous la licence de l'éditeur (LicenseRef-Navin-Enterprise) et sort du champ de cette règle.
2. Dépendances (bibliothèques liées à un composant ou embarquées dans une image) : elles peuvent aussi être sous ces licences permissives, sans exception mais listées dans le rapport de licences : BSD-2-Clause, BSD-3-Clause, ISC, PSF-2.0, Zlib, 0BSD, Unlicense, CC0-1.0 (et leurs variantes SPDX usuelles : Python-2.0, BSD-3-Clause-Clear, MIT-0, BlueOak-1.0.0, Unicode-3.0, Unicode-DFS-2016, CC-BY-4.0 pour les fichiers de données, X11, curl, OFL-1.1 pour les polices).
3. Tout le reste exige une entrée dans catalog/licence-exceptions.yaml : licences copyleft et copyleft faible (LGPL, MPL, GPL, AGPL, EPL, EUPL, CDDL), licences source-available (SSPL, BUSL, Elastic, RSAL), cœur permissif autre que MIT ou Apache-2.0 (PostgreSQL, Redis BSD-3-Clause), pièces propriétaires d'exécution (pilotes NVIDIA et CUDA) et poids de modèles. Une entrée donne la justification, la portée (distribué par l'éditeur ou fourni par le client, lié ou processus séparé), les obligations, l'alternative et approval_status.
4. Seul le client approuve. L'équipe plateforme enregistre chaque entrée avec approval_status: pending. Une livraison est bloquée tant qu'un composant distribué est non_compliant ou repose sur une exception en attente que le client n'a pas approuvée (release/lock-manifest.json liste les deux cas).
5. Non conforme signifie : une licence hors politique sans exception, ou une version non épinglée (une étiquette flottante comme redis:7-alpine peut basculer vers une licence source-available). Un tel composant porte un replacement ou une action dans son manifeste.
6. Preuves. Chaque manifeste de catalog/components/ enregistre l'expression SPDX de la version épinglée, l'URL du fichier de licence à cette étiquette (ou l'API de licence GitHub) et la date de vérification. Les SBOM de release/sbom/ (SPDX 2.3 JSON, Syft) listent les licences des dépendances de chaque artefact ; tools/components/licence_report.py en tire docs/implementation/LICENCES.md, et chaque dépendance hors des points 1 et 2 doit correspondre à une exception.

Conséquences

• services/control-plane/tests/test_platform_components.py échoue quand un manifeste déclare une licence hors politique sans exception existante, quand une dépendance d'un SBOM n'est pas couverte, ou quand les documents générés ne sont pas à jour.
• Remplacer un composant (Grafana par les tableaux de bord du Navin Manager et du portail, Loki par OpenSearch, MinIO par SeaweedFS) est la réponse par défaut à un cœur AGPL ; l'exception est la réponse quand aucune alternative permissive n'existe (PostgreSQL, codecs FFmpeg, pilotes NVIDIA).
• La ressource de cluster platform.navin.ai/v1alpha1 ManagedComponent (navin-manager/operator) pilote une instance déployée ; le manifeste de catalogue enterprise-ai.io/v1 ManagedComponent (contracts/v1/managed-component.schema.json) décrit la capacité, ses épinglages et sa licence.