|Summary:||internals documentation cannot be fixed without new GFDL license grants|
|Product:||gcc||Reporter:||Jorn Wolfgang Rennecke <amylaar>|
|Component:||other||Assignee:||Not yet assigned to anyone <unassigned>|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2010-05-07 22:33:48|
|Bug Depends on:|
Description Jorn Wolfgang Rennecke 2010-05-07 22:32:21 UTC
Often, the information to fix internals documentation is available as GPLed code - e.g. example code, comments, function signatures. The internals Documentation is GFDLed, and thus it requires a new license grant from the FSF (or from the the author/Copyright assigner if (s)he gives notice beforehand) in order to use this information to be used to fix the documentation. This is also related to PR other/44032, in that both issues could be fixed if the internals documentation was GPLed - although for 44032 it would be sufficient to have dual licensing or partial relicensing permissions to the GPL, whereas in order to fix the documentation freely, the documentation would have to be just GPLed, or otherwise the code would have to have dual licensing or relicensing permissions that enable use for GCC documentation.
Comment 1 Joseph S. Myers 2011-02-22 16:41:27 UTC
Joern, after discussion with Mark and Richi my advice at this point on the GFDL issue is that you should prepare a concrete patch that moves all the text you want from both code and documentation to its ideal places in target.def, and send that patch - including the changes to the generated file tm.texi - to RMS for legal review (asking explicitly for approval of GFDL licensing of the changes to tm.texi and of GPL licensing for the changes to target.def) as well as to gcc-patches for technical review. That way at least RMS is faced with questions relating to licensing of fixed bodies of text under existing licenses - though the exercise would need repeating in future (maybe once per major release) after more target macros become hooks - rather than general abstract questions needing new dual-licensing notices. And in the past it's been much easier to get him to approve changes in concrete cases (e.g. licensing of longlong.h). It may be worth pointing out in the mail to RMS that the text describing macros in tm.texi (pre-GFDL, under a non-GPL copyleft) used to be routinely duplicated in comments (GPL) on individual definitions of those macros, so having this sort of text under the GPL as well as a documentation license is nothing new.
Comment 2 Jorn Wolfgang Rennecke 2011-03-09 20:12:15 UTC
(In reply to comment #1) > Joern, after discussion with Mark and Richi my advice at this point on the GFDL > issue is that you should prepare a concrete patch that moves all the text you > want from both code and documentation to its ideal places in target.def, I did this once before: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00559.html This was a lot of work, since I went through all the hook in code and doc/*.texi documentation to merge the contained information, and for a number of dubious documentation I also checked against the actual implementation for the veracity/accuracy of the documentation. It seems unlikely that I'll find time to re-do this work any time soon. If RMS want to see how the code / documentation works, he can have a look at this patch. With regards to the body of text that we want dual-licensed, in addition to the target.def from the old patch, we should also consider the current target.def, and all the documentation of specific target hooks in tm.texi . That's all the @hook definitions, and a probably a bunch of @deftypefn too . All or most of the remaining @deftypefn definitons, and the @defmac definitions, should probably converted to hooks, so we want that documentation also to be dual-licensed. If RMS has specific objections about dual-licensing particular @hook / @deftypefn / @defmac texts, he could list these, so we can continue handling them in our current haphazard way of having two sets of incomplete documentation fragments that are disjointly maintained with incompatible licenses.
Comment 3 email@example.com 2011-03-09 20:27:27 UTC
On Wed, 9 Mar 2011, amylaar at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035 > > --- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2011-03-09 20:12:15 UTC --- > (In reply to comment #1) > > Joern, after discussion with Mark and Richi my advice at this point on the GFDL > > issue is that you should prepare a concrete patch that moves all the text you > > want from both code and documentation to its ideal places in target.def, > > I did this once before: > http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00559.html But did you send it to RMS? RMS finds it easier to deal with licensing of specific bodies of text than with general permissions, but that requires a concrete patch being placed before him showing quite what FSF-owned text you want to license how - and as with all patches, this is best done without intermediaries, direct from the person preparing the patch to RMS.