I Read the AI Policies of 120 Open Source Projects. Here Is What They Actually Say. · Rakshit Yadav · Medium, August 22, 2026
Someone read 120 open source AI policies. 37 ban AI-assisted contributions outright
Yadav counted every project with a written, published policy, working from the public catalogue at melissawm/open-source-ai-contribution-policies, and read them in August 2026. The split: 72 allow AI assistance with conditions, 37 ban it outright, 11 have live arguments and no settled policy. The permissive camp includes Python, NumPy, Django, Kubernetes, the Linux kernel, curl and PyTorch. The banning camp includes Zig, QEMU, GIMP, Gentoo, Servo, Alacritty, SDL, OpenJDK, Asahi Linux and Clojure.
The bans are mostly about legal provenance, not taste. QEMU's code provenance policy states it plainly: "Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content." The reasoning Yadav reports is that the copyright status of generated output is unsettled, training data may include incompatibly licensed code, and a contributor therefore cannot honestly certify the DCO. The kernel documentation makes the same point as a hard rule: AI agents must not add Signed-off-by tags, because only humans can legally certify the DCO.
Permission comes with a format, and the format is per project. Kubernetes wants Assisted-by: and specifically does not want Co-developed-by:. The kernel wants the model version, as Assisted-by: AGENT_NAME:MODEL_VERSION. Several projects reject naming the tool in Co-authored-by: at all. The per-project rules get more specific from there. LLVM and qutip forbid AI on "good first issue" tickets, because those exist as learning opportunities. Homebrew allows one AI-assisted pull request open at a time. NetBSD requires core team approval before generated code enters the tree. Django asks contributors not to point automated AI reviews at other people's pull requests. curl's line is the sharpest of them: "A basic rule of thumb is that if someone can spot that the contribution was made with the help of AI, you have more work to do."
Two limits on this count. Yadav is a writer working from a public catalogue rather than a maintainer reporting his own project, though the catalogue is public and a skeptical reader can recount it. And the figures move: he places GCC among the projects still deciding, while Otto Kekäläinen's essay six days later lists GCC among those rejecting all AI-assisted contributions. Yadav's own advice is to check the catalogue on the day you submit rather than trust any blog post, including his.
Why it matters: The DCO rule is a hard constraint that does not change with model capability. A pipeline that generates a patch, opens the pull request and signs it off has no compliant form in the permissive majority, let alone the 37. Somebody has to read the patch and put their name on it, which means the last step of an upstream contribution loop cannot be unattended by policy, not merely by preference. Trailer formats add another cost: "disclose" is not one behavior, it is a per-project string, and getting it wrong is how a good patch gets closed.