Any plans for non-LGPL alternatives for GMP and MPFR?

General Usage
1

Hi!

While I can use LGPL libraries in this moment, I’m not sure if any projects that I face in the future might have static linking requirements that would make it impossible to use LGPL libs without all the project becoming LGPL.

Because of this, and thinking in the future, I’m wondering if there are any plans for providing non-LGPL alternatives for the currently required LGPL libs in Julia (if I’m not mistaken it’s just two libs: GMP and MPFR)

I don’t know the details of the feasibility of this, but, there’s a success story of allowing to use Boost.multiprecision instead of these libs in symengine, turning symengine MIT/BSD licensed if you build it with that option (you can read the details on how this was done here: https://github.com/symengine/symengine/pull/1121 )

Thanks!

3 Likes
2

There currently aren’t any plans to, but there has been discussion in the past about removing some of the need for these libraries. As BigFloats aren’t really core to the language, MPFR would be the easiest to remove (there are only a handful of other places, such as inequality comparisons involving irrationals, where it is used). BigInts would require a bit more work, as they are generated by the parser, but it might be possible to move the parsing code into Julia itself, and leave GMP just for arithmetic (or leave it to a package).

1 Like
3

As far as I know there is no such problem with LGPL: GNU Lesser General Public License - Wikipedia Am I missing something?

4

A BigInt package I think wouldn’t be to hard to implement from scratch in pure Julia (all of the algorithms are pretty well known), and I think it would have a lot of performance/memory utilization advantages over the current wrapper of GMP (some of the latest Union optimizations might be very useful for that).

(I’ve written one in Scheme, and later on in C and assembly, doing up to 128-bit arithmetic with 16-bit operations)

5

From what I understand, in the case of static linking, you need to provide a way for the user to relink the executable using an updated or modified version of the LGPL code, either by providing source code or linkable object code modules.

I guess it’s just that it’s more burdensome to comply with the LGPL if you have to do static linking.

1 Like
6

In order to help you it needs some more information what you are trying to accomplish.

  • Do you actually need BigFloat and BigInt functionality?

If not you can easily rip off those parts from Julia. If you don’t know how, you can leave me a private message and I will make you an offer (assuming that you have commercial interests, which is indicated by your question).

In general, there is no licensing issue though. Even if you statically link to libjulia, you would still link dynamically to GMP and MPFR.

7

A BigInt package I think wouldn’t be to hard to implement from scratch in pure Julia…

It seems you have a concrete plan for a replacement package which is really great. Looking forward to this.

8

Do you have commercial interests? :slight_smile:

9

Do you have commercial interests? :slight_smile:

No. Just wanted to express that it is great when there there is a potential replacement for BigInt written in pure julia.

10

BigFloats are used in a lot of math tests though, so it would require quite a lot of hardcoding wouldn’t it? Or would BigFloats.jl just be in a test require file?

11

BigFloats are used in a lot of math tests though, so it would require quite a lot of hardcoding wouldn’t it? Or would BigFloats.jl just be in a test require file?

That depends on what one wants to accomplish. If the goal is to distribute Julia (e.g. as part of a product) one would usually not distribute it with tests.

Regarding the removal of GMP and mpfr it basically boils down to commenting out some lines here:

and there may be some other files where the exports are within. It would be even easier to just remove the .so/.dll/.dylib from Julia. So again, if someone really has a need for this, it would be a tiny bit of effort but we are here to help out. Just say concretely what is the goal and there will be a simple solution.

12

I read Simons comment as a general comment that bigfloat could be moved, not that it could be opt out. That’s why I asked what I did.

13

In the past, what I implemented was multiprecision arithmetic, integer and decimal floating point, up to 128 bits, using 16-bit and 32-bit arithmetic, in assembly (8086 & IBM 360 series), as well as pure C, then pure C with assembly optimizations (to do things like 16x16 → 32 or 32/16 → 16). Since the language these were done for was string oriented (ANSI M/MUMPS), I only had to provide *, / div, rem, +, -, cmp, ==, and fast string → number, number → string routines.

Looking at Julia, these are the functions which would have to be implemented to replace BigInt:

*, +, -, /, rem, div, divrem
<, <=, ==, cmp
&, <<, >>, >>>, count_ones, trailing_ones, trailing_zeros, xor, |, ~
flipsign, signbit, signed
show
convert, string
base, bin, hex, dec, oct
ndigits
serialize
^, binomial, factorial, fld, gcd, gcdx, invmod, isqrt, lcm, mod, nextpow2, powermod, prevpow2, sqrt

I’m know I can handle all of them (time permitting), except for the last line, and some of those I could handle also (but IANAM, and it isn’t my primary area of interest, I’m happy with just the basic functions :grinning: )

14

I don’t know if anybody recalls, but a couple of years ago (in the v0.4 release timeframe), I had a branch of Julia which I had gotten to build and pass tests, where I made pretty much everything opt-out, LinAlg, the REPL, documentation, BigInt, BigFloat, etc.
The hardest part back then was dealing with the way documentation had all been thrown together in huge files, instead of being placed with the definitions of the functions.
I think that that issue may have been resolved by now, so maybe after all the rest has been moved out of Base and in to stdlib, that’s going to be moved, I’ll resurrect that set of changes and do the same on master.

2 Likes
15

I currently don’t need BigFloat nor BigInt directly, but I didn’t know if they were internally needed by Julia, its libraries, or any external component that I might use, so that’s why I asked. From your reply I understand that some surgery in the parser source would be feasible for cases when BigInt is not really used in a project.

Anyway, as you point out, there’s no licensing issue if you dynamically link to GMP and MPFR. But if you cannot dynamically link (and believe me, I’ve been in situations in the past where statically linking was the way to go, either because of limitations/requirements from the deployment OS, or by constraints from the build system), then in these cases, the LGPL might not be feasible for binary-only distribution.

We are in a always changing world. You don’t know if dynamically linking would be convenient (or even possible) in a project you’ll have a couple of years from now. You meet most open-source non-GNU licenses by giving proper credit to the authors, accepting the guarantee disclaimers, and personally contacting the authors for notifying them their work has been chosen for a product (the later is not usually a license requirement, but honest and kind behaviour obliges it). OTOH, LGPL licenses impose the extra requirement that static linking is not possible.

I’m new to Julia. I’m liking it. So much that I think it’s going to become a must have language for me from now on. When you invest time writing code in a language, or for an API, you start depending on that technology for many, many years to come (I wrote several man-years of Motif-GUI based code in the 90s, so you can guess what happened to those man-years when Motif got phased out in the 2000s --the code was not dropped, but an important transformation, involving even more man-years, was required).

16

Ok then this question is basically solved and you hopefully have a better feeling investigating time into Julia.

While it would be technically possible to statically link those libraries into libjulia this does not work out of the box. Since this would be problematic from the licensing perspective the probability that someone tries to do that is pretty low. And even if someone tries this at home, such code would certainly not land in the Julia repo.

17

I’m not following your train of thought here… it wouldn’t be problematic from the licensing perspective if these libs were replaced by non-LGPL alternatives (which do exist), which is my question. There’re no plans to replace them, so the feasibility of using Julia for a binary-only distribution in a OS or scenario that didn’t allow dynamic linking is not possible. I don’t really follow how you get to the above conclusions, but the answer is the same: not planned at this time.

18

I said that it is technically possible to link these libraries to libjulia, but that currently there is no infrastructure for that. Further I said that statically linking LGPL libraries into MIT code is problematic. What is wrong with that conclusion? As you said, a (one) binary only distribution is not there and also not planned.

19

Is there any generic code for these functions, so that if I implemented the basic functions that I know how to do, then they would still be supported (although maybe not as fast as specialized versions, of course):

^, binomial, factorial, fld, gcd, gcdx, invmod, isqrt, lcm, mod, nextpow2, powermod, prevpow2, sqrt

Also, if I did get a BigInt replacement together, where would be the appropriate place for it?
(stdlib, or JuliaMath, perhaps?)

20

OT: How does static linking of a shared object actually work (if there are no licensing restrictions)? I remember trying to do this with various ld.so setups (admit, it was in Solaris) and never managed to get a running executable. The solution was usually to work with the library in source - and redo the calls via dlopen.