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
