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). Richard. > All the best > Chris > >
