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
| Fichier | Rôle |
|---|---|
LICENSE | licence propriétaire AuroraMind baseline, à faire valider par avocat |
EVALUATION_LICENSE.md | conditions POC / évaluation, à compléter par client |
COMMERCIAL_TERMS_TEMPLATE.md | modèle d'annexe contractuelle commerciale |
THIRD_PARTY_NOTICES.md | notices et points de vigilance des composants tiers |
docs/legal/LICENSING_TRANSITION.md | note 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.txtaurora_gateway/requirements.txtingestion/requirements.txttests/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.csvlicenses/reports/python_ingestion.csvlicenses/reports/python_tests.csvlicenses/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 ingestion5. 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-alpineflottant, à 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.mdet les conditions client signées. - Documenter le statut MinIO / Redis.
- Faire valider le dossier par le juridique avant livraison.