I understand the JuliaPro does not ship MKL version anymore. There is an explanation of the situation in 2016 by @StefanKarpinski :
This is not a technical issue primarily, it’s a legal one. You can easily build Julia with MKL, but as long as Julia ships with GPL libraries like FFTW and SuiteSparse, shipping Julia with MKL is illegal. Non-GPL licenses for both FFTW and SuiteSparse can be purchased, but obviously that’s not a viable open source default. If you’re willing to pay for a commercially supported Julia Pro, then you can get Julia built with non-GPL versions of these libraries and MKL.
from https://github.com/JuliaLang/julia/issues/18374. So what prevents Julia from shipping with MKL instead of (or addition to) OpenBLAS? Does this legal argument still apply? Or is it perhaps developer-time issue? Or some other technical difficulty?
Still legal: some of SuiteSparse is GPL. In order to use it legally, we must abide by the terms of its license, which requires that the derived work (julia) follow the rules of the GPL. This means that all code that we ship as part of julia must be provided under terms compatible with the GPL. That’s no problem for MIT or BSD code, but MKL is distinctly not something that we can ship under terms compatible with the GPL since it is closed source. Therefore, if we shipped julia with MKL, we would be violating the terms of SuiteSparse’s license, voiding our legal permission to use it. Dynamic versus static linking does not alleviate this responsibility: anything that is clearly intended to be part of the derived work counts.
Yes, that would fix the problem and allow us to ship Julia with MKL. This is one of the reasons we’ve been trying to move functionality like sparse at arrays and arpack out of Base.
I have to say I am lost. If SuiteSparse (ss) was a stand-alone package, JuliaPro would be able to ship Julia with MKL, but no one would be able to use ss with Julia then, because Julia would be distributed with a license incompatible with that of ss. Or am I misundertanding?
Loading it as an add-on package would be fine. That does not create a derived work because Julia would then be fully functional and complete without the package, which means that Julia is not a derived work. However, since we ship SuiteSparse and build it with Julia and build it into the system image, it’s very questionable to try to try to claim that what we ship is not a derived work including SuiteSparse.
So to clarify: Julia would be shipped with a different license? Not MIT?
Also developers who use Julia and “derive” their work by building on ss would be in trouble?
Julia’s code is and will remain MIT licensed,
regardless of what we combine it with. The derived work that is the julia binary that we ship is a combination of MIT, GPL, BSD and a few others—the requirements of using it are effectively the same as the legal requirements of the GPL (it’s a very slightly larger superset). Writing programs or packages in Julia does not create a derived work. If you were to build a custom system image including your code and then ship that, while including SuiteSparse, then that would be a derived work and the GPL would apply. MIT and BSD licenses don’t talk about “derived works” so the concept doesn’t really matter when considering whether you’re complying with them.
If I’m reading #27460 correctly, ARPACK was removed in #27616, and the SuiteSparse removal is being worked in #27638, right? Or are there additional issues not tracked by those?
Crossposting in general is rude, and necroing old topics to do so is even ruder. Please don’t do so in the future.
On the actual topic of anaconda and MKL, I don’t believe numpy includes or is derived from GPL code, so the legal barriers to bundling it with MKL are not significant compared to Julia.