Re: Claude AI code audit of GNUstep core stack — 1 50 fixes, 12 perf optimizations, all available for upstream

--000000000000a32d360656de63c7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM David Chisnall <gnustep@theravensne=
st.org>
wrote:

> On 14 Jul 2026, at 22:48, Gregory Casamento <[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=E2=80=99s =
quite
> surprising that most of the folks in this thread seem unfamiliar with the=
m,
> but I would add one thing:
>
> This week, EMACS paused =E2=80=98AI=E2=80=99 contributions because the GN=
U project is
> expected to provide an explicit policy soon. I presume that policy will
> apply to GNUstep as well.
>
> David
>
>

--=20
Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.openhub.net/languages/objective_c

--000000000000a32d360656de63c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><p class=3D"gmail-isSelectedEnd">David,</p><p class=3D"gmail-i=
sSelectedEnd">Sorry for the late reply; work has been very demanding lately=
.=C2=A0 Of course, any policy they issue will apply to us.=C2=A0 I think th=
is is a reasonable approach for EMACS if they are waiting for guidance from=
 the GNU Project.</p><p class=3D"gmail-isSelectedEnd">Until that policy is =
published, however, I don&#39;t think it gives us any basis for changing GN=
Ustep&#39;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.</p><p class=3D"gma=
il-isSelectedEnd">I believe our current policy provides a practical balance=
 as it focuses on licensing, provenance, code quality, review, and maintain=
ability rather than the specific tools contributors use.</p><p class=3D"gma=
il-isSelectedEnd">As mentioned in previous emails, I have set a clear line =
on what is acceptable, and this=C2=A0was reflected in the discussion a few=
=C2=A0weeks ago.</p><p>Yours, GC</p></div></div><br><div class=3D"gmail_quo=
te gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul=
 15, 2026 at 4:31=E2=80=AFAM David Chisnall &lt;<a href=3D"mailto:gnustep@t=
heravensnest.org">[email protected]</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">On 14 Jul 2026, at 22:48, Gregor=
y Casamento &lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt; wrote:<br>
&gt; <br>
&gt; Based on the discussion, I do not see sufficient consensus or justific=
ation to replace our existing AI policy with a &quot;No-AI&quot; policy for=
 the GNUstep core libraries. Accordingly, the existing policy will remain i=
n effect.<br>
<br>
Most of the arguments have been covered in other places and it=E2=80=99s qu=
ite surprising that most of the folks in this thread seem unfamiliar with t=
hem, but I would add one thing:<br>
<br>
This week, EMACS paused =E2=80=98AI=E2=80=99 contributions because the GNU =
project is expected to provide an explicit policy soon. I presume that poli=
cy will apply to GNUstep as well.<br>
<br>
David<br>
<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr"><font fac=
e=3D"monospace">Gregory Casamento<br>GNUstep Lead Developer / Black Lotus, =
Principal Consultant<br><a href=3D"http://www.gnustep.org" target=3D"_blank=
">http://www.gnustep.org</a> - <a href=3D"http://heronsperch.blogspot.com" =
target=3D"_blank">http://heronsperch.blogspot.com</a><br></font></div></div=
><div dir=3D"ltr"><font color=3D"#888888" face=3D"monospace"><a href=3D"htt=
ps://www.openhub.net/languages/objective_c" style=3D"color:rgb(17,85,204)" =
target=3D"_blank">https://www.openhub.net/languages/objective_c</a></font><=
/div></div></div></div>

--000000000000a32d360656de63c7--