Re: changes and standards documents
Hi,
>>"Philip" == Philip Hands <phil@hands.com> writes:
Marcus> a) Without documentation, you can't use the software.
>>
>> Does not apply to a standard. You use the standard by reading
>> it -- nothing has to be modified. A standard is not documentation for
>> a program.
Philip> Lets say the restrictions on the standard were relaxed to the
Philip> point that one were allowed to redistribute it as an ASCII
Philip> text file, as long ad the md5sum was the same as the
Philip> original.
Philip> We would then have the following options:
Philip> 1) not distribute it anyway
Philip> 2) distribute it in non-free
Philip> (for example I might put it in mgetty-doc-nonfree.deb)
Philip> 3) distribute it in main
Philip> (so I might include it in mgetty-doc.deb)
Philip> IMO 1) is a disservice to our users, since it is a standard
Philip> to which some of the programmes in main are written.
Agreed.
Philip> I also think 3) is wrong, since it gives the impression that
Philip> there is no difference between this document and other parts
Philip> of main, despite the redistribution restriction.
Is there really a difference? Remember not to compare apples
to oranges. We cannot use software and its documentation for
comparision. And one does not throw things into non-free just because
they are different; we put them in non-free because we think they are
detrimental to the community, but since our users want them, we
reluctantly make them available on our ftp site.
Philip> 2) seems to fit the bill quite well. We give our users
Philip> fairly easy access to the document, without contaminating
Philip> main with non-free stuff, or causing confusion by
Philip> requiring that the licences for documentation in main need
Philip> to be read in detail before fixing a spelling mistake, for
Philip> example.
I think 2 is wrong, since it restricts access to a standard
that is freely distributable. 2 would make it not part of debian, and
not be on the CD ROMS. I think that the community benefts from the
dissemination of standards documents.
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*
follws the same document.
Standards are not improved by generating a gazilionsets of
documents, confusing what exactly the standard says, and then
converging the standard back. Stnadards bodies *do* look at
non-confrmant 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 teh 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.
What is good for software may be bad for standards.
manoj
--
PLUG IT IN!!!
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: