Quad-float math library: licence question

Quad-float math library: licence question

[FX]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

Dear all,

Here's an update on my work towards quad-float (aka __float18, aka binary128) support in Fortran. I've worked on runtime library support, and came to the conclusion that building wrappers around MPFR was not the right way to go. It is quite impractical, as it requires an MPFR target library. Moreover, it is quite inefficient.

Thus, I have lifted a binary128 math library from glibc, which contains one. It took some rewriting to make it standalone (the glibc sources are a bit convoluted to my taste). I combined that with David M. Gay's gdtoa routines (http://www.netlib.org/fp/), which I stripped down to the essentials needed for __float128). The resulting libquadmath library (with simple Makefile) is attached to this mail.

Technically, this  works very well. The question of integration is now more a question about licences:

  -- some of the math code comes from Cephes; it has liberal licencing, and was included into glibc under the LGPL
  -- the rest of the math code comes from fdlibm, with very liberal licencing
  -- the gdtoa code licencing is also pretty liberal; it's already used in a variety of projects

So, the question is: how do we manage this? I suppose because of the LGPL licence, direct integration into libgfortran is out of the question. I see three options :

  -- ask the FSF (who owns the glibc, after all) to relicence this code under the GPL + exception, so we can integrate everything into libgfortran
  -- keep this as a separate package, and allow libgfortran to be configured with it (this seems like a very wrong solution)
  -- have it inside libgfortran, but in a separate library, which is linked in when quad-float support is requested; document the licence difference in the manual

I can proceed with any of the three, or any other option that the maintainers think is best. So, what do people think about this?

Regards,
FX


PS: Initial discussion thread on this was here: http://gcc.gnu.org/ml/gcc/2010-05/msg00452.html



