Critique of draft GNU Free Doucumentation License v1.0

[<dave@lafn.org>]

		Critique by David S Lawyer (Jan. 6, 2000)
	  of DRAFT: GNU Free Documentation License Version 1.0

Overall I am disappointed with this GNU draft license by Richard
Stallman.  I think it has too many restrictions on modification and is
too complicated.  There is so much that needs changing that I would
propose a complete rewrite of it.

INVARIANT SECTIONS ETC.
I think that the "Invariant Sections" and "Cover Texts" parts should
be eliminated.  The problem is that they can be abused.  One may put
any non-technical material here and be assured that it will appear
years later in modified versions.  Even someone that only wanted to
use a small part of a document would need to include the full
invariant text in the derived work.

It's nice that one could express their political views in "Invariant
Sections", but what if it contains misleading information or an unduly
biased approach to the subject.  What if it's partly (or entirely)
advertising?  Are there any limits as to how long this could be?
Suppose that circumstances have made the invariant section obsolete.
How can it be altered or removed?

You may say that to change an invariant section all you need to do is
to obtain the permission of the author.  What if the author can't be
located?  Also, just the permission of the author may not be enough.
Changing an invariant section requires an exception be made to the
license.  Suppose A is the author, then B modified it some and then C
modified B's document.  Then if D want to modify C's work and change
the "Invariant Sections" D must get permission from A, B and C.  After
a long period of time one might need permissions from A, B, C, ..., Z
where some of the people can't be located (including cases where
people have died, etc.).  Also it's not majority rule since all need
to agree.  

Even if the benefits of having invariant sections outweighed the
negative aspects, the fact that it makes the license much longer and
complex is an argument against it.  Without invariant sections one can
still put such material in documents, but anyone who doesn't like it
can remove it.  In some cases where the material doesn't belong in the
document, such removal will be justified.  In other cases removing it
will not be justified, and the author's recourse will be to post
complaints on the Internet.  Of course what is "justified" or not is
often a matter of opinion.

MANUAL?

The draft license refers to each document as a manual.  In Linux the
word "manual" brings to mind the man pages and manuals that come with
application software.  I think the word "document" is broader and
should be used instead of "manual".

TWO-PART LICENSE

In order to make a license contained in a document very small in size
I would suggest that each document contain a very short license that
points to a url for the full text.  Such a license might read:

Please freely copy and distribute (sell or give away) this document.
Any modifications must conform to the full text of the GNU Free
Documentation License at www.gnu.org/...

Most people that get a document will not want to modify it for
redistribution.  Most people will understand that modifying it for
personal use is OK.  It's something like writing notes in the margins
of a book.  However many people will obtain the document as a download
and this short license lets them know that their copying of it was OK.
They also know it's OK to give others copies or put a copy on their
website.

NOT INTEROPERABLE WITH GPL

There are many LDP documents licensed under GPL.  It would be nice if
one could merge a document licensed under GPL with one licensed under
the GNU Free Documentation License.  Unfortunately, each of these
"free" licenses requires that derivative works be licensed under the
same license, so this can't be done.

TRANSPARENT COPIES
It's important to insure that people have access to copies that can be
readily modified and read using free software.  But I would suggest
handling it differently.  For any modified version I would require
that a transparent copy be placed at a well known Internet site (such
as LDP's with a large number of mirrors) for free distribution.
Provision should be made for the case where the modified version is so
poor in quality that no reputable site wants to accept it.  In such a
case the modifier would still need to post it on his own website (or
the like).

Opaque copies could be distributed in any volume provided there were
well know sites where the same (or a "better") version could be
obtained.  HOWTOs often need revision monthly and it makes little
sense to require that old versions be kept unless important
information has been deleted from the old version.  The draft didn't
seem to take into account that number of copies that the number of
copies in a distribution of a Manual is often unknown in advance.
This is especially true when someone places a work on a website for
distribution by free downloading.

Remember that people in the MS Windows world consider that formats
such as PDF, Word, and WordPerfect are standard formats for interchange
of information.  I don't like this but I also think it's good that
free software and documents from GNU/Linux have been entering into the
world of Ms Windows.  People that are used to dealing with these
opaque formats don't want to have to learn about using new tools view
them.

FREQUENCY of MODIFICATION

It seems that this draft did not consider the possibility that in some
cases documents may be modified as often as weekly.  Even with the
current HOWTOs, an author may get a few emails a week commenting on
his HOWTO and make about one change per week to the HOWTO.  It's not a
bad idea to post this modified document so that people may use the
improvement/correction in it right away.  

Why do things change so frequently?  For one, there are numerous
distributions of Linux and they may frequently change their
installation and configuration procedures.  New software and debugging
tools appear and old software is improved.  Hardware is frequently
changing as new models are introduced.  In addition, a HOWTO may have
numerous url links to other documents on the Internet.  Not only do
these urls change (and sometimes disappear) but new urls need to be
frequently added.  Also, readers or the author may discover ways to
improve clarity, find mistakes that people frequently make (and need
listing by symptom), devise new troubleshooting ideas, etc.   While
few (if any) HOWTOs are currently submitted weekly, my HOWTOs often do
change approximately weekly (although I don't submit them weekly
--perhaps I should).  In the future one may expect more frequent
changes and daily changes are not to be ruled out as the popularity of
Linux grows.

COMMENTS ON SPECIFIC PARTS:
0.  The GNU Project designed this, the GNU Free Documentation License,
for use with documentation about free software.

My comment:
The LDP HOWTOs are only in part documentation about free software.
Documentation about software programs generally comes with the
software and are not written by the LDP.  The HOWTOs are integrative
and often take a systems approach.  They cover how to get certain
tasks done using various combinations of software and hardware.
Sometimes they discuss theory and protocols.  To think that the HOWTOs
are documents about free software is a gross oversimplification.
Could not the GNU Free Documentation License be designed for
documentation relating to computer systems operating primarily on free
software?

2. You may copy and distribute the Manual in any medium .....

   You may also lend copies, under the same conditions stated above,
   and you may publicly display copies.

My comment:
Once you have given anyone the right to copy and distribute a work,
have you not implicitly given them the right to lend and display the
work.  Also, why is it necessary to grant such a right since copyright
law doesn't prohibit lending or displaying a copyrighted work?  Of
course copyright law doesn't allow one to "display" a copyrighted work
on the Internet since that is tantamount to allowing others to copy it.

2.
A. Entitle your Modified Version with the Manual's title, plus
   some additional words (or a subtitle) stating that the version has
   been modified, and distinguishing it from the Manual you started with.
   (Additions to the title are not required if the original publisher
   of the version you started with waives this requirement.)

My comment:
What if the title need changing.  Suppose the scope is expanded by the
modification.  Fictions examples are: "Terminal-Server-HOWTO" might become
"Remote-Access-Server-HOWTO", "Analog-Modem-HOWTO" might become
Modem-HOWTO".  There is also the possibility for narrowing the scope.
For example, I lifted material from Serial-HOWTO and created: 1.
Modem-HOWTO and 2. Text-Terminal-HOWTO.

C. Mention on the Title Page at least one name of a person or entity
   responsible for authorship of the modifications in the Modified
   Version and/or publication of the Modified Version, and describe
   that entity's relationship to the Modified Version.  (This requirement
   may be waived by the original publisher of the version you started with.)
 
