AI-code bijdragen aan open source: zo pakt u dit aan

Wat u moet doen voordat u met AI ondersteunde code upstream aanbiedt

Open-sourceprojecten publiceren inmiddels beleidsregels over met AI ondersteunde code, en deze regels lopen uiteen. De gewoonte is daarom eenvoudig: zoek het beleid op voordat u de patch schrijft en wees transparant wanneer u deze indient. Eén regel geldt in beide gevallen. Dien nooit een regel in die u tijdens een review niet kunt uitleggen.

Een correcte patch wordt alsnog afgewezen als het project gegenereerde code verbiedt, of als u de herkomst van de code heeft verzwegen. De gevolgen hiervan zijn voor uw eigen naam en blijven daar ook, omdat een beheerder die de omissie later ontdekt, geen reden meer heeft om de rest van uw bijdragen te vertrouwen. Eerst enkele definities, omdat het beleid deze termen hanteert. Een LLM (large language model) is het model achter uw programmeerassistent. Een PR (pull request) op GitHub is een MR (merge request) op GitLab, en alles wat hieronder staat is op beide van toepassing. Het DCO (developer certificate of origin) is de ondertekeningsregel onderaan een commit-bericht, en dit blijkt het middelpunt van de gehele discussie te zijn.

Waar open-sourcebeleid over AI-code is beland

Projecten hebben zich in vier categorieën verdeeld. Elk onderstaand voorbeeld is gedateerd, omdat deze teksten aan verandering onderhevig zijn.

Verboden. De raad van Gentoo stemde op 14 april 2024 dat het "uitdrukkelijk verboden is om bijdragen aan Gentoo te leveren die zijn gecreëerd met hulp van kunstmatige intelligentie voor natuurlijke taalverwerking". De commit-richtlijnen van NetBSD noemen output van een LLM "besmette code" die "niet mag worden gecommit zonder voorafgaande schriftelijke goedkeuring van de core". Het document over de herkomst van code van QEMU stelt per augustus 2026 nog steeds dat het project "ELKE bijdrage zal WEIGEREN waarvan wordt aangenomen dat deze AI-gegenereerde inhoud bevat of daarvan is afgeleid".

Alleen analyse. De meeste verboden zijn beperkter dan de kop doet vermoeden. Het document van QEMU stelt dat het beleid "niet van toepassing is op ander gebruik van AI, zoals het onderzoeken van API's of algoritmen, statische analyse of debugging, mits de output daarvan niet is opgenomen in bijdragen". U mag de agent gebruiken om de code te lezen. U mag niet verzenden wat de agent heeft geschreven. Dat onderscheid is de werkbare grens binnen de meeste restrictieve projecten, en het is het punt dat mensen vaak missen.

Openbaarmaking vereist. De raad van Fedora keurde in oktober 2025 een beleid goed voor AI-ondersteunde bijdragen. Het staat de tools toe en legt de verantwoordelijkheid bij de persoon: de bijdrager is de auteur, is volledig verantwoordelijk voor de gehele bijdrage en moet openbaar maken wanneer een aanzienlijk deel ervan zonder wijzigingen afkomstig is van een tool. De Linux kernel kreeg in december 2025 een pagina voor codeerassistenten in de procesdocumentatie, met een aanhangsel voor het registreren van de tool en een strikte regel over wie mag sign-offen.

Niets vastgelegd. Dit is nog steeds het meest voorkomende geval. Een preprint van mei 2026 onderzocht 1.000 populaire GitHub-repositories en vond er 118 met enig schriftelijk AI-beleid. Stilte is geen toestemming. Vraag het in één zin in de issue tracker voordat u de patch schrijft; het antwoord wordt dan een openbaar archief waarnaar u later kunt verwijzen.

Waarom beheerders deze regels hebben opgesteld

De eerste reden is de beoordelingslast, en de rekensom is eenzijdig. Een agent genereert in een minuut een aannemelijke merge request van 400 regels. Het correct beoordelen van dat verzoek kost een beheerder een middag, en de meeste beheerders zijn vrijwilligers. De kosten voor het indienen zijn tot bijna nul gedaald. De kosten voor het beoordelen zijn onveranderd gebleven.

