Git development
 help / color / mirror / Atom feed
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: Sun, 23 Aug 2026 08:23:31 -0700	[thread overview]
Message-ID: <xmqqa4qcvp1o.fsf@gitster.g> (raw)
In-Reply-To: <aooRdiVdjovWSFiG@fruit.crustytoothpaste.net> (brian m. carlson's message of "Sat, 22 Aug 2026 21:15:35 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2026-08-22 at 17:59:09, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> 
>> > I therefore haven't read this series to avoid being influenced by code
>> > we're not allowed to include.

More on this a bit later...

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

Projects like the Linux kernel ask you to disclose your use of AI
(and have other requirements on your use), but I haven't read
exactly why they want it.  I wish they instead said, "We do not want
to be blamed for knowingly infringing.  While we do not particularly
encourage you to use AI, if you use one, do not tell us" ;-).

> 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 that contradicts what you yourself did, doesn't it?  An honest
developer who discloses their use of AI admits that their eyes are
already contaminated by AI output, because they did not avoid being
influenced as you did.  So are they unwelcome now?

Stepping back a bit, even before the AI era, a human developer may
have seen code elsewhere that they are not allowed to include in a
particular project.  Learning from what others did is the nature of
our work, and it is inevitable.  Is it reasonable for BSD-only
projects to declare that those who are familiar with constructs that
appear in Git code after working on it are unwelcome, because their
contributions may be contaminated by what they have seen in a GPLed
project?

I very much appreciate that you are treading very cautiously on the
safer side, but I hope that the actual balance lies on a somewhat
more practical side that trusts humans.

> 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.

True. True.

Thanks.

  reply	other threads:[~2026-08-23 15:23 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
2026-08-23 15:23       ` Junio C Hamano [this message]
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=xmqqa4qcvp1o.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox