AI-assisted code and open source policies

What to do before you send AI-assisted code upstream

Open source projects now publish policies on AI-assisted code, and those policies do not agree with each other. So the habit is simple: find the policy before you write the patch, and disclose accurately when you send it. One rule sits under both. Never submit a line you cannot explain in review.

A correct patch still gets closed if the project bans generated code, or if you hid where the code came from. The cost lands on your name and stays there, because a maintainer who discovers the omission later has no reason to trust the rest of your history. Some words first, because the policies use them. An LLM (large language model) is the model behind your coding agent. A PR (pull request) on GitHub is an MR (merge request) on GitLab, and everything below applies to both. The DCO (developer certificate of origin) is the sign-off line at the bottom of a commit message, and it turns out to be the centre of the whole argument.

Where open source policies on AI code have landed

Projects have settled into four bands. Every example below is dated, because these texts move.

Banned. Gentoo's council voted on 14 April 2024 that it is "expressly forbidden to contribute to Gentoo any content that has been created with the assistance of Natural Language Processing artificial intelligence tools". NetBSD's commit guidelines call output from an LLM "tainted code" that "must not be committed without prior written approval by core". QEMU's code provenance document, as of August 2026, still says the project will "DECLINE any contributions which are believed to include or derive from AI generated content".

Analysis only. Most bans are narrower than the headline. QEMU's document says the policy "does not apply to other uses of AI, such as researching APIs or algorithms, static analysis, or debugging, provided their output is not included in contributions". You may use the agent to read the code. You may not ship what it wrote. That distinction is the working line inside most restrictive projects, and it is the one people miss.

Disclosure required. Fedora's council approved a policy on AI-assisted contributions in October 2025. It allows the tools and puts the weight on the person: the contributor is the author, is fully accountable for the whole contribution, and must disclose when a significant part of it came from a tool without changes. The Linux kernel gained a coding assistants page in its process documentation in December 2025, with a trailer for recording the tool and a hard rule about who may sign off.

Nothing written down. This is still the common case. A preprint from May 2026 surveyed 1,000 popular GitHub repositories and found 118 with any written AI policy. Silence is not permission. Ask in the issue tracker in one sentence before you write the patch, and the answer becomes a public record you can point at later.

Why maintainers wrote these rules

The first reason is review load, and the arithmetic runs one way. An agent produces a plausible 400 line merge request in a minute. Reviewing that request properly costs a maintainer an afternoon, and most maintainers are volunteers. The cost of submitting fell to near zero. The cost of reviewing did not move at all.

curl shows the far end of that curve. Daniel Stenberg reported in mid-2025 that roughly a fifth of the security reports arriving through the project's bug bounty were what he calls AI slop: reports that name real functions and real code paths, describe a plausible attack, and contain nothing. The project ended the bounty in early 2026 rather than keep funding the flood. Those were reports rather than patches, but it is the same mechanism that makes a maintainer open your PR already tired.

GNOME Calendar wrote the problem down as a label. In June 2026 the project introduced "Probabilistically Automated" for merge requests showing "major or total reliance on artificial 'intelligence' to generate code", and named the symptom exactly: "usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code". Read that last phrase twice. The code looks like it should work. Nobody checked whether it does.

The second reason is provenance, meaning where the code came from and under what license. QEMU states the conflict plainly: signing off asserts that you "fully understand the copyright and license status of content" you contribute, and the copyright status of model output is unsettled. Gentoo's council gave the same reason, along with quality and ethics. You do not have to agree with the legal reading. You do have to notice that it is the maintainer's call to make, not yours.

How do I find a project's AI policy?

Look in these places, in this order.

• CONTRIBUTING.md in the repository root, then .github/CONTRIBUTING.md, then any DCO file next to it.
• The developer docs. QEMU keeps its rule in docs/devel/code-provenance.rst. The kernel keeps its in Documentation/process/coding-assistants.rst.
• The project website or wiki. Gentoo's policy lives on the council's wiki page, and NetBSD's lives in the commit guidelines.
• The issue tracker and the mailing list archive. A policy usually exists there for months before anyone writes it into the repository.

