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, build with make USE_GPL_LIBS=0, and you should get a non-GPL julia. Sebastian - I also just received some Intel licenses. The best place to bug is on the relevant github issues or create new ones. For example: https://github.com/JuliaLang/julia/issues/9145 -viral On Friday, April 17, 2015 at 9:08:47 PM UTC+5:30, Sebastian Good wrote: > > 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 the knot. I > have the licenses and it could be a useful way to learn a bit more about > the core. Who is the right person to bug as I figure that out? > > On April 17, 2015 at 11:33:51 AM, Scott Jones ([email protected]) > wrote: > > 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 without any of the GPL > code, that will still run as long as you don't use FFTW, SUITESPARSE, or > RMATH, > then that would be fine. > > It does seem that Julia has had the (mathematical) everything including > the kitchen sink thrown in (although decimal floating point is a surprising > omission), > and I hate to see that limiting its potential use because of licensing > issues... > > Scott > > On Friday, April 17, 2015 at 11:16:36 AM UTC-4, Isaiah wrote: >> >> 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 < >> [email protected]> wrote: >> >>> 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 linear algebra and array cleverness seems comfortable in Julia’s Base, >>> but with so many different kinds of users of Julia — even just considering >>> those doing math& science with it — things like solvers and sparse arrays >>> certainly feel like they could be in packages. Packages blessed by >>> julialang, to be sure, but perhaps separate from the core. >>> >>> On April 16, 2015 at 12:32:06 PM, Viral Shah ([email protected]) wrote: >>> >>> 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 routines. There is also a VML package for vector math >>> functions. The only big missing piece is sparse solvers - but perhaps that >>> is ok for people, who can use Intel's sparse solvers or MUMPS or something >>> else. >>> >>> -viral >>> >>> On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote: >>>> >>>> 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, but pull requests to make the >>>> situation >>>> clearer or to make a GPL-free build simpler would be fine. For example, >>>> there could be a NO_GPL Makefile variable, and a macro on the Julia side >>>> to >>>> annotate and selectively exclude GPL stuff from the system image (FFTW and >>>> Rmath should be, respectively, easy and very easy to exclude, however I'm >>>> not sure how deeply entangled the SuiteSparse stuff is). >>>> >>>> >>>> >>>> On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman <[email protected]> wrote: >>>> >>>>> 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 >>>>> issue of GPL dependencies, the most useful places to contribute would be >>>>> helping set up BinDeps for the forked Rmath-julia library so it does not >>>>> need to be built by base and Distributions.jl can still work well and be >>>>> easy to install, and asking on the "New DFT API" pull request whether >>>>> there >>>>> are specific areas where Steven Johnson needs help - likely answers are >>>>> benchmarking, conflict resolution to rebase to master, and setting up >>>>> FFTW >>>>> as a package with automatic BinDeps etc. >>>>> >>>>> Removing things from Base has proven difficult to do smoothly, and >>>>> while it will be necessary to slim down the mandatory runtime >>>>> dependencies >>>>> for embedding, static compilation, and less-restrictive licensing use >>>>> cases, a lot of work still needs to be done to figure out how to manage >>>>> code migrations in the least disruptive manner possible. I don't think >>>>> this >>>>> is the primary concern of any core Julia developers or contributors at >>>>> the >>>>> moment (in fact several people have said they would strongly prefer to >>>>> not >>>>> remove any other code from Base until after 0.4.0 is released, and I >>>>> agree >>>>> with that), but help and contributions are always welcome. >>>>> >>>>> >>>>> On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good >>>>> wrote: >>>>>> >>>>>> 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 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 ;-) >>>>>>>> >>>>>>> >>>>>>> I plan to implement real-data FFTs, and move FFTW into a package. >>>>>>> >>>>>>> Pure-Julia DCT and DST are not in my immediate plans (they are a >>>>>>> PITA to do right because there are 16 types, of which 8 are common); my >>>>>>> feeling is that the need for these is uncommon enough that it's not >>>>>>> terrible to have these in a package instead of in Base. (Hadamard >>>>>>> transforms and MDCTs are also currently in packages.) >>>>>>> >>>>>> >>>> >>
