Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo Deny complains about LGPL-3.0 licenses #1786

Closed
stevenj opened this issue Jun 27, 2024 · 2 comments · Fixed by #1884
Closed

Cargo Deny complains about LGPL-3.0 licenses #1786

stevenj opened this issue Jun 27, 2024 · 2 comments · Fixed by #1884
Labels
feature 🚀 New implemented feature

Comments

@stevenj
Copy link
Contributor

stevenj commented Jun 27, 2024

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
Copy link
Member

ch1bo commented Jul 3, 2024

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
Copy link
Contributor Author

stevenj commented Jul 8, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature 🚀 New implemented feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants