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.