[-- Attachment #2: quadmath.tar.gz --]
[-- Type: application/x-gzip, Size: 259482 bytes --]

Re: Quad-float math library: licence question

[Jerry DeLisle]

On 08/13/2010 07:23 AM, FX wrote:
> Dear all,
>
> Here's an update on my work towards quad-float (aka __float18, aka binary128) support in Fortran. I've worked on runtime library support, and came to the conclusion that building wrappers around MPFR was not the right way to go. It is quite impractical, as it requires an MPFR target library. Moreover, it is quite inefficient.
>
> Thus, I have lifted a binary128 math library from glibc, which contains one. It took some rewriting to make it standalone (the glibc sources are a bit convoluted to my taste). I combined that with David M. Gay's gdtoa routines (http://www.netlib.org/fp/), which I stripped down to the essentials needed for __float128). The resulting libquadmath library (with simple Makefile) is attached to this mail.
>
> Technically, this  works very well. The question of integration is now more a question about licences:
>
>    -- some of the math code comes from Cephes; it has liberal licencing, and was included into glibc under the LGPL
>    -- the rest of the math code comes from fdlibm, with very liberal licencing
>    -- the gdtoa code licencing is also pretty liberal; it's already used in a variety of projects
>
> So, the question is: how do we manage this? I suppose because of the LGPL licence, direct integration into libgfortran is out of the question. I see three options :
>
>    -- ask the FSF (who owns the glibc, after all) to relicence this code under the GPL + exception, so we can integrate everything into libgfortran
>    -- keep this as a separate package, and allow libgfortran to be configured with it (this seems like a very wrong solution)
>    -- have it inside libgfortran, but in a separate library, which is linked in when quad-float support is requested; document the licence difference in the manual
>
> I can proceed with any of the three, or any other option that the maintainers think is best. So, what do people think about this?
>

First, I would ask FSF to at least get some foundation for whatever we do.

Second, can we define a F95 module interface so that one can simply do USE 
QUADsomename and have that automatically link in the separate library.

Third, can we not expand our current dtoa code to handle quad.  Our current code 
is fairly flexible I think.  (I have not reviewed your code yet)

Regards,

Jerry

Re: Quad-float math library: licence question

[Steve Kargl]

On Fri, Aug 13, 2010 at 08:08:33AM -0700, Jerry DeLisle wrote:
> On 08/13/2010 07:23 AM, FX wrote:
> >
> >So, the question is: how do we manage this? I suppose because of the LGPL 
> >licence, direct integration into libgfortran is out of the question. I 
> >see three options :
> >
> >   -- ask the FSF (who owns the glibc, after all) to relicence this code 
> >   under the GPL + exception, so we can integrate everything into 
> >   libgfortran
> >   -- keep this as a separate package, and allow libgfortran to be 
> >   configured with it (this seems like a very wrong solution)
> >   -- have it inside libgfortran, but in a separate library, which is 
> >   linked in when quad-float support is requested; document the licence 
> >   difference in the manual
> >
> >I can proceed with any of the three, or any other option that the 
> >maintainers think is best. So, what do people think about this?
> >
> 
> First, I would ask FSF to at least get some foundation for whatever we do.
> 

I Agree with Jerry, here.  This seems like an issue that
the GCC steering committee should take up with FSF.

-- 
Steve

Re: Quad-float math library: licence question

[FX]

> Second, can we define a F95 module interface so that one can simply do USE QUADsomename and have that automatically link in the separate library.

There is no question about how this is handled on the Fortran end: the user says "real(kind=16)".

> Third, can we not expand our current dtoa code to handle quad.  Our current code is fairly flexible I think.  (I have not reviewed your code yet)

Unless I'm wrong, the current code uses the system's printf functions for floating-point output, does it not? If so, because C99 (nor glibc, nor any other libc out there) provides binary128 I/O, we need to provide our own.

Regarding how to proceed, well... let's just say my opinion is that if you ask the SC to ask the FSF to ... to tell the SC to tell the community to ... then maybe this will make it into gfortran-4.9 :)


FX

Re: Quad-float math library: licence question

[Jerry DeLisle]

On 08/13/2010 08:22 AM, Steve Kargl wrote:
> On Fri, Aug 13, 2010 at 08:08:33AM -0700, Jerry DeLisle wrote:
>> On 08/13/2010 07:23 AM, FX wrote:
>>>
>>> So, the question is: how do we manage this? I suppose because of the LGPL
>>> licence, direct integration into libgfortran is out of the question. I
>>> see three options :
>>>
>>>    -- ask the FSF (who owns the glibc, after all) to relicence this code
>>>    under the GPL + exception, so we can integrate everything into
>>>    libgfortran
>>>    -- keep this as a separate package, and allow libgfortran to be
>>>    configured with it (this seems like a very wrong solution)
>>>    -- have it inside libgfortran, but in a separate library, which is
>>>    linked in when quad-float support is requested; document the licence
>>>    difference in the manual
>>>
>>> I can proceed with any of the three, or any other option that the
>>> maintainers think is best. So, what do people think about this?
>>>
>>
>> First, I would ask FSF to at least get some foundation for whatever we do.
>>
>
> I Agree with Jerry, here.  This seems like an issue that
> the GCC steering committee should take up with FSF.
>

I forwarded this to Toon in hopes of getting something moving on this quickly. 
(If that is possible)

Jerry

Re: Quad-float math library: licence question

[Jakub Jelinek]

On Fri, Aug 13, 2010 at 05:48:23PM +0200, FX wrote:
> > Second, can we define a F95 module interface so that one can simply do
> > USE QUADsomename and have that automatically link in the separate
> > library.
> 
> There is no question about how this is handled on the Fortran end: the user says "real(kind=16)".
> 
> > Third, can we not expand our current dtoa code to handle quad.  Our
> > current code is fairly flexible I think.  (I have not reviewed your code
> > yet)
> 
> Unless I'm wrong, the current code uses the system's printf functions for
> floating-point output, does it not?  If so, because C99 (nor glibc, nor
> any other libc out there) provides binary128 I/O, we need to provide our
> own.

Well, for glibc you could just use printf hooks and handle __float128 in the
hooks.

	Jakub

Re: Quad-float math library: licence question

[FX]

> Well, for glibc you could just use printf hooks and handle __float128 in the
> hooks.

But in the hook, you still need to have proper code that knows how to transform a __float128 value into decimal digits... so you're not really any closer!

FX

Re: Quad-float math library: licence question

[Steve Kargl]

On Fri, Aug 13, 2010 at 05:48:23PM +0200, FX wrote:
> 
> Regarding how to proceed, well... let's just say my opinion is
> that if you ask the SC to ask the FSF to ... to tell the SC to
> tell the community to ... then maybe this will make it into
> gfortran-4.9 :)

Unfortunately, I think your assessment of the above
scenario is likely correctly :(   ISTR, that someone
took (part of) glibc's libm and integrated that into
GCC, and it was not received too well.

I'll start reading your patch tonight (ie., in about
8 hours) and give you feedback.

-- 
Steve

