The firmware-nonfree source package has files under many different
licenses, so there is no catch-all '*' pattern in debian/copyright.

As a result, lintian complains:

W: firmware-nonfree source: file-without-copyright-information Apache-2 [debian/copyright]
[...]
W: firmware-nonfree source: file-without-copyright-information GPL-2 [debian/copyright]
W: firmware-nonfree source: file-without-copyright-information GPL-3 [debian/copyright]
W: firmware-nonfree source: file-without-copyright-information LICENCE.Abilis [debian/copyright]
W: firmware-nonfree source: file-without-copyright-information LICENCE.IntcSST2 [debian/copyright]
W: firmware-nonfree source: file-without-copyright-information LICENCE.Marvell [debian/copyright]
[...]
W: firmware-nonfree source: file-without-copyright-information MIT [debian/copyright]

and so on.

The GNU licenses do include an explicit meta-license for verbatim
copying.  However most license texts do not have this.  Despite the
lack of that explicit meta-license, we are clearly intended and
(usually) required to copy them along with the works they apply to.

The copyright format does not explain how such license text files
should be documented.  Unless they are public domain, which I don't
think is correct, the paragraph listing these files is required to
include or refer to a (meta-)license text.  But there is none that I
can point to.

Ben.

Hello,

I think Lintian is just wrong to be warning about d/copyright.

We don't apply DFSG requirements to license text itself, when including
that license text purely because it's the license of some other thing we
are actually interested in including.

So, if we had a hypothetical collection of interesting licenses, that we
were shipping for their own sakes and not for the sake of documenting
the license terms of some other thing, that would be different; perhaps
that collection would have to go in non-free if they didn't permit
modification.

But that's not what d/copyright is.  So I think the answer to how such
license text files should be documented is that they shouldn't be.

As the saying goes, "the copyright format doesn't require specifying
anything that is not required by the common d/copyright requirements".
We just always ignored the licenses for the license texts, including the
fact that they may be non-free.

patterns, thus removing the file-without-copyright-information tag?

Hello,

I think d/copyright should get an exception.

Ah.
It's not warning about the "debian/copyright" file.
"Apache-2" is the file name it's warning about, "debian/copyright" is I
guess the place where it was expecting to find the info.

to debian/copyright:

Files:
  Apache-2
  GPL-2
  ...
Copyright: various
License: license-text
 These are the licence texts themselves.

Normally, these licenses are captured by the Files: * catch-all, so
this doesn't usually appear.  I have no idea who holds the copyright
to the licenses themselves and what the License on the license is....

Best wishes,

   Julian

to debian/copyright:

Files:
  Apache-2
  GPL-2
  ...
Copyright: various
License: license-text
 These are the licence texts themselves.

Normally, these licenses are captured by the Files: * catch-all, so
this doesn't usually appear.  I have no idea who holds the copyright
to the licenses themselves and what the License on the license is....

Best wishes,

   Julian

Strictly speaking, this defeats the purpose of the DEP5 format and also
makes it clear that the Policy is not followed.

Yet the Policy 2.3 requires you to know and specify this.
We just normally ignore this.

Julian Gilbey <julian@d-and-j.net> writes:

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?

On Fri, 2025-08-15 at 10:20 -0700, Russ Allbery wrote:
[...]

Exactly.

[...]

I think copyright/license information is precisely the special case that
does merit special treatment in debian/copyright.

I've gone with overrides for now, but I would prefer to have a proper
way to document these files.

Ben.

Hello,

Yes, this would be better.

Hi!

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

Hi,

Agreed.
Copyright field and a License field with the license explicitly given.
So the current tools would presumably not be happy with:

Files:
 GPL-2
 GPL-3
License: license-text

but would need to see the elaborated version I suggested about.  A
copyright-format 1.1 could permit this exception, but I'm dubious
whether it's currently worth updating the copyright-format version for
this when almost no packages do it.  Even though separating out the
license text file is the right thing to do for all packages that
include it within the package (presumably the vast majority of source
packages), almost no-one currently does so.

Best wishes,

   Julian

Hi everyone

I'm not sure whether one has to interpret the current Policy section 2.3
as requiring to include copyright information _about copyright
information_ itself (or for those files to be DFSG-compliant for that
matter.)

If that is not the case, then what Sean proposes

is the right way to proceed, IMHO. In the FOSS world, this is not
without precedent, as e.g. the Free Software Foundation Europe backed
[REUSE spec is very clear about license files themselves not being
covered by the spec][1].

[1]: https://reuse.software/spec-3.3/#covered-and-ignored-files

However, there are other files in addition to licenses themselves, which
do not need copyright information, IMHO: e.g., REUSE.toml or .license
files as described by the REUSE spec. I.e., files whose sole purpose is
the conveyance of licensing/copyright information.

