MPIR Announcement

[MPIR Team]

Dear All,

Despite our recent April Fools prank:

http://groups.google.com/group/sage-devel/browse_thread/thread/d2777413749f37e5

the MPIR developers have actually been considering a switch to an LGPL v3+

license for a while, for the following reasons:

1) Maintaining GMP interface compatibility - a major requirement for MPIR users -
without moving to an LGPL v3 license would involve a significant, ongoing and
wasteful effort in duplicating code that has already been written. This would
seriously undermine more productive investments in code development that

we hope to make.

2) It is desirable that MPIR is able to incorporate high quality code from
developers who are committed to v3 licensing. For example, the first rate
toom8h code written by Marco Bodrato would not be available for use in
MPIR without a major and costly rewrite.

3) There is a danger that staying with a v2 license when others in the bignum
community are moving to LGPL/GPL v3 will merely contribute to community 

fragmentation.

There are of course also disadvantages in that some developers dislike the
political aspects of v3 licensing and some companies have decided not to use
any v3 licensed code.  But given the limited development effort available to
us, we believe the ability to easily maintain GMP interface compatibility, the
ability to incorporate high quality LGPL v3 licensed code, the avoidance of
a wasteful duplication of development effort and additional time to put more effort 

into the improvements that we have been contributing, combine to make a move 

to an  LGPL v3 license seem worthwhile in practice.

Accordingly we have now developed an LGPL v3+ version of MPIR, based on selectively
using code from the GMP project where we consider it to be of high quality. We have
not adopted all GMP speed improvements though as we have it in mind to pursue
different strategies in some areas which should ultimately see much more significant 

gains.  

Moreover this release includes new code developments of our own.  In this release we 

have concentrated effort on speed improvements in multiplication and division with a 

focus on the creation of a basis for future performance improvements in division and 

elsewhere. 

We also have speedups in the root code, string input/output and gcd/gcdext by 

selective use of code from GMP. There are also dramatic performance improvements

in the Itanium assembly code made possible by mixing code from GMP and a little bit

of new code by Jason Martin.

Our first release candidate is available for testing at:

http://www.mpir.org/mpir-2.0.0-rc1.tar.gz

Documentation is here:

http://www.mpir.org/mpir-2.0.0.pdf

See the files AUTHORS and NEWS for details of all the improvements and
who they were written by. Our website will be updated with full credits and

details as usual once testing of the release is complete.

MPIR 2.0.0 is near to 100% compatible with the published interface of GMP 5.0.1
(some minor exceptions exist, such as the lack of support for secure

cryptographic functions which we believe are not appropriate for MPIR).

We'd be grateful for any and all feedback on this release. (We also need someone
with an i7 to do some tuning for us - it only takes a few minutes; can someone help?).

Before switching license permanently, we decided to consult with numerous
individuals in the bignum community privately by email. All responses so far
have been encouraging and positive. We also wish to consult publicly, now 

that we have a first offering available.

So how would this affect your projects? Are there any reasons we should not
change license permanently?

We think that the benefits of our planned change outweigh the disadvantages.
What do you think? We are interested to hear your opinion.

Best Wishes,

The MPIR Team

[Antony Vennard]

Oh, so *this* is the real announcement! :D

On a more serious note, my comments from last time still stand - I'm not
sure about the political necessity of some features of the v3 licenses,
but they still protect the essentials of open source (I've reviewed them
more closely since the joke I took too seriously...) and that's fine by
me. One developer not put off contributing by this.

Antony

> --
> You received this message because you are subscribed to the Google
> Groups "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.

[Bill Hart]

Great! Once again, welcome on board!

Bill.

[Bill Hart]

I've updated the website with rc1, including what I think is the
current testing status.

Please notify of any omissions, corrections or otherwise.

Also, if anyone can help fill out the testing matrix, please let us know.

Bill.

[Jason Moxham]

On Wednesday 07 April 2010 23:06:30 Bill Hart wrote:
> I've updated the website with rc1, including what I think is the
> current testing status.
>
> Please notify of any omissions, corrections or otherwise.
>
> Also, if anyone can help fill out the testing matrix, please let us know.
>
> Bill.

