To follow up from the previous post, I want to give a list of all the things that people have offered to contribute to the MPIR project from "outside" the project. I don't want to give the impression that absolutely no one is contributing anything new to MPIR:
* Jason Martin recently contributed some Itanium assembly functions to MPIR and has more to come. * A developer already contributed some code for binomial coefficients, factorial and root testing at the mpz level. * A developer promised to contribute some parallel code for factorial and double factorial computation. * A new developer, Antony Venard recently joined our team to work on a branch of MPIR for parallel (OpenMP) support. * A developer promised to write a unified interface between MPIR and a whole pile of languages. He has a whole lot of experience in this sort of thing. As far as I know, license was not an issue for any of these contributors. But it is early days. Perhaps in a few months the contributions will increase due to our new strategy. Certainly we will ourselves be able to work on more interesting code contributions. Bill. On 12 April 2010 12:55, Bill Hart <goodwillh...@googlemail.com> wrote: > Hi Pierre, > > Thanks very much for your questions and comments. I attempt to answer > them below based on my (limited) understanding at this point in time. > Others might be able to give more clear or helpful answers. > > On 12 April 2010 11:18, Pierre Joye <pierre....@gmail.com> wrote: >> hi, >> >> On Fri, Apr 9, 2010 at 2:55 PM, Bill Hart <goodwillh...@googlemail.com> >> wrote: >>> On 9 April 2010 13:23, Marc <marc.gli...@gmail.com> wrote: >>>> Hello, >>>> >>>> I am not sure I understand what is going on with MPIR. When the fork >>>> happened, 2 of the main stated goals where: >>>> 1) LGPL2 (required for sage+microsoft) >>>> --> MPIR is now LGPL3+ only >>> >>> Correct. Will this create any issues for you? >> >> What are the appealing reasons for this move given one of the initial >> arguments for mpir (gmp license changes)? > > The main appeal is that we can use code from GMP without replicating > their efforts and accept code from developers who want to license > their code v3+. It basically means less effort for us, and faster > development times. It means that the bignum community is using a > single license and is less fragmented. > >> >> Reading http://www.gnu.org/licenses/lgpl.html, I really wonder if this >> is a good move. I don't feel comfortable to add the GPL license to the >> PHP distribution (see the section 3b, 4b and 4c) as the PHP license is >> not compatible with the GPL. Things can get worst as we are testing >> mpir to be used with php engine for large integers related operations. >> > > I can definitely understand that concern. It could even be confusing > to some people who don't understand that having the GPL license in the > distribution doesn't mean that it can only be distributed under the > terms of the GPL. > > We will attempt to help out projects which definitely do not want to > use a v3+ MPIR: we will still port our bugfixes to MPIR 1.3.x which > will remain LGPL v2+. But new features will not be added to the > LGPLv2+ version (unless someone volunteers to maintain it and there > are sufficient LGPL v2+ code contributions to MPIR). > > Regarding the GPL, this is a more restrictive license than LGPL and > thus if your project is LGPL it is automatically compatible with the > GPL. In fact with version 3 of the license, the LGPL is just a set of > exceptions to the GPL. > > By "not compatible with the GPL", I assume you mean that you want to > distribute PHP under terms that are more permissive than the GPL will > allow. Of course this is absolutely fine as the LGPL gives precisely > these extra permissions. So long as you include both the GPL and LGPL > texts you can distribute under LGPL terms and are not restricted to > GPL terms only. It's a similar situation to what the old LGPL v2.1 > gave you. > >> I also have concerns about the legal aspects of the lgpl v3. I know >> that the v2 can be used safely but I've a bad feeling about the v3. > > Our position on version 3 of the (L)GPL is well documented, so I won't > add anything here. > > The reason we switched has nothing to do with the content of the > license, which we consider immaterial. It has everything to do with > making the project more developer friendly and contributing more to > the bignum community. It was wholly motivated by the very small > developer community we have, even after two years of working on MPIR, > and a desire to find ways of extending that community, or at least > increase the effectiveness of that community. > > We realise that a license switch is slightly less user friendly and > slightly more developer friendly. But as a matter of strategy, we > decided that the latter was preferable given our slow growth. > > The only other objections we've had so far are: > > * One prominent developer thinks tivoisation is a good thing and > doesn't like v3 for that reason, but said he could live with it. > > * I contacted Microsoft Research and an individual there commented > that they don't like v3, but if we back port bug fixes to MPIR 1.3 > (which remains v2+) it won't make life too impossible for them (they > want to use MPIR as a basis for Pari and Sage if I understand > correctly, both of which they use for mathematical research). > >> Does anyone have more in depth details about the actual changes >> between the two? > > There seem to be very few implications for Open Source projects. Most > of the changes seem to be directed at lawyers, big software companies > and the like. There's a whole pile of legalese on issues such as > patents, tivoisation, etc. > > A couple of important differences include (I am not a lawyer, this is > only what I've heard): > > * Make a "prominent notice" that the library is used by your software > (LGPL section 4a). > > * If you offer binaries for download somewhere you also have to give > equal access to the source for the library from the same location. See > section 6 of the GPL for more details on this fairly complex set of > rules. Don't ask me what they mean. I don't know either. > > * Effectively you have to make it so that anyone can remove the > library and link in their own version if they want. (LGPL section 4d). > > * There are some minimal requirements with regard to documenting how > to build the library (LGPL section 4e). But I've seen this abused, > with people including the requisite files but filling them with > nonsense. Despite fulfilling the legal requirements, this extra > information was completely worthless. > > * You have to include the text of the GPL with any software that > includes the library as the LGPL is now a set of exceptions to the GPL > rather than a separate license (LGPL section 4b). > > * You can't use any code which was LGPL v2 *only*. All the code must > have been licensed LGPL v2.1+ (or LGPL v3+). Of course that was > already a condition for any project which was overall LGPL v2+. I > think there are few if any mathematical projects still around which > are LGPL or GPL v2 only. > > PHP is a pretty important customer for us. So please do keep us > informed on how this decision will affect you. And note that no final > decision has been made at this point as to whether MPIR will switch > permanently. It depends on the feedback we receive from the community > about the proposed switch. We can always go back to MPIR 1.3 and keep > developing in a completely independent way as LGPL v2+. However > development will be slower, especially if the development community > continues to remain small. > > The only other option we considered was to start a completely new > library from scratch which is much simpler. The biggest issue for > people to volunteer to contribute to MPIR is the complexity of the > project. A simpler project may attract "new blood". I wrote a pile of > such code for integer multiplication (which I've not released). But > the performance was bad (10-15% slower than MPIR) and that was even > after linking against the MPIR assembly code. It was more like 50% > slower if I didn't do this. This is always going to be an issue in any > simpler project. Performance seems to mandate complexity. Also, > eventually simple projects grow up, and they become more complex. > > Bill. > >> >> Cheers, >> -- >> Pierre >> >> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> To post to this group, send email to mpir-de...@googlegroups.com. >> To unsubscribe from this group, send email to >> mpir-devel+unsubscr...@googlegroups.com. >> 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 mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