My comment:
At least the main person (or entity) responsible for the modification
should be listed.  This doesn't require this for two reasons.  For
one, all that is required is to list the person responsible for the
"publication".  This could just be the person that uploads the
modified document to a website.  Putting a document at a website is a
form of "publication".

The requirement is for at least one name.  Suppose two people modify a
document but one of them does much more of it than the other.  As
written, the one least responsible for the modification could put
their name on the modification thereby concealing the name of the
person who did most of the modification.

D. Retain on the Title Page or its continuation the authors' and publishers'
   names listed on the Manual's Title Page.

My comment:
A document may be modified, merged, and diverged many times.
Eventually the contribution of the original author(s) may become almost
obliterated.  When this happens they should no longer be mentioned on
the title pages but instead should be put into the "credits" section
(if there is one).  A document could wind up with a long list of names
on the title page that actually belong in the credits section.

Another problem is: who are the publishers?  For example take the case
of the HOWTOs.  Is Metalab the publisher?  Is the Linux Documentation
Project the publisher?  Is every mirror site that gets the HOWTO a
publisher?  It the author/maintainer who emails the doc to be posted a
publisher?  Perhaps the HOWTO coordinator who uploads the doc to
Metalab is the publisher.  Then again, perhaps none of the above are
publishers.  It's not clear.

E. Preserve all the copyright notices of the Manual.

My comment:
If only a small portion of the "Manual" has been used in the "modification"
the previous copyright notices should not need to be included.
However a note about this belongs in the "credits" section.

I. Include an unaltered copy of this License.

My comment:
I think a brief statement plus a pointer to the License should be
enough.

J. Preserve the network location, if any, given in the Manual for
   public access to a Transparent copy of the Manual, and likewise
   those network locations given in the Manual for any earlier
   works it was based on (but you may delete those for works
   that were published at least four years before the Manual itself).

My comment:
As a document is modified, it goes through various versions and in
some cases the document could be modified weekly.  It would be
impractical to have pointers to all the old versions.  Also, in the
case of the HOWTOs old versions are often not to be found on the
Internet.  When they are found, they are often at an obscure (or
unmaintained) site that neglected to get an updated copy of the
"manual".  There is not much point in having a pointer to such a site
since the old version may not be there long.

7. TRANSLATION
... (about invariant sections)

   You may include a translation of this License provided that you
   also include the original English version of this License.  In case
   of a disagreement between the translation and the original English
   version of this License, the original English version will prevail.

My comment:
Would it not be simpler to just require a pointer to the English
version?  The translate licenses should be available on the Internet
so that there would then be a pointer to both the English and
translated versions.

9. FUTURE REVISIONS OF THIS LICENSE
.....
   Each version of the License is given a distinguishing version
   number.  If the Manual specifies that a particular numbered version
   of this License "or any later version" applies to it, you have the
   option of following the terms and conditions either of that
   specified version or of any later version that has been published
   by the Free Software Foundation.  If the Manual does not specify a
   version number of this License, you may choose any version ever
   published by the Free Software Foundation.

My comment:
What if the license specifies only a certain version?  This is
apparently permitted.  In that case (see section 4G of the draft) any
modification must be licensed under the same version.  Thus in some
cases one will not be able to merge two documents even when they have
the same GNU License.  This would be the case if the two documents
specify different versions (without the phrase "or any later version").
Also for example, if one document says version 1.0 and another says
1.1 or later, these are not compatible.

			David Lawyer


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org