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

Re: changes and standards documents



Manoj Srivastava <srivasta@datasync.com> wrote:
>  Raul> Or maybe you're implying that the authors of the program have a
>  Raul> duty to re-write the concepts described in the standard, from
>  Raul> scratch but phrased differently so that it doesn't violate the
>  Raul> copyright on the standard?
>
>  It is always better to rewrite the language used in standards in
>  plain english. Perhaps fair use clauses come in effect? Especially if
>  the excerts are small enough? If the excerpts are very large, I fail
>  to see that you have followed the standard.

What I'm envisioning is that you'd take what the standard has to 
say about, for example, the implemented language, leave that as
quoted text and flesh it out with notes about implementation dependent
choices and such.  Then you'd toss the more verbose stuff and
replace it with something that doesn't need to cover all possibilities.

What you seem to be envisioning is that there's no reason to believe
that it's worthwhile to our community for a standard to do this.

Anyways, what I'm proposing is that such works should go into
a new section -- one which could be put on cdrom, but whose labeling
indicates that they don't meet the same guidelines as main.  I'm
not sure what to best call it -- perhaps "verbatim".

[Aside: I think each section should have a short document at its
root describing what sorts of things would go in it.  For main,
that would be a copy of DFSG...]

-- 
Raul

> 	Can I say the following program is an incomplete implenetation
>  of POSIX 1003.2 and, quote the whole standard as an exception?
> --------------------------------------------------------------------
> int main (void) { return 0; }
> -------------------------------------------------------------------
> 
> 
>  Raul> Or...?
> 
> 	You mean that becuase someone writes a buggy implementation of
>  a standard, you want to change the licensing on the standard? 
> 
>  >> If the program does not follow what the stadard says, the program
>  >> is buggy. The standard is always authoritative (unless some one has
>  >> monkeyed with the standard, in which case it is no loger a standard).
> 
>  Raul> This implies that there's only one standard, and that it's
>  Raul> reasonable to refer a person to that entire standard when
>  Raul> learning to use the program.  This might be true in some cases,
>  Raul> but it's very far from being accurate for the general case.
> 
> 	File a bug against the program to get docs of its own. This
>  has nothing to do with whether it implements a standard or not, the
>  program should ahve documentation, as I said before. OK?
> 
> 	We are talking about a standard, and whether it needs be
>  mutable. I find this paragraph has little to do with that -- perhaps
>  I am being dense. 
> 
> 	Look, if Fred wants to create a program that implements
>  standard X, and Fred fails, we do not change the standard; since
>  Jack, Jill, and Joan are also trying to implement the original
>  standard, and they should not be penalized for Freds incompetence or
>  sloth. 
> 
> 	Also, Erik maybe writig code that interacts with standard
>  complaint programs, and Freds buggy implementation should not be used
>  as an excuse to modify the standard itself.
> 
> 	manoj
> 
> -- 
>  No man can have a reasonable opinion of women until he has long lost
>  interest in hair restorers. Austin O'Malley 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: