[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Should our documentation be free? (Was Re: Inconsistencies in our approach)



On Thu, 31 Jul 2003, John Goerzen wrote:
> *ALL* of these approaches are wrong.  Putting non-software items into
> the same box as a very different beast serves only to cloud the
> issue.

No one as yet has come forward with a compelling argument as to why we
should consider treating documentation any differently than software.

Most of the arguments that have been presented boil down to:

    Removing foo would do harm to our users.

Not packaging Microsoft Word with Debian has negative aspects for our
users. However, we typically agree that the positive aspects of being
able to exercise freedoms granted under the DFSG outweigh the negative
aspects of such a decision.

> We have, and continue to, allow information to be distributed with
> software under even more strict terms than the FDL.  Examples of
> these things include licenses.

Not to mention the fact that we can't modify copyright statements...

So are you saying that because we allow software that is licenced
under a license that cannot be modified itself we should accept
documentation that cannot be modified itself? 

> Speaking in a general sense, rather than with regard to the
> particulars of the FDL, it does not prove a significant problem for
> people down the line if portions of a document specifically relating
> to copyright, licensing, and original authorship remain immutable,
> while the "important" parts remain mutable.

I'd gather that most of -legal isn't worried about the copyright
statement, license, or author's statement (which is the same thing as
the copyright statement) being immutable. Most of those can't be
modified under the applicable copyright law and construed as the
original anyway.

What we are worried about is the addition of odious requirements for
keeping sections of documents which are not related to the above and
significantly impair the exercise of our freedom to modify and
distribute those modifications.

> While I share that concern, and agree in principle that they should
> be modifyable providing the modified version does not claim to be an
> RFC, we need to bear in mind that RFCs serve a quite different
> purpose than software documentation.

Copying sections from an RFC to generate documentation about such an
RFC or using well engineered portions of an RFC to generate better
RFC's down the line are all relatively reasonable things to do. If
it's present in Debian, one expects to be able to use it just like
they would use the source code present in Debian.

It saddens me that the terms for so much documentation are so
egregious, and I would definetly support installers for said
documentation that downloads the documentation from a canonical site,
but to place it in Debian proper seems to directly conflict with our
stated guidelines and social contract with our users.


If we are to treat documentation any differently than software, we
should first define a ruberic that distinguishes software from
documentation. In all previous discussions, we were unable to do this.
[I cannot do it, but perhaps someone else is able.]

Secondly, someone who advocates the difference between documentation
and software, after distinguishing between the two, should decide what
freedoms are reasonable give up to include documentation. After much
heated discussion, it will probably be GR time.

Until that point, I really don't see us doing much differently than
weighing documentation by the same scales that we weigh software, and
fulfilling our obligations under the social contract.


Don Armstrong 
(Earnestly hoping for (and writing) more free documentation.)
-- 
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
 -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu

Attachment: pgpuA1KZRjTfF.pgp
Description: PGP signature


Reply to: