@@ -71,7 +71,6 @@ responsibility among the other maintainers.
7171 AVR Denis Chertykov <chertykov@gmail.com>
7272 AVR Marek Michalkiewicz <marekm@amelek.gda.pl>
7373 BFIN Jie Zhang <jzhang918@gmail.com>
74- BFIN Mike Frysinger <vapier@gentoo.org>
7574 BPF Jose E. Marchesi <jose.marchesi@oracle.com>
7675 CRIS Hans-Peter Nilsson <hp@axis.com>
7776 CTF Nick Alcock <nick.alcock@oracle.com>
@@ -87,15 +86,14 @@ responsibility among the other maintainers.
8786 FRV Alexandre Oliva <aoliva@sourceware.org>
8887 GOLD Ian Lance Taylor <iant@google.com>
8988 GOLD Cary Coutant <ccoutant@gmail.com>
90- gprofng Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
89+ gprofng Claudiu Zissulescu <claziss@gmail.com>
90+ gprofng Jose E. Marchesi <jemarch@gnu.org>
9191 HPPA Dave Anglin <dave.anglin@bell.net>
9292 HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only]
93- IA-64 Jim Wilson <wilson@tuliptree.org>
9493 ix86 H.J. Lu <hjl.tools@gmail.com>
9594 ix86 COFF DJ Delorie <dj@redhat.com>
9695 ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com>
9796 ix86 INTEL MODE Jan Beulich <jbeulich@suse.com>
98- KVX Paul Iannetta <piannetta@kalrayinc.com>
9997 libsframe Indu Bhagat <indu.bhagat@oracle.com>
10098 LM32 Jon Beniston <jon@beniston.com>
10199 LoongArch Chenghua Xu <xuchenghua@loongson.cn>
@@ -123,7 +121,7 @@ responsibility among the other maintainers.
123121 RISC-V Palmer Dabbelt <palmer@dabbelt.com>
124122 RISC-V Andrew Waterman <andrew@sifive.com>
125123 RISC-V Jim Wilson <jim.wilson.gcc@gmail.com>
126- RISC-V Nelson Chu <nelson@rivosinc .com>
124+ RISC-V Nelson Chu <nelson.chu1990@gmail .com>
127125 RX Nick Clifton <nickc@redhat.com>
128126 S12Z John Darrington <john@darrington.wattle.id.au>
129127 s390, s390x Andreas Krebbel <krebbel@linux.ibm.com>
@@ -140,7 +138,6 @@ responsibility among the other maintainers.
140138 x86_64 Jan Hubicka <jh@suse.cz>
141139 x86_64 Andreas Jaeger <aj@suse.de>
142140 x86_64 H.J. Lu <hjl.tools@gmail.com>
143- XCOFF Richard Sandiford <r.sandiford@uk.ibm.com>
144141 XGATE Sean Keys <skeys@ipdatasys.com>
145142 Xtensa Max Filippov <jcmvbkbc@gmail.com>
146143 Xtensa Sterling Augustine <augustine.sterling@gmail.com>
@@ -155,17 +152,22 @@ goes with them.
155152 Paul Brook
156153 Eric Christopher
157154 Jason Eckhardt
155+ Mike Frysinger
156+ Paul Iannetta
158157 Geoff Keating
159158 Mark Kettenis
160159 Walter Lee
161160 Mei Ligang
162161 Arnold Metselaar
162+ Vladimir Mezentsev
163163 Mark Mitchell
164+ Richard Sandiford
164165 Bernd Schmidt
165166 Svein Seldal
166- M R Swami Reddy
167167 Martin Schwidefsky
168+ M R Swami Reddy
168169 Matt Thomas
170+ Jim Wilson
169171
170172 --------- CGEN Maintainers -------------
171173
@@ -233,6 +235,67 @@ The details of the Developer's Certificate or Origin can be found here:
233235
234236 https://developercertificate.org/
235237
238+ --------- LLM Generated Patches ---------
239+
240+ The GNU Binutils project is currently *NOT* accepting LLM generated patches.
241+
242+ This is because the copyright status of code generated by a LLM (Large
243+ Language Model [1]) is currently unclear. The policy applies to all
244+ parts of the GNU Binutils including, but not limited to, source code,
245+ documentation and the testsuites.
246+
247+ There are however some exceptions to the policy:
248+
249+ * Using LLMs to assist in writing code is fine providing that the
250+ LLM does not actually generate code. So for example using an
251+ LLM to provide text to speech services or to search for published
252+ information is OK.
253+
254+ * LLM generated code that is not "legally significant"[2] is OK.
255+ As a rule of thumb, this means that trivial changes, such as
256+ spelling corrections, or small code formatting cleanups are fine.
257+
258+ Using an LLM to inspire or help create a patch might be OK. It is a
259+ question of whether LLM generated output eventually makes it into the
260+ patch. If it does, then the patch is unacceptable. (Unless it can
261+ be considered legally insignificant).
262+
263+ In addition all patch submissions must involve a human. Fully
264+ automated patch submission, whether by a bot, a script, or some other
265+ means is not acceptable. This is because only humans can sign a
266+ Developer Certificate of Origin or complete a FSF Copyright Assignment
267+ and one of these needs to be in place for every submission.
268+
269+ The copyright assignment or DCO allows the GNU Binutils project to
270+ trust that the submitter is legally able to make the contribution
271+ and that the submission can be used under the terms of the GNU General
272+ Public License (see the COPYING3 file).
273+
274+ Footnotes:
275+
276+ This policy is not set in stone. It may well be reviewed and changed
277+ in the future.
278+
279+ The policy uses the term "LLM generated" rather than "A.I. generated"
280+ as the latter could be misunderstood. See [3] for more details.
281+ Nevertheless the policy applies to any kind of machine generated
282+ contribution where the copyright status is unclear.
283+
284+ When submitting a non-legally-significant LLM generated change, it is
285+ encouraged to clearly indicate the use of the LLM. The identification
286+ could take the form of a line starting with the Generated-By: prefix
287+ which identifies the LLM used. For example:
288+
289+ Generated-By: GNU-LLM version 1.0
290+
291+ The reason for asking for this is to set a precedent. So in the
292+ future, if non-trivial LLM generated patches do become acceptable,
293+ the process of labeling them will already be a standard action.
294+
295+ [1]: https://en.wikipedia.org/wiki/Large_language_model
296+ [2]: https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
297+ [3]: https://www.gnu.org/philosophy/words-to-avoid.en.html#ArtificialIntelligence
298+
236299 --------- Branch Checkins ---------
237300
238301If a patch is approved for check in to the mainline sources, it can
@@ -331,7 +394,7 @@ Having selected the branch name, create the branch as follows:
331394Please do not commit any patches to a branch you did not create
332395without the explicit permission of the person who created the branch.
333396
334- Copyright (C) 2012-2025 Free Software Foundation, Inc.
397+ Copyright (C) 2012-2026 Free Software Foundation, Inc.
335398
336399Copying and distribution of this file, with or without modification,
337400are permitted in any medium without royalty provided the copyright
0 commit comments