If there is consensus on **not** requiring copyright information for all
files which are included in the source/binary package which supply
exactly this type of information, the question becomes how to deal with
Lintian recognizing what those files are exactly. Maybe have a fourth
stanza type in d/copyright which is a list of patterns/paths identifying
files license/copyright information rather than trying to make this
information fit the existing File stanza?

@Guillem: Which tools have a hard requirement on d/copyright covering
*all* files in the package?

Best,

Alex <alex@puer-robustus.eu> writes:

We have never included licensing information for the license files
themselves, nor have we ever treated them as subject to the DFSG. If we
did, we would have to remove all GPL software from the distribution since
the text of the GPL is not DFSG-free, we could not distribute it under
DFSG rules, and therefore we couldn't distribute GPL-covered software
since we couldn't provide a copy of the license.

Maybe we should write this exception for license texts somewhere formally.
I can't imagine it ever changing.

I'm not familiar with the contents of those files. Insofar as they contain
license text, I think this is a variation of the same problem that
probably has the same solution. If they are just statements about the
copyright holders and names of licenses that are applicable, they're
probably not even copyrightable (mere recitations of facts are not
creative), but in general could probably be assumed to be under the same
license as the rest of the package, like we do with other documentation
files, unless there's some statement to the contrary.

I'm not sure d/copyright is the best place to put this (some new file in
debian/source may be more appropriate), but sure.

a response to which Ben pointed me to this bug.

[1]: https://lists.debian.org/debian-devel/2026/05/msg00168.html

In short: I think - maybe wrongly - that we inadvertantly do make claims
about the licensing information of license files with stanzas like

File: *
Copyright: Some Author <someauthor@example.com>
License: GPL3

whereby the GPL-3.0 license itself is included in the package as
LICENSE, for example.

Me neither. I think it would be good to make this exception explicit in
the policy but also carve out some handling in d/copyright, or at least
not "force" per-package Lintian overrides onto maintainers for this
specific exception handling.

They are simply statements about copyright, not new
licenses. Non-copyrightability of these files is another argument why I
think there should be no expectation (e.g. via Lintian) to have to
assign them any copyright information in the first place.

Alex <alex@puer-robustus.eu> writes:

I understand, but that's just not how * has ever been interpreted. I do
see the argument for spelling that out explicitly, and we should probably
do that. But people should not, IMO, change their behavior in how they
write debian/copyright files. It would be a lot of churn for no real
improvement. We should just say that "File: *" doesn't make any claims
about license texts themselves.

If Lintian is saying that you should describe the licensing information of
the license texts themselves, I agree this is a bug. I believe you should
ignore them completely when writing debian/copyright files (except, of
course, as source material for understanding the licenses of *other*
files).
Lintian that I've never seen, but perhaps it was a recent change?

I would just use a File: * stanza with the general package license and let
it cover such files and not give it a second thought. It is not worth your
time and energy, or the time and energy of someone reading
debian/copyright, to worry about whether those files are copyrightable or
not.

This might be an artifact of spdx2debian not (always or by default or
never; would have to investigate) generating a catch-all Files: *
stanza. If a project is fully SPDX/REUSE compliant, spdx2debian can
(theoretically) generate an exhaustive and correct d/copyright for all
non-licensing related files without resorting to
catch-all-but-not-really-all blocks. This might make d/copyright files
less readable but more accurate/technically correct.

Hello,
upstream maintainer of "spdx2debian" here. Please note that I am not a
DM and don't have much experience in Debian packaging.

I often asked myself if someone at Debian ever checked that behavior
with a lawyer.
It is IMHO not OK to add a default license/copyright to every file that
is not covered by something else.
You can not guarantee that upstream add some new files and the DM is not
aware of them. But those
files then will be covered by the * stanza. This results in kind of
illegal situations.

Correct. "spdx2debian" works on 100%-spdx-compliant projects only.
If "reuse lint" is not satisfied so "spdx2debian" also won't be.

As I stated on debian-devel I think the real solution should made on the
level of "reuse-tools" and not my tool or Debian.

Regards,
Christian

Mmm, it is part of the Debian package maintainer's job to review all
changes in a new upstream version. At the very least, it is *very*
important for the Debian package maintainer to review any copyright or
license changes, it is *very* important to also check for any breaking
functionality changes, it is *very* important to also check for any
new dependencies needed... so, in general, examining the changes between
the old and the new upstream version is quite important. Even when it is
not practical to examine each and every changed line, such as with
big projects that do not release new versions very often, it is still
a very, very, very good idea to at least scan all the changes and see if
anything funny jumps out. I know I have caught newly-introduced bugs
this way :) (of course, I have also missed newly-introduced bugs, but
that is a completely different question)

G'luck,
Peter

On Sun, 17 May 2026 11:53:29 +0000 c.buhtz@posteo.jp wrote:> Hello,
Yes, the members of the new dfsg-team are aware of that problems. They also
discuss it with a lawyer.
This issue is well-known by the dfsg-team. We check it, too.

