Re: [patches] Proposal for submission of dfp add-on to EGLIBC

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Fri, 30 Mar 2007, Ryan S. Arnold wrote:

>   * Libdfp has an internal version of libdecnumber v3.37 that is
> currently licensed LGPLv2.1.  In order to contribute Libdfp to EGLIBC
> this internal version of libdecnumber must be removed from Libdfp
> because the FSF doesn't allow the same source code to have multiple
> licenses.

It allows the use of LGPL+exception as for soft-fp, which I think is the 
safest option to use here (subject to approval by RMS).

> o Certain GLIBC files are overridden in the dfp add-on so as to not
> intrude on the base GLIBC versions of these files.  They can either
> remain overrides or they can be merged with the EGlibc base versions.
> These include:

As I previously indicated, I think the core libc versions in EGLIBC should 
have appropriate conditionals to facilitate merging, rather than having 
modified copies of the core files in the add-on.

> Libdfp is currently copyright IBM in order to retain the maximum amount
> of flexibility/freedom with regard to copyright and license until we can
> find a community home for Libdfp.  If EGLIBC accepts Libdfp we'll adjust
> the copyright and license under the terms and conditions of the EGLIBC
> license and FSF copyright strictures.

I think we must presume that all contributions to EGLIBC must be assigned 
to the FSF and distributed under LGPL or LGPL+exception, even though there 
is some code presently in glibc not assigned to the FSF, unless the FSF 
gives specific approval for some other arrangement that would allow 
merging back to glibc in future.

Any exported symbol versions should be of the form LIBDFP_* or similar, 
since GLIBC_* versions could potentially conflict with those assigned by 
FSF glibc in future.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx