Rust Static Binary Licenses / Static Binary Licensing Policy

[jeremiahpslewis]

Much of this topic is already explored in #4088.

Summary

Yggdrasil makes it possible to compile static binaries of rust packages which, unlike dynamically linked binaries (the typical case for Yggdrasil), include the code of their dependencies and as a result can be bound by the terms of the dependency licenses.

Two things make this tricky:

1. cargo build doesn't produce licenses for your binaries which include dependency licenses
2. Other packaging ecosystems have inconsistent takes on the issue

   Fedora pays lip service to the topic here but does not seem to consistently incorporate dependency licenses into built packages like ripgrep.

The rust package cargo-license (among others) provides the basic machinery we need to implement any agreed upon approach for rust, but we first need a consensus on a few issues.

Open Topics

1. Is this an actual problem? How important is it to solve?
2. What is an appropriate, general policy for static binary licenses (rust and go)?
3. Is it enough to dump all dependency licenses into the jll (like in #4088) or do we need something more elegant which calculates a 'derived license' from the set of all direct & dependency licenses?

[imciner2]

2. Other packaging ecosystems have inconsistent takes on the issue

   Fedora pays lip service to the topic here but does not seem to consistently incorporate dependency licenses into built packages like ripgrep.

The dependency license is incorporated into the compiled Rust crate package - it has the license MIT and (ASL 2.0 or Boost), so I really don't see what is inconsistent about it.

As for the licensing in general, the overall license for the compiled Rust crate must be provided. That said, it doesn't have to be the entire tree of licenses if some are compatible and can be merged into an overarching license (e.g. if a dep is MIT and the main code is GPL, then I think just saying GPL is perfectly acceptable).

I think dumping all the dependent licenses into the jll, while useful to people doing a full audit, could get very noisy if there are a lot of licenses for the deps. If we do want to go that route, separating out the license files for the full dependency tree from the overarching license file would be important (e.g. by putting the dep tree licenses inside a subdirectory).

[jeremiahpslewis]

Thanks for the feedback!

2. Other packaging ecosystems have inconsistent takes on the issue

Fedora pays lip service to the topic here but does not seem to consistently incorporate dependency licenses into built packages like ripgrep.

The dependency license is incorporated into the compiled Rust crate package - it has the license MIT and (ASL 2.0 or Boost), so I really don't see what is inconsistent about it.

Sorry, that was too strongly worded for the claim I wanted to make (and the knowledge base I am making it on. When I (as a non-lawyer) read the MIT license, it seems to me like a compiled binary must include the copyright notice (e.g. author year or w/e) of the project as well as its dependencies ("The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."). Can you point me in the direction of an interpretation of this license that might clarify this?

As for the licensing in general, the overall license for the compiled Rust crate must be provided. That said, it doesn't have to be the entire tree of licenses if some are compatible and can be merged into an overarching license (e.g. if a dep is MIT and the main code is GPL, then I think just saying GPL is perfectly acceptable).

Agree, any solution must yield an overall 'license interpretation' to be tractable, but this AFAICT needs to factor in dependency licenses to be valid.

I think dumping all the dependent licenses into the jll, while useful to people doing a full audit, could get very noisy if there are a lot of licenses for the deps. If we do want to go that route, separating out the license files for the full dependency tree from the overarching license file would be important (e.g. by putting the dep tree licenses inside a subdirectory).

Agreed. We definitely don't want to just dump a chaos of licenses into the _jll and consider it a job well done, which is why I opened an issue so we can build a general consensus before pouring it into code.