Re: GR: Ban LLM contributions from Debian

On 29/07/26 10:31 am, Lucas Nussbaum wrote:
> On 28/07/26 at 19:49 +0530, Nilesh Patra wrote:
>> On 28/07/26 3:01 pm, Ian Jackson wrote:
>>> Andrea Pappacoda writes ("Re: GR: Ban LLM contributions from Debian"):
>>>> On Mon Jul 27, 2026 at 6:07 PM -03, Matthias Geiger wrote:
>>>>> Ians' proposal would exactly allow that: Per-team/per-repo decisions 
>>>>> whether LLMs would be allowed in developing it. If e.g. the lintian 
>>>>> team chose to disallow LLMs for all its contributions, that could be 
>>>>> stated in the README etc.
>>>>
>>>> Does it? It allows "Moderators and disciplinary teams" to do so, such as 
>>>> list masters. I don't read it as granting per-repo exeptions.
>>>
>>> Matthias's scenario is indeed covered by paragraph 6 of my proposal:
>>>
>>>   6. Individual projects and maintainers may ban LLM contributions
>>>      completely.  Such bans (including by upstream projects) must be
>>>      respected.
>>>
>>> So lintian can set a stronger policy.
>>>
>>> You're perhaps thinking of 4a.  That is a limited power for moderators
>>> to set weaker policy.
>>>
>>> My proposal does not allow individual projects to weaken the policy,
>>> only strengthen it.  For example, the lintian[1] maintainers aren't
>>> allowed to write an exception into their README so they can reply to
>>> bug reports with LLM output.
>> I was instead looking for the opposite - i.e. allow individual projects
>> to be more permissive. I understand that your current proposal does not
>> allow that.
>>
>> It may be good to have a provision to have individual projects or maintainer
>> teams to have policies of their own around AI, which could be different from
>> what is enforced on all projects in the project at large.
> 
> This does not really work because of human-to-human communications.
> Lintian bugs might end up on the debian-bugs-rc@ mailing list, or be
> read by other maintainers, so they cannot include LLM output under Ian's
> proposal.

We need to draw the line somewhere, I think. There are contrib and non-free
packages as well, but the bug reports of those also would land at a common
place. Non-free packages may not be allowed in all maintainer teams either.

I was thinking of a more pragmatic stance here, i.e. the maintainers of a
particular niche/team could decide what to do about the policy, and others
reviewing that work/working in that team by definition accept the policy.

Thanks,
Nilesh