Deux textes — personnes physiques et entités —, un registre qui tient lieu de signature, le DCO 1.1 joint, un guide, et un outil qui contrôle l'historique. Ce que l'accord demande Le contributeur garde son droit d'auteur. Aucune cession : une licence large, incluant le droit de republier sous une autre licence. C'est ce qui préserve la capacité de changer de licence, de proposer un module sous licence distincte, et surtout d'agir en justice contre un contrefacteur sans réunir la signature de chaque contributeur. Ce qu'il donne en retour, et pourquoi il le faut Ce droit de relicenciement crée un déséquilibre réel : une partie du pouvoir sur le code du contributeur passe à l'éditeur. C'est ce qui fait refuser les accords de contribution, souvent à raison. L'article 7 est la contrepartie, et elle est opposable. Publication libre immédiate de toute contribution intégrée. Aucun retrait de ce qui est déjà sorti sous AGPL. Le cœur reste sous une licence approuvée OSI ou FSF. Attribution conservée dans l'historique publié. Et ces engagements survivent à l'abandon du projet, opposables aux ayants droit. Deux points de droit français traités, pas recopiés d'un modèle américain Le droit moral est perpétuel et inaliénable : une clause de renonciation serait nulle. Plutôt que d'en recopier une qui donnerait une fausse garantie, l'accord organise ce que ce droit appelle concrètement — paternité au registre et dans l'historique, traçabilité des modifications ultérieures. L'article L. 113-9 attribue de plein droit à l'employeur les droits sur le logiciel écrit par un salarié dans l'exercice de ses fonctions. Un développeur salarié qui signe l'accord individuel accorde des droits dont il n'est pas titulaire : sa signature ne couvre rien. D'où l'accord entité, qui fait garantir la titularité par celui qui la détient et nommer les adresses autorisées. C'est le défaut le plus courant des accords de contribution, et il ne se voit que le jour où quelqu'un le conteste. Ces textes n'ont pas été relus par un avocat, et le disent en tête. À faire avant d'ouvrir le dépôt. Ce qui ne demande aucune signature, dit avant le reste Un rapport de bogue, une critique de conception, une remarque sur la documentation. Sur un outil de crise, un rapport précis vaut souvent mieux qu'un correctif — le guide le dit d'entrée, avant de parler de formalités. Un accord qu'on ne vérifie pas se découvre incomplet des années plus tard « pnpm accords » lit l'historique réel : tout auteur figure-t-il au registre, tout commit postérieur à l'ouverture porte-t-il sa certification d'origine. L'ouverture n'est pas une date choisie à la main, c'est le commit qui a introduit CONTRIBUTING.md — ce qui précède est antérieur à la règle et n'a pas à s'y conformer rétroactivement. L'outil est sous CC0, comme le vérificateur de journal : ce qui contrôle un projet ne doit rien lui devoir. Neuf contrôles de plus dans « pnpm verif » (454 → 463) sur la cohérence des documents entre eux : l'accord existe dans les deux formes, il laisse la titularité, il porte son article 7, il ne prétend pas faire renoncer au droit moral, il traite le salarié, le DCO est joint sans être réécrit, le registre se lit, le guide dit comment signer et ouvre un canal privé pour les failles. Sur les commits assistés par un outil L'historique porte des « Co-Authored-By: Claude Opus 5 ». Le vérificateur les ignore, et le registre dit pourquoi : une œuvre suppose un auteur personne physique, un outil ne détient aucun droit à accorder et n'a donc rien à signer. L'auteur du commit répond seul des garanties de l'article 6. La mention reste, parce que dire comment ce code a été écrit vaut mieux que de l'effacer. Signed-off-by:Kourser <contact@kourser.bzh> Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
