Hi Teo, Simon's draft policy is what inspired and motivated the statement.
I see this exactly as more of a statement and less of a policy. The only "policy" thing in our text is indeed "you need to label/attribute LLM generated content". And we mention that only because it is part of "protecting the no-LLM" side. I believe that the rest of Simon's policy is maybe a worthwhile effort, but is quite separate from the matter of "here's our position on LLM use". Quality standards, workflow expectations, notions of authorship etc. are indeed things that need to be defined separately, whether we ban or allow LLMs. So maybe this is the way forward: users who want to know where the project stands in the "LLM discussion" can read this text. For more specific details on quality requirements, etc. we need a "contribution policy" that lays out requirements on ownership, review expectations and so on. They can certainly link to one another. But my feeling is that we got sidetracked from the essence of our disagreement while descending into the depths of policy specifications. Cheers, Julian On Tue, 2026-07-28 at 21:04 +0100, Teo Camarasu wrote: > Hi Moritz and Julian, > > Are you proposing this as an alternative to Simon's draft policy? > > Cheers, > Teo > > > > On Tue, 28 Jul 2026, at 11:14 AM, Moritz Angermann via ghc-devs > wrote: > > Dear friends, > > > > I've spent the last two days discussing the topic of LLM > > contributions in detail with Julian at length over video. As the > > discussion over the last few weeks have shown that it's very hard > > to find agreement on a common policy, we have tried to outline what > > we consider a statement that covers at least both of our views. > > With Julian and I representing a fairly wide spectrum of the > > positions, we hope that this may provide a statement that many can > > subscribe to. > > > > We have tried to keep it short, and not get distracted by > > specificies of workflows, quality standards, and definitions of > > terms, which seem to distract from the core that we want to > > address. > > > > Respectfully, > > Julian and Moritz > > > > > > ## A shared statement on our environment in the face of LLMs > > > > As human-LLM interaction is becoming more common, we find ourselves > > debating not only our technical goals, but also our understanding > > of open source community and values. > > > > This is why we all agree that we want to participate in an > > environment... > > > > 1. that inspires the exchange of technical ideas and knowledge > > between humans > > 2. that is supportive and accessible to the point that no one > > should feel the need to use LLM in the first place > > 3. that facilitates building trust relationships with one another > > 4. that rewards technical excellence and authenticity > > 5. that demands all interactions to be genuine and respectful > > > > We recognize that using LLMs responsibly is challenging. Not only > > can they be used for abuse[^1][^2], but they may also cause the > > quality of communication and intellectual engagement to > > decline[^3]. > > > > There is an emerging body of scientific literature supporting these > > concerns about negative effects on psychological, cognitive, real- > > world performance, etc. We recommend everyone to familiarize > > themselves with the current state of research. Here are a few links > > for your consideration. > > > > * [How AI Impacts Skill > > Formation](https://arxiv.org/abs/2601.20245) > > * [AI Assistance Reduces Persistence and Hurts Independent > > Performance](https://arxiv.org/abs/2604.04721) > > * [From Future of Work to Future of Workers: Addressing > > Asymptomatic AI Harms for Dignified Human-AI > > Interaction](https://arxiv.org/abs/2601.21920) > > * [AI Competency Erosion: Understanding Expertise > > Decay](https://link.springer.com/chapter/10.1007/978-3-032-11748-9_ > > 5) > > * [Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using > > an AI Assistant for Essay Writing > > Task](https://arxiv.org/abs/2506.08872) > > * [Investigating the Effects of LLM Use on Critical Thinking Under > > Time Constraints: Access Timing and Time > > Availability](https://arxiv.org/abs/2603.08849) > > > > _(This list does not claim to be comprehensive; it is merely meant > > to provide you with an initial stepping stone into the current > > research)._ > > > > Moreover we are especially concerned about their potential negative > > effects on open source communities[^4], human communication and > > collaboration. > > > > We strive to be an inclusive community and judge contributions on > > their merits. This includes the use of LLMs as long as it does not > > disturb our envisioned environment outlined earlier. > > > > We recognize that there are users and contributors of this project > > who would rather not interact with LLM generated content at all. To > > balance the preferences and self-determination of the diverse group > > of contributors, we require that the use of LLMs to generate > > content is clearly attributed as such, failure to do so may result > > in contributions to be rejected. We understand that this may not be > > satisfactory to everyone, since we cannot completely avoid exposure > > to LLM generated content. However, we will neither compromise our > > quality standards, nor allow any disruption of human-human > > interaction by the use of technology. > > > > Examples of inappropriate use are: > > > > - feeding someone's email into an LLM to generate an answer > > - creating automated LLMs written bug reports that a volunteer has > > to work through to determine if it has any value at all > > - generating large patches that take more time to review by the > > project than it took you to create > > > > We want this to be a project of human interaction, of shared > > curiosity and a beacon of engineering excellence. > > > > These are the shared values we stand by today as a project, and > > they may evolve along with our shared experiences and emerging > > scientific evidence over time. > > > > > > Julian Ospald > > Moritz Angermann > > > > -- > > [^1]: https://openai.com/index/disrupting-malicious-ai-uses/ > > [^2]: https://www.infoq.com/news/2026/02/ai-floods-close-projects/ > > [^3]: https://arxiv.org/abs/2506.06166 > > [^4]: https://arxiv.org/abs/2601.15494 > > _______________________________________________ > > ghc-devs mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
