Julia is no longer GPL licensed (as a whole)

[PallHaraldsson]

It seems SuiteSparse in no longer a regular stdlib, so is no part of it in the sysimage (and USE_GPL_LIBS in Makefile misleading)? And was it the last GPL there (i.e. not GPL just bundled with Julia)? And neither SparseArrays that includes SuiteSparse. If I'm right Julia should document it as such.

julia/stdlib/Makefile

Line 49 in 6bfb7fb

STDLIBS_EXT = Pkg Statistics LibCURL DelimitedFiles Downloads ArgTools Tar NetworkOptions SuiteSparse SparseArrays SHA

[ViralBShah]

It is still an stdlib (inside SparseArrays). Nothing has changed.

[StefanKarpinski]

I don't think that's true. The former stdlibs are only stdlibs in a very loose sense that we happen to ship a copy of the packages that used to be stdlibs along with julia in a special directory that we know to look in when loading former stdlibs if they aren't somewhere in the load path. I don't think that passes the bar of making them part of the derived work. The FSF is very clear that "mere aggregation" does not constitute creation of a derived work, so I think julia itself is probably non-GPL at this point and we could update the structure of the THRIDPARTY document to reflect that. Pinging @JeffBezanson and @Keno for opinions on the matter.

[StefanKarpinski]

I posted a bit more analysis here:

The FSF is very clear that mere aggregation does not constitute creation of a derived work: https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation. At this point Julia doesn't require or link by default against any GPL software. Nothing GPL is loaded unless you explicitly go out of your way to load it. Since Julia is literally capable of loading any dynamic library at runtime, the fact that you could load a library does not mean that it's part of Julia—you can't argue that Julia must be bound by the licensee of every library in existence just because it can load them. The only thing special about SuiteSparse is that it happens to be shipped side by side in the same tarball—you could delete it and everything would work fine unless you tried to load the SuiteSparse package. The SuiteSparse .so isn't linked into libjulia or anything either. Quoting the FSF FAQ, in the case of mere aggregation of two programs, "if one of the programs is covered by the GPL, it has no effect on the other program." So I think at this point we can already consider base Julia to be GPL-free.

[Seelengrab]

They also state this in the following paragraph:

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

There's a reason the ClassPath exception exists after all - https://en.wikipedia.org/wiki/GPL_linking_exception, which the FSF itself agrees with https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL. I guess this could be viewed as "julia is GPL free until you actually start to use SparseArrays", since SuiteSparse doesn't have the linking exception.

[StefanKarpinski]

Yes, if you write a program that uses both SparseArrays and some GPL-incompatible library like MKL then you cannot legally redistribute that code. I believe it is fine to use them together so long as the combined work is not redistributed. But this is no different from the situation with any GPL package that someone could use.

[ViralBShah]

It seems that the key thing here is that SparseArrays (which includes SuiteSparse bindings), while still an stdlib, is no longer part of the system image.

We should perhaps get rid of the USE_GPL_LIBS flags in the codebase along with the licensing language update.

This should probably also be prominently included in the 1.9 NEWS.

[KristofferC]

This should probably also be prominently included in the 1.9 NEWS.

1.10.

[ViralBShah]

Lost track of which release we removed SparseArrays from the system image...

[PallHaraldsson]

I opened this issue since I had "mere aggregation" in mind, but yes, only when using/linking to (even indirectly) SuiteSparse, then the whole becomes GPL. But even then it seems the System Library exception applies:

https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

https://www.gnu.org/licenses/gpl-3.0.html

[not just the OS but also meant for the] interpreter used to run it.

Also whatever you do in private can't violate the GPL. Julia is MIT, and thus GPL compatible, but even if your program, that you run on/with Julia, isn't, then also that's ok (I'm not a lawyer, and it may depend on if Julia qualifies as an interpreter, JIT not ok?), as long as you don't distribute Julia with it (e.g. use PackageCompiler). So it would be best if PackageCompiler opts out of supporting (that one) GPL component by default, and it would be an opt-in.

It need to be documented well; in NEWS, MIT/"GPL-free", unless/until you actually use that component...

[StefanKarpinski]

It's unclear to me if an MKL that we ship would qualify for the System Library Exception.

[JeffBezanson]

I agree we are non-GPL now. Given this:

If modules are designed to run linked together in a shared address space,

it is clear to me julia is not designed to run with suitesparse; there are no references to it anywhere in the rest of the system.