MKL bundled Julia by Julia Computing

They are certainly in a solid financial position to take on any potential legal consequences from shipping GPL code combined with non-open libraries such as MKL. I would not feel comfortable doing so, financially or ethically, and I know others at Julia Computing feel similarly.

5 Likes

According to the docs, it looks like they ship multiple BLAS libraries, and the user selects during installation against which one to link. Is this what they are doing?

IANAL, but I think this could at least conform to the spirit of the GPL: Linking GPL against closed source is permitted for users, but distributing linked binaries is not; both works, application-agnostic MKL and BLAS-agnostic R, are useful on their own right, purists get full functionality at lower speed with completely free software, but both can be linked together by the user to create a new derived work that is never distributed.

Might be worthwhile to ask FSF on an FAQ item whether something like that is acceptable (ship both openblas and mkl binaries, user decides against which to link; if somebody mentions docker LALALA CANT HEAR YOU).

4 Likes

I really like the idea of using docker container :grinning:

That seems like a plausible explanation for how this is legally acceptable. That’s a possible approach for us as well, with the down side is that making it possible to choose which BLAS to link against at install time seems like a fair amount of engineering effort.

Scilab is GPL and the installer gives the default option to use the Intel MKL, with the note that the user is subject to the Intel EULA. I’m not sure how that compares.

Is it? Naively, I’d think that one can ship both shared object files; during installation, set a symlink, and then build the sysimg. Possibly also set various environment variables to enable/disable known openblas / mkl bugs. I mean, the annoyingly slow part when building julia from scratch is compilation of the libraries (blas and llvm), not the sysimg. Do we ship sysimage binaries at all? If yes, these would need to be openblas, but waiting <5 minutes for sysimg recompilation is a much smaller price to pay than compiling the full llvm.

On the other hand, I’m sure you know better how much engineering effort that would be :slight_smile:

1 Like

A nice feature about the julia installation is that you unpack it and it works. Adding a whole sysimg compilation step there (which also requires a linker AFAIK) would make installing Julia much less nice.

6 Likes

If re-building sysimg is an OK solution then https://github.com/JuliaComputing/MKL.jl is the way to go?

1 Like

Well this licensing issue excuse is old now.

Python Annaconda ships with MKL-powered libraries:
https://docs.anaconda.com/mkl-optimizations/
https://docs.anaconda.com/anaconda/eula/
https://docs.anaconda.com/mkl-optimizations/eula/

I don’t think anything that was discussed in https://github.com/JuliaLang/julia/issues/18374 has really changed.

1 Like


https://software.intel.com/en-us/license/intel-simplified-software-license

To be compatible with the GPL, a license must allow not just redistribution but modification. The ISSL clearly does not: https://software.intel.com/en-us/license/intel-simplified-software-license

3 Likes

I don’t think the problem is with the MKL license but with the GPL license.

1 Like

I don’t find anything licensed under GPL. Please show me what you are talking about. (I didn’t know I should check stdlib as well)

Most browsers have a text search facility, often bound to ctrl-F. If you use that and search for the term “GPL” you will find multiple hits in that file. Each one indicates a piece of software that Julia uses that is GPL licensed.

4 Likes

I think whether the problem is with the ISSL or the GPL is more of a philosophical question (I would be inclined to say the problem is with the ISSL and its restrictions on user freedom).

In any case, to be as specific as possible, for anyone reading this thread in the future, the problem is caused by the fact that the ISSL doesn’t allow modification nor makes the source of MKL available while the GPL requires derived work/combined works to be freely redistributable and modifiable by the user. See point 5 here: https://www.gnu.org/licenses/gpl-3.0.html

3 Likes

Well, Conda has LGPL license. Conda license — Conda documentation
Are the problems caused by Julia standard libs?

LGPL ≠ GPL. The former has a linking exception which makes all the difference here.

3 Likes

OK, I get it. Essentially, Julia has a GPL license partially and so, which makes it non-combinable with other types of licenses.

Correct. Also, if the BLAS library were pluggable, instead of built in, then one could also argue that it’s not part of the GPL derived work, so you could ship with an MKL library and another BLAS (like OpenBLAS) and just use MKL by default. This is what Microsoft’s R distribution does in order to legally use MKL. It’s a bit legally iffy imo since MKL is the default, but I’m sure they have excellent lawyers who have looked at it.

For annoying library binary incompatibility reasons, Julia cannot currently just swap out OpenBLAS with MKL. I suspect the best way to fix this is to make compatible shims around both MKL and OpenBLAS so that they are actually binary compatible.

Another route to fixing this situation would be removing the GPL libraries from the base Julia distribution and making them add-on packages.

All of this is possible, it’s just quite a lot of work which doesn’t seem to be important enough to anyone who is willing or able to pay for or do the work themselves.

18 Likes