Riccardo, Please see the response below...
On Sat, Jul 11, 2026 at 8:43 AM Riccardo Mottola <[email protected]> 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’t 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. 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’t changed. Calling the policy “soft” implies that a stricter policy would produce better outcomes, but I haven’t 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’t think it is a good direction for GNUstep. 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. “AI Free” defines the project by the 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’t 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’t think those are equivalent cases. It's important to remember 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’t *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’s 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 “AI use.” 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’d 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’m not convinced AI use falls into the same category. If the contributor has the legal right to contribute the code, complies with our disclosure policy, and the patch satisfies our technical standards, then I don’t see what additional risk is addressed by treating AI-assisted code differently. So I think the question then becomes: what project risk does an “AI-free” 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. “AI-free” is different. It is a statement about the tools contributors used while creating the software. Once the code is submitted, reviewed, accepted, and maintained, that attribute isn’t reflected in the software itself. I’m not opposed to projects choosing to make that part of their identity. I simply don’t think it aligns with GNUstep’s long-standing philosophy 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’s 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’t 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’s a much narrower proposal, and I appreciate that you’re exploring ideas rather than presenting a finished policy. I still have reservations, though. My concern isn’t primarily whether the boundary is “GNUstep core” or the entire ecosystem—it’s whether the criterion is one we want to govern at all. Historically we’ve accepted 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 criteria tied directly to the software. Once we start distinguishing between “human-written”, “AI-assisted”, “AI-generated”, “vibe-coded”, etc., we’re no longer evaluating the contribution itself—we’re evaluating the contributor’s workflow. I think those boundaries are becoming increasingly difficult to define consistently, and I worry we’ll 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’s the right basis on which to decide 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’t yet seen is a compelling project-specific reason to regulate contributors’ choice of development tools beyond those existing requirements. If that changes—if there’s a concrete legal, technical, or maintenance issue that our current policy fails to address—then I’m open to discussing changes. But I’d want the policy to be driven by an identified problem rather than by the pace of AI development itself. Technology changing is a reason to review a policy. It’s not, by itself, 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 -- Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.openhub.net/languages/objective_c
