4

It is my understanding that when an executable program that depends (directly or indirectly) on libraries licensed under MIT and/or Apache 2.0 is compiled into a statically-linked binary that is then distributed to third parties, the binary must be accompanied by the individual licenses & copyright notices for all of the program's direct & indirect dependencies. (If you can definitively confirm or refute this belief, please consider posting an answer to this question.) However, I've come across some software in the official Debian repositories that does not seem to properly honor these requirements. I'd expect the Debian packagers to get licensing right, so I'm wondering what I'm missing.

Specific example: The program hyperfine, written in Rust. Rust libraries are usually statically-linked, so the compiled binaries that the Debian project distributes contain code from all of hyperfine's dependencies.

  • The webpage for the hyperfine v1.17.0 package in Debian Trixie can be found here. 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 contains the text of the MIT license (separate from the copyright) 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 the amd64 deb) 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). This is supported by the fact that running ldd on the hyperfine binary only lists the glibc libraries as being dynamically linked, and so the other build-time dependencies (i.e., the third-party Rust libraries) are most likely statically linked into the binary.

  • For a specific dependency of hyperfine's whose license I believe is being violated, consider the direct dependency indicatif. The X-Cargo-Built-Using field for the binary package I inspected states that the hyperfine binary was built with indicatif v1.17.3, the source for which contains this LICENSE file, consisting 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 file.

So, is Debian handling dependency licenses for this package and others incorrectly, or is there something I'm missing?

11
  • @planetmaker: I may have worded that part poorly. I know Rust can make dynamically-linked binaries, but the default is static linking, and the binary in question happens to be statically linked.
    – jwodder
    Sep 25, 2023 at 22:16
  • The binary in question is dynamically-linked: hyperfine: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=01dc3bdc2d9335f0141154c10ffc885365f0a9f7, for GNU/Linux 3.2.0, stripped (downloaded from packages.debian.org/trixie/amd64/hyperfine/download ) Sep 25, 2023 at 22:17
  • run the file command on your binary and compare that with the result of my previous comment Sep 25, 2023 at 22:19
  • @planetmaker: There are no other binary files in the .deb, so anything it's linking with has to come from the dependencies, which are just libc6 and libgcc-s1 (and running ldd on the binary just lists fundamental C libraries). Thus, it appears that the Rust third-party library dependencies are still statically linked.
    – jwodder
    Sep 25, 2023 at 22:31
  • Indeed, it makes one wonder. Or the dependencies for the installed package are not properly listed. Did you ask the maintainers or in a debian channel on discord/irc/forums/...? Sep 25, 2023 at 22:34

1 Answer 1

6

I asked about this on the debian-legal mailing list. It is indeed a license violation, but fixing the tooling to automatically bundle dependencies' licenses is a non-trivial undertaking.

The reply from Paul Wise follows:

Your analysis is correct, some extra context for this problem:

The problem you have identified applies to other statically linked languages too, so I have updated the wiki page to link to it.

https://wiki.debian.org/StaticLinking

The problem can be more generally stated as; Debian aggregates the copyright and license of source files we distribute but does not trace the path from source files to compiled files, and therefore does not trace which source files each generated file was created from and as a subset of that problem, does therefore not trace the flow of copyright and license information and does not aggregate that information and does not discover license incompatibilities in the generated files.

This more general problem is very hard to impossible to solve, since it would mean patching every single build toolchain and source package to provide traces of the path from source files to compiled files and then processing those traces to generate copyright info for binary packages.

The specific problem with Rust/Go/etc static linking might be solvable by a new debhelper command that would read the Built-Using and related fields and then append each of them to the DEBIAN/copyright files.

1
  • 1
    Many congratulations (and +1) from me for following this process from source to conclusion - and a damn good piece of spotting on your part. I wasn't quite sure enough of my own ability to understand rust to give an answer, but I was fairly sure that you had a point. Three cheers to you for asking Debian themselves; I'm glad they know about it, and hopefully one day they'll fix it.
    – MadHatter
    Sep 27, 2023 at 16:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.