After some consideration and a brief discussion on #guix, I have decided to write a long-form response, to try to express my views and to try and understand your views. We seem to already agree on some/much of the background, yet we come to vastly different conclusions, thus I hope to find clarity on what brought about this difference, and what would need to change for you to accept a future successor of GCD008
I apologize for my long-winded response, there's just a lot to respond to Gabriel Wicki <[email protected]> writes: > While this document is arguably the best we were able to compile within > the given timeframe, I just don't think it's good enough. I found my > way into the Guix project because I felt this was the place where we did > things the right, and not the easy or the fast way. While I agree with the general sentiment, I don't see any realistic way this GCD process could have (realistically) gone any better, nor do I think that a do-over will yield any improvement (heck, I think it would likely be worse). I know that you think otherwise, but I don't quite understand *why* > My main issues are > summarized as follows, longer explanations can be found further below: I will rearrange your message such that summarized issues are next to the longer explanations in my response: > 1. From the project perspective: Discussions continued way into the > deliberation period: the proposal could use some more time to (at least) > smooth the rough edges. > > 1. Discussions never really calmed down. The proposal was altered until > the very last moment. Multiple people asked to withdraw to have more > time. While I don't think any one of these are absolute thresholds to > disapprove of a GCD, I think they are good indications that more time is > needed. Do you think that a longer discussion period would have benefitted this GCD? I am personally quite strongly convinced that the continued discussion was primarily a result of the contentious nature of the subject, rather than of any flaw in the consensus-building process. Heck, I think that the only thing that *could* make discussion calm down would be a baseline decision to work from > 2. Consent-wise: Time-pressure and an overwhelming amount of FUD grossly > contradict my understanding of consent. > > 2. I just don't buy the "if we don't regulate it now it will be too late > and Guix is doomed forever" argument. This feels like fear-mongering > and should not find its way into consent-finding processes. I find the accusations of fearmongering to be rather divisive and harmful to the consensus-building process. People voiced their concerns. While you or I may not agree with all of the concerns voiced or with their stated severity, that does not mean that these people were manipulatively spreading fear to influence the GCD process. Accusations of fearmongering make it nearly impossible to build consensus, as such accusations imply that people's concerns and views ought to be dismissed off the bat, rather than be taken seriously, incorporated, such that a result that everyone can live with can be found. > Please excuse the probably historically inaccurate and by terminology > xenophobic comparison (damn my western/european upbringing!), but if > the Barbarians were to invade our realms and we fear they set our > village(s) on fire, I can't imagine us sitting down for a multi-month > process to figure out with what solutions most people are most > comfortable with. I, as a mere community member, don't have a way to do anything other than partake in this multi-month process. An inability to address a problem quickly does not preclude the urgency and severity of said problem. As an unrelated example, addressing climate change is of existential importance for our societies. The fact that most people who are deeply concerned about climate change employ long-term civic and political tactics rather than resorting to ecoterrorism does not serve to dismiss the urgency of climate change. Returning to the GCD, in fact, there is already a de-facto moratorium on LLM-generated content, but that situation is (in my opinion) inadequate in the long run (and insufficient even in the short run). That is why I personally have a strong inclination to pass this GCD (or a successor) as soon as possible. > If the fear were real, I guess the adequate, temporary solution would > have been to enact a moratorium until legal questions are > satisfactorily answered. Legal clarity will not be achieved for years and years to come, as a plethora of legal questions need to still be resolved in a multitude of different jurisdictions. I would not be surprised if some open questions surrounding LLM would simply remain open indefinitely, or if some jurisdictions would never converge towards consistently applicable maxims and instead judge IP-questions relating to LLMs on a primarily case-by-case basis. Thus, waiting for legal questions to be answered is (in my opinion) not a workable solution. Furthermore, even if there were no legal concerns, I (and I presume many others), would still support banning LLM contributions > We do have the tools (consent in each and every PR) to black any > change that could potentially hurt the project. I do not think this is a workable solution, since it formally would require individual committers to reject all individual LLM-based contributions on their own behalf, rather than on the behalf of the project. In such a situation, it is very likely that some LLM-based contributions will slip through (which would be rather annoying to deal with after the fact), and the likelihood of something slipping through increases as the situation continues. This is a stopgap measure at best, and even a temporary project-wide moratorium (decided on behalf of the project rather than individual committers) would be much more workable than continuous PR-rejections by individual committers. And in my opinion, the policies in GCD008 would be in the long-term be significantly more useful than any temporary moratorium could be. Furthermore, without a project-wide commitment to not use LLMs (or to at least denote LLM-generated code as such) it is impossible for committers to consistently reject said code, since there is no reliable way to identify LLM-generated contributions. > 3. From a community perspective: I don't think it is appropriate to > craft contribution guidelines as a by-product of the LLM discussion. > > 3. I find it highly questionable that the first time we should introduce > contribution guidelines is to tell people not to use the wrong tools. > We are a project by people, for people, so contribution guidelines > should be rooted on that fact, and not upon (potentially questionable) > tooling choices. While I understand this sentiment, in my opinion the right conclusion would be "we should've drafted contribution guidelines a long time ago and should work towards extending the LLM-guidelines ASAP", not "let's not have contribution guidelines about LLMs until broader contribution guidelines have been added". To me this feels like throwing the baby out with the bathwater. Heck, most of your concerns to me seem like you're throwing the baby out with the bathwater > 4. Quality of the document: It is still rather unclear in a few areas. > > 4. The term genAI is not (properly) defined. Are we talking about > proprietary SaaS (which AFAICT is clearly regulated FSDG-wise: we, as a > project, can and will neither use nor advocate)? > > Do we include everything in the future that can be labeled genAI? Is > this "just" about large-language models or are we including other "AI" > technologies that can output code? Are "coding assistants" (like the > ones currently baked into VS Code and the like by default) meant as > well, or are we just talking about `prompt-to-code' tools? I don't see the definitional murkiness that you describe, nor do I think it is useful to try to make such a definition fully watertight and futureproof. I don't know whether definitional issues will come up in the future, nor do I know what issues /could/ come up. However, if any issues *do* come up, we will then be way better equipped to deal with them than we are now, as we will know what we are dealing with. In such cases, minor adjustments/clarifications to the policies proposed by GCD008 could be made through a simple PR. Thus, I personally think that accepting GCD008 would have greatly improved the situation, since (in my opinion) it is a huge step in the right direction. > What exactly is the ruling in GCD008 with translations? > > Also, formulations like: >> through any other communication deemed appropriate > only postpone adequate measures to undefined people in the unspecified > future. No, they leave flexibility so that future guix can address the details in whichever way they see fit, without needing to go through a GCD process. > 5. Technically: The (please excuse the potentially wrong label) > "Luddite" angle ("these tools hurt real craftspersonship") seems to be > historically wrong, in a way that is ignorant in how progress works in > the tech world. This is just your opinion, rather than a matter of historical fact. A brief aside on the luddites: The luddites made the observation that replacing hand looms in the control of individual weaving families with power looms in the hands of capitalists would gravely worsen their lives. Therefore, they protested against such a replacement by any means available to them. However, their movement was squashed, and as a result they (by and large) now had to choose between starving and working in large, dangerous, polluting factories. The result was that many workers (and many children) were forced to work in such factories, many of which were injured, maimed, or killed in the course of their work. Furthermore, the polution caused by the automatisation of textile production poisoned both nature and people alike. You clearly have a strong vision of how "progress works in the tech world", but we are decidely not part of the corporate "tech world", nor is the "tech world" at large a monolith. Even if we presume that there is some grand technological progression throughout history, I don't see how that would affect the choices we should make in this situation. Furthermore, calling people "ignorant" is another of those thought-terminating clichés (akin to calling people fearmongerers) that in my opinion gravely harms the consensus-building process. This is a matter of differing opinions and approaching this as "other people need to be educated and once they have all the facts they will clearly agree with me" makes it nearly impossible to build consensus. > 5. The "Luddite" angle reminds me of how people have probably argued > back in the 80ies, when general purpose C compilers took away the jobs > of the crafty assembly programmers. With—I guess—mostly similar > arguments. And while it is still true that *real, fast code*, which > people understand and can translate to what the machine actually does, > is written in assembler¹ it is without doubt that we are generally happy > not having to write code at instruction level. I don't see the use in talking about how people "probably" argued in the 80s, without any factual or experiential reports and takeaways from people who partook in such discussions. > The history of our Free Software movement has shown how we roll, again > and again: Tools get invented and when they prove useful the technology > providing the tools gets liberated (by us, the movement). This is how > GCC came to dominate and extinguish many other compilers, how GNU+Linux > distros replaced (almost) all the Unices, how ... you get the idea. This has happened many times, yes, but it does not happen universally - e.g., there is no liberatory way to use DRM or mass surveillance technology. Even if we assume that it would eventually happen for some technology, that does not mean that we need to embrace, accept, or tolerate its current form. > Without adequately defining *what exactly* we are banning or > restricting, thus by accepting this GCD, we burden ourselves to > another one of these absolutely nerve-wrecking processes. Doesn't rejecting this GCD also burden ourselves to another one of these absolutely nerve-wrecking processes? I personally think that a theoretical future GCD to do minor amendments to the policies in GCD008 would have been a *lot* less contentious than a do-over of GCD008 (which is what we need now), but that is just my personal view. > I know this was an especially long and hard process that consumed an > unbelievable amount of resources. I hope we can circumvent the waste of > many of these resources in the future, for I am convinced that we could > use them more wisely and sustainably. I hope we can do better in the future, perhaps with more structured discussion ("one thread per subject") or with more active moderation of the discussion. I do not, however, think that any such a change would have affected the result of the consensus-building process at large. > I am convinced we will find satisfying solutions for all the different > aspects that have flown into this discussion and GCD. > > But I fear that the premature acceptance of GCDs like GCD008 can > sustainably choke-hold our beloved project, driven by a level of FUD and > time pressure I am convinced will hurt our mission sustainably. I have > a hard time consolidating this with my ideas of consent-driven > collective project management. I still don't quite understand the long-term harm you think GCD008 would have caused, but seeing as you clearly think it would have caused such harm, I respect that you felt the need to disapprove of the proposal. > That being said, the amount of social pressure to disapprove of such a > long and hard discussion is almost unbearable. I can imagine others > preferring not to expose themselves against what could be perceived as > an overwhelming consensus of a vast majority of GNU Guix. I don't know > if I am the only one opposing, but the amount of exposure with the > potential attack-surface ("we had such a great consent except for this > one turd in the punchbowl") is highly problematic for consent-finding > processes. Voicing disapproval should be encouraged, otherwise we will > never be able to truly find the best solutions for all of us, and slowly > lose valuable participants, that prefer to remain silent than exposing > themselves, one discussion at a time. I think such arguments are useless and I think it is harmful to reject a GCD based on the idea that others might also disagree but might not dare to do so publicly. GCD's have been rejected before, with several disapprovals rather than just one, and people have voiced strong disagreement with (versions of) GCD008 throughout the process. Furthermore, I think that seeing many people want and some people accept a specific GCD *should* be a very strong reason to consider whether you could, even disgruntledly, live with it. This societal "pressure" is, in my opinion, necessary in order to form consensus on contentious subjects. > The way I learned it, consensus is when you can enthusiastically agree, > not agreeing because you have been worn down over months, unable to cope > with the volume of input or paralyzed by fear. No, consensus is when everyone finds the proposed solution tolerable. This is precisely what "I accept" is for. In matters of personal intimacy only enthusiastic consent "counts", but definitionally consent does not imply entusiastic agreement. In the context of GCD deliberation enthusiastic agreement is explicitly not required, and a lack thereof should not be sufficient to bring someone to disapprove of a proposal I hope my response will help elucidate the differences of opinion and can thus ultimately help bring about consensus, Kind regards, pinoaffe
