Do open source projects allow AI-generated code contributions?

The short version

There is no community-wide rule, and there is no body that could issue one. Open source projects are independently governed, so each sets its own policy. What exists instead is a spread of positions that currently runs from an explicit ban through mandatory disclosure to explicit permission with responsibility attached.

That means the question you actually need to answer is never do open source projects allow this, but does this project allow this, and the answer lives in that project's contributing documentation.

Four real policies, and what each one actually says

Debian: permitted with full contributor responsibility. Debian's general resolution on LLM usage ran from 2026-08-15 to 2026-08-28 and the winning option was Responsible Use of Generative AI. The adopted text says Debian neither endorses nor prohibits the use of generative AI tools, and that all contributions must satisfy the same standards of quality, correctness, maintainability, and legal compliance regardless of how they were produced. It states plainly that using a generative AI tool does not diminish the contributor's responsibility, that contributors are expected to understand, review, test, and where appropriate modify AI-assisted output, and that blindly accepting or uploading AI-generated material without human review is inconsistent with Debian's practices. On disclosure it encourages but does not require it. The text also explicitly declines to take a position on whether AI output is copyrightable.

Gentoo: forbidden. The Gentoo Council voted on 2024-04-14 that it is expressly forbidden to contribute to Gentoo any content created with the assistance of natural language processing AI tools. The policy states it can be revisited if a case is made for a tool that does not raise copyright, ethical, and quality concerns, and it applies to contributions and official Gentoo projects. It does not prohibit packaging AI-related software, which is a distinction people frequently get wrong.

curl: disclosure required for security reports, code accepted on merit. curl's contributing documentation says that if you asked an AI tool to find problems in curl you must reveal that in your report, and that you must verify the findings yourself first because AI-based tools frequently generate inaccurate or fabricated results. For code, curl says it can accept code written with AI help provided it follows coding standards, is documented, has test cases, and meets all the project's normal requirements. It also offers a blunt heuristic: if someone can spot that the contribution was made with AI help, there is more work to do.

QEMU: provenance must be declared. QEMU's code-provenance documentation predates the current wave of policies and approaches the problem through generated files rather than AI specifically. Patches are expected in the preferred format for making modifications; where generated files are permitted, their existence must be acknowledged and justified in the commit that introduces them, and automated manipulation of code should be declared in the commit message.

The pattern underneath the disagreement

The projects that permit AI assistance and the projects that ban it are largely worried about the same three things: licensing and copyright provenance of the generated output, code quality and maintainability, and the reviewer time consumed by low-effort submissions.

They differ on whether those risks are better handled by a rule or by responsibility. Debian's answer is responsibility: the tool is irrelevant, the contributor owns the result. Gentoo's answer is a rule, on the stated grounds that the copyright position is unsettled and that accepting such material could weaken the project's own copyright claims. Both are coherent responses to the same uncertainty, which is why you cannot generalise from one project to another.

It is also worth separating two complaints that often get merged. Volume-based objections, of the kind visible in the maintainer commentary circulating this week about projects being flooded with low-quality contributions, are about reviewer burden and effort asymmetry. Provenance-based objections are about copyright and licensing. A project can care a lot about one and little about the other, and its policy will look different depending on which.

What to do before you open a pull request

Read the project's CONTRIBUTING file, its developer documentation, and its code of conduct, and search those documents for AI, LLM, and generated. If a policy exists, it is usually in one of those places.

If you find no policy, do not read silence as permission to skip review. The baseline expectation in every policy surveyed here is that you understand the code you are submitting and can defend it in review. If you cannot explain why a change is correct, it is not ready regardless of who or what wrote it.

When a project requires disclosure, disclose. When it merely encourages disclosure, disclosing is still the lower-risk choice: it costs a sentence and it prevents a maintainer discovering it later, which is a much worse conversation.

For security reports specifically, treat unverified AI output as unpublishable. curl's documentation is explicit that fabricated security reports consume maintainer time on a priority path and are actively harmful. Reproduce the issue yourself and write the report in your own words.

If you are contributing on behalf of an employer, check your internal policy too. Your obligations to the project and to your employer are separate, and satisfying one does not satisfy the other.

If you maintain a project

Write the policy down, even if the policy is that you have not decided yet. Every project surveyed here made review easier by publishing a position, because it converts an argument in a pull request thread into a link.

Decide separately what you require and what you merely prefer, and say which is which. Debian's text is a useful model precisely because it is explicit that disclosure is encouraged rather than required, so nobody has to guess.

Be specific about scope. Gentoo's policy is clearer than most because it states what it does not cover, namely packaging AI-related software and software developed with such tools upstream. Ambiguity about scope is where policies generate disputes.

Limits of this answer

The five policies described here were read on 2026-08-29 at the URLs cited. They are a deliberately varied sample, not a survey, and they cannot tell you what any other project requires. Policies in this area are being actively revised, so check the current text rather than relying on this article.

This article does not take a position on whether AI-generated code is copyrightable. Debian's adopted text explicitly declines to resolve that question, courts and legislatures across jurisdictions have not settled it, and it would be irresponsible to assert a conclusion here. If your situation turns on that question, it is a legal question and needs a lawyer, not a blog post.

The article also makes no claim about how well any of these policies are enforced in practice. Every project surveyed acknowledges, directly or indirectly, that AI assistance is difficult to detect reliably.

A useful next action

Pick the project you contribute to most often and search its contributing documentation for the words AI, LLM, and generated right now. If a policy exists, you will know your obligations in under a minute. If none exists and you contribute regularly, that is a reasonable and genuinely useful issue to open with the maintainers.