CLA vs. DCO: Welke Contributor Agreement Moet Je Open Source Project Gebruiken?

Je hobbyproject is net over de 500 sterren gepasseerd, en een vreemde heeft de eerste serieuze pull request geopend: 2.000 regels die een probleem oplossen dat je al maanden ontwijkt. Je wilt op merge klikken. Maar voordat je dat doet, stel jezelf de ongemakkelijke vraag: heb je eigenlijk wel het wettelijke recht om die code te verspreiden — en om die voor altijd te blijven verspreiden onder jouw licentie, ongeacht voor wie die contributor werkt?

Als je repository geen contribution policy heeft, is het eerlijke antwoord dat je het niet zeker weet. De contributor bezit nog steeds het auteursrecht op elke regel die hij heeft geschreven, en de licentie van je project alleen beslecht niet altijd wie wat aan wie heeft toegekend. Die onzekerheid blijft onzichtbaar tot het moment dat het ertoe doet: een herlicentiëring, een overname, een bedrijfsmatige gebruiker die due diligence op licenties doet, of de werkgever van een contributor die claimt dat het werk al die tijd van hen was.

Twee mechanismen lossen dit probleem op, en vrijwel elk open source project kiest er één van: de Contributor License Agreement (CLA) en de Developer Certificate of Origin (DCO). Beide bestaan om vast te leggen dat een contributor de bijdrage mag doen en dat het project het recht heeft om die te distribueren. Ze verschillen enorm in gewicht, frictie en wat ze je later toestaan. Deze gids legt uit hoe elk werkt, wanneer je welke kiest, en hoe je je keuze in een middag opzet.

Waarom Je Projectüberhaupt een Contribution Policy Nodig Heeft​

Auteursrecht ontstaat automatisch. Op het moment dat iemand code schrijft, is die van hen — geen registratie, geen copyrightvermelding nodig. Wanneer ze het bij jouw project indienen, dekt je open source licentie veel, maar laat het hiaten die alleen een contribution policy dicht:

• De inkomende licentieverlening. Je uitgaande licentie (MIT, Apache-2.0, GPL) vertelt gebruikers wat ze met je code mogen doen. Een contribution policy maakt expliciet dat inkomende bijdragen onder compatibele voorwaarden binnenkomen, zodat je het gecombineerde werk kunt distribueren zonder per bestand de herkomst handmatig bij te houden.
• Werkgeverclaims. De meeste arbeidsovereenkomsten dragen IE van hobbyprojecten over aan de werkgever, in ieder geval voor werk dat verband houdt met de functie van de werknemer. Een policy die contributors vraagt te bevestigen dat ze het recht hebben om in te dienen, legt die verantwoordelijkheid — en het papieren spoor — bij de contributor.
• Herlicentiëringsopties. Als je ooit van licentie wilt veranderen, een commerciële editie wilt toevoegen, of het project aan een stichting wilt schenken, heb je rechten van elke contributor nodig. Die toestemming met terugwerkende kracht verzamelen van tientallen oud-contributors is ergens tussen pijnlijk en onmogelijk. Een policy die op dag één wordt gekozen, bepaalt of die deur open blijft.
• Octrooibescherming. Codebijdragen kunnen octrooirechten met zich meedragen. Sommige policies bevatten een expliciete octrooilicentieverlening; andere niet, wat meer uitmaakt dan de meeste maintainers beseffen.

Niets hiervan vereist een advocatenkantoor op retainer. Het vereist dat je CLA of DCO kiest, het opschrijft in je repository, en het automatisch afdwingt. Dit is wat elke keuze inhoudt.

Wat Is een Contributor License Agreement (CLA)?​

Een Contributor License Agreement is een ondertekend juridisch document tussen de contributor en het project (of het bedrijf of de stichting erachter). De contributor ondertekent één keer, en die handtekening dekt al hun toekomstige bijdragen.

Anders dan open source licenties zijn CLA's niet gestandaardiseerd. Elk project schrijft zijn eigen versie, maar de meeste vallen in twee bekende vormen:

Individuele vs. bedrijfs-CLA's​

