New Documentation License--Comments Requested
Richard Stallman
draft of it. Please don't use it yet; I have not finished checking
it. But please do give me constructive comments for improving the
details of it. I can make use of them to improve version 1.0.
GNU Free Documentation License Version 0.9
DRAFT
0. PREAMBLE
The GNU Free Documentation License is a form of copyleft designed for
books, such as reference manuals and tutorials. We designed it in
order to use it for documentation about free software, but it can be
used regardless of the subject matter. It can also apply to textual
works that are not released in book form. It gives users the right to
copy, redistribute and modify the work, just as users have the right
to copy, redistribute and modify free software.
1. APPLICABILITY
This License applies to any manual or other work which contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License. The "Manual", below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you".
A "Modified Version" of the Manual means any work containing the
Manual or a portion of it, either copied verbatim or with
modifications and/or translated into another language.
The "Invariant Sections" are certain appendices or front-matter
sections of the Manual, which deal exclusively with nontechnical
matters (such as the political views, histories or legal positions of
the authors), and whose titles are listed as Invariant Sections in
the notice saying that the Manual is released under this license.
The "Front-Cover Texts" are certain short passages of text are listed as
Front-Cover Texts or Back-Cover Texts in the notice saying that the
Manual is released under this license.
A "Transparent" copy of the Manual means a machine-readable copy,
represented in a format whose specification is available to the
general public, in which the text may be viewed straightforwardly with
ordinary text editors, and which is suitable for input to text
formatters or for automatic translation to a variety of formats
suitable for input to text formatters. Examples of suitable formats
for transparent copies include Texinfo input format, LaTeX input
format, SGML, and standard-conforming HTML. A copy that is not
"Transparent" is called "Opaque".
The "Title Page" means, for a printed book, the title page; for works
in other formats where there is no title page as such, it means the
text near the most prominent mention of the work's title, preceding
the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Manual, in any medium, either
commercially or noncommercially, provided that this license is
reproduced in all copies, and you add no other conditions whatsoever
to those of this license. You may accept compensation in exchange for
copies, but you may not technically obstruct the reading or further
copying of the copies you make or distribute.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
It is requested, but not required, that you give the authors of the
Manual thirty days (or more) advance notice of your plans to
redistribute any large number of copies, to give them a chance to
provide you with an updated version of the Manual.
3. COPYING IN QUANTITY
If you publish or distribute printed copies of the Manual numbering
more than 100, and the Manual'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. If the required texts for either
cover are too voluminous to fit legibly, put the first ones listed (as
many as fit reasonably) on the actual cover, and continue the rest
onto adjacent pages.
If you publish or distribute Opaque copies of the Manual numbering
more than 100, you must state in or with each copy a publicly
accessible computer network location containing a Transparent copy of
the Manual, no more and no less, which the general network-using
public has access to download at no charge. You must take reasonably
prudent steps, when you begin distribution of Opaque copies in
quantity, to ensure that this Transparent copy will remain thus
accessible at the stated location until at least six months after you
last distribute an Opaque copy.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Manual under the
conditions of section 2 and 3 above, provided that you release the
Modified Version under precisely this license, with the Modified
Version filling the role of the Manual, thus licensing use of the
Modified Version to whoever possesses a copy of it. In addition, you
must do these things in the Modified Version:
A. Mention the Manual's title on the Title Page.
B. Add something to the title, or a subtitle, stating that the version has
been modified, and distinguishing it from the Manual you started with.
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.
D. Retain on the Title Page or its continuation the authors' and publishers'
names listed on the Manual's Title Page.
E. Preserve all the copyright notices of the Manual.
F. Add an appropriate copyright notice for your own work.
G. Include after them a notice stating giving the public permission to
use the Modified Version under the terms of this license,
in the form shown in the Addendum below.
H. Preserve in that notice the full list of Invariant Sections,
and the full list of required Cover Texts, given in Manual's notice.
I. Include an unaltered copy of this license.
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
versions it was based on.
K. If the Manual has an Acknowledgements and/or Dedications section,
preserve therein all the substance of each of the contributor
acknowledgements and/or dedications stated therein.
L. Preserve all the Invariant Sections of the Manual,
unaltered in text and in their titles.
If the Modified Version includes new front-matter sections (or
appendices) which deal exclusively with nontechnical matters, and
contain no material copied from the Manual, you may at your option add
the section titles of any or all of these sections to the list of
Invariant Sections in the Modified Version.
You may add up to five words of Front-Cover Text and up to 25 words of
Back-Cover Text to the end of the list of Cover Texts in the Modified
Version.
The author(s) and publisher(s) of the Manual do not by this license
give permission to use their names for publicity or to assert or imply
endorsement of any Modified Version.
5. COMBINING MANUALS
You may combine the Manual with other manuals released under this
license, under the terms of section 3 above as for modified versions,
provided that you include all of the Invariant Sections of all of
the original manuals, unmodified, in the combination, and list them
all as Invariant Sections in your combined work.
The combined work need only contain one copy of this license, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end, in parentheses, the name of the original author or
publisher of that section if known, otherwise the name of an author or
publisher of the manual that section came from; and make the same
adjustment in the list of Invariant Sections in the license of the
combined work.
6. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Manual or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Manual, provided no compilation copyright is claimed for the
compilation. In such a case, this license does not apply to the other
self-contained works thus compiled with the Manual, if they are not
derivative works of the Manual.
7. TRANSLATION
Translation is considered a kind of modification, so you can
distribute translations of the manual under the terms of section 4.
This implies that translation of the Invariant Sections requires
special permission from their copyright holders. You may include a
translation of this license provided that you also include this
license in the original English version. In case of a disagreement
between the translation and the English version of this license, the
English version will prevail.
8. TERMINATION
You may not copy, modify, sublicense, or distribute the Manual
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Manual is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
9. ADDENDUM: How to use this license for your manuals
To use this license in a manual you have written, put the following
notice on the page after the title page:
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this
manual under the terms of the GNU Free Documentation License,
Version 1.0 or any later version published by the Free Software
Foundation, with the Invariant Sections being LIST THEIR TITLES,
Front-Cover Texts being LIST, and Back-Cover Texts being LIST.
A copy of the license is included in the section entitled "GNU
Free Documentation License"
If you have no Invariant Sections, write "with no Invariant Sections"
instead. If you have no Front-Cover Texts, write "no Front-Cover Texts"
instead of "Front-Cover Texts being LIST". Likewise for Back-Cover Texts.
Stephan Boettcher
Richard Stallman <r...@gnu.org> writes:
> You may add up to five words of Front-Cover Text and up to 25 words of
> Back-Cover Text to the end of the list of Cover Texts in the Modified
> Version.
How is this enforcable? I may license the modified version to myself,
and modify it again, adding another 5/25 words. No?
Kind regards
Stephan
--
------------------------------------------------------------------------
Stephan Boettcher FAX: +1-914-591-4540
Columbia University, Nevis Labs Tel: +1-914-591-2863
P.O. Box 137, 136 South Broadway mailto:ste...@nevis1.columbia.edu
Irvington, NY 10533, USA http://www.nevis.columbia.edu/~stephan
------------------------------------------------------------------------
Ulrich Windl
licence, and to point out the differences to GPL and LGPL.
Otherwise it seems quite acceptable (to me).
--- &disclaimer; ---
Ulrich Windl <Ulrich...@rz.uni-regensburg.de+no-spam>
Steven Michael ROBBINS
Ulrich Windl <wiu0...@rrzc5.rz.uni-regensburg.de> wrote:
> I think it would be helpful to explain the reasons why to create a new
> licence, and to point out the differences to GPL and LGPL.
... and *especially* to the OPL from the OpenContent folks
<http://www.opencontent.org> who seem to have exactly the
same goal of "GPL for non-programs".
David Woolley
Richard Stallman <r...@gnu.org> wrote:
>
>The GNU Free Documentation License is a form of copyleft designed for
This is an FSF "marketing" term, for certain types of copyright
licence; I don't think it has any right to be in a legal document
except as a term defined by that document.
>suitable for input to text formatters. Examples of suitable formats
>for transparent copies include Texinfo input format, LaTeX input
>format, SGML, and standard-conforming HTML. A copy that is not
Standards conforming HTML is covered by SGML, but HTML can be standards
conforming and pretty opaque when created using authoring tools and SGML
is much much more general than the Linux Documentation Project's document
type definition (not quite HTML, but Office 2000 tries to produce
XHTML with all the proprietory semantics of Word).
With the use of WYSIWYG editors, Postscript or PDF (you can have
uncompressed PDF) may be the nearest that you can realistically
expect people to get to an open format without compromising the
document's structure.
Current standards conforming HTML doesn't support line drawings and
accessibility probably requires the use of GIF rather than PNG for
illustrations.
>"Transparent" is called "Opaque".
I really need to read this more carefully at home, but given the level
of fear uncertainty and doubt that has arisen over the interpretation
of the GPL, to the extent that most commercial organisations will stay
well clear of GPLed software for external use, I think that the wording
needs to be extrememly precise.
Barry Margolin
David Woolley <da...@djwhome.demon.co.uk> wrote:
>With the use of WYSIWYG editors, Postscript or PDF (you can have
>uncompressed PDF) may be the nearest that you can realistically
>expect people to get to an open format without compromising the
>document's structure.
The problem is that Postscript and PDF aren't really designed to be
editable. Transparent documents are intended to be revisable.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Christopher Browne
<da...@djwhome.demon.co.uk> wrote:
>In article <gnusenet199909...@psilocin.gnu.org>,
>Richard Stallman <r...@gnu.org> wrote:
>>for transparent copies include Texinfo input format, LaTeX input
>>format, SGML, and standard-conforming HTML. A copy that is not
>
>conforming and pretty opaque when created using authoring tools and SGML
>is much much more general than the Linux Documentation Project's document
>type definition (not quite HTML, but Office 2000 tries to produce
>XHTML with all the proprietory semantics of Word).
I'd suggest rewording it thus:
"Examples of formats likely to be suitable for ``transparent''
copies include Texinfo input format, LaTeX input format, and formats
conforming to some publicly-defined and publicly-available SGML or
XML DTD such as DocBook, LinuxDoc, HTML 3.2, or HTML 4.0."
- By saying "likely to be suitable" this removes the implication that
HTML is *forcibly* an acceptable format.
- I would recommend naming some DTDs rather than merely saying "SGML,"
since it is *not* a language in which *documents* are written. SGML
is the language in which DTDs are written.
- The requirement that DTDs be "publicly-defined and
publicly-available" rules out the notion that Microsoft's "XHTML,"
and other forms that are deliberately proprietary, could be
considered acceptable. There may be a better way of saying this
than the rather wieldy "publicly-defined and publicly-available."
- The use of the term "conforming" mandates that the document "plays
at least a bit nicely."
>With the use of WYSIWYG editors, Postscript or PDF (you can have
>uncompressed PDF) may be the nearest that you can realistically
>expect people to get to an open format without compromising the
>document's structure.
PDF is most definitely an "opaque" format, by almost any metric, as it
is *not* a format that is directly editable. PDF documents are
produced by taking a document written in some other form and
"distilling" it into PDF; they are in no way a "source format."
Similarly, while there are some people that have written books in
Postscript, and promote such, as documented at
<http://www.cappella.demon.co.uk/tinyfiles/tinydict.html>, Postscript
is *normally* treated as an "opaque" format that is not editable.
The point of the exercise here is thus:
a) To downright *REJECT* the use of formats that do not permit people
to manipulate the document's structure,
b) To discourage the use of formats that *do* permit document
manipulation but which are not desirable as they involve proprietary
restrictions of some sort.
Examples:
- MS Word ".doc" is manipulable, but fails due to b), as the software
required for that manipulation is proprietary.
- MSFT XHTML is reasonable for a) if it is editable using (say) Word
2000, but fails on b), as Word 2000 is proprietary.
- Framemaker is reasonable for a), but fails on b) under the same
reasoning as is true for MS Word.
- PDF fails on a), as it is not a form that permits ready manipulation
of document structure/contents.
- Postscript fails on a) (except in the pathological case where the
author actually *does* compose the document in raw Postscript), as
it is not usually manipulable.
- GIF fails as an image format due to the proprietary restriction
resulting from US patent 4558302.
>Current standards conforming HTML doesn't support line drawings and
>accessibility probably requires the use of GIF rather than PNG for
>illustrations.
JPEG represents a perhaps acceptable alternative at present; it won't
be acceptable to use GIF until US patent 4558302 expires in 2002. Or
are you implying that the FSF counsel folks that produce documents to
infringe on the Unisys patent?
It may prove necessary to make some technical compromises as a result
of the need to satisfy the requirement that "accessibility" includes
the property of the format not being under proprietary control.
>>"Transparent" is called "Opaque".
>
>I really need to read this more carefully at home, but given the level
>of fear uncertainty and doubt that has arisen over the interpretation
>of the GPL, to the extent that most commercial organisations will stay
>well clear of GPLed software for external use, I think that the wording
>needs to be extremely precise.
... which is precisely why it is nice that a draft is available now
for comment ...
My sense is that the term "Transparent" perhaps should be retermed
"Transparent Source," as this diminishes the ability of the obstinate
to choose to misread it such that they might treat formats that are
almost never "Source" formats as the publicly available format for a
document...
--
quit When the quit statement is read, the bc processor
is terminated, regardless of where the quit state-
ment is found. For example, "if (0 == 1) quit"
will cause bc to terminate.
(Seen in the manpage for "bc". Note the "if" statement's logic)
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/printing.html>
Christopher Browne
<bar...@bbnplanet.com> wrote:
>In article <FI1qG...@bts.co.uk>,
>David Woolley <da...@djwhome.demon.co.uk> wrote:
>>uncompressed PDF) may be the nearest that you can realistically
>>expect people to get to an open format without compromising the
>>document's structure.
>
>editable. Transparent documents are intended to be revisable.
The whole point of the notion of a "transparent" format is that the
document be editable; this means that the *intent* is that there be a
direct ability to "compromise the document's structure."
--> It should be possible for me to add a chapter in the middle to
further explain some confusing topic.
--> It should be possible to add extra diagrams, if necessary.
--> It should be possible to add an extra index.
--> Supposing a new version of a software package comes out, it should
be possible for me to rewrite material throughout to document the
new functionality.
These are all sorts of things that it is intended that people be able
to do to the documents thus licensed. Such changes would be
unrealistic to *attempt* with PDF, where there are only a relatively
small number of "manipulations of view" that are possible.
Many of these sorts of changes *will* affect the document's structure;
the license clearly is inappropriate for documents where someone feels
that the document structure they have established must be rigidly
observed without change.
--
"I will not send lard through the mail" ^ 100 -- Bart Simpson
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/wpdpl.html>
Gerhard Poul
> These are all sorts of things that it is intended that people be able
> to do to the documents thus licensed. Such changes would be
> unrealistic to *attempt* with PDF, where there are only a relatively
> small number of "manipulations of view" that are possible.
what about writing "it has to contain only plain-ASCII text"??
or 7-bit ASCII
this should be enough...
regards
gerhard
Michael Fischer v. Mollard
> I'd suggest rewording it thus:
>
> "Examples of formats likely to be suitable for ``transparent''
> copies include Texinfo input format, LaTeX input format, and formats
> conforming to some publicly-defined and publicly-available SGML or
> XML DTD such as DocBook, LinuxDoc, HTML 3.2, or HTML 4.0."
>
> - By saying "likely to be suitable" this removes the implication that
> HTML is *forcibly* an acceptable format.
>
> - I would recommend naming some DTDs rather than merely saying "SGML,"
> since it is *not* a language in which *documents* are written. SGML
> is the language in which DTDs are written.
>
> - The requirement that DTDs be "publicly-defined and
> publicly-available" rules out the notion that Microsoft's "XHTML,"
> and other forms that are deliberately proprietary, could be
> considered acceptable. There may be a better way of saying this
> than the rather wieldy "publicly-defined and publicly-available."
>
> - The use of the term "conforming" mandates that the document "plays
> at least a bit nicely."
I agree with your suggestions, but I still have a problem: If a manual
originally is written with the DocBook DTD, which is a really nice and
very transparent format for writing documentation, and somebody decides
to modify eg the HTML output, the modification isn't very usefull for
the public as it 'branches' the documentation. But this is still defined
to be a transparent copy, and publishing it would be enough to fullfill
condition 3. Did I miss some terms forbidding this or is this a gap in
the draft?
> >With the use of WYSIWYG editors, Postscript or PDF (you can have
> >uncompressed PDF) may be the nearest that you can realistically
> >expect people to get to an open format without compromising the
> >document's structure.
>
> PDF is most definitely an "opaque" format, by almost any metric, as it
> is *not* a format that is directly editable. PDF documents are
> produced by taking a document written in some other form and
> "distilling" it into PDF; they are in no way a "source format."
>...
> My sense is that the term "Transparent" perhaps should be retermed
> "Transparent Source," as this diminishes the ability of the obstinate
> to choose to misread it such that they might treat formats that are
> almost never "Source" formats as the publicly available format for a
> document...
As this seems to be a point of uncertainity one could explicitly define
pdf and ps to be opaque.
--
MFvM
Michael Fischer v. Mollard
mf...@gmx.de
Phil Hunt
cbbr...@hex.net "Christopher Browne" writes:
> >Richard Stallman <r...@gnu.org> wrote:
> >>suitable for input to text formatters. Examples of suitable formats
> >>for transparent copies include Texinfo input format, LaTeX input
> >>format, SGML, and standard-conforming HTML. A copy that is not
>
> Similarly, while there are some people that have written books in
> Postscript, and promote such, as documented at
> <http://www.cappella.demon.co.uk/tinyfiles/tinydict.html>, Postscript
> is *normally* treated as an "opaque" format that is not editable.
>
> The point of the exercise here is thus:
>
> a) To downright *REJECT* the use of formats that do not permit people
> to manipulate the document's structure,
>
> b) To discourage the use of formats that *do* permit document
> manipulation but which are not desirable as they involve proprietary
> restrictions of some sort.
Since the intention is the same as the GPL's provision regarding
source code, why not use similar language, e.g:
``a transparent copy is a copy made in the preferred form of the
work for making modifications to it''
--
Phil Hunt - - - - - - - - - ph...@vision25.demon.co.uk
- Linux will be 8 years old on 17th September! See: -
http://www.vision25.demon.co.uk/prog/linuxbirthday.html
Dylan Thurston
> I agree with your suggestions, but I still have a problem: If a manual
> originally is written with the DocBook DTD, which is a really nice and
> very transparent format for writing documentation, and somebody decides
> to modify eg the HTML output, the modification isn't very usefull for
> the public as it 'branches' the documentation. But this is still defined
> to be a transparent copy, and publishing it would be enough to fullfill
> condition 3. Did I miss some terms forbidding this or is this a gap in
> the draft?
It's not a bug; it's a feature. All sorts of modifications are
allowed to a document, including branching it, translating it into
another language, or converting from very transparent DocBook SGML to
less transparent HTML, as long as some sort of transparent copy is
available (and all the other conditions, preserving authors names,
etc, are kept).
It would be unreasonable to require that all derived versions use the
same formatting system as the original. What happens in 20 years that
way?
--Dylan Thurston
d...@math.berkeley.edu
Barry Margolin
Phil Hunt <ph...@vision25.demon.co.uk> wrote:
>Since the intention is the same as the GPL's provision regarding
>source code, why not use similar language, e.g:
> ``a transparent copy is a copy made in the preferred form of the
>work for making modifications to it''
I think because many people may "prefer" to use proprietary formats like MS
Word .doc files. These are transparent if you happen to have the non-free
software that supports it, but they're opaque to others (although in the
case of Word documents, just about every word processor can import them and
convert them to its own format).
There's an oft-raised issue with the GPL regarding software written in a
language for which there are only proprietary compilers. This meets the
letter of the GPL, but perhaps not the spirit. It sounds like the
Documentation License is attempting to avoid this bug.
Christopher Browne
<mf...@gmx.de> wrote:
>
>> I'd suggest rewording it thus:
>>
>> "Examples of formats likely to be suitable for ``transparent''
>> copies include Texinfo input format, LaTeX input format, and formats
>> conforming to some publicly-defined and publicly-available SGML or
>> XML DTD such as DocBook, LinuxDoc, HTML 3.2, or HTML 4.0."
>>
>> - By saying "likely to be suitable" this removes the implication that
>> HTML is *forcibly* an acceptable format.
>
>originally is written with the DocBook DTD, which is a really nice and
>very transparent format for writing documentation, and somebody decides
>to modify eg the HTML output, the modification isn't very usefull for
>the public as it 'branches' the documentation. But this is still defined
>to be a transparent copy, and publishing it would be enough to fullfill
>condition 3. Did I miss some terms forbidding this or is this a gap in
>the draft?
Your problem is precisely the reason I used the phrase "likely to be
suitable."
If the original document was written using DocBook (as the case for my
web site; <http://www.hex.net/~cbbrowne/>), then the HTML form is very
probably less suitable as a "transparent form" than the DocBook form.
>> >With the use of WYSIWYG editors, Postscript or PDF (you can have
>> >uncompressed PDF) may be the nearest that you can realistically
>> >expect people to get to an open format without compromising the
>> >document's structure.
>>
>> PDF is most definitely an "opaque" format, by almost any metric, as it
>> is *not* a format that is directly editable. PDF documents are
>> produced by taking a document written in some other form and
>> "distilling" it into PDF; they are in no way a "source format."
>>...
>> My sense is that the term "Transparent" perhaps should be retermed
>> "Transparent Source," as this diminishes the ability of the obstinate
>> to choose to misread it such that they might treat formats that are
>> almost never "Source" formats as the publicly available format for a
>> document...
>
>As this seems to be a point of uncertainity one could explicitly define
>pdf and ps to be opaque.
If the original document was composed as raw Postscript, as I outlined
as a possibility, then while Postscript is normally not considered
"transparent form," the fact that there's no *better* form available
indicates that Postscript is in fact the preferred form in which to
transmit the document.
This implies that what should be "legislated" as "must have"
properties are not quite so obvious.
- If Postscript is considered "constitutionally opaque," then
documents written in Postscript are deemed opaque, even though they
conceptually aren't. It may be somewhat unusual to thus compose
documents, but it is not impossible, and it would be inappropriate
to rule this out apriori.
- Supposing the folks that brought us <application/XPDF/ produce an
upgrade or an "add-on" that makes it possible to readily edit PDF
documents, this turns PDF from an "opaque" format to a rather more
"transparent" one.
This is another reason for using the phrase "likely to be suitable" to
describe particular formats, as well as defining "opaque" in more
precise detail, perhaps thusly:
"``Opaque'' formats are document formats that are not suitable due to
such factors as:
- The use of undocumented or otherwise proprietary formatting;
- The unavailability of free software that may be used to modify the
document in the manners required in this license;
- A requirement to use technologies involving ``software patents''
to edit or render the document;
- Does not represent the natural ``source form'' of the document.
Examples of formats likely to be unsuitable due to being "opaque"
include:
- RTF, as it lacks clear documentation for the definition of the
format;
- PDF, for which, while there do exist free tools to render the
format for display, lacks free tools for editing of documents.
In some cases, knowing the document format type is not sufficient to
determine if the form is ``opaque'' or ``transparent.''
For instance, sometimes documents are composed in HTML, in which case
it is likely the ``transparent'' format for the document. Sometimes
documents are composed in some other format such as DocBook and
rendered into HTML, in which case DocBook should be treated as the
``transparent'' format and HTML an ``opaque'' format.
Usually, documents are not composed in Postscript, but are rather
composed using some other document format, and rendered into
Postscript. In such cases, the Postscript rendition is not a form
that is readily modified, thus indicating that it is an ``opaque''
form. On occasion, authors have been known to compose documents in
Postscript, in which case it would need to be treated as a
``transparent'' form.
--
All ITS machines now have hardware for a new machine instruction --
XOI Execute Operator Immediate.
Please update your programs.
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
Michael Fischer v. Mollard
> It would be unreasonable to require that all derived versions use the
> same formatting system as the original. What happens in 20 years that
> way?
What I wanted to say is not that one should be forced to use the *same*
formating system but one should use a *not less transparent* formating
system.
In the case of DocBook vs HTML the problem is not only that HTML is less
transparent than DocBook but the loss of semantic informations that may
be coded in the DocBook source but not in the HTML output. But I agree
that a formulation like "the modifications should be made in a format
that preserves all semantic informations from the original version,
preferable in the source version of the original manual" is not very
clear. Perhaps a native speaker may have a better idea how to say that.
--
MfG
MFvM
David Woolley
Phil Hunt <ph...@vision25.demon.co.uk> wrote:
>
>Since the intention is the same as the GPL's provision regarding
>source code, why not use similar language, e.g:
> ``a transparent copy is a copy made in the preferred form of the
>work for making modifications to it''
The preferred form for most people (dyed in the wool Unix enthusiasts
apart) these days is patches of light on a VDU screen. Taking one
step back from that, the preferred format is Microsoft Word 97
binary format.
I think the first would be a silly interpretation, and the second would
clearly be against what I perceive to be the intention behind the
licence proposal.
Incidentally, in the market are that my employers are in MS Word binary
is the preferred format for people to receive documents, with MS .WRI
and plain text as tolerated alternatives. It could be argued that IE4/NS4
HTML is in there as well, with GIF images. PDF is not accessible to
most customers and, whilst PS would be easy to print for most, virtually
none of them would have any idea how to do so. I doubt if any could
cope with LaTeX, nroff, etc.
David Woolley
Christopher Browne <cbbr...@hex.net> wrote:
>On 15 Sep 1999 16:10:46 +0200, Michael Fischer v. Mollard
><mf...@gmx.de> wrote:
[ Attribution lost ]
>>
>>> PDF is most definitely an "opaque" format, by almost any metric, as it
>>> is *not* a format that is directly editable. PDF documents are
>>> produced by taking a document written in some other form and
>>> "distilling" it into PDF; they are in no way a "source format."
More precisely, distilling is taking the postscript form, running
the interpreter but not executing the graphics primitives, but rather
outputting them into the result with literal arguments, then adding
additional structures to speed navigation.
PDF is designed to be edited, but only by page replacement - you can
add to the end, in the same way that multi-session CDs work.
On the other hand you can reversibly translate between PDF and Postscript
(with PDF Mark operators), with only the first PS to PDF transformation
losing anything.
The real point about PDF is that it is the third most likely form of
rich text document that people can read after MS Word and Big 2 HTML
(SGML conforming HTML is *very* rare; accessible conforming HTML is
even rarer). Even so, outside certain technical areas, it is quite
unlikely that people have Acrobat and even less likely that they have
a freeware reader.
Very few people have the (minimal) level of technical expertise needed
to print raw Postscript, so, as a delivery medium, it is much worse
than PDF, even though most companies have the technology to print it.
HTML does not currently work reliably were layout is important
(although unfortunately that's how most web sites try to use
it). Proper HTML authoring requires the author to have a grasp of
the abstract structure of the document that goes far beyond the
average WISYWIG idea of a document and the advantage of PDF/PS is that,
for authors who represent deep structure only with surface visual effects
(i.e. nearly all of them) it preserves their message reasonably
faithfully.
>Usually, documents are not composed in Postscript, but are rather
>composed using some other document format, and rendered into
>Postscript. In such cases, the Postscript rendition is not a form
But normally the intermediate, revisable forms are proprietory
(read MS Word).
I think there are conflicting requirements here. On one had there
is a desire to produce revisable form documents in forms that can
be easily edited with free tools. On the other hand, there is the
requirement to produce documents that are readable, without a lot
of trouble, by people who need to read the documentation.
Phil Hunt
bar...@bbnplanet.com "Barry Margolin" writes:
> In article <937430...@vision25.demon.co.uk>,
> Phil Hunt <ph...@vision25.demon.co.uk> wrote:
> >Since the intention is the same as the GPL's provision regarding
> >source code, why not use similar language, e.g:
> > ``a transparent copy is a copy made in the preferred form of the
> >work for making modifications to it''
>
> Word .doc files. These are transparent if you happen to have the non-free
> software that supports it, but they're opaque to others (although in the
> case of Word documents, just about every word processor can import them and
> convert them to its own format).
True. Many people (me included) think MS Word is an inappropriate
format for writing documentation for free software.
> There's an oft-raised issue with the GPL regarding software written in a
> language for which there are only proprietary compilers. This meets the
> letter of the GPL, but perhaps not the spirit. It sounds like the
> Documentation License is attempting to avoid this bug.
Phil Hunt
da...@djwhome.demon.co.uk "David Woolley" writes:
> On the other hand you can reversibly translate between PDF and Postscript
> (with PDF Mark operators), with only the first PS to PDF transformation
> losing anything.
>
> The real point about PDF is that it is the third most likely form of
> rich text document that people can read after MS Word and Big 2 HTML
> (SGML conforming HTML is *very* rare; accessible conforming HTML is
> even rarer). Even so, outside certain technical areas, it is quite
> unlikely that people have Acrobat and even less likely that they have
> a freeware reader.
I'm not sure this is true; doesn't Acrobat come installed on most
Windows PCs? -- Certainly on ones I've used, you can click on a
link to a pdf file on a web page, and up comes Acrobat to read it.
> Very few people have the (minimal) level of technical expertise needed
> to print raw Postscript,
This is significantly harder on Windows than on Unix (where it is
trivial).
Christopher Browne
<da...@djwhome.demon.co.uk> wrote:
>In article <__YD3.4504$_x1.1...@news5.giganews.com>,
>Christopher Browne <cbbr...@hex.net> wrote:
>>composed using some other document format, and rendered into
>>Postscript. In such cases, the Postscript rendition is not a form
>
>(read MS Word).
Which is a form that is certainly not intended to be encouraged.
>I think there are conflicting requirements here. On one had there
>is a desire to produce revisable form documents in forms that can
>be easily edited with free tools. On the other hand, there is the
>requirement to produce documents that are readable, without a lot
>of trouble, by people who need to read the documentation.
Yes, there's a conflict; the question is whether there should be:
a) A compromise made now, that thereby encourages people to use
proprietary documentation tools, or
b) No compromise, but rather a license that actively *discourages* the
use of proprietary documentation tools.
Which of these options seems more likely for the FSF to adopt?
Three guesses, and the first two don't count...
--
"I don't know why, but first C programs tend to look a lot worse than
first programs in any other language (maybe except for FORTRAN, but
then I suspect all FORTRAN programs look like `firsts')" -- Olaf Kirch
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/sgml.html>
Michael Fischer v. Mollard
> >Usually, documents are not composed in Postscript, but are rather
> >composed using some other document format, and rendered into
> >Postscript. In such cases, the Postscript rendition is not a form
>
> But normally the intermediate, revisable forms are proprietory
> (read MS Word).
Not in the Unix/Linux world.
> I think there are conflicting requirements here. On one had there
> is a desire to produce revisable form documents in forms that can
> be easily edited with free tools. On the other hand, there is the
> requirement to produce documents that are readable, without a lot
> of trouble, by people who need to read the documentation.
I don't see any conflicting requirements here. I supose that people
who really want to edit a manual should have a minimal technical
knowledge so they could use tools which are not so easy to use. But
the point is that the transparent copy (read DocBook, Linuxdoc or
texinfo here) is only the source code for the manual, and it is no
problem to produce opaque formats like Postscript, pdf, rtf, html from
that source (at least from DocBook and Linuxdoc DTDs, I don't know to
much about texinfo). For an user it would be sufficient to read the
html or pdf output, which should be a quite trivial thing on most
modern computers.
--
MfG
MFvM
Christopher B. Browne
>da...@djwhome.demon.co.uk (David Woolley) writes:
>
>> >Usually, documents are not composed in Postscript, but are rather
>> >composed using some other document format, and rendered into
>> >Postscript. In such cases, the Postscript rendition is not a form
>>
>> (read MS Word).
>
>Not in the Unix/Linux world.
And more particularly with the GNU Project.
Remember that this license is intended fundamentally for use with
documentation produced for software produced for the GNU Project.
It would be downright stupid to say:
"The software we produced is free, and that was the whole point to
the GNU Project, but in order to work on the documentation, you need
a bunch of proprietary software that only runs on decidedly non-free
platforms."
--
Do you know where your towel is?
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
David Woolley
Phil Hunt <ph...@vision25.demon.co.uk> wrote:
>I'm not sure this is true; doesn't Acrobat come installed on most
>Windows PCs? -- Certainly on ones I've used, you can click on a
It comes with neither Windows 98 nor Windows NT 4. However it is
commonly found on the install disks with the drivers for third
party hardware.
The position I'm quoting from here is that of a company that provides
reports (from an web interface locally and) as a bureaux service. My
current understanding of our marketing position is that the only
delivery format that we believe there is enough demand to develop for
is Word 97 RTF and Excel snapshot (i.e. packaged Windows Metafle). We
would probably give PDF if there was a real demand.
>link to a pdf file on a web page, and up comes Acrobat to read it.
I personally am reluctant to fill my hard disk with lots of tools, e.g.
I reject offers of Shockwave Flash; many other people may not have
adequate web access or have house rules that forbid downloading software
(that probably rules out GPLed software, but documents can exist without
software). (I do have PDF and PS viewing tools.)
>> Very few people have the (minimal) level of technical expertise needed
>> to print raw Postscript,
>
>This is significantly harder on Windows than on Unix (where it is
>trivial).
It's not difficult on windows, but you have to use MS-DOS level interfaces,
or something like Netware pconsole (remember to disable banners), or,
of course, ghostscript. All of these are two technical for the average
punter.
Christopher B. Browne
<da...@djwhome.demon.co.uk> posted:
>Phil Hunt <ph...@vision25.demon.co.uk> wrote:
>>I'm not sure this is true; doesn't Acrobat come installed on most
>>Windows PCs? -- Certainly on ones I've used, you can click on a
>
>It comes with neither Windows 98 nor Windows NT 4. However it is
>commonly found on the install disks with the drivers for third
>party hardware.
>
>The position I'm quoting from here is that of a company that provides
>reports (from an web interface locally and) as a bureaux service.
The perspective associated with the "New Documentation License" is
particularly that of documenting the software created under the GPL.
It is *necessary* that it serve that purpose.
--
"Although UNIX is more reliable, NT may become more reliable with time"
- Ron Redman, deputy technical director of the Fleet Introduction
Division of the Aegis Program Executive Office, US Navy.
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
Michael Fischer v. Mollard
GPL? Wrong descriptions in a manual may be as dangerous as bugs in a
program, and therefore I think it would be a good idea to add a 'no
warranty' section to the license.
--
Barry Margolin
Michael Fischer v. Mollard <mf...@gmx.de> wrote:
>What about a 'no warranty' section like the sections 11 and 12 in the
>GPL? Wrong descriptions in a manual may be as dangerous as bugs in a
>program, and therefore I think it would be a good idea to add a 'no
>warranty' section to the license.
Is there normally an implied warranty for documentation? You probably
don't need to disclaim something that isn't there in the first place.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Jakob 'sparky' Kaivo
> In article <ca6715l...@u27.num.math.uni-goettingen.de>,
> Michael Fischer v. Mollard <mf...@gmx.de> wrote:
> >What about a 'no warranty' section like the sections 11 and 12 in the
> >GPL? Wrong descriptions in a manual may be as dangerous as bugs in a
> >program, and therefore I think it would be a good idea to add a 'no
> >warranty' section to the license.
>
> Is there normally an implied warranty for documentation? You probably
> don't need to disclaim something that isn't there in the first place.
Even if there isn't an implied warranty, it's wise to disclaim it just in
case. Better safe than sorry, you know.
--
Jakob 'sparky' Kaivo - jka...@ndn.net - http://www.ndn.net/
"As time goes on, my signature gets shorter and shorter..." - me
donisha...@gmail.com
Luca Saiu
be a bad idea. Don't.
--
Luca Saiu
GNU epsilon: http://www.gnu.org/software/epsilon
Marionnet: http://marionnet.org
My blog: http://ageinghacker.net/blog
muhmmada...@gmail.com
plz give me this mobile country code
Ben Ritchey
tonfen...@gmail.com
> I am working on a new license to use for GNU documentation. Here is a
> draft of it. Please don't use it yet; I have not finished checking
> it. But please do give me constructive comments for improving the
> details of it. I can make use of them to improve version 1.0.
>
>
> GNU Free Documentation License Version 0.9
> DRAFT
>
>
> 0. PREAMBLE
>
> The GNU Free Documentation License is a form of copyleft designed for
> books, such as reference manuals and tutorials. We designed it in
> order to use it for documentation about free software, but it can be
> used regardless of the subject matter. It can also apply to textual
> works that are not released in book form. It gives users the right to
> copy, redistribute and modify the work, just as users have the right
> to copy, redistribute and modify free software.
>
>
> 1. APPLICABILITY
>
> This License applies to any manual or other work which contains a
> notice placed by the copyright holder saying it can be distributed
> under the terms of this License. The "Manual", below, refers to any
> such manual or work. Any member of the public is a licensee, and is
> addressed as "you".
>
> A "Modified Version" of the Manual means any work containing the
> Manual or a portion of it, either copied verbatim or with
> modifications and/or translated into another language.
>
> The "Invariant Sections" are certain appendices or front-matter
> sections of the Manual, which deal exclusively with nontechnical
> matters (such as the political views, histories or legal positions of
> the authors), and whose titles are listed as Invariant Sections in
> the notice saying that the Manual is released under this license.
>
> The "Front-Cover Texts" are certain short passages of text are listed as
> Front-Cover Texts or Back-Cover Texts in the notice saying that the
> Manual is released under this license.
>
> A "Transparent" copy of the Manual means a machine-readable copy,
> represented in a format whose specification is available to the
> general public, in which the text may be viewed straightforwardly with
> ordinary text editors, and which is suitable for input to text
> formatters or for automatic translation to a variety of formats
>
> in other formats where there is no title page as such, it means the
> text near the most prominent mention of the work's title, preceding
> the beginning of the body of the text.
>
>
> 2. VERBATIM COPYING
>
> You may copy and distribute the Manual, in any medium, either
> commercially or noncommercially, provided that this license is
> reproduced in all copies, and you add no other conditions whatsoever
> to those of this license. You may accept compensation in exchange for
> copies, but you may not technically obstruct the reading or further
> copying of the copies you make or distribute.
>
> You may also lend copies, under the same conditions stated above, and
> you may publicly display copies.
>
> It is requested, but not required, that you give the authors of the
> Manual thirty days (or more) advance notice of your plans to
> redistribute any large number of copies, to give them a chance to
> provide you with an updated version of the Manual.
>
>
> 3. COPYING IN QUANTITY
>
> If you publish or distribute printed copies of the Manual numbering
> more than 100, and the Manual'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. If the required texts for either
> cover are too voluminous to fit legibly, put the first ones listed (as
> many as fit reasonably) on the actual cover, and continue the rest
> onto adjacent pages.
>
> If you publish or distribute Opaque copies of the Manual numbering
> more than 100, you must state in or with each copy a publicly
> accessible computer network location containing a Transparent copy of
> the Manual, no more and no less, which the general network-using
> public has access to download at no charge. You must take reasonably
> prudent steps, when you begin distribution of Opaque copies in
> quantity, to ensure that this Transparent copy will remain thus
> accessible at the stated location until at least six months after you
> last distribute an Opaque copy.
>
>
> 4. MODIFICATIONS
>
> You may copy and distribute a Modified Version of the Manual under the
> conditions of section 2 and 3 above, provided that you release the
> Modified Version under precisely this license, with the Modified
> Version filling the role of the Manual, thus licensing use of the
> Modified Version to whoever possesses a copy of it. In addition, you
> must do these things in the Modified Version:
>
> A. Mention the Manual's title on the Title Page.
> B. Add something to the title, or a subtitle, stating that the version has
> been modified, and distinguishing it from the Manual you started with.
> 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.
> D. Retain on the Title Page or its continuation the authors' and publishers'
> names listed on the Manual's Title Page.
> E. Preserve all the copyright notices of the Manual.
> F. Add an appropriate copyright notice for your own work.
> G. Include after them a notice stating giving the public permission to
> use the Modified Version under the terms of this license,
> in the form shown in the Addendum below.
> H. Preserve in that notice the full list of Invariant Sections,
> and the full list of required Cover Texts, given in Manual's notice.
> I. Include an unaltered copy of this license.
> 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
> versions it was based on.
> K. If the Manual has an Acknowledgements and/or Dedications section,
> preserve therein all the substance of each of the contributor
> acknowledgements and/or dedications stated therein.
> L. Preserve all the Invariant Sections of the Manual,
> unaltered in text and in their titles.
>
> If the Modified Version includes new front-matter sections (or
> appendices) which deal exclusively with nontechnical matters, and
> contain no material copied from the Manual, you may at your option add
> the section titles of any or all of these sections to the list of
> Invariant Sections in the Modified Version.
>
> You may add up to five words of Front-Cover Text and up to 25 words of
> Back-Cover Text to the end of the list of Cover Texts in the Modified
> Version.
>
> The author(s) and publisher(s) of the Manual do not by this license
> give permission to use their names for publicity or to assert or imply
> endorsement of any Modified Version.
>
>
> 5. COMBINING MANUALS
>
> You may combine the Manual with other manuals released under this
> license, under the terms of section 3 above as for modified versions,
> provided that you include all of the Invariant Sections of all of
> the original manuals, unmodified, in the combination, and list them
> all as Invariant Sections in your combined work.
>
> The combined work need only contain one copy of this license, and
> multiple identical Invariant Sections may be replaced with a single
> copy. If there are multiple Invariant Sections with the same name but
> different contents, make the title of each such section unique by
> adding at the end, in parentheses, the name of the original author or
> publisher of that section if known, otherwise the name of an author or
> publisher of the manual that section came from; and make the same
> adjustment in the list of Invariant Sections in the license of the
> combined work.
>
>
> 6. AGGREGATION WITH INDEPENDENT WORKS
>
> A compilation of the Manual or its derivatives with other separate and
> independent documents or works, in or on a volume of a storage or
> distribution medium, does not as a whole count as a Modified Version
> of the Manual, provided no compilation copyright is claimed for the
> compilation. In such a case, this license does not apply to the other
> self-contained works thus compiled with the Manual, if they are not
> derivative works of the Manual.
>
>
> 7. TRANSLATION
>
> Translation is considered a kind of modification, so you can
> distribute translations of the manual under the terms of section 4.
> This implies that translation of the Invariant Sections requires
> special permission from their copyright holders. You may include a
> translation of this license provided that you also include this
> license in the original English version. In case of a disagreement
> between the translation and the English version of this license, the
> English version will prevail.
>
>
> 8. TERMINATION
>
> You may not copy, modify, sublicense, or distribute the Manual
> except as expressly provided under this License. Any attempt
> otherwise to copy, modify, sublicense or distribute the Manual is
> void, and will automatically terminate your rights under this License.
> However, parties who have received copies, or rights, from you under
> this License will not have their licenses terminated so long as such
> parties remain in full compliance.
>
>
> 9. ADDENDUM: How to use this license for your manuals
>
> To use this license in a manual you have written, put the following
> notice on the page after the title page:
>
> Copyright (c) YEAR YOUR NAME.
> Permission is granted to copy, distribute and/or modify this
> manual under the terms of the GNU Free Documentation License,
> Version 1.0 or any later version published by the Free Software
> Foundation, with the Invariant Sections being LIST THEIR TITLES,
> Front-Cover Texts being LIST, and Back-Cover Texts being LIST.
> A copy of the license is included in the section entitled "GNU
> Free Documentation License"
>
> If you have no Invariant Sections, write "with no Invariant Sections"
> instead. If you have no Front-Cover Texts, write "no Front-Cover Texts"
> instead of "Front-Cover Texts being LIST". Likewise for Back-Cover Texts.