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.) >> >
