Git development
 help / color / mirror / Atom feed
From: Scott Chacon <scott@gitbutler.net>
To: git@vger.kernel.org
Subject: [RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance
Date: Wed,  7 Oct 2026 16:29:53 +0200	[thread overview]
Message-ID: <20261007142954.31761-1-scott@gitbutler.net> (raw)

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
-- 
2.50.1 (Apple Git-155)


             reply	other threads:[~2026-10-07 14:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 14:29 Scott Chacon [this message]
2026-10-07 14:29 ` [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance Scott Chacon
2026-10-07 21:42   ` brian m. carlson
2026-10-08  4:49     ` Scott Chacon
2026-10-08  5:29       ` Luca Milanesio
2026-10-08  5:53       ` Kristoffer Haugsbakk
2026-10-08 16:15       ` brian m. carlson
2026-10-07 22:44   ` Junio C Hamano
2026-10-08 13:53     ` Scott Chacon
2026-10-09 10:22       ` Patrick Steinhardt
2026-10-09 20:39         ` Junio C Hamano
2026-10-08 18:10 ` [RFC PATCH 0/1] " D. Ben Knoble

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261007142954.31761-1-scott@gitbutler.net \
    --to=scott@gitbutler.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox