# Is JULIA suitable for the development of proprietary derived-softwares?
**URL:** https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912
**Category:** General Usage
**Created:** [December 22, 2017, 5:45am UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912 "2017-12-22T05:45:51Z")
**Posts on this page:** 12
**Page:** 2
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 22, 2017, 4:47pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/21 "2017-12-22T16:47:01Z")
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.
---
### Author:  [@NKC](https://discourse.julialang.org/u/NKC)
#### Post date: [December 22, 2017, 5:02pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/22 "2017-12-22T17:02:18Z")
Thank you very much.
---
### Author:  [@avik](https://discourse.julialang.org/u/avik)
#### Post date: [December 29, 2017, 2:30pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/23 "2017-12-29T14:30:38Z")
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.
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [December 29, 2017, 4:09pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/24 "2017-12-29T16:09:13Z")
> [@ScottPJones](#):
>
> 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.
MPFR and GMP are available via LGPL, so they are fine to distribute with proprietary software (indeed Mathematica uses GMP as well).
> [@ScottPJones](#):
>
> Compare the performance of 36 digit floating point numbers with BigFloat and DecFP.jl, for example.
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).
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 29, 2017, 9:29pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/25 "2017-12-29T21:29:30Z")
> [@simonbyrne](#):
>
> MPFR and GMP are available via LGPL, so they are fine to distribute with proprietary software (indeed Mathematica uses GMP as well).
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](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 😉 ), 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).
> [@simonbyrne](#):
>
> 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).
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 `BigFloat`s and `BigInt`s 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.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [December 29, 2017, 9:48pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/26 "2017-12-29T21:48:26Z")
> [@ScottPJones](#):
>
> 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.
No. The LGPL [explicitly states](https://www.gnu.org/licenses/lgpl-3.0.en.html)
> 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.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 29, 2017, 9:50pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/27 "2017-12-29T21:50:35Z")
> [@stevengj](#):
>
> 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)
---
### Author:  [@ssfrr](https://discourse.julialang.org/u/ssfrr)
#### Post date: [December 29, 2017, 9:54pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/28 "2017-12-29T21:54:08Z")
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)
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [December 29, 2017, 10:03pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/29 "2017-12-29T22:03:12Z")
> [@ScottPJones](#):
>
> If you follow the link, he (and Richard Stallman) were talking about LGPL, not GPL.
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.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 29, 2017, 10:03pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/30 "2017-12-29T22:03:29Z")
One of the things I’d been warned about is if the product was more or less a wrapper for the LGPL code.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 29, 2017, 10:05pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/31 "2017-12-29T22:05:50Z")
OK, good to hear. I get paranoid when dealing with stuff from Stallman 😉
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?
---
### Author:  [@ihnorton](https://discourse.julialang.org/u/ihnorton)
#### Post date: [December 29, 2017, 10:13pm UTC](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912/32 "2017-12-29T22:13:49Z")
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](https://www.autodesk.com/company/legal-notices-trademarks/open-source-distribution)
[Previous page](https://discourse.julialang.org/t/is-julia-suitable-for-the-development-of-proprietary-derived-softwares/7912.md?page=1)