FSF Policy re. inclusion of source code from other projects in GCC

[Richard Guenther]

On 17 Mar 2006 22:44:37 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
>
> [...]
>
> | >> Because RMS has approved the use of GLIBC's software floating-point code
> | >> in GCC's runtime libraries, using GPL + exception, the correct thing for
> | >> Joseph Myers to do with his recent patch is to mark those files as not
> | >> part of GCC, but rather as part of GLIBC, and adjust the copyright
> | >> notice to be GPL + exception.  Joseph should also document (in a README
> | >> or similar) that these files are not to be changed, except by import
> | >> from upstream GLIBC.
> | >
> | > Do I understand this correctly that the upstream GLIBC versions of the
> | > files will get their license changed, or will this happen only in the GCC
> | > copy?
> |
> | Only in the GCC copy.
> |
> | I don't understand enough about libgcc-math to know what should happen
> | there; I don't even know what bits of GLIBC you used.  RMS has given
> | explicit permission to use GPL + exception for the software
> | floating-point emulation code, but not for any other part of GLIBC.
>
> I am confused.  My interest in libgcc-math is that it helps solve
> thorny issues with libstdc++-v3 and my expectation is that we can make
> modification to libgcc-math so that we can't advantage of it.  Now, I
> understand that we cannot make modification to libgcc-math without
> modifying GLIBC?  Is that correct.

I understand it in the way that we should modify the imported parts
upstream (or not), while we can for sure add glues and wrappers or
other thinks to libgcc-math.  So this discussion only affects flt-32
and dbl-64 directories.  I don't think this will make the libstdc++-v3
issues impossible - maybe a little harder.  If there will be a point where
a true fork is inevitable, we can politely ask again.

Richard.