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
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.
(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:
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
On Wed, 9 Mar 2011, amylaar at gcc dot gnu.org wrote:
> --- 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:
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.
Does this really need to have "blocker" importance? It has gone several years without actually blocking any releases.
(In reply to Eric Gallager from comment #4)
> Does this really need to have "blocker" importance? It has gone several
> years without actually blocking any releases.
The license issue has blocked a comprehensive consolidation of the target description.
The question if it's currently blocking is a bit philosophical. If the
license issue was resolved, would there be anyone right now with the time
and motivation to take up the work?
OTOH, we generally accept that there can be multiple blocking issues,
all of which have to be resolved to allow a certain task to proceed.
Since we have docstring relicensing maintainers, I don't think this is an
(In reply to email@example.com from comment #6)
> Since we have docstring relicensing maintainers, I don't think this is an
> issue now.
Oops, that slipped my mind. Indeed, we can consider this arrangement
to have fixed this issue.
(In reply to Jorn Wolfgang Rennecke from comment #7)
> (In reply to firstname.lastname@example.org from comment #6)
> > Since we have docstring relicensing maintainers, I don't think this is an
> > issue now.
> Oops, that slipped my mind. Indeed, we can consider this arrangement
> to have fixed this issue.