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.

[douweschulte]

If I read the EUPL developer guidelines correctly this should expressly be allowed.

The EUPL refers to the laws of EU countries and is therefore interoperable. This means that all the interfaces of the covered software (the APIs, formats, data structures) can be freely copied and reproduced in other independent works in order to build interoperability, e.g. combining software distributed under the EUPL with any other software licensed differently, even under a proprietary licence. In such a combination or statically linked aggregation, every linked component will keep its primary licence, without any ‘viral effect’.
EUPL guidelines 2021, page 4

But if this statement is not clear enough for lawyers and that means that other people cannot use the software that would be a shame.