Pourquoi choisir l’AGPL ? Le cas RoadSimulator3

Le choix d’une licence open source n’est jamais neutre. Il conditionne la diffusion, l’adoption et la protection d’un projet logiciel. Pour RoadSimulator3 — simulateur inertiel multi-contexte conçu pour générer des trajectoires réalistes à 10 Hz avec inertie, gyroscope, topographie et météo — ce choix est particulièrement stratégique. Après analyse des différentes options (MIT, Apache, GPL, CeCILL…), nous avons retenu l’Affero General Public License (AGPL).

Dans cet article, nous expliquons en détail pourquoi l’AGPL est le meilleur compromis entre ouverture scientifique, protection contre la captation industrielle, et alignement avec notre modèle économique.

—

1. Contexte : pourquoi la licence compte pour RoadSimulator3 ?

RoadSimulator3 n’est pas un simple script académique, mais une plateforme complète de simulation véhicule :

• Trajectoires GPS réalistes via OSRM et OSM
• Injection d’événements inertiels : freinages, accélérations, dos d’âne, nids de poule
• Modélisation du gyroscope (gyro_x, gyro_y, gyro_z) et bruit stochastique
• Prise en compte du relief (IGN RGE Alti®) et des conditions météo
• Production de données à haute fréquence (10 Hz) pour IA, télématique et recherche

La valeur de RoadSimulator3 repose donc autant sur le code source que sur l’approche scientifique et la création de jeux de données synthétiques. Sans licence claire, le risque est double :

• Des acteurs commerciaux peuvent réutiliser le moteur dans leurs propres offres SaaS sans jamais contribuer en retour.
• Les chercheurs n’ont aucune garantie que le code restera accessible ni que leurs améliorations seront reversées à la communauté.

—

2. Comprendre la licence AGPL

L’Affero GPL (AGPL v3) est une variante de la GPL conçue pour répondre au problème des logiciels utilisés via un réseau (par exemple dans le cloud ou en SaaS).

2.1. Principe de base

Comme la GPL, l’AGPL impose que tout dérivé du code reste open source. Mais elle ajoute une clause spécifique :

« Si vous proposez ce logiciel comme service sur un réseau (SaaS, API), vous devez fournir le code source complet aux utilisateurs de ce service. »

2.2. Conséquence

Impossible donc de créer un SaaS fermé basé sur RoadSimulator3 sans reverser les améliorations à la communauté.

—

3. Pourquoi l’AGPL protège RoadSimulator3

3.1. Contre la captation industrielle

Les acteurs de la mobilité connectée (constructeurs, assureurs, éditeurs télématiques) pourraient être tentés de forker RoadSimulator3 et de l’intégrer dans leur cloud. Avec une licence permissive (MIT, Apache), ils ne seraient pas obligés de partager leurs modifications. Avec l’AGPL, toute mise en production doit rester ouverte.

3.2. Cohérence avec la recherche

La science progresse par le partage. L’AGPL garantit que RoadSimulator3 restera disponible pour les chercheurs, et que toute amélioration significative sera partagée en retour. Cela aligne le projet avec les principes d’open science et de reproductibilité.

3.3. Protection de l’écosystème

RoadSimulator3 intègre des dépendances open source (OSM, OSRM, OpenWeatherMap). L’AGPL permet d’assurer que notre code reste dans le même esprit collaboratif et évite un « enclosure » du bien commun.

—

4. Comparaison avec les autres licences

—

5. Implications pour notre modèle économique

Notre Business Model Canvas prévoit plusieurs sources de revenus :

• Accès API payant (SaaS)
• Consulting et formation
• Jeux de données enrichis et premium

L’AGPL ne bloque pas ces activités, car :

• Nous pouvons proposer un SaaS officiel de RoadSimulator3 (les utilisateurs obtiennent le code, mais préfèrent payer pour l’hébergement, la maintenance et le support).
• Nous pouvons publier le noyau sous AGPL, tout en réservant certaines extensions ou datasets sous licence commerciale.
• Nous pouvons proposer une double licence : AGPL pour l’open science, et une licence propriétaire sur demande pour des industriels qui refusent l’AGPL.

—

6. Exemple concret : scénario de simulation et diffusion

Lors d’un run récent, RoadSimulator3 a généré un trajet avec injection d’événements :

• 5 freinages
• 5 accélérations
• 5 dos d’âne
• 5 nids de poule
• 5 franchissements de trottoirs
• 1672 arrêts temporaires (« wait »)

Ces données sont précieuses pour entraîner des IA de détection d’événements ou tester des algorithmes embarqués. Grâce à l’AGPL :

• Tout acteur qui réutilise ces scripts pour son propre simulateur doit publier son code dérivé.
• Les chercheurs peuvent améliorer les modèles (bruit inertiel, gyro, typologie routière) et redistribuer librement leurs versions.

—

7. Répondre aux critiques fréquentes sur l’AGPL

7.1. « L’AGPL fait peur aux industriels »

C’est vrai que certaines DSI rechignent à intégrer du code AGPL. Mais cela peut être transformé en opportunité : proposer un contrat de licence commerciale pour ces acteurs. C’est le principe de la dual licensing strategy adopté par MongoDB ou Elastic.

7.2. « L’AGPL est trop contraignante »

La contrainte est justement sa force : elle garantit que les améliorations restent dans l’écosystème. Pour un projet scientifique comme RoadSimulator3, c’est un avantage, pas un frein.

7.3. « L’AGPL est peu utilisée »

C’est vrai qu’elle est moins répandue que MIT ou Apache. Mais elle est adoptée par des projets majeurs comme GNU Affero, Moodle ou OpenERP/Odoo. Son adoption croît dans le contexte SaaS.

—

8. Conclusion : un choix aligné avec notre vision

En adoptant l’AGPL v3, RoadSimulator3 choisit :

• La protection contre la privatisation de son code par des acteurs SaaS
• La cohérence scientifique avec les principes d’open science
• La possibilité d’un modèle économique hybride : open pour la recherche, commercial pour l’industrie

Ce choix n’est pas seulement juridique : il incarne une philosophie. La simulation inertielle doit rester un bien commun, au service de la recherche, de l’innovation et de la mobilité durable.

—