Cargo Deny complains about LGPL-3.0 licenses

[stevenj]

Context & versions

cargo deny check complains that the mithril libraries rely on LGPL-3.0+ licensed dependencies.

This is a problem for code because these libraries are statically linked, which means that any consumer can not produce a binary only version of the code. As the LGPL requires that the program must be able to be relinked.

Output of cargo deny check

error[rejected]: failed to satisfy license requirements
  ┌─ registry+https://github.com/rust-lang/crates.io-index#[email protected]:4:12
  │
4 │ license = "LGPL-3.0+"
  │            ^^^^^^^^-
  │            │       │
  │            │       a GNU license was followed by a `+`
  │            license expression retrieved via Cargo.toml `license`
  │            rejected: license was not explicitly allowed
  │
  = LGPL-3.0 - GNU Lesser General Public License v3.0 only:
  =   - **DEPRECATED**
  =   - OSI approved
  =   - FSF Free/Libre
  =   - Copyleft
  = gmp-mpfr-sys v1.6.4
    └── rug v1.24.1
        └── mithril-stm v0.3.22
            └── mithril-common v0.4.14
                └── mithril-client v0.8.4
                    └── cardano-chain-follower v0.1.0
                        └── hermes v0.0.1

error[rejected]: failed to satisfy license requirements
  ┌─ registry+https://github.com/rust-lang/crates.io-index#[email protected]:4:12
  │
4 │ license = "LGPL-3.0+"
  │            ^^^^^^^^-
  │            │       │
  │            │       a GNU license was followed by a `+`
  │            license expression retrieved via Cargo.toml `license`
  │            rejected: license was not explicitly allowed
  │
  = LGPL-3.0 - GNU Lesser General Public License v3.0 only:
  =   - **DEPRECATED**
  =   - OSI approved
  =   - FSF Free/Libre
  =   - Copyleft
  = rug v1.24.1
    └── mithril-stm v0.3.22
        └── mithril-common v0.4.14
            └── mithril-client v0.8.4
                └── cardano-chain-follower v0.1.0
                    └── hermes v0.0.1

Steps to reproduce

Run cargo deny check --exclude-dev on the code.

Actual behavior

Links against LGPL code without the option to select it.

Expected behavior

The libraries in-question have non LGPL counterparts already but there is no way to select them, its automatically chosen based on architecture.

It would be nice to expose a feature flag to control which library is used.