GPL/MIT licensing issue

[rcurtin]

Hi there!

@nassarhuda and I and others are looking to use GLM.jl in one of our projects, but we noticed that GLM.jl, which is licensed as MIT, depends on this package (also licensed as MIT), but then this package depends on the binary package Rmath_jll, which must be licensed GPL, as the Rmath-julia sources for that package are GPLv2.0.

Now, I am definitely not a lawyer, but based on my understanding of licensing, I think that this package must also be licensed under the GPL? I suppose (but am not sure) that it would be sufficient to leave this package under the MIT license, but point out in LICENSE.md that Rmath_jll is GPL-licensed and thus any derivative works that depend on Rmath.jl must also be distributed under the terms of the GPL.

In any case, this seems like it has significant implications downstream, as core packages like StatsFuns.jl have a dependency graph that involves this package and also Rmath_jll, and so all of those would also need to note that they are transitively under the terms of the GPL too. (This includes TensorFlow.jl too, it seems, judging by the dependency list.)

Let me know what you think. At least for us, we can't use GLM.jl (or anything else that depends on this) with this licensing issue present.

Thanks!

[ararslan]

https://github.com/JuliaMath/FFTW.jl#license provides a good explanation of a mostly analogous situation. The package itself doesn't have to be licensed under GPL, as it's not a derived or combined work.

[rcurtin]

Thanks for the link! That roughly matches my understanding of what the license implies, so good to know I am not totally off base in my thinking. :)

But, in this case, this nuance and implications of using this package aren't adequately communicated in all downstream packages---meaning that people who build things against downstream packages are unaware that they could be violating the GPL if they distribute their packages only in accordance with, e.g., the MIT license. What can be done to fix that?

[JeffBezanson]

If a package has a GPL dependency, it needs to use a "GPL-compatible" license. The MIT license is one. Then the combined bundle, when distributed, is automatically GPL. To inform users of that situation, in julia we're now using a file THIRDPARTY.md to list the licenses of dependencies.

[rcurtin]

Thanks for the response. The THIRDPARTY.md solution seems reasonable, but it doesn't seem like it's been applied to all the reverse dependencies of this package.

1. Would it be reasonable to go through that reverse dependencies list and make sure that this GPL dependency is noted in each of those repositories, be it via a THIRDPARTY.md file or a note in the README? It is very easy to miss this issue when building software.

2. I see that there has been some discussion about replacing the GPL-ed functions wrapped here before: discourse, Mention GPL dependancy? StatsFuns.jl#13, RFC: move log/exp variants to a separate package StatsFuns.jl#46. Does anyone know what the status of that effort is? If I (or someone else) was able to help out with that effort, would someone be able to bring me (or others) up to speed on what needs to be done to get it merged?

Basically we would really like to use GLM.jl and maybe some other packages that have dependencies on Rmath, but the GPL compatibility issue is a bit of a blocker for us. :)

[nalimilan]

1. I'd say it would be reasonable to make PRs to packages that depend on Rmath to add a THIRDPARTY.md file and a reference to it in LICENSE.md. Though of course it will be very hard to be exhaustive given that these are quite fundamental packages that are used indirectly by many packages (and new ones are added all the time).
2. Progress is going on at Use julia implementations for pdfs and some cdf-like functions StatsFuns.jl#113 but this is a large undertaking.

[ViralBShah]

The README of this package clearly mentions that it is licensed under GPL. I feel this can be closed, as there is nothing further to do in this package.