On Fri, 10 Feb 2012, Geert Bosch wrote: > On Feb 9, 2012, at 15:33, Joseph S. Myers wrote: > > For a few, yes, inline support (such as already exists for some functions > > on some targets) makes sense. But for some more complicated cases it > > seems plausible that LTO information in a library might be an appropriate > > way of inlining while allowing the functions to be written directly in C. > > (Or they could be inline in a header provided with GCC, but that would > > only help for use in C and C++ code.) > But neither LTO nor header-based inlining would be compatible with LGPL, > right?
Indeed. Either the LGPL+exception used in soft-fp, or a generic permissive license, would be more appropriate there. (GPL+exception as for most of libgcc should also work, though I don't think there's any of that in glibc at present.) > > Indeed, if we can't then other sources would need using for the functions. > > But it seems worth explaining the issues to RMS - that is, that there is a > > need for permissively licensed versions of these functions in GNU, the > > question is just whether new ones are written or taken from elsewhere or > > whether glibc versions can be used for some functions. > > I'm skeptical that talking to RMS will result in relicensing of these glibc > functions. If we're writing new ones (or incorporate libraries such as > fdlibm), > we don't need permission. Relicensing of soft-fp to LGPL+exception was approved by RMS. There are certainly some justifications for a relicensing that might not be sufficient - that a change would cause some software to be more widely used, for example, may not be a justification by itself - but the justification here is more in terms of the GNU system working better together as a whole, that permissively licensed versions of many of the functions already exist, and especially if as you suggest you don't want to maintain a stable ABI to the functions called from GCC (so many would only be linked in statically) permissive licensing is needed to meet the expectations people have for use of code built with GCC. You may of course get approval for specific concrete functions rather than more generally, if you identify particular functions where the glibc implementations are of interest - and there may be functions not owned by the FSF, or where the assignments to the FSF do not permit a more permissive relicensing. There may also be functions assigned to the FSF by a few big contributors who could grant permissive licenses themselves if they wish (where there haven't been significant changes to those functions after the contribution). -- Joseph S. Myers jos...@codesourcery.com
