Re: Draft permissive ballot option (was: GR: Ban LLM contributions from Debian)

Lucas Nussbaum <[email protected]> Mon, 27 Jul 2026 08:14:53 +0200
Newsgroups	gmane.linux.debian.devel.vote
Message-ID	<[email protected]>
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 (application/pgp-signature, 833 B)