curl laat het uiterste punt van die curve zien. Daniel Stenberg rapporteerde medio 2025 dat ongeveer een vijfde van de beveiligingsmeldingen die via het bug bounty-programma van het project binnenkwamen, wat hij AI-slop noemt: rapporten die echte functies en echte codepaden benoemen, een aannemelijke aanval beschrijven, maar inhoudelijk niets bevatten. Het project beëindigde de bounty begin 2026 in plaats van de stroom te blijven financieren. Dat waren rapporten in plaats van patches, maar het is hetzelfde mechanisme dat ervoor zorgt dat een beheerder uw PR al vermoeid opent.

GNOME Calendar heeft het probleem vastgelegd als een label. In juni 2026 introduceerde het project "Probabilistically Automated" voor merge requests die "grote of volledige afhankelijkheid van kunstmatige 'intelligentie' bij het genereren van code" vertonen, en benoemde het symptoom exact: "meestal gepaard gaand met een gebrek aan goede tests, en het afronden van patches op basis van theoretisch beoogd gedrag in plaats van de correctheid van de code". Lees die laatste zin twee keer. De code ziet eruit alsof deze zou moeten werken. Niemand heeft gecontroleerd of dat ook zo is.

De tweede reden is herkomst, oftewel waar de code vandaan komt en onder welke licentie. QEMU verwoordt het conflict duidelijk: door te ondertekenen bevestigt u dat u "volledig begrijpt wat de auteursrechtelijke en licentiestatus is van de inhoud" die u bijdraagt, en de auteursrechtelijke status van modeloutput is onduidelijk. De raad van Gentoo gaf dezelfde reden, naast kwaliteit en ethiek. U hoeft het niet eens te zijn met de juridische interpretatie. U moet wel inzien dat het de beslissing van de beheerder is, niet die van u.

Hoe vind ik het AI-beleid van een project?

Zoek op de volgende locaties, in deze volgorde.

• CONTRIBUTING.md in de root van de repository, daarna .github/CONTRIBUTING.md, en vervolgens elk DCO-bestand dat daarnaast staat.
• De documentatie voor ontwikkelaars. QEMU bewaart zijn regels in docs/devel/code-provenance.rst. De kernel bewaart de zijne in Documentation/process/coding-assistants.rst.
• De website of wiki van het project. Het beleid van Gentoo staat op de wiki-pagina van de council, en dat van NetBSD staat in de commit-richtlijnen.
• De issue tracker en het archief van de mailinglijst. Een beleid bestaat daar meestal al maanden voordat iemand het in de repository vastlegt.

Vanuit een lokale checkout dekt één grep het meeste af:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Bestudeer daarna de eigen geschiedenis van het project, omdat de vastgelegde conventie zwaarder weegt dan elke samenvatting ervan:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Een telling naast een trailer-waarde geeft aan welke vorm dit project daadwerkelijk gebruikt. Een leeg resultaat betekent dat niemand in die vorm heeft gerapporteerd, wat op zichzelf ook informatie is. Als het project op GitHub staat en de workflow nieuw voor u is, behandelt hoe pull requests en forks werken op GitHub de mechanismen waar dit gedeelte vanuit gaat.

Vermeld dit in de commit-trailer, niet in een commentaar

Een trailer is een Key: value-regel in de laatste alinea van een commit-bericht. Git gebruikt deze vorm al voor Signed-off-by: en Co-authored-by:, en tools kunnen dit parsen. Het is daarom de enige vorm van openbaarmaking die met de code mee de boom in reist.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

De kernel documenteert dit formaat als Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] en is expliciet over de beperking van de regel: "AI-agents mogen geen Signed-off-by-tags toevoegen. Alleen mensen kunnen juridisch het Developer Certificate of Origin (DCO) certificeren." De naam van de agent komt op Assisted-by. Uw naam komt op Signed-off-by. Laat een tool nooit de tweede schrijven en laat deze nooit een Co-authored-by-adres verzinnen dat aan niemand toebehoort.