creating t-dc_bdiv_q
make[4]: Leaving directory `/root/sourcecode/box1/tests/mpn'
make check-TESTS
make[4]: Entering directory `/root/sourcecode/box1/tests/mpn'
PASS: t-asmtype
PASS: t-aors_1
PASS: t-divrem_1
PASS: t-fat
PASS: t-get_d
PASS: t-instrument
PASS: t-iord_u
PASS: t-mulmid
PASS: t-mp_bases
PASS: t-perfsqr
PASS: t-scan
PASS: t-lorrshift1
PASS: t-divebyff
PASS: t-addadd_n
PASS: t-addsub_n
PASS: t-subadd_n
PASS: t-redc_basecase
PASS: t-divebyBm1of
PASS: t-mullowhigh
PASS: t-mullow_basecase
PASS: t-neg
PASS: t-mulmod_2expp1
PASS: t-mulmod_2expm1
PASS: t-tdiv_q
PASS: t-sb_divappr_q
PASS: t-dc_divappr_q_n
PASS: t-inv_divappr_q_n
PASS: t-invert
PASS: t-sb_div_q
PASS: t-sb_div_qr
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22232 Aborted ${dir}$tst
FAIL: t-dc_div_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22257 Aborted ${dir}$tst
FAIL: t-dc_div_qr
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22282 Aborted ${dir}$tst
FAIL: t-dc_divappr_q
PASS: t-dc_div_qr_n
PASS: t-inv_divappr_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22353 Aborted ${dir}$tst
FAIL: t-inv_div_q
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22380 Aborted ${dir}$tst
FAIL: t-inv_div_qr
PASS: t-inv_div_qr_n
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22430 Aborted ${dir}$tst
FAIL: t-tdiv_qr
PASS: t-sb_bdiv_q
PASS: t-sb_bdiv_qr
PASS: t-dc_bdiv_q_n
PASS: t-dc_bdiv_qr_n
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22547 Aborted ${dir}$tst
FAIL: t-dc_bdiv_qr
toom8h_mul.c:84: GNU MP assertion failed: bn >= 86
/bin/sh: line 4: 22572 Aborted ${dir}$tst
FAIL: t-dc_bdiv_q
PASS: st_fat
PASS: st_instrument
=============================================================
8 of 47 tests failed
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/root/sourcecode/box1/tests/mpn'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/root/sourcecode/box1/tests/mpn'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/root/sourcecode/box1/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/root/sourcecode/box1'
make: *** [check] Error 2
box1

PASSED CC=gcc CXX=g++ configure=
PASSED CC=gcc CXX=g++ configure=--enable-cxx --enable-gmpcompat
FAILED CC=gcc CXX=g++ configure=--enable-cxx --enable-gmpcompat --enable-assert
--enable-alloca=debug

This is on linux atom 64 bit gcc 4.3.3

[Jason Moxham]

On Wednesday 07 April 2010 23:06:30 Bill Hart wrote:

> I've updated the website with rc1, including what I think is the
> current testing status.
>
> Please notify of any omissions, corrections or otherwise.
>
> Also, if anyone can help fill out the testing matrix, please let us know.
>
> Bill.
>

linux 32bit k7 passes make check for many options

[Bill Hart]

Have you tuned for that platform? I think once it is tuned it should be fine.

Bill.

[Jason Moxham]

Yeah , I tuned it after all the changes , I'll try it again to see what
happens

[Bill Hart]

Unless for some reason the toom8 threshold is less than 86 on Atom. I
highly doubt it. but worth checking. Anyhow I thought we added code to
disallow that.

Bill.

[Bill Hart]

If you could add the tuning values to svn too, that would be great. We
don't currently have them.

Bill.

[Jason Moxham]

On Thursday 08 April 2010 22:49:06 Bill Hart wrote:
> Unless for some reason the toom8 threshold is less than 86 on Atom. I
> highly doubt it. but worth checking. Anyhow I thought we added code to
> disallow that.
>
> Bill.

Yes , thats what I thought , I've retuned it , and with the new set of params
it passes .

[Jason Moxham]

Done

[Bill Hart]

Great. If you commit the vals to svn I'll update and issue an rc2.

I'll also add in the GMP 1 defines.

Not sure what to do with gmp_randinit though. It's not exactly the
same thing to do what I had above. Is the old function still in MPIR
or was the code itself removed?

Bill.

[Marc]

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
2) a more open development process
--> the public svn repository has been unavailable for months, the
public mailing lists almost didn't see any traffic for that same
period, and out of nowhere appears a new major release of MPIR.

This is not a criticism, just noticing.

Also, since you went back to considering GMP as upstream, I expect you
will try to contribute relevant code there and only maintain in MPIR
the code you find interesting and GMP hasn't integrated.

