On 2026-11-09 14:02, Bill Allombert wrote:
Lucas [1] posted an example of a LLM review. The review was completly wrong but it was sufficiently plausible that Lucas and most other debian-devel commentors accepted it as valid. Some of them, including Lucas, have years of experience as DD. This failure to spot the blatant errors show that nobody is immune to LLM influence.
"completly wrong" and "blatant errors" dramatically overstates the situation.
The Copyright lines under discussion here do actually exist. The LLM didn't hallucinate them. FWIW, the (AFAIK) deterministic non-LLM `dnq author-check` flags the exact same things. And in any event, I checked myself on forgejo; they exist.
[Quoting reordered for flow.]
[1] https://lists.debian.org/debian-devel/2026/10/msg00290.html https://salsa.debian.org/dfsg-team/dfsg-omp-review/-/work_items/26
The issue that you pointed out is that notices for files that are _only_ part of the build system and/or do _not_ end up in the binary package (e.g. an rpm-related file Copyright SUSE) "need not be included in /usr/share/doc/PACKAGE/copyright" per Policy 2.3.
Such behaviour by an expert human would be considered as a deception attempt and lead to sanction.
Someone pointing out, "There are these copyright lines here that you didn't include in debian/copyright" would absolutely _not_ be considered a "deception attempt and lead to sanction". This hyperbole doesn't help the discussion.
I didn't, off the top of my head, remember this nuance in Policy 2.3. If I had hand-reviewed this, I could have easily said the same thing.
Having re-read Policy 2.3, my personal position remains: while I understand the logic in Policy, I would put those things in debian/copyright anyway, ideally with a `Comment` that they are not ending up in the built package, in a machine-readable format debian/copyright. [1]
After all, we distribute the source tarball too. We require source tarballs to be DFSG free, and repack them when they are not. So it seems weird to say that we would omit source-only things from debian/copyright.
Furthermore, to me it feels like more than _merely_ an omission when we are saying things like "File: *" (or depending on the particular situation, possibly something even more specific) that specifically cover those, in a format intended to be machine-readable and thus pedantically _specific_ and _comprehensive_. It feels more like an _incorrect_ claim once we get into the machine-readable format.
The `Files` paths themselves are all about the _source_ package hierarchy anyway, _not_ what gets installed in binary packages. So there's at least a bit of a disconnect here between Policy 2.3 and the machine-readable copyright format.
Even without the machine-readable copyright nuances, it separately seems wrong to me to exclude the build system on a GPL-ed project. (I realize this one is not GPL, but I'm talking about Policy's position generally.) After all, the GPL requires you to provide the build scripts, so if the build script's copyright was incompatible, that is an _actual_ problem. I think it would entirely proper for the DFSG Team to reject a package in such a scenario (which again, I realize is _not_ the situation here).
But that would be an example demonstrating that Policy sets the floor of what they can enforce, but not necessarily the ceiling. Policy says those things "need not" be in there, which is saying they're not required, not that they are prohibited.
[1] Lest anyone accuse me of post-hoc rationalization, this is exactly what I did in ntpsec:
Files: libjsmn/* Copyright: Serge Zaitsev <[email protected]> Comment: This is currently unused, in favor of the packaged libjsmn-dev. https://github.com/zserge/jsmn # SPDX calls this "MIT". License: Expat -- Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
