377 lines
17 KiB
HTML
377 lines
17 KiB
HTML
<!-- MHonArc v2.5.0b2 -->
|
|
<!--X-Subject: Critique of draft GNU Free Doucumentation License v1.0 -->
|
|
<!--X-From-R13: <qnirNynsa.bet> -->
|
|
<!--X-Date: Fri, 7 Jan 2000 15:57:00 -0500 (EST) -->
|
|
<!--X-Message-Id: 20000107122249.A193@localhost -->
|
|
<!--X-Content-Type: text/plain -->
|
|
<!--X-Head-End-->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML//EN">
|
|
<html>
|
|
<head>
|
|
<title>Critique of draft GNU Free Doucumentation License v1.0</title>
|
|
<link rev="made" href="mailto:dave@lafn.org">
|
|
</head>
|
|
<body>
|
|
<!--X-Body-Begin-->
|
|
<!--X-User-Header-->
|
|
<!--X-User-Header-End-->
|
|
<!--X-TopPNI-->
|
|
<hr>
|
|
[<a href="msg00999.html">Date Prev</a>][<a href="msg00991.html">Date Next</a>][<a href="msg00999.html">Thread Prev</a>][<a href="msg00984.html">Thread Next</a>][<a href="maillist.html#01000">Date Index</a>][<a href="threads.html#01000">Thread Index</a>]
|
|
<!--X-TopPNI-End-->
|
|
<!--X-MsgBody-->
|
|
<!--X-Subject-Header-Begin-->
|
|
<h1>Critique of draft GNU Free Doucumentation License v1.0</h1>
|
|
<hr>
|
|
<!--X-Subject-Header-End-->
|
|
<!--X-Head-of-Message-->
|
|
<ul>
|
|
<li><em>To</em>: <A HREF="mailto:ldp-discuss@lists.linuxdoc.org">ldp-discuss@lists.linuxdoc.org</A></li>
|
|
<li><em>Subject</em>: Critique of draft GNU Free Doucumentation License v1.0</li>
|
|
<li><em>From</em>: <<A HREF="mailto:dave@lafn.org">dave@lafn.org</A>></li>
|
|
<li><em>Date</em>: Fri, 7 Jan 2000 12:22:49 -0800</li>
|
|
<li><em>Cc</em>: <A HREF="mailto:rms@gnu.org">rms@gnu.org</A></li>
|
|
<li><em>Mail-followup-to</em>: ldp-discuss@lists.linuxdoc.org, rms@gnu.org</li>
|
|
<li><em>Resent-cc</em>: recipient list not shown: ;</li>
|
|
<li><em>Resent-date</em>: 7 Jan 2000 20:28:42 -0000</li>
|
|
<li><em>Resent-from</em>: <A HREF="mailto:ldp-discuss@lists.debian.org">ldp-discuss@lists.debian.org</A></li>
|
|
<li><em>Resent-message-id</em>: <XtMw.A.XWB.4xkd4@murphy></li>
|
|
<li><em>Resent-sender</em>: <A HREF="mailto:ldp-discuss-request@lists.debian.org">ldp-discuss-request@lists.debian.org</A></li>
|
|
<li><em>User-agent</em>: Mutt/1.0pre3i</li>
|
|
</ul>
|
|
<!--X-Head-of-Message-End-->
|
|
<!--X-Head-Body-Sep-Begin-->
|
|
<hr>
|
|
<!--X-Head-Body-Sep-End-->
|
|
<!--X-Body-of-Message-->
|
|
<pre>
|
|
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
|
|
|
|
</pre>
|
|
|
|
<!--X-Body-of-Message-End-->
|
|
<!--X-MsgBody-End-->
|
|
<!--X-Follow-Ups-->
|
|
<hr>
|
|
<ul><li><strong>Follow-Ups</strong>:
|
|
<ul>
|
|
<li><strong><a name="00984" href="msg00984.html">Re: Critique of draft GNU Free Doucumentation License v1.0</a></strong>
|
|
<ul><li><em>From:</em> Poet/Joshua Drake <poet@linuxports.com></li></ul></li>
|
|
<li><strong><a name="00992" href="msg00992.html">Re: Critique of draft GNU Free Doucumentation License v1.0</a></strong>
|
|
<ul><li><em>From:</em> Richard Stallman <rms@gnu.org></li></ul></li>
|
|
</ul></li></ul>
|
|
<!--X-Follow-Ups-End-->
|
|
<!--X-References-->
|
|
<!--X-References-End-->
|
|
<!--X-BotPNI-->
|
|
<ul>
|
|
<li>Prev by Date:
|
|
<strong><a href="msg00999.html">Re: [oswg-dis] [Fwd: Linux Documentation Infrastructure]</a></strong>
|
|
</li>
|
|
<li>Next by Date:
|
|
<strong><a href="msg00991.html">Re: Linux Documentation Infrastructure</a></strong>
|
|
</li>
|
|
<li>Previous by thread:
|
|
<strong><a href="msg00999.html">Re: [oswg-dis] [Fwd: Linux Documentation Infrastructure]</a></strong>
|
|
</li>
|
|
<li>Next by thread:
|
|
<strong><a href="msg00984.html">Re: Critique of draft GNU Free Doucumentation License v1.0</a></strong>
|
|
</li>
|
|
<li>Index(es):
|
|
<ul>
|
|
<li><a href="maillist.html#01000"><strong>Date</strong></a></li>
|
|
<li><a href="threads.html#01000"><strong>Thread</strong></a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<!--X-BotPNI-End-->
|
|
<!--X-User-Footer-->
|
|
<!--X-User-Footer-End-->
|
|
</body>
|
|
</html>
|