[Bill Hart]

On 9 April 2010 13:23, Marc <marc....@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?

> 2) a more open development process
> --> the public svn repository has been unavailable for months, the
> public mailing lists almost didn't see any traffic for that same
> period, and out of nowhere appears a new major release of MPIR.

Agreed. Of course the majority of the code being merged was already
public, being available in GMP.

>
> This is not a criticism, just noticing.
>
> Also, since you went back to considering GMP as upstream, I expect you
> will try to contribute relevant code there and only maintain in MPIR
> the code you find interesting and GMP hasn't integrated.
>

It's Open Source. They can, and always have been able to use whatever they want.

[Bill Hart]

Whoops, I nearly forgot.

The svn had to be moved as we had problems at the original location.

Here is the new address:

http://boxen.math.washington.edu/svn/mpir/mpir/

Thanks again to William Stein for hosting this for us!

Bill.

[Pierre Joye]

hi,

On Fri, Apr 9, 2010 at 2:55 PM, Bill Hart <goodwi...@googlemail.com> wrote:
> On 9 April 2010 13:23, Marc <marc....@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)?

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 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.
Does anyone have more in depth details about the actual changes
between the two?

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

[Bill Hart]

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 <pierr...@gmail.com> wrote:
> hi,
>
> On Fri, Apr 9, 2010 at 2:55 PM, Bill Hart <goodwi...@googlemail.com> wrote:
>> On 9 April 2010 13:23, Marc <marc....@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
>

[Cactus]

On Apr 12, 11:18 am, 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)?

In my view the main reasons for doing this are:

(a) many developers of cutting edge multiple precision
algorithms have decided to publish code with a v3+
license
(b) the majority of MPIR users want 'drop in'
compatibility with GMP, which has an LGPL
v3+ license.

To meet these needs while keeping a v2+ license would require
a massive ongoing development effort to re-implement v3+ code
with a v2+ license.

Since there is no relaistic prospect of such development effort
being found, we either have to move to an LGPL v3+ license or
stay with v2+ and accept that MPIR will not be GMP compatible
and will not have the cutting edge performance offerred by v3+
developers.

> Readinghttp://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.

It's not ideal - I would call this license change 'the least worst
option'.

In short, continuing to offer a state of the art LGPL v2+ licensed
multiple precision library will require a large increase in the
MPIR developer community.

> 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.
> Does anyone have more in depth details about the actual changes
> between the two?

This seems to be a difficult issue with lawyers in different
organisations taking different views.

I know of companies who intend to use LGPL v3+ licensed code in
commercial software products without the latter becoming subject
to GPL licensing. But I also know of companies who think this is
not possible.

Brian

[Bill Hart]

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.

[Bill Hart]

Yes, I can independently confirm that come companies are extremely
suspicious of the motivations.

In fact, I recently thought very hard about whether I should
personally be licensing all my code contributions with an MIT or BSD
license. The reason is that companies can use this for whatever they
please and then have a big incentive to fund such work. (I don't need
funding personally, but I know numerous people who could work full
time on MPIR if only they could be funded to do it.)

I haven't been able to bring myself to actually make such a radical
change. The issue is that there is a history of companies in my field
(mathematics) of taking mathematical code and making it closed source
so that we cannot learn from their research. Of course if GMP and MPIR
had been GPL and not LGPL right from the start, then this could never
have happened.

However, funding of Open Source work remains a huge problem. I
recently took a very close look at the model the Haiku operating
system is using to fund their contributors. They use an MIT license.

Of course MPIR *cannot* switch to a more permissive license, as it is
based on GMP. So this is a completely separate issue though related
issue.

It seems to me we have the worst of all worlds. We aren't funded, due
to our code being regarded with suspicion by companies who fear we are
trying to destroy them. And at the same time companies are free to
build their closed source products on top of our Open Source library.
Some (not all) of those companies, could definitely afford to fund a
project like MPIR, but wont.

Bill.

>   Brian

[Cactus]

On Apr 12, 1:18 pm, Bill Hart <goodwillh...@googlemail.com> wrote:

In my view GMP and MPIR are a total mess in software engineering terms
and I would hence like nothing beeter than to participate in the
development of a new, well structured multiple precision library under
aa open source license that provided for commercial use.

The number of comapnies who could benefit from this is very large and
the individual cost would be small but we have no obvious way of
orchestrating this.

