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?

jwodder
  • 222
  • 1
  • 10
  • @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 '23 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 https://packages.debian.org/trixie/amd64/hyperfine/download ) – planetmaker Sep 25 '23 at 22:17
  • run the file command on your binary and compare that with the result of my previous comment – planetmaker Sep 25 '23 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 '23 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/...? – planetmaker Sep 25 '23 at 22:34
  • @planetmaker: The command runs fine on my Ubuntu box without installing anything else, so I think the dependency listing is correct. I've haven't asked on an official mailing list yet, but I may do so depending on what answer I get here. – jwodder Sep 25 '23 at 22:38
  • I added the gist of our discussion into your question. Feel free to revert or revise if you think its detrimental. All this said, I'd recommend to contact the maintainers / project owners first instead of discussing a possible oversight elsewhere. Debian is not known for being lenient on copyright violations, especially not willful ones. I'd go elsewhere if the people in charge are unresponsive or unwilling to enter a dialogue – planetmaker Sep 25 '23 at 23:31
  • Have you contacted the maintainers of the project to ask for clarification? It could be that they have an easy explanation. Or it could be that an error occurred which they are likely willing to fix in no time. – Martin_in_AUT Sep 26 '23 at 09:56
  • It does seem like the Debian copyright file is suboptimal here. It accurately describes the source code for that crate, and Debian maintains licensing metadata for all the dependency crates needed for its builds. However Debian doesn't aggregate this info for the resulting binary packages. Perhaps this is intentional, perhaps this is a bug for the Debian Rust team: https://salsa.debian.org/rust-team/ – amon Sep 26 '23 at 15:11
  • The licenses include the obligation to make available the information (license language, copyright/attribution, notices, etc). But there is no obligation to make it easy to read for the recipient of the software. @amon found that all information is there, it is just not easy to find and to separate for each individual binary. But this is no grounds for an official complaint. – Martin_in_AUT Sep 27 '23 at 07:07
  • I pored over the shipping binary of hyperfine quite hard, but try as I might, could not find the copyright statement from indicatif (Copyright (c) 2017 Armin Ronacher <armin.ronacher@active-4.com>), and I'm fairly sure that hyperfine does use the ProgressBar routine from indicatif. So I'm not yet completely convinced that hyperfine, as shipped, is faultless. But I'd love to be convinced - do either of you fancy writing your thoughts up as an answer? – MadHatter Sep 27 '23 at 08:43

1 Answers1

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.

jwodder
  • 222
  • 1
  • 10
  • 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 '23 at 16:03