Re: Quad-float math library: licence question

[FX]

> I'll start reading your patch tonight (ie., in about
> 8 hours) and give you feedback.

It's not a patch, it's just the runtime math library. I have also been working on my patch, which should be ready to post in a week's time or so.

FX

Re: Quad-float math library: licence question

[Jerry DeLisle]

On 08/13/2010 08:48 AM, FX wrote:
>> Second, can we define a F95 module interface so that one can simply do USE QUADsomename and have that automatically link in the separate library.
>
> There is no question about how this is handled on the Fortran end: the user says "real(kind=16)".
>
>> Third, can we not expand our current dtoa code to handle quad.  Our current code is fairly flexible I think.  (I have not reviewed your code yet)
>
> Unless I'm wrong, the current code uses the system's printf functions for floating-point output, does it not? If so, because C99 (nor glibc, nor any other libc out there) provides binary128 I/O, we need to provide our own.
>
> Regarding how to proceed, well... let's just say my opinion is that if you ask the SC to ask the FSF to ... to tell the SC to tell the community to ... then maybe this will make it into gfortran-4.9 :)
>
OK

Then this:

Build the runtime library separately and provide some common binaries for it 
along with the source hosted out of the gfortran.org. Call it libgfortranquad.

Use configury magic to optionally compile the front-end portions.  This would be 
similat to what we do with blas and lapack libraries.

Then gcc is free of any licensing concerns and down the road if something better 
comes along or the licensing gets settled, we can integrate it further.

How does this sound?

Jerry

Re: Quad-float math library: licence question

[Toon Moene]

FX wrote:

> Here's an update on my work towards quad-float (aka __float18, aka binary128) support in Fortran. I've worked on runtime library support, and came to the conclusion that building wrappers around MPFR was not the right way to go. It is quite impractical, as it requires an MPFR target library. Moreover, it is quite inefficient.
> 
> Thus, I have lifted a binary128 math library from glibc, which contains one. It took some rewriting to make it standalone (the glibc sources are a bit convoluted to my taste). I combined that with David M. Gay's gdtoa routines (http://www.netlib.org/fp/), which I stripped down to the essentials needed for __float128). The resulting libquadmath library (with simple Makefile) is attached to this mail.
> 
> Technically, this  works very well. The question of integration is now more a question about licences:
> 
>   -- some of the math code comes from Cephes; it has liberal licencing, and was included into glibc under the LGPL
>   -- the rest of the math code comes from fdlibm, with very liberal licencing
>   -- the gdtoa code licencing is also pretty liberal; it's already used in a variety of projects
> 
> So, the question is: how do we manage this? I suppose because of the LGPL licence, direct integration into libgfortran is out of the question. I see three options :
> 
>   -- ask the FSF (who owns the glibc, after all) to relicence this code under the GPL + exception, so we can integrate everything into libgfortran
>   -- keep this as a separate package, and allow libgfortran to be configured with it (this seems like a very wrong solution)
>   -- have it inside libgfortran, but in a separate library, which is linked in when quad-float support is requested; document the licence difference in the manual
> 
> I can proceed with any of the three, or any other option that the maintainers think is best. So, what do people think about this?

I will discuss this on the SC mailing list (which includes RMS, so the 
path to the FSF is not *that* long :-)

Can you say something more about the gdtoa code license (IIRC, fdlibm is 
already included in glibc) ?

One obvious question I see coming is "why can't you just *call* the 
binary128 routines in glibc ?", so I have to understand that bit first 
(otherwise I'm bound to get into a slow back-and-forth between you and me).

Cheers,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Quad-float math library: licence question

[Jakub Jelinek]

On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:
> One obvious question I see coming is "why can't you just *call* the
> binary128 routines in glibc ?", so I have to understand that bit
> first (otherwise I'm bound to get into a slow back-and-forth between
> you and me).

Because they aren't there.  glibc has sysdeps/ieee754/ldbl-128/*l.c
sources for *l functions, using 128-bit IEEE quad long double and with
L suffix on floating point constants, for architectures that have
IEEE quad long double (sparc, alpha, s390).
The routines in libquadmath are very similar, but with
s/long double/__float128/, s/L/Q/ and renaming of fn suffixes from l
to q (there are likely a few other changes), for targets that have smaller
or less precise long double, but have __float128 type (i?86, x86-64, ia64).

	Jakub

Re: Quad-float math library: licence question

[Toon Moene]

Jakub Jelinek wrote:

> On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:

>> One obvious question I see coming is "why can't you just *call* the
>> binary128 routines in glibc ?", so I have to understand that bit
>> first (otherwise I'm bound to get into a slow back-and-forth between
>> you and me).

> Because they aren't there.  glibc has sysdeps/ieee754/ldbl-128/*l.c
> sources for *l functions, using 128-bit IEEE quad long double and with
> L suffix on floating point constants, for architectures that have
> IEEE quad long double (sparc, alpha, s390).
> The routines in libquadmath are very similar, but with
> s/long double/__float128/, s/L/Q/ and renaming of fn suffixes from l
> to q (there are likely a few other changes), for targets that have smaller
> or less precise long double, but have __float128 type (i?86, x86-64, ia64).

I suspect in that case the suggestion would be to add these functions to 
glibc (I have been in an earlier discussion about a comparable request - 
Richard Guenther's suggestion to add a library for vectorized math 
functions).

If there's a good reason why this can't be done, I'd rather hear it 
beforehand :-)

