License violations for dependencies of Rust and Go programs?
I am a concerned citizen who, while looking into prior art for handling
dependency licenses in order to inform some of my own projects, stumbled upon
what appear to be systemic license violations in the Debian repositories
regarding dependencies of statically-linked compiled binary programs (primarily
those written in Rust or Go). I would normally expect Debian to be rather
strict about licensing, yet the packages I've looked at unambiguously violate
what I understand the licenses require, so I'm wondering what I'm missing.
It is my understanding that when an executable program that depends (directly
or indirectly) on libraries licensed under (picking one license here) the MIT
license is compiled into a binary that statically links these libraries, and
this binary is then distributed to third parties, the binary must be
accompanied by the license text & copyright notices for all of the program's
direct & indirect MIT-licensed dependencies. In particular, since applying the
MIT license to a project typically involves placing a copyright line containing
the author's name in the same file as the base license text, this copyright
line must accompany all derivatives of the project, and so compiled,
statically-linked executable programs must be accompanied by the copyright
lines of all MIT-licensed dependencies.
Unfortunately, I've come across some software in the official Debian
repositories that do not seem to properly honor these requirements.
EXAMPLE #1: The program hyperfine (https://github.com/sharkdp/hyperfine),
written in Rust. Rust is a compiled language that usually statically-links
binaries, and so the compiled binaries that Debian distributes contain code
from all of hyperfine's dependencies.
- The webpage for the hyperfine v1.17.0 package in Debian Trixie is
https://packages.debian.org/trixie/hyperfine. Clicking on "Copyright File"
on the right side of the page leads to a debian/copyright file that declares
that the source files and the Debian packaging files are both licensed under
"MIT or Apache-2.0", and the copyright line listed for the source files
credits only the author of hyperfine. (Note that most if not all of
hyperfine's dependencies are written by other authors.) The file also
contains the base text of the MIT license and a reference to where the text
of the Apache 2.0 license can be found.
- Downloading & inspecting a binary .deb file for hyperfine (I picked amd64)
shows that it contains the same "copyright" file and no other copyright
information, though the Debian "control" file does contain an
"X-Cargo-Built-Using" field listing the names & versions of the Debian Rust
packages used to build the .deb. Note that these "built using" packages are
only used at build time and are not listed as runtime dependencies, and so
they are not installed when installing hyperfine from the Debian
repositories. Furthermore, running `ldd` on the hyperfine binary only lists
fundamental C libraries as being dynamically linked, supporting the
conclusion that the Rust dependencies are statically linked into the binary.
- For a specific dependency of hyperfine's whose license I believe is being
violated, consider the direct dependency "indicatif"
(https://github.com/console-rs/indicatif). The "X-Cargo-Built-Using" field
for the binary package I inspected above states that the hyperfine binary was
built with indicatif v0.17.3, the source for which contains the LICENSE file
https://github.com/console-rs/indicatif/blob/0.17.3/LICENSE, which consists
of a copyright line and the text of the MIT license. This copyright line
does not appear in the above-mentioned "copyright" file or anywhere in the
.deb package.
EXAMPLE #2: The program gh (https://github.com/cli/cli), written in Go. Go is
a compiled language that usually statically-links binaries, and so the compiled
binaries that Debian distributes contain code from all of gh's dependencies.
- The webpage for the gh v2.27.0 package in Debian Trixie is
https://packages.debian.org/trixie/gh. Clicking on "Copyright File" on the
right side of the page leads to a debian/copyright file that declares that
the source files and the Debian packaging files are both licensed under the
Expat license (another name for the MIT license), and the copyright line
listed for the source files credits only the author of gh. License
information is also given for several third-party dependencies that are
included in the Debian source package in order to handle some dependency
versioning issues. No information is given on the dependencies not bundled
in the source package (of which there are many).
- Downloading & inspecting a binary .deb file for gh (I picked amd64) shows
that it contains the same "copyright" file and no other copyright
information, though the Debian "control" file does contain a
"Static-Built-Using" field listing the names & versions of the Debian Go
packages used to build the .deb. Note that these "built using" packages are
only used at build time and are not listed as runtime dependencies, and so
they are not installed when installing gh from the Debian repositories.
Furthermore, running `ldd` on the gh binary only lists fundamental C
libraries as being dynamically linked, supporting the conclusion that the Go
dependencies are statically linked into the binary.
- For a specific dependency of gh's whose license I believe is being violated,
consider the direct dependency "heredoc"
(https://github.com/MakeNowJust/heredoc). The "Static-Built-Using" field for
the binary package I inspected above states that the gh binary was built with
heredoc v1.0.0, the source for which contains the LICENSE file
https://github.com/makenowjust/heredoc/blob/v1.0.0/LICENSE, which consists of
a copyright line and the text of the MIT license. This copyright line does
not appear in the above-mentioned "copyright" file or anywhere in the .deb
package.
Other packages I looked at that had similar licensing issues:
- age
- bat (In addition to the type of problem discussed above, the source code for
bat has an Apache 2.0 `NOTICE` file, yet this is not included in the .deb
package.)
- dfrs
- exa
- reposurgeon
- restic
- ripgrep
- tty-share
I suspect that this problem applies to all programs written in Go or Rust that
Debian distributes. Is Debian handling dependency licenses for these packages
incorrectly, or is there something I'm missing?
-- John Wodder
Reply to: