Hi, On 26/07/26 at 17:17 +0200, Marc Haber wrote: > On Sun, Jul 26, 2026 at 09:38:28AM +0200, Stefano Zacchiroli wrote: > > 2) And speaking of Lucas' proposal, in the interest of avoiding > > over-complicated ballots for voters, I'd like you and Lucas to comment > > on how the two relate to each other. In my view, at a very high level, > > they are quite similar. > > I think that Lucas' proposal has a lot more language about guidelines that > could lead to an "editorial changes" effect that I deliberately try to > avoid. I see the numbers 1, 2, and 4 of Lucas proposal having the > possibility of such interpreatation. > > > Lucas' proposal has an additional explicit point about mandatory > > disclosure of AI assistance. Yours doesn't and I'm assuming that's on > > purpose, correct? > > I do not have such a strict stance on the attribution clause, but seeing AI > as just a very powerful tool, why would I want/need to state what tools I > used to create something that I reviewed and tested after its generation. > Noone is currently forced to say "I used a jetbrains closed source IDE to > generate the boilerplate structure of classes foo, bar and baz including the > getter and setter methods". > > > Other than that, Lucas' proposal has more specific > > comments on various aspects/consequences of AI assistance; your doesn't, > > but as a voter I don't see this difference as something that would make > > me strongly favor one option over the other. > > Yes, I did not want that in my ballot options as this levels the fighting > ground for the next rounds. > > > So one possible way forward to simplify the ballot, if you two agree, > > would be to have on the ballot your proposal (which is shorter, KISS) + > > and another option which has identical text + a paragraph about > > mandatory disclosure. > > I would be willing to build a second ballot options that it basically > identical but has one or the other more specific option on it, if Lucas > agrees about that. > > Lucas, I would love hearing your opinion about deliberately being less > specific.
The end goal of this GR process is to define Debian's position on LLMs. It is clear that this is a controversial topic, with Debian contributors spread all over the spectrum. I would really like that the proposal that wins does not cause anyone to feel that they should leave the project, or massively reduce contributing to Debian. (I believe that Proposal A would have that effect.) My proposal B is written with that in mind, trying to make it as acceptable as possible to people who fundamentally disagree with it. I believe than Ian's proposal C is written in the same spirit. Specifically, 1/ I believe that it's important for Debian to state that LLMs raise many concerns (and not just related to copyright). That's what this paragraph is trying to achieve (and I would welcome suggestions to extend it from people against LLMs): > The Debian project recognizes that AI-assisted contributions raise > many concerns, e.g. about the technical quality and maintainability of > such contributions, and their legal status. AI itself also raises > additional concerns, about its impact on society at large, on the IT > industry and on Free Software; about its environmental impact; and the > aggressive or non-compliant practices of AI scrapers. 2/ I believe that a clear set of safeguards is useful to make LLM usage by others less inacceptable for contributors who would prefer to reject LLMs. Specifically, I think that disclosure is important because some contributors might choose to apply different standards to AI-assisted contributions (and that's fine). Now I wonder and worry about this: > I think that Lucas' proposal has a lot more language about guidelines that > could lead to an "editorial changes" effect that I deliberately try to > avoid. I see the numbers 1, 2, and 4 of Lucas proposal having the > possibility of such interpreatation. And I wonder if there's a way to improve Proposal B to address this. But in general, at this point I don't think that we should merge our proposals. Lucas
signature.asc
Description: PGP signature
