Re: Copyright from the lcs-projekt!? [dwarf@polaris.net: Re: First cut at testing and validation]
Hi,
>>"David" == David Welton <davidw@gate.cks.com> writes:
David> Have you read RMS' comments regarding documentation? They are, as
David> usual, quite relevant and on the mark.
Yes, I have. And not, it is not relevant to the issue at
hand. It is very relevat when you are talking about documentation for
programs
Ah, the heck with it. I'll post my (still under development)
comments that I posted to debian-policy. Please reply about this
message to the -policy group, -devel is already too cluttered.
manoj
Have fun
Licenses for non-software entities
----------------------------------
Manoj Srivastava<srivasta@debian.org>
$Revision: 1.2 $
-------------------------------------------------------------------------------
1. Introduction an scope
------------------------
I am trying to put together a a document that captures what we have
discussed so far; and help us decide what we want to do.
We are trying to decide our stance on entities that go beyond
software, for which our stand solidied in the DFSG. I think we have
largely agreed that clause 1, and cluses 5-9 of the DFSG stand
unchanged for the documents we are considering, as well as they do for
software. The bone of contention is the mutability (right to change
and redistribute changes) of the entity under review.
The primary consideration is the impact the licences on various forms
of documents have on the free software community; and I think, we
should be inclusive: we should tend to include things unless there is
reason to believe that the licence does harm to the community at
large.
I think we should stop any knee jerk reaction like Hey, mutability was
good for sotware, so it is good for everything else, because it may
not be.
We have to consider what kinds of documents we are talking about, and
what kinds of mutability is desired.
-------------------------------------------------------------------------------
2. Types of modifications
-------------------------
1. Changes in content. This actually alters the document in
question.
2. Fixing simple grammatical or structural problems, spelling
errors, etc, in a fashion where the content is largly unchanged.
3. Translation into another language
4. Reformatting into another intermediate or final rendition, format
changes from LaTeX to HTML or ps, for example
-------------------------------------------------------------------------------
3. Types and categories of Documents considered
-----------------------------------------------
Documentation for software
Technical documentation describes the behaviour, usage, and
configuration details about a specific piece of code. It may also
be instructions about how to modify or extend the software.
(Users manuals, etc) Examples include the GIMP Users Manual, the
GCC Internals guide, any source-code written with "literate
programming" tools, etc.
A Standards document
A standard describes is a common set of standard interfaces,
formats, rules, application programming interfaces, common
practice, conventions, etc, that other people are supposed to
comply with in order to facilitate interoperability, consistancy,
or some other public goal outside of the scope of one program or
developer.. Generally, this has the fax-like law: one or two
people adopting it is not of much value, a million people
adopting it and it comes into its own.
Personal opinions
Opinions of a person, whether technical or otherwise, essays,
open letters, USENET postings (assuming proper permission for
redistributin has been obtained, of course).
Works of fiction
Books, novels, essays, short stories, etc. The project Gutenburg
has a collection of works fo fiction for whom the copyright has
expired, there are tohers that give the right of redistribution
with certain restrictions.
Poetry
Defined as imaginative language or composition, whether expressed
rhythmically or in prose. Specifically: Metrical composition;
verse; rhyme; poems collectively; as, heroic poetry; dramatic
poetry; lyric or Pindaric poetry.
Magazines and graphic novels
These are publications where the layout is as important as the
contents. Graphic novels are rapidly gaining mainstream approval,
and there are already contless web-zines and other magazines
distributed purely electronically, and already Debian has several
such mags packaged up.
Art work, paintings, Images, Photographs
Rendered, ray traced, or hand created usig the GIMP, photographs,
line drawings: these are going to become more and more common.
Technical Opinion
Documents which state the opinion of a particular person or group
in relation to a technical matter. Unlike standards, this
material is not binding in an of itself, but serves rather to
influence technical decisions or to explain why or how a
particular technical decision was made. Examples include the FYI
series or RFCs, judicial opinions, NTSB crash investigation
reports, etc.
Instructional material
Documents which are written to teachtechnical material. Unlike
software documentation, this material need not be specific to a
particular piece of software, or even of software itself.
Examples: The guided-walk-through sections of the Kernel Hacker's
Guide, physics textbooks, US Department of Defence field manuals
on the proper way to brush one's teeth, etc.
-------------------------------------------------------------------------------
4. Arguments for and against mutability
---------------------------------------
This Chapter is where this document needs more work, we need to put in
arguments for and against the desirability for each kind of change,
and how important it is to the community that the changes be demanded.
As I said before, unless there exists a need in the interest of the
comunity, we should not exclude documents of that type that do not
allow the particular kind of change.
4.1. Documentation for software
-------------------------------
Compelling points have been made for the documentation for a program
to be as modifiable as the program itself. If one modifies the
software, one should be able to modify the documentation that
acompanies it so that it sontinues to be useful -- with erroneous
documentation, it is hard to use the software.
Add to that the fact that often the documentation and software are
intertwined, (even more so in literate programming environements), and
some dicuments are automatically generated from the source code,
having a different policy would be hard.
Software documentation really exists to facilitate the use of the
software, and hence needs to be updated when the program changes;
simple grammatical errors being fixed does not detract from the
documentation or its purpose (indeed, it may improve it), similarily,
documentation *should* not be very dependent on layout; proper
dissemination of information over rides artistic needs.
I think it is in the interest of the community to allow all the types
of changes, namely, for content, simple non-content errors,
translation, and format changes.
4.2. Standards
--------------
The bottom line with standards is that people have to accept it -- and
the degree of coperation and synergy that develops when one can depend
on third party code since everyone is playing by the same rules. You
lose all that as soon as people start tweaking the rules around. You
lose interoperability, and trust in the standard, which makes it hard
for the standard to be used for the purpose it was intended.
I think that mutable strandards are an anathema: supporting a plethora
of modified almost standards dilutes the benefits of a standard, the
strength of a standard lies in the fact that *everyone* follows the
same document.
Standards are modified by the standards body, not by any tom dick, or
harry that comes along. How would things be if Debian modifies the
FHS, and so does Red Hat, and caldera an so. We all have our own FHS,
and now none of the distributions are using compatible file layouts.
Just look at what happens when standards are not immutable: MS
embracing java, and then extending it, and essentially breaking the
write once, run anywhere promise of the standard. Modifying standards,
in my opinion, hurts the software community worse than proprietary,
non free software does. It divides us, and lowers the efficacy of the
standardizing effort.
Standards are not improved by generating a gazilion sets of documents,
confusing what exactly the standard says, and then converging the
standard back. Standards bodies *do* look at non-conformant
implemntations and applications, and use prior art to amend or enhance
the next version; but never have I heard any standards body taking in
an bastardized version and incorporating it into the next standard.
As the community benefits from the wide dissemination and use of
standards, which allows authors to synergistically build upon each
others works, and the community suffers from the spread of a subtly or
drastically different copies of what purports to be a standards
dcument, I think we should actually frown on mutable standards.
So, I oppose penalizing standards documents that prohibit change in
content. I guess translations, or format changes, should be
acceptable.
4.3. Personal opinions
----------------------
Personal opinions, right or wrong, belong to the person who holds
them, I see no need for anyone else modifying the opinions of someone
else (reasoning with the opinion holder is a different kettle of
fish).
4.4. Works of fiction
---------------------
4.5. Poetry
-----------
4.6. Magazines and graphic novels
---------------------------------
4.7. Art work, paintings, Images, Photographs
---------------------------------------------
4.8. Technical Opinion
----------------------
-------------------------------------------------------------------------------
Licenses for non-software entities
Manoj Srivastava<srivasta@debian.org> $Revision: 1.2 $
--
Class: when they're running you out of town, to look like you're
leading the parade. Bill Battie
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: