Aurora Nexus
Aurora NexusSécurité

Licences & conformité

licence propriétaire AuroraMind + conformité dépendances tierces (process)

Aurora Nexus est désormais cadré comme logiciel propriétaire AuroraMind dans ce dépôt. Voir LICENSE.

Ce document ne constitue pas un avis juridique. Il décrit le processus opérationnel attendu pour préparer une revue DSI / juridique et une release client maîtrisée.

1. Documents de référence

FichierRôle
LICENSElicence propriétaire AuroraMind baseline, à faire valider par avocat
EVALUATION_LICENSE.mdconditions POC / évaluation, à compléter par client
COMMERCIAL_TERMS_TEMPLATE.mdmodèle d'annexe contractuelle commerciale
THIRD_PARTY_NOTICES.mdnotices et points de vigilance des composants tiers
docs/legal/LICENSING_TRANSITION.mdnote de transition depuis les mentions AGPL historiques

Les composants tiers open source ou source-available ne sont pas relicenciés par AuroraMind. Ils restent soumis à leurs propres licences.

2. Licence du projet

La position cible est :

  • Nexus = logiciel propriétaire AuroraMind ;
  • usage client = limité au contrat signé ou à la licence d'évaluation ;
  • pas de revente, sous-licence, hébergement pour tiers, modification, reverse engineering ou usage concurrentiel sans accord écrit ;
  • composants tiers = conditions séparées dans THIRD_PARTY_NOTICES.md.

Avant tout envoi client, faire valider les textes par un avocat spécialisé logiciel.

3. Conformité dépendances applicatives

3.1 Python

Les dépendances Python sont définies par :

  • api/requirements.txt
  • aurora_gateway/requirements.txt
  • ingestion/requirements.txt
  • tests/requirements.txt

Pour une release, produire un inventaire :

  • nom du package ;
  • version installée ;
  • licence déclarée ;
  • rôle runtime/build/test ;
  • statut de revue.

3.2 UI Node / Next.js

Les dépendances UI sont verrouillées par :

  • ui/package-lock.json

Pour une release, produire un inventaire :

  • nom du package ;
  • version ;
  • licence déclarée ;
  • rôle runtime/build/test ;
  • statut de revue.

4. Scripts de génération

Scripts :

  • ops/licenses/generate_reports.py

Sorties attendues :

  • licenses/reports/python_api.csv
  • licenses/reports/python_ingestion.csv
  • licenses/reports/python_tests.csv
  • licenses/reports/node_ui.csv

Exécution typique :

python3 ops/licenses/generate_reports.py --node-lock ui/package-lock.json
docker compose exec api python3 ops/licenses/generate_reports.py --python-env api
docker compose exec ingestion python3 ops/licenses/generate_reports.py --python-env ingestion

5. Images conteneurs

Les images Docker ont leurs propres licences. Les points actuellement sensibles sont :

  • MinIO : GNU AGPLv3 selon l'amont, à valider ou remplacer par S3/stockage approuvé ;
  • Redis : tag redis:7-alpine flottant, à pinner ; le régime de licence dépend de la version exacte ;
  • bases OS Alpine/Debian : notices des packages à conserver selon le mode de distribution.

6. Bonnes pratiques de release

  • Pinner les images Docker par tag exact ou digest.
  • Éviter les dépendances Python non figées pour une release client.
  • Générer les inventaires de licences.
  • Conserver les lockfiles et rapports avec l'artefact livré.
  • Attacher LICENSE, THIRD_PARTY_NOTICES.md et les conditions client signées.
  • Documenter le statut MinIO / Redis.
  • Faire valider le dossier par le juridique avant livraison.

On this page