• Individuele CLA (ICLA): ondertekend door een persoon die namens zichzelf bijdraagt. Het verleent het project doorgaans een brede auteursrechtlicentie en vaak een octrooilicentie, terwijl de contributor zijn eigen auteursrecht behoudt.
• Bedrijfs-CLA (CCLA): ondertekend door een bedrijf, dat zijn werknemers machtigt om bij te dragen. Het bedrijf verleent dezelfde rechten voor werk dat zijn mensen indienen. Projecten die bedrijfsbijdragen accepteren zonder CCLA vertrouwen erop dat de manager van elke werknemer het weet — en goedkeurt — wat precies het soort vertrouwen is dat verdampt tijdens due diligence.

Licentieverlening vs. auteursrechtsoverdracht​

De meeste moderne CLA's zijn licentieverleningen: de contributor behoudt het eigendom en geeft het project een eeuwigdurende, wereldwijde, royaltyvrije licentie — vaak een die breed genoeg is om herlicentiëring toe te staan. De ICLA van de Apache Software Foundation is het canonieke voorbeeld.

Een minderheid van de projecten gebruikt auteursrechtsoverdracht, waarbij de contributor het eigendom volledig overdraagt (de aanpak van de Free Software Foundation). Overdracht geeft het project maximale vrijheid om te handhaven en te herlicentiëren, maar het vraagt het meest van contributors en is uit de gratie geraakt bij community-gedreven projecten.

Wat een CLA jou en je contributors kost​

De afweging is frictie. Een eerstekeer-contributor moet de pull request verlaten, een juridisch document lezen, het ondertekenen (meestal elektronisch), en wachten tot de statuscheck groen wordt voordat een maintainer zijn code bekijkt. Tooling heeft dit bijna pijnloos gemaakt — bots zoals CLA Assistant reageren op de pull request met een ondertekeningslink en registreren de handtekening automatisch — maar het blijft een poort tussen "ik heb je bug opgelost" en "je kunt mijn fix mergen". Sommige drive-by contributors haken hierop af.

In ruil daarvoor krijgt het project een ondertekend, controleerbaar register: deze persoon, op deze datum, verleende deze rechten. Voor bedrijfsgesteunde projecten, dual-licensed projecten, en alles dat ooit overgenomen zou kunnen worden, is dat papieren spoor echt geld waard.

Wat Is de Developer Certificate of Origin (DCO)?​

De Developer Certificate of Origin werd in 2004 door de Linux Foundation geïntroduceerd voor de Linux-kernel, precies om het gewicht van een CLA te vermijden. Het is geen contract dat een contributor ondertekent en opbergt. Het is een korte verklaring — vijf paragrafen, versie 1.1 — die de contributor bij elke commit bevestigt door een Signed-off-by-regel toe te voegen aan het commit-bericht:

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]>

Het toevoegen van de regel is één flag: git commit -s voegt het automatisch toe met je geconfigureerde Git-identiteit. Door te ondertekenen verklaart de contributor dat:

1. Zij de bijdrage hebben gecreëerd (geheel of gedeeltelijk) en het recht hebben om die in te dienen onder de open source licentie van het project, of
2. Hun bijdrage is gebaseerd op eerder werk dat al onder een passende open source licentie valt die deze indiening toestaat, of
3. Zij de bijdrage van iemand anders hebben ontvangen die een van bovenstaande heeft verklaard, en zij die niet hebben gewijzigd, en
4. Zij begrijpen dat de bijdrage en het record daarvan — inclusief hun ondertekening — openbaar zijn en voor onbepaalde tijd bewaard blijven.

Dat is het hele mechanisme. Geen apart document, geen accountkoppeling, geen per-project onboarding. Handhaving is een statuscheck: de DCO-app of een gelijkwaardige check verifieert dat elke commit in de pull request een geldige ondertekening draagt, en maintainers mergen alleen wanneer die groen is.

De bewuste beperkingen van de DCO​

