ADR-015 — Licence MPL 2.0, contribution DCO, gouvernance évolutive, marque modèle Linux

Statut : Accepté — document fondateur. Édition directe autorisée en phase de design pré-ouverture publique ; immuable après ouverture publique (toute évolution via RFC, ADR-015). Catégorie : Gouvernance (licence, contribution, structure juridique).

Contexte

Un projet d’infrastructure destiné à durer doit fixer très tôt ce qui ne se renégocie pas : sous quelle licence il vit, comment une contribution y entre, et qui tranche.

Différer ces choix les rend plus coûteux à mesure que les contributeurs arrivent — un changement de licence rétroactif exige leur accord à tous.

Décision

Licence : Mozilla Public License 2.0 (MPL 2.0) pour l’intégralité du code source d’Air et de sa documentation. Copyleft par fichier protégeant le cœur d’Air contre les forks propriétaires non-libérés, sans contaminer les apps .airapp qui peuvent rester propriétaires. Compatible avec Apache 2.0 et GPL.

Contribution : Developer Certificate of Origin (DCO). Tout commit doit contenir un Signed-off-by valide. Vérification automatique en CI. Pas de CLA. Conséquence : impossibilité de changement de licence rétroactif sans consentement des contributeurs.

Gouvernance technique évolutive :

1. BDFL (phase 0 et début phase 1) : le fondateur décide, valide RFCs, merge PRs.
2. Comité Technique (déclenché à ~5 contributeurs réguliers) : fondateur + contributeurs cooptés puis élus. Décisions par lazy consensus, vote si désaccord, veto BDFL transitoire.
3. Fondation (vers Air 1.0) : séparation CA/TC, formalisation juridique. Modèle Blender Foundation.

Mécanisme RFC pour évolutions significatives : une RFC est un ADR au statut « Proposé », dans ce dépôt.

• Où : docs/adrs/, sous la forme d’une paire ADR-NNN-slug-fr.md / ADR-NNN-slug-en.md, déposée par une pull request, avec son entrée dans docs/adrs/statuts.toml et le registre régénéré.
• Forme : l’en-tête porte **Statut :** Proposé (RFC — ADR-015). Le corps suit la structure commune des ADR du dépôt — pourquoi, décisions numérotées, ce qui n’est pas décidé, conséquences, alternatives rejetées. Il n’existe pas de fichier gabarit.
• Discussion : la pull request. En phase BDFL, aucune durée minimale de commentaire n’est imposée.
• Décision : le BDFL, puis le Comité Technique. L’acceptation fait passer l’en-tête à **Statut :** Accepté.
• Archivage : l’historique git et le registre généré. Ils deviendront publics avec le dépôt.

Rectifié le 2026-09-24 (décision BDFL). Ce paragraphe décrivait jusque-là un « Repository dédié air-rfcs, template structuré, période de commentaires 2-4 semaines, décision BDFL/TC, archivage public. Modèle Rust RFCs ». Rien de cela n’a existé : ni le dépôt, ni le gabarit, ni la période de commentaires. Pendant ce temps, trente-six ADR renvoyaient à ce mécanisme, dont seize au statut « Proposé ». Le constat a été fait en application de la règle NO GO de CLAUDE.md (« un référentiel affirmé qui n’existe pas »). Le texte décrit désormais ce qui se pratique. Un dépôt dédié, avec un gabarit et une période de commentaires, pourra revenir avec l’ouverture publique ou la création du Comité Technique ; il fera alors l’objet d’un ADR, et ce paragraphe ne l’annoncera qu’une fois ce dépôt créé.

Code de conduite : Contributor Covenant 2.1.

Marque « Air » modèle Linux : usage libre pour la communauté, distributions, éditeurs d’apps, sans autorisation préalable formelle. Action juridique uniquement contre abus manifestes.

Structure juridique évolutive :

• Phase A (0-12 mois) : individuel, propriété personnelle du fondateur.
• Phase B (12-36 mois) : association loi 1901.
• Phase C (vers Air 1.0) : Fondation à but non lucratif.

Conséquences

Voir la section « Décision » : cet ADR énonce une politique dont les conséquences sont directement celles des règles qu’elle pose.

Alternatives rejetées

Aucune alternative n’a été consignée lors de l’instruction.

Licence du document : MPL 2.0