Votre projet personnel vient de dépasser les 500 étoiles, et un inconnu a ouvert sa première vraie pull request sérieuse : 2 000 lignes qui corrigent un problème que vous évitez depuis des mois. Vous voulez cliquer sur merge. Mais avant de le faire, posez-vous la question désagréable : avez-vous réellement le droit légal de distribuer ce code — et de continuer à le distribuer sous votre licence, pour toujours, peu importe pour qui travaille ce contributeur ?
Si votre dépôt n'a aucune politique de contribution, la réponse honnête est que vous n'en êtes pas sûr. Le contributeur reste titulaire du droit d'auteur sur chaque ligne qu'il a écrite, et la licence de votre projet à elle seule ne détermine pas toujours qui a accordé quoi à qui. Cette incertitude reste invisible jusqu'au jour où elle compte : un changement de licence, une acquisition, un utilisateur corporate qui fait sa due diligence de licences, ou l'employeur d'un contributeur qui affirme que le travail lui appartenait depuis le début.
Deux mécanismes résolvent ce problème, et presque tous les projets open source en choisissent un : le Contributor License Agreement (CLA) et le Developer Certificate of Origin (DCO). Les deux existent pour établir qu'un contributeur est autorisé à faire la contribution et que le projet a le droit de la distribuer. Ils diffèrent énormément en poids, en friction et en ce qu'ils vous permettent de faire ensuite. Ce guide explique comment chacun fonctionne, quand choisir lequel, et comment mettre en place votre choix en un après-midi.
Pourquoi votre projet a besoin d'une politique de contribution
Le droit d'auteur s'attache automatiquement. Dès qu'une personne écrit du code, elle en est propriétaire — aucune inscription, aucun avis de copyright requis. Lorsqu'elle le soumet à votre projet, votre licence open source couvre beaucoup de choses, mais elle laisse des lacunes que seule une politique de contribution comble :
- L'autorisation entrante. Votre licence sortante (MIT, Apache-2.0, GPL) indique aux utilisateurs ce qu'ils peuvent faire de votre code. Une politique de contribution rend explicite le fait que les contributions entrantes arrivent sous des conditions compatibles, afin que vous puissiez distribuer l'œuvre combinée sans suivre à la main la provenance de chaque fichier.
- Les revendications des employeurs. La plupart des contrats de travail cèdent la propriété intellectuelle des projets personnels à l'employeur, au moins pour le travail lié à l'emploi du salarié. Une politique qui demande aux contributeurs de confirmer qu'ils ont le droit de soumettre place cette responsabilité — et la trace écrite — sur le contributeur.
- L'option de changement de licence. Si vous voulez un jour changer de licence, ajouter une édition commerciale ou céder le projet à une fondation, vous avez besoin des droits de chaque contributeur. Obtenir cette autorisation rétroactivement auprès de dizaines de contributeurs passés est quelque part entre pénible et impossible. Une politique choisie dès le premier jour décide si cette porte reste ouverte.
- La protection des brevets. Les contributions de code peuvent transporter avec elles des droits de brevet. Certaines politiques incluent une concession de brevet explicite ; d'autres non, ce qui compte plus que la plupart des mainteneurs ne le réalisent.
Rien de tout cela n'exige un cabinet d'avocats sous contrat. Cela exige de choisir CLA ou DCO, de l'écrire dans votre dépôt et de l'appliquer automatiquement. Voici ce que chaque choix implique.
Qu'est-ce qu'un Contributor License Agreement (CLA) ?
Un Contributor License Agreement est un document juridique signé entre le contributeur et le projet (ou l'entreprise ou la fondation qui le porte). Le contributeur signe une fois, et cette signature couvre toutes ses contributions futures.
Contrairement aux licences open source, les CLA ne sont pas standardisés. Chaque projet écrit le sien, mais la plupart se rangent dans deux formes familières :
CLA individuel vs. corporate
- CLA individuel (ICLA) : signé par une personne contribuant en son propre nom. Il accorde généralement au projet une large licence de droit d'auteur et souvent une licence de brevet, tandis que le contributeur conserve son propre droit d'auteur.
- CLA corporate (CCLA) : signé par une entreprise, autorisant ses employés à contribuer. L'entreprise accorde les mêmes droits pour le travail soumis par ses équipes. Les projets qui acceptent des contributions corporate sans CCLA font confiance au fait que le manager de chaque employé sait — et approuve — ce qui est exactement le type de confiance qui s'évapore pendant une due diligence.
Concession de licence vs. cession de droit d'auteur
La plupart des CLA modernes sont des concessions de licence : le contributeur conserve la propriété et accorde au projet une licence perpétuelle, mondiale et gratuite — souvent assez large pour permettre un changement de licence. L'ICLA de l'Apache Software Foundation en est l'exemple canonique.
Une minorité de projets utilise la cession de droit d'auteur, où le contributeur transfère la propriété purement et simplement (l'approche de la Free Software Foundation). La cession donne au projet une liberté maximale pour faire respecter ses droits et changer de licence, mais elle demande le plus aux contributeurs et est tombée en défaveur auprès des projets portés par la communauté.
Ce qu'un CLA coûte à vous et à vos contributeurs
Le compromis, c'est la friction. Un contributeur qui intervient pour la première fois doit quitter la pull request, lire un document juridique, le signer (généralement par voie électronique) et attendre que la vérification de statut passe au vert avant qu'un mainteneur examine son code. L'outillage a rendu cela presque indolore — des bots comme CLA Assistant commentent la pull request avec un lien de signature et enregistrent la signature automatiquement — mais cela reste une barrière entre « j'ai corrigé votre bug » et « vous pouvez fusionner ma correction ». Certains contributeurs occasionnels rebroussent chemin à cause de cela.
En échange, le projet obtient un enregistrement signé et auditable : cette personne, à cette date, a accordé ces droits. Pour les projets soutenus par des entreprises, les projets à double licence et tout ce qui pourrait un jour être acquis, cette trace écrite vaut de l'argent réel.
Qu'est-ce que le Developer Certificate of Origin (DCO) ?
Le Developer Certificate of Origin a été introduit par la Linux Foundation en 2004 pour le noyau Linux, précisément pour éviter le poids d'un CLA. Ce n'est pas un contrat qu'un contributeur signe et classe. C'est une brève certification — cinq paragraphes, version 1.1 — que le contributeur affirme à chaque commit en ajoutant une ligne Signed-off-by au message de commit :
Fix off-by-one error in retry backoff calculation
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
Signed-off-by: Alex Rivera <[email protected]>Ajouter la ligne ne demande qu'un drapeau : git commit -s l'ajoute automatiquement en utilisant votre identité Git configurée. En signant, le contributeur certifie que :
- Il a créé la contribution (en tout ou en partie) et a le droit de la soumettre sous la licence open source du projet, ou
- Sa contribution est basée sur un travail antérieur déjà placé sous une licence open source appropriée qui permet cette soumission, ou
- Il a reçu la contribution de quelqu'un d'autre qui a certifié l'un des points ci-dessus, et il ne l'a pas modifiée, et
- Il comprend que la contribution et son enregistrement — y compris sa signature — sont publics et conservés indéfiniment.
Voilà tout le mécanisme. Aucun document séparé, aucune liaison de compte, aucun onboarding par projet. L'application se fait par une vérification de statut : l'application DCO ou une vérification équivalente s'assure que chaque commit de la pull request porte une signature valide, et les mainteneurs ne fusionnent que lorsque c'est vert.
Les limites délibérées du DCO
Notez ce que le DCO ne fait pas. Il n'accorde aucune licence au-delà de ce que la licence sortante du projet confère déjà — il s'appuie sur le fait que la contribution arrive sous les termes de licence du projet. Il ne contient aucune concession de brevet. Et comme rien n'est signé ni classé par contributeur, il n'existe aucun registre central de qui a accepté quoi ; l'historique git est lui-même l'enregistrement.
Ses partisans y voient une qualité : la barrière basse du DCO est tout l'intérêt. Le noyau Linux, GitLab (qui est passé d'un CLA en 2017) et Chef (qui a fait de même en 2016) ont tous conclu que l'attestation par commit leur donne la provenance dont ils ont besoin sans taxer chaque contributeur. Le comité technique d'OpenStack a décidé en 2025 de remplacer son CLA par le DCO pour toutes les contributions. La tendance du secteur est indéniable — mais une tendance n'est pas un verdict pour votre projet, comme l'expliquent les sections suivantes.
CLA vs. DCO côte à côte
| Dimension | CLA | DCO |
|---|---|---|
| Mécanisme juridique | Accord signé, classé une fois par contributeur | Attestation par commit dans le message de commit |
| Ce que fait le contributeur | Signe un document (généralement via un lien de bot) | Ajoute Signed-off-by avec git commit -s |
| Gestion du droit d'auteur | Concession de licence explicite (ou cession) au projet | La contribution arrive sous la licence du projet ; aucune concession séparée |
| Concession de brevet | Généralement incluse | Aucune |
| Liberté de changer de licence | Des concessions larges le permettent souvent | Aucun droit supplémentaire ; un changement de licence exige le consentement de chaque contributeur |
| Friction pour le contributeur | Plus élevée : lire, signer, attendre la vérification | Minimale : un drapeau Git |
| Outillage d'application | CLA Assistant, EasyCLA, bots sur mesure | Application DCO, vérifications du message de commit |
| Enregistrement du consentement | Base de données de signatures | L'historique git lui-même |
| Couverture des employeurs | Le CLA corporate couvre explicitement les employés | Le contributeur certifie lui-même qu'il a le droit de soumettre |
| Idéal pour | Projets soutenus par des entreprises, à double licence ou concernés par une acquisition | Projets communautaires où la friction de contribution compte le plus |
Quand un CLA est le bon choix
Choisissez le CLA lorsque l'avenir du projet pourrait dépendre de droits que le DCO ne capture pas :
- Vous prévoyez une double licence ou un changement de licence. Si une édition commerciale, un changement de licence ou un passage de copyleft à permissif est ne serait-ce que vaguement plausible, un CLA avec une large concession en retour est le seul moyen léger de garder cette option ouverte. Reconstituer le consentement des années plus tard, c'est le scénario cauchemar.
- Une entreprise soutient le projet. Les sponsors corporate, les acquéreurs et les clients enterprise qui font une due diligence de PI veulent un registre de signatures, pas de l'archéologie. Google, les projets Apache et Canonical utilisent tous des CLA exactement pour cette raison.
- Les brevets comptent dans votre domaine. Codecs, protocoles sans fil, architectures de modèles ML — dans les domaines riches en brevets, la concession de brevet explicite du CLA fait un vrai travail que le DCO saute silencieusement.
- Une fondation l'exige. Certaines fondations imposent leur CLA comme condition d'hébergement ou de graduation. Vérifiez avant de supposer que le DCO suffit.
Si vous prenez cette voie, gardez le CLA lui-même standard et ennuyeux : partez de l'ICLA d'Apache ou d'un modèle Harmony plutôt que de rédiger à partir de zéro, publiez les versions individuelle et corporate, et mettez en place un bot de signature dès le premier jour pour que la friction soit un clic, pas un aller-retour de PDF.
Quand le DCO l'emporte
Choisissez le DCO lorsque les contributions sont le sang du projet et que la friction est l'ennemi :
- Projets communautaires avec de nombreux contributeurs occasionnels. Corrections de documentation, fautes de frappe, petits patchs de bugs — les contributions les plus susceptibles de rebrousser chemin devant une barrière de signature sont aussi celles qu'un DCO gère avec élégance.
- Licence permissive, aucun projet de changement de licence. Si le projet restera MIT ou Apache-2.0 pour toujours et qu'aucune édition commerciale n'est au programme, les droits supplémentaires du CLA vous apportent peu.
- Mainteneurs solo et petites équipes. Le DCO n'a besoin d'aucune infrastructure de signature, d'aucune entité juridique pour conserver les accords et d'aucun processus de contreseing des formulaires corporate. C'est une gouvernance que vous pouvez gérer depuis un fichier
CONTRIBUTING.mdet une vérification de statut. - Posture de compatibilité maximale. Certains contributeurs — en particulier ceux employés par de grandes entreprises aux politiques de PI strictes — peuvent signer un DCO mais ne peuvent pas signer un CLA externe sans revue juridique. Le DCO garde cette porte ouverte.
Quel que soit votre choix, écrivez la décision. Un CONTRIBUTING.md qui énonce la politique, montre le flux exact de signature ou de sign-off et renvoie au texte intégral élimine la source de confusion la plus courante : des contributeurs qui devinent les exigences à partir d'une vérification de statut en échec.
5 erreurs qui sapent l'un ou l'autre choix
1. Dire les deux. L'échec réel le plus courant est un CONTRIBUTING.md qui exige des signatures DCO dans un paragraphe et des signatures CLA dans un autre — généralement après une migration à moitié terminée. Les contributeurs suivent une instruction, l'autre vérification échoue, et les mainteneurs fusionnent quand même, ce qui annule l'intérêt des deux. Choisissez un seul mécanisme, appliquez-le et supprimez toute trace de l'autre.
2. Aucune application automatisée. Une politique énoncée uniquement en prose est une suggestion. Intégrez la vérification dans votre workflow de pull request comme vérification de statut obligatoire — l'application DCO pour les sign-offs, CLA Assistant ou EasyCLA pour les signatures — afin qu'une contribution non acceptée ne puisse pas être fusionnée par accident ou par fatigue des mainteneurs.
3. Ignorer les contributeurs corporate. Si des entreprises utilisent et patchent votre projet, des employés soumettront du code sur leur temps de travail. Avec une politique CLA, cela signifie faire signer le CCLA tôt, tant que la relation est chaleureuse. Avec une politique DCO, cela signifie s'assurer que l'exigence de sign-off est assez visible pour que la première contribution de personne ne devienne un incident de PI.
4. Supposer que les contrats de travail permettent de contribuer. Revers de la même médaille : si vous contribuez à d'autres projets, vérifiez d'abord votre propre contrat de travail. Beaucoup cèdent par défaut à l'employeur la PI des projets personnels liés au travail. La certification du DCO (« j'ai le droit de soumettre ceci ») n'est vraie que si cette paperasse le dit.
5. Aucune politique pour le code assisté par IA. Les contributions générées par machine soulèvent des questions de provenance que ni le texte du DCO de 2004 ni la plupart des modèles de CLA n'avaient anticipées. Décidez votre position — autorisé avec revue, divulgué, ou interdit — et énoncez-la dans CONTRIBUTING.md aux côtés de votre politique CLA/DCO, avant que votre première pull request générée par IA n'arrive plutôt qu'après.
N'oubliez pas le volet financier de votre projet
Voici la partie que les mainteneurs reportent jusqu'à la saison fiscale : dès que votre projet gagne son premier dollar — paiements GitHub Sponsors, dons Open Collective, une mission de conseil arrivée grâce à votre README — il a des finances, et des finances ont besoin de comptes.
La même discipline qui rend la provenance des contributions auditable rend l'argent du projet gérable. Suivez les revenus de sponsoring séparément de votre salaire pour savoir ce qui constitue un revenu indépendant imposable. Enregistrez les dépenses du projet — renouvellements de domaine, minutes de CI, l'après-midi qu'un avocat a passé à examiner votre CLA — dans leurs propres comptes pour que les déductions ne s'évaporent pas dans des relevés de carte personnelle. Si le projet devient une LLC ou rejoint un hôte fiscal, des enregistrements historiques propres rendent la transition ennuyeuse plutôt que médico-légale.
La comptabilité en texte brut convient particulièrement bien à ce workflow : votre grand livre vit dans le contrôle de version à côté de votre code, chaque écriture a un historique, et rien ne se cache dans un format propriétaire. Notre documentation explique comment faire tourner un premier grand livre en quelques minutes.
Gardez les comptes de votre projet aussi propres que son historique Git
Choisir entre un CLA et un DCO prend un après-midi ; démêler la provenance ou les finances d'un projet des années plus tard prend des semaines. Prenez la décision de contribution maintenant, automatisez son application, et accordez à l'argent du projet le même soin qu'à ses commits. Beancount.io propose une comptabilité en texte brut qui vous donne une transparence et un contrôle complets sur vos données financières — pas de boîtes noires, pas de dépendance à un fournisseur. Commencez gratuitement et découvrez pourquoi les développeurs et les professionnels de la finance passent à la comptabilité en texte brut.
