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

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".

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.

> 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.

> *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...
>
> *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.
>
> 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.

> 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.

>
> 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.


Regards,

Riccardo