When you use AI to fix a long-standing bug in an open-source library, pass all local tests, and prepare to submit a pull request (PR) upstream, you may encounter a new kind of experience. In the past, maintainers typically only cared about whether the code worked and whether the tests were thorough. Now, however, when you submit code, the system may first show you a prompt asking you to make several explicit disclosures and declarations.
Maintainers need you to explain in detail: where exactly was AI used? Have you understood the logic of every line? Are you willing to take responsibility for any issues that may arise later? This is not some open-source project going out of its way to make things difficult. Behind these changes, the trust rules of the entire open-source world are quietly being reshaped.
Some see this as the open-source community resisting new technology, but in reality they are protecting an accountable contribution chain. The open-source community has begun rejecting code that no one is responsible for, even if that code was generated by AI. What a project accepts has never been just a diff — it is a clear and traceable contribution chain: who wrote it, who understands it, who has the right to submit, who can respond to routine reviews, and who will be accountable for future bugs, copyright issues, and maintenance costs. AI lowers the barrier to producing code, but it also makes this kind of accountability scarce, forcing open-source projects to tighten the entry point for responsibility.
To protect the fragile chain of accountability, some open-source communities have adopted strict restrictions. In the Zig Code of Conduct, the official policy lays out a highly binding AI ban. Zig not only prohibits submitting AI-generated code, but also bans using large language models for translation, polishing text, writing documentation, and even vulnerability discovery or brainstorming. Under this environment, AI-generated auto-replies in communities and forums are likewise considered violations.
This decision is grounded in the project’s long-term development, not a mere rejection of technology. Maintainers are unwilling to serve as unpaid testers for cheaply generated automated code, and they prefer to discover and cultivate developers through code review. Every code review is a deep conversation — maintainers use it to assess the contributor’s understanding and confirm whether they have grasped the project’s core design philosophy. If all submissions are done by models, with humans serving only as messengers, maintainers cannot evaluate the contributor’s true ability, and the project will lose its capacity for self-sustaining growth.
There are also communities that, instead of an outright blockade, seek a balance between humans and tools. The Godot Pull Request Guidelines demonstrate a moderate and pragmatic approach. While the project does not encourage AI-assisted contributions and will outright reject pull requests that are entirely auto-generated by models, if a developer merely uses AI to aid their thinking and has done thorough proofreading and improvement before submission, the project will still accept the contribution — provided the disclosure is honest at the time of submission.
To dispel developers’ concerns, Godot even explicitly states that everyday single-line code completions or pure translation tools are not within the scope of the restriction. This mechanism shows that the community does not have a purist objection to tools — they support compliant use of development tools, but the bottom line is that a specific contributor must stand up and take responsibility for every line of code submitted.
For some low-level system projects, the defensive posture against AI code is extremely tight, with core concerns centered on security and copyright. The Gentoo Council AI policy explicitly prohibits contributing content created with the assistance of large language models. Model-generated code is like a black box, lacking sufficient explainability, and the complex provenance of training data makes copyright and compliance disputes highly likely.
The virtualization low-level project QEMU stipulates in its QEMU Code provenance that any content determined to be AI-generated or AI-derived shall be rejected outright. They require that code have clear provenance, to avoid bringing future legal risks to the community due to ambiguous intellectual property backgrounds. The browser engine Servo AI contributions policy likewise chooses to keep AI-written code, issue reports, and discussions out, because for infrastructure projects with extremely low fault tolerance, any hidden risks can lead to severe consequences.
In mid-tier ecosystems such as data science and web development, NumPy, pandas, and Django bind responsibility through more granular disclosure mechanisms. Under the NumPy AI Policy, developers may introduce AI assistants into their workflow, but must explain in detail which parts used the tool in the commit description. Any attempt to conceal the traces of usage, once discovered, will result in outright rejection by the project team. The pandas automated contributions policy emphasizes the value of human correction, accepting only logic that has been rewritten, tested, and verified by humans. AI can generate a first draft, but the final submitted content must be deeply confirmed by a human.
Django AI-assisted contributions goes a step further by drawing an additional line of defense. Django allows AI-assisted code writing with honest disclosure, but absolutely prohibits using AI tools to automatically review pull requests. From the maintainers’ perspective, auto-generated review comments often contain substantial noise and hallucinations, which greatly consume maintainers’ limited energy. Therefore, the power to guard the gates must remain firmly in human hands.
Facing more complex commercial and technical ecosystems, top open-source foundations and mega infrastructure projects choose mature institutions to anchor legal and quality accountability to individuals. The Apache Software Foundation (ASF), in its ASF Generative Tooling Guidance, provides systematic guidelines. It avoids a blunt one-size-fits-all approach, focusing instead on tool terms of service, third-party material compliance, and open-source license compatibility. It recommends that developers contribute under these compliance conditions and use markers to indicate provenance.
The Linux kernel, as the cornerstone of the open-source world,
demonstrates an even purer contractual spirit. In the Linux
kernel AI Coding Assistants guide, the kernel community explicitly
states that it does not restrict which AI coding assistants developers
may use, but it firmly insists on the Developer Certificate of Origin
(DCO) as a non-negotiable bottom line. Anyone submitting a patch to the
kernel must attach a Signed-off-by signature. This
signature is not merely a technical marker — it is a solemn legal
declaration, representing that the submitter assumes full responsibility
for the code’s copyright and quality.
Since AI assistants are not legal entities and cannot assume responsibility, they must never sign off in the kernel. This means that all potential infringement risks, security vulnerabilities, and maintenance costs must ultimately be attributed to a specific natural person. It is by virtue of this robust chain of accountability that the Linux kernel can ensure the security and compliance of a massive project without rejecting AI tools outright.
This wave of rule reshaping sends a clear signal to all developers and engineering teams. Developers accustomed to quickly writing code with AI locally, passing tests, and submitting directly will need to adjust their work habits. In future open-source collaboration, what developers submit is not just working code, but also a weighty credential of responsibility. Before hitting send, we need to have thorough test records ready, clearly write out the detailed rationale for our changes, honestly disclose the traces of AI usage, and demonstrate our ability to consistently respond to reviews.
Large language models have indeed liberated productivity, capable of filling your editor at extremely low cost. But they can never sign on a contribution certificate, nor can they be held accountable for how the code performs afterwards. Delegate code generation to the tools, but keep the responsibility for the code with yourself. AI can write every line of code, but the one who can truly make a promise to the community and bear the consequences will always be the person in front of the screen.