Can Maintainers Require AI Disclosure in Pull Requests?

Yes. Maintainers can make disclosure of AI use a condition of submitting or merging contributions to a project they control, provided the requirement is clear and applied consistently. That is a project policy, not a universal rule for every repository: contributors should check the project’s contribution guide and pull-request template, and maintainers should define what must be disclosed.

Why projects set disclosure rules

AI tools can assist with many parts of software work: generating code, suggesting tests, explaining an unfamiliar codebase, drafting documentation, or revising wording. A pull request alone may not reveal which of these occurred. Some projects therefore request disclosure to understand how a change was prepared and what review it may need.

The reasons differ. A project might want contributors to verify generated code carefully, make sure they understand and can maintain it, or identify tests and documentation that need extra scrutiny. A project may also be collecting information about tool use for internal evaluation. Disclosure can help with these aims, but it does not establish that a contribution is correct, incorrect, original, or improperly licensed.

There is no single standard across open-source projects. One repository may ask contributors to mention substantial AI assistance; another may not ask at all. A policy in one project does not automatically apply to a separate project, even if both use the same hosting service.

What maintainers can require

In practical terms, maintainers generally decide how contributions to their own repository are submitted and reviewed. They may document a disclosure rule in a contribution guide, a code of conduct where relevant, or a pull-request template. They can ask contributors to provide information before review or make it a condition for accepting a change.

That project-level authority is not the same as unlimited legal authority over a contributor. The details can depend on the project’s governance, applicable law, platform rules, and any agreements involved. A contributor who does not want to follow a repository’s policy can choose not to submit, ask for clarification, or discuss an exception; maintainers can decide whether to proceed with the contribution under their stated rules.

A useful policy says what the project means by “AI use.” For example, it might require disclosure when a tool generates or materially rewrites code, tests, or documentation, while not requiring a note for routine spell-checking or autocomplete. If the project wants disclosure for all AI assistance, it should say so plainly rather than leaving contributors to guess.

What a useful disclosure includes

Most projects do not need a transcript of every prompt or a list of every tool interaction. A brief, task-focused note can tell reviewers what matters without turning the pull request into a surveillance record. A policy can ask contributors to state:

• Which parts of the contribution were generated, substantially revised, or otherwise assisted by a tool.
• What kind of assistance was used, such as code generation, test suggestions, or documentation drafting.
• Whether the contributor reviewed, tested, and can explain the submitted changes.
• Any project-specific information needed to assess provenance or compliance, if the project has a concrete reason to request it.

For instance, a contributor might write: “An AI coding assistant suggested the initial unit-test cases; I reviewed and edited them, and ran the test suite. The implementation was written by me.” That is more useful than “AI used” because it distinguishes the affected material and describes the contributor’s review. It also avoids making an unsupported claim that a tool’s output is necessarily accurate or safe.

How to write and apply the policy

Maintainers should place the rule somewhere contributors will find before investing time in a change. A contribution guide and a pull-request template work well together: the guide explains the reasoning and scope, while the template prompts for the relevant information at submission time.

1. Define the threshold. Say whether the rule covers any assistance or only generated or materially altered contributions. Give examples of covered and excluded uses.
2. Ask only for relevant details. Explain whether a tool category, affected files, or review and testing information is needed. Avoid requesting sensitive prompts or proprietary material unless there is a clear, stated need.
3. Explain the review process. Tell contributors how disclosure affects review, whether omissions can be corrected, and whom to contact with questions.
4. Apply it consistently. Similar contributions should be treated under the same written standard. If the policy changes, announce the change and clarify how it applies to open pull requests.

A template could say: “Did you use an AI tool to generate or substantially revise any part of this contribution? If yes, identify the affected areas and describe your review and testing. Do not include confidential prompts or data.” The wording should match the project’s actual policy rather than imply that every tool use is prohibited.

Disclosure is not the same as permission or proof

A common misconception is that disclosure itself settles questions about copyright, licensing, security, or quality. It does not. A contributor’s statement can help reviewers understand how work was produced, but it does not prove that output is free of third-party material, that the code works, or that the contributor has fulfilled every obligation that applies to the project.

Likewise, requiring disclosure does not automatically mean a project bans AI-assisted work. A project can permit such work subject to review, restrict it in specified circumstances, or decline it under a clearly stated policy. Those are separate choices. Reviewers should still inspect the code, tests, dependencies, and documentation according to the project’s normal standards.

Policies should also avoid treating a disclosure as an accusation. Contributors may use tools in different ways, and the boundary between autocomplete, editing assistance, and generated content is not always obvious. Clear examples and a way to ask questions make compliance more practical and reduce disputes over terminology.

Common problems and fair responses

Vague rules create inconsistent answers. If one maintainer considers grammar suggestions “AI use” and another considers only generated code relevant, contributors cannot know what to report. A narrow, explicit definition is usually easier to follow than a broad phrase with no examples.

Another problem is demanding details that do not help review. Full prompts may contain personal, confidential, or employer-owned information. A project can usually ask about the contribution and the contributor’s verification without collecting private prompt histories. If specific provenance information is important, explain why and offer a safe way to provide it.

If a contributor omitted a required disclosure, a proportionate first response is often to request the missing information and pause review while it is clarified. Rejection may be appropriate under a project’s stated rules, but an undisclosed use should not automatically be treated as proof of misconduct. The project should distinguish a correctable omission from a substantive policy violation and follow its governance process.

Frequently Asked Questions

Can a maintainer reject a pull request because AI was used?
Yes, if the project’s applicable rules allow that decision. A project can prohibit certain uses or require disclosure, but contributors should be able to find the policy and understand what it covers.

Do contributors have to disclose every AI-assisted edit?
There is no universal requirement. It depends on the repository’s policy. A project may cover all assistance, only substantial generation, or specified kinds of work; read its contribution instructions or ask maintainers.

Does using AI violate an open-source license?
AI use by itself does not answer whether a contribution complies with a license. The relevant facts can include the material submitted, the project’s license and contribution terms, and applicable law. Disclosure is not a substitute for checking those requirements.

Should contributors include their prompts in a pull request?
Usually, a concise description of the affected work and verification is more useful. Share prompts only if the project has a clear reason to request them, and do not expose confidential or sensitive information.

What if the project has no AI disclosure policy?
Check the contribution guide and ask the maintainers if the expected practice is unclear. A contributor can voluntarily explain material assistance, but should not assume that every repository has the same rule.

Bottom line

Maintainers can set disclosure conditions for contributions to their projects, but the strongest policies are specific, visible, limited to useful information, and consistently applied. Contributors should check the repository’s instructions, describe material assistance honestly when asked, and remain responsible for understanding and validating what they submit. Disclosure informs review; it does not replace it.

Related

• How Programs Allocate and Reclaim Memory
• Office Camera Privacy: Can You Stop Monitoring?
• Chromium Browser Supporters: Who Backs the Project?