Thread (19 messages) flat view 19 messages, 5 authors, 16d ago

Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat

From: Weijie Yuan <wy@wyuan.org>
Date: 2026-08-24 15:33:39

On Sun, Aug 23, 2026 at 06:49:49PM -0700, Junio C Hamano wrote:
Weijie Yuan [off-list ref] writes:
quoted
quoted
We know Johannes well enough to trust that his patches were sent
with sufficient due diligence.  So...?
<xmqqzeyeujde.fsf@gitster.g>:
quoted
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.
What I meant is that you said we should be wary of content that might
carry legal risks,...
I am not sure what your point is.  Is there any part in "we trust
Dscho well enough to trust that he sent them with sufficient due
diligence" that was hard for you to understand?
Sorry, I think I failed to make my actual question clear in my previous
replies.

I do understand, and agree with, your point that you trust Johannes to
have submitted his patches with sufficient due diligence. I was not
trying to question Johannes or your trust in him.

What I was trying to understand is how that fits with the particular DCO
concern being discussed here.

You pointed out that if something submitted under the DCO later turns
out to be based on material we cannot legally use, the project also
bears the cost of removing it, and that the fallout becomes worse the
later such a problem is discovered.

As I understand brian's concern, if a significant amount of a
contribution is generated by an AI tool, there may be uncertainty over
whether the submitter can make the DCO certification with sufficient
confidence.

That is why Johannes's existing commits with an Assisted-by trailer
came to mind. I am not claiming that those commits necessarily contain
AI-generated content of the kind brian is concerned about; I do not know
what the assistance actually consisted of.

But if the disclosed assistance did involve generated content of that
kind, wouldn't the same DCO question arise? And if we do not know
whether it did, isn't that the sort of question that, following your
point above, would be better clarified sooner rather than later?

At the same time, I can also see the point behind your:

"if you use one, do not tell us" ;-)

Thinking about it from that angle also makes me wonder about
Assisted-by trailers themselves. If I understand the point behind
"if you use one, do not tell us" correctly, then perhaps we should
simply not encourage Assisted-by: LLM trailers, since such a trailer
explicitly records the very fact that we might prefer the project not
to be told about.

Of course, I am simply worried that an Assisted-by trailer might
create some legal risk. I am not a lawyer, though, so I do not know
whether that concern is actually well-founded.

On the other hand, I can also understand why the kernel community made
a different trade-off and prefers disclosure. Knowing that a tool was
involved gives the maintainer additional information, and the maintainer
can then decide according to their own judgment whether that information
should affect how the patch is handled. (possibly there are other reasons)

That was what I was trying, rather unsuccessfully, to get at before. I
am sorry that my earlier replies made it sound as though I was singling
out Johannes as a problematic case.

Sorry again for the confusion and the noise.

Thanks,
Weijie
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help