Re: [julia-users] Re: Non-GPL Julia?

+1 On April 20, 2015 at 9:18:10 AM, Jay Kickliter (jay.kickli...@gmail.com) wrote: Thanks Viral On Sunday, April 19, 2015 at 10:05:23 AM UTC-6, Viral Shah wrote: And it is merged now.  On Saturday, April 18, 2015 at 4:22:26 PM UTC+5:30, Scott Jones wrote: That's great! That solves our dilemma fo

Re: [julia-users] Re: Non-GPL Julia?

Thanks Viral On Sunday, April 19, 2015 at 10:05:23 AM UTC-6, Viral Shah wrote: > > And it is merged now. > > On Saturday, April 18, 2015 at 4:22:26 PM UTC+5:30, Scott Jones wrote: >> >> That's great! That solves our dilemma for us! >> >> Scott > >

Re: [julia-users] Re: Non-GPL Julia?

And it is merged now. On Saturday, April 18, 2015 at 4:22:26 PM UTC+5:30, Scott Jones wrote: > > That's great! That solves our dilemma for us! > > Scott

Re: [julia-users] Re: Non-GPL Julia?

That's great! That solves our dilemma for us! Scott

Re: [julia-users] Re: Non-GPL Julia?

Non-GPL julia, when this PR is merged. https://github.com/JuliaLang/julia/pull/10870 The mac and windows installers we distribute will still be GPL due to git and busybox (although technically I don't think Julia can be considered as a derivative work here). If you are building from source, bui

Re: [julia-users] Re: Non-GPL Julia?

Is that available for non-Intel platforms? Given it is from Intel, I would be surprised... More importantly, it doesn't seem to support arbitrary precision decimal floating point, which the decNumber package does, just the 3 new IEEE formats (32-bit, 64-bit, 128-bit), which the decNumber packag

Re: [julia-users] Re: Non-GPL Julia?

On Friday, April 17, 2015 at 12:03:43 PM UTC-4, Scott Jones wrote: > > (and also to help adding a decimal float package using decNumber, which > is under the ICU license > Why not the Intel library https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library It's und

Re: [julia-users] Re: Non-GPL Julia?

Thanks. I still haven't tried building Julia, I've just been using the Mac and Ubuntu release and nightly builds, but I'll start looking into that... Scott On Friday, April 17, 2015 at 11:51:34 AM UTC-4, Milan Bouchet-Valat wrote: > > Le vendredi 17 avril 2015 à 08:33 -0700, Scott Jones a écrit

Re: [julia-users] Re: Non-GPL Julia?

I'm quite willing to help do so... (and also to help adding a decimal float package using decNumber, which is under the ICU license, and maybe contribute to a few other things I need, like the ODBC.jl package), but right now I'm just a few weeks into learning Julia. Maybe by the time JuliaCon i

Re: [julia-users] Re: Non-GPL Julia?

Le vendredi 17 avril 2015 à 08:33 -0700, Scott Jones a écrit : > Yes, but I need a solution to keeping things GPL free (LGPL would be > fine) in the short-term (say, in the next 3-6 months maybe), not > long-term. > For anybody contemplating using Julia for commercial projects, this > seems like a

Re: [julia-users] Re: Non-GPL Julia?

Scott: to save anyone else the trouble of saying the same thing: the best way to achieve this will be to roll up your sleeves and help take care of it yourself. :-D Viral - I’m happy to try and spend some extra cycles getting Julia to compile with the Intel tool suite if that helps start to cut

Re: [julia-users] Re: Non-GPL Julia?

Yes, but I need a solution to keeping things GPL free (LGPL would be fine) in the short-term (say, in the next 3-6 months maybe), not long-term. For anybody contemplating using Julia for commercial projects, this seems like a critical issue... If there is some way of building a Julia executable

Re: [julia-users] Re: Non-GPL Julia?

Initially, our software would just be available as a service, and I do understand that that won't be a problem with the GPL, however, later on, it could be that we'd want to set up a server at a customer site or on customer hardware... which would probably count as "distribution"... I don't thin

Re: [julia-users] Re: Non-GPL Julia?

> > Packages blessed by julialang, to be sure, but perhaps separate from the > core. > Yes, there is a broad consensus that this will be the long-term direction. https://github.com/JuliaLang/julia/issues/5155 On Fri, Apr 17, 2015 at 11:08 AM, Sebastian Good < sebast...@palladiumconsulting.com> w

Re: [julia-users] Re: Non-GPL Julia?

Certainly the licensing is important from a commercial aspect, but I think this is also an interesting discussion from a  core vs packages perspective. Python is separate from numpy, but indeed no one is under the illusion that they should work against any other sort of array package. Core linea

Re: [julia-users] Re: Non-GPL Julia?

If you're not distributing Julia to anyone, then the GPL doesn't matter. If you are distributing Julia in some form, then it does matter and it will take some work and/or money to excise the GPL parts, which are FFTW, SUITESPARSE and RMath. Rmath is simple to remove since nothing in Julia itself de

[julia-users] Re: Non-GPL Julia?

I'd like to use Julia for a commercial project, and need to know just what we need to avoid to not have any problems with GPL. I'd much rather use Julia than say Python or C++ for various parts of the code, and have been having a great time learning/using Julia this last month since I first lear

Re: [julia-users] Re: Non-GPL Julia?

MKL contains Pardiso and a number of other sparse routines that can be quite useful and could be good alternatives to SuiteSparse (as well as providing some additional functionality that SuiteSparse does not have), but would of course need to have Julia bindings written for them. The API docume

Re: [julia-users] Re: Non-GPL Julia?

The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, it is straightforward to completely avoid using SuiteSparse. One of the things I want is to have a version of Julia built with Intel compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, LIBM, and FFT rout

Re: [julia-users] Re: Non-GPL Julia?

I recently annotated the license list to give myself (and others) a quick-look grasp of the license situation: https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df I agree with Tony that in the short-term, distributing a GPL-free binary ourselves is not a priority, b

[julia-users] Re: Non-GPL Julia?

It's certainly a long-term goal. 0.4 is far enough behind-schedule already that it's very unlikely to happen by then. Like most things in open source, it's limited by available labor. People who want to see it happen will need to help out if they want it to happen faster. For this particular iss

[julia-users] Re: Non-GPL Julia?

Is producing a non-GPL Julia build still on the radar? It might be a nice goal for the 0.4 release, even if we have to build it ourselves (e.g. against MKL, etc.) On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote: > > > > On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Kn

[julia-users] Re: Non-GPL Julia?

On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote: > > Yes this is awesome work you have done there. Do you plan to implement the > real-data FFT, DCT and DST in pure Julia also? Then one could really think > about moving FFTW into a package. Hopefully its author is ok with that ;-

[julia-users] Re: Non-GPL Julia?

Yes this is awesome work you have done there. Do you plan to implement the real-data FFT, DCT and DST in pure Julia also? Then one could really think about moving FFTW into a package. Hopefully its author is ok with that ;-) Am Montag, 21. April 2014 22:25:27 UTC+2 schrieb Steven G. Johnson: > >