From inside a checkout, one grep covers most of it:

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

Then read the project's own history, because the committed convention beats any summary of it:

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

A count next to a trailer value tells you the form this project actually uses. An empty result means nobody has disclosed in that form here, which is information too. If the project lives on GitHub and the workflow itself is new to you, how pull requests and forks work on GitHub covers the mechanics this section assumes.

Disclose in the commit trailer, not in a comment

A trailer is a Key: value line in the last paragraph of a commit message. Git already uses this shape for Signed-off-by: and Co-authored-by:, and tools parse it, so it is the one disclosure that travels with the code into the tree.

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>

The kernel documents that format as Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], and it is explicit about the limit of the line: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." The agent's name goes on Assisted-by. Your name goes on Signed-off-by. Never let a tool write the second one, and never let it invent a Co-authored-by address that belongs to nobody.

Names vary, so copy the local one instead of inventing your own. A patch posted to the QEMU list in May 2026 proposed relaxing that project's ban for mechanical changes, tests, docs and bug fixes of twenty lines or less, recorded with a trailer like AI-used-for: tests, docs. As of August 2026 that is a proposal on a mailing list and the committed document still declines generated content. One project moved its position twice between 2023 and 2026. The next move will not wait for you, which is why the method matters more than the list.

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 needs Git 2.32 or newer. The second command should print the value straight back to you. An empty line means git did not parse the trailer, almost always because a blank line or an ordinary sentence sits inside the trailer block at the bottom of the message. For a series you already wrote, git rebase --signoff origin/main adds the sign-off to every commit, and git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt edits a message file.

Two failure modes are worth planning for. A squash merge rewrites the commit message, so on a project that squashes, repeat the disclosure in the PR description where the maintainer reads it. And a review comment is not a record, because comments can be edited and never land in git history.

Accuracy cuts both ways. Assisted-by on a commit you typed by hand is noise, and it makes your real disclosures worth less. Leaving it off a commit the agent wrote is the thing that ends the relationship.

What does Signed-off-by actually attest?

The DCO is one short text, version 1.1, published at developercertificate.org and used by the kernel, by QEMU and by many others. Adding Signed-off-by: Your Name <you@example.com> says you certify it. Read what you are certifying, because most people sign it without ever reading it.

Clause (a) says the contribution "was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file". Clause (b) covers work based on earlier open source code you have the right to pass on with modifications. Clause (c) covers code handed to you by someone who certified the same thing. Clause (d) says you understand that the contribution and the personal information in your sign-off are public and kept indefinitely.

Notice what is missing. The DCO never says you typed every character. It says you have the right to submit the code under this license. That is why generated code sits awkwardly here: the question is not authorship, it is whether you can account for the origin. Most projects that require sign-off also require a real name, so a pseudonym fails the check. Add the line with git commit -s, which reads user.name and user.email from your git config. When a DCO bot fails your PR and names the commit that lacks the line, git rebase --signoff origin/main and a force push to your branch fixes it.

Signing a commit is not the same as signing off

git commit -s adds a line of text. git commit -S makes a cryptographic signature over the commit object using your GPG or SSH key. They answer different questions. The signature attests that this commit came from the holder of that key and has not been altered since. It says nothing about where the code inside came from, so a signed commit full of undisclosed generated code is signed and still a policy violation. Sign-off is the claim about origin. The signature is the claim about identity. Projects that want both will ask for both.

Never submit code you cannot explain in review

Here is the test, and it is not really about honesty. For every line: what is this for, and what breaks without it? If either answer is missing, the patch is not ready, because the review comment is coming and your answer will be another round of generation. Reviewers can tell. That is the moment a contributor turns into a cost. Ask the same question about the edges, the empty input, the failure path, the second caller.

