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
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
...

Erfahren Sie mehr »

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:step...@nevis1.columbia.edu
Irvington, NY 10533, USA          http://www.nevis.columbia.edu/~stephan
------------------------------------------------------------------------

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.

Otherwise it seems quite acceptable (to me).

--- &disclaimer; ---
Ulrich Windl <Ulrich.Wi...@rz.uni-regensburg.de+no-spam>

In article <snfn1upnc5m....@rrzc5.rz.uni-regensburg.de>,

... 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".

In article <gnusenet199909120759.DAA04...@psilocin.gnu.org>,
Richard Stallman  <r...@gnu.org> wrote:
                                                 ^^^^^^^^

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.

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.

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.

In article <FI1qGp....@bts.co.uk>,

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.

On Tue, 14 Sep 1999 10:57:54 GMT, David Woolley

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."

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.

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.

... 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)
cbbro...@hex.net- <http://www.ntlug.org/~cbbrowne/printing.html>

On Tue, 14 Sep 1999 20:20:21 GMT, Barry Margolin

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
cbbro...@ntlug.org- <http://www.hex.net/~cbbrowne/wpdpl.html>

Hi,

what about writing "it has to contain only plain-ASCII text"??

or 7-bit ASCII

this should be enough...

regards
 gerhard

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?

As this seems to be a point of uncertainity one could explicitly define
pdf and ps to be opaque.

--
                  MFvM

Michael Fischer v. Mollard
m...@gmx.de

In article <EJBD3.1304$wr5.51...@news6.giganews.com>
           cbbro...@hex.net "Christopher Browne" writes:

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

m...@gmx.de (Michael Fischer v. Mollard) writes:

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

In article <937430054...@vision25.demon.co.uk>,

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.

--
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.

On 15 Sep 1999 16:10:46 +0200, Michael Fischer v. Mollard

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.

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.
cbbro...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>

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

Michael Fischer v. Mollard
m...@gmx.de

In article <937430054...@vision25.demon.co.uk>,

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.

In article <__YD3.4504$_x1.107...@news5.giganews.com>,

[ Attribution lost ]

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.

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.

In article <Z1XD3.36$zE6.2679@burlma1-snr2>
           bar...@bbnplanet.com "Barry Margolin" writes:

True. Many people (me included) think MS Word is an inappropriate
format for writing documentation for free software.

--
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

In article <FI5FwB....@bts.co.uk>
           da...@djwhome.demon.co.uk "David Woolley" writes:

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.

This is significantly harder on Windows than on Unix (where it is
trivial).

--
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

On Thu, 16 Sep 1999 11:00:04 GMT, David Woolley

Which is a form that is certainly not intended to be encouraged.

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
cbbro...@hex.net- <http://www.hex.net/~cbbrowne/sgml.html>

Not in the Unix/Linux world.

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

Michael Fischer v. Mollard
m...@gmx.de

On 17 Sep 1999 11:44:54 +0200, Michael Fischer v. Mollard <m...@gmx.de> posted:

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?
cbbro...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

In article <937516686...@vision25.demon.co.uk>,

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.

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.)

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.

On Fri, 17 Sep 1999 10:55:02 GMT, David Woolley
<da...@djwhome.demon.co.uk> posted:

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.  
cbbro...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

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.

--
Michael Fischer v. Mollard
m...@gmx.de