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.
