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#gmp-mpfr-sys@1.6.4: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#rug@1.24.1: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.

[ch1bo]

As the LGPL requires that the program must be able to be relinked.

IANAL, but LGPL-3 section 4 paragraph d) states two alternatives, while option 1) is your mentioned relinkability, option 0) means basically "make the combined work's source code available". Mithril is open source (and rather falls under section 5 of the LGPL-3 license) so I think this would be satisfied?

@stevenj Would this be an option in your case? i.e. as long as the application using mithril-client library is open source this should not be very urgent issue?

[stevenj]

As the LGPL requires that the program must be able to be relinked.

IANAL, but LGPL-3 section 4 paragraph d) states two alternatives, while option 1) is your mentioned relinkability, option 0) means basically "make the combined work's source code available". Mithril is open source (and rather falls under section 5 of the LGPL-3 license) so I think this would be satisfied?

@stevenj Would this be an option in your case? i.e. as long as the application using mithril-client library is open source this should not be very urgent issue?

Your right, but Apache2 allows distribution in Object form without source, it's not Copyleft. So the LGPL license prevents anyone from taking advantage of this aspect of the Apache 2 license. My current use case is in a library which is itself Apache2, so having a LGPL library restricts the scope of the Apache 2 license to that of LGPL (Source, or re-linkable against object files).

It's not urgent, I raised this issue because I will, at some point in the near future, raise a PR to address this with a feature flag.

Is there a performance or some other reason behind the library choice? Not trying to second guess it, just after more context because there is already a non LGPL alternative supported by the code?