Problems in GNU FDL 1.2 Draft
I've subscribed to the debian-legal mailing list purely out of interest,
and have seen the request for comments on the GNU FDL 1.2 Draft.
Several of the discussions on debian-legal over the past six months have
got me to thinking, and looking over the draft I have finally figured
out precisely what bothers me about the GNU FDL; I hope that I can
express my concerns clearly enough.
> We have designed this License in order to use it for manuals for free
> software, because free software needs free documentation: a free
> program should come with manuals providing the same freedoms that the
> software does. But this License is not limited to software manuals;
> it can be used for any textual work, regardless of subject matter or
> whether it is published as a printed book. We recommend this License
> principally for works whose purpose is instruction or reference.
I quote this primarily to establish that the FDL is intended to be used
for documentation for free software. I do not object to this, but part
of my objection is strengthened by this fact.
> 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. (Thus, 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.
>
> The "Invariant Sections" are certain Secondary Sections whose titles
> are designated, as being those of Invariant Sections, in the notice
> that says that the Document is released under this License. If a
> section does not fit the above definition of Secondary then it is not
> allowed to be designated as Invariant. The Document may contain no
> Invariant Sections.
One problem with Invariant Sections that I haven't seen mentioned before
is that once a Secondary Section has been declared as Invariant, the
main Document may no longer be modified to have as part of its overall
subject the contents of the Secondary Section. That is, that subject is
not part of the overall subject matter *now*, but once there is an
Invariant Secondary Section added, it may never be in the future,
either.
For instance, if a Document has a Secondary Section which explains some
mathematics, I am thereby forbidden to add any mathematics as part of
the "overall subject" of the main document, even though a unifying
mathematical theory may have been discovered since the original document
was written, and would be of great use in simplifying and extending the
original document. Additionally, I am now forbidden to add any
significant amount of text to the GNU Emacs manual concerning the
economics of Free Software development because of the Invariant Section
on Funding Free Software. I understand that the intent of Invariant
Sections is to prevent their removal, but they are also preventing the
addition of other parts. For anything except absolutely trivial
Invariant Sections, this is a severe limitation on the Freeness of the
Document.
If I release a piece of software with Invariant Sections in the code, it
would immediately (and rightly) be flagged as non-Free. However, I
could conceivably write a document with Invariant Sections under the
GFDL and it would be considered Free under the GNU FDL, yet I could not
include it in a piece of software licensed under the GPL, because it is
not Free according to the GPL. However (and this is where it is
important that the FDL is intended to be used for manuals for free
software), this is a fairly common occurrence to want to do this - it is
nice for a piece of software to display its documentation in reponse to
the "Help" command. Under other circumstances, it is roundly condemned
if one were to take a piece of Free Software and attempt to include a
piece that is not Free by means of dynamic linking - yet it appears to
be acceptable to add a piece of documentation to the software which
would be labeled non-Free if it was included in the code, so long as it
is done by dynamic loading at run time in response to a request for
documentation. This strikes me as hypocritical.
Languages like Knuth's Web where code and documentation are interleaved
in a single file further blurs the line; if such languages become more
popular in the future, or if currently used languages acquire such
features, we will find that we do not have the Freedom to do so. I look
to the Free Software Foundation to protect against such a future, not to
create it.
> If you publish printed copies (or copies in media that commonly have
> printed covers) of the Document, numbering more than 100, and the
> Document's license notice requires Cover Texts, you must enclose the
> copies in covers that carry, clearly and legibly, all these Cover
> Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
> the back cover. Both covers must also clearly and legibly identify
> you as the publisher of these copies. The front cover must present
> the full title with all words of the title equally prominent and
> visible. You may add other material on the covers in addition.
> Copying with changes limited to the covers, as long as they preserve
> the title of the Document and satisfy these conditions, can be treated
> as verbatim copying in other respects.
>
> If the required texts for either cover are too voluminous to fit
> legibly, you should put the first ones listed (as many as fit
> reasonably) on the actual cover, and continue the rest onto adjacent
> pages.
Hmm.... this seems familiar. Where have I seen a license before that
required large amounts of invariant text to be printed, even if it was
inconvenient and required more space, and a well written objection to
it? Ah, yes, right here:
http://www.gnu.org/philosophy/bsd.html
I'm only going to suggest that one should consider pots and kettles
*very* carefully, in light of the above referenced commentary on the
*BSD license before finalizing the new GNU FDL. Eliminating Invariant
Sections as a permitted part of the FDL will also eliminate this
potential problem.
--
Stephen Ryan Debian GNU/Linux
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College
Reply to: