# Which open source projects ban AI-generated contributions?

Source: https://forum.codelifter.com/posts/which-open-source-projects-ban-ai-generated-contributions/
Site: CodeLifter Forum, category AI code policies
Published: 2026-10-16. Updated: 2026-10-16. Replies: 0.

## Question by CodeLifter editors (staff), 2026-10-16

Six projects in the CodeLifter tracker had a written ban when it was last checked on 15 October 2026: Gentoo, NetBSD, QEMU, Servo, Zig and the GNOME Shell extensions review. Most others, including the Linux kernel, LLVM, Mesa and Fedora, accept AI help with disclosure or other conditions. Always read the current policy page before you send anything.

## The projects with a written ban

A ban here means the project's own policy page says AI-generated content will be refused or needs special approval. Each row quotes the page it comes from. The wording matters, because several bans carve out uses that do not end up in the patch.

| Project | What the policy says | What is still allowed | Source |
| --- | --- | --- | --- |
| Gentoo | "It is expressly forbidden to contribute to Gentoo any content that has been created with the assistance of Natural Language Processing artificial intelligence tools." Council vote of 14 April 2024 | No exception in the quoted rule | [Gentoo Council AI policy](https://wiki.gentoo.org/wiki/Project:Council/AI_policy) |
| NetBSD | Code generated by such tools "is presumed to be tainted code, and must not be committed without prior written approval by core" | Commit with written approval from core | [NetBSD commit guidelines](https://www.netbsd.org/developers/commit-guidelines.html) |
| QEMU | Will "DECLINE any contributions which are believed to include or derive from AI generated content" | Researching APIs or algorithms, static analysis and debugging, as long as the output is not in the contribution | [QEMU code provenance](https://www.qemu.org/docs/master/devel/code-provenance.html) |
| Servo | "Contributions must not include content generated by large language models or other probabilistic tools" | Translation is allowed | [Servo AI usage policy](https://book.servo.org/policy/ai-usage.html) |
| Zig | "No LLM-generated content, whether it be code or prose." | No exception in the quoted rule | [Zig code of conduct](https://ziglang.org/code-of-conduct/) |
| GNOME Shell extensions | Extensions with signs "of AI-generated output will be rejected" | Code completion is allowed | [GNOME extension review guidelines](https://gjs.guide/extensions/review-guidelines/review-guidelines.html) |

Two points are easy to miss. First, the GNOME rule applies to extensions submitted for review on the extensions site, not to GNOME as a whole. Second, QEMU says it will decline a contribution "if use of AI is either known or suspected", so a patch can be refused on suspicion alone. If you ever end up arguing about a flag, the thread on [a detector flagging code written in 2019](/posts/a-detector-flagged-code-written-in-2019-as-ai-what-now/) covers what a detector can and cannot show.

## Why these projects say no

The reason given most clearly is legal, not about code quality. QEMU requires every patch to carry a `Signed-off-by:` line under the [Developer's Certificate of Origin](https://developercertificate.org), which asks you to certify that you have the right to submit the work under the project's licence. The QEMU page explains that "the copyright and license status of the output is ill-defined" for AI content generators, and that it "is not willing or able to accept the legal risks of non-compliance." It also says the policy "may evolve as AI tools mature and the legal situation is clarified", and that exceptions can be proposed on the qemu-devel mailing list.

NetBSD uses the same idea in its own words ("tainted code"). The other bans do not all explain their reasons on the policy page, so do not assume one project's reasoning applies to another. The CodeLifter desk article on [who owns AI-generated code](https://codelifter.com/provenance/who-owns-ai-generated-code/) covers the copyright side in more depth.

## Projects that allow it, with conditions

Most projects in the tracker do not ban AI help. They ask you to disclose it, review it yourself, or both.

| Project | Rule in one line | Source |
| --- | --- | --- |
| Linux kernel | Add an `Assisted-by` tag; "AI agents MUST NOT add Signed-off-by tags" | [Kernel coding assistants guide](https://docs.kernel.org/process/coding-assistants.html) |
| LLVM | Contributors must read and review all LLM-generated code before asking others to review it | [LLVM AI tool policy](https://llvm.org/docs/AIToolPolicy.html) |
| Mesa | "Disclosure is always required when \"AI\" was involved in the creative process" | [Mesa submitting patches](https://docs.mesa3d.org/submittingpatches.html) |
| Ghostty | "All AI usage in any form must be disclosed." | [Ghostty AI_POLICY.md](https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md) |
| curl | AI-assisted code accepted on normal terms; reveal it if AI found the issue you report | [curl contribute page](https://curl.se/dev/contribute.html) |
| CPython | Disclosure "is appreciated, while not required" | [Python devguide on AI tools](https://devguide.python.org/getting-started/ai-tools/) |
| Fedora | "The contributor is always the author and is fully accountable"; `Assisted-by` encouraged | [Fedora Council policy post](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/) |
| Apache Software Foundation | Allowed on conditions; a `Generated-by:` token is the recommended practice | [ASF generative tooling guidance](https://www.apache.org/legal/generative-tooling.html) |

The full list, with the OpenInfra and Linux Foundation rows and the date each was checked, is on the [AI-code policy tracker](https://codelifter.com/provenance/ai-code-policy-tracker/). If your project wants to require a disclosure trailer, the thread on [enforcing an Assisted-by trailer](/posts/how-can-a-team-enforce-an-assisted-by-trailer-on-commits/) shows how teams check for it.

## How to check a project before you contribute

Policies change, and a list like this one goes stale. Check the project itself each time.

1. Open the repository root and look for a file named `AI_POLICY.md`, `CONTRIBUTING.md` or `CODE_OF_CONDUCT.md`. Ghostty, for example, keeps its rule in `AI_POLICY.md`.
2. Search the developer documentation for "AI", "LLM", "generated" and "provenance". QEMU's rule sits on a page called Code provenance, not on its contributing page.
3. Read the sign-off rules. If the project uses the Developer's Certificate of Origin, your `Signed-off-by:` line is a personal statement about where the code came from, whatever the AI policy says.
4. Note any carve-outs. Research, debugging, translation and code completion are allowed by some of the projects that otherwise ban AI content.
5. If the page is unclear, ask on the project's mailing list or issue tracker before you send the patch, not after it is rejected.
6. Keep a note of the page URL and the date you read it, along with what you used. The thread on [what a provenance record should include](/posts/what-should-a-provenance-record-for-copied-code-include/) has a format.

## What this list does not tell you

It does not tell you how maintainers decide that a patch was AI-written; the rules quoted here do not describe a detection method. It does not cover workplace rules, which are set separately and can differ from any open source policy. And it reflects pages read on 15 October 2026. If a project has changed its policy since then, its own page wins over anything here.

---
Cite as: CodeLifter Forum, "Which open source projects ban AI-generated contributions?", https://forum.codelifter.com/posts/which-open-source-projects-ban-ai-generated-contributions/, accessed 2026-10-16.