[julia-users] Re: Non-GPL Julia?

On Thursday, April 10, 2014 3:16:12 PM UTC-4, Tobias Knopp wrote: > > should be fairly easy to use fftpack which has single and double precision > and is ok from the license. > I already have significantly better performance than FFTPACK in my pure-Julia FFT, as well as (in some ways [*]) sign

Re: [julia-users] Re: Non-GPL Julia?

On Thu, Apr 10, 2014 at 2:29 PM, Simon Kornblith wrote: > I'm not a lawyer either, but I don't think this is any more problematic than > the current situation with inclusion of Rmath etc. The combined work is GPL > (or LGPL, once we get rid of the GPL parts), but the vast majority of the > source

[julia-users] Re: Non-GPL Julia?

I think it helps to distinguish in the license discussion build dependencies and runtime dependencies. As far as I can see: - Core Julia, which consists of libjulia (statically linking libuv and llvm) and the repl, are MIT licensed - Base Julia has some GPL dependencies. But to get rid of them on

[julia-users] Re: Non-GPL Julia?

should be fairly easy to use fftpack which has single and double precision and is ok from the license. Am Donnerstag, 10. April 2014 21:10:25 UTC+2 schrieb Jay Kickliter: > > Thanks to everyone for the information. I guess it's fair to say a non-GPL > version is feasible and likely in the future

[julia-users] Re: Non-GPL Julia?

Thanks to everyone for the information. I guess it's fair to say a non-GPL version is feasible and likely in the future. I love the language myself and would continue using it myself regardless, but I wanted to clear this up before I start evangelizing it at work. I'm interested to hear more ab

Re: [julia-users] Re: Non-GPL Julia?

I'm not a lawyer either, but I don't think this is any more problematic than the current situation with inclusion of Rmath etc. The combined work is GPL (or LGPL, once we get rid of the GPL parts), but the vast majority of the source files are (also) MIT. This seems fine since MIT gives all of

Re: [julia-users] Re: Non-GPL Julia?

On 4/10/14, 12:31, Mike Nolta wrote: On Thu, Apr 10, 2014 at 11:07 AM, Tony Kelman wrote: MPFR and GMP are LGPL, which is not quite as problematic or viral. Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of the Julia code in base for sparse matrices that is based on pa

Re: [julia-users] Re: Non-GPL Julia?

On Thu, Apr 10, 2014 at 11:07 AM, Tony Kelman wrote: > MPFR and GMP are LGPL, which is not quite as problematic or viral. > > Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of > the Julia code in base for sparse matrices that is based on parts of > SuiteSparse is also LGPL

Re: [julia-users] Re: Non-GPL Julia?

MPFR and GMP are LGPL, which is not quite as problematic or viral. Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of the Julia code in base for sparse matrices that is based on parts of SuiteSparse is also LGPL. On Thursday, April 10, 2014 7:18:45 AM UTC-7, Jake Bolews

Re: [julia-users] Re: Non-GPL Julia?

Are there any more liberally licensed libraries that get close to the functionality in MPFR, I know that there are some non-GPL BigInt implementations out there although I don't think any match GMP's performance. On Thursday, April 10, 2014 10:13:20 AM UTC-4, Stefan Karpinski wrote: > > There's

Re: [julia-users] Re: Non-GPL Julia?

There's been a lot of talk about turning various bits of functionality like GMP, MPFR, FFTW and such into packages that simply happen to be pre-loaded by default, making it easy to get a much more spare basic Julia version. This will definitely happen over the summer. Note that OpenBLAS is BSD-lice

[julia-users] Re: Non-GPL Julia?

See also DISTRIBUTING.md. Any discussion should probably be summarized there. kl. 16:05:10 UTC+2 torsdag 10. april 2014 skrev Jake Bolewski følgende: > > As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary > pre

Re: [julia-users] Re: Non-GPL Julia?

Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski wrote: > As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary > precision floating points

[julia-users] Re: Non-GPL Julia?

As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 20