Re: license of generated info docs (GFDL?) and man pages

["Joseph S. Myers" <jsm28@cam.ac.uk>]

On Fri, 23 May 2003, Matthias Klose wrote:

> Looking at the source of the gcc docs, the GFDL-1.2 is mentioned. In
> the generated html docs and in the generated man pages you can re-find
> the copyright, but it's absent of the generated info docs. Some
> questions:

The generated info docs are under the GFDL.  Look at the very top of the
info files (before the parts that info readers actually show).

> - Assuming the description of the options will be generated from a
>   common description in the sources (in 3.4 or later), will the output
>   of gcc --help be put under the GFDL as well?

If part of the code that goes into GCC (generating --help output) is
derived from text in the Texinfo manual, I expect that the relevant part
of the manual would need to be GFDL/GPL dual licensed.  But we don't have
any code that generates --help output from the manual, and GFDL/GPL dual
licensing of invoke.texi and the other files involved would be a matter
for the FSF.

> - Could the GCC project consider to re-license the man pages under a
>   license, which would Debian allow to distribute these as part of the
>   gcc package(s)?

It is the FSF (i.e., RMS) you need to talk to about any licensing changes.  
The man pages carefully follow instructions given by the FSF about the
correct way to handle man pages generated from GFDL manuals with invariant
sections (without actually duplicating those section within every man
page); it's for the FSF to make any changes to that licensing.

I don't like non-removable Invariant Sections (and think Funding Free
Software belongs on the FSF website - where it already is - not in GCC
manuals, though I don't see any problem with having a copy of the GPL in
the manuals if it were removable) and I know various other GCC maintainers
don't like them either, but it's RMS who would need to authorise any
licence change; patches (as Zack sent some time ago
<http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01687.html>) to remove them
are useless without prior FSF approval.

-- 
Joseph S. Myers
jsm28@cam.ac.uk