Namen variëren, dus kopieer de lokale naam in plaats van er zelf een te verzinnen. Een patch die in mei 2026 naar de QEMU-lijst werd gestuurd, stelde voor om het verbod van dat project te versoepelen voor mechanische wijzigingen, tests, documentatie en bugfixes van twintig regels of minder, vastgelegd met een trailer zoals AI-used-for: tests, docs. Sinds augustus 2026 is dit een voorstel op een mailinglijst en wijst het vastgelegde document gegenereerde inhoud nog steeds af. Eén project veranderde zijn standpunt twee keer tussen 2023 en 2026. De volgende verandering wacht niet op u; daarom is de methode belangrijker dan de lijst.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer vereist Git 2.32 of nieuwer. Het tweede commando hoort de waarde direct aan u terug te geven. Een lege regel betekent dat git de trailer niet heeft geparseerd, bijna altijd omdat er een lege regel of een gewone zin in het trailerblok onderaan het bericht staat. Voor een reeks die u al heeft geschreven, voegt git rebase --signoff origin/main de sign-off toe aan elke commit, en git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt bewerkt een berichtbestand.

Er zijn twee faalmodi waar u rekening mee moet houden. Een squash merge herschrijft het commit-bericht; bij een project dat squasht, moet u de openbaarmaking herhalen in de PR-beschrijving waar de beheerder deze leest. Een review-commentaar is geen officieel verslag, omdat commentaren bewerkt kunnen worden en nooit in de git-geschiedenis terechtkomen.

Nauwkeurigheid werkt twee kanten op. Assisted-by op een commit die u handmatig heeft getypt is ruis, en het maakt uw echte openbaarmakingen minder waardevol. Het weglaten ervan bij een commit die door de agent is geschreven, is de actie die de samenwerking beëindigt.

Wat bevestigt Signed-off-by daadwerkelijk?

Het DCO is een korte tekst, versie 1.1, gepubliceerd op developercertificate.org en wordt gebruikt door de kernel, door QEMU en door vele anderen. Door Signed-off-by: Your Name <you@example.com> toe te voegen, verklaart u dat u dit certificeert. Lees wat u certificeert, want de meeste mensen ondertekenen het zonder het ooit te lezen.

Clausule (a) stelt dat de bijdrage "geheel of gedeeltelijk door mij is gemaakt en dat ik het recht heb om deze in te dienen onder de open source-licentie die in het bestand is aangegeven". Clausule (b) heeft betrekking op werk dat gebaseerd is op eerdere open source-code die u met wijzigingen mag doorgeven. Clausule (c) heeft betrekking op code die aan u is overhandigd door iemand die hetzelfde heeft gecertificeerd. Clausule (d) stelt dat u begrijpt dat de bijdrage en de persoonlijke informatie in uw sign-off openbaar zijn en voor onbepaalde tijd worden bewaard.

Let op wat er ontbreekt. Het DCO stelt nergens dat u elk teken zelf hebt getypt. Het stelt dat u het recht hebt om de code onder deze licentie in te dienen. Daarom is gegenereerde code hier problematisch: de vraag is niet wie de auteur is, maar of u verantwoording kunt afleggen over de herkomst. De meeste projecten die een sign-off vereisen, vereisen ook een echte naam, dus een pseudoniem wordt afgekeurd. Voeg de regel toe met git commit -s, die user.name en user.email uit uw git config leest. Wanneer een DCO-bot uw PR afkeurt en de commit noemt die de regel mist, lossen git rebase --signoff origin/main en een force push naar uw branch dit op.

Het ondertekenen van een commit is niet hetzelfde als een sign-off

git commit -s voegt een tekstregel toe. git commit -S plaatst een cryptografische handtekening op het commit-object met behulp van uw GPG- of SSH-sleutel. Ze beantwoorden verschillende vragen. De handtekening bevestigt dat deze commit afkomstig is van de houder van die sleutel en sindsdien niet is gewijzigd. Het zegt niets over de herkomst van de code zelf; een ondertekende commit vol met niet-openbaar gemaakte gegenereerde code is dus wel ondertekend, maar schendt nog steeds het beleid. Een sign-off is een verklaring over de herkomst. De handtekening is een verklaring over de identiteit. Projecten die beide vereisen, zullen om beide vragen.

Dien nooit code in die u niet kunt uitleggen tijdens een review

Dit is de test, en het gaat hierbij niet echt om eerlijkheid. Vraag uzelf bij elke regel af: waar dient dit voor en wat gaat er kapot als dit ontbreekt? Als een van beide antwoorden ontbreekt, is de patch niet gereed. Er komt namelijk een review-opmerking en uw antwoord zal dan leiden tot een nieuwe ronde van genereren. Reviewers merken dit op. Dat is het moment waarop een bijdrager een last wordt. Stel dezelfde vraag over de randgevallen, de lege invoer, het foutpad en de tweede aanroeper.

Voer het uit. Bouw het, draai de testsuite van het project en schrijf een reproducer voor de bug die u claimt te verhelpen. De kernel-documentatie geeft het eerlijke alternatief in duidelijke bewoordingen: "Als de fix niet gebouwd of getest kon worden, of als er geen reproducer kon worden gemaakt, zeg dit dan expliciet: beheerders verspillen momenteel te veel tijd aan het analyseren van ongeverifieerde rapporten en ongeteste fixes." Schrijven dat u dit niet op echte hardware kon testen, kost u niets. Impliceren dat u dat wel deed, kost u uw positie in het project.

Beantwoord review-opmerkingen zelf, in uw eigen woorden en op uw eigen tijd. Een antwoord dat dertig seconden na de opmerking binnenkomt en deze in vijf alinea's herhaalt, vertelt de beheerder precies wat er is gebeurd. Houd de diff bovendien klein. Veertig regels die u volledig begrijpt, zijn voor een project meer waard dan een refactor van vierhonderd regels waar u toezicht op hield. Als uw agent meer blijft teruggeven dan u vroeg, is een vaardigheid die de agent dwingt tot de kleinst mogelijke wijziging die werkt een manier om de patch te beperken tot iets wat u nog regel voor regel kunt verdedigen.

Houd de instructies voor de agent in de repository

De instructies die u aan uw agent geeft, maken deel uit van uw toolchain; behandel ze daarom als code. Een bestand in de root van de repository, meestal AGENTS.md, bevat het build-commando, het test-commando, het formaat voor commit-berichten, de vereisten voor sign-off en de stijlafspraken die het project al documenteert. Dat bestand is geversioneerd en controleerbaar, en het is morgen hetzelfde als vandaag. Instructies die elke sessie opnieuw uit het hoofd worden getypt, leveren elke sessie een andere patch op, en u zult niet weten welke sessie de patch heeft geproduceerd die werd afgewezen. Het schrijven van een AGENTS.md die zowel door een agent als door een mens gelezen kan worden behandelt het bestand zelf.

Een waarschuwing met betrekking tot de repositories van anderen. Maak van uw eerste bijdrage geen PR die een agent-instructiebestand toevoegt aan een project dat u niet beheert. Dit komt over als een poging om het toolingbeleid van het project van buitenaf te bepalen, en het is een snelle manier om uw account geassocieerd te krijgen met zaken waar beheerders al moe van zijn. Houd het bestand in uw fork totdat iemand erom vraagt.

Waar u de agent uitvoert, is om dezelfde reden van belang. Een agent die het project kan bouwen en de tests kan uitvoeren binnen een sandbox die u beheert, levert u een patch op die u daadwerkelijk heeft geverifieerd. Dat is het verschil tussen het melden van assistentie en het melden van een gok. Het draaien van een coding agent op uw eigen VPS behandelt die configuratie, en de praktische verschillen tussen Claude Code, Cursor, Codex en Copilot behandelt hoe de tools in de dagelijkse praktijk van elkaar verschillen.

