License mismatch: Dependency context_error requires special compatible licenses

[tkschmidt]

Hey,
I was testing mzcore and noticed that my CI/CD pipeline (using cargo deny) flagged an issue with one dependency (context_error) being licensed under the European Union Public Licence, Version 1.2 (EUPL-1.2).

According to the EUPL-1.2 licence text and its compatibility clause (Appendix, see https://eupl.eu/1.2/en/), Apache-2.0 and MIT are not listed as compatible outgoing licences.

Since context_error (the dependency with the EUPL-1.2 license) is statically linked into the Rust binaries and mzcore distribute those binaries, this creates a derivative work. As a result, mzcore cannot be distributed under Apache-2.0 or MIT while including this dependency.

The combined work would need to be licensed under EUPL-1.2 or one of its listed compatible licenses.

This makes this project very dangerous for a lot of people because the license field within the Cargo.toml now clearly states a wrong fact.

I would also advocate to not move the whole project to any of the compatible licenses because they are too restrictive.

Questions/Ideas

• Are there any easy ways to change the historical Cargo.toml content to warn people? I only see ways to yank it which doesn't change/warn.
• Ask @douweschulte to move context_error to Apache-2.0 or MIT if the license is not too important to him.
• A lot of rework: make context_error an optional dependency

[douweschulte]

As far as I can understand on the discussion of linking on EUPL itself (https://interoperable-europe.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences#section-3) the static linkage does not produce a derivative work and as such this should not produce any issues. If I read this correctly this would mean that anyone working with context_error should be able to safely go on with their business and only need to think about this when they create their SBOM which should list all dependencies and their respective licenses anyways. And only people that make a derivative work of context_error (i.e. copy and past the code and rework to add their own features) need to publish that new code in a compatible license.

If we assume that static linkage would create derivative work. Yanking could work together with a new release that has a different license. Re-licensing context_error would not be hard as it is all written by me. Making context_error an optional dependency is not a possibility. Or we could open a discussion to change the license of mzcore in the next rusteomics meeting.

[tkschmidt]

Not a lawyer, so take this with a grain of salt — this is based on my reading and some discussion with ChatGPT around how the EUPL applies.

The EUPL explicitly defers to EU law on whether static linking creates a derivative or combined work, and EU copyright law (via the Software Directive) governs how such linking is assessed. There is no clear bright-line rule that static linking is always safe, and some recognised interpretations (e.g. licence-compatibility analyses and OSPO guidance) treat statically linked binaries as derivative or combined works for the purposes of copyleft licensing.

So this might be fine — but it also might not be, and that legal uncertainty is likely why larger organisations (e.g. Google: https://opensource.google/documentation/reference/thirdparty/licenses#european_union_public_licence_eupl_not_allowed) tend to avoid EUPL-licensed dependencies altogether.

From a very personal standpoint, I would strongly prefer re-licensing 🙂

[gadi-armony-brkr]

I was looking into another issue and noticed this one.
We would also prefer the option of re-licensing of context_error

[mg-schneider]

Appreciate the clarification on the intent of the licensing situation!

Unfortunately, the status quo can be a problem for organizations which have to follow a fixed process to get dependencies approved. Even if the author intent is clear, the fact that automated tools pick this up as a violation may create difficulties depending on the specific processes involved.

A resolution where future versions of the tool would be released with a compatible dependency license would be a great help.