On Thu, Aug 13, 1998 at 08:26:37PM +0200, Michael Bramer wrote: > On Wed, Aug 12, 1998 at 04:16:00PM -0500, Manoj Srivastava wrote: > > Licenses for non-software entities > > ---------------------------------- > > Manoj Srivastava<srivasta@debian.org> > > $Revision: 1.2 $ > > [...] > > > 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. > > We must not save the file, we must save the information of the file. > > Fixing simple grammatical or spelling errors are ok. (my optinion) > Also translation into another language or in another format (gif->jpg, > latex->tex). But the information (the content for the user of the file) must > be the same. > > In some file-format you can write a program (postcript, word-files, > excel-files, StarOffice-files, siag-files). If in the program part of the files > a bug, it must be allowed to fix the bug without change the information for > the user. I am right? > > Also tom dick or harry must be allowed to make a new proposel of the standard. > Get the file, change the content and distribute it to the public as a proposel > of the next version of the standard or of a new standard. > > Is this all ok? > > > This proposel is a good start for a non-software Debian Guidelines. > Thank you Manoj. > > Grisu -- Michael Bramer - a Debian Certified Linux Developer http://www.debian.org PGP: finger grisu@master.debian.org -- Linux Sysadmin -- Use Debian Linux "The Box said 'Windows NT or better', so I installed Debian Linux"
Attachment:
pgp9TEik9BAvW.pgp
Description: PGP signature