Git development
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Alexey Samsonov via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Alexey Samsonov <vonosmas@gmail.com>
Subject: Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
Date: Sat, 22 Aug 2026 21:15:35 +0000	[thread overview]
Message-ID: <aooRdiVdjovWSFiG@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqzeyeujde.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]

On 2026-08-22 at 17:59:09, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > On 2026-08-21 at 14:23:20, Alexey Samsonov via GitGitGadget wrote:
> >> This change is generated by Gemini Flash from Antigravity, but all the code
> >> has been manually verified by me, and, where applicable, adjusted to match
> >> the existing behavior as closely as possible.
> >
> > Unfortunately, I don't think that's allowed.  From SubmittingPatches[0]:
> >
> >     The Developer's Certificate of Origin requires contributors to certify
> >     that they know the origin of their contributions to the project and
> >     that they have the right to submit it under the project's license.
> >     It's not yet clear that this can be legally satisfied when submitting
> >     significant amount of content that has been generated by AI tools.
> >
> > I therefore haven't read this series to avoid being influenced by code
> > we're not allowed to include.
> >
> > [0] https://git-scm.com/docs/SubmittingPatches#ai
> 
> Your stance, as I understand it, is that Alexey's DCO is not valid
> because, acting as a copy editor of Antigravity/Gemini's work,
> Alexey cannot possibly know where the code was copied from.  And we
> cannot accept work that is not covered by a valid DCO.

Yes.  We know that in some cases LLMs regurgitate code that is
substantially similar to training inputs and we don't know what the
legal status of the output of an LLM is, especially since there is
active litigation around the world.

The DCO was invented to provide a legal assertion by an author that they
are only submitting code they legally have the right to submit and I
don't think there's enough legal clarity for us to know that with an
LLM.

> I think that is a much more prudent attitude than being cavalier
> about legal issues.  I used to think, "Hey, the person claims in the
> DCO that the code is appropriately licensed, so if it turns out to
> be a false claim later, that is his or her problem, not ours."
> 
> But that is not how things work.

It's my understanding that in many places there's a difference between
knowingly doing something and doing something without knowledge.  For
example, Canada's Copyright Act uses the text, "that the person knows or
should have known infringes copyright".

So we do have more of a legal problem if we knowingly distribute code
that infringes copyright or which we suspect may do so.

> If work submitted under a DCO later turns out to be based on
> something we cannot legally use, the submitter may of course be in
> trouble, but we would also need to bear the cost of ripping it out;
> the later we discover the problem, the more substantial the effort
> necessary to deal with the fallout will be.

Yes, that's true.  We still have the fallout and issues in terms of
project management to deal with, but fewer legal problems.

> Stepping back a bit, though, is the situation really all that
> different between a relatively new author who discloses their use of
> AI and another author similarly unknown to us who claims it is all
> their own work?  Either way, if the code turns out to be unusable,
> we would still be on the hook for participating in the infringement
> and would bear the cost of ripping it out.
> 
> What worries me a bit is that there may not be much difference
> between "you said that you relayed AI output, so we won't talk to
> you" and "we do not know you well enough to trust you, so we won't
> talk to you".

If somebody comes to our project and lies to us about the provenance of
their work, that's very serious.  Saying, "I wrote this with AI," when
we don't allow AI is being honest and ethical and disclosing relevant
details to the project.  It may be that we can't accept their code for
that reason, but they have participated in the project in good faith.
We could certainly accept other patches from such a person written
without AI.

But if a contributor misleads us about the origin of their code, whether
it came from AI or was taken without credit from another project,
then they're not at all acting in good faith and we will likely not
allow them to continue to contribute to the project.  Moreover, they
will also be unwelcome in most other projects as well because they'll be
viewed as dishonest.

That doesn't affect whether we end up having negative consequences from
distributing that code, true.  But at some point, we have to trust that
most people are honest or our community and society break down.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

  reply	other threads:[~2026-08-22 21:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 1/3] compat/posix: introduce utimensat(2) wrapper Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 2/3] treewide: use utimensat(2) instead of legacy utime(3p) Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 3/3] compat/posix: drop legacy <utime.h> header and shims Alexey Samsonov via GitGitGadget
2026-08-21 17:33 ` [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Junio C Hamano
2026-08-22 16:03 ` brian m. carlson
2026-08-22 17:59   ` Junio C Hamano
2026-08-22 21:15     ` brian m. carlson [this message]
2026-08-23 15:23       ` Junio C Hamano
2026-08-23 13:26     ` Weijie Yuan
2026-08-23 15:26       ` Junio C Hamano
2026-08-23 15:45         ` Weijie Yuan
2026-08-24  1:49           ` Junio C Hamano
2026-08-24 12:19             ` Weijie Yuan
2026-08-24 15:33             ` Weijie Yuan
2026-08-24 16:06               ` Junio C Hamano
2026-08-24 16:23                 ` Junio C Hamano
2026-08-24 16:33                 ` Weijie Yuan
2026-08-24 20:25                 ` Oswald Buddenhagen

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=aooRdiVdjovWSFiG@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=vonosmas@gmail.com \
    /path/to/YOUR_REPLY

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

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