Merk op wat de DCO niet doet. Het verleent geen licentie verder dan wat de uitgaande licentie van het project al overdraagt — het vertrouwt erop dat de bijdrage onder de licentievoorwaarden van het project binnenkomt. Het bevat geen octrooilicentieverlening. En omdat er niets per contributor wordt ondertekend en gearchiveerd, is er geen centraal register van wie waarmee heeft ingestemd; de git-geschiedenis zelf is het record.

Voorstanders beschouwen dit als een voordeel: de lage drempel van de DCO is juist het punt. De Linux-kernel, GitLab (dat in 2017 overstapte van een CLA) en Chef (dat in 2016 overstapte) concludeerden allemaal dat per-commit attestatie hen de herkomst geeft die ze nodig hebben zonder elke contributor te belasten. De Technical Committee van OpenStack besloot in 2025 zijn CLA te vervangen door de DCO voor alle bijdragen. De industrietrend is onmiskenbaar — maar een trend is geen verdict voor jouw project, zoals de volgende secties uitleggen.

CLA vs. DCO Naast Elkaar​

Wanneer een CLA de Juiste Keuze Is​

Kies de CLA wanneer de toekomst van het project kan afhangen van rechten die de DCO niet vastlegt:

• Je bent van plan om dual-licensing te doen of te herlicentiëren. Als een commerciële editie, een licentieverandering, of een overstap van copyleft naar permissieve licenties ook maar enigszins waarschijnlijk is, is een CLA met een brede teruglicentie de enige lichtgewicht manier om die optie open te houden. Het reconstrueren van toestemming jaren later is het nachtmerriescenario.
• Een bedrijf staat achter het project. Bedrijfssponsors, overnemers en zakelijke klanten die IE due diligence doen, willen een handtekeningenregister, geen archeologie. Google, Apache-projecten en Canonical gebruiken allemaal CLA's om precies deze reden.
• Octrooien doen ertoe in jouw domein. Codecs, draadloze protocollen, ML-modelarchitecturen — in octrooirelijke velden doet de expliciete octrooilicentie van de CLA echt werk dat de DCO stil overslaat.
• Een stichting vereist het. Sommige stichtingen verplichten hun CLA als voorwaarde voor hosting of graduatie. Controleer dit voordat je aanneemt dat de DCO volstaat.

Als je deze route kiest, houd de CLA zelf dan standaard en saai: begin met de Apache ICLA of een Harmony-template in plaats van vanaf nul te ontwerpen, publiceer zowel individuele als bedrijfsversies, en zet op dag één een ondertekeningsbot op zodat de frictie één klik is, niet een PDF-heen-en-weer.

Wanneer de DCO Wint​

Kies de DCO wanneer bijdragen de levensader zijn en frictie de vijand is:

• Community-projecten met veel gelegenheidscontributors. Documentatiefixes, typefoutcorrecties, kleine bugpatches — de bijdragen die het vaakst afketsen op een ondertekeningspoort zijn ook degene die een DCO sierlijk afhandelt.
• Permissieve licentie, geen herlicentiëringsplannen. Als het project voor altijd MIT of Apache-2.0 blijft en er geen commerciële editie op de roadmap staat, leveren de extra rechten van de CLA je weinig op.
• Solo-maintainers en kleine teams. De DCO heeft geen handtekeninginfrastructuur nodig, geen juridische entiteit om overeenkomsten te bewaren, en geen proces voor het medeondertekenen van bedrijfsformulieren. Het is governance die je kunt runnen vanuit een CONTRIBUTING.md-bestand en een statuscheck.
• Maximale-compatibiliteitshouding. Sommige contributors — met name zij die in dienst zijn bij grote bedrijven met strikte IE-policies — kunnen een DCO ondertekenen maar geen externe CLA zonder juridische toetsing. De DCO houdt die deur open.

Welke je ook kiest, schrijf de beslissing op. Een CONTRIBUTING.md die de policy vermeldt, de exacte ondertekenings- of sign-off-flow toont, en de volledige tekst linkt, verwijdert de meest voorkomende bron van verwarring: contributors die eisen raden op basis van een falende statuscheck.

5 Fouten Die Elke Keuze Ondermijnen​

