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

[Mark Mitchell <mark at codesourcery dot com>]

There has recently been extensive discussion on the GCC Steering
Committee list about the manner in which we're handling imports of
source code from other projects.

The FSF's guidelines permit us to import code (assuming it's free
software, of course), but, as specified here:

http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries

we're discouraged from doing so gratuitously.

To quote RMS:

> If someone signs an assignment for GCC, and has made contributions
> to package Z which is not part of GCC, he has no reason to believe that
> his assignment covers his changes to Z.
>
> If subsequently we include Z in GCC, that can hardly count as a
> justification to claim, retroactively, that he had assign his code in
> Z to us.

There are two different situations that we need to distinguish: imports,
where we then make no modifications subsequently, except to import newer
versions, and imports where we do make subsequent modifications.  The
first situation is less problematic than the second, so we want to avoid
the second situation if at all possible.

Packages imported from an externally maintained source must be mentioned
in the "Upstream packages" section of the "GCC Coding Conventions" page.
 This must say where the code came from, and how it will be maintained.
 See http://gcc.gnu.org/codingconventions.html#upstream libgcc-math
should be mentioned here.

A recent example of a mis-handled situation is the inclusion of
libgcc-math.  This code appears to be based largely on code from GLIBC.
 It's OK to include it in our repository, but it needs to be documented
as not being part of GCC.  Before we approve these kinds of changes, we
need to be cognizant of the copyright issues.  I know that Richard
Henderson meant no harm by approving the inclusion of this library, and
I don't think most of the maintainers were aware of the implications
until now, but we need to avoid making the same mistake in future, and
we need to fix this mistake now.

Richard Guenther, would you please add a README to libgcc-math
explaining that it that the GLIBC code is not part of GCC, as per the
web page above?  Also, please document that all of the GLIBC files are
not to be changed, except by reimporting from GLIBC.  If any of the
GLIBC files have been changed from their upstream sources, please submit
those changes to the GLIBC maintainers ASAP.

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.

RMS says:

> The GLIBC developers should accept some conditionals into their
> source, so that we do not have two diverging versions.  We should all
> talk together to make this happen.

So, while the criteria they should use is not merely whether or not the
changes are good for GLIBC, we should of course respect their position
as GLIBC maintainers.

The inclusion of fastjar long ago was also probably a mistake, because
fastjar is not assigned to the FSF, and because it's a tool for use with
GCC, not a part of GCC.  It's a logically separate tool, in the same way
that the GNU Binary Utilities are separate.  The FSF and GCC SC have
decided to move fastjar to savannah, and stop including it in future GCC
releases, which will clarify this situation.  Will someone please
volunteer to migrate fastjar out of our repository?

The STL files in libstdc++-v3 need to be clearly marked as not part of
GCC.  Benjamin, will you please take care of that, by modifying the
libstdc++-v3/README to indicate that the files originally from HP are
not part of GCC, and specifically list those files?  RMS has given us
permission not to set up a separate repository for the STL files.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713