Re: Policy on use of LLM tools and bug fixes

On 4/17/26 1:38 PM, Richard Biener wrote:

> On Fri, Apr 17, 2026 at 12:51 PM Christopher Albert via Gcc
> <[email protected]> wrote:
>>> On Thu, 16 Apr 2026 at 15:28, Richard Earnshaw (foss) via Gcc
>>> <[email protected]> wrote:
>>>> On 14/03/2026 19:02, Jeffrey Law via Gcc wrote:
>>>>>
>>>>> On 3/14/2026 12:59 PM, Jerry D via Gcc wrote:
>>>>>> Some of the various LLM services available appear to be getting very good at generating bug fixes. I realize that one must be careful as these tools can at times do things that may be superfluous to the actual fix. By superfluous I mean lines of code that are not relevant to the lines that fix it.
>>>>>>
>>>>>> I saw some discussions of this subject for gcc somewhere and wanted to know if we have a specific policy established / documented somewhere regarding this.
>>>>> The steering committee is trying to figure out a good policy right now.
>>>>>
>>>>> Jeff
>>>> I notice that the Linux kernel recently adopted the following policy:  https://github.com/torvalds/linux/blob/master/Documentation/process/coding-assistants.rst
>>>>
>>>> Has there been any progress on GCC yet?
>>> Carlos and I prepared a draft policy, but I believe the GCC steering
>>> committee is also looking into it. The FSF are also working on
>>> policies.
>>>
>>> Our draft policy takes a similar position to the kernel one: LLMs
>>> cannot do a DCO sign-off as their output is not copyrightable. The
>>> correct trailer to use is Assisted-by and not Co-authored-by. But our
>>> draft policy proposes *not* accepted AI-generated code, only allowing
>>> the use of AI for assistance, idea generation, testing, but not
>>> generating the actual code. That's because the legal status of
>>> AI-generated code is unclear, is not copyrightable, and does not meet
>>> the legal prerequisites for GCC contributions.
>> I would add one practical point from recent experience.
>> A substantial part of my own recent GCC contributions was only possible
>> because reviewers and maintainers engaged seriously with patches I
>> developed using AI tools under my direction. In at least some cases, it
>> would be fair to say that this went beyond AI as pure "idea generation":
>> the tools were part of the development workflow that let me produce,
>> iterate on, and validate fixes much more efficiently. The patches were
>> still submitted by me, reviewed by me, tested by me, and signed off by
>> me, with full responsibility on my side for every line.
>> In practice, this workflow was very successful. I do not think I could
>> have fixed so many bugs, at that quality and speed, without it. I would
>> therefore be cautious about a policy that is too strict. If GCC rules
>> out any patch where AI contributed more than idea generation, we may
>> lose an accountable workflow that has worked well here, and we risk
>> falling behind projects that take a more pragmatic line.
>> The legal picture also seems more nuanced to me than a simple rule of
>> "assistance allowed, generation forbidden":
>> *US. U.S. Copyright Office, Copyright and Artificial Intelligence,
>> Part 2: Copyrightability (Jan 2025): AI used to assist human
>> creativity does not by itself defeat protection; purely AI-generated
>> material is not protected; the analysis is case-specific and turns on
>> human authorship and control over the final expression; human
>> selection, arrangement, and modification of AI output may be
>> protected.
>> https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
>> *EU. The CJEU standard is the "author's own intellectual creation",
>> that is, free and creative choices by a human author (Infopaq
>> C-5/08, Painer C-145/10, Cofemel C-683/17). The EU AI Act
>> (Reg. 2024/1689) regulates AI systems and transparency, not copyright
>> authorship.
>> https://eur-lex.europa.eu/eli/reg/2024/1689/oj
>> *UK. CDPA 1988 s.9(3) assigns authorship of computer-generated works
>> to "the person by whom the arrangements necessary for the creation of
>> the work are undertaken."
>> https://www.legislation.gov.uk/ukpga/1988/48/section/9
>> These regimes do not, in my view, support a simple categorical rule
>> that any code produced with substantial AI involvement must be excluded.
>> The more relevant question seems to be whether there is sufficient human
>> authorship and control over the final result.
>> I fully understand the need for caution on provenance, licensing, and
>> responsibility, and I agree that an LLM cannot itself sign a DCO. But
>> from my perspective, the decisive criterion should be that the human
>> contributor takes full responsibility for the submitted patch:
>> careful review, any necessary rewriting, testing, and sign-off,
>> rather than a blanket rule that excludes code whenever AI tools played
>> a substantial role somewhere in the development process.
> I agree to some extent, but then I'd also like to at least see assisted-by
> tags as proposed by the Linux kernel policy.  But I also have to say that
> for people that do not have an existing track record with projects it's
> very difficult to provide that upfront trust on following such "grey" policy
> to the spirit it was written with.  Esp. since there's wide areas of GCC
> where knowledge of existing code is scarce and since LLMs are so
> convincing in their hallucinations so code quality might degrade (I
> realize this isn't a problem of LLMs per se but of unmaintained code
> pieces and any contribution to it).

I fully agree with you, Richard! Making AI assistance transparent and 
have clear rules about it is key. I didn't publicly flag my use of AI 
tools up to now because I was afraid that the contributions would get 
rejected upfront due to unclear policy or strong opinions. Internally, I 
was more open about it out of respect for the reviewers who invested a 
lot of time and effort. From now on, I will add Assisted-by: to the patches.


In other projects there are rules that outright refuse any contribution 
that has to do with AI because they are afraid to be flooded by 
unqualified code. I had such an experience also in one of my projects, 
where I got automatically generated contributions that were completely 
useless. Some (possibly semi-automatic) pre-screening could also become 
relevant, depending on the amount of PRs and patches of such kind.


IMHO there is no turning back from these developments, and I am 
confident that Richard and Carlos will find a well-balanced solution.


Best
Chris

> Richard.
>