Regards

Alex <alex@puer-robustus.eu> writes:
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.

If I were maintaining the tool, which obviously I'm not, I'd add a flag to
specify the upstream catch-all license, generate a Files: * block stating
that license, and then only list the files that are exceptions to the
overall license. I suspect the DFSG review team would also thank you for
that.

Hello Alex,
thank you for your comments.

Am 17.05.2026 17:14 schrieb Russ Allbery:

It is not that easy. A stanza in the d/copyright file is build from a
license plus copyright information.
If two files share the same license but have different copyright
(author) information "spdx2debian" would
create two different stanzas for them.

Regards,
Christian

Hello,

my thoughts about the problems with licenses of license texts:

https://wiki.debian.org/LicenseText

It is still a draft.

Kind regards
Michael (lawyer (Rechtsanwalt (Deutschland)))

c.buhtz@posteo.jp writes:

I would not do that either, again because it undermines readability. Just
collect all the copyright notices for the same license into a single
stanza as is explicitly allowed by section 6.8 of the copyright-format
standard.

Hello Russ,

Am 17.05.2026 19:05 schrieb Russ Allbery:

That is fine. In this case "spdx2debian" is not the appropriate tool for
your
workflow or packages. It does not try to solve or serve everything, only
SPDX/REUSE compliant projects. And when it comes to SPDX it is immanent
in that standard to distinguish authors/copyright the way I described.

 From a perspective as an author I wouldn't like to get my name on a file
which I have not authored.

Again I wonder if section 6.8 was approved by a lawyer anyday?

Hello,

Am 17.05.26 um 20:06 schrieb c.buhtz@posteo.jp:
Use a license which prohibits that.

Regards
Michael

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.

Alex <alex@puer-robustus.eu> writes:

I have mixed feelings about the usefulness of that effort but I'm never
going to tell people not to spend time on something that matters to them
and I'm very glad that better ways of tagging licenses is coming out of
that project.

That information in the sort of granular format that has been described in
this bug does not, in the general case, belong in debian/copyright. That's
where we're disagreeing.

debian/copyright is intended to be a primarily *human-readable* summary of
the licensing of the *installed package* (secondarily the source package
as well, but primarily the *installed package*) for the *users of Debian*,
not for machines. Putting all of this detailed information in
debian/copyright in the way that's been described on this thread runs the
high risk of making the file unusable for its intended purpose. It's
turning it into a detailed license attribution database in a complicated,
verbose, and redundant format that's annoying for humans to understand.

The main purpose of the debian/copyright file is to communicate to *other
humans* what the license of the source and binaries of that package is,
ideally without them having to pour over a complex quasi-database and
perform mental license set mathematics.

Therefore, replicating this sort of detailed machine-readable information
into debian/copyright at this level of granularity is, IMO, a bug in the
Debian package. It may not be a very severe one depending on how much
overhead and obfuscation this generates, but I'm certainly not going to
recommend that anyone use debian/copyright in that fashion, nor am I going
to support any changes to Debian Policy to encourage that.

The copyright-format standard is an attempt at a compromise between
machine readability and human readability, and I think that compromise is
best suited by having an opening Files: * stanza that specifies the main
license that the user cares about for the package, and then, if necessary,
a list of specific exceptions, with as much coalescing of copyright
statements and licenses as possible without misrepresenting the package.

I have no objections to someone looking at ways to generate complex
machine-readable copyright information in Debian, although I would
question how much effort people put into source licensing when *binary*
licensing matters as much or more to most of our users and is a more
complex problem with more real-world risk than the nitpicky details of
specific source files. But again, I am certainly not going to tell people
not to work on things that interest them.

However, I do object to overloading debian/copyright with individual
listings of every file or separate stanzas for every copyright holder.
This is poor packaging, IMO, because it's poor communication to the user.

