Re: [PATCH 0/2] Fix misaligned output of git repo structure

Jiang Xin <worldhello.net@gmail.com> writes:

In other words, addition of this is solely to help corporations like Alibaba to measure which AI tools are used (and what correlation there are between success rate of the patches and the tools that generated them, etc..

What is in it for us? What benefit are we getting in exchange for tolerating these additional trailer lines in our log messages?

A few random thoughts about generated contents:

 * Disclosing the tools that were used during the development of a
   patch is a good practice in principle, but this is not limited to
   use of AI tools.  We have fixes for issues found with existing
   Coccinelle checks, sanitizers, static checkers, and it is the
   usual practice for the patches that fix them to disclose how the
   author discovered the issue.  When making mechanical replacement
   changes en masse, it is the usual practice for the patches to
   describe what scripts were used to make the changes in them.  But
   we do not dedicate a trailer line for such a disclosure, and
   there is no reason why AI tools has to be treated specially here.
   Instead of "Co-developed-by" that only tells what tool was used,
   why not disclose what prompts (again, somehow AI tools are
   treated specially here, too---we call the input to these tools
   "scripts" when the changes were made with sed or perl or
   coccinelle) were used?

 * Whether some or all contents in a submitted patch were generated
   by tools, it does not change the obligation of the person who
   submits the patch.  They need to make sure that the changes are
   reviewable, its goal and implementation are described in the
   proposed log message appropriately, the updated code does what
   the proposed log message claims to do.  They need to make sure
   that they have the right to contribute the patch under DCO, and
   sign off their patch accordingly.

 * What is made more difficult for a submitter with AI tools is that
   it is often not obvious to the human developer how much of the
   tools' generated output is parroting what the tools saw during
   their training session, and what the licensing terms of these
   training materials are.  Even if a hypothetical AI tool were
   trained only with BSD licensed material, the output from such a
   tool is likely to hold you under certain obligations like
   including the original copyright notice, but without the tool
   disclosing to you the human developer, you do not even know whose
   copyright notice to include.

 * Worse yet, the above difficulty is only for the submitter of such
   a patch, not the project that, trusting what the sign-off of the
   submitter certifies, reviews and accepts such a patch.  It does
   not make any difference if the original submitter copied and
   pasted proprietary code of their employer in the patch, or
   included code that AI tools "borrowed" from elsewhere without
   following proper procedure to honor the licensing terms.  In
   either case, the project may have accepted what was stolen
   without knowing, and it is very likely that the submitter but not
   the project is primarily held liable.  In a sense, the project
   would be better off if the patch does not say it was generated
   with AI tools---if the project does not know, it cannot possibly
   held liable for it, even though the project will have to waste
   engineering resources to rewrite or remove the remnant from such
   a faulty contribution.