General Resolution: LLM usage in Debian
12 points by boramalper
12 points by boramalper
LLM output has very unclear legal status: ...
Whether or not this is true, I think it is easy to agree that it isn't absolutely clear. Which is why I've been surprised it has taken this long for Debian to move in this direction based on this rationale alone:
Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in Debian; LLM output should not have a special exception to this.
Beyond being pro- or anti-LLM, a policy like this is pro-packaging because it removes the burden from every packager to determine the copyright/licensing status of LLM code. Even if it proves too expensive in the end, in the meantime it gives everyone an easy rule to follow.
I found this interesting: quoting "Proposal A" (emphasis mine):
6. Works Created through the use of Large Language Models (LLMs)We will not allow direct contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools. Direct contributions are defined as packaging, native Debian software like lintian, documentation and translations written by Debian contributors, and official Debian web resources, etc. Other categories such as upstream projects written with LLM assistance may be included at a later date. This ensures that Debian remains a stable, trusted, and reliable operating system, and protects the interests of the Debian volunteers who make it possible.
As far as I know there are zero distros so far which have already enacted policies around compromised upstreams. I would imagine part of it is because it's hard enough to get consensus around packaging itself, and part of it is that the work needed to track compromised upstreams is enormous; far too big for any one distro to manage. I think for this to happen we'd need a cross-distro effort to coordinate tracking information.
Given the compromised state of the kernel, I'm not optimistic that we'll see a distro that will do the needful. I think the best we can hope for is getting LLM status tracked in package manager metadata, and at best a kind of "surgeon general's warning" similar to the way debian-security-support tracks packages which are included but without security guarantees that apply to the rest of the system.
Wouldn't this prevent the kernel?
Upstream projects aren't in scope for this resolution:
It does not include: Upstream projects using LLMs for development