We have already strayed a little too far towards machine readability at
the cost of human readability, in my opinion, and going farther is not
good for the distribution. If you want to publish detailed
machine-parsable information, I think it would be better to come up with a
new file for that purpose and keep debian/copyright as succinct and to the
point as possible, conveying the information that our users care about
(and the information we're legally required to convey by the licenses).

I'm not really convinced by this, since I think explaining this explicitly
in Debian Policy is sufficient to handle this fairly minor issue. But I
can see the argument for specifying this in debian/copyright *succinctly*.
It only adds a bit more noise.

I am much more alarmed by the descriptions of the debian/copyright files
that some folks seem to want to generate that have turned up in this bug.
to use Files: * and Lintian therefore is complaining about uncovered
files. You can file a bug against Lintian to carve out an exception for
LICENSES/*, and I think that's reasonable, but the real solution for the
Lintian diagnostic is that you should use Files: * with a set of
exceptions because it's a better way of communicating license information
to *humans*.

I don't have a strong objection to this, although I don't like that it's
being used to support a pattern that I think is introducing communication
bugs into Debian, so I'm not super-excited about it either.

I am also dubious, as previously stated, that it belongs in
debian/copyright. I can see the argument, but remember that
copyright-format is *optional*, and many packages in Debian still use a
free-form copyright-format file but may still be interested in the Lintian
configuration aspect of the problem. To me, that argues for using a
separate file in debian/source, but this isn't a strongly-held opinion.

Hello Russ,
thank for your comment.

Am 18.05.2026 02:55 schrieb Russ Allbery:

Thank you for pointing me to this. I did not realized it nor give much
thoughts
on that. I recognized at primarily machine-readble format with the
side-benefit
of being also human readable.

For someone like me, none-DM and Debian-outsider, reading a d/copyright
file
gives the idea that it is intended to me accurate (kind of perfect) in
its details.

I can imagine that. If a laywer needs specific and accurate information
about
licenses and copyright/authorship in such a project, the reuse-tool
itself can be
used. No need to use or rely on a d/copyright file.

Agreed.

I checked the Debian Policy (sections 4.5, 12.5 and 2.3). It be because
of my
non-native English but I couldn't find a clear statement about the
purpose
of that file.

But I remembered that the file format is often refered to as being
"machine-readable". I think this misdirects me about its purpose.

I wonder how to solve this in project like Back In Time. Currently the
d/copyright file is buggy and somehow illegal. Don't ask me about the
"responsible" DM. ;)

The project is 17 years hold and has over the thumb 50-100 different
copyright statements (authors). Even if pack them together in a *
stanza,
would somehow blow-up the d/copyright file.

The question is if copyright/author info should be state in that file?
Or
might it be enough to name only the current maintainer (group) and
point to the fact that the package consist of several parts and dozen of
authors and where to find this detailed information?

I simply don't know.

It would help me, as author of spdx2debian, a lot if Debian could give
me a
clear statement about how to handle copyright/author information,
including
the dos and donts. I might be able to implement that desired behavior in
the tool.

I'll think about it try to improve spdx2debian. For me it is also a
learning
process about the needs of the Debian project and the purposes and use
cases
of that d/copyright file.

Regards,
Christian

It is important to understand what the DEP-5 debian/copyright file is
intending to communicate.

It is *NOT* trying to communicate that all of the *	COPYRIGHT* information in
each stanza applies to all of the files in that stanza.  Rather, it is
communicating that the *LICENSE* listed in the stanza applies to all of the
files in that stanza.

In other words, it communicates the following:

“All of the files in this stanza are released under the listed license(s).  If
you would like to use these files, you must comply with the terms of these
license(s).  Each item in the list of copyright information applies to *one or
more* of the files in this stanza.  If you would like to relicense all of the
files in this stanza under a non-compatible license, you will need to receive
permission from all of enumerated copyright holders.  If you would like to
relicense only some of the files in this stanza under a non-compatile license,
please investigate the headers and associated copyright information for just
those files to determine who holds the copyright for them and can grant you
permission to relicense.”

Hello Soren,

thank you for clearing this for me. You gave me something to think about
it.

Don't get me wrong. I don't believe your or want to argument against
you.

Am 19.05.2026 22:31 schrieb Soren Stoutner:

 From my point of view the format specs for this file do not contain this
information.
It appears to me as a technical document, not a policy. So I don't give
much weight
on it when it says I can sum up (and mix) the copyright statements.

That is nice! You should put that in the wiki or a policy document
somehow.
As an outsider I would like to see this as an official Debian statement
or policy
entry. But from my current understanding of the discussion and knowledge
of the policy this is not the case. I only have some arguments from
individual
persons; very good arguments. But Debian is not one person.

Maybe you have an idea how to improve the policy in this way? Or maybe
the info is just there and I do miss(understand) the section?

Regards,
Christian

This is the current practice of Debian and is generally understood by almost
everyone involved in Debian packaging.  I would applaud any efforts to improve
the documentation to make this easier to understand for outsiders or those new
to Debian packaging.  Feel free to reuse or publish what I have written here
anywhere you think is helpful.

Hello Soren,

thank you for your response.

No this is not the way. I am also not in the position.

You described implicit knowledge which is not transparent and public to
others and/or non-Debians.
I request to make this knowledge public and official in form of a policy
or something similar.

Regards,
Christian

This is already spelled out in https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field

C.

Hello Chris,

thank you for the reply.

Am 28.05.2026 13:55 schrieb Chris Hofstaedtler:

But as I described it is IMHO the wrong location. The document is a
technical reference
describing a format. I would prefer to see it in the official Debian
policy document.

c.buhtz@posteo.jp [28/May 11:59am GMT] wrote:

That document is part of Policy.