Make Julia fully non-GPL (and non-LGPL?)

[PallHaraldsson]

A.
SUITESPARSE [mix of LGPL2+ and GPL2+]
seems to be gone in Julia 1.9, so document Julia no longer under GPL, assuming not a misunderstanding. [And maybe clarify in LICENSE-file of Julia 1.8 and older, at least 1.6, that Julia as a whole is under GPL.]

Julia being GPL (or LGPL) isn't any kind of problem, assuming you just use your default Julia and do not distribute/convey it WITH your source code to others (recommending downloading Julia first is however perfectly fine):
JuliaLang/PackageCompiler.jl#702

B.
With the last GPL component gone, Julia is under LGPL3. because of:

GMP [LGPL3+ or GPL2+]
and
MPFR [LGPL3+]

so could they be excised (from the sysimage), IF considered a problem (and might be a good idea anyway for smaller Julia, I assume Gig and BigFloat not needed by the Julia [compiler] itself)? It seems that would be a breaking change for Julia 2.0, requiring making an external package, and having to first need to do:

using Big

The LGPL3 is based on GPL3, but it DOESN'T mean anything like being GPL3 or GPL2-licenced, more like the older LGPL2. Still I'm unclear about the differences between LGPL2 and LGPL3 (I know some object to at least the latter).

Note:
LIBGIT2 [GPL2+ with unlimited linking exception]

shouldn't be a problem.

[ViralBShah]

I can understand being non-GPL, but why do we need to be non-LGPL?

Once SparseArrays moves out (note that SuiteSparse is now included in SparseArrays for backwards compatibility reasons), we will drop the major GPL dependency automatically. Let's hope we can get there for 1.9.

[PallHaraldsson]

but why do we need to be non-LGPL?

I'm not confident we strictly need to, for now just document LGPL prominently (and GPL in older). Given the downsides of the breaking change of adding a "Big" module, let's be sure first, it's a potential problem. It's something I saw with Qt preferring LGPLv3 over the older LGPLv2.1.

So some arguments here (I quote what I think may be most relevant):
https://www.qt.io/licensing/open-source-lgpl-obligations

The user is allowed to change and re-link the library used in the application or device – including reverse engineering. With LGPLv3 it is explicitly stated that the user also needs to be able to run the re-linked binary, and that sufficient installation information must be provided. In practice, this forbids the creation of closed devices, also known as tivoization.
[..]
For example some means of distribution, such as online application stores, may have rules that are in conflict with LGPL, in which case those cannot be used with the LGPL licensing option of Qt.
The user of an application or device created with LGPL library has to be notified of their rights by providing a copy of the LGPL license text to the user and displaying a prominent notice about using the LGPL library – i.e. it is not allowed to hide the fact the LGPL library is used.

Are the LGPLed libraries used dynamically linked? I'm not worried either way, until you use PackageCompiler, then static linking might be a problem (and GPL already is..., for proprietary code).

[PallHaraldsson]

Note it seems LGPLv3 code (but not LGPLv2.1) is incompatible with "GPLv2 only" code (see there full matrix):

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

So if Julia as a whole is LGPLv3, it might be a problem for users, i.e. if you have some "GPLv2 only" code (which is rare, outside of the Linux kernel), as opposed to "GPLv2 or later". This is mostly an argument to document what you get, and even is this case you're allowed to use Julia with that code (just not distribute/convey together).

If you DO NOT use LGPLv3 (e.g. GMP or MPFR) of Julia with your GPLv2 code, it seems silly that you would be in non-compliance, but I'm not a lawyer so I do not want to recommend either that "dead code" exception exists. If you DO use together, you're in this unfortunate (and likely unintended by FSF) GPL hell...

On the other hand while LGPLv2.1 would have been better, not always (if "LGPLv2.1 only"): https://opensource.stackexchange.com/questions/5664/linking-from-lgpl-2-1-software-to-apache-2-0-library

[PallHaraldsson]

It's not possible to get rid of Big without syntax change (but possible to move BigFloat to a package, still a breaking change, but not a syntax breaking change, and I think Julia only has a "syntax guarantee"; not API guarantee, or that is where they are located):
#25716 (comment)

[fingolfin]

The point of LGPL is that it is not contagious, like GPL. In particular, it is simply not correct that "Julia as a whole is LGPLv3". The one requirement is that the user can swap out the LGPL parts against a modified version. Note that it is even possible to ship a closed source program with LGPL parts, as long as the LGPL part can be replaced by the user (this is usually achieved by putting the LGPL part into a separate loadable module / executable, which is loaded during runtime -- note that this is also the case for Julia, thanks to all these bits being distributed via JLLs for release versions)

[PallHaraldsson]

Ok, "Julia as a whole" will not be LGPL (as suggested by someone), the main point, no longer GPL. That's an improvement, and I believe it's already happened, so maybe close this issue, if already documented.

I'm not worried about B. (LGPL) personally, it can be an issue is unusual situations, that do not apply (yet) to Julia users:

The one requirement is that the user can swap out the LGPL parts against a modified version.

In practice you can't if you were to upload Julia, or an app, made with, to Apple's app store. They disallow the GPL, and I believe the LGPL too (LGPLv3 is based on the GPL). And the FSF considers it Tivoization to NOT allow changes to software (such as in embedded hardware, e.g. Tivo), the reason they made the GPLv3 and LGPLv3 at the same time.

So the FSF also considers it a violation if you can't, in practice, swap out LGPL libraries, such as GMP and MPFR, which I believe they own the copyright to. Would you use those embedded (or for and iOS or Android app)? Not sure, but then Julia would be in violation.

So this is at least an argument to document as "MIT licensed plus LGPLv3 dependencies" (those dependencies would be "mere aggregation", at least until a user actually uses either). Since we can't drop both of them without breaking, I'm not sure worth it to make Big module just for BigFloat/MPFR. But that's a possibility to reduce likelyhood of such potential problems.

Should we excise MPFR (and GMP)? And for now add as stdlibs? PackageCompiler.jl should likely disable both (and SuiteSparse) by default...

[ViralBShah]

Should we excise MPFR (and GMP)? And for now add as stdlibs? PackageCompiler.jl should likely disable both (and SuiteSparse) by default...

This is unlikely to happen mainly for the reasons you mention (some of the big stuff is part of the language and base). See issues/PRs marked with the excision label - there are individual ones with discussion on all these issues.

Whenever things get excised, the licenses will be updated. We don't need a particular issue open here for that. Can certainly continue the conversation on discourse.