From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
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 10:59:09 -0700 [thread overview]
Message-ID: <xmqqzeyeujde.fsf@gitster.g> (raw)
In-Reply-To: <aonIVn-ZQoMKWCAd@fruit.crustytoothpaste.net> (brian m. carlson's message of "Sat, 22 Aug 2026 16:03:35 +0000")
"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.
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.
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.
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".
next prev parent reply other threads:[~2026-08-22 17:59 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 [this message]
2026-08-22 21:15 ` brian m. carlson
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=xmqqzeyeujde.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=sandals@crustytoothpaste.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.