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.

[Seelengrab]

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.

Yes, with the caveat that this also means that the SparseArrays package itself is GPL, right? It does make specific references to SuiteSparse etc. after all.

Maybe this is a case of "wrappers are ok", but I'm honestly out of my depth in regard to that..

[ViralBShah]

SparseArrays itself is not GPL, and neither are its wrappers around SuiteSparse.

[JeffBezanson]

In practice, SparseArrays is designed to work with SuiteSparse and will always be used with it, so arguably the wrappers are a derived work. However the core sparse array code does not mention SuiteSparse and so could be separated from it and the wrappers.

[ViralBShah]

SparseArrays can work perfectly fine without SuiteSparse, and in fact can with little effort, replace those solvers with other solvers, many of which are already packaged in Yggdrasil, or with MKL. The SuiteSparse wrappers themselves are the only parts that are designed to work with SuiteSparse.

In fact, for a while SparseArrays.jl and SuiteSparse.jl were separated, but merged back into a single package for type piracy reasons.

[Keno]

I concur with the analysis.

[StefanKarpinski]

I would also point out that even for code like wrappers that are tightly coupled and designed to interact with GPL code, that only implies that the GPL applies to the combination, which requires the wrapper to have a GPL-compatible license. It does not imply that the wrapper must be GPL-licensed. The SuiteSparse wrapper code is MIT-licensed but when used with the SuiteSparse library, the combination is GPL. If the wrapper code is modified to work with some other library, the GPL does not come along.

[JeffBezanson]

I added a news item in #50848; please review the language used there. I actually can't find anything in THIRDPARTY.md or our documentation that looks like it needs to be updated; we don't generally mention what is included in the default system image since it's kind of a detail. Let me know if you can find anything that should change.

[PallHaraldsson]

SparseArrays and SuiteSparse are no longer included in the default system image, so the core language no longer contains GPL libraries.

@JeffBezanson about your wording above, I assumed SuiteSparse the last GPL holdout. There is though: "GMP [LGPL3+ or GPL2+]". Depending on what you mean by core language, then we depend on LGPL at least, which is better than GPL.

This seem ok (for proprietary code, not sure any disallows LGPL[3]; also for GPLv2 only code): https://softwareengineering.stackexchange.com/questions/238748/can-gpl-v2-code-link-to-an-lgpl-v3-library

And technically we have Pkg (still) in the sysimage (until we merge my PallHaraldsson#4 see #2050833), and it depends on "LIBGIT2 [GPL2+ with unlimited linking exception]". I wouldn't include it as a "core language" feature, and we can likely keep silent on it since it's a special case with "unlimited linking exception".

the default system image since it's kind of a detail.

But for legal reasons it isn't. If you distribute Julia (as is) with Julia, and thus the sysimage, your source code, the GPL would apply (also if you use PackageCompiler.jl I think since it uses the same sysimage?), if GPL code there. I doubt it falls under "mere aggregation". Why I want it completely GPL free. And possibly LGPL free too. I think it's easy, you choose what you precompile into the sysimage. It's kind of bad that big is in Base but not a stdlib, but I think ok since because of LPGL. People have a right to dynamically link to a replacement. I think that works, i.e. we do not statically link to GMP?