(Replying to -vote because that's where the discussion is taking
place. While non-DDs can't vote, the discussion is open to everyone
and all constructive contributions are welcome. At least that's how I understand it.)

Aryan Karamtoth wrote:

I've been reading the proposals listed for the GR about a project-wide LL

M policy so far and they're all great but I feel like they've been focusing
on the extreme end of the discussion -- either ban them completely or allo
w them completely.

I was trying to imagine what a "middle ground" proposal might look like i

f it were to exist and I got a glimpse of it when I saw GCC announcing its
own AI policy [1].

The GCC steering committee has announced that it has accepted an AI cont

ributions policy recommended by >the GCC AI policy working group.

The policy, in part, states that the project will decline any "legally s

ignificant contributions which include LLM->generated content or are derive
d from LLM-generated content". It uses the definition of "legally significa
nt" >from the GNU Project maintainer guidelines, which holds that the thres hold is "around 15 lines of code and/or >text" to qualify as significant fo
r copyright purposes. GCC maintainers may, however, choose to accept legall
y >significant test cases that are generated by an LLM.

The policy does not forbid use of LLMs for research, analysis, bug disco

very and reporting, patch review, etc. as >long as the output is not includ
ed in contributions. The committee says that it expects the policy will evo
lve and >will be revisited periodically.

I feel like a similar proposal (maybe Proposal F) could focus on somethin

g similar:

" Allow LLM usage only for research or understanding purposes but forbid

any of that work from being directly materialised into code or documentatio
n (copy pasting). "

This way we can not only limit the usage of LLMs in the project but also

avoid DFSG compliance issues because the code must be written by humans.

I personally feel like allowing LLM usage directly in the project would o

nly result in more unmaintainable codebases, poor quality packages and a te chnical debt that will be a burden on new contributors as they may not be a ctively interacting with mentors for help. We're already dealing with sever
al occurrences of server downtime because of the clankers and some vibe cod
ed debian packages lying out there in mentors.d.net.

On the other hand, we're way past the point where we can just block the u

sage of LLMs completely because to be honest, despite being an anti-LLM per
son previously (I still am but not very aggressive), I found them to be of some use when dealing with problems where there's a lack of documentation o
r little resources online but when it comes to code, they still do a horrib
le job. We need to focus on maintainability too and LLMs are bad at that.

A good way forward that I personally see is actively discouraging LLM usa

ge but not outright banning it completely and ensuring that the final work
is human written even though there might be some LLM assistance with resear
ch or understanding errors.

I do not have voting rights yet so I just thought I'd raise my point of v

iew about this GR.

[1] https://lwn.net/Articles/1086041/

--
Regards,

Aryan Karamtoth,
Debian Maintainer

It is my understanding that the GCC policy addresses only one concern
about AI, that is, the copyright status of AI-generated code. They
won't incorporate code that someone else might be able to claim
copyright on. That's the whole point of the "legally significant"
thing and that's all they seem to worry about. Other activities are
allowed simply because they don't result directly in adding code to
the GCC codebase, so they are zero-risk from that point of view.

That is of course a valid concern, and possibly the one that could
most directly cause legal liability (in the current legal situation --
it is also possible that future rulings may establish that the output
of AI is never copyrightable, thus voiding the issue).

Other concerns are outside the scope of their policy and not addressed
at all: the reliability and quality of AI-generated contributions, the
negative effect on human ability to understand the codebase, the
burden that a flood of AI-generated patches place on maintainers, the environmental impact of running big LLM models, and so on.

It is ok to adopt the GCC policy *if* you do not think that those
other concerns matter.

Gerardo

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Monday, August 03, 2026 07:14:01 AM Gerardo Ballabio wrote:

(Replying to -vote because that's where the discussion is taking
place. While non-DDs can't vote, the discussion is open to everyone
and all constructive contributions are welcome. At least that's how I understand it.)
Other concerns are outside the scope of their policy and not addressed
at all: the reliability and quality of AI-generated contributions, the negative effect on human ability to understand the codebase, the
burden that a flood of AI-generated patches place on maintainers, the environmental impact of running big LLM models, and so on.

As a non-(code)contributor, from the peanut gallery:
I don't disagree that those are valid concerns, but I would point out that:
* AI work can (and should, imho) be supervised / vetted by a human.
* AI can be asked to explain the codebase (and patches) multiple times if necessary (I mean to dig deeper) so a human can understand and vet the code base and patches
* AI can be asked to improve the documentation (by asking (prompting) multiple times) (Aside: I'm going to experiment with asking for some "literate programming" style documentation in programs I plan to get written -- unlikely they'd get into Debian in any way.)
Environment: yes, that is a big issue, don't plan to discuss my thoughts here.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

For anybody else reading...

*Please* follow up on debian-vote, not to debian-project. Splitting
the discussion across multiple lists doesn't help.

On Mon, Aug 03, 2026 at 09:48:38AM -0400, rhkramer@gmail.com wrote:

On Monday, August 03, 2026 07:14:01 AM Gerardo Ballabio wrote:

(Replying to -vote because that's where the discussion is taking
place. While non-DDs can't vote, the discussion is open to everyone
and all constructive contributions are welcome. At least that's how I
understand it.)

...

--
Steve McIntyre, Cambridge, UK. steve@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)