License compliance issue

[jnqnfe]

I would like to bring to your attention the fact that your licensing is incompatible with your dependencies.

Your crate is MIT licensed but depends upon nalgebra which is Apache-2.0 licensed only. While Apache-2.0 projects can use MIT licensed components, the reverse is not so.

Consider for instance that MIT is GPL v3 compatible, while Apache-2.0 is not; Your crate being MIT licensed is thus misleading to any potential GPL-v3 projects that consider using your crate - they'd end up constructing a non-compliant product.

[troublescooter]

Can you elaborate why an MIT licenced library cannot use an Apache-2.0 library?

Consider for instance that MIT is GPL v3 compatible, while Apache-2.0 is not; Your crate being MIT licensed is thus misleading to any potential GPL-v3 projects that consider using your crate - they'd end up constructing a non-compliant product.

The FSF states that GPL v3 and Apache-2.0 are compatible, and Apache expands on this, stating that this is allowed as long as the end product is GPLv3 licenced.

[jnqnfe]

Oh, that should have said GPL v2 not v3, sorry about that. Apache-2.0 is said to be considered compatible with GPL v3 but not GPL v2, which I think related primarily to the patent clause in Apache-2.0.

Note also the discussion of licensing here which hints at Apache only being problematic: https://rust-lang.github.io/api-guidelines/necessities.html

[troublescooter]

I do not have any legal training, but my current understanding is that there is a difference between other crates using an API and application authors that effectively compile everything, the latter of which, due to including binary code during the compilation process, are in the unfortunate situation of having to comply with licencing terms that are obscured by transitive dependencies. Referencing the API in a library does not include any code, so the statement

While Apache-2.0 projects can use MIT licensed components, the reverse is not so.

is incorrect in my understanding. Exclusively MIT licenced applications cannot use Apache-2.0 libraries, but exclusively MIT licenced libraries can use Apache-2.0 libraries. If this understanding is erroneous, I'm happy for corrections.

Combinations that are problematic are using this library in any GPL-licenced library or application except GPLv3. This is unfortunate.
The main author made statrs a derivative of the Math.NET library, which is MIT. Maybe being a derivative allows this library to potentially be released as Apache-2.0, but this would necessitate the agreement of all contributors.
If the current situation is legal, I don't see the benefits of doing this. Licencing under Apache-2.0 would potentially create headaches for other users, although it's uncertain how realistic the use case is where a GPLv2 consumer of this library would want to replace the dependency on nalgebra. Relicencing statrs as Apache-2.0 would necessitate them finding a complete GPLv2-conforming replacement for statrs.

[jnqnfe]

Sorry for the delay, I've been spending a lot of time these past couple of days trying to research things further. I have ultimately discovered some very enlightening info from the gnu project from which I've realised that my understanding of how licensing works in situations of mixed licences was fundamentally flawed. I've explained more thoroughly here in an issue for the same problem I made against nalgebra itself, should you care to read it for any reason.

Exclusively MIT licenced applications cannot use Apache-2.0 libraries, but exclusively MIT licenced libraries can use Apache-2.0 libraries. If this understanding is erroneous, I'm happy for corrections.

My new understanding, from what I learned from the gnu pages, is that this is not so. If you have an application with MIT licensed code, and a library with Apache-2.0 licensed code, or visa versa, and build a work combining them, that work then has both MIT and Apache-2.0 license terms applied to it in combination (you would need to comply with both sets of license terms and conditions together in use and distribution of it).

Combinations that are problematic are using this library in any GPL-licenced library or application except GPLv3. This is unfortunate.

Indeed.

The main author made statrs a derivative of the Math.NET library, which is MIT. Maybe being a derivative allows this library to potentially be released as Apache-2.0, but this would necessitate the agreement of all contributors.

That would not help. statrs currently cannot be used in a GPLv1/2 program due to it's dependencies being licensed as Apache-2.0 only, which means the final work would be the product of the incompatible set of licences MIT + Apache-2.0 + GPLv1/2. (The produced work does not have one single license, it has a set of three*).

*If this is weird, think about how linux packages gather such sets of licenses in their package data.

To enable compatibility with GPLv1/2 programs (as might be helpful for existing C codebases with [L]GPLv1/2 licenses migrating to Rust), you'd have to drop/replace the nalgebra dependency, or convince them to convert to an MIT or BSD-3 or BSD-2 license. In the linked discussion above they did mention that nalgebra had previously been BSD-3 licensed and it could be switched back, but as I type this I recall that in fact nalgebra itself depends upon further crates that are Apache-2.0 only so...

I'll close this since my original assertion was a mistake and there is no compliance issue to fix. Apologies for wasting your time.

[vks]

It might still be worthwhile to dual-license this project as MIT and APACHE2, for better compatibility with the Rust ecosystem.

[troublescooter]

If you have an application with MIT licensed code, and a library with Apache-2.0 licensed code, or visa versa, and build a work combining them, that work then has both MIT and Apache-2.0 license terms applied to it in combination (you would need to comply with both sets of license terms and conditions together in use and distribution of it).

Yes, that is what I was trying to say in my second comment. Simply referencing the API of an Apache-2.0 library in an MIT library does not create a derivative, and permissive licences generally do not contaminate other libraries. Only when the libraries are mixed into an application, modulo dynamic linking questions, does the onus of all the combined licencing terms rest on the application author. It's unfortunate that one cannot tell from the top-level licence what obligations using the library entails. These are two separate sets of obligations: Those of modifying the library and those of using the library (and all its implicit dependencies).

To enable compatibility with GPLv1/2 programs (as might be helpful for existing C codebases with [L]GPLv1/2 licenses migrating to Rust), you'd have to drop/replace the nalgebra dependency, or convince them to convert to an MIT or BSD-3 or BSD-2 license. In the linked discussion above they did mention that nalgebra had previously been BSD-3 licensed and it could be switched back, but as I type this I recall that in fact nalgebra itself depends upon further crates that are Apache-2.0 only so...

That is true, but licencing under Apache-2.0 xor BSD/MIT still reduces the scope of modifications somebody would have to do in order to make it compliant with GPLv1/2.

Also, these licencing issues are a nightmare to have to deal with, so as a bit of off-topic publicity, I recommend using Unlicense.

It might still be worthwhile to dual-license this project as MIT and APACHE2, for better compatibility with the Rust ecosystem.

I agree, but these issues are a huge pain to deal with correctly. Again, not a lawyer, but since the ownership of the code has not been assigned to statrs maintainers, I think that involves contacting all contributors.

Edit: Being completely anal here, we're not talking about licencing as MIT && Apache-2.0, but MIT xor Apache-2.0. Being compliant with the Rust ecosystem involves finding code snippets from Apache-2.0 libraries from which we can derive the Apache-2.0 licence on this crate, since we cannot remove the MIT licence of the Math.NET lib statrs was derived from.

[vks]

I agree, but these issues are a huge pain to deal with correctly. Again, not a lawyer, but since the ownership of the code has not been assigned to statrs maintainers, I think that involves contacting all contributors.

Yes, I think we would have to ask all 15 contributors.

[jnqnfe]

It might still be worthwhile to dual-license this project as MIT and APACHE2, for better compatibility with the Rust ecosystem.

I agree, but these issues are a huge pain to deal with correctly. Again, not a lawyer, but since the ownership of the code has not been assigned to statrs maintainers, I think that involves contacting all contributors.

I don't believe you would (also not a lawyer though). There are two different concepts to consider here:

Re-licensing would require contacting contributors since this concept is fundamentally about replacing licensing to resolve situations that cannot otherwise be solved, for instance switching to a more permissible license. Re-licensing requires seeking permission from all of the copyright holders (contributors) to offer their work under different terms & conditions (licensing). (You can always remove contributions (revert) from anyone for whom you do not get permission if someone refuses or does not respond btw).

Sublicensing is incorporating the work into something with a more restrictive license (I'm sure your fork and published crates count as that 'something'). The MIT license explicitly allows sublicensing, as you can see in the license text, or here. The license gives you a bunch of rights include sublicensing under just one condition:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Thus considering you are definitely using a "substantial portion" of the work you must do as it says; all you need to do though is simply make sure you keep that original MIT license file where it is in your repo (and ensure it's bundled within published crates). That's it, conditions met, you're now free to start distributing with a more restrictive license, which would allow your desired 'MIT OR Apache-2.0' choice. Just whatever you do, never remove that MIT license file and you're golden.

It would also be advisable to additionally ensure any existing copyright lines within files (the 'Copyright ' bit, not strictly the license declaration bit which you could change though) remain in place, as well as that being good form.

Edit: Being completely anal here, we're not talking about licencing as MIT && Apache-2.0, but MIT xor Apache-2.0. Being compliant with the Rust ecosystem involves finding code snippets from Apache-2.0 libraries from which we can derive the Apache-2.0 licence on this crate, since we cannot remove the MIT licence of the Math.NET lib statrs was derived from.

Ah, I misunderstood you as suggesting switching from MIT to Apache-2.0 rather than adding Apache-2.0 alongside MIT, as I think you realised. Yes, switching the license to 'MIT OR Apache-2.0' would offer maximum compatibility, for your crate itself at least, not much you can do about the dependencies. This is the same license offering the Rust devs use.

[troublescooter]

#122 tracks the changing of the licence.