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

[simonbyrne]

@pkofod

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?

Well, the first step would be to move it to the stdlib, which wouldn’t really be a problem since the Test module is now there as well. Moving it to a separate package would be more complicated but doable.

[ces]

@tobias.knopp

I said that statically linking LGPL libraries into MIT code is problematic. What is wrong with that conclusion?

Yep, that’s why I said I don’t follow your train of thought here. That sentence is basically implicit in my first post (i.e.: my first post asked for plans about replacing such libs with non-LGPL alternatives, so that license problematic scenarios are avoided). And your conclusion is that it’s problematic because of the LGPL license requirements… but that was what I was asking… my question wasn’t about static linking (that was just an example), but about getting a non-LGPL build.

[ces]

@lobingera

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.

Why do you want to do static linking of a dynamic object? Why don’t you recompile the library as a static lib?

[lobingera]

As said above, the solution was to recompile dependencies from source and work on the library connections. And it was not my idea. However the classical ld.so actually produced the static executable before running it, so …

[tobias.knopp]

@ces

Yep, that’s why I said I don’t follow your train of thought here. That sentence is basically implicit in my first post (i.e.: my first post asked for plans about replacing such libs with non-LGPL alternatives, so that license problematic scenarios are avoided). And your conclusion is that it’s problematic because of the LGPL license requirements… but that was what I was asking… my question wasn’t about static linking (that was just an example), but about getting a non-LGPL build.

If you are not interested in static linking then you motivation of getting rid of LGPL libraries is unclear. We recently had lots of confusion in this forum where some misinformation was floating around (i.e. that LGPL has an issue when being used in a closed source application). Thus it was not clear what you are aiming to do.

So the consensus of most Julia developers seems that LGPL libraries are absolutely fine, and for that reason nobody is actively working on a replacement. Still there is some motivation of splitting of those things into dedicated modules (living in stdlib) which would make it super simple to remove them or to provide a drop-in replacement.