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

Re: Copyright from the lcs-projekt!? [dwarf@polaris.net: Re: First cut at testing and validation]



Hi,
>>"Michael" == Michael Bramer <grisu@debian.org> writes:

 Michael> Today I have read the first time from the lcs projekt.

 Michael> After that I subcrib the lcp-en mailing list and found a eMail from 
 Michael> Dale Scheetz. In this eMail he send program code this a copyright.
 Michael> I have ask him, to change the copyright to a DFSG-free copyright.

 Michael> This is the answer:

	Why are you posting a private reply? Did you ask permission?
 If you did, you should note that in your message.

	I think I agree with Dale: since a verification program
 certifies a disrtibution, a modified certification program can allow
 a non-conforming distribution to lie about it an pretend they are
 qualified.

	I shall quote from one of my messages on the -policy list.

	manoj	

     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. 


-- 
 You will be audited by the Internal Revenue Service.
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: