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 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. I haven't seriously considered it, but it seems quite easy to remove all code using these libraries, as well as the handful of functions which were ported from SuiteSparse. You'll have to spend some time tracking the places where this code was called, but apart from tests there shouldn't be too many of them.
The long-term solution will require more work, but if you need a quick solution it should be OK. Regards > 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 > <seba...@palladiumconsulting.com> 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 > (vi...@mayin.org) 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 <to...@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.) > > > > > > > >
