{"thread":{"id":"66483","subject":"[RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance","startedAt":"2026-10-07T14:29:53Z","lastAt":"2026-10-07T22:44:01Z","messageCount":4,"participants":["Scott Chacon","brian m. carlson","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"554383","messageId":"20261007142954.31761-1-scott@gitbutler.net","threadId":"66483","inReplyTo":null,"subject":"[RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance","fromName":"Scott Chacon","fromEmail":"scott@gitbutler.net","sentAt":"2026-10-07T14:29:53Z","receivedAt":"2026-10-07T14:29:53Z","isPatch":true,"sender":{"key":"scott@gitbutler.net","avatar":null},"body":"After the AI discussion at the contributors' summit [1], I'd like to submit\na concrete alternative for allowing AI generated work responsibly. This moves\nus closer to Linux's approach: use the tools you find helpful, but take \nresponsibility for what you send.\n\nOur current policy encourages careful use of AI, then says we'll reject\nanything that looks AI generated. That leaves someone with a useful,\nreviewed patch wondering whether telling us how they made it will get it\nrejected. I believe that it would be better to allow valuable, reviewed\nseries and simply include disclosure (again, how Linux does it).\n\nSFC's legal advice came up at the summit. The original policy credits\nRick Sanders [2] of the SFC and there was some talk of the policy being sound\nbecause it had legal review. However, the SFC's public guidance has changed\nsince then. They date a change in strategy to November 2025 (1 month after\nreviewing the Git policy), when they concluded that relying only on bans was\nno longer a good approach [3].  \n\nTheir June 2026 recommendations describe how to use these tools responsibly:\nreview the output, disclose the assistance, and keep records [4]. The change\nproposed with this patch is in line with their current recommendations.\n\nThere are also several other prominant example projects:\n\n* Linux accepts tool-generated contributions under the existing DCO,\n  asks for disclosure, and leaves maintainers free to request more\n  testing or reject a patch [5][6].\n* Xen is another GPLv2 project using human sign-off and an Assisted-by\n  trailer [7][8]. Its documentation change explicitly followed Linux\n  [9].\n* Debian now allows responsible AI use too, though disclosure is\n  optional there [10].\n\nThey all agree that we don't need to change the DCO to do this. Clause (a)\nalready covers work created \"in whole or in part\" by the contributor, and (b)\ncovers changes to appropriately licensed existing work [11]. Both still\nrequire the right to submit the contribution. Neither requires the\nsubmitter to have personally written every line [12].\n\nSo this updated version of the submission guidelines asks contributors sending\nAI assisted patches (code included) to:\n\n* Review and understand the whole submission, test it appropriately, and\n  answer review comments.\n* Meet the existing DCO and license requirements.\n* Add an Assisted-by trailer for substantial assistance and briefly\n  explain what the tool did and how they checked it.\n\nI'd like us to give people a clear way to submit good work with these\ntools, while keeping the expectations that make patches worth reviewing.\n\n[1] Git Contributors' Summit 2026, AI contribution policy discussion:\n    https://lore.kernel.org/git/summit-2026.94e33e9ddf234334.06@ttaylorr.com/\n[2] Original Git policy commit:\n    https://github.com/git/git/commit/7b0c37953d2e9198309ca6b6faf10bb5deeb4837\n[3] SFC's account of its November 2025 strategic reassessment:\n    https://sfconservancy.org/llm-gen-ai/\n[4] SFC's recommendations, particularly points 4-8 and 11:\n    https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html\n[5] Linux tool-generated content guidelines:\n    https://docs.kernel.org/process/generated-content.html\n[6] Linux AI coding assistant requirements:\n    https://docs.kernel.org/process/coding-assistants.html\n[7] Xen contribution guidance, Assisted-by and Signed-off-by:\n    https://xenbits.xen.org/docs/unstable/process/sending-patches.html#assisted-by\n[8] Xen licensing:\n    https://github.com/xen-project/xen/blob/master/COPYING\n[9] Xen's Linux-inspired documentation patch, 2026-06-15:\n    https://lists.xenproject.org/archives/html/xen-devel/2026-06/msg00882.html\n[10] Debian GR 2026/002, winning option 5:\n     https://www.debian.org/vote/2026/vote_002\n[11] Developer Certificate of Origin 1.1:\n     https://developercertificate.org/\n[12] Red Hat's DCO analysis, 2025-10-15:\n     https://www.redhat.com/en/blog/ai-assisted-development-and-open-source-navigating-legal-issues\n\nScott Chacon (1):\n  SubmittingPatches: allow responsible AI assistance\n\n Documentation/SubmittingPatches | 73 ++++++++++++++++++++++-----------\n 1 file changed, 49 insertions(+), 24 deletions(-)\n\n\nbase-commit: a018953688f1b10bddf91bff8747068f5f4746a4\n-- \n2.50.1 (Apple Git-155)\n\n\n"},{"id":"554384","messageId":"20261007142954.31761-2-scott@gitbutler.net","threadId":"66483","inReplyTo":"20261007142954.31761-1-scott@gitbutler.net","subject":"[RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance","fromName":"Scott Chacon","fromEmail":"scott@gitbutler.net","sentAt":"2026-10-07T14:29:54Z","receivedAt":"2026-10-07T14:29:54Z","isPatch":true,"sender":{"key":"scott@gitbutler.net","avatar":null},"body":"The AI section encourages careful use of AI tools, but also says we\nwill reject anything that looks AI generated. That leaves contributors\nwithout a clear path for submitting useful, reviewed, understood work and\ncan discourage disclosure of the assistance they received.\n\nAllow AI-assisted contributions under the usual quality and licensing\nrequirements. Require human understanding, appropriate testing, and\ndisclosure of substantial assistance. Retain the DCO without changing\nits terms, and require contributors to consider provenance and meet\napplicable license obligations. Reviewers can ask for further evidence\nor decline work they cannot confidently assess.\n\nReplace the appearance-based rejection rule with these concrete\nexpectations. AI assistance neither excuses an inadequate submission\nnor prevents an otherwise acceptable one from being considered.\n\nAs an example, an OpenAI model was used to help me research, compare and\ncraft the appropriate legal language for this policy change to help us\nmatch the modern, legally reviewed approaches now taken by peer GPL\nprojects such as the Linux kernel [1].\n\n[1] https://docs.kernel.org/process/coding-assistants.html\n\nAssisted-by: OpenAI GPT-6 Astra\nSigned-off-by: Scott Chacon <scott@gitbutler.net>\n---\n Documentation/SubmittingPatches | 73 ++++++++++++++++++++++-----------\n 1 file changed, 49 insertions(+), 24 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex c60855f706..f703f96667 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -571,30 +571,55 @@ the patches.\n [[ai]]\n === Use of Artificial Intelligence (AI)\n \n-The Developer's Certificate of Origin requires contributors to certify\n-that they know the origin of their contributions to the project and\n-that they have the right to submit it under the project's license.\n-It's not yet clear that this can be legally satisfied when submitting\n-significant amount of content that has been generated by AI tools.\n-\n-Another issue with AI generated content is that AIs still often\n-hallucinate or just produce bad code, commit messages, documentation\n-or output, even when you point out their mistakes.\n-\n-To avoid these issues, we will reject anything that looks AI\n-generated, that sounds overly formal or bloated, that looks like AI\n-slop, that looks good on the surface but makes no sense, or that\n-senders don’t understand or cannot explain.\n-\n-We strongly recommend using AI tools carefully and responsibly.\n-\n-Contributors would often benefit more from AI by using it to guide and\n-help them step by step towards producing a solution by themselves\n-rather than by asking for a full solution that they would then mostly\n-copy-paste. They can also use AI to help with debugging, or with\n-checking for obvious mistakes, things that can be improved, things\n-that don’t match our style, guidelines or our feedback, before sending\n-it to us.\n+AI tools may be used to help prepare contributions, including code,\n+tests, documentation, and commit messages. AI assistance does not by\n+itself disqualify a contribution. The same requirements for correctness,\n+maintainability, licensing, and review apply regardless of the tools\n+used.\n+\n+You are responsible for the entire contribution. Before submitting it,\n+review and understand the changes, check factual claims, and perform\n+the testing appropriate to the change. Be prepared to explain your\n+decisions and respond to review comments. Do not pass unreviewed tool\n+output on to reviewers, including in commit messages or mailing list\n+replies. Keep explanations concise and relevant to the change.\n+\n+The <<dco,Developer's Certificate of Origin>> applies unchanged. Only a\n+human can make that certification; an AI tool cannot sign off on your\n+behalf. Consider the origin and licensing of generated material,\n+including any third-party material it reproduces, and comply with\n+applicable license and attribution requirements. A tool's assurance\n+that its output is original or compatible with our license is not a\n+substitute for checking those requirements. If you cannot certify the\n+DCO for a contribution, do not submit it.\n+\n+Disclose substantial AI assistance in each affected commit with an\n+`Assisted-by:` trailer naming the tool and, when available, its model\n+or version. For example:\n+\n+....\n+\tAssisted-by: ExampleTool version 1.2\n+....\n+\n+In the accompanying explanation, briefly describe how the tool helped,\n+which parts of the contribution it affected, and how you checked the\n+result. This can go in the cover letter or below the `---` line in the\n+patch email. Disclose substantial assistance with mailing list replies\n+in those replies as well. Trivial spelling corrections, formatting,\n+and identifier completion do not need disclosure. When in doubt,\n+disclose the assistance.\n+\n+Keep relevant prompts and outputs to help answer questions during\n+review. Include short prompts, or a summary of longer sessions, when\n+they help explain the change. Do not include credentials or private\n+material in these records when sharing them.\n+\n+Maintainers may request more explanation, testing, or information about\n+provenance, and may decline contributions they cannot confidently\n+assess. Tool use does not entitle a contribution to review or\n+acceptance. Discuss plans for large-scale automated submissions on the\n+mailing list before sending them; generating patches faster does not\n+increase the project's capacity to review them.\n \n [[git-tools]]\n === Generate your patch using Git tools out of your commits.\n-- \n2.50.1 (Apple Git-155)\n\n\n"},{"id":"554425","messageId":"asa8ymCv4hoRJcZM@fruit.crustytoothpaste.net","threadId":"66483","inReplyTo":"20261007142954.31761-2-scott@gitbutler.net","subject":"Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-10-07T21:42:35Z","receivedAt":"2026-10-07T21:42:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2026-10-07 at 14:29:54, Scott Chacon wrote:\n> The AI section encourages careful use of AI tools, but also says we\n> will reject anything that looks AI generated. That leaves contributors\n> without a clear path for submitting useful, reviewed, understood work and\n> can discourage disclosure of the assistance they received.\n> \n> Allow AI-assisted contributions under the usual quality and licensing\n> requirements. Require human understanding, appropriate testing, and\n> disclosure of substantial assistance. Retain the DCO without changing\n> its terms, and require contributors to consider provenance and meet\n> applicable license obligations. Reviewers can ask for further evidence\n> or decline work they cannot confidently assess.\n> \n> Replace the appearance-based rejection rule with these concrete\n> expectations. AI assistance neither excuses an inadequate submission\n> nor prevents an otherwise acceptable one from being considered.\n> \n> As an example, an OpenAI model was used to help me research, compare and\n> craft the appropriate legal language for this policy change to help us\n> match the modern, legally reviewed approaches now taken by peer GPL\n> projects such as the Linux kernel [1].\n\nI don't think I'm in favour of this policy.  All the major models have\nbeen trained on a large variety of code from a large variety of sources,\nincluding sources such as news reports or personal websites that do not\nallow copying, modification, or distribution.  Given that LLMs are known\nto reproduce portions of their training set or craft code or text which\nis very similar to items in the training set, how can anyone honestly\nassert the DCO without knowing all of the sources that were used to\ncreate it?\n\nEven if the model were, for instance, trained only on MIT-licensed code,\nthe license still requires a copyright and permission notice on every\ncopy, so the fact that the code generated from an LLM doesn't contain\nthat would seem to violate the license and prohibit us from using it.\n\nThe DCO was created to help us unambiguously state that the code is\nacceptable to be included to avoid any later claims that the code was\ncopied from somewhere that it shouldn't have been.  Given the fact that\nnobody knows what the sources are with a current LLM, it doesn't seem\nthat a reasonable person could make such an assertion.\n\nI'm a distributor of Git and I don't want to be sued or arrested because\nI end up distributing code that I don't have the right to distribute.\nLarge companies may have lawyers and lots of money to fight those\nclaims, but I do not (nor does the Git project) and I don't want to\nspend my resources fighting allegations of copyright infringement or\nhave my reputation besmirched for that reason.  Just because other\nprojects think it's okay to do legally and ethically questionable things\ndoesn't mean we should as well.\n\nI'll add that if Git were to include a portion of my MIT- or\nBSD-licensed code without including a copyright or permission notice\nbecause it was laundered through an LLM, I would absolutely file a\ncopyright complaint, and rightfully so.\n\nI refer you to policies from other major open source projects that cover\nthis exact provenance issue:\n\n* Gentoo: https://wiki.gentoo.org/wiki/Project:Council/AI_policy\n* NetBSD: https://www.netbsd.org/developers/commit-guidelines.html\n\nI also will point out the notes from the Contributor Summit where we\ndiscussed this issue in some depth and proposed an approach for further\ndiscussion.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"554432","messageId":"xmqqcxtl3zda.fsf@gitster.g","threadId":"66483","inReplyTo":"20261007142954.31761-2-scott@gitbutler.net","subject":"Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-07T22:44:01Z","receivedAt":"2026-10-07T22:44:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Chacon <scott@gitbutler.net> writes:\n\n> As an example, an OpenAI model was used to help me research, compare and\n> craft the appropriate legal language for this policy change to help us\n> match the modern, legally reviewed approaches now taken by peer GPL\n> projects such as the Linux kernel [1].\n>\n> [1] https://docs.kernel.org/process/coding-assistants.html\n\nThat makes it sound as if this is just as legally sound as what the\nkernel project uses.  However, the only assurance we get (unless you\nare willing to act as our lawyer, and I do not know if you are one)\nis that an OpenAI model produced plausible-sounding utterances.\n\nIndeed, the proposed text seems to instruct developers and reviewers\nto do quite different things from the rules I see in the above URL.\nNote that in the following, I will be playing devil's advocate for\nmuch of the time, so please accept my apologies in advance if I\nsound too skeptical.\n\n> +AI tools may be used to help prepare contributions, including code,\n> +tests, documentation, and commit messages. AI assistance does not by\n> +itself disqualify a contribution. The same requirements for correctness,\n> +maintainability, licensing, and review apply regardless of the tools\n> +used.\n> +\n> +You are responsible for the entire contribution. Before submitting it,\n> +review and understand the changes, check factual claims, and perform\n> +the testing appropriate to the change. Be prepared to explain your\n> +decisions and respond to review comments. Do not pass unreviewed tool\n> +output on to reviewers, including in commit messages or mailing list\n> +replies. Keep explanations concise and relevant to the change.\n\nIt looks, at least to me, that there is not much that can be\nmeaningfully enforced by reviewers and followed by contributors in\nthe above text.  It seems to be little more than \"the world would be\na wonderful place if everybody behaved this way.\"\n\nA violation of \"concise and relevant\" seems to be the recent trend\nof much AI-generated slop, so it may be a good suggestion to give\ntoday.  But would we need to update it once the trend of text\ngenerated by AI tools becomes \"concise and relevant\" nonsense that\nmerely sounds plausible?  What if an \"AI-assisted\" contributor lacks\ncommon sense to tell between plausible-sounding nonsense and a\nwell-written description?  What if reviewers get too many such\n\"contributions\" and cannot allocate enough review bandwidth to sift\ngood contributions from plausible-sounding nonsense?\n\n> +The <<dco,Developer's Certificate of Origin>> applies unchanged. Only a\n> +human can make that certification; an AI tool cannot sign off on your\n> +behalf. Consider the origin and licensing of generated material,\n> +including any third-party material it reproduces, and comply with\n> +applicable license and attribution requirements. A tool's assurance\n> +that its output is original or compatible with our license is not a\n> +substitute for checking those requirements. If you cannot certify the\n> +DCO for a contribution, do not submit it.\n\nAgain, this is a good aspiration to have, but I doubt that anyone\ncan practically certify that the output of an LLM is devoid of\ncontent borrowed from problematic sources under the rule the text\nabove gives.  Would it not be more useful to help contributors by\ndefining what not to do more clearly?  Our current text says as much\nmore directly: you cannot practically certify, so do not send in\nAI-generated slop, period.\n\n> +Disclose substantial AI assistance in each affected commit with an\n> +`Assisted-by:` trailer naming the tool and, when available, its model\n> +or version. For example:\n> +\n> +....\n> +\tAssisted-by: ExampleTool version 1.2\n> +....\n\nI thought the kernel guidelines instructed us to say only \"LLM\"\nthese days, to avoid giving free advertising.  On the other hand,\nthey ask contributors to also list non-LLM tools, like coccinelle\nand clang-tidy, that were used in their machine-assisted\ncontributions.  I am undecided on the merit of specifying the\nexact model and version, but listing non-LLM tools alongside\nmaterials for independent reproduction looks like a good idea.\n\n> +Maintainers may request more explanation, testing, or information about\n> +provenance, and may decline contributions they cannot confidently\n> +assess.\n\nThe text of the kernel guidelines appears to give maintainers more\nlatitude (cf. https://docs.kernel.org/process/generated-content.html).\nThey can treat it just like any other contribution, reject it\noutright, or choose any approach in between.  The proposed text above\ndoes not account for cases where reviewers simply lack the bandwidth\nto even think about what explanation and proof to request, and it\nmakes it sound as if declining a submission in such a case an unfair\nrejection.\n\n\n\n"}]}