A project maintainer opens a pull request and sees a patch that is plausible, poorly tested, and difficult to review. The contributor says an AI coding tool helped. What should happen next: reject the patch because AI was involved, ask for more evidence, or review it under the same quality bar as any other contribution?
That question moved beyond code review on October 24, when moderators of Reddit's r/opensource announced that projects using AI, made with AI, or intended for AI would not be welcome. The same rule update added age, maintenance, contributor-count, and account-history requirements. It also rejected AI-translated submissions on the grounds that moderators could not reliably distinguish them from AI-written text. The October 24 announcement's restrictions were a community moderation policy, not a new definition of open-source software. In follow-up comments reported on October 26, the moderator acknowledged there was no objective way to implement the policy and said adjustments would be made. That makes the announcement a moving moderation decision, not a settled standard; check the original thread for any later revisions. Coverage of the announcement and response describes the backlash and the rules' broad reach.
There is a useful distinction underneath the argument: a forum deciding what it will promote is solving a different problem from a software project deciding how to accept contributions. The first needs a moderation rule that volunteers can apply quickly. The second needs a review process that protects code quality, licensing, security, and maintainer time.
Disclosure: This is a source-based comparison of public policies and research, not a report from a maintainer's firsthand experience. The examples below are specific policies, not universal prescriptions.
First separate “open source” from “made with AI”
The Open Source Initiative's Open Source Definition sets conditions for software licenses and the rights those licenses grant. Those criteria include free redistribution, access to source code, permission to create derived works, and no discrimination against fields of endeavor. They do not prescribe whether a person may use a compiler, an IDE, autocomplete, translation software, or an AI assistant while creating the software. The OSI's definition is about license terms, not a declaration that every project or contribution must be created in a particular way.
A project can therefore be open source under its license and still choose not to accept AI-generated patches. A forum can decide not to promote AI-focused projects without changing the license on those projects. Those decisions may be criticized as restrictive or exclusionary, but they operate at different layers.
That distinction matters because debates often slide between three questions:
- License: May users inspect, modify, and redistribute this software under the project's license?
- Contribution process: What evidence and review must a patch meet before maintainers accept it?
- Community scope: What projects, posts, or people will a forum choose to host or promote?
A clear policy names which of these it governs. A vague sentence such as “no AI in open source” can be read as a rule about code, contributors, project features, discussion, translation, or all of them at once.
Option one: a broad ban
A broad ban is easy to state and can be easy to enforce when the boundary is visible. A community that wants to focus on human-created projects can prohibit AI-generated submissions outright. A project with strict legal or provenance requirements might also choose to refuse a category of generated contributions.
The attraction is operational. Moderators do not need to evaluate the quality of every AI-assisted submission if the presence of AI is itself disqualifying. For a high-volume forum facing spam, this may reduce the amount of material volunteers have to inspect. A rule can also communicate a deliberate community identity rather than treating every new technology as an automatic fit.
But a ban has a classification problem. What counts as “using AI”? Does it include generated code, a suggested line accepted after review, a documentation draft, bug analysis, a spelling correction, translation, or a project feature that calls an AI service? If moderators cannot answer consistently, the rule may be clear in tone but subjective in application.
The r/opensource rules illustrate how far a scope can spread. Its October announcement addressed not only AI-made projects but projects that use AI or are intended for AI. The update also required promoted projects to meet age and contributor thresholds, among other criteria. Reporting described concerns from solo maintainers and non-English speakers who could be excluded even when the central issue was not low-quality generated code. A community can choose those limits, but it should name the trade-off: fewer borderline submissions may also mean fewer legitimate projects and contributors.
A broad ban is most defensible when the actual goal is categorical exclusion and the community is willing to accept its false positives. It is less defensible when the stated problem is low-quality contributions but the rule penalizes contributors based on an invisible tool-use boundary.
Option two: allow AI with conditions
A contribution policy can permit AI assistance while making a human contributor responsible for the result. The GNU Compiler Collection's published policy is a concrete example of a narrower approach. GCC currently declines legally significant contributions that include or derive from LLM-generated content, while maintainers may accept clearly marked, legally insignificant generated contributions and may accept generated test cases as an exception. Its policy also requires a human submitter who understands the changes and can answer questions. Only a human may provide the Signed-off-by certification. GCC's AI policy distinguishes contribution categories instead of treating every use of AI as identical.
This is not a universal middle ground. GCC makes a project-specific legal distinction that other projects may not be able or willing to apply. Its page says the policy will be reviewed no later than the start of 2027. The useful design lesson is not to copy its exact categories blindly. It is to specify what is restricted, what is allowed, who decides, and what the contributor remains accountable for.
A September 2026 study of 281 AI contribution policies in popular open-source projects found that 83.3% permitted or encouraged AI use in code contributions. That permission commonly came with conditions: 67.3% called for substantial human involvement, and 43.4% assigned accountability. The researchers also found that disclosure requirements varied, and that half of the 92 dedicated policy files they tracked had been revised after creation. The study's abstract and full text report that conditional permission is common, while policies are still evolving.
Those numbers describe the policies the researchers examined. They do not prove that permissive rules produce better code, that bans fail, or that the same percentages apply to every project. They do challenge the idea that open-source maintainers have settled on one common AI rule.
Compare the policies by the problem they solve
Instead of asking whether a ban or permission is morally correct in the abstract, ask which problem your rule is meant to reduce.
- If the problem is reviewer overload: set expectations for patch size, tests, reproduction steps, and contributor responsiveness. A ban may reduce volume, but it does not establish that a human-written patch is easy to review.
- If the problem is licensing uncertainty: specify what contributors must attest to and which kinds of generated material are not acceptable. “AI used” alone may not describe the source or rights issue you need to evaluate.
- If the problem is security or correctness: require tests, threat analysis, or maintainer review proportional to the risk. Tool provenance does not replace evidence that a patch behaves safely.
- If the problem is spam: rate limits, issue templates, prior discussion, and limits on concurrent submissions can target the behavior directly. Those controls may be less disruptive to experienced contributors than a blanket exclusion.
- If the problem is community identity: say that the community is choosing not to host AI-related projects, then be candid that the policy is about scope, not a general claim that such projects are not open source.
A rule that targets the actual cost is easier to explain and revise. A rule that treats “AI” as a proxy for slop risks missing low-quality human work while rejecting careful, reviewable AI-assisted work.
A practical policy design for maintainers
A maintainable AI policy can fit in a short section of CONTRIBUTING.md. It does not need to predict every tool or model. It needs to give contributors and reviewers a shared process.
1. Define where the rule applies. State whether it covers code contributions, documentation, issue reports, project features, or posts in a related community. Separate an AI-powered product from a contribution created with an AI assistant. If translation or accessibility tools are covered, say so explicitly and explain why.
2. Name allowed and restricted work. Avoid “AI is allowed” or “AI is banned” without examples. A project might allow research and debugging assistance but restrict generated text included verbatim in a patch. Another might permit generated tests while requiring extra review for production code. The policy should describe its actual categories rather than imply a boundary maintainers cannot observe.
3. Put responsibility on the submitter. Require the human contributor to understand the patch, explain its behavior, and respond to review. A person should not be able to transfer responsibility to an assistant or claim that a tool's output is self-validating. GCC's human-submitter and human-signoff rules provide one published example of this principle.
4. Ask for useful disclosure, not a ritual. If disclosure helps reviewers, say what information is useful and where to put it. For example: which parts were materially generated, what checks the contributor performed, and whether generated content was copied into the patch. Avoid collecting details that do not change review. A binary “used AI: yes/no” can hide more than it reveals when the tool helped with a typo or drafted an entire implementation.
5. Tie scrutiny to risk and evidence. Ask for tests, expected behavior, reproduction steps, or security analysis that fit the change. Keep ordinary quality requirements applicable to all submissions. If certain generated content is disallowed for legal reasons, define that boundary separately from quality review.
6. Make enforcement predictable. Explain whether moderators will remove a post, ask for edits, close a patch, or restrict repeat abuse. Provide an appeal or correction path where feasible. Policies that depend on “obvious AI” should acknowledge that this is a subjective signal, not a reliable detector.
7. Review the policy itself. Record an owner and a review date. The policies are changing quickly, and the 2026 survey found that many dedicated AI policy files had already been revised. A dated review is better than letting a temporary response become invisible permanent governance.
A short policy skeleton
The following is a starting point, not legal advice or a drop-in rule for every repository:
AI assistance is [allowed / limited / not accepted] for [specific contribution types].
Every submission must meet the project's normal requirements for correctness,
security, licensing, tests, and review. The human submitter is responsible for
understanding the change and answering questions about it.
For [specified generated content], include [the disclosure or evidence reviewers need]
in [the pull request or commit message]. Do not submit [clearly defined prohibited work].
Maintainers may request additional evidence, close submissions that do not meet
these requirements, and revise this policy after review on [date or cadence].
Fill in the brackets with project-specific decisions. If maintainers cannot reliably determine whether a rule was followed, consider whether the requirement should be reframed around observable evidence and contributor responsibility.
The decision is not “AI or open source”
A forum may choose strict limits to protect its volunteers from a flood of low-effort posts. A source-code project may draw narrower boundaries around legally significant material, require human accountability, and review each patch on its merits. A project may also ban AI-assisted contributions for its own reasons. None of those choices alone changes what its license permits users to do with released code.
The practical question for maintainers is more precise: What behavior is consuming trust or review capacity, and what evidence would show that a contribution meets the project's bar? If the answer is “we do not want AI-related projects in this community,” write a scope rule. If the answer is “we cannot safely review generated patches,” specify the checks and responsibilities that make review possible, or define the exact content you will not accept.
A policy is useful when contributors can follow it, reviewers can apply it consistently, and maintainers can revise it when it fails. That is a better standard than trying to win a broad argument about whether AI belongs in open source.
Save-worthy maintainer checklist:
- Define whether the policy covers licenses, contributions, or community submissions.
- Distinguish AI features from AI-assisted development.
- State what is allowed, restricted, and prohibited with examples.
- Keep a human contributor responsible for the change.
- Request disclosures only when they help review.
- Apply tests and scrutiny in proportion to risk.
- Explain enforcement, exceptions, and how the policy will be reviewed.
I write about practical software engineering, developer tools, and AI. Subscribe for more source-based guides. How does your project handle AI-assisted contributions: a ban, disclosure, or review based on the patch? What has worked for your maintainers?
Top comments (0)