I’m maintaining an open source project and recently got a pull request with AI-generated code. The code works, but I’m unsure about licensing, code ownership, security risks, and whether accepting it could create problems for the project later. I need help understanding best practices for reviewing and allowing AI-generated contributions in open source projects.
Yes, but only with rules.
What matters is not ‘AI wrote it’. What matters is license, provenance, review quality, and maintainer burden.
I’d set a policy like this:
-
Require disclosure.
If a contributor used AI, they say so in the PR. Short note. Which tool, what parts. -
Require human sign-off.
The submitter states they reviewed the code, tested it, and have rights to submit it under your project license. -
Review it like untrusted code.
AI code often passes tests and still hides bad auth checks, weak input validation, race bugs, and copied snippets. Treat it like code from a stranger on the internet, becuase it is. -
Check license risk.
This is the messy part. Some AI tools have terms that assign output rights broadly. Some do not give clean indemnity. If your project is risk-sensitive, reject code from tools with unclear terms. Keep a short allowlist. -
Ask for provenance on non-trivial PRs.
If the PR is big, ask for design notes, links to docs used, and why the code is correct. If they cannot explain it, reject it. -
Add DCO or CLA coverage.
Make sure your normal contribution gate still applies. AI use should not bypass ownership attestations. -
Prefer small PRs.
Small diffs are easier to audit. Huge AI dumps are where maintainers get burned.
Example policy line:
‘AI-assisted contributions are allowed if disclosed, reviewed by the contributor, submitted under the project license, and accepted after normal maintainer review.’
If you want the low-drama path, accept AI-assisted code only when the contributor owns the submission, the tool terms are acceptable, and your review finds no red flags. If any of those are fuzzy, say no. That saves time later, and fewer headahces.
I’d allow it, but I would not treat “AI-generated” as just another boring implementation detail.
Where I slightly disagree with @hoshikuzu is this: disclosure alone is not enough if your project is widely used or security-sensitive. A contributor can honestly say “yes I used AI” and still dump a pile of code they barely understand. That’s the real danger to me, more than the robot co-author drama.
My rule would be: accept AI-assisted code only if the PR is explainable and maintainable by the human submitting it. If they can’t answer basic questions about edge cases, failure modes, portability, or why a certain approach was chosen, then the code is not ready. Doesn’t matter if it passes tests today.
Also, think about project culture. If you allow giant AI PRs, you may accidentally turn maintainers into cleanup staff. That burns people out fast. I’d be stricter on volume than on tool usage. Ten small, reviewed commits are way safer than one 2,000-line “it works lol” drop.
On licensing, if you’re worried, the simplest answer is boring but effective: document a policy and reserve the right to reject contributions with unclear provenance. You do not need to solve the entire legal status of AI output for the whole internet before merging one PR.
So yeah, allowed? Sure. Automatically welcomed? Nope. If the contributor can’t own it, explain it, and maintain it, I wouldn’t merge it. That’s true for human-written code too, tbh.
I’d split this into two separate questions: can you accept it, and do you want to normalize it in your project.
I mostly agree with @hoshikuzu that process matters more than ideology, but I’m a bit less relaxed on the copyright side. Not because every AI PR is poison, but because open source maintainers are the ones left holding the bag if provenance gets fuzzy later. If your project has commercial users, distro packaging, or corporate adopters, that uncertainty can become their problem too.
My take: allow AI-assisted contributions only under the same contributor certification you already use, but make the contributor explicitly confirm two things:
- they have the right to submit the code under your project license
- they reviewed and tested it enough to stand behind it as their own contribution
That matters because the legal issue is not just “was AI used?” but “who is actually making the licensing grant to the project?”
I would also add a practical filter that is separate from code quality: reject PRs that have unclear origin history. If someone says “I pasted a bug report into a model and it gave me this file,” that is weaker than “I used AI to draft this function, then rewrote and integrated it.” Same output quality maybe, different risk profile.
Pros for allowing it:
- faster fixes and docs
- easier onboarding for newer contributors
- more test scaffolding and refactoring help
Cons:
- provenance uncertainty
- shallow understanding from contributors
- maintainers inherit review and security costs
- possible community trust issues if policy is vague
So yes, allow it, but only with a written policy, explicit attestation, and a lower tolerance for mystery code than usual. If the source trail is muddy, skip it.