Hi Simon et al., First of all, I agree with most of what you write. These are good suggestions for improvement.
> Our goal is not to judge what individuals are doing. > Instead, this proposal aims at setting a standard for what we do > collectively within the project. My understanding of this GCD is that it has two messages: - The quoted one: we don't want genAI do harm to our community. - We consider genAI harmful to society at large and want to discourage its use in general, even outside our community. BTW, if you replace "genAI" by "non-free software", you get better understood goals that many projects have adopted long ago. We should be able to exploit the parallels more than we do. The problem with these two goals is that they are formulated as negatives. They don't say what we do want our community and its social environment to become like. Negatively stated goals look defensive and can be seen as a tacit wish for a world without change. That's not going to happen. This is why I like point 5 of the GCD in particular: it sets positive goals that we can work on together. Most of the discussion about this GCD can be summarized as defining how we want to Guix to exist in a world where genAI tools are used by various people for various reasons and various tasks, no matter what we decide. What do we want that coexistence to look like? Something that I see an inevitable is the creation of channels with genAI software and vibe-coded software, much like there are channels for non-free software. Maybe we should embrace this and make it part of the GCD. Something along the lines of "We encourage people to set up distinct communities for working on genAI-related software, maintaining their own channels, and at the same time continue to contribute to Guix itself in accordance with our rules." But then, it will be hard to maintain point 2. Someone who works with coding agents all day will find it hard to abandon them for making a Guix package, and will likely prefer vibe-coding the package and submitting it to a genAI-friendly channel. We could make point 2 less strict and only demand that submissions be human-auditable, no matter how they were developed. The message would then be: we don't care if you use genAI at home, but we don't want your habits to affect our community. > Either the item #2 is clarified, either the section should include these > potential silent assisted-by contributions. What I outline above would imply silencing genAI use. The big advantage is that this is a workable policy. The downside is accepting more genAI use than some are comfortable with. > From an engineering point of view speaking about automation of > configurations, there is not so much difference between autotools and a > statistical text generator. However, there is still a difference, IMHO, > it’s about hackability: it implies autonomous, sovereign, being > inspectable or explainable, etc. Exactly, and that makes for a good criterion for choosing what's good for our community: keep things hackable. What I see as much more difficult is the second message: discouraging genAI use outside of Guix, mostly by refusing to include vibe-coded software. Point 3 of the pledge. Again, I think we should think of this as how to organize coexistence with an outside world that doesn't share our values. Where do we draw the line between acceptable and unacceptable software for inclusion in Guix? Put differently, which packages we want to be in Guix and which ones we prefer to relegate to outside channels? My take on this is likely to be unpopular here: I think that Guix is already too big and diverse in its current state. I'd prefer Guix to concentrate on a minimal core with just the packages necessary for a minimal viable system. For such a core, it would be much easier to be strict about rejecting vibe-coded software. Everything else could be in separate channels, and each of these channels could have its own genAI policies. With today's approach of "the more packages the better", it is hard to draw a line that includes enough package for Guix to remain useful and at the same time excludes enough packages to send a credible anti-genAI message to the outside world. >> acceptable for inclusion in Guix. Should applying this rule lead >> to package removal, the [Deprecation >> >> Policy](https://guix.gnu.org/manual/devel/en/html_node/Deprecation-Policy.html) >> must be followed. > > Well, I’ve not checked, but I’d be interested to know if there is > packages from Bioinformatics that fall into this item #4 and thus > should be deprecated. That's a check that we should do not only for bioinformatics. It's always good to know the consequence of one's decisions before committing to them. Yes, I know, it's a lot of work to check everyone's policies, especially since they are in flux. But each team could try to explore at least the most critical packages in its domain. The ones that have the most dependees. Cheers, Konrad.
