METIS is Apache 2.0 licensed exclusively about metis-rs HOT 4 CLOSED

Hello @wlinna,

METIS FAQ states that you can distribute it under Apache 2.0

That's not exactly what the FAQ says. The FAQ states:

METIS as of 5.0.3 is being distributed under the Apache License Version 2.0.

metis-rs relies on the latest commit of the METIS repository, so the version predicate applies. This means that further terms of distribution are dictated by whatever the Apache-2.0 license states. From its 4th paragraph:

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

According to this, I think it would technically be possible to redistribute METIS along with metis-rs and slap an MIT or Apache-2.0 license on top. However, that's not what we are doing. Our README states:

metis-rs is distributed under the terms of both the MIT license and the Apache License (Version 2.0). Refer to LICENSE-APACHE and LICENSE-MIT for more details.

I would argue that the scope of our terms only applies to metis-rs, not METIS. However, you are absolutely right on this point:

Regardless, distributing them under MIT is likely to confuse users who believe they can use the library-as-a-whole under MIT license.

It is not our job to state which terms the original library can be used under (and we're not doing that), and because of our usage of submodules and cargo-vendor, there is some ambiguity on the scope of our terms / what we are distributing.

All of this being said, here's my suggestion:

• keep the license coverage unchanged
• add a paragraph in our README explicitly stating that our licensing only covers metis-rs and does not apply to METIS

@cedricchevalier19 @dssgabriel any input?

from metis-rs.

Thank you for the quick response :)

My paraphrasing indeed misses some important nuances. Should have quoted verbatim instead.

It is not our job to state which terms the original library can be used under (and we're not doing that)

This is what I was thinking as well. Offering metis-rs under MIT or Apache-2.0 indeed makes sense. The license of METIS could change in the future in theory, in which case it's good that metis-rs is already licensed under terms that work well with the rest of the Rust ecosystem.

The only downside in this arrangement is the little bit of difficulty it might add to the process.
For example, if someone had to avoid Apache 2.0 license for some reason, and tried to use cargo deny or similar tool, they would easily miss the fact that they are using METIS which is distributed under Apache 2.0. If you can and do distribute both metis-rs and METIS under MIT and Apache 2.0, that would resolve the issue completely (or so I think, but IANAL).

This doesn't matter to me personally though, because I wasn't planning to use metis-rs, at least not yet. I merely found it out of curiosity.

from metis-rs.

Hello @wlinna,

I agree with the suggestions made by @imrn99. We should (a) keep the licensing of metis-rs under MIT or Apache-2.0 and; (b) make it clear that only the bindings are subject to this dual license, not METIS (which AFAIK, we do not redistribute ourselves within this project).

I understand your concerns about the exclusive Apache-2.0 license of METIS. Still, I would argue it is not our responsibility if users somehow have to avoid Apache-2.0: we only provide bindings, and as such, it's up to users to ensure they comply with METIS's licensing policy.

Moreover, the METIS project hasn't had significant contributions for several years now — the latest change was already over a year ago, and contributions in the past few years were bug fixes — so it's unlikely their license will change in the future.

Anyway, I believe the most qualified and experienced person to respond to this is @cedricchevalier19, I'll defer to his opinion.

from metis-rs.

@wlinna thanks for reporting this. As suggested by @imrn99 we will update the README.

The main concern is using the vendored feature that is enabled by default, in this case we also provide Metis source code (as Apache-2.0) but it might be confusing for the user.
I do not think we can automatically handle this cleanly with cargo (like disabling vendored when only MIT).

Anyway, we just provide a wrapper and the crate name metis-sys is explicit enough to flag the project as dependent on an external library and others projects on crates.io package the same way.

from metis-rs.