Dear Scott, I don't understand this GPL discussion. If you want to use Julia in a commercial product you will have to think about deployment. I doubt that you want to use the regular Julia installers for that. At this point its about deleting two shared libraries (fftw and these sparse solvers). Thats it. The entire Julia code is GPL free.
When I would distribute a commercial Julia package I would further generate a custom system image where all the "commercial" code is compiled in. Regards, Tobi Am Freitag, 1. Mai 2015 16:35:53 UTC+2 schrieb Scott Jones: > > > > On Friday, May 1, 2015 at 12:10:32 AM UTC-4, Jeff Bezanson wrote: >> >> On Thu, Apr 30, 2015 at 5:26 PM, Scott Jones <[email protected]> >> wrote: >> > Maybe because it seems that a lot of the major packages have been put >> into >> > Base, so it isn't a problem, as MA Laforge pointed out, leading to Base >> > being incredibly large, >> >> That's absurd. There are 500 packages. We added Dates and...what else? >> We would like Base to be a bit smaller >> (https://github.com/JuliaLang/julia/issues/5155), but "incredibly >> large" is a bit of an overstatement. It's *nothing* compared to >> matlab's default namespace for example. >> > > 1) Anything with a GPL license... that is really nasty to anybody would > like to use Julia on a commercial project... > (I have nothing against GPL, I do like OSS, but I much prefer the way > the MIT license works, and don't have the luxury of being able to use GPL > software in what I do for a living... [use in the sense of using a library, > if it's not under the LGPL]... I *use* a lot of GPL'ed software, Emacs, > gcc, ...) > > 2) multimedia.jl, linalg.jl, statistics.jl, sparse.jl > [fftw.jl, dsp.jl - I know these are also under my above GPL list, but > if a non-GPLed alternative is found, I still think it doesn't need to be in > "Julia-lite"] > quadgk.jl, profile.jl, Dates.jl > > pkg.jl I'm not sure about... you'd need a way of loading it, to load other > packages, but... doesn't it use GPLed software, which could get people > using it into legal hot water? > > I'm not sure about: reducedlm.jl, combinatorics.jl, don't know what they > do, or how basic their functionality is... > > Also Markdown, I think there is a lot there that isn't needed just for > getting ? help documentation (or with @doc) at the terminal... > Anything not needed for @doc, I think should be optional, in a package. > > > > with stuff that means Julia's MIT license doesn't mean all that much, >> > because it includes GPL code by default... >> >> So the license of the entire compiler, runtime, and 90%+ of the >> standard library doesn't "mean much"? Ouch. >> In any case Viral started adding a flag to exclude GPL libs last week. >> The changes for that are tiny. >> > > Yes, and I'm very grateful to Viral, because otherwise we'd probably have > had to totally stop planning on using Julia... > However, I feel that the developers should be very careful to not let GPL > get into the base distribution... > (I think the default for 0.4 release should be without the GPL encumbered > parts) > > >> I'm still confused about MongoDB vs. TokuMX. In your last post about >> them you mentioned using them as drop-in replacements for each other. >> But before that you said they are competitors, and won't necessarily >> implement the same interface. If they have incompatible interfaces, >> how can they be drop-in replacements? I don't get it. >> > > Do you remember the lawsuits about Java vs. Microsoft's version of Java? > Or go look at the cringing README.md for the matlab compatibility package > for Julia... > Think about how AMD and Intel battled over extending the x86 instruction > set from 32-bits to 64... > Intel's approach was to introduce the Itanium chip... (real winner there! > ;-) We called it the Titanium chip... going down like the Titanic!) > AMD went and extended the x86 instruction set... then Intel went back and > introduced a new instruction set that was mostly compatible with the AMD > 64-bit instructions... > That is life outside of academia! > > TokuMX recreated the MongoDB's API... but that doesn't mean that > MongoDB's developers are going to stop adding new things (sometimes > precisely in an attempt to lock people into using MongoDB, make it harder > to switch to some other platform), or that TokuMX hasn't added it's own new > things. > I had a part in playing this sort of game for years... with multiple > vendors of an ANSI standard language, each adding their own extensions, > sometimes having those extensions copied by other competitors... > > Scott >
