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.net<javascript:>> 
> 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. 
> >>>> 
> >>>> 
> >>> 
> > 
>

Reply via email to