{"thread":{"id":"63716","subject":"[RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","startedAt":"2025-06-30T20:32:25Z","lastAt":"2025-10-23T17:32:10Z","messageCount":34,"participants":["Junio C Hamano","brian m. carlson","Collin Funk","Christian Couder","Chuck Wolber","Ben Knoble","rsbecker@nexbridge.com","Elijah Newren","Michal Suchánek"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"520970","messageId":"xmqqcyalm0mh.fsf@gitster.g","threadId":"63716","inReplyTo":null,"subject":"[RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-30T20:32:22Z","receivedAt":"2025-06-30T20:32:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Following the example set by QEMU folks, let's explicitly forbid use\nof genAI tools until the copyright and license situations become\nmore clear. Here is what QEMU folks say in their commit to adopt\nsuch a rule:\n\n The DCO requires contributors to assert they have the right to\n contribute under the designated project license. Given the lack\n of consensus on the licensing of AI code generator output, it is\n not considered credible to assert compliance with the DCO clause\n (b) or (c) where a patch includes such generated code.\n\nand it applies equally well to ours.\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/SubmittingPatches | 17 +++++++++++++++++\n 1 file changed, 17 insertions(+)\n\ndiff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches\nindex 958e3cc3d5..63fd10ce39 100644\n--- c/Documentation/SubmittingPatches\n+++ w/Documentation/SubmittingPatches\n@@ -439,6 +439,23 @@ highlighted above.\n Only capitalize the very first letter of the trailer, i.e. favor\n \"Signed-off-by\" over \"Signed-Off-By\" and \"Acked-by:\" over \"Acked-By\".\n \n+\n+[[ai]]\n+=== Use of AI content generators\n+\n+This project requires that contributors certify that their\n+contributions are made under Developer's Certificate of Origin 1.1,\n+which in turn means that contributors must understand the full\n+provenance of what they are contributing. With AI content generators,\n+the copyright or license status of their output is ill-defined, without\n+any generally accepted legal foundation.\n+\n+Hence, the project asks that contributors refrain from using AI content\n+generators on changes that are submitted to the project.\n+Contributions in which use of AI is either known or suspected may not\n+be accepted.\n+\n+\n [[git-tools]]\n === Generate your patch using Git tools out of your commits.\n \n"},{"id":"520971","messageId":"aGL8hubqY35UAaGh@fruit.crustytoothpaste.net","threadId":"63716","inReplyTo":"xmqqcyalm0mh.fsf@gitster.g","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-06-30T21:07:18Z","receivedAt":"2025-06-30T21:07:21Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-06-30 at 20:32:22, Junio C Hamano wrote:\n> Following the example set by QEMU folks, let's explicitly forbid use\n> of genAI tools until the copyright and license situations become\n> more clear. Here is what QEMU folks say in their commit to adopt\n> such a rule:\n> \n> The DCO requires contributors to assert they have the right to\n> contribute under the designated project license. Given the lack\n> of consensus on the licensing of AI code generator output, it is\n> not considered credible to assert compliance with the DCO clause\n> (b) or (c) where a patch includes such generated code.\n> \n> and it applies equally well to ours.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/SubmittingPatches | 17 +++++++++++++++++\n> 1 file changed, 17 insertions(+)\n> \n> diff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches\n> index 958e3cc3d5..63fd10ce39 100644\n> --- c/Documentation/SubmittingPatches\n> +++ w/Documentation/SubmittingPatches\n> @@ -439,6 +439,23 @@ highlighted above.\n> Only capitalize the very first letter of the trailer, i.e. favor\n> \"Signed-off-by\" over \"Signed-Off-By\" and \"Acked-by:\" over \"Acked-By\".\n> \n> +\n> +[[ai]]\n> +=== Use of AI content generators\n> +\n> +This project requires that contributors certify that their\n> +contributions are made under Developer's Certificate of Origin 1.1,\n> +which in turn means that contributors must understand the full\n> +provenance of what they are contributing. With AI content generators,\n> +the copyright or license status of their output is ill-defined, without\n> +any generally accepted legal foundation.\n> +\n> +Hence, the project asks that contributors refrain from using AI content\n> +generators on changes that are submitted to the project.\n> +Contributions in which use of AI is either known or suspected may not\n> +be accepted.\n\nThis matches the advice we gave contributors to GSOC and similar\nprojects, so it's good that we're being consistent here.\n\nI think this seems prudent given the fact that there are 181 signatories\nto the Berne Convention and even if the courts rule that the use of\ngenerative AI is acceptable in one country (say, the United States), it\nisn't clear that that will mean anything in other countries (such as\nCanada). Considering that there's ongoing litigation and quite a bit of\nlegal uncertainty, as well as substantial pushback on generative AI from\nthe open source community, this approach seems like it's in the best\ninterests of the project at the moment[0]. We can always reconsider in\nthe future if need be.\n\nI'll note that this was my interpretation of the DCO from the start (and\nI have governed my behaviour and contributions accordingly) but it can\nbe helpful to explicitly document our shared understanding.\n\nOne style note: I noticed that there's two blank lines before and after\nthis block. Some sections have one blank line between them and some\nhave two, so I don't think this is a problem, but I thought I might as\nwell point it out.\n\n[0] I know some large companies feel differently, but considering our\nstatus as a member project of Conservancy (which is a non-profit), our\ncomparatively limited assets, and the potential negative legal effects\non downstream distributors (many of which are independent people or\nnon-profits), I would say we find ourselves in a different position from\nthose companies and would need to make a different decision.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"520974","messageId":"87ms9oore1.fsf@gmail.com","threadId":"63716","inReplyTo":"aGL8hubqY35UAaGh@fruit.crustytoothpaste.net","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Collin Funk","fromEmail":"collin.funk1@gmail.com","sentAt":"2025-06-30T21:23:34Z","receivedAt":"2025-06-30T21:23:36Z","isPatch":true,"sender":{"key":"collin.funk1@gmail.com","avatar":"https://avatars.githubusercontent.com/u/65689063?v=4"},"body":"Hi all,\n\n\"brian m. carlson\" writes:\n\n> I think this seems prudent given the fact that there are 181 signatories\n> to the Berne Convention and even if the courts rule that the use of\n> generative AI is acceptable in one country (say, the United States), it\n> isn't clear that that will mean anything in other countries (such as\n> Canada). Considering that there's ongoing litigation and quite a bit of\n> legal uncertainty, as well as substantial pushback on generative AI from\n> the open source community, this approach seems like it's in the best\n> interests of the project at the moment[0]. We can always reconsider in\n> the future if need be.\n\nI agree. It feels unsafe given the lack of legislation and lack of case\nlaw.\n\nOne thing, though:\n\n>> +Hence, the project asks that contributors refrain from using AI content\n>> +generators on changes that are submitted to the project.\n>> +Contributions in which use of AI is either known or suspected may not\n>> +be accepted.\n\nThis feels more like a suggestion than a requirement. Shouldn't we\nexplicitly prohibit it? If we truly are worried about the\ncopyright-ability of its output.\n\nCollin\n"},{"id":"521007","messageId":"CAP8UFD0bd1PD03VPaenAd+76Q6CeCOmDOJsso1nMKk4tZ4vbMg@mail.gmail.com","threadId":"63716","inReplyTo":"xmqqcyalm0mh.fsf@gitster.g","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-07-01T10:36:24Z","receivedAt":"2025-07-01T10:36:38Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Jun 30, 2025 at 10:32 PM Junio C Hamano wrote:\n>\n> Following the example set by QEMU folks, let's explicitly forbid use\n> of genAI tools until the copyright and license situations become\n> more clear. Here is what QEMU folks say in their commit to adopt\n> such a rule:\n>\n> The DCO requires contributors to assert they have the right to\n> contribute under the designated project license. Given the lack\n> of consensus on the licensing of AI code generator output, it is\n> not considered credible to assert compliance with the DCO clause\n> (b) or (c) where a patch includes such generated code.\n\nHere they forbid licensing any \"AI code generator output\" with the DCO.\n\n> and it applies equally well to ours.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/SubmittingPatches | 17 +++++++++++++++++\n> 1 file changed, 17 insertions(+)\n>\n> diff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches\n> index 958e3cc3d5..63fd10ce39 100644\n> --- c/Documentation/SubmittingPatches\n> +++ w/Documentation/SubmittingPatches\n> @@ -439,6 +439,23 @@ highlighted above.\n> Only capitalize the very first letter of the trailer, i.e. favor\n> \"Signed-off-by\" over \"Signed-Off-By\" and \"Acked-by:\" over \"Acked-By\".\n>\n> +\n> +[[ai]]\n> +=== Use of AI content generators\n> +\n> +This project requires that contributors certify that their\n> +contributions are made under Developer's Certificate of Origin 1.1,\n> +which in turn means that contributors must understand the full\n> +provenance of what they are contributing. With AI content generators,\n> +the copyright or license status of their output is ill-defined, without\n> +any generally accepted legal foundation.\n\nHere we would forbid licensing any \"AI content generator\" output, not\njust AI code generator output. So what we would forbid might be more\ngeneral than what QEMU folks forbid. For example they might still\naccept a new logo, or even commit messages, made using an AI while we\nwouldn't.\n\n> +Hence, the project asks that contributors refrain from using AI content\n> +generators on changes that are submitted to the project.\n\nHere it looks like using an AI capable of generating content to just\ncheck code that would be submitted could also be forbidden. I don't\nthink this is what we want, so I think we might want to reword this.\n\n> +Contributions in which use of AI is either known or suspected may not\n> +be accepted.\n\nHere also \"use of AI\" might forbid checking what we submit using any AI tool.\n"},{"id":"521012","messageId":"CAP8UFD3DCi5n12HpYwuF4Sh4gG-B98a57HBpDAB+uPrqJcN+jQ@mail.gmail.com","threadId":"63716","inReplyTo":"CAP8UFD0bd1PD03VPaenAd+76Q6CeCOmDOJsso1nMKk4tZ4vbMg@mail.gmail.com","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-07-01T11:07:52Z","receivedAt":"2025-07-01T11:08:06Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jul 1, 2025 at 12:36 PM Christian Couder\n wrote:\n>\n> On Mon, Jun 30, 2025 at 10:32 PM Junio C Hamano wrote:\n> >\n> > Following the example set by QEMU folks, let's explicitly forbid use\n> > of genAI tools until the copyright and license situations become\n> > more clear. Here is what QEMU folks say in their commit to adopt\n> > such a rule:\n> >\n> > The DCO requires contributors to assert they have the right to\n> > contribute under the designated project license. Given the lack\n> > of consensus on the licensing of AI code generator output, it is\n> > not considered credible to assert compliance with the DCO clause\n> > (b) or (c) where a patch includes such generated code.\n>\n> Here they forbid licensing any \"AI code generator output\" with the DCO.\n>\n> > and it applies equally well to ours.\n\n[...]\n\n> > +=== Use of AI content generators\n> > +\n> > +This project requires that contributors certify that their\n> > +contributions are made under Developer's Certificate of Origin 1.1,\n> > +which in turn means that contributors must understand the full\n> > +provenance of what they are contributing. With AI content generators,\n> > +the copyright or license status of their output is ill-defined, without\n> > +any generally accepted legal foundation.\n>\n> Here we would forbid licensing any \"AI content generator\" output, not\n> just AI code generator output. So what we would forbid might be more\n> general than what QEMU folks forbid. For example they might still\n> accept a new logo, or even commit messages, made using an AI while we\n> wouldn't.\n\nAs QEMU is part of the Conservancy, like Git, I wonder if they\nconsulted a Conservancy lawyer to come up with their wording? If they\ndid, maybe we could reuse that expertise?\n"},{"id":"521080","messageId":"xmqqms9nkhms.fsf@gitster.g","threadId":"63716","inReplyTo":"CAP8UFD0bd1PD03VPaenAd+76Q6CeCOmDOJsso1nMKk4tZ4vbMg@mail.gmail.com","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-01T16:20:11Z","receivedAt":"2025-07-01T16:20:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n>> +\n>> +[[ai]]\n>> +=== Use of AI content generators\n>> +\n>> +This project requires that contributors certify that their\n>> +contributions are made under Developer's Certificate of Origin 1.1,\n>> +which in turn means that contributors must understand the full\n>> +provenance of what they are contributing. With AI content generators,\n>> +the copyright or license status of their output is ill-defined, without\n>> +any generally accepted legal foundation.\n>\n> Here we would forbid licensing any \"AI content generator\" output, not\n> just AI code generator output. So what we would forbid might be more\n> general than what QEMU folks forbid. For example they might still\n> accept a new logo, or even commit messages, made using an AI while we\n> wouldn't.\n\nI didn't think about the distinction you are trying to draw when I\nwrote the patch, but after thinking about it, I think it is a good\nthing to prevent us from adopting a new logo graphics somebody may\nhave ownership rights without us knowing. I would consider the\ncommit log message as an integral part of any \"contribution\", and\nread the word \"contribution\" used in the [[dco]] section as such, if\nthe rule covers the commit log message, that is very much\nappreciated.\n\n>> +Hence, the project asks that contributors refrain from using AI content\n>> +generators on changes that are submitted to the project.\n>\n> Here it looks like using an AI capable of generating content to just\n> check code that would be submitted could also be forbidden. I don't\n> think this is what we want, so I think we might want to reword this.\n\nGood point. Asking agents to proofread and suggest improvements is\nlike asking your friends to do so. Care to suggest replacement to\nthese two sentences (above and below)?\n\n>> +Contributions in which use of AI is either known or suspected may not\n>> +be accepted.\n>\n> Here also \"use of AI\" might forbid checking what we submit using any AI tool.\n\nThanks.\n\n"},{"id":"521091","messageId":"xmqq4ivvlss8.fsf@gitster.g","threadId":"63716","inReplyTo":"CAP8UFD3DCi5n12HpYwuF4Sh4gG-B98a57HBpDAB+uPrqJcN+jQ@mail.gmail.com","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-01T17:33:59Z","receivedAt":"2025-07-01T17:34:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> As QEMU is part of the Conservancy, like Git, I wonder if they\n> consulted a Conservancy lawyer to come up with their wording? If they\n> did, maybe we could reuse that expertise?\n\nOr grab their wording wholesale, perhaps?\n\n https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048\n\nis the commit they added it to their policy.\n\nThanks.\n"},{"id":"521550","messageId":"CAP8UFD1StfAY3kLNmCtBJrCVM9ADuDVjQ-WC=9yMdSSouLLCbw@mail.gmail.com","threadId":"63716","inReplyTo":"xmqqms9nkhms.fsf@gitster.g","subject":"Re: [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-07-08T14:23:26Z","receivedAt":"2025-07-08T14:23:39Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jul 1, 2025 at 6:20 PM Junio C Hamano wrote:\n>\n> Christian Couder writes:\n\n> > Here we would forbid licensing any \"AI content generator\" output, not\n> > just AI code generator output. So what we would forbid might be more\n> > general than what QEMU folks forbid. For example they might still\n> > accept a new logo, or even commit messages, made using an AI while we\n> > wouldn't.\n>\n> I didn't think about the distinction you are trying to draw when I\n> wrote the patch, but after thinking about it, I think it is a good\n> thing to prevent us from adopting a new logo graphics somebody may\n> have ownership rights without us knowing. I would consider the\n> commit log message as an integral part of any \"contribution\", and\n> read the word \"contribution\" used in the [[dco]] section as such, if\n> the rule covers the commit log message, that is very much\n> appreciated.\n\nI am not sure about logos, but for the commit message, it seems to me\nthat it could have drawbacks related to translation or wordings.\n\nFor example if someone is not a good English writer, they could write\na commit message in their native language and then ask an AI to\ntranslate it. Or they could write it in their bad English and then ask\nan AI to improve the wordings. I am not sure we want to forbid all\nthat.\n\n> >> +Hence, the project asks that contributors refrain from using AI content\n> >> +generators on changes that are submitted to the project.\n> >\n> > Here it looks like using an AI capable of generating content to just\n> > check code that would be submitted could also be forbidden. I don't\n> > think this is what we want, so I think we might want to reword this.\n>\n> Good point. Asking agents to proofread and suggest improvements is\n> like asking your friends to do so. Care to suggest replacement to\n> these two sentences (above and below)?\n\nI could try but I would feel better if we tried to find and ask people\naround who have thought about this subject already.\n\nEspecially I think it's difficult to draw the line between a tool that\nsuggests improvements and a tool that generates content. For example\nif I were a very bad English writer and asked an AI to suggest\nimprovements to a commit message I wrote, then the AI might actually\nrewrite nearly everything and the result could be very similar to what\nthe AI would have generated in the first place based only on the diff\npart of the patch.\n"},{"id":"527680","messageId":"20251001140310.527097-1-christian.couder@gmail.com","threadId":"63716","inReplyTo":"xmqqcyalm0mh.fsf@gitster.g","subject":"[PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-01T14:02:50Z","receivedAt":"2025-10-01T14:03:30Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"As more and more developer tools use AI, we are facing two main risks\nrelated to AI generated content:\n\n - its situation regarding copyright and license is not clear,\n and:\n\n - more and more bad quality content could be submitted for review to\n the mailing list.\n\nTo mitigate both risks, let's add an \"Use of Artificial Intelligence\"\nsection to \"Documentation/SubmittingPatches\" with the goal of\ndiscouraging its blind use to generate content that is submitted to\nthe project, while still allowing us to benefit from its help in some\ninnovative, useful and less risky ways.\n\nHelped-by: Rick Sanders \nSigned-off-by: Christian Couder \n\n---\nThis is inspired by the \"AI guidelines\" section we already have for\nmentoring programs (like GSoC or Outreachy) in:\n\nhttps://git.github.io/General-Application-Information/\n\nwhich was discussed briefly in a PR\n(https://github.com/git/git.github.io/pull/771)\nand in a small thread on the mailing list\n(https://lore.kernel.org/git/CAP8UFD37_qsTjM97GK2EOWHteqoUKdwxjKS-SU629H2LnbTTtA@mail.gmail.com/).\n\n Documentation/SubmittingPatches | 28 ++++++++++++++++++++++++++++\n 1 file changed, 28 insertions(+)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 86ca7f6a78..04191e2945 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -446,6 +446,34 @@ highlighted above.\n Only capitalize the very first letter of the trailer, i.e. favor\n \"Signed-off-by\" over \"Signed-Off-By\" and \"Acked-by:\" over \"Acked-By\".\n \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+\n [[git-tools]]\n === Generate your patch using Git tools out of your commits.\n \n-- \n2.51.0.195.ge34f015aea.dirty\n\n"},{"id":"527716","messageId":"DD77TA1H1OOO.351R9WDH93UZ5@wolber.net","threadId":"63716","inReplyTo":"20251001140310.527097-1-christian.couder@gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Chuck Wolber","fromEmail":"chuck@wolber.net","sentAt":"2025-10-01T18:59:31Z","receivedAt":"2025-10-01T18:59:34Z","isPatch":true,"sender":{"key":"chuck@wolber.net","avatar":null},"body":"On Wed Oct 1, 2025 at 2:03 PM UTC, Christian Couder wrote:\n\n> To mitigate both risks, let's add an \"Use of Artificial Intelligence\"\n> section to \"Documentation/SubmittingPatches\" with the goal of\n> discouraging its blind use to generate content that is submitted to\n> the project, while still allowing us to benefit from its help in some\n> innovative, useful and less risky ways.\n\nI love the intent here, but it does not seem like that came through in the\nproposed patch.\n\nI think this patch opens the door to some concerning issues, including the\npotential for false accusations and inconsistent treatment of human (non-AI)\ngenerated contributions.\n\nSticking to a message of self-reliance (e.g. responsible AI use) and making\nsome technical changes to mark AI content might be a better approach.\n\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\nThe legal issues around AI will be resolved in time, but the future will not\nstop bringing us a steady stream of things that create legal ambiguity.\n\nCreating one-off sections that cover _multiple_ topics _including_ legal\nambiguity seems like it risks reducing clarity. To get the full picture, this\npatch (and patches like it in the future) require me to navigate multiple\nsections to understand all of the project's relevant legal concerns.\n\nI also have two specific concerns with the wording:\n\n1. It repeats what is said just a few paragraphs earlier in the document. I\nunderstand _why_ it does this, but moving the essence of this topic up to the\nDCO section avoids the repetition and avoids diluting the project's legal\nguidance.\n\n2. What am I supposed to do with \"It's not yet clear\"? This is worse than\ntelling me nothing. It introduces a vague question with no clear guidance. It\nis _true_ that no clear guidance exists, but what are the consequences when it\n_does_ exist? The worst case scenario is that we have to go back and\nrework/remove AI generated patches. So why not just require something like a\ndeclaration of AI content like the one proposed at declare-ai.org?\n\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\nThat reads like a full stop rejection of all AI generated patch content.\n\nWhat if AI were to generate a great patch whose technical quality is exemplary\nin every way? How is that any different from a great patch of exemplary\ntechnical quality submitted by a person who is unambiguosly evil?\n\nBut perhaps you intended it to mean a full stop rejection of content that\n_looks_ like it was generated by the primitive AI we have _today_? Even going\nwith the interpretation you likely intended opens up a concerning double\nstandard.\n\nWhat if a patch \"looks\" AI generated, but in reality was wholly geneated by a\nhuman? Does this mean that patches generated by humans that fit the declared\ncriteria would be treated as if they were AI generated?\n\nWhat about a non-native speaker who uses AI in an attempt to bridge a language\nbarrier? By definition they would lack the ability to judge the degree to which\ntheir patch suddenly meets your criteria.\n\nHow is any of that fair, and how could you even tell the difference?\n\nAnd on a personal note, the subjective wording gives me a \"walking on\neggshells\" feeling. It opens the door for false accusations, and gets us away\nfrom judging things _purely_ on their technical merit.\n\nWould it not be more _consistent_ to continue saying what is already true? That\nyour patches _must_ be remarkably high quality regardless of how they were\ncreated?\n\nWith the addition of a required AI declaration (again, check out declare-ai.org\nfor an example of what that might look like), I think you cover all of the\nnecessary bases. And sure, someone could lie. But they can lie about meeting\nthe DCO as well. The consequences are the same - remove/rework.\n\n\n> +We strongly recommend using AI tools carefully and responsibly.\n\nAgreed, but I think you lost me here.\n\nTaking your words at face value, the prior paragraph reads as if the Git\nproject is declaring an outright ban on _all_ AI generated content (and I am\nnearly certain that is _not_ what you intended to say). If so, why bother\ncontinuing on with a PSA (Public Safety Announcement)? It reads like a\nnon-alcoholic drink that has the words, \"Drink Responsibly\" printed on the side\nof the can.\n\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\nI think this is very useful guidance. And although it is timely, I think it\nstands a good chance of being timeless, even when AI becomes far more competent\nthan it is today.\n\nAI is not going away, and we need to find a way to use it productively\n_without_ losing our sense of self-reliance. If we fail to develop this ability\nwhen AI is hardly more skilled than an above average intern, full of hubris and\nzero real world experience, imagine how unqualified we will be when AI becomes\ncompetent enough to manipulate and mislead us?\n\n\nOverall, I feel like an addition to the documentation is warranted, but this\nversion makes me uncomfortable if not a little unwelcome. Making a techncial\nchange to the required declarations and expanding on the theme of self-reliance\nand responsible use feels like a more productive way to address this issue.\n\nPutting my \"money where my mouth is\", I am more than happy to suggest a\nrevision to this patch if you would like. I wanted to avoid that right now\nbecause it seemed like a dialog was warranted first.\n\n..Ch:W..\n\n"},{"id":"527725","messageId":"xmqq4isi1gpm.fsf@gitster.g","threadId":"63716","inReplyTo":"20251001140310.527097-1-christian.couder@gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-01T20:59:17Z","receivedAt":"2025-10-01T20:59:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> As more and more developer tools use AI, we are facing two main risks\n> related to AI generated content:\n>\n> - its situation regarding copyright and license is not clear,\n> and:\n>\n> - more and more bad quality content could be submitted for review to\n> the mailing list.\n>\n> To mitigate both risks, let's add an \"Use of Artificial Intelligence\"\n> section to \"Documentation/SubmittingPatches\" with the goal of\n> discouraging its blind use to generate content that is submitted to\n> the project, while still allowing us to benefit from its help in some\n> innovative, useful and less risky ways.\n>\n> Helped-by: Rick Sanders \n> Signed-off-by: Christian Couder \n>\n> ---\n> This is inspired by the \"AI guidelines\" section we already have for\n\nA more important thing to mention is that Rick is a lawyer at SFC\nhelped us to draft the wording used in this one.\n\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\nA milder way to phrase this would be to jump directly to \"we reject\nwhat the sender cannot explain when asked about it\". \"How does this\nwork?\" \"Why is this a good thing to do?\" \"Where did it come from?\"\ninstead of saying \"looks AI generated\".\n\nIt would sidestep the \"who decides if it looks AI generated?\" question.\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> +\n> [[git-tools]]\n> === Generate your patch using Git tools out of your commits.\n\n\nThanks.\n"},{"id":"527732","messageId":"aN2fG-nS9fE5-2jD@fruit.crustytoothpaste.net","threadId":"63716","inReplyTo":"20251001140310.527097-1-christian.couder@gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-01T21:37:31Z","receivedAt":"2025-10-01T21:37:33Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-01 at 14:02:50, Christian Couder wrote:\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\nPerhaps we'd like to write this:\n\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 so we cannot accept this content in our project.\n\nIf we're going to have a policy, we need to be direct about it and not\nlet people draw their own conclusions. Many people don't have English\nas a first language and we don't want people trying to language lawyer.\n\nWe could say something like this:\n\n Please do not sign off your work if you’re using an LLM to contribute\n unless you have included copyright and license information for all the\n code used in that LLM.\n\nThis allows the possibility that, say, Google trains an LLM entirely on\ntheir own code, such that there is only one copyright holder and they\ncan license it as they see fit. I don't think we _need_ to consider\nthat case if we don't want to allow that (say, for code quality\nreasons), but we could if we wanted to.\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\nI've definitely seen this. LLMs also typically do not write nice,\nlogical, bisectable commits, which I personally dislike as a reviewer.\n\n> +We strongly recommend using AI tools carefully and responsibly.\n\nI think this is maybe not definitive enough. If we don't believe it's\npossible to sign-off when code is generated using LLMs, then we should\nsay definitively, \"Contributors may not use AI to write contributions to\nGit,\" or something similarly clear.\n\nRight now, this sounds too ambiguous and it might allow someone to write\nsubstantial code that they think is of good quality using an LLM because\nin their view that's careful and responsible, when we don't think that\nusers can sign off on that and therefore that's not possible. Telling\npeople to use tools \"carefully and responsibly\" is like telling people\nto drive \"a reasonable and prudent speed\" without further qualification\nand then being surprised when they go 200 km/hr down the road.\n\nI'd like to see the language be more like our code of conduct in that it\nis broad and covers a wide variety of behaviour but also explicitly\nstates what is and is not acceptable to avoid ambiguity, confusion, or\nargument.\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\nThis kind of use I feel is less objectionable. I think it might be\nacceptable to use an LLM as a guide, a linter, or a first-pass code\nreview.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"527744","messageId":"aN26C68pxi-eJgn8@fruit.crustytoothpaste.net","threadId":"63716","inReplyTo":"DD77TA1H1OOO.351R9WDH93UZ5@wolber.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-01T23:32:27Z","receivedAt":"2025-10-01T23:32:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-01 at 18:59:31, Chuck Wolber wrote:\n> 1. It repeats what is said just a few paragraphs earlier in the document. I\n> understand _why_ it does this, but moving the essence of this topic up to the\n> DCO section avoids the repetition and avoids diluting the project's legal\n> guidance.\n> \n> 2. What am I supposed to do with \"It's not yet clear\"? This is worse than\n> telling me nothing. It introduces a vague question with no clear guidance. It\n> is _true_ that no clear guidance exists, but what are the consequences when it\n> _does_ exist? The worst case scenario is that we have to go back and\n> rework/remove AI generated patches. So why not just require something like a\n> declaration of AI content like the one proposed at declare-ai.org?\n\nI agree that this is unclear, which is why I suggested we be more\ndefinitive.\n\nMany of the companies that develop LLMs are headquartered in the United\nStates. Many of the people that contribute to Git or distribute Git are\nnot. For instance, I am located in Canada, which has different\ncopyright laws (we have the more limited fair dealing like the UK,\ninstead of the US's fair use) and has moral rights. It is entirely\npossible that the use of an LLM could be legal in one country or\njurisdiction but not another.\n\nBy accepting code that is written using LLMs into Git, we expose our\ncontributors (who implicitly distribute Git code by uploading it to\nservers) and distributors (such as Linux distros or their distributors)\nto potential liability if the use of a particular LLM or LLMs in general\nare found to be illegal in their jurisdiction. Unlike most of the\ncompanies that develop LLMs, most contributors and distributors of Git\nare individuals or non-profits with limited resources. Even as someone\nwho works in the tech industry and is paid accordingly, defending a\ncopyright claim would be extremely expensive and probably financially\ndevastating for me and I really do not want to take that risk.\n\nThat's why simply declaring LLM use is not acceptable: because it\nexposes others who have limited resources to legal risk. Note that\nripping it out afterwards would require rewriting the Git history and\nwould not solve the problem of all of the people who are distributing or\nusing older versions (which would have been judged to violate copyright\nlaw) or relieve them of the fact that they would have been exposed to\nlegal liability for their distribution.\n\nThe avoidance of legal problems is why we require sign-off. If\nDeveloper X signs off a patch that was later judged to violate copyright\nlaw, then they have made a legally binding statement to that effect and\nthey have effectively accepted the entire legal liability for that[0]. If\nwe don't believe people can legally make certain types of contributions,\nthen we should explicitly tell people that they should not make that\nlegal statement to avoid any ambiguity.\n\nThis is very different from situations where companies make a decision\nto incorporate LLM-generated code into their own codebases. They can\nhire lawyers to determine whether LLM-generated code is legal in their\ngiven jurisdiction and obtain whatever legal necessities are required to\noperate in compliance with the law. They also usually have substantial\nresources to address any problems that come up. We, on the other hand,\nare effectively a global project, must engage in behaviour that is legal\nin all or nearly all jurisdictions, and have very limited resources.\n\n> That reads like a full stop rejection of all AI generated patch content.\n> \n> What if AI were to generate a great patch whose technical quality is exemplary\n> in every way? How is that any different from a great patch of exemplary\n> technical quality submitted by a person who is unambiguosly evil?\n\nThere are a couple of problems here: one, some AI code (including\ndocumentation or other text) is of poor quality; two, regardless of the\nquality, many people submit AI-generated code they do not understand;\nand three, AI-generated code is a legal minefield.\n\nA technically great patch solves the first but not the other two. We\nstill need people who submit code to be able to explain their changes\nand respond to questions about the code. What decisions were made? Why\nwere they made? What are the tradeoffs and downsides?\n\n> Taking your words at face value, the prior paragraph reads as if the Git\n> project is declaring an outright ban on _all_ AI generated content (and I am\n> nearly certain that is _not_ what you intended to say). If so, why bother\n> continuing on with a PSA (Public Safety Announcement)? It reads like a\n> non-alcoholic drink that has the words, \"Drink Responsibly\" printed on the side\n> of the can.\n\nI think this is actually what they intended to say, but did so poorly.\nI agree clarification would be valuable.\n\n> AI is not going away, and we need to find a way to use it productively\n> _without_ losing our sense of self-reliance. If we fail to develop this ability\n> when AI is hardly more skilled than an above average intern, full of hubris and\n> zero real world experience, imagine how unqualified we will be when AI becomes\n> competent enough to manipulate and mislead us?\n\nI think you assume LLMs can have intelligence. They are glorified\nprediction engines, effectively fancy Markov chains. In some cases,\nthat can be useful and valuable and we can do interesting things with\nthem, but they cannot actually have intelligence, creativity or reason.\n\nAnd LLMs already manipulate and mislead people. They have been\nimplicated in goading teenagers to suicide or leading people into\nconspiracy theories. Some LLMs espouse racist, anti-Semitic, or\notherwise hateful views. That's a good reason to be wary of them and\nhow they're incorporated to our lives, at least until such a time that\nthey have appropriate safety measures and regulation in place (if that\never happens).\n\n[0] I refer you to the common-law doctrine of promissory estoppel.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"527745","messageId":"41F7B31F-1CED-4A74-A69C-1C3D61B10A42@gmail.com","threadId":"63716","inReplyTo":"aN26C68pxi-eJgn8@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-02T02:30:42Z","receivedAt":"2025-10-02T02:30:54Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 1 oct. 2025 à 19:44, brian m. carlson a écrit :\n> \n> On 2025-10-01 at 18:59:31, Chuck Wolber wrote:\n> \n>> AI is not going away, and we need to find a way to use it productively\n>> _without_ losing our sense of self-reliance. If we fail to develop this ability\n>> when AI is hardly more skilled than an above average intern, full of hubris and\n>> zero real world experience, imagine how unqualified we will be when AI becomes\n>> competent enough to manipulate and mislead us?\n> \n> I think you assume LLMs can have intelligence. They are glorified\n> prediction engines, effectively fancy Markov chains. In some cases,\n> that can be useful and valuable and we can do interesting things with\n> them, but they cannot actually have intelligence, creativity or reason.\n> \n> And LLMs already manipulate and mislead people. They have been\n> implicated in goading teenagers to suicide or leading people into\n> conspiracy theories. Some LLMs espouse racist, anti-Semitic, or\n> otherwise hateful views. That's a good reason to be wary of them and\n> how they're incorporated to our lives, at least until such a time that\n> they have appropriate safety measures and regulation in place (if that\n> ever happens).\n\nA tangent, and one I’m happy to continue but off-list (I’m happy to continue publicly, but this is not the forum): I’d encourage folks to give the LLMentalist Effect [1] a read. Regardless of where you fall on “intelligence vs stochastic parrot,” I think you’ll find some interesting conclusions.\n\n[1]: https://softwarecrisis.dev/letters/llmentalist"},{"id":"527870","messageId":"CAP8UFD3wc-aj27Q_kFXvknJrpa-ySWbZiPmNCTMboA08=HP+xw@mail.gmail.com","threadId":"63716","inReplyTo":"xmqq4isi1gpm.fsf@gitster.g","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-03T08:51:13Z","receivedAt":"2025-10-03T08:51:26Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Oct 1, 2025 at 10:59 PM Junio C Hamano wrote:\n>\n> Christian Couder writes:\n>\n> > As more and more developer tools use AI, we are facing two main risks\n> > related to AI generated content:\n> >\n> > - its situation regarding copyright and license is not clear,\n> > and:\n> >\n> > - more and more bad quality content could be submitted for review to\n> > the mailing list.\n> >\n> > To mitigate both risks, let's add an \"Use of Artificial Intelligence\"\n> > section to \"Documentation/SubmittingPatches\" with the goal of\n> > discouraging its blind use to generate content that is submitted to\n> > the project, while still allowing us to benefit from its help in some\n> > innovative, useful and less risky ways.\n> >\n> > Helped-by: Rick Sanders \n> > Signed-off-by: Christian Couder \n> >\n> > ---\n> > This is inspired by the \"AI guidelines\" section we already have for\n>\n> A more important thing to mention is that Rick is a lawyer at SFC\n> helped us to draft the wording used in this one.\n\nYeah, right, I will mention it in a v3 if there is one.\n\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> A milder way to phrase this would be to jump directly to \"we reject\n> what the sender cannot explain when asked about it\". \"How does this\n> work?\" \"Why is this a good thing to do?\" \"Where did it come from?\"\n> instead of saying \"looks AI generated\".\n>\n> It would sidestep the \"who decides if it looks AI generated?\" question.\n\nI don't think the \"who decides if it looks AI generated?\" question is\nvery relevant. If someone says that a patch looks mostly AI generated\nand gives a good argument supporting this claim, it's the same as if\nsomeone gives any other good argument against the patch. In the end,\nthe community and you decide if the argument is good enough and if the\npatch should be rejected based on that (and other arguments for and\nagainst the patch of course).\n\nFor example, let's suppose that in the future someone knows that\nChatGPT7 is very likely to use double dash (\"--\") and the word\n\"absolutely\" a lot in its sentences, and notices that a contributor\nsent a long documentation patch that is full of them. I would say that\nit would be a good argument to reject that patch. We could be wrong in\nrejecting the patch because of that argument, because maybe the\nwriter's style happens to be similar to ChatGPT7's style, but I think\nwe should have the possibility to reject such patches based on the\nfact that they definitely look AI generated. Otherwise I don't think\nwe can seriously claim that we try to uphold the DCO as well as we\ncan.\n\nSo I think we definitely need to say something like \"we will reject\nanything that looks AI generated\" or maybe \"we will reject anything\nthat looks significantly AI generated\". In the v3 if there is one, I\nwill change the wording to the latter.\n\nThanks.\n"},{"id":"527878","messageId":"CAP8UFD1Yso0NnwOVyy5bRA1ufgrjSjTXHOPeQ6us5pUX--P3rw@mail.gmail.com","threadId":"63716","inReplyTo":"DD77TA1H1OOO.351R9WDH93UZ5@wolber.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-03T13:33:12Z","receivedAt":"2025-10-03T13:33:26Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Oct 1, 2025 at 8:59 PM Chuck Wolber wrote:\n>\n> On Wed Oct 1, 2025 at 2:03 PM UTC, Christian Couder wrote:\n>\n> > To mitigate both risks, let's add an \"Use of Artificial Intelligence\"\n> > section to \"Documentation/SubmittingPatches\" with the goal of\n> > discouraging its blind use to generate content that is submitted to\n> > the project, while still allowing us to benefit from its help in some\n> > innovative, useful and less risky ways.\n>\n> I love the intent here, but it does not seem like that came through in the\n> proposed patch.\n>\n> I think this patch opens the door to some concerning issues, including the\n> potential for false accusations and inconsistent treatment of human (non-AI)\n> generated contributions.\n\nI don't think the patch changes anything regarding false accusation\nand inconsistent treatment of human generated contributions.\n\n> Sticking to a message of self-reliance (e.g. responsible AI use) and making\n> some technical changes to mark AI content might be a better approach.\n\nI don't think we want to mark AI content. It would be too much of a\nburden managing this especially knowing the limit of what should be\nmarked or not.\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> The legal issues around AI will be resolved in time, but the future will not\n> stop bringing us a steady stream of things that create legal ambiguity.\n>\n> Creating one-off sections that cover _multiple_ topics _including_ legal\n> ambiguity seems like it risks reducing clarity. To get the full picture, this\n> patch (and patches like it in the future) require me to navigate multiple\n> sections to understand all of the project's relevant legal concerns.\n\nI don't think having this section on top of the rest is a big burden\nfor developers in general. Perhaps you are very concerned about the\nlegal issues in the project you contribute to, but on the other hand\nthere weren't a lot of concerns when we added the similar AI\nguidelines in https://git.github.io/General-Application-Information/.\n\n> I also have two specific concerns with the wording:\n>\n> 1. It repeats what is said just a few paragraphs earlier in the document. I\n> understand _why_ it does this, but moving the essence of this topic up to the\n> DCO section avoids the repetition and avoids diluting the project's legal\n> guidance.\n\nBeing able to refer people to a single section about AI has some\nbenefits. If you have a wording that reduces the repetition while\nstill making the AI section easily understandable on its own, I am\nwilling to consider it for a v3 version of this patch.\n\n> 2. What am I supposed to do with \"It's not yet clear\"? This is worse than\n> telling me nothing. It introduces a vague question with no clear guidance. It\n> is _true_ that no clear guidance exists, but what are the consequences when it\n> _does_ exist? The worst case scenario is that we have to go back and\n> rework/remove AI generated patches.\n\nWhen guidance will exist, we might have to change our \"AI use\"\nsection, but we can deal with that then. It's better to adapt now to\nthe current situation as well as we can rather than try to anticipate\nthe future while we can't really know what it will look like.\n\nAnd if we have done our best to avoid accepting too much AI generated\ncontent now, then hopefully we won't have to go back and rework/remove\nmany AI generated patches.\n\n> So why not just require something like a\n> declaration of AI content like the one proposed at declare-ai.org?\n\nI think this could add a lot of complexity to the process. For example\npeople could be using many different AI tools in every contribution,\nlike:\n\n- for code completion,\n- for checking for memory leaks,\n- for checking for possible refactorings,\n- for commit message translation from their native language to English,\n- for email translation from their native language to English,\n- for better understanding the feedback they received,\n- for helping with the forge they are using (what if it performs\ninteractive rebases for example),\n- etc\n\nThey might not know where to stop and might not even know if their\nemail software (like GMail for example) is already using AI to help\nthem write messages.\n\nIt's also possible to ask different AIs to do the same job, for\nexample checking for errors in the patches that are about to be sent.\nWhat if some AIs find no improvements and others find some? Shoud what\nevery AI found be mentioned?\n\nWhat if AIs start debating between themselves whether something is an\nerror or not and cannot come to a conclusion? Should that debate be\nkept somehow?\n\nAnd no, this is not pure speculation. I talked recently to someone\nworking on an IDE and thinking about saving into Git all the AI\ncontext (including such AI debates) around some contributions to make\nsure it's available for other AIs and humans working down the road on\nfurther work based on those contributions.\n\nIn short if we now ask people to declare, then those who try to do the\nright thing will spend a lot of time figuring things out and being\nburdened for perhaps no good reason while those who won't care and\nwill do the worst on that will have the most benefits as they will not\nbe burdened and save a lot of time.\n\nIf automated processes are one day easily available to record some AI\ncontext, then I don't think we would be against them, and maybe we can\ndecide then to ask people to use them. But we are not there yet, we\ndon't know what they will look like and require, and it's just not our\nrole to push on this.\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> That reads like a full stop rejection of all AI generated patch content.\n\nIn a reply to Junio, I have suggested changing \"we will reject\nanything that looks AI generated\" to \"we will reject anything that\nlooks significantly AI generated\". I am open to tweaking that even\nmore, but we need to say somehow that submitting a lot of AI generated\ncontent as-is is not welcome. Otherwise we just don't mitigate the\nrisks we want to mitigate. (See my reply to Junio.)\n\n> What if AI were to generate a great patch whose technical quality is exemplary\n> in every way? How is that any different from a great patch of exemplary\n> technical quality submitted by a person who is unambiguosly evil?\n\nIf an AI were to generate a great patch no different than what a human\nwould generate, then we cannot say that it looks AI generated, and\nthen the only issue is \"Do we trust the person sending the patch?\". If\nthe person has sent a lot of patches that looked AI generated in the\npast, we might reject the patch based on that. Otherwise, the issue is\nthe same as if someone sends some proprietary code. Yeah, we could\naccept code that is proprietary if someone sends it to us and we don't\nrealize it's proprietary code, but then if they signed off the patch,\nthey are responsible for that according to the DCO.\n\n> But perhaps you intended it to mean a full stop rejection of content that\n> _looks_ like it was generated by the primitive AI we have _today_? Even going\n> with the interpretation you likely intended opens up a concerning double\n> standard.\n>\n> What if a patch \"looks\" AI generated, but in reality was wholly geneated by a\n> human?\n\nMistakes happen. We could indeed be wrong to reject the patch based on\nthat. See my reply to Junio about this.\n\nThe thing is that we cannot eat our cake and have it too. If we want\nto protect the project from risks related to too much AI generated\ncontent, we need to be able to reject such content based on some\ncriteria that are unlikely to be perfect.\n\n> Does this mean that patches generated by humans that fit the declared\n> criteria would be treated as if they were AI generated?\n\nPatches generated by humans that look like AI generated patches will\nprobably be treated as if they were AI generated. That's unfortunate,\nbut hopefully soon the few people who would generate patches that look\nlike AI generated patches will learn and will soon make their patches\nlook different than AI generated ones.\n\n> What about a non-native speaker who uses AI in an attempt to bridge a language\n> barrier? By definition they would lack the ability to judge the degree to which\n> their patch suddenly meets your criteria.\n\nThis is one of the reasons why this v2 is different from the previous\nv1. We don't outright reject any use of generative AI in this v2, we\nwant to say that the result shouldn't look like a lot of AI generated\ncontent sent as-is. If an AI was used to translate something that was\ninitially human generated, it will hopefully not sound like it was\nfully AI generated.\n\nAnd yeah mistakes can happen, but hopefully the community and the\nmaintainer will be able to learn and adapt from them and the process\nwill be relatively smooth after some time.\n\n> How is any of that fair, and how could you even tell the difference?\n\nIt's a judgment call, like when we decide if a patch is technically\ngood enough to be accepted. In practice I think we will often\nrecommend rewriting parts that look AI generated in the same way we\nask to rewrite bad code or bad commit messages. We might sometimes not\neven mention that it seems to us like it was AI generated.\n\nYou might say that it might then not be worth having an \"Use of AI\"\nsection in our SubmittingPatches document, but we think it's still\nuseful for different reasons like:\n\n- it shows that we are trying to do something against the AI related\nrisks, especially the legal one,\n- it might save us from reviewing AI generated content in the first\nplace if contributors read our SubmittingPatches document before\nworking on patches,\n- it could give contributors good ideas about how to use AI in acceptable ways,\n- it signals to our reviewers that they should speak up against, or\njust reject, what looks like a lot of AI generated content,\n- it gives reviewers the possibility to refer contributors to some\ndocumentation about the subject.\n\n> And on a personal note, the subjective wording gives me a \"walking on\n> eggshells\" feeling. It opens the door for false accusations, and gets us away\n> from judging things _purely_ on their technical merit.\n\nIf we see content in some patches that looks copyrighted by a company,\nand we are not confident that the company agreed to release it under a\ncompatible license, we can already reject it on non technical merit.\nWe could even already say something like:\n\n\"Your code looks obviously AI generated for such and such a reason. We\nare not sure that so much AI generated code is compatible with the DCO\nas the AI could have copy-pasted proprietary code it saw during its\ntraining. So we are going to reject it.\"\n\nSo things don't fundamentally change. In this regard, this patch just\nclarifies things for contributors and reviewers.\n\nIn some ways, the section that this patch adds is not different from\nother sections like for example \"Make separate commits for logically\nseparate changes.\" Yeah, perhaps many developers are unfortunately not\nused to making separate commits for logically separate changes, and\nthey put a lot of different things into a single commit, and they\ndon't want to spend time reworking their working commits. So they\nmight feel that their contributions are going to be judged on baseless\nred tape merit instead of the real thing. But anyway we state our\nstandards clearly, so they should know in advance how their\ncontributions are going to be judged.\n\n> Would it not be more _consistent_ to continue saying what is already true? That\n> your patches _must_ be remarkably high quality regardless of how they were\n> created?\n\nThe issue is that quality might not be defined in the same way by\neveryone. Some aspects of what we consider quality might be considered\notherwise (maybe \"useless red tape\") by some. So it's better to be\nexplicit as much as we can.\n\n> With the addition of a required AI declaration (again, check out declare-ai.org\n> for an example of what that might look like), I think you cover all of the\n> necessary bases. And sure, someone could lie. But they can lie about meeting\n> the DCO as well. The consequences are the same - remove/rework.\n>\n> > +We strongly recommend using AI tools carefully and responsibly.\n>\n> Agreed, but I think you lost me here.\n>\n> Taking your words at face value, the prior paragraph reads as if the Git\n> project is declaring an outright ban on _all_ AI generated content (and I am\n> nearly certain that is _not_ what you intended to say).\n\nYeah, we don't intend to ban _all_ AI generated content. Please\nsuggest other wordings if some sentences read like that.\n\nWhat we don't want is a lot of AI generated content that no human was\ninvolved in creating. If a human was involved in creating some\ncontent, then the human has at least some copyright and some\nresponsibility on it.\n\n> If so, why bother\n> continuing on with a PSA (Public Safety Announcement)? It reads like a\n> non-alcoholic drink that has the words, \"Drink Responsibly\" printed on the side\n> of the can.\n\nOn prescription and over-the-counter drug packaging there are\nsometimes \"Boxed Warning\" (or warnings along with a red warning\ntriangle pictogram in Europe) designed to alert people to potential\nside effects that could impair their ability to drive or operate heavy\nmachinery safely. This sentence (\"We strongly recommend using AI tools\ncarefully and responsibly.\") is a bit similar. It is intended to make\npeople who would machinally read or look at the document pause and\nthink for a bit. It's a good thing when used sparingly and for good\nreason which I think is the case here.\n\n[...]\n\n> Overall, I feel like an addition to the documentation is warranted, but this\n> version makes me uncomfortable if not a little unwelcome. Making a techncial\n> change to the required declarations and expanding on the theme of self-reliance\n> and responsible use feels like a more productive way to address this issue.\n>\n> Putting my \"money where my mouth is\", I am more than happy to suggest a\n> revision to this patch if you would like. I wanted to avoid that right now\n> because it seemed like a dialog was warranted first.\n\nThanks for the review and for the offer of a revision to this patch. I\nwould prefer not a full new version of the patch though, but rather\nsome suggestions for alternative wordings of some sentences.\n"},{"id":"527882","messageId":"CAP8UFD0=W3Mn8FQBmWFPN+3G9V73iorK-Y9Hs-LQ69hWCBeDOw@mail.gmail.com","threadId":"63716","inReplyTo":"aN2fG-nS9fE5-2jD@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-03T14:25:28Z","receivedAt":"2025-10-03T14:25:42Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Oct 1, 2025 at 11:37 PM brian m. carlson\n wrote:\n>\n> On 2025-10-01 at 14:02:50, Christian Couder wrote:\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> Perhaps we'd like to write this:\n>\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> so we cannot accept this content in our project.\n>\n> If we're going to have a policy, we need to be direct about it and not\n> let people draw their own conclusions. Many people don't have English\n> as a first language and we don't want people trying to language lawyer.\n\nI understand why you want to be direct, but unfortunately (or\nfortunately depending on your point of view) some generated content is\nacceptable if it is not too big, or if it is specific enough or if a\nhuman has been involved enough. In a number of cases like for example\ntranslated or reworded content, wrapping lines, refactored code, or\nrenamed variables, it is likely that a significant amount of content\nis acceptable because a human has already been involved and the\ncontent is specific enough. If we say right away that we cannot accept\nit, we might prevent interesting and useful use cases.\n\n> We could say something like this:\n>\n> Please do not sign off your work if you’re using an LLM to contribute\n> unless you have included copyright and license information for all the\n> code used in that LLM.\n\nFor now I don't think we want or need to be involved in checking or\ntrying to check what code and/or training data has been/is used in an\nLLM, what LLM(s) are used in which AI tools, all the AI tools that a\nuser might have used, etc. See my reply to Chuck Wolber's review\nrelated to declare-ai.org.\n\n> This allows the possibility that, say, Google trains an LLM entirely on\n> their own code, such that there is only one copyright holder and they\n> can license it as they see fit. I don't think we _need_ to consider\n> that case if we don't want to allow that (say, for code quality\n> reasons), but we could if we wanted to.\n\nI agree it would be nice if some LLMs were trained only on specific\ncode (or on no existing code at all) so that we could alleviate the\nlegal issue with them, but for now I don't think they exist. We can\nalways adapt later if/when they ever appear.\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> I've definitely seen this. LLMs also typically do not write nice,\n> logical, bisectable commits, which I personally dislike as a reviewer.\n>\n> > +We strongly recommend using AI tools carefully and responsibly.\n>\n> I think this is maybe not definitive enough. If we don't believe it's\n> possible to sign-off when code is generated using LLMs, then we should\n> say definitively, \"Contributors may not use AI to write contributions to\n> Git,\" or something similarly clear.\n\nI think it's far too restrictive for no good reason. See above and see\nmy discussion about this with Junio on the first version of this patch\nhe sent last July.\n\n> Right now, this sounds too ambiguous and it might allow someone to write\n> substantial code that they think is of good quality using an LLM because\n> in their view that's careful and responsible, when we don't think that\n> users can sign off on that and therefore that's not possible. Telling\n> people to use tools \"carefully and responsibly\" is like telling people\n> to drive \"a reasonable and prudent speed\" without further qualification\n> and then being surprised when they go 200 km/hr down the road.\n\nThe sentence (\"We strongly recommend using AI tools carefully and\nresponsibly.\") is designed to make people pause and think a bit when\nthey are reading machinally or just skimming the doc. It's not\ndesigned to set a clear limit on what is acceptable and what is not.\nAnd in fact it couldn't do so because there is no such clear limit.\n\n> I'd like to see the language be more like our code of conduct in that it\n> is broad and covers a wide variety of behaviour but also explicitly\n> states what is and is not acceptable to avoid ambiguity, confusion, or\n> argument.\n\nFeel free to make more suggestions. I don't think your goal is easy to\nachieve though.\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>\n> This kind of use I feel is less objectionable. I think it might be\n> acceptable to use an LLM as a guide, a linter, or a first-pass code\n> review.\n\nYeah, it looks like we all agree on that. The issue is that the limit\nbetween these acceptable kinds of use and other problematic ones is\nfuzzy.\n\nThanks.\n"},{"id":"527884","messageId":"xmqqjz1cufcd.fsf@gitster.g","threadId":"63716","inReplyTo":"CAP8UFD3wc-aj27Q_kFXvknJrpa-ySWbZiPmNCTMboA08=HP+xw@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-03T16:20:34Z","receivedAt":"2025-10-03T16:20:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n>> A milder way to phrase this would be to jump directly to \"we reject\n>> what the sender cannot explain when asked about it\". \"How does this\n>> work?\" \"Why is this a good thing to do?\" \"Where did it come from?\"\n>> instead of saying \"looks AI generated\".\n>>\n>> It would sidestep the \"who decides if it looks AI generated?\" question.\n>\n> I don't think the \"who decides if it looks AI generated?\" question is\n> very relevant. If someone says that a patch looks mostly AI generated\n> and gives a good argument supporting this claim, it's the same as if\n> someone gives any other good argument against the patch. In the end,\n> the community and you decide if the argument is good enough and if the\n> patch should be rejected based on that (and other arguments for and\n> against the patch of course).\n\nAnd then who plays the final arbiter? One can keep insisting on a\npatch that looks to me an apparent AI slop that it was what one\nwrote oneself, but you may find it a plausible that it was a human\ncreation. Then what?\n\nIt is very much relevant to avoid such argument, because the point\nis irrelevant. We are trying to avoid accepting something the\nsubmitter has no rights to claim theirs, and requesting them to\nexplain where it came from, how it works, etc. would be a better\ntest than \"does it look AI generated? to everybody?\", wouldn't it?\n"},{"id":"527888","messageId":"061a01dc3485$2ca50820$85ef1860$@nexbridge.com","threadId":"63716","inReplyTo":"xmqqjz1cufcd.fsf@gitster.g","subject":"RE: [PATCH v2] SubmittingPatches: add section about AI","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-03T16:45:43Z","receivedAt":"2025-10-03T16:48:21Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 3, 2025 12:21 PM, Junio C Hamano wrote:\n>Christian Couder writes:\n>\n>>> A milder way to phrase this would be to jump directly to \"we reject\n>>> what the sender cannot explain when asked about it\". \"How does this\n>>> work?\" \"Why is this a good thing to do?\" \"Where did it come from?\"\n>>> instead of saying \"looks AI generated\".\n>>>\n>>> It would sidestep the \"who decides if it looks AI generated?\" question.\n>>\n>> I don't think the \"who decides if it looks AI generated?\" question is\n>> very relevant. If someone says that a patch looks mostly AI generated\n>> and gives a good argument supporting this claim, it's the same as if\n>> someone gives any other good argument against the patch. In the end,\n>> the community and you decide if the argument is good enough and if the\n>> patch should be rejected based on that (and other arguments for and\n>> against the patch of course).\n>\n>And then who plays the final arbiter? One can keep insisting on a patch\nthat looks\n>to me an apparent AI slop that it was what one wrote oneself, but you may\nfind it a\n>plausible that it was a human creation. Then what?\n>\n>It is very much relevant to avoid such argument, because the point is\nirrelevant. We\n>are trying to avoid accepting something the submitter has no rights to\nclaim theirs,\n>and requesting them to explain where it came from, how it works, etc. would\nbe a\n>better test than \"does it look AI generated? to everybody?\", wouldn't it?\n\nCan the cover page from the originator contain statements that:\na) I (whomever it is) has the legal authority to the submitted patch without\nviolating any copyright.\nb) The code is original work and does not violate any IP laws where I\n(whomever)\nam located.\nc) The code is not generated from AI and/or despite being AI generated, I\n(whomever)\nhave verified that the code works as anticipated and does not contain AI\ncontents\ntrained from another code-base or project that might otherwise violate b),\nand that\nI (whomever) accept all responsibility for falsely making this statement.\n\nThis could be changed to an agreement maintained by the Conservancy prior to\nAccepting any non-trivial contributions providing the agreement is\nreferenced in\nEither the cover page or commit comments.\n\n"},{"id":"527906","messageId":"CABPp-BFcg9M=XjqGPd+akrUOqJqREBmE9+NvO1Q05r4pUcOmEQ@mail.gmail.com","threadId":"63716","inReplyTo":"aN2fG-nS9fE5-2jD@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-10-03T20:48:40Z","receivedAt":"2025-10-03T20:48:52Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Oct 1, 2025 at 2:37 PM brian m. carlson\n wrote:\n>\n> On 2025-10-01 at 14:02:50, Christian Couder wrote:\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> Perhaps we'd like to write this:\n>\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> so we cannot accept this content in our project.\n>\n> If we're going to have a policy, we need to be direct about it and not\n> let people draw their own conclusions. Many people don't have English\n> as a first language and we don't want people trying to language lawyer.\n>\n> We could say something like this:\n>\n> Please do not sign off your work if you’re using an LLM to contribute\n> unless you have included copyright and license information for all the\n> code used in that LLM.\n\nWould this mean that you wanted to ban contributions like d12166d3c8bb\n(Merge branch 'en/docfixes', 2023-10-23), available on the list over\nat https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n? We don't need to go theoretical, I've already contributed such a\npatch series before -- 2 years ago -- and it was merged. Granted,\nthat was entirely documentation, and I called out the usage of AI in\nthe cover letter, and I manually checked every change (discarding many\nof them) and split it into commits on my own, could easily explain any\nchange and why it was good, etc. And I was upfront about all of it.\n\nIf any use of AI is bad, do we need to revert that series?\n"},{"id":"527912","messageId":"aOBMHqLxNd86vgjH@fruit.crustytoothpaste.net","threadId":"63716","inReplyTo":"CABPp-BFcg9M=XjqGPd+akrUOqJqREBmE9+NvO1Q05r4pUcOmEQ@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-03T22:20:14Z","receivedAt":"2025-10-03T22:20:16Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-03 at 20:48:40, Elijah Newren wrote:\n> Would this mean that you wanted to ban contributions like d12166d3c8bb\n> (Merge branch 'en/docfixes', 2023-10-23), available on the list over\n> at https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n> ? We don't need to go theoretical, I've already contributed such a\n> patch series before -- 2 years ago -- and it was merged. Granted,\n> that was entirely documentation, and I called out the usage of AI in\n> the cover letter, and I manually checked every change (discarding many\n> of them) and split it into commits on my own, could easily explain any\n> change and why it was good, etc. And I was upfront about all of it.\n\nI think the main problem here is that we don't know the copyright\nstatus of LLM outputs. It is not uncommon for them to produce output\nthat reflects their training input and we see evidence of that in, for\ninstance, the New York Times lawsuit against OpenAI.\n\nAs I said, the situation is very unclear legally, with active litigation\nin multiple countries, and we have to comply with pretty much every\ncountry's laws in this situation. Whether something is legal in the\nUnited States, where you're located, is completely irrelevant to whether\nit is legal in Canada, where I'm located, or Germany or the UK, where we\nhave other contributors. We also have to consider whether it's legal in\nall of the countries that Git is distributed in, which includes every\ncountry in which Debian has a mirror[0], even countries under\ninternational sanctions, such as Iran, Russia, and Belarus.\n\nIt doesn't matter if the person using AI has indemnification, either,\nsince that only covers civil matters, and at least in the U.S. and\nCanada, knowingly violating copyright is also a criminal offence.\n\nThe sign-off process is designed to clearly state that a person has the\nability to contribute code under the license and I don't think, as\nthings stand, it's possible to make that assertion with code or\ndocumentation generated from an LLM except in very limited\ncircumstances. I don't allow LLM-generated code in my personal projects\nthat require sign-off for that reason, and neither does QEMU[1]. I\ndon't think I could honestly assert either (a) or (b) in the DCO with\nLLM-generated code because it's not clear to me whether \"I have the\nright to submit it under the…license.\"\n\nTo quote the QEMU policy:\n\n To satisfy the DCO, the patch contributor has to fully understand the\n copyright and license status of content they are contributing to QEMU. With AI\n content generators, the copyright and license status of the output is\n ill-defined with no generally accepted, settled legal foundation.\n\n Where the training material is known, it is common for it to include large\n volumes of material under restrictive licensing/copyright terms. Even where\n the training material is all known to be under open source licenses, it is\n likely to be under a variety of terms, not all of which will be compatible\n with QEMU's licensing requirements.\n\nI remember the SCO situation with Linux and how it really created a lot\nof uncertainty with Linux because SCO created FUD around Linux licensing\nand how that led to the DCO being created. I am aware of the fact that\nmany open source contributors are very unhappy that their code has been\nused to train LLMs without retaining credits and copyright notices or\nhonouring the license terms[2]. And I have spent many years working\nwith non-profits[3], where I have always been taught that we should\navoid even the appearance of impropriety.\n\nIt may matter less what the situation actually ends up being legally\n(although it could end up being quite bad) and more whether someone can\nimply or suggest that Git is not being distributed in compliance with\nthe license or contains infringing code, which could effectively make it\nundistributable because nobody wants to take that risk. And litigation,\neven if Git and its contributors are successful, can be extraordinarily\nexpensive.\n\nSo I think, given the circumstances, yes, the right thing to do is to\nban LLM-generated contributions with a policy very similar or identical\nto QEMU's. If, in the future, the legal situation changes and it\nbecomes unambiguously legal to use LLMs across the world, then we can\nreconsider that policy then.\n\n[0] https://www.debian.org/mirror/list\n[1] https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048\n[2] Regardless of the legal concerns, this implicates professional\nethics concerns, such as §1.5 of the ACM Code of Ethics[4]. Ethics\nrequirements usually go well beyond what the law requires.\n[3] Software Freedom Conservancy, which handles legal matters for the\nGit project, is a non-profit.\n[4] https://www.acm.org/code-of-ethics\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"528008","messageId":"xmqqh5wbq5z8.fsf@gitster.g","threadId":"63716","inReplyTo":"aOBMHqLxNd86vgjH@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-06T17:45:31Z","receivedAt":"2025-10-06T17:45:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> It may matter less what the situation actually ends up being legally\n> (although it could end up being quite bad) and more whether someone can\n> imply or suggest that Git is not being distributed in compliance with\n> the license or contains infringing code, which could effectively make it\n> undistributable because nobody wants to take that risk. And litigation,\n> even if Git and its contributors are successful, can be extraordinarily\n> expensive.\n>\n> So I think, given the circumstances, yes, the right thing to do is to\n> ban LLM-generated contributions with a policy very similar or identical\n> to QEMU's. If, in the future, the legal situation changes and it\n> becomes unambiguously legal to use LLMs across the world, then we can\n> reconsider that policy then.\n\nOK, so here is theirs for further discussion minimally adjusted for\nour use. I do not see much difference at least in spirit with what\nstarted this thread, but phrasing is certainly firmer, and I have no\nproblem with it.\n\n\n\nUse of AI content generators\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nTL;DR:\n\n **Current Git project policy is copied from what QEMU does. To\n DECLINE any contributions which are believed to include or derive\n from AI generated content. This includes ChatGPT, Claude, Copilot,\n Llama and similar tools.**\n\nThe increasing prevalence of AI-assisted software development results in a\nnumber of difficult legal questions and risks for software projects, including\nGit. Of particular concern is content generated by `Large Language Models\n`__ (LLMs).\n\nThe Git community requires that contributors certify their patch submissions\nare made in accordance with the rules of the `Developer's Certificate of\nOrigin (DCO) `.\n\nTo satisfy the DCO, the patch contributor has to fully understand the\ncopyright and license status of content they are contributing to Git. With AI\ncontent generators, the copyright and license status of the output is\nill-defined with no generally accepted, settled legal foundation.\n\nWhere the training material is known, it is common for it to include large\nvolumes of material under restrictive licensing/copyright terms. Even where\nthe training material is all known to be under open source licenses, it is\nlikely to be under a variety of terms, not all of which will be compatible\nwith Git's licensing requirements.\n\nHow contributors could comply with DCO terms (b) or (c) for the output of AI\ncontent generators commonly available today is unclear. The Git project is\nnot willing or able to accept the legal risks of non-compliance.\n\nThe Git project thus requires that contributors refrain from using AI content\ngenerators on patches intended to be submitted to the project, and will\ndecline any contribution if use of AI is either known or suspected.\n\nThis policy does not apply to other uses of AI, such as researching APIs or\nalgorithms, static analysis, or debugging, provided their output is not to be\nincluded in contributions.\n\nExamples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's\nChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content\ngeneration agents which are built on top of such tools.\n\nThis policy may evolve as AI tools mature and the legal situation is\nclarifed. In the meanwhile, requests for exceptions to this policy will be\nevaluated by the Git project on a case by case basis. To be granted an\nexception, a contributor will need to demonstrate clarity of the license and\ncopyright status for the tool's output in relation to its training model and\ncode, to the satisfaction of the project maintainers.\n"},{"id":"528195","messageId":"CABPp-BHNaWdjkFuWs7uHdNweuurDGhb3DOrseSZmAEQnCEZFgw@mail.gmail.com","threadId":"63716","inReplyTo":"aOBMHqLxNd86vgjH@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-10-08T04:18:09Z","receivedAt":"2025-10-08T04:18:22Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Oct 3, 2025 at 3:20 PM brian m. carlson\n wrote:\n>\n> On 2025-10-03 at 20:48:40, Elijah Newren wrote:\n> > Would this mean that you wanted to ban contributions like d12166d3c8bb\n> > (Merge branch 'en/docfixes', 2023-10-23), available on the list over\n> > at https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n> > ? We don't need to go theoretical, I've already contributed such a\n> > patch series before -- 2 years ago -- and it was merged. Granted,\n> > that was entirely documentation, and I called out the usage of AI in\n> > the cover letter, and I manually checked every change (discarding many\n> > of them) and split it into commits on my own, could easily explain any\n> > change and why it was good, etc. And I was upfront about all of it.\n>\n> I think the main problem here is that we don't know the copyright\n> status of LLM outputs. It is not uncommon for them to produce output\n> that reflects their training input and we see evidence of that in, for\n> instance, the New York Times lawsuit against OpenAI.\n>\n> As I said, the situation is very unclear legally, with active litigation\n> in multiple countries, and we have to comply with pretty much every\n> country's laws in this situation. Whether something is legal in the\n> United States, where you're located, is completely irrelevant to whether\n> it is legal in Canada, where I'm located, or Germany or the UK, where we\n> have other contributors. We also have to consider whether it's legal in\n> all of the countries that Git is distributed in, which includes every\n> country in which Debian has a mirror[0], even countries under\n> international sanctions, such as Iran, Russia, and Belarus.\n>\n> It doesn't matter if the person using AI has indemnification, either,\n> since that only covers civil matters, and at least in the U.S. and\n> Canada, knowingly violating copyright is also a criminal offence.\n>\n> The sign-off process is designed to clearly state that a person has the\n> ability to contribute code under the license and I don't think, as\n> things stand, it's possible to make that assertion with code or\n> documentation generated from an LLM except in very limited\n> circumstances. I don't allow LLM-generated code in my personal projects\n> that require sign-off for that reason, and neither does QEMU[1]. I\n> don't think I could honestly assert either (a) or (b) in the DCO with\n> LLM-generated code because it's not clear to me whether \"I have the\n> right to submit it under the…license.\"\n>\n> To quote the QEMU policy:\n>\n> To satisfy the DCO, the patch contributor has to fully understand the\n> copyright and license status of content they are contributing to QEMU. With AI\n> content generators, the copyright and license status of the output is\n> ill-defined with no generally accepted, settled legal foundation.\n>\n> Where the training material is known, it is common for it to include large\n> volumes of material under restrictive licensing/copyright terms. Even where\n> the training material is all known to be under open source licenses, it is\n> likely to be under a variety of terms, not all of which will be compatible\n> with QEMU's licensing requirements.\n>\n> I remember the SCO situation with Linux and how it really created a lot\n> of uncertainty with Linux because SCO created FUD around Linux licensing\n> and how that led to the DCO being created. I am aware of the fact that\n> many open source contributors are very unhappy that their code has been\n> used to train LLMs without retaining credits and copyright notices or\n> honouring the license terms[2]. And I have spent many years working\n> with non-profits[3], where I have always been taught that we should\n> avoid even the appearance of impropriety.\n>\n> It may matter less what the situation actually ends up being legally\n> (although it could end up being quite bad) and more whether someone can\n> imply or suggest that Git is not being distributed in compliance with\n> the license or contains infringing code, which could effectively make it\n> undistributable because nobody wants to take that risk. And litigation,\n> even if Git and its contributors are successful, can be extraordinarily\n> expensive.\n>\n> So I think, given the circumstances, yes, the right thing to do is to\n> ban LLM-generated contributions with a policy very similar or identical\n> to QEMU's. If, in the future, the legal situation changes and it\n> becomes unambiguously legal to use LLMs across the world, then we can\n> reconsider that policy then.\n>\n> [0] https://www.debian.org/mirror/list\n> [1] https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048\n> [2] Regardless of the legal concerns, this implicates professional\n> ethics concerns, such as §1.5 of the ACM Code of Ethics[4]. Ethics\n> requirements usually go well beyond what the law requires.\n> [3] Software Freedom Conservancy, which handles legal matters for the\n> Git project, is a non-profit.\n> [4] https://www.acm.org/code-of-ethics\n\nThanks for clarifying your position. To me, your preferred wording\nfor the position statement doesn't quite match the rationale. I think\nfor cases of:\n\n * fixing typos\n * finding wording tweaks to existing documentation\n * tab completion of e.g. the next three lines in an IDE when limited\nto e.g. what most any engineer in the world would write based on the\ncomment on the line before (or if the AI plugin doesn't quite get the\nthree lines right, well I already had them in my head and if it gets\nclose enough, it's easier for me to accept and then edit into what I\nalready knew I wanted)\n * assisting with wording in writing a commit message as an editor\n(or maybe even suggesting some initial wording based on the patch I\nalready wrote)\n * identifying potential bugs in a patch\n * identifying potential typos in documentation\n\nthat none of these particular uses cause problems for the rationale\nyou specify, but at least the first four would be disallowed by the\npreferred wording you want, and perhaps even the last two wouldn't be\nallowed either (though I don't think AI is very good at the second to\nlast one, so not a big loss on that particular one yet). Perhaps due\nto my incomplete understanding of copyright all of these would\nactually be problematic with the rationale you already gave for\nreasons I don't yet know about or just haven't yet understood, but if\nnot, I'd rather not disallow these kinds of uses.\n\nThe first two from my list have a good example in the form of the\nseries at d12166d3c8bb (Merge branch 'en/docfixes', 2023-10-23) [or on\nthe list at https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n], which was already merged a few years ago. So if we adopt wording\nthat disallows these kinds of changes, then we also need to talk about\nwhether we grandfather already-merged series or proactively revert\nthem.\n"},{"id":"528196","messageId":"CABPp-BFf+_8cUc6sWZci9F0voosOQFWQ3x8dNs0YXEZ-uRvhNg@mail.gmail.com","threadId":"63716","inReplyTo":"xmqqh5wbq5z8.fsf@gitster.g","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-10-08T04:18:12Z","receivedAt":"2025-10-08T04:18:24Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Oct 6, 2025 at 10:45 AM Junio C Hamano wrote:\n>\n> \"brian m. carlson\" writes:\n>\n> > It may matter less what the situation actually ends up being legally\n> > (although it could end up being quite bad) and more whether someone can\n> > imply or suggest that Git is not being distributed in compliance with\n> > the license or contains infringing code, which could effectively make it\n> > undistributable because nobody wants to take that risk. And litigation,\n> > even if Git and its contributors are successful, can be extraordinarily\n> > expensive.\n> >\n> > So I think, given the circumstances, yes, the right thing to do is to\n> > ban LLM-generated contributions with a policy very similar or identical\n> > to QEMU's. If, in the future, the legal situation changes and it\n> > becomes unambiguously legal to use LLMs across the world, then we can\n> > reconsider that policy then.\n>\n> OK, so here is theirs for further discussion minimally adjusted for\n> our use. I do not see much difference at least in spirit with what\n> started this thread, but phrasing is certainly firmer, and I have no\n> problem with it.\n>\n>\n>\n> Use of AI content generators\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>\n> TL;DR:\n>\n> **Current Git project policy is copied from what QEMU does. To\n> DECLINE any contributions which are believed to include or derive\n> from AI generated content. This includes ChatGPT, Claude, Copilot,\n> Llama and similar tools.**\n>\n> The increasing prevalence of AI-assisted software development results in a\n> number of difficult legal questions and risks for software projects, including\n> Git. Of particular concern is content generated by `Large Language Models\n> `__ (LLMs).\n>\n> The Git community requires that contributors certify their patch submissions\n> are made in accordance with the rules of the `Developer's Certificate of\n> Origin (DCO) `.\n>\n> To satisfy the DCO, the patch contributor has to fully understand the\n> copyright and license status of content they are contributing to Git. With AI\n> content generators, the copyright and license status of the output is\n> ill-defined with no generally accepted, settled legal foundation.\n>\n> Where the training material is known, it is common for it to include large\n> volumes of material under restrictive licensing/copyright terms. Even where\n> the training material is all known to be under open source licenses, it is\n> likely to be under a variety of terms, not all of which will be compatible\n> with Git's licensing requirements.\n>\n> How contributors could comply with DCO terms (b) or (c) for the output of AI\n> content generators commonly available today is unclear. The Git project is\n> not willing or able to accept the legal risks of non-compliance.\n>\n> The Git project thus requires that contributors refrain from using AI content\n> generators on patches intended to be submitted to the project, and will\n> decline any contribution if use of AI is either known or suspected.\n>\n> This policy does not apply to other uses of AI, such as researching APIs or\n> algorithms, static analysis, or debugging, provided their output is not to be\n> included in contributions.\n>\n> Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's\n> ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content\n> generation agents which are built on top of such tools.\n>\n> This policy may evolve as AI tools mature and the legal situation is\n> clarifed. In the meanwhile, requests for exceptions to this policy will be\n> evaluated by the Git project on a case by case basis. To be granted an\n> exception, a contributor will need to demonstrate clarity of the license and\n> copyright status for the tool's output in relation to its training model and\n> code, to the satisfaction of the project maintainers.\n\nI preferred the version Christian sent, but *if* we end up adopting\nsome of the QEMU wording, I've got a logistics question:\n\n Will we grandfather already accepted series, or proactively revert them?\n\nFor example, the series merged at d12166d3c8bb (Merge branch\n'en/docfixes', 2023-10-23) [or on the list at\nhttps://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n], which was already merged a few years ago. I don't think that\nseries has anything remotely questionable from a copyright standpoint,\nyet the QEMU-inspired wording would explicitly disallow it as far as I\ncan tell, and would claim that such kinds of things would never be\naccepted in our project, even though people can find and point to the\nfact that we already did. Would that be problematic?\n\nOf course, if we don't adopt the QEMU wording and go with Christian's\nversion, then we don't need to worry about whether to revert or\nexplain how it is grandfathered.\n"},{"id":"528216","messageId":"CAP8UFD0Nrc-ENbjhP_eBmqe9jGyAd4kmp3Bw8b18JbxdC6neVQ@mail.gmail.com","threadId":"63716","inReplyTo":"xmqqjz1cufcd.fsf@gitster.g","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-08T07:22:35Z","receivedAt":"2025-10-08T07:22:49Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Oct 3, 2025 at 6:20 PM Junio C Hamano wrote:\n>\n> Christian Couder writes:\n>\n> >> A milder way to phrase this would be to jump directly to \"we reject\n> >> what the sender cannot explain when asked about it\". \"How does this\n> >> work?\" \"Why is this a good thing to do?\" \"Where did it come from?\"\n> >> instead of saying \"looks AI generated\".\n> >>\n> >> It would sidestep the \"who decides if it looks AI generated?\" question.\n> >\n> > I don't think the \"who decides if it looks AI generated?\" question is\n> > very relevant. If someone says that a patch looks mostly AI generated\n> > and gives a good argument supporting this claim, it's the same as if\n> > someone gives any other good argument against the patch. In the end,\n> > the community and you decide if the argument is good enough and if the\n> > patch should be rejected based on that (and other arguments for and\n> > against the patch of course).\n>\n> And then who plays the final arbiter?\n\nYou, like for any other discussion about a patch when there are\ndifferent opinions.\n\n> One can keep insisting on a\n> patch that looks to me an apparent AI slop that it was what one\n> wrote oneself, but you may find it a plausible that it was a human\n> creation. Then what?\n\nYou decide if the arguments on one side are better than those on the\nother side, again like for any other discussion about a patch when\nthere are different opinions.\n\nWhy should the process be different? It could be different if we think\nthat such behavior is similar to the bad behavior we talk about in our\ncode of conduct, but I don't think we want to go there and have some\nspecial procedures, right?\n\n> It is very much relevant to avoid such argument, because the point\n> is irrelevant. We are trying to avoid accepting something the\n> submitter has no rights to claim theirs, and requesting them to\n> explain where it came from, how it works, etc. would be a better\n> test than \"does it look AI generated? to everybody?\", wouldn't it?\n\nThe sender can ask the AI where it came from, how it works, etc, and\ncopy-paste the AI's answers. The sender could also prompt the AI or\nmodify its answers so that they look human generated as much as\npossible. So just asking those questions might not help much in some\ncases. In the end, whatever the answers to some questions, we have to\nbe able to decide if the suspicious content looks too much like it has\nbeen AI generated or not.\n\nIt doesn't mean that asking those questions couldn't help in some\ncases. It means that we just don't want to enter into the details of\nwhich questions we can ask and if we should judge based on the answers\nto those questions or something else. For example our code of conduct\nsays that we will take action \"in response to any behavior that they\ndeem inappropriate, threatening, offensive, or harmful.\" It doesn't\ntie us to asking some questions and taking action based on the\nanswers.\n\nThanks.\n"},{"id":"528219","messageId":"CAP8UFD3QUQpnUYGS1qtfGbxOynJrZ-Q5aPPyjb7oij-6YSx7Wg@mail.gmail.com","threadId":"63716","inReplyTo":"CABPp-BFcg9M=XjqGPd+akrUOqJqREBmE9+NvO1Q05r4pUcOmEQ@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-08T07:30:21Z","receivedAt":"2025-10-08T07:30:36Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Oct 3, 2025 at 10:48 PM Elijah Newren wrote:\n>\n> On Wed, Oct 1, 2025 at 2:37 PM brian m. carlson\n> wrote:\n\n> > We could say something like this:\n> >\n> > Please do not sign off your work if you’re using an LLM to contribute\n> > unless you have included copyright and license information for all the\n> > code used in that LLM.\n>\n> Would this mean that you wanted to ban contributions like d12166d3c8bb\n> (Merge branch 'en/docfixes', 2023-10-23), available on the list over\n> at https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n> ? We don't need to go theoretical, I've already contributed such a\n> patch series before -- 2 years ago -- and it was merged. Granted,\n> that was entirely documentation, and I called out the usage of AI in\n> the cover letter, and I manually checked every change (discarding many\n> of them) and split it into commits on my own, could easily explain any\n> change and why it was good, etc. And I was upfront about all of it.\n\nThis is a good example why we don't want to ban any use of generated AI. Thanks.\n\n> If any use of AI is bad, do we need to revert that series?\n"},{"id":"528222","messageId":"CAP8UFD34TrBa-GV1wUpvhO9K+qjHpXF4gr=afY2nsXiNL_-S+Q@mail.gmail.com","threadId":"63716","inReplyTo":"aOBMHqLxNd86vgjH@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-08T08:37:53Z","receivedAt":"2025-10-08T08:38:07Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Oct 4, 2025 at 12:20 AM brian m. carlson\n wrote:\n>\n> On 2025-10-03 at 20:48:40, Elijah Newren wrote:\n> > Would this mean that you wanted to ban contributions like d12166d3c8bb\n> > (Merge branch 'en/docfixes', 2023-10-23), available on the list over\n> > at https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n> > ? We don't need to go theoretical, I've already contributed such a\n> > patch series before -- 2 years ago -- and it was merged. Granted,\n> > that was entirely documentation, and I called out the usage of AI in\n> > the cover letter, and I manually checked every change (discarding many\n> > of them) and split it into commits on my own, could easily explain any\n> > change and why it was good, etc. And I was upfront about all of it.\n>\n> I think the main problem here is that we don't know the copyright\n> status of LLM outputs.\n\nIt's very unlikely that whatever is decided about the copyright status\nof LLM outputs will fundamentally change copyright law. So for example\nsmall changes, or changes where a human has been involved a lot, or\nchanges that are very specific, and so on, are very likely acceptable.\n\n> It is not uncommon for them to produce output\n> that reflects their training input and we see evidence of that in, for\n> instance, the New York Times lawsuit against OpenAI.\n\nYou might say something very similar about people contributing proprietary code:\n\n\"It is not uncommon to have people copy-paste some proprietary code\ninto an open source project and we see evidence of that in such and\nsuch incidents.\"\n\nSo it's just fine to accept some degree of risk. We have to accept it\nanyway. Saying \"we will ban everything AI generated\" will not make the\nrisk disappear either.\n\n> As I said, the situation is very unclear legally, with active litigation\n> in multiple countries, and we have to comply with pretty much every\n> country's laws in this situation. Whether something is legal in the\n> United States, where you're located, is completely irrelevant to whether\n> it is legal in Canada, where I'm located, or Germany or the UK, where we\n> have other contributors. We also have to consider whether it's legal in\n> all of the countries that Git is distributed in, which includes every\n> country in which Debian has a mirror[0], even countries under\n> international sanctions, such as Iran, Russia, and Belarus.\n\nI don't quite agree with this. Theoretically if the official mirrors\nare only in a few countries, then only the laws in these few countries\n(+ US law as the Conservancy is US based) might be really legally\nrelevant for the project. Then it's the responsibility of\ndistributions or people cloning/downloading the software to check that\nit's legal in the countries they distribute or clone/download it.\n\nIn practice we should pay attention a bit to make sure we don't create\nobvious legal problems for too many people, but if some countries\ndecide to have laws that are too stupid and ban too many things, we\ncould decide that we should definitely not pay attention to those\nlaws.\n\n> It doesn't matter if the person using AI has indemnification, either,\n> since that only covers civil matters, and at least in the U.S. and\n> Canada, knowingly violating copyright is also a criminal offence.\n>\n> The sign-off process is designed to clearly state that a person has the\n> ability to contribute code under the license and I don't think, as\n> things stand, it's possible to make that assertion with code or\n> documentation generated from an LLM except in very limited\n> circumstances.\n\nI think in practice those \"very limited circumstances\" can cover a lot\nof different things though. Do we really want to enter into a legal\ndebate over what\nhttps://en.wikipedia.org/wiki/Sc%C3%A8nes_%C3%A0_faire means for\nsoftware for example? Or about allowing or disallowing translation of\ndocumentation or commit messages based on the fact that the tools used\nfor translation use an LLM or not?\n\nI have given a lot of examples of what is very likely acceptable.\nElijah has given a very good concrete example showing why we should\nnot outright ban AI too. If you think they are not good examples\nplease tell it clearly. Otherwise I think you cannot keep saying that\nthey are related to \"very limited circumstances\".\n\n> I don't allow LLM-generated code in my personal projects\n> that require sign-off for that reason, and neither does QEMU[1]. I\n> don't think I could honestly assert either (a) or (b) in the DCO with\n> LLM-generated code because it's not clear to me whether \"I have the\n> right to submit it under the…license.\"\n>\n> To quote the QEMU policy:\n>\n> To satisfy the DCO, the patch contributor has to fully understand the\n> copyright and license status of content they are contributing to QEMU. With AI\n> content generators, the copyright and license status of the output is\n> ill-defined with no generally accepted, settled legal foundation.\n>\n> Where the training material is known, it is common for it to include large\n> volumes of material under restrictive licensing/copyright terms. Even where\n> the training material is all known to be under open source licenses, it is\n> likely to be under a variety of terms, not all of which will be compatible\n> with QEMU's licensing requirements.\n\nThe QEMU policy was discussed in the previous version already.\n\n> I remember the SCO situation with Linux and how it really created a lot\n> of uncertainty with Linux because SCO created FUD around Linux licensing\n> and how that led to the DCO being created. I am aware of the fact that\n> many open source contributors are very unhappy that their code has been\n> used to train LLMs without retaining credits and copyright notices or\n> honouring the license terms[2].\n\nI don't think it's very relevant for your position on this. On the\ncontrary, if LLMs have been trained mostly with open source code, then\nif they produce copyrighted output, that output is more likely to be\ncompatible with the GPL. It has even been suggested (and discussed in\nthis thread) that some AIs should be trained only with open source\nmaterial (for example MIT licensed material?) so that we could stop\nworrying about including it. If that happens, there would be no reason\nto outright ban AI generated content, right?\n\n> And I have spent many years working\n> with non-profits[3], where I have always been taught that we should\n> avoid even the appearance of impropriety.\n\nAdding a section restricting AI use, even if it doesn't go as far as\nyou would like, is already a first step in the direction you want. If\nthis gets merged, you can always send patches on top to make it more\nrestrictive.\n\n> It may matter less what the situation actually ends up being legally\n> (although it could end up being quite bad) and more whether someone can\n> imply or suggest that Git is not being distributed in compliance with\n> the license or contains infringing code, which could effectively make it\n> undistributable because nobody wants to take that risk. And litigation,\n> even if Git and its contributors are successful, can be extraordinarily\n> expensive.\n\nThere are already legal risks anyway (see above).\n"},{"id":"528224","messageId":"aOYuvGkQglLOEu-V@kitsune.suse.cz","threadId":"63716","inReplyTo":"CAP8UFD34TrBa-GV1wUpvhO9K+qjHpXF4gr=afY2nsXiNL_-S+Q@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-08T09:28:28Z","receivedAt":"2025-10-08T09:28:31Z","isPatch":true,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"Hello,\n\nOn Wed, Oct 08, 2025 at 10:37:53AM +0200, Christian Couder wrote:\n> On Sat, Oct 4, 2025 at 12:20 AM brian m. carlson\n> wrote:\n> >\n\n> \n> > I remember the SCO situation with Linux and how it really created a lot\n> > of uncertainty with Linux because SCO created FUD around Linux licensing\n> > and how that led to the DCO being created. I am aware of the fact that\n> > many open source contributors are very unhappy that their code has been\n> > used to train LLMs without retaining credits and copyright notices or\n> > honouring the license terms[2].\n> \n> I don't think it's very relevant for your position on this. On the\n> contrary, if LLMs have been trained mostly with open source code, then\n> if they produce copyrighted output, that output is more likely to be\n> compatible with the GPL. It has even been suggested (and discussed in\n> this thread) that some AIs should be trained only with open source\n> material (for example MIT licensed material?) so that we could stop\n> worrying about including it. If that happens, there would be no reason\n> to outright ban AI generated content, right?\n\neven MIT license requires attribution. As most current day LLMs fail to\nprovide that their output is legally dubious even when trained on fairly\npermissively licensed code.\n\nThanks\n\nMichal\n"},{"id":"528225","messageId":"CAP8UFD1Bc0bRdty9O0et9T=UL9FtN-g_K3DYUmHUR31waTQ+GQ@mail.gmail.com","threadId":"63716","inReplyTo":"xmqqh5wbq5z8.fsf@gitster.g","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-08T09:28:44Z","receivedAt":"2025-10-08T09:28:59Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Oct 6, 2025 at 7:45 PM Junio C Hamano wrote:\n\n> OK, so here is theirs for further discussion minimally adjusted for\n> our use. I do not see much difference at least in spirit with what\n> started this thread, but phrasing is certainly firmer, and I have no\n> problem with it.\n\nI don't think it's a good idea to be too firm. It could prevent people\nwilling to follow the rules from doing things that are actually\nacceptable while it won't prevent the risks from people not following\nthe rules anyway.\n\nSome of us have given examples of some uses that are likely acceptable\nbut seem to be banned by such firm wording. Do we want to discuss\nagain if translating a commit message using an AI tool is fine or not?\n\nSo I think we should start with something less firm, and then discuss\nthe pros vs cons of being firmer if some insist on being firmer then.\n\n[...]\n\n> How contributors could comply with DCO terms (b) or (c) for the output of AI\n> content generators commonly available today is unclear. The Git project is\n> not willing or able to accept the legal risks of non-compliance.\n\nI think this could be understood as if the Git project is responsible\nfor contributors submitting content they should not submit. I don't\nthink we should go into this.\n\n[...]\n\n> This policy does not apply to other uses of AI, such as researching APIs or\n> algorithms, static analysis, or debugging, provided their output is not to be\n> included in contributions.\n\nThis is not realistic. If an AI does static analysis for example, it\nis likely to suggest a fix for the issues it finds. Hopefully the fix\nwill be the right one, so it will end up being included in the\ncontributions.\n\n> Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's\n\ns/includes/include/\n\n> ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content\n> generation agents which are built on top of such tools.\n\nI don't think we should list examples like this. It could be\nunderstood as if we ban such tools while they can help with static\nanalysis, typo fixing, translation, etc... On the other hand some\nIDEs, for example, might include AI tools without users being really\naware of them.\n\n> This policy may evolve as AI tools mature and the legal situation is\n> clarifed. In the meanwhile, requests for exceptions to this policy will be\n> evaluated by the Git project on a case by case basis.\n\nI don't think we want to go into such processes.\n\n> To be granted an\n> exception, a contributor will need to demonstrate clarity of the license and\n> copyright status for the tool's output in relation to its training model and\n> code, to the satisfaction of the project maintainers.\n\nIf there are ever such AI tools trained on material such that the\nlegal risk is reduced, we will likely know about it. And even though\nthe legal risk will be reduced, the risk to be flooded with bad output\nmight not. So I don't think it's worth getting into this.\n\nThanks.\n"},{"id":"528226","messageId":"CAP8UFD3cg1W+LEgDrs77prdFvKHhUBsT1d0P7zpYswBfMXpWVA@mail.gmail.com","threadId":"63716","inReplyTo":"aOYuvGkQglLOEu-V@kitsune.suse.cz","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-08T09:35:35Z","receivedAt":"2025-10-08T09:35:49Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Oct 8, 2025 at 11:28 AM Michal Suchánek wrote:\n\n> > I don't think it's very relevant for your position on this. On the\n> > contrary, if LLMs have been trained mostly with open source code, then\n> > if they produce copyrighted output, that output is more likely to be\n> > compatible with the GPL. It has even been suggested (and discussed in\n> > this thread) that some AIs should be trained only with open source\n> > material (for example MIT licensed material?) so that we could stop\n> > worrying about including it. If that happens, there would be no reason\n> > to outright ban AI generated content, right?\n>\n> even MIT license requires attribution. As most current day LLMs fail to\n> provide that their output is legally dubious even when trained on fairly\n> permissively licensed code.\n\nFair enough, but then if an AI is ever trained with the particular\npurpose of producing code that can be included into MIT compatible\ncode bases, then hopefully people training it will make sure it can\nhelp with properly attributing that code.\n"},{"id":"528346","messageId":"87cy6wdghk.fsf@gmail.com","threadId":"63716","inReplyTo":"CAP8UFD34TrBa-GV1wUpvhO9K+qjHpXF4gr=afY2nsXiNL_-S+Q@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Collin Funk","fromEmail":"collin.funk1@gmail.com","sentAt":"2025-10-09T01:13:43Z","receivedAt":"2025-10-09T01:13:46Z","isPatch":true,"sender":{"key":"collin.funk1@gmail.com","avatar":"https://avatars.githubusercontent.com/u/65689063?v=4"},"body":"Christian Couder writes:\n\n> On Sat, Oct 4, 2025 at 12:20 AM brian m. carlson\n> wrote:\n>>\n>> On 2025-10-03 at 20:48:40, Elijah Newren wrote:\n>> > Would this mean that you wanted to ban contributions like d12166d3c8bb\n>> > (Merge branch 'en/docfixes', 2023-10-23), available on the list over\n>> > at https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/\n>> > ? We don't need to go theoretical, I've already contributed such a\n>> > patch series before -- 2 years ago -- and it was merged. Granted,\n>> > that was entirely documentation, and I called out the usage of AI in\n>> > the cover letter, and I manually checked every change (discarding many\n>> > of them) and split it into commits on my own, could easily explain any\n>> > change and why it was good, etc. And I was upfront about all of it.\n>>\n>> I think the main problem here is that we don't know the copyright\n>> status of LLM outputs.\n>\n> It's very unlikely that whatever is decided about the copyright status\n> of LLM outputs will fundamentally change copyright law. So for example\n> small changes, or changes where a human has been involved a lot, or\n> changes that are very specific, and so on, are very likely acceptable.\n\nThe issue is lack of law, from my understanding. There has been zero\npolitical will in the US for copyright legislation with respect to the\noutput of AI. Therefore, we are left with case law that is still\nongoing, that is, no precedent.\n\n>> I remember the SCO situation with Linux and how it really created a lot\n>> of uncertainty with Linux because SCO created FUD around Linux licensing\n>> and how that led to the DCO being created. I am aware of the fact that\n>> many open source contributors are very unhappy that their code has been\n>> used to train LLMs without retaining credits and copyright notices or\n>> honouring the license terms[2].\n>\n> I don't think it's very relevant for your position on this. On the\n> contrary, if LLMs have been trained mostly with open source code, then\n> if they produce copyrighted output, that output is more likely to be\n> compatible with the GPL. It has even been suggested (and discussed in\n> this thread) that some AIs should be trained only with open source\n> material (for example MIT licensed material?) so that we could stop\n> worrying about including it. If that happens, there would be no reason\n> to outright ban AI generated content, right?\n\nNot all open source code is compatible with other open source code. If\nyou use the output of a model trained on GPLv3+ code in a GPLv2-only\nproject, then the creator of the GPLv3+ code could claim that you\nviolated the license since they are not compatible. Whether they would\nwin in court or not, I have no clue, but it is probably best to avoid\nthat situation.\n\nCollin\n"},{"id":"528583","messageId":"xmqq5xck5fb0.fsf@gitster.g","threadId":"63716","inReplyTo":"CABPp-BFf+_8cUc6sWZci9F0voosOQFWQ3x8dNs0YXEZ-uRvhNg@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-12T15:07:47Z","receivedAt":"2025-10-12T15:07:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n>> ...\n>> This policy may evolve as AI tools mature and the legal situation is\n>> clarifed. In the meanwhile, requests for exceptions to this policy will be\n>> evaluated by the Git project on a case by case basis. To be granted an\n>> exception, a contributor will need to demonstrate clarity of the license and\n>> copyright status for the tool's output in relation to its training model and\n>> code, to the satisfaction of the project maintainers.\n>\n> I preferred the version Christian sent, but *if* we end up adopting\n> some of the QEMU wording, I've got a logistics question:\n>\n> Will we grandfather already accepted series, or proactively revert them?\n\nStepping back a bit, can we treat this new guideline element just\nlike any other guidelines in SubmittingPatches and also\nCodingGuidelines?\n\nWe have certain rules in our SubmittingPatches and CodingGuidelines\nto help us not get into trouble in the future. We require the log\nmessages to follow certain style to give them uniformity as\notherwise it would become harder to dig the history later to find\ncause of an issue we are having today, and more importantly what the\ndesign parameters were back when the change we are having trouble\nwith was written. We ask people to follow certain style in the code\nas it would make it more work to understand code if different styles\nare mixed together without reason.\n\nBut we also frown upon churning the codebase for the sake of\nstrictly match the prescribed coding style. The rules are mostly to\ncontrol newly written things so that they do not make our codebase\ninto worse shape than it currently is. When we update a part of our\ncodebase for some reason, other than \"there is no particular reason\nbut we want to fix them to match guidelines\", we would take existing\nguideline violations the touched part may have into account, of\ncourse. And we find no need in our other non-AI guidelines to say\n\"we grandfather badness that already exists, but we try our best to\nenforce the guidelines as strictly as possible\", and the reason, I\nthink, is because that is implicitly what everybody expects. Should\nthe \"We tell you again not to blindly add things with unknown\norigin, given the recent proliferation of AI coding product\" rule be\nany special and different?\n\n"},{"id":"528648","messageId":"xmqqv7ki1xf1.fsf@gitster.g","threadId":"63716","inReplyTo":"CAP8UFD1Bc0bRdty9O0et9T=UL9FtN-g_K3DYUmHUR31waTQ+GQ@mail.gmail.com","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-13T18:14:42Z","receivedAt":"2025-10-13T18:14:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> On Mon, Oct 6, 2025 at 7:45 PM Junio C Hamano wrote:\n>\n>> OK, so here is theirs for further discussion minimally adjusted for\n>> our use. I do not see much difference at least in spirit with what\n>> started this thread, but phrasing is certainly firmer, and I have no\n>> problem with it.\n>\n> I don't think it's a good idea to be too firm. It could prevent people\n> willing to follow the rules from doing things that are actually\n> acceptable while it won't prevent the risks from people not following\n> the rules anyway.\n\n>> How contributors could comply with DCO terms (b) or (c) for the output of AI\n>> content generators commonly available today is unclear. The Git project is\n>> not willing or able to accept the legal risks of non-compliance.\n>\n> I think this could be understood as if the Git project is responsible\n> for contributors submitting content they should not submit. I don't\n> think we should go into this.\n\nWhen the project distributes work that it has no right to\ndistribute, those who claim to be right holders would try to make\nthe project be held responsible for it. It is a different story if\nthe court agrees.\n\n> [...]\n>\n>> This policy does not apply to other uses of AI, such as researching APIs or\n>> algorithms, static analysis, or debugging, provided their output is not to be\n>> included in contributions.\n>\n> This is not realistic. If an AI does static analysis for example, it\n> is likely to suggest a fix for the issues it finds. Hopefully the fix\n> will be the right one, so it will end up being included in the\n> contributions.\n>\n>> Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's\n>\n> s/includes/include/\n\nWe are not in the business of typofixing QEMU policy. Send that\npatch in their direction ;-).\n\nI do not have strong preference either way. Even if the wording is\nfirm, it is really up to each contributor to honor the guideline and\nbe honest with us. You may see autocorrection in your editor fix a\ntypo for you, and more advanced tools may offer to rewrite what you\nwrote, whether it is prose or code. It is very plausible that,\nespecially for simple fixes, the result may be what the contributor\nwould have arrived on their own anyway, and in such a case, even the\ncontributor would not even know how much came from \"AI\" or simple\ndictionary, or if that AI learned with things you should not have\nseen.\n\nSo, I do not think it makes too big a difference in practice whether\nwe adopt the QEMU with minimum rewrite, or the version you posted.\nAs the one you sent is in line with what we give applicants of our\nmentoring programs, and it was read over by our SFC lawyer, I'd\nprefer to keep the version I already have in my tree. Not moving on\neither, I think, is worse than adopting either in this case.\n\nThanks.\n\n"},{"id":"529512","messageId":"xmqqfrb9v814.fsf@gitster.g","threadId":"63716","inReplyTo":"xmqqv7ki1xf1.fsf@gitster.g","subject":"Re: [PATCH v2] SubmittingPatches: add section about AI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-23T17:32:07Z","receivedAt":"2025-10-23T17:32:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I do not have strong preference either way. Even if the wording is\n> firm, it is really up to each contributor to honor the guideline and\n> be honest with us. You may see autocorrection in your editor fix a\n> typo for you, and more advanced tools may offer to rewrite what you\n> wrote, whether it is prose or code. It is very plausible that,\n> especially for simple fixes, the result may be what the contributor\n> would have arrived on their own anyway, and in such a case, even the\n> contributor would not even know how much came from \"AI\" or simple\n> dictionary, or if that AI learned with things you should not have\n> seen.\n>\n> So, I do not think it makes too big a difference in practice whether\n> we adopt the QEMU with minimum rewrite, or the version you posted.\n> As the one you sent is in line with what we give applicants of our\n> mentoring programs, and it was read over by our SFC lawyer, I'd\n> prefer to keep the version I already have in my tree. Not moving on\n> either, I think, is worse than adopting either in this case.\n\nTaking time to discuss before deciding on an important issue is one\nthing, but waiting for more input to happen and not moving in either\ndirection is worse than picking one and move on. As I said above, I\ndo not quite see material difference between either one in practice.\n\nI guess it is time to make an executive decision to merge it down to\n'next'. We can still tweak the language if we want, but it is more\nimportant to have a written policy to reject materials of unknown\norigin (whether it came from generative AI or not) than not having\none while we wish to be able to pick the best policy, waiting for a\nbetter argument to come from somewhere.\n\nAs to Elijah's concern about grandfathering, I do not think it has\nmuch practical benefit to make such a declaration. If it turns out\nthat older \"contributions\" had added something we shouldn't have,\nregardless of how it was generated (either from generative AI or a\nhuman contributor typing while unconciously recalling what they saw\nelsewhere), we may need to revert it anyway, so we will deal with it\nwhen it becomes an issue.\n\n"}]}