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 <t...@kelman.net> 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.) >>>> >>> >
