Re: [PATCH v2] SubmittingPatches: add section about AI

[Elijah Newren <newren@gmail.com>]

On Mon, Oct 6, 2025 at 10:45 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > It may matter less what the situation actually ends up being legally
> > (although it could end up being quite bad) and more whether someone can
> > imply or suggest that Git is not being distributed in compliance with
> > the license or contains infringing code, which could effectively make it
> > undistributable because nobody wants to take that risk.  And litigation,
> > even if Git and its contributors are successful, can be extraordinarily
> > expensive.
> >
> > So I think, given the circumstances, yes, the right thing to do is to
> > ban LLM-generated contributions with a policy very similar or identical
> > to QEMU's.  If, in the future, the legal situation changes and it
> > becomes unambiguously legal to use LLMs across the world, then we can
> > reconsider that policy then.
>
> OK, so here is theirs for further discussion minimally adjusted for
> our use.  I do not see much difference at least in spirit with what
> started this thread, but phrasing is certainly firmer, and I have no
> problem with it.
>
>
>
> Use of AI content generators
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> TL;DR:
>
>   **Current Git project policy is copied from what QEMU does.  To
>   DECLINE any contributions which are believed to include or derive
>   from AI generated content. This includes ChatGPT, Claude, Copilot,
>   Llama and similar tools.**
>
> The increasing prevalence of AI-assisted software development results in a
> number of difficult legal questions and risks for software projects, including
> Git.  Of particular concern is content generated by `Large Language Models
> <https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs).
>
> The Git community requires that contributors certify their patch submissions
> are made in accordance with the rules of the `Developer's Certificate of
> Origin (DCO) <dco>`.
>
> To satisfy the DCO, the patch contributor has to fully understand the
> copyright and license status of content they are contributing to Git. With AI
> content generators, the copyright and license status of the output is
> ill-defined with no generally accepted, settled legal foundation.
>
> Where the training material is known, it is common for it to include large
> volumes of material under restrictive licensing/copyright terms. Even where
> the training material is all known to be under open source licenses, it is
> likely to be under a variety of terms, not all of which will be compatible
> with Git's licensing requirements.
>
> How contributors could comply with DCO terms (b) or (c) for the output of AI
> content generators commonly available today is unclear.  The Git project is
> not willing or able to accept the legal risks of non-compliance.
>
> The Git project thus requires that contributors refrain from using AI content
> generators on patches intended to be submitted to the project, and will
> decline any contribution if use of AI is either known or suspected.
>
> This policy does not apply to other uses of AI, such as researching APIs or
> algorithms, static analysis, or debugging, provided their output is not to be
> included in contributions.
>
> Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's
> ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content
> generation agents which are built on top of such tools.
>
> This policy may evolve as AI tools mature and the legal situation is
> clarifed. In the meanwhile, requests for exceptions to this policy will be
> evaluated by the Git project on a case by case basis. To be granted an
> exception, a contributor will need to demonstrate clarity of the license and
> copyright status for the tool's output in relation to its training model and
> code, to the satisfaction of the project maintainers.

I preferred the version Christian sent, but *if* we end up adopting
some of the QEMU wording, I've got a logistics question:

    Will we grandfather already accepted series, or proactively revert them?

For example, the series merged at d12166d3c8bb (Merge branch
'en/docfixes', 2023-10-23) [or on the list at
https://lore.kernel.org/git/pull.1595.git.1696747527.gitgitgadget@gmail.com/
], which was already merged a few years ago.  I don't think that
series has anything remotely questionable from a copyright standpoint,
yet the QEMU-inspired wording would explicitly disallow it as far as I
can tell, and would claim that such kinds of things would never be
accepted in our project, even though people can find and point to the
fact that we already did.  Would that be problematic?

Of course, if we don't adopt the QEMU wording and go with Christian's
version, then we don't need to worry about whether to revert or
explain how it is grandfathered.