> It seems to me we have the worst of all worlds. We aren't funded, due
> to our code being regarded with suspicion by companies who fear we are
> trying to destroy them. And at the same time companies are free to
> build their closed source products on top of our Open Source library.
> Some (not all) of those companies, could definitely afford to fund a
> project like MPIR, but wont.

I agree. We could build a first class BSD licensed multiple precision
library given modest sponsorsship. But while some major companies (not
all) feel they can exploit open source developers whilst making no
contributions to the development community in return, its hard to see
this happening.

Brian

[Pierre Joye]

hi Bill,

Thanks for the extensive reply, very much appreciated.

On Mon, Apr 12, 2010 at 1:55 PM, Bill Hart <goodwi...@googlemail.com> wrote:

> On 12 April 2010 11:18, Pierre Joye <pierr...@gmail.com> wrote:

> 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.

It makes sense, however I wonder if it is good for mpir users. But it
makes the work easier for mpir developers, that's a sure thing.

I will have to split my reply as it is a rather large topic.

> 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.

The GPL does not allow any GPL code to be linked with PHP Licensed
code, at least this restriction up to v2. For v3 there is a debate
about "linkage" and "usage" as in using GPL code in an external
process (calling a cmd line tool for example). But the whole v3 move
(gpl and lgpl) creates a lot of troubles lately for companies and
other OSS projects. The "or later" clause has also been ignored in the
past, but the v3 shows the implications and the direction the gpl
license takes is scary (no offense meant, only writing down my feeling
about the GPL movement for the last decade).

Short reply but other will come in the next days :)

[Bill Hart]

As quite a lot of people have mentioned the possibility of a BSD
licensed MPIR, I started a separate thread for this.

Bill.

[Xilman]

On Apr 12, 1:59 pm, Cactus <rieman...@googlemail.com> wrote:
> In my view GMP and MPIR are a total mess in software engineering terms
> and I would hence like nothing beeter than to participate in the
> development of a new, well structured multiple precision library under
> aa open source license that provided for commercial use.
>
> The number of comapnies who could benefit from this is very large and
> the individual cost would be small but we have no obvious way of
> orchestrating this.
>
> > It seems to me we have the worst of all worlds. We aren't funded, due
> > to our code being regarded with suspicion by companies who fear we are
> > trying to destroy them. And at the same time companies are free to
> > build their closed source products on top of our Open Source library.
> > Some (not all) of those companies, could definitely afford to fund a
> > project like MPIR, but wont.
>
> I agree. We could build a first class BSD licensed multiple precision
> library given modest sponsorsship. But while some major companies (not
> all) feel they can exploit open source developers whilst making no
> contributions to the development community in return, its hard to see
> this happening.

I confess that I have never contributed code to MPIR, so please weight
my response correspondingly.

I have a profound dislike of the GPL because of its restrictions. I
can just about live with LGPL 2 but am very, very wary of LGPL 3. In
this regard I seem to be in good company. Whenever I distribute
something it is always under a BSD-like license or something even more
permissive, such as renouncing all copyright interest. However, just
because I give something away I don't see why my recipients should be
forced to follow my philosophy. After all, they can not prevent me
also giving away my stuff to their competitors if I feel like it.

Here's just one example of how I fell foul of the GPL. A colleague
wanted to run my code under Cygwin. I very happily supplied source
code but was unable to provide a pre-compiled binary and had to forbid
him to do the same. The reason: both of us had only the freeware
version of Cygwin and its license terms dictate that binaries linked
with Cygwin libraries *must* be released under the GPL. I find it
bizarre, and very sad, that the FSF prevents me from giving away
binaries even though I'm more than willing to give away full
sources. When I want to give something away I mean it to be as a
gift, not as a loan. That's why I'm sold on BSD-like licenses.

It's just possible I may contribute code to a LGPL 2+ library. In
particular, I'm rather interested in parallel computation, including
GPGPU. It is very very unlikely that I will contribute to a LGPL 3
library. It is much more likely that I'll contribute under a BSD-
like license.

I've no idea whether I'm unique or unusual in my views. It may well
be that a significant number of other developers are also deterred
from contributing to MPIR by the LPGP license.

Paul

[Bill Hart]

Hi Paul,

I am rapidly coming to the realisation that you are right.

I am very, very surprised by this. I had up until now been under the
impression that there is far more development going on under the GPL
or LGPL licenses. In fact I had been told that licensing something
with the BSD license would be a major turn off to developers.

Well, so far I have 6 people very interested, versus the three we had
working on MPIR.

I'm actually flabbergasted!

Bill.