The d/copyright file only contains the license info of the source package but it
does not contain the license info for each software that is contained in the
binary /usr/bin/lalrpop:

X-Cargo-Built-Using: rust-aho-corasick (= 0.7.10-1), rust-ascii-canvas (=
2.0.0-2), rust-atty (= 0.2.14-2), rust-bit-set (= 0.5.0-1), rust-bit-vec (=
0.5.0-1), rust-block-buffer (= 0.9.0-4), rust-block-padding (= 0.2.1-1),
rust-byteorder (= 1.3.4-1), rust-cfg-if-0.1 (= 0.1.10-2), rust-cfg-if (=
1.0.0-1), rust-cpuid-bool (= 0.1.2-4), rust-diff (= 0.1.12-1), rust-digest (=
0.9.0-1), rust-dirs (= 3.0.1-1), rust-dirs-sys (= 0.3.5-1), rust-docopt (=
1.1.0-1), rust-either (= 1.5.0-1), rust-ena (= 0.14.0-1), rust-fixedbitset (=
0.2.0-1), rust-generic-array (= 0.14.4-1), rust-indexmap (= 1.3.2-1),
rust-itertools (= 0.9.0-1), rust-lalrpop-util (= 0.17.2-1), rust-lazy-static (=
1.4.0-1), rust-libc (= 0.2.80-1), rust-log (= 0.4.11-2), rust-memchr (=
2.3.3-1), rust-new-debug-unreachable (= 1.0.1-1), rust-opaque-debug (= 0.3.0-1),
rust-petgraph (= 0.5.0-1), rust-phf-shared (= 0.8.0-1), rust-precomputed-hash (=
0.1.1-1), rust-regex (= 1.3.7-1), rust-regex-syntax (= 0.6.17-1), rust-serde (=
1.0.106-1), rust-sha2 (= 0.9.2-2), rust-siphasher (= 0.3.1-1), rust-string-cache
(= 0.8.0-1), rust-strsim (= 0.9.3-1), rust-term (= 0.5.2-3), rust-thread-local
(= 1.0.1-1), rust-typenum (= 1.12.0-1), rust-unicode-xid (= 0.2.0-1),
rust-unreachable (= 1.0.0-1), rust-void (= 1.0.2-1), rustc (= 1.48.0+dfsg1-2)

Many of their licenses require copying the license terms to binary
distributions. I do not think that copying each info manually is a good idea but
concatenating the copyright files during build (via debcargo?) might be an option.

I think this is a general problem with Debian's Rust packages that contain
binaries, so maybe you want to get FTP Masters' opinion on this.

The d/copyright file is about the source package not the binary package, you are misinterpreting policy.

In fact there is nowhere in the d/copyright file format to put this information; and it would not be efficient to do so since the information already exists in the d/copyright of those other packages.

Closing the bug report for this reason.

Control: reopen -1
Control: reassign -1 ftp.debian.org

In Policy 12.5, I read "Every package must be accompanied by a verbatim copy of its
distribution license(s) in the file /usr/share/doc/PACKAGE/copyright." There is no
indication that the d/copyright file is about the source package only. In fact quite the
opposite, as in 2.3 (Copyright consideration) there is a distinction between source and
binary distribution.

In my interpretation, the copyright file for one specific package has to fulfill the legal
obligations of its contents' distribution license(s), including binary packages with their
specific obligations. How would a user who does not know about the X-Cargo-Built-Using
shtick know that they are to obtain the copyright files of dozens of other packages (NOT
dependencies) to get the complete distribution license information? I think, Debian
manuals just point to the copyright file for license information.

https://wiki.debian.org/StaticLinking mentions: "Packages can declare they were built
using code from other packages by using the Built-Using header and the Debian archive
keeps around old sources, marking them with the Extra-Source-Only header. Debian Policy
unfortunately says that Built-Using may *only* be used for the purposes of DFSG/license
compliance so tracking static linking must be done using custom headers."

Maybe there is nowhere in the DEP-5 format, which is not mandatory by now. This
inefficiency is why I suggested to contact FTP Master about it. I do not think, there is a
good mechanism for it in Debian right now. Maybe, there should be a similar field to
Built-Using that is not about source retaining but about applicable licenses from other
packages.

Reopening and reassigning to FTP Master to check if they are content with the current
"custom headers" over a complete d/copyright approach. If "custom headers" is enough, I
request to have a complete list of their names at a prominent place to enable users to get
the complete license info for a package.

Bastian Germann:

(Note: the name "DEP-5" refers to when the format was just a proposal, but now it is the "official" format.)

The current mechanism is to look in the d/copyright of the other package. What do you think is bad or not good about it?

Taking a step back for some perspective, I also suggest you might want to spend your own time on other things that are more productive and have more real-world impact. Nobody is going to get sued over this, there is no legal basis for doing so as the license information is already in an easy-to-access place, namely the d/copyright of the other package.

This will be my last message in the thread because I also want to spend my time doing more constructive things.

Ximin

renderdoc. Their licenses do not require a Built-Using. Having vulkan-validationlayers or renderdoc installed does not
give you any hint that glslang-dev's distribution license also applies. If you want to know that you have to look at the
source package.

Some months after I filed the bug, this issue was apparently handled by the Go team with
https://wiki.debian.org/Static-Built-Using

I have just found that by chance and suggest to promote this field via the Policy.