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
