Bug#1111126: Copyright format does not explain how to describe a license text itself

[Guillem Jover <guillem@debian.org>]

Hi!

On Fri, 2025-08-15 at 10:20:29 -0700, Russ Allbery wrote:
> Julian Gilbey <julian@d-and-j.net> writes:
> > You could work around it by adding a list of all these license files
> > to debian/copyright:
> 
> > Files:
> >   Apache-2
> >   GPL-2
> >   ...
> > Copyright: various
> > License: license-text
> >  These are the licence texts themselves.

> I think the point of the bug report is that we should consider adding a
> keyword like "license-text" to the standard to allow explicitly tagging
> such files without having each person come up with their own.
> 
> I agree that this is a false positive in Lintian, but structurally it's a
> difficult false positive to avoid without annoying heuristics. We do
> generally expect debian/copyright to cover all of the source, and while
> that doesn't include license texts, Lintian doesn't have a great way to
> know which files only contain license text and are therefore irrelevant.
> So a way of explicitly tagging those files so that it can ignore them
> seems reasonable to me.
> 
> I'm not sure they should have their own license block, since the whole
> point is that we're ignoring them. Maybe there should be a new field that
> lists ignored files that don't need to be documented in debian/copyright
> for whatever reason? Although I'm not sure this generalizes; I can't
> off-hand think of another case besides license texts.
>
> I suppose that mechanism could be a Lintian override, and that's not a bad
> answer here. Maybe this case is uncommon enough that an override would be
> fine and it's overkill to add a field?

The problem with a lintian-specific solution, is that the information
in debian/copyright is being used by more tools, that can easily trip
over the same problem with unmatched files in the source tree.

So it seems best if this was encoded in debian/copyright, some way or
another.

The proposed license-text (or something alike), has the appeal that it
seems to faithfully represent what is going on, and in addition should
work out of the box (as in no need to modify tooling). It might simply
require adding such pseudo-license-name exception in the spec.

Thanks,
Guillem