1. Beide zeggen. De meest voorkomende praktijkfout is een CONTRIBUTING.md die in de ene paragraaf DCO-ondertekeningen eist en in de andere CLA-handtekeningen — meestal na een half afgeronde migratie. Contributors volgen de ene instructie, de andere check faalt, en maintainers mergen alsnog, wat het doel van beide tenietdoet. Kies één mechanisme, handhaaf het, en verwijder elk spoor van het andere.

2. Geen geautomatiseerde handhaving. Een policy die alleen in proza staat is een suggestie. Koppel de check aan je pull request-workflow als een verplichte statuscheck — de DCO-app voor ondertekeningen, CLA Assistant of EasyCLA voor handtekeningen — zodat een niet-goedgekeurde bijdrage niet per ongeluk of door maintainer-moeheid kan mergen.

3. Bedrijfscontributors negeren. Als bedrijven je project gebruiken en patchen, zullen werknemers code indienen onder werktijd. Onder een CLA-policy betekent dat de CCLA vroeg laten ondertekenen, terwijl de relatie nog warm is. Onder een DCO-policy betekent het ervoor zorgen dat de ondertekeningsvereiste zichtbaar genoeg is dat niemand' eerste bijdrage een IE-incident wordt.

4. Aannemen dat arbeidsovereenkomsten bijdragen toestaan. Keerzijde van dezelfde medaille: als je aan andere projecten bijdraagt, controleer dan eerst je eigen arbeidsovereenkomst. Veel dragen werkgerelateerde IE van hobbyprojecten standaard over aan de werkgever. De verklaring van de DCO ("ik heb het recht om dit in te dienen") is alleen waar als dat papierwerk dat zegt.

5. Geen policy voor AI-ondersteunde code. Machinegegenereerde bijdragen roepen herkomstvragen op die noch de DCO-tekst uit 2004 noch de meeste CLA-templates voorzagen. Bepaal je standpunt — toegestaan met review, openbaar gemaakt, of verboden — en vermeld het in CONTRIBUTING.md naast je CLA/DCO-policy, voordat je eerste AI-gegenereerde pull request arriveert in plaats van erna.

Vergeet de Geldkant van Je Project Niet​

Dit is het deel dat maintainers uitstellen tot het belastingseizoen: op het moment dat je project zijn eerste dollar verdient — GitHub Sponsors-uitbetalingen, Open Collective-donaties, een consultancyopdracht die binnenkwam dankzij je README — heeft het financiën, en financiën hebben boekhouding nodig.

Dezelfde discipline die bijdrageherkomst controleerbaar maakt, maakt projectgeld beheersbaar. Houd sponsorinkomsten gescheiden van je salaris zodat je weet wat belastbaar inkomen uit zelfstandige arbeid is. Registreer projectkosten — domeinvernieuwingen, CI-minuten, de middag die een advocaat besteedde aan het beoordelen van je CLA — in hun eigen rekeningen zodat aftrekposten niet verdampen in persoonlijke creditcardafschriften. Als het project uitgroeit tot een LLC of zich aansluit bij een fiscale host, maken schone historische gegevens de overgang saai in plaats van forensisch.

Plain-text accounting past ongewoon goed bij deze workflow: je grootboek leeft in versiebeheer naast je code, elke boeking heeft een geschiedenis, en niets verstopt zich in een propriëtair formaat. Onze docs leggen uit hoe je in enkele minuten een eerste grootboek operationeel hebt.

Houd de Boeken van Je Project Zo Schoon als Zijn Git-geschiedenis​

Kiezen tussen een CLA en een DCO kost een middag; het ontwarren van herkomst of projectfinanciën jaren later kost weken. Neem de bijdragebeslissing nu, automatiseer de handhaving, en geef het geld van het project dezelfde zorg die je aan zijn commits geeft. Beancount.io biedt plain-text accounting die je volledige transparantie en controle over je financiële gegevens geeft — geen black boxes, geen vendor lock-in. Begin gratis en zie waarom ontwikkelaars en finance professionals overstappen op plain-text accounting.