What you suggest is to effectively maintain two versions of MPIR, one version 2.1 the other 3. We did consider such an option, but it is much harder than it seems, and we simply don't have sufficiently many contributors to manage that, whereas there seems to be a lot of interest in contributing to a BSD licensed library. Another individual I asked about this said they thought it was a great idea and that one of the main things that puts them off currently is the LGPL. They can't contribute to a BSD licensed library in the short term, but perhaps in a year or so they may.
So that is 7 potential regular and talented developers for a BSD licensed library. We probably have 7 contributors for an LGPL license if we include the GMP regular contributors in that count. But I think we will easily exceed this number with a BSD license. If I turn out to be wrong about that, we will have to do something like what you suggest. Bill. On 16 April 2010 08:36, Sergey Bochkanov <[email protected]> wrote: > Hello, Mpir-devel. > > I've read discussion about future of LGPL-licensed MPIR, and about new > BSD-licensed library. May be there is much more simpler solution to > the LGPL 3 issue than making new library. > > As far as I can see, all updates may be divided into two distinct > groups: > * bugfixes > * improved algorithms - but with the same functionality as in the > previous version of the library. There were no NEW functions in > several previous releases. > > Bugfixes are relatively easy to implement in LGPL 2. But what with > these new algorithms? > > The only difference from old ones is performance, I think. But how > large is this difference? In the mpn layer, I think, it can't be VERY > large. 10% faster - very likely. 50% faster - possible. 300% faster - > unlikely. > > I know that performance is like Holy Grail for bignum community (and > for linear algebra community too). But it isn't the only important > factor. Other important factors are: > * functionality (fast, but without functions you need = useless) > * license questions (if you are the only library with LGPL 2.1 code, > you will have your share of users even with moderate performance) > * ease of use (if I were to choose between 1 hour of my time spent > studying unfamiliar build environment and 3 hours of CPU time lost > with slower library, I'd choose slower library - I can read a book > while CPU is glowing hot). > * support by community. There are a lot of bignum libraries around, > but they aren't supported anymore, and no one want to use them just > because of that. > > So, I propose to: > * separate MPIR sources into two groups - 2.1-licensed and > 3.0-licensed, but hold them together within one distribution. > * implement every algorithm in 2.1-licensed code. You still have a lot > of fast 2.1-licensed code. > * use 3.0 licensed code when you have it, but it should be treated as > addition to 2.1 codebase, but not as the main implementation. > * build MPIR either as LGPL 2.1 or 3.0 licensed library. In the first > case only 2.1 code is used, in the second case build system > overrides 2.1-licensed algorithms with 3.0 licensed files. > > In such case you can have: > * good enough implementations for those who needs LGPL 2.1 > * state-of-the-art implementations for those who happy with LGPL 3 > * one library instead of "New MPIR" and "Old-but-still-supported-MPIR" > * easy support - you don't have to support two branches anymore > > What do you think about such idea? > > -- > With best regards, > Sergey mailto:[email protected] > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
