Riccardo,
Our policy already has something similar. Here:
---
## 5. Disclosure Requirement
Contributors should disclose AI assistance when it materially shaped the
submission (for example, where significant portions of code or
an AI system drafted documentation).
Disclosure may be included in:
- The merge request or pull request description
- The commit message
Disclosure is intended to assist reviewers in calibrating review depth,
not to discourage responsible use of tooling.
---
I think this covers the same ground for us. Additionally, we have this:
---
## 7. Contributor Responsibilities
Anyone submitting AI-assisted content must be prepared to:
- Explain clearly what the change does and why it is correct
- Provide reproduction steps, tests, or benchmarks when relevant
- Revise or withdraw a submission if concerns arise regarding
correctness, security, maintainability, or licensing
---
We have another section by the same name, by the way, they should be
combined. :)
Also, I have recently added:
- Generate entire classes / features
to section 6 (Prohibited uses). The reason for adding this is because of
the case I mentioned (Thaler v. Perlmutter) that establishes that, unless
a human has made significant contributions, the content can't be
copyrighted. This protects us against legal issues regarding the
provenance of the code.
I feel as though the GCC policy is too prohibitive. Additionally, I feel as
though an overly restrictive policy, as I have mentioned in previous posts,
is not enforceable. As has been demonstrated in the past, your "Turing
meter" is very much off. ;) (kidding on that last part).
We are under no obligation to follow GCC's policy whatsoever. I believe
what we have strikes a good balance. Becoming overly restrictive will put
us at a significant disadvantage. Constantly questioning people's code (as
has happened with mine and others) damages developer trust. Historically,
the FSF has focused on:
* The four essential freedoms
* Copyleft licensing
* Source availability and modifiability
Historically, the FSF has NOT focused on the tools used to create software.
Consider a simple edge case: I can write a script that generates
boilerplate from a class name—something I've done before. I could easily
extend it to discover includes and generate accessors automatically. The
resulting code could exceed the usual 15-line threshold, particularly for
classes that are little more than data holders.
How is that fundamentally different from using AI to generate the same
boilerplate? In both cases, a tool generates code algorithmically. If one
is acceptable and the other isn't, we need a clear technical or legal
distinction explaining why.
It is important to protect ourselves, but equally important is to welcome
contributions.
Yours, GC
On Fri, Sep 4, 2026 at 3:59 AM Riccardo Mottola <[email protected]>
wrote:
> 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
> >>
> >>
> >>
>
>
--
Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.openhub.net/languages/objective_c
