# [RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance 4 messages from 2026-10-07 to 2026-10-07. Participants: Scott Chacon, brian m. carlson, Junio C Hamano. Thread: https://gitlist.dev/t/66483 ## Scott Chacon, 2026-10-07 14:29 Subject: [RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance Message-ID: <20261007142954.31761-1-scott@gitbutler.net> URL: https://gitlist.dev/e/20261007142954.31761-1-scott%40gitbutler.net ``` 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) ``` ## Scott Chacon, 2026-10-07 14:29 Subject: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance Message-ID: <20261007142954.31761-2-scott@gitbutler.net> URL: https://gitlist.dev/e/20261007142954.31761-2-scott%40gitbutler.net In-Reply-To: <20261007142954.31761-1-scott@gitbutler.net> ``` 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 --- Documentation/SubmittingPatches | 73 ++++++++++++++++++++++----------- 1 file changed, 49 insertions(+), 24 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c60855f706..f703f96667 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -571,30 +571,55 @@ the patches. [[ai]] === Use of Artificial Intelligence (AI) -The Developer's Certificate of Origin requires contributors to certify -that they know the origin of their contributions to the project and -that they have the right to submit it under the project's license. -It's not yet clear that this can be legally satisfied when submitting -significant amount of content that has been generated by AI tools. - -Another issue with AI generated content is that AIs still often -hallucinate or just produce bad code, commit messages, documentation -or output, even when you point out their mistakes. - -To avoid these issues, we will reject anything that looks AI -generated, that sounds overly formal or bloated, that looks like AI -slop, that looks good on the surface but makes no sense, or that -senders don’t understand or cannot explain. - -We strongly recommend using AI tools carefully and responsibly. - -Contributors would often benefit more from AI by using it to guide and -help them step by step towards producing a solution by themselves -rather than by asking for a full solution that they would then mostly -copy-paste. They can also use AI to help with debugging, or with -checking for obvious mistakes, things that can be improved, things -that don’t match our style, guidelines or our feedback, before sending -it to us. +AI tools may be used to help prepare contributions, including code, +tests, documentation, and commit messages. AI assistance does not by +itself disqualify a contribution. The same requirements for correctness, +maintainability, licensing, and review apply regardless of the tools +used. + +You are responsible for the entire contribution. Before submitting it, +review and understand the changes, check factual claims, and perform +the testing appropriate to the change. Be prepared to explain your +decisions and respond to review comments. Do not pass unreviewed tool +output on to reviewers, including in commit messages or mailing list +replies. Keep explanations concise and relevant to the change. + +The <> applies unchanged. Only a +human can make that certification; an AI tool cannot sign off on your +behalf. Consider the origin and licensing of generated material, +including any third-party material it reproduces, and comply with +applicable license and attribution requirements. A tool's assurance +that its output is original or compatible with our license is not a +substitute for checking those requirements. If you cannot certify the +DCO for a contribution, do not submit it. + +Disclose substantial AI assistance in each affected commit with an +`Assisted-by:` trailer naming the tool and, when available, its model +or version. For example: + +.... + Assisted-by: ExampleTool version 1.2 +.... + +In the accompanying explanation, briefly describe how the tool helped, +which parts of the contribution it affected, and how you checked the +result. This can go in the cover letter or below the `---` line in the +patch email. Disclose substantial assistance with mailing list replies +in those replies as well. Trivial spelling corrections, formatting, +and identifier completion do not need disclosure. When in doubt, +disclose the assistance. + +Keep relevant prompts and outputs to help answer questions during +review. Include short prompts, or a summary of longer sessions, when +they help explain the change. Do not include credentials or private +material in these records when sharing them. + +Maintainers may request more explanation, testing, or information about +provenance, and may decline contributions they cannot confidently +assess. Tool use does not entitle a contribution to review or +acceptance. Discuss plans for large-scale automated submissions on the +mailing list before sending them; generating patches faster does not +increase the project's capacity to review them. [[git-tools]] === Generate your patch using Git tools out of your commits. -- 2.50.1 (Apple Git-155) ``` ## brian m. carlson, 2026-10-07 21:42 Subject: Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance Message-ID: URL: https://gitlist.dev/e/asa8ymCv4hoRJcZM%40fruit.crustytoothpaste.net In-Reply-To: <20261007142954.31761-2-scott@gitbutler.net> ``` On 2026-10-07 at 14:29:54, Scott Chacon wrote: > 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]. I don't think I'm in favour of this policy. All the major models have been trained on a large variety of code from a large variety of sources, including sources such as news reports or personal websites that do not allow copying, modification, or distribution. Given that LLMs are known to reproduce portions of their training set or craft code or text which is very similar to items in the training set, how can anyone honestly assert the DCO without knowing all of the sources that were used to create it? Even if the model were, for instance, trained only on MIT-licensed code, the license still requires a copyright and permission notice on every copy, so the fact that the code generated from an LLM doesn't contain that would seem to violate the license and prohibit us from using it. The DCO was created to help us unambiguously state that the code is acceptable to be included to avoid any later claims that the code was copied from somewhere that it shouldn't have been. Given the fact that nobody knows what the sources are with a current LLM, it doesn't seem that a reasonable person could make such an assertion. I'm a distributor of Git and I don't want to be sued or arrested because I end up distributing code that I don't have the right to distribute. Large companies may have lawyers and lots of money to fight those claims, but I do not (nor does the Git project) and I don't want to spend my resources fighting allegations of copyright infringement or have my reputation besmirched for that reason. Just because other projects think it's okay to do legally and ethically questionable things doesn't mean we should as well. I'll add that if Git were to include a portion of my MIT- or BSD-licensed code without including a copyright or permission notice because it was laundered through an LLM, I would absolutely file a copyright complaint, and rightfully so. I refer you to policies from other major open source projects that cover this exact provenance issue: * Gentoo: https://wiki.gentoo.org/wiki/Project:Council/AI_policy * NetBSD: https://www.netbsd.org/developers/commit-guidelines.html I also will point out the notes from the Contributor Summit where we discussed this issue in some depth and proposed an approach for further discussion. -- brian m. carlson (they/them) Toronto, Ontario, CA ``` ## Junio C Hamano, 2026-10-07 22:44 Subject: Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance Message-ID: URL: https://gitlist.dev/e/xmqqcxtl3zda.fsf%40gitster.g In-Reply-To: <20261007142954.31761-2-scott@gitbutler.net> ``` Scott Chacon writes: > 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 That makes it sound as if this is just as legally sound as what the kernel project uses. However, the only assurance we get (unless you are willing to act as our lawyer, and I do not know if you are one) is that an OpenAI model produced plausible-sounding utterances. Indeed, the proposed text seems to instruct developers and reviewers to do quite different things from the rules I see in the above URL. Note that in the following, I will be playing devil's advocate for much of the time, so please accept my apologies in advance if I sound too skeptical. > +AI tools may be used to help prepare contributions, including code, > +tests, documentation, and commit messages. AI assistance does not by > +itself disqualify a contribution. The same requirements for correctness, > +maintainability, licensing, and review apply regardless of the tools > +used. > + > +You are responsible for the entire contribution. Before submitting it, > +review and understand the changes, check factual claims, and perform > +the testing appropriate to the change. Be prepared to explain your > +decisions and respond to review comments. Do not pass unreviewed tool > +output on to reviewers, including in commit messages or mailing list > +replies. Keep explanations concise and relevant to the change. It looks, at least to me, that there is not much that can be meaningfully enforced by reviewers and followed by contributors in the above text. It seems to be little more than "the world would be a wonderful place if everybody behaved this way." A violation of "concise and relevant" seems to be the recent trend of much AI-generated slop, so it may be a good suggestion to give today. But would we need to update it once the trend of text generated by AI tools becomes "concise and relevant" nonsense that merely sounds plausible? What if an "AI-assisted" contributor lacks common sense to tell between plausible-sounding nonsense and a well-written description? What if reviewers get too many such "contributions" and cannot allocate enough review bandwidth to sift good contributions from plausible-sounding nonsense? > +The <> applies unchanged. Only a > +human can make that certification; an AI tool cannot sign off on your > +behalf. Consider the origin and licensing of generated material, > +including any third-party material it reproduces, and comply with > +applicable license and attribution requirements. A tool's assurance > +that its output is original or compatible with our license is not a > +substitute for checking those requirements. If you cannot certify the > +DCO for a contribution, do not submit it. Again, this is a good aspiration to have, but I doubt that anyone can practically certify that the output of an LLM is devoid of content borrowed from problematic sources under the rule the text above gives. Would it not be more useful to help contributors by defining what not to do more clearly? Our current text says as much more directly: you cannot practically certify, so do not send in AI-generated slop, period. > +Disclose substantial AI assistance in each affected commit with an > +`Assisted-by:` trailer naming the tool and, when available, its model > +or version. For example: > + > +.... > + Assisted-by: ExampleTool version 1.2 > +.... I thought the kernel guidelines instructed us to say only "LLM" these days, to avoid giving free advertising. On the other hand, they ask contributors to also list non-LLM tools, like coccinelle and clang-tidy, that were used in their machine-assisted contributions. I am undecided on the merit of specifying the exact model and version, but listing non-LLM tools alongside materials for independent reproduction looks like a good idea. > +Maintainers may request more explanation, testing, or information about > +provenance, and may decline contributions they cannot confidently > +assess. The text of the kernel guidelines appears to give maintainers more latitude (cf. https://docs.kernel.org/process/generated-content.html). They can treat it just like any other contribution, reject it outright, or choose any approach in between. The proposed text above does not account for cases where reviewers simply lack the bandwidth to even think about what explanation and proof to request, and it makes it sound as if declining a submission in such a case an unfair rejection. ```