Richard Guenther wrote: > Remembering the patches from Joseph these were from a different part > of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and > dbl-64 which contain C implementations of C99 math intrinsics such as > sin and cos. The flt-32 parts are public domain as in > > /* > * ==================================================== > * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. > * > * Developed at SunPro, a Sun Microsystems, Inc. business. > * Permission to use, copy, modify, and distribute this > * software is freely granted, provided that this notice > * is preserved. > * ==================================================== > */ > > while the dbl-64 parts are LGPL and so subject to the change to GPL > + exception. I don't know if these parts of GLIBC are covered by RMS's > permission, it is probably advisable to ask.
I think that we need to ask RMS specifically about this. Would you please send a message to RMS, and copy the SC list (is that address public? I'm not sure if I'm supposed to give it out, ask me privately if you don't know it) on the mail. Explain the situation, including what code you're importing and why you want an exception. My guess is that it's OK to include the Sun code, since it's in the public domain. My guess is also that, without explicit permission from RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't sound like that is covered by "software floating-point emulation". That means that people who linked with this library would find that the LGPL applies, which is contrary to our general policy that binaries produced by GCC are not subject to GPL/LGPL issues. So, I think you should remove the dbl-64 code until this is resolved, or at least prevent it from being compiled by removing whatever Makefile bits compile it. My experience is that it usually takes some time for RMS to grant a license exception, and that he may not choose to do it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