De methode, zodra het beleid wijzigt

1. Zoek het vastgestelde beleid op voordat u iets schrijft: repository, ontwikkelaarsdocumentatie, website of tracker.
2. Als er geen beleid is, vraag er dan in één zin naar in de issue en bewaar het antwoord.
3. Maak de openbaarmaking op de wijze die het project hanteert, in de commit-trailer, en herhaal deze in de body van de PR als het project commits samenvoegt (squasht).
4. Onderteken met uw echte naam, in het besef dat deze regel een claim is over uw recht om de code in te dienen.
5. Review uw eigen patch alsof een vreemde deze heeft geschreven, want dat is ook zo.

Elk project dat op deze pagina wordt genoemd, zal verplaatst zijn tegen de tijd dat u dit leest. De vijf stappen veranderen niet.

FAQ

Moet ik melden dat ik een AI-codeerassistent heb gebruikt?

Controleer het project, aangezien het antwoord lokaal is vastgelegd. Fedora vereist openbaarmaking wanneer een aanzienlijk deel van de bijdrage afkomstig is van een tool zonder wijzigingen. De Linux kernel vraagt om een Assisted-by-trailer. Gentoo en QEMU accepteren per augustus 2026 dergelijke bijdragen in het geheel niet. Waar niets is vastgelegd, dient u dit alsnog te melden in een commit-trailer. Een beheerder die hier later achter komt, reageert op het verzwijgen in plaats van op de tool, en die reactie kleeft aan al uw andere inzendingen.

Welke open-sourceprojecten verbieden door AI gegenereerde code?

Een momentopname van augustus 2026: Gentoo sinds april 2024, NetBSD dat LLM-output behandelt als besmette code die goedkeuring van de kernontwikkelaars vereist, QEMU dat bijdragen afkomstig van gegenereerde inhoud weigert, en diverse GNOME-applicaties waaronder Loupe en Calendar. Lees de eigen teksten van elk project in plaats van deze lijst, omdat deze veroudert. Let op de vrijstelling die de meeste projecten delen: het gebruik van een model om een API te onderzoeken, statische analyse uit te voeren of te helpen bij het debuggen is meestal toegestaan, zolang de output ervan niet in de patch terechtkomt.

Wat is het verschil tussen Signed-off-by en een ondertekende commit?

Signed-off-by is een tekstregel die wordt toegevoegd door git commit -s. Het certificeert het developer certificate of origin, wat betekent dat u het recht heeft om deze code in te dienen onder de licentie van het project. Een ondertekende commit, gemaakt met git commit -S, is een cryptografische handtekening over het commit-object met uw GPG- of SSH-sleutel. Het bewijst dat de commit afkomstig is van uw sleutel en niet is gewijzigd. Herkomst en identiteit zijn afzonderlijke claims, dus een ondertekende commit kan nog steeds in strijd zijn met een AI-beleid.

Kan ik de melding in de beschrijving van de pull request zetten in plaats van in het commit-bericht?

Zet het in het commit-bericht, aangezien dat het verslag is dat in de git-historie belandt en meereist met de code naar iedereen die de repository later kloont. Een beschrijving van een pull request kan achteraf worden bewerkt en leeft op het hostingplatform. Voeg het ook toe aan de body van de PR wanneer het project squash merges gebruikt, omdat een squash uw commit-bericht herschrijft en de trailer kan verwijderen.

Mijn pull request werd gesloten omdat het door AI was gegenereerd. Wat nu?

Ga niet in discussie over het beleid in de thread, omdat de persoon die het sloot de regel niet alleen heeft geschreven en de thread niet de plek is waar dit verandert. Lees de beleidstekst en beslis vervolgens of u eraan kunt voldoen. Waar het project gegenereerde patches verbiedt, is een duidelijke bugrapportage met een reproducer en zonder patch nog steeds welkom, en dit is vaak de nuttigere bijdrage. Als u terugkeert met code, kom dan met een kleine wijziging die u regel voor regel kunt verdedigen.