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 is on I'll be competent enough with the Julia environment to do so. (I'm looking forward to going to my old stomping grounds and and learning more about Julia in two months, just waiting for registration to open!) (I haven't been this excited about a language since learning Lisp and CLU!) Scott On Friday, April 17, 2015 at 11:38:47 AM UTC-4, 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] > <javascript:>) 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.) >>>>>>> >>>>>> >>>> >>
