Bug#1111126: Policy change and technical adjustments

Alex <[email protected]> Sun, 17 May 2026 23:19:39 +0200
Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<87a4txwx78.fsf__42901.5927294799$1779052888$gmane$org@t400deb>
>> This might be an artifact of spdx2debian not (always or by default or
>> never; would have to investigate) generating a catch-all Files: *
>> stanza.
>
> Ah, yes, okay. I think this is just a bad idea and would probably not use
> a tool that did that. Not because it's technically incorrect, but because
> I think it's a poor way to communicate the license and the primary
> audience for license information is humans. And, also, because I think it
> inaccurately represents upstream's intentions in many cases.
>
> The vast, vast majority of free software packages are released under a
> catch-all license with (possibly) some exceptions. This is the upstream
> intent, usually pretty clearly documented by upstream using other metadata
> (the license key in pyproject.toml, for instance, or the equivalent in
> Perl Makefile.PL). One point of Files: * is to echo upstream's licensing
> so that we're communicating the same license that upstream is stating.
> Another point is to avoid irritatingly exhaustive lists of files that
> don't themselves convey meaningful information.
>
> I think avoiding Files: * runs the risk of prioritizing rigor and
> precision about something that is not, in reality, rigorous and precise
> over clear communication, and prioritizing machine readability over human
> readability.

So I think we're agreeing on many points, Russ, but talking past each
other in some aspects. REUSE-compliant projects go to great lengths
maintaining detailed, machine- and human-readable information about the
copyright of directories, files and even snippets in files in their
project. They are very different from projects which ship a single
LICENSE file. **Not** taking that effort seriously, would be a lapse on
Debian's part, IMO.

Now, to tie this back to the original problem of the bug and away from
the spdx2debian tool: REUSE requires projects to put all LICENSES it
uses into a LICENSES/ directory at the root project level (see e.g. [the
reuse tool itself][1]). And just like the case Ben encountered, there is
no really accurate way to cover this directory in d/copyright properly:

- Files: * or Files: LICENSES/* would be misleading as discussed:

  - While we can explicitly say that Files: * does not apply to
    LICENSES, this discussion shows that one can easily be lead think it
    does. A Files: LICENSES/* stanza would be even more inviting to the
    latter interpretation.
    
  - Files: * doesn't really make sense for multi-licensed projects like
    Ben described or multi-licensed REUSE projects as it begs the
    question which license one should choose for the catch-all
    stanza. In case of REUSE-compliance of upstream the situation is
    even worse because a Files: * stanza is neither necessary, nor
    judging from upstream's work on maintaining reuse compliance,
    desired.

- Silencing Lintian to stop complaining about uncovered LICENSE files,
  or as I pointed out, other copyright information conveying files, on a
  per-project basis is also an inelegant way forward.

[1]: https://salsa.debian.org/debian/reuse/-/tree/debian/latest/LICENSES?ref_type=heads

Which is why I still think that introducing a fourth type of stanza into
d/copyright, which allows making explicit which files d/copyright is
**not** making a copyright claim about, would be a workable solution. It
is

a) backwards compatible,
b) completely optional for the majority of single licensed packages in
   Debian,
c) flexible enough to accomodate Ben's multi-license use
   case or REUSE-compliant projects, and
d) probably easily consumed by Lintian so that it can be extended to
   stop throwing warnings which maintainers have to silence.

I'd be interested to hear counter-arguments to this suggestion. I think
Guillem might have the strongest one, when he claims that (some?)
downstream tools rely on _every_ file to be covered by d/copyright. It
would also be another thing the DFSG team would have to check in their
reviews, though I think these "ignore-lists" would be fairly short.
signature.asc (application/pgp-signature, 865 B)