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

General Usage
21

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.

5 Likes
22

Thank you very much.

2 Likes
23

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
24

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).

2 Likes
25

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
(https://www.spinics.net/lists/xf/msg02311.html)

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.

26

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.

4 Likes
27

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)

28

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)

29

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.

4 Likes
30

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

31

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?

32

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

https://www.autodesk.com/company/legal-notices-trademarks/open-source-distribution

1 Like