Re: GCC LLM policy adopted

On Fri, Jul 31, 2026 at 10:56:18AM +0200, Gard Spreemann wrote:
> Gard Spreemann <[email protected]> writes:
> 
> > Russ Allbery <[email protected]> writes:
> >
> >> Sean Whitton <[email protected]> writes:
> >>
> >>> - It clearly distinguishes including LLM output in what gets committed
> >>>   from other uses of LLMs for software development, as I have been
> >>>   repeatedly advocating is important, without much uptake.
> >>
> >> For the record, I also strongly agree with this distinction. Sean is not
> >> alone.
> >
> > I completely agree, too. And I fear that none of the ballot options
> > sufficiently cater to this distinction.
> >
> > Sean & Russ: How would you feel about a ballot option that bans
> > LLM-generated contributions, but explicitly does not opine on the
> > contributing human using LLM tools to e.g. debug, learn, plan, critique
> > etc. when creating the contribution?
> >
> > (I realize that such a proposal might be interpreted by some as forcing
> > those who are fine with LLM-generated code to become transcribers for
> > the LLM, but I hope that's a minority view and that most would
> > understand that that is not the intent.)
> 
> Something like:
> 
> DRAFT BALLOT OPTION
> 
> **Ban AI-generated contributions, but allow AI assistance**
> 
> Debian neither endorses nor prohibits the assistance of AI tools,
> including generative ones, during the work of contributing to the
> project. This includes e.g. tools used for research, learning,
> debugging, critique, adversarial testing etc. during the creation of
> contributions to Debian.
> 
> However, the actual outputs of these tools suffer from several problems:
> 
> * Unclear copyright status.
> 
> * Difficulty with quality review and future maintenance.
> 
> * Unanswered questions pertaining to what the preferred form of
>   modification is for software created this way.
> 
> Debian therefore prohibits the inclusion of any AI-generated code,
> documentation or other content into the project.

This draft option also applies to upstream code.

There is an important difference between GCC and us:
We are a collection of upstream sources in an ecosystem where usage of
AI-generated code is no longer rare, with our own code parts being 
rather small compared to the upstream code we include.

The fundamental problem with all anti-AI proposals is that there are 
good arguments against inclusion of AI-generated code at least for now,[1]
but the consequence of applying this also to upstream code in main would 
not be workable.

Trying to apply such rules only to Debian-specific parts would have 
consequences like banning AI-generated test cases under debian/tests/,
but the maintainer submitting this code upstream and then backporting 
the same code would be fine.

cu
Adrian

[1] personally I would consider the unclear copyright status sufficient