Re: [julia-users] Re: Non-GPL Julia?
Thanks Viral On Sunday, April 19, 2015 at 10:05:23 AM UTC-6, Viral Shah wrote: And it is merged now. On Saturday, April 18, 2015 at 4:22:26 PM UTC+5:30, Scott Jones wrote: That's great! That solves our dilemma for us! Scott
Re: [julia-users] Re: Non-GPL Julia?
+1 On April 20, 2015 at 9:18:10 AM, Jay Kickliter (jay.kickli...@gmail.com) wrote: Thanks Viral On Sunday, April 19, 2015 at 10:05:23 AM UTC-6, Viral Shah wrote: And it is merged now. On Saturday, April 18, 2015 at 4:22:26 PM UTC+5:30, Scott Jones wrote: That's great! That solves our dilemma for us! Scott
Re: [julia-users] Re: Non-GPL Julia?
And it is merged now. On Saturday, April 18, 2015 at 4:22:26 PM UTC+5:30, Scott Jones wrote: That's great! That solves our dilemma for us! Scott
Re: [julia-users] Re: Non-GPL Julia?
That's great! That solves our dilemma for us! Scott
Re: [julia-users] Re: Non-GPL Julia?
Non-GPL julia, when this PR is merged. https://github.com/JuliaLang/julia/pull/10870 The mac and windows installers we distribute will still be GPL due to git and busybox (although technically I don't think Julia can be considered as a derivative work here). If you are building from source, build with make USE_GPL_LIBS=0, and you should get a non-GPL julia. Sebastian - I also just received some Intel licenses. The best place to bug is on the relevant github issues or create new ones. For example: https://github.com/JuliaLang/julia/issues/9145 -viral On Friday, April 17, 2015 at 9:08:47 PM UTC+5:30, 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 (scott.paul.jo...@gmail.com) 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 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
Re: [julia-users] Re: Non-GPL Julia?
If you're not distributing Julia to anyone, then the GPL doesn't matter. If you are distributing Julia in some form, then it does matter and it will take some work and/or money to excise the GPL parts, which are FFTW, SUITESPARSE and RMath. Rmath is simple to remove since nothing in Julia itself depends on it – arguably, you don't even need to remove it since Julia is not actually a derived work of Rmath, we simply bundle the library. (If you use Distrubutions, however, then that program is a derived work and would have to be GPL; work is ongoing to remove the Rmath dependency.) It is possible to purchase commercial licenses for both FFTW and SUITESPARSE, but I don't know how much they cost. On Fri, Apr 17, 2015 at 9:36 AM, Scott Jones scott.paul.jo...@gmail.com wrote: I'd like to use Julia for a commercial project, and need to know just what we need to avoid to not have any problems with GPL. I'd much rather use Julia than say Python or C++ for various parts of the code, and have been having a great time learning/using Julia this last month since I first learned about it, and I'd hate to see this not be possible because of the GPL... (and I'm not even using it for fancy math ;-), I just love its speed, extensibility, ease of use with the REPL, and easy interface to C). Thanks, Scott On Thursday, April 10, 2014 at 3:46:54 PM UTC-4, Tobias Knopp wrote: I think it helps to distinguish in the license discussion build dependencies and runtime dependencies. As far as I can see: - Core Julia, which consists of libjulia (statically linking libuv and llvm) and the repl, are MIT licensed - Base Julia has some GPL dependencies. But to get rid of them one just has to remove the shared library and of course not use the functionality. It seems only fftw and SuiteSparse are runtime GPL dependencies. Am Donnerstag, 10. April 2014 15:26:55 UTC+2 schrieb Jay Kickliter: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
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 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.)
Re: [julia-users] Re: Non-GPL Julia?
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 sebast...@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 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.)
Re: [julia-users] Re: Non-GPL Julia?
Initially, our software would just be available as a service, and I do understand that that won't be a problem with the GPL, however, later on, it could be that we'd want to set up a server at a customer site or on customer hardware... which would probably count as distribution... I don't think we need any of FFTW, SUITESPARSE, or RMATH anyway... Julia is such a nice language, for lots of things besides just math science, it *really* would be great to have a version of Julia with any GPL stuff as packages... as Sebastian Good just suggested.. Right now, it seems to be the main obstacle to using the language for lots of things... Thanks, Scott On Friday, April 17, 2015 at 10:36:26 AM UTC-4, Stefan Karpinski wrote: If you're not distributing Julia to anyone, then the GPL doesn't matter. If you are distributing Julia in some form, then it does matter and it will take some work and/or money to excise the GPL parts, which are FFTW, SUITESPARSE and RMath. Rmath is simple to remove since nothing in Julia itself depends on it – arguably, you don't even need to remove it since Julia is not actually a derived work of Rmath, we simply bundle the library. (If you use Distrubutions, however, then that program is a derived work and would have to be GPL; work is ongoing to remove the Rmath dependency.) It is possible to purchase commercial licenses for both FFTW and SUITESPARSE, but I don't know how much they cost. On Fri, Apr 17, 2015 at 9:36 AM, Scott Jones scott.pa...@gmail.com javascript: wrote: I'd like to use Julia for a commercial project, and need to know just what we need to avoid to not have any problems with GPL. I'd much rather use Julia than say Python or C++ for various parts of the code, and have been having a great time learning/using Julia this last month since I first learned about it, and I'd hate to see this not be possible because of the GPL... (and I'm not even using it for fancy math ;-), I just love its speed, extensibility, ease of use with the REPL, and easy interface to C). Thanks, Scott On Thursday, April 10, 2014 at 3:46:54 PM UTC-4, Tobias Knopp wrote: I think it helps to distinguish in the license discussion build dependencies and runtime dependencies. As far as I can see: - Core Julia, which consists of libjulia (statically linking libuv and llvm) and the repl, are MIT licensed - Base Julia has some GPL dependencies. But to get rid of them one just has to remove the shared library and of course not use the functionality. It seems only fftw and SuiteSparse are runtime GPL dependencies. Am Donnerstag, 10. April 2014 15:26:55 UTC+2 schrieb Jay Kickliter: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
Is that available for non-Intel platforms? Given it is from Intel, I would be surprised... More importantly, it doesn't seem to support arbitrary precision decimal floating point, which the decNumber package does, just the 3 new IEEE formats (32-bit, 64-bit, 128-bit), which the decNumber package has. If it performs much better, it might be interesting to make a package that used the Intel library optionally on Intel platforms (if it is restricted to Intel) for the 3 IEEE formats, and use the decNumber package (which was written originally by Mike Cowlishaw, whose decimal arithmetic specification is at the heart of the new IEEE decimal floating point standard) Scott On Friday, April 17, 2015 at 12:45:14 PM UTC-4, Steven G. Johnson wrote: On Friday, April 17, 2015 at 12:03:43 PM UTC-4, Scott Jones wrote: (and also to help adding a decimal float package using decNumber, which is under the ICU license Why not the Intel library https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library It's under 3-clause BSD.
Re: [julia-users] Re: Non-GPL Julia?
Thanks. I still haven't tried building Julia, I've just been using the Mac and Ubuntu release and nightly builds, but I'll start looking into that... Scott On Friday, April 17, 2015 at 11:51:34 AM UTC-4, Milan Bouchet-Valat wrote: 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
Re: [julia-users] Re: Non-GPL Julia?
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
Re: [julia-users] Re: Non-GPL Julia?
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 (scott.pa...@gmail.com 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 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
Re: [julia-users] Re: Non-GPL Julia?
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 (scott.paul.jo...@gmail.com) 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 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
Re: [julia-users] Re: Non-GPL Julia?
On Friday, April 17, 2015 at 12:03:43 PM UTC-4, Scott Jones wrote: (and also to help adding a decimal float package using decNumber, which is under the ICU license Why not the Intel library https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library It's under 3-clause BSD.
Re: [julia-users] Re: Non-GPL Julia?
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.)
Re: [julia-users] Re: Non-GPL Julia?
MKL contains Pardiso and a number of other sparse routines that can be quite useful and could be good alternatives to SuiteSparse (as well as providing some additional functionality that SuiteSparse does not have), but would of course need to have Julia bindings written for them. The API documentation for MKL is quite comprehensive so I don't expect this would be all that challenging, but work still needs to be done on the sparse linear algebra functionality in base to make things more flexible so you could easily swap out different backend solver libraries. The situation is a bit more complicated than with swapping out different dense Blas/Lapack implementations where the API's are standardized. On Thursday, April 16, 2015 at 9:32:01 AM UTC-7, Viral Shah 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 javascript: 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.)
Re: [julia-users] Re: Non-GPL Julia?
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.)
Re: [julia-users] Re: Non-GPL Julia?
Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski jakebolew...@gmail.comwrote: As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 2014 9:26:55 AM UTC-4, Jay Kickliter wrote: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
There's been a lot of talk about turning various bits of functionality like GMP, MPFR, FFTW and such into packages that simply happen to be pre-loaded by default, making it easy to get a much more spare basic Julia version. This will definitely happen over the summer. Note that OpenBLAS is BSD-license, so using MKL is not necessary for non-GPL Julia. On Thu, Apr 10, 2014 at 10:07 AM, Isaiah Norton isaiah.nor...@gmail.comwrote: Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski jakebolew...@gmail.comwrote: As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 2014 9:26:55 AM UTC-4, Jay Kickliter wrote: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
Are there any more liberally licensed libraries that get close to the functionality in MPFR, I know that there are some non-GPL BigInt implementations out there although I don't think any match GMP's performance. On Thursday, April 10, 2014 10:13:20 AM UTC-4, Stefan Karpinski wrote: There's been a lot of talk about turning various bits of functionality like GMP, MPFR, FFTW and such into packages that simply happen to be pre-loaded by default, making it easy to get a much more spare basic Julia version. This will definitely happen over the summer. Note that OpenBLAS is BSD-license, so using MKL is not necessary for non-GPL Julia. On Thu, Apr 10, 2014 at 10:07 AM, Isaiah Norton isaiah...@gmail.comjavascript: wrote: Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski jakebo...@gmail.comjavascript: wrote: As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 2014 9:26:55 AM UTC-4, Jay Kickliter wrote: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
MPFR and GMP are LGPL, which is not quite as problematic or viral. Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of the Julia code in base for sparse matrices that is based on parts of SuiteSparse is also LGPL. On Thursday, April 10, 2014 7:18:45 AM UTC-7, Jake Bolewski wrote: Are there any more liberally licensed libraries that get close to the functionality in MPFR, I know that there are some non-GPL BigInt implementations out there although I don't think any match GMP's performance. On Thursday, April 10, 2014 10:13:20 AM UTC-4, Stefan Karpinski wrote: There's been a lot of talk about turning various bits of functionality like GMP, MPFR, FFTW and such into packages that simply happen to be pre-loaded by default, making it easy to get a much more spare basic Julia version. This will definitely happen over the summer. Note that OpenBLAS is BSD-license, so using MKL is not necessary for non-GPL Julia. On Thu, Apr 10, 2014 at 10:07 AM, Isaiah Norton isaiah...@gmail.comwrote: Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski jakebo...@gmail.comwrote: As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 2014 9:26:55 AM UTC-4, Jay Kickliter wrote: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
On Thu, Apr 10, 2014 at 11:07 AM, Tony Kelman t...@kelman.net wrote: MPFR and GMP are LGPL, which is not quite as problematic or viral. Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of the Julia code in base for sparse matrices that is based on parts of SuiteSparse is also LGPL. IANAL, but doesn't this mean we've crossed the line from work that uses the library to derivative work, and thus are in violation of the LGPL? Specifically, this part of section (2): These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. -Mike On Thursday, April 10, 2014 7:18:45 AM UTC-7, Jake Bolewski wrote: Are there any more liberally licensed libraries that get close to the functionality in MPFR, I know that there are some non-GPL BigInt implementations out there although I don't think any match GMP's performance. On Thursday, April 10, 2014 10:13:20 AM UTC-4, Stefan Karpinski wrote: There's been a lot of talk about turning various bits of functionality like GMP, MPFR, FFTW and such into packages that simply happen to be pre-loaded by default, making it easy to get a much more spare basic Julia version. This will definitely happen over the summer. Note that OpenBLAS is BSD-license, so using MKL is not necessary for non-GPL Julia. On Thu, Apr 10, 2014 at 10:07 AM, Isaiah Norton isaiah...@gmail.com wrote: Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski jakebo...@gmail.com wrote: As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 2014 9:26:55 AM UTC-4, Jay Kickliter wrote: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
Re: [julia-users] Re: Non-GPL Julia?
On 4/10/14, 12:31, Mike Nolta wrote: On Thu, Apr 10, 2014 at 11:07 AM, Tony Kelman t...@kelman.net wrote: MPFR and GMP are LGPL, which is not quite as problematic or viral. Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of the Julia code in base for sparse matrices that is based on parts of SuiteSparse is also LGPL. IANAL, but doesn't this mean we've crossed the line from work that uses the library to derivative work, and thus are in violation of the LGPL? Specifically, this part of section (2): These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. (apologies if my post gets to the list twice---I just subscribed and tried to post through gmane, but that seems to not be working...) If LGPL is a problem, then you might keep your eye on bsdnt for a bignum library: https://github.com/wbhart/bsdnt. Bill Hart is/was one of the main guys behind MPIR [1]. This project isn't up GMP speed (yet), but getting close is an eventual goal (see https://groups.google.com/d/msg/bsdnt-devel/_1A2vMeUFSQ/946CBtez3XYJ, which compares the philosophies behind bsdnt and gmp: [bsdnt is] essentially targeting programming languages that for whatever reason don't yet have bignums or don't want to use GMP.) Thanks, Jason Grout [1] MPIR, a fork of GMP, may also be another thing to look at: http://www.mpir.org/ We switched Sage to using it instead of GMP a while ago.
Re: [julia-users] Re: Non-GPL Julia?
I'm not a lawyer either, but I don't think this is any more problematic than the current situation with inclusion of Rmath etc. The combined work is GPL (or LGPL, once we get rid of the GPL parts), but the vast majority of the source files are (also) MIT. This seems fine since MIT gives all of the permissions of (L)GPL and then some, and just because an author licenses something as (L)GPL doesn't mean that author can't also make that file available under another license. On Thursday, April 10, 2014 1:31:24 PM UTC-4, Mike Nolta wrote: On Thu, Apr 10, 2014 at 11:07 AM, Tony Kelman to...@kelman.netjavascript: wrote: MPFR and GMP are LGPL, which is not quite as problematic or viral. Some of SuiteSparse is GPL, parts of it are LGPL, and at least one file of the Julia code in base for sparse matrices that is based on parts of SuiteSparse is also LGPL. IANAL, but doesn't this mean we've crossed the line from work that uses the library to derivative work, and thus are in violation of the LGPL? Specifically, this part of section (2): These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. -Mike On Thursday, April 10, 2014 7:18:45 AM UTC-7, Jake Bolewski wrote: Are there any more liberally licensed libraries that get close to the functionality in MPFR, I know that there are some non-GPL BigInt implementations out there although I don't think any match GMP's performance. On Thursday, April 10, 2014 10:13:20 AM UTC-4, Stefan Karpinski wrote: There's been a lot of talk about turning various bits of functionality like GMP, MPFR, FFTW and such into packages that simply happen to be pre-loaded by default, making it easy to get a much more spare basic Julia version. This will definitely happen over the summer. Note that OpenBLAS is BSD-license, so using MKL is not necessary for non-GPL Julia. On Thu, Apr 10, 2014 at 10:07 AM, Isaiah Norton isaiah...@gmail.com wrote: Rmath too, but I think that is on the way out. All of the licenses are linked here: https://github.com/JuliaLang/julia/blob/master/LICENSE.md On Thu, Apr 10, 2014 at 10:05 AM, Jake Bolewski jakebo...@gmail.com wrote: As readline is now removed I think GMP (BigInt's) and MPFR (arbitrary precision floating points) are the only GNU ibraries left if you are able to use MKL and don't require FFTW. Steven also working on a branch where he provides FFT support in pure julia. Best, Jake On Thursday, April 10, 2014 9:26:55 AM UTC-4, Jay Kickliter wrote: There are bits and pieces in Github issues and posts, but can post a definitive list of what needs to be replaced/removed to make Julia non GPL? Will any functionality be missing? From what I understand I can use MKL for some stuff. I've read that MKL has the ability to mimic FFTW, but will Julia use that interface? For the record I'm not anti-GPL. I'd like to pitch Julia to my company as alternative to Matlab and C++. But our customers can't accept a project built with GPL. It's not a problem now, but I'm looking down the road when Julia can be compiled in to executables.
