Julia release-0.5 builds the GPL version of mbedtls vs Apache

[mdcfrancis]

By default it builds against the gpl version.

michael@shadow:~/src/julia5/deps/build/mbedtls-2.3.0/library$ strings * | grep -i GPL
# Install script for directory: /home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_cli.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_srv.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_tls.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_cli.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_srv.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_tls.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_cli.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_srv.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_tls.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_cli.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_srv.c
/home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl/library/ssl_tls.c
CMAKE_SOURCE_DIR = /home/michael/src/julia5/deps/srccache/mbedtls-2.3.0-gpl

https://tls.mbed.org/how-to-get
'mbed TLS is primarily available under the Apache 2.0 open source license. Additional options are available if you have different needs.'

any reason for this ?

[wildart]

If you set USE_GPL_LIBS to 0, you'll get a Apache 2.0 version. Is there any problem with GPL version?

[tkelman]

Apache is not entirely compatible with GPLv2. When we build a GPL-allowed Julia, we use the GPL mbedtls tarball. With a no-GPL Julia we use the Apache tarball, which is exactly the same except for the license headers.

[mdcfrancis]

Without the linking exceptions I'm very cautious to use GPL code. libgit2 for example has a very specific exemption. I find it surprising that when there exists a alternative license Julia is not going for the less restrictive option.

[ViralBShah]

The current choice appears to be the right one. If you worry about GPL, why not just go with the no-GPL Julia build, which would satisfy all your constraints?

http://www.apache.org/licenses/GPL-compatibility.html

[ViralBShah]

I had not realized the subtlety of the argument before and found the link above quite instructive. Specifically the article says:
We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.

[mdcfrancis]

Yes the argument is very subtle and gets even more interesting when you add the affero clause
https://www.gnu.org/licenses/why-affero-gpl.en.html
Thankfully there exists the LGPL to explicitly allow linking without the viral transitivity. (this is appears to be the intent of the libgit2 authors, but in a different way)
https://www.gnu.org/licenses/lgpl-3.0.en.html

Not being a lawyer and not wanting to get on the wrong side of this, I avoid using any GPL code in my work.

My preference would be for Julia to by default be GPL free and have additional packages which can link / use GPL code.

[mdcfrancis]

As an aside, my local branch / build does set the NO_GPL flag

[tkelman]

Nothing used in Julia base is Affero GPL. A few Julia packages are (PLX.jl, maybe others?) or used to be.

Since we removed Rmath and command-line Git, the only thing left that's GPLv2-only is busybox which we only include on Windows and only for testing purposes (libgit2 is also GPLv2-only, but has a linking exception). That actually convinces me that we should be skipping busybox when USE_GPL_LIBS is off, even though it's only used via shelling out.

I guess when #17391 was opened we hadn't quite merged the Rmath removal yet.

[mdcfrancis]

Yes having a clean story is good. I'm very glad that most of base is pure and that we are not exposed to license risks. With the gpl flag off dies this also remove the sparse Julia code?

[tkelman]

It removes the code that calls into SuiteSparse. So you can't solve a sparse linear system of equations in a no-GPL Julia, which is kind of unfortunate. We're off-topic if the original issue is about mbedtls, but anyway... migrating FFTW out of base will probably be easier since I don't think it's extending any base methods on base types. There is a pure-Julia FFT implementation floating around in a PR that hasn't been merged yet, but I think that should have been made a package itself from the beginning so people could have actually been using it for the past year or two.

For sparse matrices we should try to come up with an extensible design where we could have the basic minimal scaffolding in base (or a general linear algebra package, eventually) but allow for different sparse solvers to be used as packages, so users could opt in to using SuiteSparse or Pardiso or MA57 or Mumps or whatever else they have installed.

[ViralBShah]

The details are murkier - only the supernodal parts of the cholmod are GPL, and umfpack and spqr are purely gpl (although there is an older lgpl version of umfpack). But it is not worthwhile to selectively use old or partial lgpl pieces, which will have known bugs and/or be significantly slower.

Many people also want to use MKL for BLAS, LAPACK, FFT, and sparse solvers. Not difficult work, but a lot of work. One step at a time. For now, I am closing this issue as it seems to be discussed and addressed.

Note that both FFTW and SuiteSparse can be licensed under non-GPL licenses by paying licensing fees.