On Wed, 2 Jun 2010, Mark Mitchell wrote:
For API documentation, or, in general, for new manuals, I have no
opinion. My guess, though, is that the FSF would want the same
invariant sections and such as are on the existing manuals.
The standard rules for Cover Texts and inclusion of Invariant
On 02/06/2010 00:31, Mark Mitchell wrote:
At this point, RMS has said, answered this question from me:
Can we take comments (not code) from FSF-owned GPL'd code and process
them in some way that results in them being included in a GFDL'd manual?
by saying, in part:
If Texinfo text is
On 02.06.2010 01:31, Mark Mitchell wrote:
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether or not the GFDL is a free license, or whether it's a good
license, or anything else about its merits
Dave Korn wrote:
If Texinfo text is included the .h files specifically to be copied into
a manual, it is ok to for you copy that text into a manual and release
the manual under the GFDL.
In context, you means the GCC maintainers and the permission would
be limited only to changes
However, if I changed the code, but did not regenerate the docs, and you
then picked up my changes, possibly made more of your own, and then
regenerated the docs, *you* would be in breach. (Because my changes are
only available to you under the GPL; you do not have the right to
relicense my
Richard Kenner wrote:
However, if I changed the code, but did not regenerate the docs, and you
then picked up my changes, possibly made more of your own, and then
regenerated the docs, *you* would be in breach. (Because my changes are
only available to you under the GPL; you do not have the
Matthias Klose wrote:
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether or not the GFDL is a free license, or whether it's a good
license, or anything else about its merits or lack thereof
On 02/06/2010 15:07, Mark Mitchell wrote:
Richard Kenner wrote:
However, if I changed the code, but did not regenerate the docs, and you
then picked up my changes, possibly made more of your own, and then
regenerated the docs, *you* would be in breach. (Because my changes are
only
Dave Korn wrote:
Just to be clear, I don't believe that regenerating the docs itself would
be a breach since NOTHING you do internally can be a GPL or GFDL breach).
What would be a breach would be *distributing* those regenerated docs.
Indeed; I was too casual in my description. Dave can
As I mentioned last week, I've been talking to the SC and RMS about the
issue of automatically generating GFDL'd documentation from GPL'd code.
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether
Quoting Mark Mitchell m...@codesourcery.com:
At this point, RMS has said, answered this question from me:
Can we take comments (not code) from FSF-owned GPL'd code and process
them in some way that results in them being included in a GFDL'd manual?
We also need struct member declarations.
Joern Rennecke wrote:
And if we need
more (as I suspect), can we be specific about what toolflow we want to
follow and what content will be generated? It would help if I could
show RMS inputs and outputs, not just with some random example, but with
GCC itself. Is someone willing to apply
Mark Mitchell m...@codesourcery.com writes:
So, my question is this: is the permission above sufficient for what
people want to do at this point?
This permission exactly covers what libiberty does for its
documentation, you can use that as an example to RMS.
Quoting Mark Mitchell m...@codesourcery.com:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02255.html
OK, I see what that is doing. Why did you choose to use a .def file
rather than something more like Doxygen to generate the documentation?
It is not only used to generate documenation, but
14 matches
Mail list logo
