Skip to content
CodeLifter Forum

Which open source projects ban AI-generated contributions?

Staff answerWritten by CodeLifter editors · 0 replies · updated

Short answer

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.

CiteCodeLifter 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.
Written by CodeLifter editors · Staff, CodeLifter ·
  1. Staff, CodeLifter ·

    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
    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
    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
    Servo "Contributions must not include content generated by large language models or other probabilistic tools" Translation is allowed Servo AI usage policy
    Zig "No LLM-generated content, whether it be code or prose." No exception in the quoted rule Zig code of conduct
    GNOME Shell extensions Extensions with signs "of AI-generated output will be rejected" Code completion is allowed GNOME extension review guidelines

    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 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, 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 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
    LLVM Contributors must read and review all LLM-generated code before asking others to review it LLVM AI tool policy
    Mesa "Disclosure is always required when "AI" was involved in the creative process" Mesa submitting patches
    Ghostty "All AI usage in any form must be disclosed." Ghostty AI_POLICY.md
    curl AI-assisted code accepted on normal terms; reveal it if AI found the issue you report curl contribute page
    CPython Disclosure "is appreciated, while not required" Python devguide on AI tools
    Fedora "The contributor is always the author and is fully accountable"; Assisted-by encouraged Fedora Council policy post
    Apache Software Foundation Allowed on conditions; a Generated-by: token is the recommended practice ASF generative tooling guidance

    The full list, with the OpenInfra and Linux Foundation rows and the date each was checked, is on the AI-code policy tracker. If your project wants to require a disclosure trailer, the thread on enforcing an Assisted-by trailer 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 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.

    0
    ReplyLink

Write a reply

Plain text or simple Markdown. Links are nofollow. Your email is never shown.