On Sep 5, 2006, at 17:36, Sanjiva Weerawarana wrote: > On Mon, 2006-09-04 at 21:52 +0100, Simon Phipps wrote: >>>> >>>> I would like to see you both apologize so we can go back to >>>> defining >>>> >>>> an Open Standard! >>>> >>>> Ironic on how the conversation to standardize an Open Standard is >>>> being conducted. >>> >>> +1 >> >> +1. I understand and agree with Sam's points about the importance of >> the openness of the development and maintenance processes and have >> spoken with many of you about it. > > I wonder whether we're all off the track a bit: the OSR is *not* about > defining what an open standard is at all. We don't care whether the > standard is defined by a bona fide "standards organization" (whatever > that means), by a single person or by a smokefilled room full of > friends > and family of one company. While I agree with you to a degree, I regard the transparency of the process by which a "standard" evolves as important. > What matters is that if something is to be a > bona fide open standard as far as open source is concerned, then it > must > meet the OSR. What we're trying to agree on is the OSR, not what an > open > standard is or the process for defining an open standard. With respect, that's a circular argument. We are discussing the OSR and fitting it to a purpose, which is creating a list of requirements that identify which "standards" are "safe" for open source developers to implement. What I am asserting is that the "safety" of a standard includes its origin and its maintenance as well as the IPR provenance. I realise some members of the OSI's committee don't agree but I remain firm in the view that both are at least relevant to the issue. > Before my head gets bitten off, I'd like to point out that there are > successful "open standards" which have been defined by each of the > means > listed above (and more) as well as there are plenty of unsuccessful > "open standards" which have been defined similarly. Indeed, some "standards" "succeed" in spite of how unsafe they are for developers! If the decision-making process behind a "standard" is opaque then it is much harder for a programmer to understand how safe the "standard" is as a foundation for development. In just the same way as open source communities frown upon large contributions, "standards" presented finished on initiation and with an opaque history rely on high levels of expertise (or faith in the originator) to develop trust. If a "standard" is not 'fixed' on completion, one can never be sure that an implementation is accurate. A final version against which to implement is essential if a developer is to be confident that interoperability is possible. If the process by which the next version of a "standard" could arise is not clear, a developer can and should fear that an entity with market power could hijack the standard or sideline it. > Our interest is not > in identifying the winning combination of features to make something a > standard, but rather in identifying what it must enable. That's deliciously vague :-) The OSD provided a means by which a developer could know that it was safe to create a derivative work from a body of source code without engaging a lawyer to analyse the license. It seems to me that the OSR should play the same role for standards, providing a developer with a basis to know that a particular standard is safe to implement without the need to engage a standards specialist. > > Is the contentious point between Sam & Russ the "No Secrets" criteria? > If so Sam, can you offer a patch? I've no idea if the views I have mentioned above resonate with Sam's, but I believe it's beyond a simple "patch" to the existing language as the OSR currently neglects the transparency of the evolution of the "standard". S.