Run the thing. Build it, run the project's test suite, and write a reproducer for the bug you claim to fix. The kernel documentation gives the honest fallback in plain words: "If the fix could not be built or tested, or if no reproducer could be produced, say so explicitly: maintainers currently waste too much time analyzing unverified reports and untested fixes." Writing "I could not test this on real hardware" costs you nothing. Implying that you did costs you the project.

Answer review comments yourself, in your own words and on your own clock. A reply that lands thirty seconds after the comment and restates it in five paragraphs tells the maintainer exactly what happened. Keep the diff small as well. Forty lines you understand completely are worth more to a project than a four hundred line refactor you supervised.

Keep the agent's instructions in the repo

The instructions you give your agent are part of your toolchain, so treat them like code. A file in the repository root, usually AGENTS.md, holds the build command, the test command, the commit message format, the sign-off requirement and the style rules the project already documents. That file is versioned and reviewable, and it is the same tomorrow as it is today. Instructions retyped from memory each session produce a different patch each session, and you will not know which session produced the patch that got rejected. Writing an AGENTS.md that both an agent and a human can read covers the file itself.

One caution about other people's repositories. Do not make your first contribution a PR that adds an agent instruction file to a project you do not maintain. It reads as an attempt to set the project's tooling policy from outside, and it is a fast way to get your account associated with the thing maintainers are already tired of. Keep the file in your fork until somebody asks for it.

Where you run the agent matters for the same reason. An agent that can build the project and run its tests inside a sandbox you control gives you a patch you have actually verified, which is the difference between disclosing assistance and disclosing a guess. Running a coding agent on your own VPS covers that setup, and the practical differences between Claude Code, Cursor, Codex and Copilot covers how the tools differ day to day.

The method, once the policy changes

1. Find the stated policy before you write anything: repository, developer docs, website, tracker.
2. If there is no policy, ask in the issue in one sentence, and keep the answer.
3. Disclose in the form that project uses, in the commit trailer, and repeat it in the PR body if the project squashes.
4. Sign off with your real name, knowing the line is a claim about your right to submit the code.
5. Review your own patch as if a stranger wrote it, because one did.

Every project named on this page will have moved by the time you read it. The five steps do not move.

FAQ

Do I have to disclose that I used an AI coding agent?

Check the project, because the answer is set locally. Fedora requires disclosure when a significant part of the contribution came from a tool without changes. The Linux kernel asks for an Assisted-by trailer. Gentoo and QEMU, as of August 2026, do not want the contribution at all. Where nothing is written down, disclose anyway in a commit trailer. A maintainer who finds out later reacts to the omission rather than to the tool, and that reaction attaches to everything else you have sent.

Which open source projects ban AI-generated code?

As a snapshot from August 2026: Gentoo since April 2024, NetBSD which treats LLM output as tainted code needing core approval, QEMU which declines contributions derived from generated content, and several GNOME applications including Loupe and Calendar. Read each project's own text rather than this list, because it will age. Note the exemption most of them share: using a model to research an API, run static analysis or help you debug is usually fine, as long as its output is not in the patch.

What is the difference between Signed-off-by and a signed commit?

Signed-off-by is a plain text line added by git commit -s. It certifies the developer certificate of origin, meaning you have the right to submit this code under the project's license. A signed commit, made with git commit -S, is a cryptographic signature over the commit object with your GPG or SSH key. It proves the commit came from your key and was not altered. Origin and identity are separate claims, so a signed commit can still break an AI policy.

Can I put the disclosure in the pull request description instead of the commit message?

Put it in the commit message, since that is the record that lands in git history and travels with the code to anyone who clones the repository later. A pull request description can be edited afterwards and lives on the hosting platform. Add it to the PR body as well when the project squash merges, because a squash rewrites your commit message and can drop the trailer.

My pull request was closed because it was AI-generated. What now?

Do not argue the policy in the thread, because the person closing it did not write the rule alone and the thread is not where it changes. Read the policy text, then decide whether you can meet it. Where the project bans generated patches, a clear bug report with a reproducer and no patch is still welcome, and it is often the more useful contribution. If you come back with code, come back with a small change you can defend line by line, and say what you did differently this time.