Hi,
time passed and I had the holidays to think about this. In the
meanwhile, our group had a member reacting quite blunt to the
(perceived?) influx of AI assisted issues.
Things are not "terribly different", but it has a point of divergence,
or, better, a GCC addresses a pain point I am trying to bring up again
and again.
It tries to address the "amount" of work done with LLMs that is acceptable.
The wording "/legally significant/" is used. While it is clearly
lawyer-speak, I think it is understandable in its core. It also uses the
word "/good faith/".
Personally, I came up with the parallel of "what is copyrightable" or
"what needs FSF attribution".
What is "big" or "small". Gregory in some chats and emails used the
example "not code a whole class".
SLOC is not significant anymore - I could make hundreds of skeletons
autogenerated : lots of stuff, little real content. I could use AI to
write one single method of a class long hundreds of lines which is
critical and core to the class. It would pass the definition of "legally
significant".
I had some chats with people and was displeased by the counter-examples.
In core, they were putting the committer in bad faith, which is
something beyond control and only testable on analysis.
In sum: I think we should update our Policy by incorporating this
concept and perhaps the easiest way is to adopt the same wording.
The paragraph of Transparency and Accountability is also an interesting
part worth of mentioning. I like it and extend it also to tests and
issues, that is, any kind of contribution.
Riccardo
Gregory Casamento wrote:
GCC released their AI-Policy... it is not terribly different from ours
and aligns pretty closely. There are a few areas of divergence:
Their policy follows... this is available at
https://forge.sourceware.org/redi/gcc-wwwdocs/raw/commit/4d0793a6a14bf9bfe9e92ac1599840780355199d/htdocs/ai-policy.html
GNU Compiler Collection - AI Policy
Community First
First, all contributors should be treated with respect and kindness
<https://gcc.gnu.org/conduct.html>. There are strongly held and widely
varying opinions regarding large language models (LLMs) and everyone
should be presumed to be contributing in good faith. We welcome all
contributors to the community even if they have not yet followed our
policies; we should guide such contributors on how to do so.
Acceptable Contributions
For the time being, the GNU Compiler Collection (GCC) policy is to
decline any legally significant
<https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant> contributions
which include LLM-generated content or are derived from LLM-generated
content.
The GCC maintainers are free to accept legally insignificant
<https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant> contributions
generated by an LLM as long as they meet the usual prerequisites
<https://gcc.gnu.org/contribute.html> for any contribution and the
contribution is clearly marked.
As an exception, the GCC maintainers are free to accept /legally
significant/
<https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant> contributions
to *test cases*, generated in whole or in part by an LLM.
This policy does not apply to code which does not primarily belong to
the GCC project, but is imported from other projects for convenience
or to satisfy prerequisites (e.g. libsanitizer).
Transparency & Accountability
The commit message for any contribution of LLM-generated content must
include an “Assisted-by:” tag.
All contributions must be submitted by a human who understands the
changes and is prepared to answer questions about them. The decision
to include the contribution in the project must also be made by a
human. Only a human may provide the “Signed-off-by:” tag certifying
the Developer Certificate of Origin (DCO)
<https://developercertificate.org/>. An LLM may not commit code to the
project repository.
Personal Use
This policy does not apply to a contributor's other uses of AI
including the use of these tools to enable them to work with their own
computing devices e.g. screen readers, text-to-speech, direct
translations, spelling or grammar assistance, where the contributor
verifies the output of the tool.
This policy does not apply to a contributor's use of AI for the
purposes of research, analysis, bug discovery and reporting (output
should not be sent verbatim without due consideration), patch review
(supporting human review, not replacing it) and debugging, so long as
the output is not included in the contributions to the project. If the
output is included in the contributions to the project then this
policy would apply.
Next Steps
This policy is expected to evolve with the community or as the overall
GNU Project position is updated. At the latest the policy will be
reviewed at the start of 2027.
This work is marked CC0 1.0 Universal
<https://creativecommons.org/publicdomain/zero/1.0/>
To Summarize:
GNUstep's approach is outcome-based: contributions are judged on
licensing, provenance, quality, correctness, maintainability, and
human review regardless of the tools used to create them. GCC's
approach is process-based for legally significant contributions:
AI-generated code is declined because of legal and provenance
concerns, even if the resulting code would otherwise satisfy the
project's technical standards.
This seems fairly closely aligned with our approach with the exception
of code that is wholly generated by an LLM. Our approach emphasizes
caution in this case and, during our discussion, I recommended not
accepting this kind of contribution. We are not bound by GCC's
policy, and I recommend we review ours as it becomes necessary as well.
Yours, GC
On Sat, Jul 18, 2026 at 12:23 PM Gregory Casamento
<[email protected] <mailto:[email protected]>> wrote:
Lars,
I don't know how the GNU Project is arriving at its policy or
whether individual GNU projects have an opportunity to provide
input. I have written to RMS about our policy and given him a link
to it. I hope it can inform any decision they make.
I don't think the discussion should become a witch hunt either. AI
is a tool, and like any tool, it can be used well or poorly.
Regardless of how code is produced, I believe our responsibility
as maintainers remains the same: to ensure that contributions meet
our standards for licensing, provenance, quality, correctness,
maintainability, and review.
Ultimately, those standards are what determine whether code
belongs in GNUstep, not the particular tools used during its
development.
I'm hoping the GNU Project reaches a thoughtful and balanced
conclusion.
Yours, Greg
On Sat, Jul 18, 2026 at 5:00 AM [email protected]
<mailto:[email protected]>
<[email protected]
<mailto:[email protected]>> wrote:
Hi Greg,
just one question in this regard: Do we have a voice in GNU’s
discussion on that topic (I hope, there is a discussion an not
just a decision by one person, namely RMS)? If so, I hope, we
make our standpoint clear and don’t go onto a witch-hunt
against AI (which would be like a witch hunt against compilers
and linkers in the times when UNIX was still written in
assembler). In my opinion AI is just a (very sophisticated)
tool which you need to know, how to use it and its
limitations. Then we can use it sanely and to our advantage.
Hoping for the best outcome,
Lars
Am 18.07.2026 um 10:23 schrieb Gregory Casamento
<[email protected] <mailto:[email protected]>>:
David,
Sorry for the late reply; work has been very demanding
lately. Of course, any policy they issue will apply to us.
I think this is a reasonable approach for EMACS if they are
waiting for guidance from the GNU Project.
Until that policy is published, however, I don't think it
gives us any basis for changing GNUstep's existing approach.
Once the GNU Project has issued its guidance, we can evaluate
it on its merits, determine whether and how it applies to
GNUstep, and discuss whether any changes are warranted.
I believe our current policy provides a practical balance as
it focuses on licensing, provenance, code quality, review,
and maintainability rather than the specific tools
contributors use.
As mentioned in previous emails, I have set a clear line on
what is acceptable, and this was reflected in the discussion
a few weeks ago.
Yours, GC
On Wed, Jul 15, 2026 at 4:31 AM David Chisnall
<[email protected]
<mailto:[email protected]>> wrote:
On 14 Jul 2026, at 22:48, Gregory Casamento
<[email protected]
<mailto:[email protected]>> wrote:
>
> Based on the discussion, I do not see sufficient
consensus or justification to replace our existing AI
policy with a "No-AI" policy for the GNUstep core
libraries. Accordingly, the existing policy will remain
in effect.
Most of the arguments have been covered in other places
and it’s quite surprising that most of the folks in this
thread seem unfamiliar with them, but I would add one thing:
This week, EMACS paused ‘AI’ contributions because the
GNU project is expected to provide an explicit policy
soon. I presume that policy will apply to GNUstep as well.
David