Cheers,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Quad-float math library: licence question

[Richard Guenther]

On Sat, Aug 14, 2010 at 3:25 PM, Toon Moene <toon@moene.org> wrote:
> Jakub Jelinek wrote:
>
>> On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:
>
>>> One obvious question I see coming is "why can't you just *call* the
>>> binary128 routines in glibc ?", so I have to understand that bit
>>> first (otherwise I'm bound to get into a slow back-and-forth between
>>> you and me).
>
>> Because they aren't there.  glibc has sysdeps/ieee754/ldbl-128/*l.c
>> sources for *l functions, using 128-bit IEEE quad long double and with
>> L suffix on floating point constants, for architectures that have
>> IEEE quad long double (sparc, alpha, s390).
>> The routines in libquadmath are very similar, but with
>> s/long double/__float128/, s/L/Q/ and renaming of fn suffixes from l
>> to q (there are likely a few other changes), for targets that have smaller
>> or less precise long double, but have __float128 type (i?86, x86-64,
>> ia64).
>
> I suspect in that case the suggestion would be to add these functions to
> glibc (I have been in an earlier discussion about a comparable request -
> Richard Guenther's suggestion to add a library for vectorized math
> functions).
>
> If there's a good reason why this can't be done, I'd rather hear it
> beforehand :-)

The single good reason is called Ulrich Drepper.  Well - at least ask him
before spending time on this.

Richard.

Re: Quad-float math library: licence question

[Steve Kargl]

