Is JULIA suitable for the development of proprietary derived-softwares?

We are using Julia at, to develop proprietary software, and we do have to build our own Julia with USE_GPL_LIBS = 0.
The one issue that was a problem when I first started with Julia, was that there was some code derived from GPL code, in the sparse matrix support, that was part of Julia.
Since it can be dangerous to study GPL derived source code, because of the viral nature of GPL, if you are implementing (or ever want to implement in the future) something proprietary, or even that you want to place under a more permissive license such as MIT, it’s not a good idea to have any GPL derived source at all in the Julia code base.
I do believe that has all been taken care of.

1 Like

Correct, there are many proprietary programs (including macOS for many years) which are compiled with GCC, which is GPL.

But if I use functions from SuiteSparse for instance then I cannot package the whole thing in one binary and hide the source, that’s against GPL from my limited understanding? So one has to be careful which functionality is used and packaged.

Yes, that’s why we have the compile option mentioned above.

1 Like

Although I do think it would be better to have any GPL stuff moved completely out of Base, and any LGPL3 dependencies moved to external packages or at least to stdlib.

Thank you very much. I understand GPL very well.

However I do not understand why web page says Julia is under GPL. By “GPL”, does it mean GPL and LGPL licenses? I mean for example what happens when USE_GPL_LIBS=0 flag is used. Are GMP, LIBGIT2, MBEDTLS, MPFR and SUITESPARSE removed during compilation?

Meanwhile was JuliaPro compiled with USE_GPL_LIBS=0 flag?

Example 1: you build Julia yourself from source with USE_GPL_LIBS=0. The Julia source code is under MIT, except the interface subdirectories noted in which are excluded from the system image by USE_GPL_LIBS=0. No GPL code is linked or loaded in the system image. You can embed in a proprietary application and distribute* without any GPL obligation (MIT license applies).

Example 2: you link your application against the Julia download distribution, which loads GPL code and links to GPL libraries. If you distribute your application, then the GPL applies.

The libraries will never be compiled. The source shouldn’t even be downloaded.

That would probably be a good guess, but I don’t know (I don’t work for Julia Computing).

*Again, if this will impact your business: talk to an actual lawyer who knows something about open source!. There are also open source compliance companies, and Julia Computing mentions that an “indemnity contract” is available for Julia Pro (whether that covers open source compliance specifically, I don’t know – contact them directly).

1 Like

JuliaPro’s product table says it has a GPL-free option.

I do wish Julia were free from some GPL dependencies, namely MPFR and GMP, because they aren’t wrapped well with Julia and don’t interact in good ways with Julia’s GC.
Compare the performance of 36 digit floating point numbers with BigFloat and DecFP.jl, for example.
BigInts are also something that would not be hard at all to implement in Julia, and are useful to have as well as BigDecimal like Java has, i.e. basically a BigInt with a huge scale (decimal scale).

I understand why MPFR and GMP were used to get Julia off the ground, but depending on them for v1.0 seems sad, when so much better could be done, both in terms of performance and memory usage, in pure Julia.


Thank you very much.


JuliaPro has an MKL version that is compiled with USE_GPL_LIBS=0 . That version therefore does not include FFTW and Suitepsarse. They use the Intel equivalents for those, and hence behave slightly differently.

1 Like

MPFR and GMP are available via LGPL, so they are fine to distribute with proprietary software (indeed Mathematica uses GMP as well).

This is not really a valid comparison: MPFR is an arbitrary precision library, DecFP.jl only offers fixed precision types. (also decimal128 provides only 34 decimal places).


LGPL doesn’t give you a free pass at all.
The opinion of the general counsel of the Free Software Foundation, Eben Moglen, speaking about the LGPL

A library linked to a program? (i.e., Is this a derivative
work of the program?)

Moglen: Code statically linked to code constitutes a
derivative work of the code to which it is linked,
without question, regardless of license terms. More
specifically, now regarding licensing as well as the
status of the work, code that cannot be used at all
unless dynamically linked to GPL’d code, and which is
distributed along with that GPL’d code, must be
distributed under the terms of the GPL. This provides
a competitive advantage to free software, requiring
those who wish to make unfree software to undertake
proprietary reimplementation of feature sets only
available in GPL’d libraries, such as GNU readline.

