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.
