Traduction automatique, non relue par un locuteur natif. L'anglais fait foi.

ProjetModifier sur GitHubSource : GOVERNANCE.md

Gouvernance de Kshana

Ce document énonce comment Kshana est gouverné : qui prend les décisions, comment, et ce que le projet absorbera ou n'absorbera pas. Il est délibérément léger — proportionné à la taille actuelle du projet — et honnête sur la réalité présente d'un seul mainteneur et sur la voie vers une gouvernance plus large à mesure que la communauté grandit.

Mission et périmètre#

Kshana est une référence neutre, reproductible et honnêtement validée pour la performance et la résilience du PNT hybride quantique/classique. La mission fixe le niveau d'exigence de chaque décision : exactitude, citations et reproductibilité plutôt qu'étendue. Le périmètre honnête est documenté dans docs/CAPABILITY.md et l'état de validation dans docs/VALIDATION.md ; les propositions sont pesées par rapport à ce périmètre, et non au nombre de fonctionnalités.

Rôles#

  • Mainteneur. Kshana est actuellement maintenu par son fondateur, Ashforde OÜ (contact : contact@ashforde.org). Le mainteneur est le décideur final pour le périmètre, la conception, les versions et ce qui est fusionné. C'est un modèle de mainteneur bienveillant, énoncé simplement plutôt que déguisé en un comité qui n'existe pas.
  • Contributeurs. Toute personne qui ouvre un ticket ou une pull request. Les contributions sont jugées selon le niveau d'exigence de CONTRIBUTING.md — une provenance pour chaque paramètre numérique, une validation par rapport à une relation publiée, et de l'honnêteté sur la maturité.
  • Futurs committers. Lorsqu'une contribution soutenue et de grande qualité le justifiera, des droits de commit seront étendus à des contributeurs de confiance, et ce document sera mis à jour vers un modèle multi-mainteneurs (décisions par consensus tacite, le groupe de mainteneurs tranchant les désaccords). D'ici là, la voie est : contribuer, se construire un historique et être invité.

Comment les décisions sont prises#

  1. Discussion en public. Les changements de fond commencent par un ticket GitHub afin que la justification, les alternatives et les compromis soient consignés.
  2. Consensus tacite. Une proposition sans objection soutenue après un délai raisonnable, et qui franchit le seuil technique ci-dessous, avance.
  3. Le mainteneur tranche en cas de désaccord. Lorsqu'aucun consensus n'est atteint, le mainteneur décide et consigne la raison. Le désaccord est résolu par la mission et le seuil technique, non par l'ancienneté ni le volume.

Le seuil technique (non négociable)#

Ce sont des invariants stricts, appliqués par l'intégration continue et la relecture, qu'aucune décision n'outrepasse :

  • Reproducibility. (scenario, seed, engine_version) doit reproduire une exécution bit à bit. Un changement qui la rend non déterministe est un défaut, pas une fonctionnalité.
  • Provenance. Aucune constante numérique anonyme — chaque paramètre cite une source.
  • Honnêteté de la validation. Chaque capacité est étiquetée validated (par rapport à une référence indépendante) ou modelled / not modeled. Rien n'est affirmé au-delà de ses preuves. Voir la matrice vérifiée par machine dans src/verification.rs.
  • Hygiène. Aucune attribution à un outil automatisé nulle part dans les commits, le contenu ou l'historique (appliqué par scripts/check-no-attribution.sh).

Un changement qui ne peut pas franchir le seuil est refusé, aussi utile soit-il.

La frontière ouvert / fermé#

Kshana est open-core. Ce dépôt est, et reste, le moteur AGPL-3.0 ouvert complet — la référence neutre, sous double licence commerciale par Ashforde OÜ (voir LICENSING.md). Le projet n'acceptera pas dans le dépôt ouvert :

  • Profondeur soumise au contrôle des exportations ou à double usage — de véritables bibliothèques de menaces, des formes d'onde adverses, ou des paramètres de performance anti-brouillage/anti-leurrage. Le dépôt public s'en tient à des modèles et méthodes génériques et publiés (voir CONTRIBUTING.md → Contrôle des exportations). En cas de doute, demandez avant de contribuer.
  • Des données ou un étalonnage confidentiels d'un client ou d'un partenaire.
  • Des dépendances à copyleft (GPL/AGPL/LGPL/MPL) — non pas parce qu'elles entrent en conflit avec la propre licence AGPL du moteur (ce n'est pas le cas), mais parce qu'elles ne peuvent pas être relicenciées dans l'édition commerciale : nous ne pouvons vendre une licence commerciale que sur du code que nous possédons ou qui est permissif. Une dépendance à copyleft contaminerait l'édition commerciale et briserait la double licence. Les dépendances restent donc permissives (Apache/MIT/BSD/ISC), ce qu'applique deny.toml.

À l'inverse, le projet ne videra pas le noyau ouvert pour pousser de la valeur propriétaire : le moteur validé, les ancrages de validation publics, le registre d'honnêteté, le format d'échange/standard et les canaux de distribution restent ouverts. Affamer le noyau ouvert est la seule erreur fatale de l'open-core, et elle est exclue.

Versions#

  • Gestion sémantique de version. Avant la 1.0, le schéma de scénario/résultat peut changer ; les changements incompatibles sont signalés, et la version du schéma d'échange (src/interchange.rs::SCHEMA_VERSION) est la source unique de vérité pour la compatibilité des artefacts.
  • Autorité de publication. La publication (par ex. cargo publish) est une étape manuelle du mainteneur exigeant un jeton de registre. L'intégration continue et le workflow de publication déclenché par étiquette ne publient jamais automatiquement vers des registres externes — ils se contentent de ré-exécuter tous les contrôles et de joindre un artefact de construction. Voir CONTRIBUTING.md → Commits et gestion de version.

Code de conduite et sécurité#

  • La conduite est régie par CODE_OF_CONDUCT.md.
  • Les problèmes de sécurité suivent le processus de divulgation privée de SECURITY.md — n'ouvrez pas de ticket public pour une vulnérabilité.

Marque#

Le nom et le logo Kshana sont des marques d'Ashforde OÜ. La licence (AGPL-3.0, ou une licence commerciale) couvre le code, et non les marques : un fork peut utiliser le code sous la licence, mais pas le nom Kshana ni l'identité de distribution canonique. Cela maintient Ashforde comme source de vérité citée et fait partie de la manière dont le noyau ouvert reste une référence neutre.

Modifier ce document#

Les changements de gouvernance sont eux-mêmes proposés sous forme de pull request et décidés selon le processus ci-dessus. À mesure que l'échelle du projet change, attendez-vous à ce que ce document se dote d'un modèle de décision multi-mainteneurs ; il ne réduira pas le seuil technique.

Léger par conception. Honnête sur aujourd'hui, avec une voie énoncée pour demain.