On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:
> 
> One obvious question I see coming is "why can't you just *call* the 
> binary128 routines in glibc ?", so I have to understand that bit first 
> (otherwise I'm bound to get into a slow back-and-forth between you and me).
> 

glibc isn't the libc on many supported OS's, e.g.,
FreeBSd, NetBSD, OpenBSD, Solaris, ...

-- 
Steve

Re: Quad-float math library: licence question

[Jerry DeLisle]

On 08/14/2010 08:20 AM, Steve Kargl wrote:
> On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:
>>
>> One obvious question I see coming is "why can't you just *call* the
>> binary128 routines in glibc ?", so I have to understand that bit first
>> (otherwise I'm bound to get into a slow back-and-forth between you and me).
>>
>
> glibc isn't the libc on many supported OS's, e.g.,
> FreeBSd, NetBSD, OpenBSD, Solaris, ...
>

I am really beginning to like the separate new library idea! Lets just do it!

Jerry

Re: Quad-float math library: licence question

[Toon Moene]

Jerry DeLisle wrote:

> On 08/14/2010 08:20 AM, Steve Kargl wrote:

>> On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:
>>>
>>> One obvious question I see coming is "why can't you just *call* the
>>> binary128 routines in glibc ?", so I have to understand that bit first
>>> (otherwise I'm bound to get into a slow back-and-forth between you 
>>> and me).

>> glibc isn't the libc on many supported OS's, e.g.,
>> FreeBSd, NetBSD, OpenBSD, Solaris, ...

Yes, this is an excellent argument from Steve, which will then be 
ignored because the FSF (at least, RMS) maintains that the GNU project 
is about developing a *system*, not just individual parts that can be 
used as building blocks (e.g., on the various BSD variants).

As you see, the discussion is not about licenses, but about what you 
think the goal of the GNU project (and *therefore*, the goal of GCC) is.

> I am really beginning to like the separate new library idea! Lets just 
> do it!

Well, I tried to defend gfortran having its own run-time library (as 
most other compilers have) and have full control over it - but alas, I 
never got very far with that argument in the discussion about Richard 
Guenther's contribution, either.

So unless someone *really, really* wants me to reopen that issue on the 
SC mailing list, I'd rather refrain ...

Cheers,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Quad-float math library: licence question

[Gerald Pfeifer]

On Sat, 14 Aug 2010, Toon Moene wrote:
>>> glibc isn't the libc on many supported OS's, e.g.,
>>> FreeBSd, NetBSD, OpenBSD, Solaris, ...
> Yes, this is an excellent argument from Steve, which will then be 
> ignored because the FSF (at least, RMS) maintains that the GNU project 
> is about developing a *system*, not just individual parts that can be 
> used as building blocks (e.g., on the various BSD variants).

Yes, except that GCC and other GNU software _is_ supposed to support
other platforms and...

> Well, I tried to defend gfortran having its own run-time library (as 
> most other compilers have) and have full control over it - but alas, I 
> never got very far with that argument in the discussion about Richard 
> Guenther's contribution, either.

...I see this question as a technical one.  If the GNU Fortran maintainers
feel they need such a library for technical reasons, it it does not impact
the GNU project negatively, just go for it.

(Otherwise, libiberty should be removed immediately, and I think nobody
is seriously going to suggest that!)

One option is to make this part of an existing library with an existing
license exception.  If it needs to be a new library, I suggest you go
for it and raise the case.

Gerald

Re: Quad-float math library: licence question

[Steve Kargl]

On Sat, Aug 14, 2010 at 06:41:18PM +0200, Toon Moene wrote:
> Jerry DeLisle wrote:
> 
> >On 08/14/2010 08:20 AM, Steve Kargl wrote:
> 
> >>On Sat, Aug 14, 2010 at 01:23:03PM +0200, Toon Moene wrote:
> >>>
> >>>One obvious question I see coming is "why can't you just *call* the
> >>>binary128 routines in glibc ?", so I have to understand that bit first
> >>>(otherwise I'm bound to get into a slow back-and-forth between you 
> >>>and me).
> 
> >>glibc isn't the libc on many supported OS's, e.g.,
> >>FreeBSd, NetBSD, OpenBSD, Solaris, ...
> 
> Yes, this is an excellent argument from Steve, which will then be 
> ignored because the FSF (at least, RMS) maintains that the GNU project 
> is about developing a *system*, not just individual parts that can be 
> used as building blocks (e.g., on the various BSD variants).
> 
> As you see, the discussion is not about licenses, but about what you 
> think the goal of the GNU project (and *therefore*, the goal of GCC) is.
> 
> >I am really beginning to like the separate new library idea! Lets just 
> >do it!
> 
> Well, I tried to defend gfortran having its own run-time library (as 
> most other compilers have) and have full control over it - but alas, I 
> never got very far with that argument in the discussion about Richard 
> Guenther's contribution, either.
> 
> So unless someone *really, really* wants me to reopen that issue on the 
> SC mailing list, I'd rather refrain ...
> 

Can we argue that FX's library is similar to libdecnumber?  I've
actually thought about using libdecnumber to give gfortran a 
real kind type with a base 10 radix.  Should libdecnumber be
removed from gcc and assimulated into glibc?

-- 
Steve

Re: Quad-float math library: licence question

[Toon Moene]

Toon Moene wrote:

> Jerry DeLisle wrote:

>> I am really beginning to like the separate new library idea! Lets just 
>> do it!

OK, I'll formulate a proposal to the SC based on the licensing 
information that FX provided (plus what I can find on the interwebs :-) 
and assume/propose that we (well, FX) will build a run-time library 
specific for use by gfortran compiled code to implement 128-bit floating 
point code arithmetic (on targets that currently only support 80-bit 
floats).

I'll pass draft(s) to the fortran list first.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Quad-float math library: licence question

[FX]

> OK, I'll formulate a proposal to the SC based on the licensing information that FX provided (plus what I can find on the interwebs :-) and assume/propose that we (well, FX) will build a run-time library specific for use by gfortran compiled code to implement 128-bit floating point code arithmetic (on targets that currently only support 80-bit floats).

That sounds correct. I'm back from my yearly "no internet" week, so please feel free to ask questions, to which I promise to reply promptly.

> I'll pass draft(s) to the fortran list first.

Please CC me :)

FX