This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fwd: MELT doc licensing issues.]

On Thu, 2010-07-01 at 20:12 -0700, Mark Mitchell wrote:
> Mark Mitchell wrote:
[quoting a mail by me Basile that I did permit to publish]

> > In [GFDL/GPL issues] you
> > announced that some comments from GCC code can be put in documentation.
> > There are more than two thousands such :doc chunks, automatically
> > processed to produce a meltgendoc.texi file included from gccint.texi in
> > the MELT branch.
> > Is this covered by Richard Stallman's decision for dual licensing of
> > GPLv3 and GFDLv2? 
> Yes, based on your description it is OK to include the :doc chunks in
> meltgendoc.texi, and license the latter under the GFDL.  The reason is
> that (a) the code on the MELT branch is assigned to the FSF, and (b) we
> are making the copy into GFDL documentation in the FSF repository.
> However, I think it would be dangerous and borderline deceptive to
> encourage use of the automatic conversion program with GCC.  The reason
> is that if (a) Person A downloads your branch, modifies the :doc string,
> does not regenerate the .texi file, and then distributes that source to
> Person B, (b) Person B runs the generator, and distributes the source
> again, then Person B has no license to distribute the regenerated .texi
> file.  But, if we run the automatic conversion program automatically in
> the Makefiles this creates a trap for Person B.  And we shouldn't be
> trapping people.

A very big thanks for the answer and the explanation.

What I did not entirely understood in the recent decisions about
documentation & code is what bothers the GCC authorities (FSF or GCC
Steering Committee). Is it to mix documentation written by hand
(GFDL-ed) with documentation generated from GPL-ed code? Is it to
produce GPL-ed documentation?

For MELT there could be a very simple solution. I could very easily make
the generated meltgendoc.texi independent of gccint.texi by removing the
@include meltgendoc from gccint.texi and then writing by hand a small
meltint.texi file which @include-s meltgendoc.texi and distributing
separately meltint.pdf from gccint.pdf

If this could ease GCC decision makers, I could even change the format
of the generated documentations & :doc chunks, for instance by having it
in LaTeX instead of texinfo.

In other words, I do generate documentation from GPL-ed code, and if it
helps I could make that documentation entirely independent of existing
GCC documentation. Actually this has the advantage of producing a MELT
specific documentation sufficient for MELT as a plugin. The question
becomes what is the preferred license for this autonomous generated
documentation? I would imagine that GPL could be ok (since that
documentation is mostly derived from GPL code). But perhaps GCC
authorities don't want any kind of GPL-ed documentation!
> Therefore, I think that the generator program should *not* be run by
> default by the Makefiles.  It should spit out a warning about this
> problem when run.  And the generated .texi file should have a comment at
> the top explaining the problem.

Could you suggest me a sentence to output and to write? I am not a
native English speaker (my English is poor) and more importantly, I
don't understand the details of US principles of licensing & copyright.
(AFAIK, the US "fair use" does not exist in France).

A very big thanks for having replied and for reading me.


email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]