On Tue, 14 Feb 2012, Christoph Lauter wrote: > As a matter of course, we'd be more than happy to get your input (and even > guidance w.r.t. copyright management and coding conventions) on and during > that project.
* GNU projects do not automatically need copyright assignments to the FSF (some do, some don't), but GCC and glibc are among the projects that do require assignments and I've never heard of an assigning project changing to non-assigning. So assigning the work to the FSF is certainly the safe option for inclusion in GCC and glibc, although it may not be required. (GCC does not necessarily require assignments for new runtime libraries; see the Mission Statement. glibc has lots of existing non-assigned code in libm, though new non-assigned code would need FSF approval.) * The soft-fp license - LGPL+exception - is the safe option for licensing code built for the target - code going in libm itself - although other permissive licenses approved by the FSF would also be fine. * Host-side code - generators - need to be free software; the GNU convention would be GPLv3+ although other free software licenses should also work (subject to FSF approval if this is a GNU project). * The generators (for code in libm, test cases, etc.) must be fully usable using only free software. For example, generators using Maple or Mathematica would not be OK for a GNU libm project. The exact free software licenses for languages and libraries used in the generators are not so significant - as long as the licenses are suitably compatible for whatever combinations are formed. I don't know what tools will be most appropriate here (though it seems likely GNU MP and GNU MPFR would end up involved somewhere even if code is not written directly in C using those C libraries directly). * Follow the GNU Coding Standards for both the generated code, and for generators if those are written in C or C++ rather than some higher level language. If using some higher level language, still follow the GNU Coding Standards as far as they make sense (not for details of source code formatting, but for such things as making programs support --help and --version, for example). > If (parts of) GNU or gcc could officially endorse it, we'd even be happier. > This might also help to get the financing. I suspect endorsement may be tricky in that normally a new GNU project would I think be designated as such at a point where working code already exists. But personally I think it's a very good idea to learn from what was done with crlibm and more recent research and use that to produce automatically generated versions of C99 libm functions suitable for use in both GCC and glibc (fully namespace-clean, avoiding global state, configurable as regards error handling, etc.), suitable for meeting a range of speed and accuracy requirements, able to handle variations among hardware architectures (for example, including variants of float and double functions that work correctly with x87 in 64-bit precision mode when the only type with real hardware operations is long double). And certainly people can talk to RMS about the directions we'd like to follow for libm development, where this involves such things as choice of licensing and starting new GNU projects. -- Joseph S. Myers jos...@codesourcery.com
