RFC patchSubmittingPatches: allow responsible AI assistance

After the AI discussion at the contributors' summit [1], I'd like to submit a concrete alternative for allowing AI generated work responsibly. This moves us closer to Linux's approach: use the tools you find helpful, but take responsibility for what you send.

Our current policy encourages careful use of AI, then says we'll reject anything that looks AI generated. That leaves someone with a useful, reviewed patch wondering whether telling us how they made it will get it rejected. I believe that it would be better to allow valuable, reviewed series and simply include disclosure (again, how Linux does it).

SFC's legal advice came up at the summit. The original policy credits Rick Sanders [2] of the SFC and there was some talk of the policy being sound because it had legal review. However, the SFC's public guidance has changed since then. They date a change in strategy to November 2025 (1 month after reviewing the Git policy), when they concluded that relying only on bans was no longer a good approach [3].

Their June 2026 recommendations describe how to use these tools responsibly: review the output, disclose the assistance, and keep records [4]. The change proposed with this patch is in line with their current recommendations.

There are also several other prominant example projects:

* Linux accepts tool-generated contributions under the existing DCO,
  asks for disclosure, and leaves maintainers free to request more
  testing or reject a patch [5][6].
* Xen is another GPLv2 project using human sign-off and an Assisted-by
  trailer [7][8]. Its documentation change explicitly followed Linux
  [9].
* Debian now allows responsible AI use too, though disclosure is
  optional there [10].

They all agree that we don't need to change the DCO to do this. Clause (a) already covers work created "in whole or in part" by the contributor, and (b) covers changes to appropriately licensed existing work [11]. Both still require the right to submit the contribution. Neither requires the submitter to have personally written every line [12].

So this updated version of the submission guidelines asks contributors sending AI assisted patches (code included) to:

* Review and understand the whole submission, test it appropriately, and
  answer review comments.
* Meet the existing DCO and license requirements.
* Add an Assisted-by trailer for substantial assistance and briefly
  explain what the tool did and how they checked it.

I'd like us to give people a clear way to submit good work with these tools, while keeping the expectations that make patches worth reviewing.

[1] Git Contributors' Summit 2026, AI contribution policy discussion:
    https://lore.kernel.org/git/summit-2026.94e33e9ddf234334.06@ttaylorr.com/
[2] Original Git policy commit:
    https://github.com/git/git/commit/7b0c37953d2e9198309ca6b6faf10bb5deeb4837
[3] SFC's account of its November 2025 strategic reassessment:
    https://sfconservancy.org/llm-gen-ai/
[4] SFC's recommendations, particularly points 4-8 and 11:
    https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
[5] Linux tool-generated content guidelines:
    https://docs.kernel.org/process/generated-content.html
[6] Linux AI coding assistant requirements:
    https://docs.kernel.org/process/coding-assistants.html
[7] Xen contribution guidance, Assisted-by and Signed-off-by:
    https://xenbits.xen.org/docs/unstable/process/sending-patches.html#assisted-by
[8] Xen licensing:
    https://github.com/xen-project/xen/blob/master/COPYING
[9] Xen's Linux-inspired documentation patch, 2026-06-15:
    https://lists.xenproject.org/archives/html/xen-devel/2026-06/msg00882.html
[10] Debian GR 2026/002, winning option 5:
     https://www.debian.org/vote/2026/vote_002
[11] Developer Certificate of Origin 1.1:
     https://developercertificate.org/
[12] Red Hat's DCO analysis, 2025-10-15:
     https://www.redhat.com/en/blog/ai-assisted-development-and-open-source-navigating-legal-issues

Scott Chacon (1):
  SubmittingPatches: allow responsible AI assistance

 Documentation/SubmittingPatches | 73 ++++++++++++++++++++++-----------
 1 file changed, 49 insertions(+), 24 deletions(-)

base-commit: a018953688f1b10bddf91bff8747068f5f4746a4

The AI section encourages careful use of AI tools, but also says we will reject anything that looks AI generated. That leaves contributors without a clear path for submitting useful, reviewed, understood work and can discourage disclosure of the assistance they received.

Allow AI-assisted contributions under the usual quality and licensing requirements. Require human understanding, appropriate testing, and disclosure of substantial assistance. Retain the DCO without changing its terms, and require contributors to consider provenance and meet applicable license obligations. Reviewers can ask for further evidence or decline work they cannot confidently assess.

Replace the appearance-based rejection rule with these concrete expectations. AI assistance neither excuses an inadequate submission nor prevents an otherwise acceptable one from being considered.

As an example, an OpenAI model was used to help me research, compare and craft the appropriate legal language for this policy change to help us match the modern, legally reviewed approaches now taken by peer GPL projects such as the Linux kernel [1].

[1] https://docs.kernel.org/process/coding-assistants.html

Assisted-by: OpenAI GPT-6 Astra
Signed-off-by: Scott Chacon <scott@gitbutler.net>
---
 Documentation/SubmittingPatches | 73 ++++++++++++++++++++++-----------
 1 file changed, 49 insertions(+), 24 deletions(-)