Re: Policy on use of LLM tools and bug fixes

On 4/17/26 7:25 PM, DJ Delorie wrote:

> Christopher Albert via Gcc <[email protected]> writes:
>> I would add one practical point from recent experience.
> I usually don't post to the gcc groups, but I have some thoughts that
> might be relevent here, as this is a common topic across many groups.
> (no need to take my thoughts seriously ;)
>
>> A substantial part of my own recent GCC contributions was only possible
>> because reviewers and maintainers engaged seriously with patches I
>> developed
> Excellent!
>
>> using AI tools under my direction.
> Yet you didn't disclose that until now, which is the part that concerns
> us.  In the past, the DCO implies that you wrote the patch yourself (vs
> copying it from elsewhere), despite how it is technically written, and
> if AI is changing that implication, we need to be clear on that first.
> Until then, it's best to disclose any origins of code other than stuff
> you write yourself, so that everyone has the same understanding of the
> code's origin.
>
> On the glibc list, we're even talking about disclosing when patches
> are mechanically generated from scripts, so...
>
>> 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.
> We agree that using AI in non-generating parts of the process
> (understanding, ideas, reviews, testing, etc) is not an issue.
> Code-generating uses of any tool creates a copyright question which must
> be answered.
>
>> The patches were still submitted by me, reviewed by me, tested by me,
> Excellent!
>
>> 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.
> Yay!  (not being sarcastic, I'm glad people are learning new ways and
> tools to be productive)
>
>> I would therefore be cautious about a policy that is too strict.
> Sadly, because GCC and other large projects are very popular and very
> visible, we must be overly cautious about copyright issues.  Getting
> this wrong can be truly damaging.
>
>> The legal picture also seems more nuanced to me
>> "the analysis is case-specific"
>> *EU. The CJEU standard is
>> *UK. CDPA 1988 s.9(3) assigns authorship of computer-generated works
> That these are all different is itself a problem, too.  The copyright
> status of AI generated content is not fully decided yet.
>
>> These regimes do not, in my view, support a simple categorical rule
> Exactly.  GCC is a global project so we have to come up with guidelines
> that work acceptably for all regimes we operate in.  Until we do, we
> must err on the side of caution.
>
>> The more relevant question seems to be whether there is sufficient human
>> authorship and control over the final result.
> Yup.  And we don't know what that is at the moment.  Until the we do, or
> the FSF gives us concrete guidance, being overly cautious and taking a
> 'no significant AI code yet" approach is best for us.

Thank you all for the honest and thoughtful replies. I was eager to get 
fixes done quickly and did not want to trigger a large policy 
discussion. In retrospect, not disclosing my use of AI tools up front 
was a mistake, and I apologize for the trouble this has caused.

For the record, a substantial number of contributions signed off by me 
were developed with assistance from Claude and/or GPT models. The form 
and extent of that assistance varied, but the submitted patches were 
reviewed by me, tested by me, and signed off by me, with full 
responsibility on my side for every line.

This discussion is clearly necessary before project-wide rules are 
settled, so it is good that it is happening now. I think we all agree 
that disclosure must be part of any policy. The harder part is where to 
draw the remaining lines.

Different major projects have drawn that line differently. OpenJDK has 
taken a stricter approach, while LLVM has adopted a more permissive one. 
Both approaches come with benefits and risks. A very strict rule may 
exclude contributors who use these tools in a careful and accountable 
way. A very loose rule may create legal or provenance risks that GCC 
cannot accept.