That seems to indicate that if the commercial software requires the LGPL library, even when just dynamically linked, it may be considered derivative, and must be distributed under the terms of the GPL.

IANAL (my wife was :wink: ), but that’s a strong reason to avoid any use of either BigInt and BigFloat in Julia if you want to be absolutely sure you don’t have a problem with the license in a commercial situation.
I’ve warned the people at my work to not depend at all on them, or on things that in turn depend on them in Julia.

MATLAB & MathWorks was around long before the LGPL and MPFR, and MATLAB does not require it, it is just part of a “multiple precision toolbox” package, so it’s optional use is fine with the LGPL.

Julia actually does require BigInt (to support the div, rem and mod functions for Int128 and UInt128, on 32-bit systems), which may mean that it is already in violation of the LGPL.
Irrationals also seem to require BigFloat, which might be another problem issue for Julia (so maybe irrationals need to be moved out of Base and the JuliaPro packages as well).

Numbers in Julia are considered immutable, however, because of the way BigFloats are currently wrapped,
they are very inefficient for space and performance. However, since they are in Base, it’s harder to supplant them with something better - for arbitrary precision, possible ArbFloats, although suffers from some of the same issues with wrapping something that has C pointers that BigFloats and BigInts have.
The way they use a global precision and rounding mode is an issue with the using multiple threads, they are not thread-safe (printing them also uses a global buffer, that is not thread-safe [or at least wasn’t, when I investigated this thoroughly back in 2016, before the JuliaCon]).

My point comparing to DecFP, was simply that other alternatives are faster and are provided totally via packages, so keeping something in Base that might cause legal problems for commercial use of Julia doesn’t seem like a good idea.

No. The LGPL explicitly states

An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library. A “Combined Work” is a work produced by combining or linking an Application with the Library.

(emphasis mine), and goes on to say

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: …

(and goes on to list a number of conditions satisfied by Julia).

Allowing software with different licenses to link to it dynamically is the whole point of the LGPL. Moglen’s quote was talking about GPLed libraries (not LGPLed!): the GPL make no such exception for linked software.


If you follow the link, he (and Richard Stallman) were talking about LGPL, not GPL (at least, that’s the opening line).
Hopefully it’s not the case that it is a problem, I’d heard about LGPL not protecting in a few cases.
I tend to be very careful with these issues (such as avoiding even reading GPLed source code)

In my understanding a large part of the point of the LGPL is that you can dynamically link a proprietary application against it without problems. As long as the user can switch out the library for a different version or a different library with the same interface, you should be fine.

I imagine the only time you’d get into trouble is if you were going out of your way to restrict the user, like checking the hash of the library and only allowing them to use one particular binary.

(standard IANAL applies)

No, Alexander Terekhov (author of the linked post) talked about the LGPL, but he quotes Moglen talking about “GPL’d libraries, such as GNU readline.”

A possible point of confusion here is that what counts as a derivative work, and hence what has to abide by the terms of the license, is set by copyright law, not by the license. In the FSF’s view, linking to a library generally creates a derivative work that must abide by the library’s terms. However, the terms of the LGPL explicitly state that the entire combined work does not need to be distributed under the LGPL.

That is, in the FSF’s view (which appears to have held up in legal actions over the years), a library has the legal right under US (and possibly other) copyright law to dictate terms of distribution to software that relies on it. The GPL exercises this right to compel release of source code for the whole program. The LGPL explicitly does not do this, and instead imposes the lesser requirement that the user should e.g. be able to swap out and modify the LGPLed library itself (which is satisfied by dynamic linking) The MIT/expat license compels essentially nothing other than that the copyright statement be preserved … but it does so using the same power provided by copyright law.

Again, this is the whole point of the LGPL.


One of the things I’d been warned about is if the product was more or less a wrapper for the LGPL code.

OK, good to hear. I get paranoid when dealing with stuff from Stallman :wink:

Still, do BigInt and BigFloat really deserve to be in Base, when not everybody wants them, and there are other, potentially better alternatives in packages?

As one example, Autodesk builds a number of proprietary products on the LGPL version of Qt (not to mention many other LGPL libraries, apparently):

1 Like