Re: Claude AI code audit of GNUstep core stack — 1 50 fixes, 12 perf optimizations, all available for upstream
Gregory Casamento <[email protected]> Sat, 11 Jul 2026 14:36:35 -0400
| Newsgroups | gmane.comp.lib.gnustep.devel |
|---|---|
| Message-ID | <CA+BLX-zy++mmKVXCAZQJwFg5r4PLqkH3nj2qrDZuCdYpC1+DDw@mail.gmail.com> |
--0000000000009c524e06565a2422 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Riccardo, Please see the response below... On Sat, Jul 11, 2026 at 8:43=E2=80=AFAM Riccardo Mottola <riccardo.mottola@= libero.it> wrote: > Hi, > > Foreword 1: when for brevity I am referring to AI, I am referring to the > latest trend of the "big plagiarism machine" to cite David (or I prefer > Chomsky's wording "High Tech Plagiarism"): large systems that suck code > from everywhere, closed and open source, that scavenge every available > resource and site (including our own) and digest everything. Well aware > that AI could be local, integrated in Lisp, neural networks in chips and > a lot of other usages of AI and Neural Networks all branded of "AI". > > Foreword 2: I reiterate that I think specifically of "core > gnustep.org"... any user/coder can do what they wish. A bit like > licensing, you can vibe code and use a human-coded library and have no > issues, but if you want an AI-free app and use an AI core or > environment, you are tainted > > Gregory Casamento wrote: > > > > We have already discussed and outlined a policy regarding this. It > > was discussed about 2 months ago days after a previous weekend > > meeting, due to Fred's concerns. > > > Things change rapidly, a lot of development is going on, discussion and > awareness of AI. I am exposed to a lot of it at work. 2 months is a lot. > I remember your policy, having it read and discussed with Fred. Nothing > wrong with it, albeit is relatively "soft". > I don=E2=80=99t disagree that AI is evolving rapidly. My concern is that ou= r policy should be based on principles that remain valid even as the technology changes, rather than reacting to every new development. The current policy was designed around the things we can actually evaluate and enforce: the quality of the submitted code, disclosure where appropriate, and compliance with our licensing and contribution requirements. Those principles haven=E2=80=99t changed. Calling the policy =E2=80=9Csoft=E2=80=9D implies that a stricter policy wo= uld produce better outcomes, but I haven=E2=80=99t seen evidence that it would. What I = have seen is that drawing a practical, enforceable line between AI-assisted development and traditional tooling is becoming increasingly difficult. A policy that cannot be applied consistently risks arbitrary enforcement and discouraging contributors without improving code quality. *We are not in a position to pick and choose given that we struggle to find contributors for other reasons as it is.* > When I have seen various projects being badged as "AI Free" or "Made by > Humans" I thought that it is something that GNUstep would fit in. A > niche of freedom and ethics very akin with the legacy of OpenSource > > It could develop in an attribute for inclusion or exclusion in certain > projects, like the License issues and wars. > > I'm not here to make forecasts, but it is a trend to observe. > Yet you are making forecasts. I can understand the appeal of that as a branding exercise, but I don=E2=80=99t think it is a good direction for GNU= step. Our identity has always been built around software freedom, portability, quality, and openness to contributors. I mentioned this in my last email. Those are enduring principles. =E2=80=9CAI Free=E2=80=9D defines the project by t= he tools contributors are *not* allowed to use, rather than by the software we produce. Unlike licensing, which governs the rights and obligations attached to the code itself, restricting development tools regulates *how* contributors work. That is a fundamentally different kind of policy, and one that becomes increasingly difficult to define and enforce as AI capabilities become integrated into editors, IDEs, compilers, refactoring tools, and code analysis. I would rather GNUstep continue to judge contributions on their merits: correctness, maintainability, licensing, and adherence to our coding standards. If a contribution meets those standards, I don=E2=80=99t believe= the implementation tools should be the deciding factor. > > I don't think we should regulate HOW the code we accept is written, > > only the code that is submitted to us. > > > > This sounds logical, but is wrong. Proof: If I copy wonderful code from > another project "robbing" it maybe even from another license, I would > see good code, but it was written badly. How verifiable it is is > questionable, stil in the ethics and responsibility of the submitter. > I don=E2=80=99t think those are equivalent cases. It's important to rememb= er that AI is more than just a stochastic prediction engine, there is a neural network involved that makes associations, etc. No court in the US or abroad has ruled that anything produced by AI is a derivative work. That being said I agree with the use of AI as a tool to help people find bugs or fix them. I don't think that creating entire classes using it is acceptable. I believe that our current AI policy strikes this balance. If someone copies code from another project without respecting its license or attribution requirements, the problem isn=E2=80=99t *how* they wrote it.= The problem is that they submitted code that we do not have the legal right to accept or distribute. That is a property of the submission itself. Likewise, if someone intentionally misrepresents the origin of a contribution, that is misconduct regardless of whether AI was involved. AI use, by itself, is different. Assuming the contributor complies with our disclosure policy and the submitted code satisfies our licensing, quality, and maintainability requirements, then the issue is the development tool that assisted them, not a defect in the resulting contribution. To me, those are fundamentally different categories. One concerns the legal provenance and rights associated with the code we are distributing; the other concerns the private workflow a contributor used to create code that we are otherwise willing and able to accept. > > *It is a practical impossibility to enforce your proposal.* Where do > > you draw the line between AI-Generated code and AI-assisted? Do you > > ban autocompleted code, refactoring, bug detection, and boilerplate > > code? Even Emacs has a .el extension to interface with OpenAI or > > Claude, etc. Also, some IDEs allow users to do code transformation. > > Enforcement of origin is hard as for other means (e.g. plagiarizing > other code). Yet we ask for it... I agree that not every policy has to be perfectly enforceable. We rely on contributors to be truthful about licensing, authorship, and other matters that we cannot always independently verify. This is why I am concerned with what you're saying. If we say we ABSOLUTELY ban AI, then the issue becomes we are discouraging people from contributing (potentially) and yet still have the same problem because how do we tell? You and others have misidentified code done by me as AI when it was done by me directly, thereby proving my point. The difference is that those policies exist to protect the project from concrete legal or ethical risks associated with the code we distribute. They concern properties of the contribution itself. An AI-use policy is different. It attempts to regulate the contributor=E2= =80=99s development process. Given how rapidly AI features are becoming embedded into editors, IDEs, refactoring tools, static analyzers, and even operating systems, it becomes increasingly unclear what should count as =E2=80=9CAI u= se.=E2=80=9D If we cannot define that boundary clearly, then we cannot apply the policy consistently. Contributors acting in good faith may reach different conclusions about whether a given feature requires disclosure or is even prohibited. To me, that is a poor basis for project governance. I=E2=80=99d rather have policies that are clear, objective, and tied to things we can evaluate: licensing, provenance, correctness, maintainability, and code quality. > > *We have historically judged code on quality, correctness, and > > maintainability. * If a patch doesn't meet these standards, it's > > rejected. If it does, how it was produced, so long as it fits the > > existing policy with respect to AI already outlined and as long as the > > user discloses its use, should not be an issue. > > Depends on "issue". In terms of maintainability, fine. But if you seek > as "proof of origin" not. I agree that provenance matters, but only to the extent that it protects the project from a concrete risk. Today we ask contributors to attest to authorship and licensing because those have direct legal consequences. If someone submits code they do not have the right to contribute, that creates a problem for the project regardless of the quality of the code. I=E2=80=99m not convinced AI use falls into the same category. If the contr= ibutor has the legal right to contribute the code, complies with our disclosure policy, and the patch satisfies our technical standards, then I don=E2=80= =99t see what additional risk is addressed by treating AI-assisted code differently. So I think the question then becomes: what project risk does an =E2=80=9CAI= -free=E2=80=9D policy mitigate that our existing requirements for licensing, provenance, disclosure, and code review do not already address? > > Also, the idea that "AI-free" is a selling point is very > > questionable. People adopt us because of GNUstep's portability, > > stability, and API compatibility (such as it is)... not because the > > contributors used certain tools to write the code. > > That applied in the past and should remain true. But now we have a new > attribute, which is AI-free vs AI-assisted AI-coded and whatever else. I agree that it is a new attribute. Where we differ is on whether it is an attribute of the software or of the development process. Portability, API compatibility, licensing, code quality, and maintainability are all properties of the software we write. They are things our users receive and can rely upon. =E2=80=9CAI-free=E2=80=9D is different. It is a statement about the tools c= ontributors used while creating the software. Once the code is submitted, reviewed, accepted, and maintained, that attribute isn=E2=80=99t reflected in the sof= tware itself. I=E2=80=99m not opposed to projects choosing to make that part of their ide= ntity. I simply don=E2=80=99t think it aligns with GNUstep=E2=80=99s long-standing p= hilosophy of evaluating contributions on what they contribute to the project rather than on the particular tools the contributor chose to use. If someone wants to adopt GNUstep because it=E2=80=99s portable, standards-compliant, stable, or free software, those are enduring characteristics of the project itself. Whether a contributor used Vim, Emacs, CLion, clang-tidy, coccinelle, or an AI-assisted editor doesn=E2=80= =99t change those characteristics. > > If we want a selling point, I'd say we stick with the one we already > > discussed on the mailing list previously with respect to review. We > > accept only well-reviewed, well-engineered, and well-understood code > > REGARDLESS of how an initial draft was produced. > > That is your opinion, I am giving an alternative view. It is not even my > final opinion, I am discussing. > > My current "gut" feeling would be to keep a defined perimeter (roughly > "gnustep core or gnustep.org") free from vibe coding and leaving freedom > for every other app or derived project. Vice-versa AI generated bug > reports would be to the taste of each individual maintainer and > preferably labelled as such > This is just a thought, not an idea of final policy or such. That=E2=80=99s a much narrower proposal, and I appreciate that you=E2=80=99= re exploring ideas rather than presenting a finished policy. I still have reservations, though. My concern isn=E2=80=99t primarily whether the boundary is =E2=80=9CGNUstep= core=E2=80=9D or the entire ecosystem=E2=80=94it=E2=80=99s whether the criterion is one we want = to govern at all. Historically we=E2=80=99ve accepted or rejected contributions based on whet= her they improve the project: correctness, maintainability, licensing, review, and whether the reviewer understands and is willing to maintain the code. Those are objective criteria tied directly to the software. Once we start distinguishing between =E2=80=9Chuman-written=E2=80=9D, =E2= =80=9CAI-assisted=E2=80=9D, =E2=80=9CAI-generated=E2=80=9D, =E2=80=9Cvibe-coded=E2=80=9D, etc., we=E2= =80=99re no longer evaluating the contribution itself=E2=80=94we=E2=80=99re evaluating the contributor=E2=80= =99s workflow. I think those boundaries are becoming increasingly difficult to define consistently, and I worry we=E2=80=99ll spend more time debating where they= lie than reviewing code. If someone submits a patch that is technically sound, legally acceptable, fully understood by both the contributor and the reviewer, and maintainable, I still think that=E2=80=99s the right basis on which to deci= de whether it belongs in GNUstep. > > So your "act now" sentiment, while understood, is hardly needed as we > > already acted as discussed. There was a post to this mailing list > > regarding this very subject that outlined the policy. > > As new factors come to play, past decisions should be re-evaluated. 10 > years ago we wouldn't even thought of it. > > Even within some members in project I have used and discussed AI. Things > are evolving. > I agree with that in principle. We should absolutely revisit our policies when circumstances change. Re-evaluating them is healthy project governance= . Where I disagree is in the conclusion. After re-evaluating our policy in light of current AI tools, it still addresses what matters: disclosure, licensing, provenance, code quality, review, and maintainability. What I haven=E2=80=99t yet seen is a compelling project-specific reason to = regulate contributors=E2=80=99 choice of development tools beyond those existing requirements. If that changes=E2=80=94if there=E2=80=99s a concrete legal, technical, or = maintenance issue that our current policy fails to address=E2=80=94then I=E2=80=99m ope= n to discussing changes. But I=E2=80=99d want the policy to be driven by an identified prob= lem rather than by the pace of AI development itself. Technology changing is a reason to review a policy. It=E2=80=99s not, by it= self, a reason to replace one. > Regards, > > Riccardo By the way, I am personally opposed to using AI to generate an entire library or even an entire class. At that point, I think it becomes much harder for the contributor to fully understand, review, and stand behind the code, and it can also raise questions about provenance and licensing that deserve depper scrutiny. I simply think our existing policy strikes the right balance by requiring disclosure while continuing to judge submissions on their quality, legality, and maintainability. Yours, GC --=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 --0000000000009c524e06565a2422 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace,monospace">Riccardo,</div><div class=3D"gmail_default" s= tyle=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_defa= ult" style=3D"font-family:monospace,monospace">Please see the response belo= w...</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div d= ir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 11, 2026 at 8:43=E2=80=AFAM Ric= cardo Mottola <<a href=3D"mailto:[email protected]">riccardo.mo= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex">Hi,<br> <br> Foreword 1: when for brevity I am referring to AI, I am referring to the <b= r> latest trend of the "big plagiarism machine" to cite David (or I = prefer <br> Chomsky's wording "High Tech Plagiarism"): large systems that= suck code <br> from everywhere, closed and open source, that scavenge every available <br> resource and site (including our own) and digest everything. Well aware <br= > that AI could be local, integrated in Lisp, neural networks in chips and <b= r> a lot of other usages of AI and Neural Networks all branded of "AI&quo= t;.<br> <br> Foreword 2: I reiterate that I think specifically of "core <br> <a href=3D"http://gnustep.org" rel=3D"noreferrer" target=3D"_blank">gnustep= .org</a>"... any user/coder can do what they wish. A bit like <br> licensing, you can vibe code and use a human-coded library and have no <br> issues, but if you want an AI-free app and use an AI core or <br> environment, you are tainted<br> <br> Gregory Casamento wrote:<br> ><br> > We have already discussed and outlined a policy regarding this.=C2=A0 = It <br> > was discussed about 2 months ago days after a previous weekend <br> > meeting, due to Fred's concerns.<br> ><br> Things change rapidly, a lot of development is going on, discussion and <br= > awareness of AI. I am exposed to a lot of it at work. 2 months is a lot.<br= > I remember your policy, having it read and discussed with Fred. Nothing <br= > wrong with it, albeit is relatively "soft".<br></blockquote><div>= <br></div><div><div class=3D"gmail_default" style=3D""><font face=3D"monosp= ace"><span style=3D"background-color:transparent">I don=E2=80=99t disagree = that AI is evolving rapidly. My concern is that our policy should be based = on principles that remain valid even as the technology changes, rather than= reacting to every new development.</span></font></div> <p class=3D"gmail-p1"><font face=3D"monospace">The current policy was desig= ned around the things we can actually evaluate and enforce: the quality of = the submitted code, disclosure where appropriate, and compliance with our l= icensing and contribution requirements. Those principles haven=E2=80=99t ch= anged.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Calling the policy =E2=80=9C= soft=E2=80=9D implies that a stricter policy would produce better outcomes,= but I haven=E2=80=99t seen evidence that it would. What I have seen is tha= t drawing a practical, enforceable line between AI-assisted development and= traditional tooling is becoming increasingly difficult. A policy that cann= ot be applied consistently risks arbitrary enforcement and discouraging con= tributors without improving code quality.</font></p><p class=3D"gmail-p1"><= span class=3D"gmail_default" style=3D"font-family:monospace,monospace"><b>W= e are not in a position to pick and choose given that we struggle to find c= ontributors for other reasons as it is.</b></span><br></p></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex">When I have seen various projects be= ing badged as "AI Free" or "Made by <br> Humans" I thought that it is something that GNUstep would fit in. A <b= r> niche of freedom and ethics very akin with the legacy of OpenSource<br> <br> It could develop in an attribute for inclusion or exclusion in certain <br> projects, like the License issues and wars.<br> <br> I'm not here to make forecasts, but it is a trend to observe.<br></bloc= kquote><div><br></div><div><div class=3D"gmail_default" style=3D""><font fa= ce=3D"monospace">Yet you are making forecasts.=C2=A0=C2=A0<span style=3D"ba= ckground-color:transparent">I can understand the appeal of that as a brandi= ng exercise, but I don=E2=80=99t think it is a good direction for GNUstep.<= /span></font></div> <p class=3D"gmail-p1"><font face=3D"monospace">Our identity has always been= built around software freedom, portability, quality, and openness to contr= ibutors. <span class=3D"gmail_default" style=3D"font-family:monospace,monos= pace">I mentioned this in my last email.=C2=A0=C2=A0</span>Those are enduri= ng principles. =E2=80=9CAI Free=E2=80=9D defines the project by the tools c= ontributors are <span class=3D"gmail-s1"><i>not</i></span> allowed to use, = rather than by the software we produce.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Unlike licensing, which gove= rns the rights and obligations attached to the code itself, restricting dev= elopment tools regulates <span class=3D"gmail-s1"><i>how</i></span> contrib= utors work. That is a fundamentally different kind of policy, and one that = becomes increasingly difficult to define and enforce as AI capabilities bec= ome integrated into editors, IDEs, compilers, refactoring tools, and code a= nalysis.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">I would rather GNUstep conti= nue to judge contributions on their merits: correctness, maintainability, l= icensing, and adherence to our coding standards. If a contribution meets th= ose standards, I don=E2=80=99t believe the implementation tools should be t= he deciding factor.</font></p></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"> > I don't think we should regulate HOW the code we accept is written= , <br> > only the code that is submitted to us.<br> ><br> <br> This sounds logical, but is wrong. Proof: If I copy wonderful code from <br= > another project "robbing" it maybe even from another license, I w= ould <br> see good code, but it was written badly. How verifiable it is is <br> questionable, stil in the ethics and responsibility of the submitter.<br></= blockquote><div><br></div><div><p class=3D"gmail-p1"><font face=3D"monospac= e"><span class=3D"gmail_default" style=3D"">I</span>=C2=A0don=E2=80=99t thi= nk those are equivalent cases.<span class=3D"gmail_default" style=3D"font-f= amily:monospace,monospace">=C2=A0 It's important to remember that AI is= more than just a stochastic prediction engine, there is a neural network i= nvolved that makes associations, etc.=C2=A0 No court in the US or abroad ha= s ruled that anything produced by AI is a derivative work.=C2=A0 That being= said I agree with the use of AI as a tool to help people find bugs or fix = them.=C2=A0 I don't think that creating entire classes using it is acce= ptable.=C2=A0 I believe that our current AI policy strikes this balance.</s= pan></font></p> <p class=3D"gmail-p1"><font face=3D"monospace">If someone copies code from = another project without respecting its license or attribution requirements,= the problem isn=E2=80=99t <span class=3D"gmail-s1"><i>how</i></span> they = wrote it. The problem is that they submitted code that we do not have the l= egal right to accept or distribute. That is a property of the submission it= self.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Likewise, if someone intenti= onally misrepresents the origin of a contribution, that is misconduct regar= dless of whether AI was involved.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">AI use, by itself, is differ= ent. Assuming the contributor complies with our disclosure policy and the s= ubmitted code satisfies our licensing, quality, and maintainability require= ments, then the issue is the development tool that assisted them, not a def= ect in the resulting contribution.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">To me, those are fundamental= ly different categories. One concerns the legal provenance and rights assoc= iated with the code we are distributing; the other concerns the private wor= kflow a contributor used to create code that we are otherwise willing and a= ble to accept.</font></p></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex">> *It is a practical impossibility to enforce your proposal.*=C2= =A0 Where do <br> > you draw the line between AI-Generated code and AI-assisted?=C2=A0 Do = you <br> > ban autocompleted=C2=A0code, refactoring, bug detection, and boilerpla= te <br> > code?=C2=A0 Even Emacs has a .el extension to interface with OpenAI or= <br> > Claude, etc. Also, some IDEs allow users to do code transformation.<br= > <br> Enforcement of origin is hard as for other means (e.g. plagiarizing <br> other code). Yet we ask for it...</blockquote><div><p class=3D"gmail-p1"><f= ont face=3D"monospace">I agree that not every policy has to be perfectly en= forceable. We rely on contributors to be truthful about licensing, authorsh= ip, and other matters that we cannot always independently verify.<span clas= s=3D"gmail_default" style=3D"font-family:monospace,monospace">=C2=A0 This i= s why I am concerned with what you're saying.=C2=A0=C2=A0</span></font>= </p><p class=3D"gmail-p1"><font face=3D"monospace"><span class=3D"gmail_def= ault" style=3D"font-family:monospace,monospace">If we say we ABSOLUTELY ban= AI, then the issue becomes we are discouraging people from contributing (p= otentially) and yet still have the same problem because how do we tell?=C2= =A0 You and others have misidentified code done by me as AI when it was don= e by me directly, thereby proving my point.</span></font></p> <p class=3D"gmail-p1"><font face=3D"monospace">The difference is that those= policies exist to protect the project from concrete legal or ethical risks= associated with the code we distribute. They concern properties of the con= tribution itself.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">An AI-use policy is differen= t. It attempts to regulate the contributor=E2=80=99s development process. G= iven how rapidly AI features are becoming embedded into editors, IDEs, refa= ctoring tools, static analyzers, and even operating systems, it becomes inc= reasingly unclear what should count as =E2=80=9CAI use.=E2=80=9D</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">If we cannot define that bou= ndary clearly, then we cannot apply the policy consistently. Contributors a= cting in good faith may reach different conclusions about whether a given f= eature requires disclosure or is even prohibited.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">To me, that is a poor basis = for project governance. I=E2=80=99d rather have policies that are clear, ob= jective, and tied to things we can evaluate: licensing, provenance, correct= ness, maintainability, and code quality.</font></p></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> > *We have historically judged code on quality, correctness, and <br> > maintainability. * =C2=A0If a patch doesn't meet these standards, = it's <br> > rejected.=C2=A0 =C2=A0If it does, how it was produced, so long as it f= its the <br> > existing policy with respect to AI already outlined and as long as the= <br> > user discloses its use, should not=C2=A0be an issue.<br> <br> Depends on "issue". In terms of maintainability, fine. But if you= seek <br> as "proof of origin" not.</blockquote><div><p class=3D"gmail-p1">= <font face=3D"monospace">I agree that provenance matters, but only=C2=A0<sp= an class=3D"gmail_default" style=3D"font-family:monospace,monospace">to the= extent</span>=C2=A0<span class=3D"gmail_default" style=3D"font-family:mono= space,monospace">that</span> it protects the project from a concrete risk.<= /font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Today we ask contributors to= attest to authorship and licensing because those have direct legal consequ= ences. If someone submits code they do not have the right to contribute, th= at creates a problem for the project regardless of the quality of the code.= </font></p> <p class=3D"gmail-p1"><font face=3D"monospace">I=E2=80=99m not convinced AI= use falls into the same category. If the contributor has the legal right t= o contribute the code, complies with our disclosure policy, and the patch s= atisfies our technical standards, then I don=E2=80=99t see what additional = risk is addressed by treating AI-assisted code differently.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">So I think the question <spa= n class=3D"gmail_default" style=3D"font-family:monospace,monospace"></span>= t<span class=3D"gmail_default" style=3D"font-family:monospace,monospace">he= n becomes</span>: what project risk does an =E2=80=9CAI-free=E2=80=9D polic= y mitigate that our existing requirements for licensing, provenance, disclo= sure, and code review do not already address?</font></p></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"> > Also, the idea that "AI-free" is a selling point is very <br= > > questionable.=C2=A0 People adopt us because of GNUstep's=C2=A0port= ability, <br> > stability, and API compatibility (such as it is)... not because the <b= r> > contributors used certain tools to write the code.<br> <br> That applied in the past and should remain true. But now we have a new <br> attribute, which is AI-free vs AI-assisted AI-coded and whatever else.</blo= ckquote><div><p class=3D"gmail-p1"><font face=3D"monospace">I agree that it= is a new attribute. Where we differ is on whether it is an attribute of th= e software or of the development process.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Portability, API compatibili= ty, licensing, code quality, and maintainability are all properties of the = software we <span class=3D"gmail_default" style=3D"font-family:monospace,mo= nospace">write</span>. They are things our users receive and can rely upon.= </font></p> <p class=3D"gmail-p1"><font face=3D"monospace">=E2=80=9CAI-free=E2=80=9D is= different. It is a statement about the tools contributors used while creat= ing the software. Once the code is submitted, reviewed, accepted, and maint= ained, that attribute isn=E2=80=99t reflected in the software itself.</font= ></p> <p class=3D"gmail-p1"><font face=3D"monospace">I=E2=80=99m not opposed to p= rojects choosing to make that part of their identity. I simply don=E2=80=99= t think it aligns with GNUstep=E2=80=99s long-standing philosophy of evalua= ting contributions on what they contribute to the project rather than on th= e particular tools the contributor chose to use.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">If someone wants to adopt GN= Ustep because it=E2=80=99s portable, standards-compliant, stable, or free s= oftware, those are enduring characteristics of the project itself. Whether = a contributor used Vim, Emacs, CLion, clang-tidy, coccinelle, or an AI-assi= sted editor doesn=E2=80=99t change those characteristics.</font></p></div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> > If we want a selling point, I'd say we stick with the one we alrea= dy <br> > discussed on the mailing list previously with respect to review.=C2=A0= =C2=A0We <br> > accept only well-reviewed, well-engineered, and well-understood code <= br> > REGARDLESS of how an initial draft was produced.<br> <br> That is your opinion, I am giving an alternative view. It is not even my <b= r> final opinion, I am discussing.<br> <br> My current "gut" feeling would be to keep a defined perimeter (ro= ughly <br> "gnustep core or <a href=3D"http://gnustep.org" rel=3D"noreferrer" tar= get=3D"_blank">gnustep.org</a>") free from vibe coding and leaving fre= edom <br> for every other app or derived project. Vice-versa AI generated bug <br> reports would be to the taste of each individual maintainer and <br> preferably labelled as such<br> This is just a thought, not an idea of final policy or such.</blockquote><d= iv><p class=3D"gmail-p1"><font face=3D"monospace">That=E2=80=99s a much nar= rower proposal, and I appreciate that you=E2=80=99re exploring ideas rather= than presenting a finished policy.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">I still have reservations, t= hough.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">My concern isn=E2=80=99t pri= marily whether the boundary is =E2=80=9CGNUstep core=E2=80=9D or the entire= ecosystem=E2=80=94it=E2=80=99s whether the criterion is one we want to gov= ern at all.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Historically we=E2=80=99ve a= ccepted or rejected contributions based on whether they improve the project= : correctness, maintainability, licensing, review, and whether the reviewer= understands and is willing to maintain the code. Those are objective crite= ria tied directly to the software.</font></p> <p class=3D"gmail-p1"><font face=3D"monospace">Once we start distinguishing= between =E2=80=9Chuman-written=E2=80=9D, =E2=80=9CAI-assisted=E2=80=9D, = =E2=80=9CAI-generated=E2=80=9D, =E2=80=9Cvibe-coded=E2=80=9D, etc., we=E2= =80=99re no longer evaluating the contribution itself=E2=80=94we=E2=80=99re= evaluating the contributor=E2=80=99s workflow. I think those boundaries ar= e becoming increasingly difficult to define consistently, and I worry we=E2= =80=99ll spend more time debating where they lie than reviewing code.</font= ></p> <p class=3D"gmail-p1"><font face=3D"monospace">If someone submits a patch t= hat is technically sound, legally acceptable, fully understood by both the = contributor and the reviewer, and maintainable, I still think that=E2=80=99= s the right basis on which to decide whether it belongs in GNUstep.</font><= /p></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > So your "act now" sentiment, while understood, is hardly nee= ded as we <br> > already acted as discussed.=C2=A0 There was a post to this mailing lis= t <br> > regarding this very subject that outlined the policy.<br> <br> As new factors come to play, past decisions should be re-evaluated. 10 <br> years ago we wouldn't even thought of it.<br> <br> Even within some members in project I have used and discussed AI. Things <b= r> are evolving.<br></blockquote><div><br></div><div><font face=3D"monospace">= I agree with that in principle. We should absolutely revisit our policies w= hen circumstances change. Re-evaluating them is healthy project governance.= <br><br>Where I disagree=C2=A0is in the conclusion. After re-evaluating our= policy in light of current AI tools, it still addresses what matters: disc= losure, licensing, provenance, code quality, review, and maintainability.<b= r><br>What I haven=E2=80=99t yet seen is a compelling project-specific reas= on to regulate contributors=E2=80=99 choice of development tools beyond tho= se existing requirements.<br><br>If that changes=E2=80=94if there=E2=80=99s= a concrete legal, technical, or maintenance issue that our current policy = fails to address=E2=80=94then I=E2=80=99m open to discussing changes. But I= =E2=80=99d want the policy to be driven by an identified problem rather tha= n by the pace of AI development itself.<br><br>Technology changing is a rea= son to review a policy. It=E2=80=99s not, by itself, a reason to replace on= e.</font></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex"> Regards,<br> <br> Riccardo</blockquote></div><div><div class=3D"gmail_default" style=3D""><p = class=3D"gmail-p1" style=3D""><font face=3D"monospace" style=3D"">By the wa= y, I am personally opposed to using AI to generate an entire library or eve= n an entire class. At that point, I think it becomes much harder for the co= ntributor to fully understand, review, and stand behind the code, and it ca= n also raise questions about provenance and licensing that deserve <span ar= ia-invalid=3D"spelling" class=3D"LI ng" style=3D"border-style:none;backgrou= nd:none">depper</span> scrutiny. I simply think our existing policy strikes= the right balance by requiring disclosure while continuing to judge submis= sions on their quality, legality, and maintainability.</font></p></div></di= v><div><div class=3D"gmail_default" style=3D"font-family:monospace,monospac= e">Yours, GC</div></div><span class=3D"gmail_signature_prefix">-- </span><b= r><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"l= tr"><div><div dir=3D"ltr"><font face=3D"monospace">Gregory Casamento<br>GNU= step 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.b= logspot.com</a><br></font></div></div><div dir=3D"ltr"><font color=3D"#8888= 88" face=3D"monospace"><a href=3D"https://www.openhub.net/languages/objecti= ve_c" style=3D"color:rgb(17,85,204)" target=3D"_blank">https://www.openhub.= net/languages/objective_c</a></font></div></div></div></div></div> --0000000000009c524e06565a2422--