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 [EMAIL PROTECTED] (650) 331-3385 x713