[please cc me]
David Starner <dstarner98@aasaa.ofe.org> writes:
> If there's an exception for non-topical chapters, then why not for
> standards?
Because these are completely different things, see below.
> A non-topical chapter is more likely to get out of date than a
> standard, which by design is intended to be eternally fixed.
Clarification: the FDL restricts non-modification to quite specific
sections, non-topicality is only one necessity. From the horses mouth:
A ``Secondary Section'' is a named appendix or a front-matter
section of the Document that deals exclusively with the
relationship of the publishers or authors of the Document to the
Document's overall subject (or to related matters) and contains
nothing that could fall directly within that overall subject.
(For example, if the Document is in part a textbook of
mathematics, a Secondary Section may not explain any mathematics.)
The relationship could be a matter of historical connection with
the subject or with related matters, or of legal, commercial,
philosophical, ethical or political position regarding them.
You can probably see now how information in these secondary sections
does not get obsolete (only maybe uninteresting). The notion that
standards do not get out of date can't be meant seriously in a world of
SQL92, IPv6, C89, etc. etc.
> In any case, the DFSG offers exceptions for neither, so the
> non-modification clause in the GNU FDL is not _okay_ with the DFSG.
> By the strict reading of the DFSG, if it is to apply to documentation
> and RFC's, modificiation must be allowed.
No. Modification to the content must be allowed ... certainly not
modification to the metadata. You can't take package X from main,
change /usr/share/doc/X/copyright, and redistribute it (except for
packages in the public domain).
Whether something is really metadata is a matter of interpretation,
and may depend on the specific case.
Personally, I think all those people/organisations that want to
protect the sancticity of their standard should just require
derivative works to bear different names (or versions).
--
Robbe
Attachment:
signature.ng
Description: PGP signature