Thanks, Bob, this is exactly the kind of criticism I hoped for. It forces me to evaluate what is done so far.
[more] On Sat, May 17, 2008 at 1:38 AM, Bob Miller <[EMAIL PROTECTED]> wrote: > I think you've got a worthy goal, defining what an open standard is. > But it's a hard task. > It's been a joy to work on. It's a task that was awaiting a legal type who had the time and who knew enough about the technology to translate the ultimate goals of various open standards definitions into a legally defensible framework. It's far from done, but it's way more fun than a lot of the legal scut work I've had to do over the years. > I would like to comment on criterion 8, Intellectual Property Rights. > > You wrote, in footnote 9: > > To the extent IPR[...] provide a legal basis for requiring that > implementations conform to the specification, they are pro- > competitive. > > I do not see it that way. In software, 100% conformance to a > specification is just about impossible. It never happens. So if the > owner has not fully waived their rights, they (or their custodian) > could shut down any competing implementation using a nonconformance > argument. The general approach in regard to use of patents as enforcement tools for conformance is to a very large extent a restatement of current practice. (My first act as Emperor of the World will be to abolish patents.) I don't know of an IPR document reading on a standard that doesn't limit its grant of rights to conforming implementations. In other words, to the extent your implementation is non-conformant, you're at risk of a patent infringement lawsuit. That limitation is unavoidable, I think, if you're going to have patents running around the IT ecosystem. If patent holders don't limit the grant of rights to conformant implementations, they're in effect signing a blank check for others to embrace and extend a spec in any way they see fit, constituting a waiver of their patent rights. Trying to talk corporate lawyers into not defining what rights they're giving away is a really hard sell. :-) At the same time, we don't have a huge history of infringement actions being brought over minor conformance bugs in an implementation. In practice, it's more a disincentive to attempts to embrace and extend a standard than something that gets litigated very often. My experience is that the barriers to fully conformant implementations largely flow from under-specification of normative requirements in standards, i.e., that in balance it's more an issue of the quality of the standards than of the quality of the software implementations. Unfortunately, there's a meme that runs around IT standards development organizations I've worked with that it's bad form for IT standards to specify application behavior even for interoperability purposes. It's more a social value than it is a reasoned position, but that particular meme is probably responsible for more under-specification in standards than any other factor I've run up against. The applicable law and common sense is contrary to that meme. In that regard, the document incorporates by reference RFC 2119, <http://www.ietf.org/rfc/rfc2119.txt>, which makes it clear in paragraph 6 that application behavior can be specified if necessary to achieve interoperability. I agree wholeheartedly that perfect fidelity in data exchange between different IT systems is more aspirational than a realizable goal. We can shoot for eventually achieving six 9s fidelity, but not perfection. But the goal of the document is to break the cycle of IT standards being produced that are aimed at vendor lock-in rather than at enabling interop. I hope that the flexibility you see as necessary is provided by the document's definition of interoperability itself, "[t]he ability of ICT systems to exchange information at one or more standardized interfaces and to make *equal mutual use* of the information that has been exchanged, *without differences in use attributable to inadequacies in technical regulations, standards, or technical specifications."* I'll take a look at whether I might integrate the definition of interoperability more tightly with the IPR section. [more] > > Also, keep in mind that implementations evolve, sometimes quite > slowly. For example, GNU Gnash is what, two years old? It's nearly > usable for playing some Adobe Flash programs, but it's by no means a > complete or conforming implementation. I'd wager it won't be for > years to come. (Yeah, I know. Adobe changed their licensing for > Flash and released the specs last week. But 100% compatible Gnash is > still years away.) > > >From my position of perfect legal ignorance, it would make sense to > strike the whole last sentence of criterion 8, the sentence that talks > about assigning IPR to a custodian. > I'll come back to this below. [more] > Moving into criterion 10, Conformity Requirements. I do not believe > that the owner/author/creator of a Universally Accessible and > Interoperable Format should have any power of enforcement that > competing implementations conform. There's too much potential > for abuse. > This is the reason that I drafted the document to require that any blocking IP rights be assigned to a custodian. But you've made me see that my approach would at least require more detail to require that the custodian is as trustworthy as FSF, so to speak, a truly vendor-neutral custodian. So you may be right here, the approach may be off. In effect, my approach would require that outfits like OASIS and Ecma get religion overnight instead of acting as corporate houses of prostitution where companies can go to s***w the competition. > Instead, what you want is a restriction that the original > implementation does conform to the spec and has no extensions. By > "original implementation", I guess I mean the IP owner's > implementation. Yes, that's what I'm thinking. If you have IP > rights, you should have less leeway in implementing a universal format > than if you don't have IP rights. > I'm going to have to rethink this area. There are competing factors afoot. One is the way things work now, which is in effect the inertia that must be overcome. Generally, one can say that the big vendors have way too much control over standards development. Non-major developers, software users, and professional standards developers have insufficient control. Patents tend to be the big vendors' major bludgeons to maintain their control, along with the number of votes they can buy in a voluntary standards organization. The way patents are generally handled now is that a company holding a patent and wanting to work on a standard has to agree to grant rights to infringe their patent claims on terms set by the standards organization, and to some extent that can be negotiated by technical committee members. (The standards organization sets the minimum rights that must be granted, but TC members have the right to insist on more liberal rights being granted as the pricetag on their participation and commitment of their own patent rights if any.) But it's a stacked deck because the big vendors typically control the standards organizations themselves and the patent have-nots have no patents of their own to use as bargaining leverage. Another major factor is the governing law. There's a strong legal argument under the Agreement on Technical Barriers to Trade that patent claims must be worked around unless it is infeasible to do so. (There's a prohibition against standards that have the effect of creating *unnecessary* obstacles to international trade.) ISO and IEC have a joint patent policy that conforms to that argument but it is not being followed. But governments have the responsibility to enforce that prohibition in their procurement processes and mandatory technical regulations. It may be that a better approach is to focus more on that issue and on the government power to require that patent rights be waived as a condition of a standard's qualification as a procurement specification. > We've invented the terms "normative" and "non-normative" which > capture much of what you're getting at in footnote 10, I think. > http://en.wikipedia.org/wiki/Normative#Standards > Right. I've avoided those terms for several reasons. One is so that the language is more easily comprehensible to more people. Another big one is that neither the applicable law nor ISO/IEC JTC 1 Directives use those terms in the relevant portions. I've followed JTC 1 Directives by using "conformity requirements" instead. > Going back to criterion 8, I'm also perplexed by the phrase, "that was > unique to the specification when introduced". Suppose I've invented a > text file format called Foo Format. It has a patented feature for the > novel, nonobvious, useful inclusion of text which is displayed in > boldface. I want Foo Format adopted as a Universally Accessible and > Interoperable Format, but I don't want to waive my patent on bold > text. So I create a second format, Bar Format. Bar Format also has > bold text. By my reading of your document, I wouldn't be required to > waive the boldface patent for Foo Format users because the IP is also > used in Bar Format. > > Why did you insert that phrase? You're thinking of something I > haven't thought of. > You're right that the part needs work. The reason for a phrase along those lines is perhaps best explained by an example. Let's use the OpenDocument standard and assume that it fulfills all requirements of the UAIS. OpenDocument incorporates by reference parts of the SVG Recommendation. But OpenDocument is an OASIS/ISO/IEC standard while SVG is a W3C recommendation. OASIS/ISO/IEC have no ownership rights in XML and SVG upon which they could base a waiver requirement. W3C has the relevant rights. There's a legal need to exclude the parts of the OpenDocument standard owned by W3C from the waiver of rights required by the OpenDocument standard. Those rights are held by W3C, not OASIS/ISO/IEC, and only W3C can set conditions --- such as a waiver --- on use of its standards. So the aim here is a carve-out for portions of a standard incorporated by reference from documents subject to other IPR documents. But I think the language would be more artfully worded if I stick with the waiver approach. > Criterion 12, Complex specifications: Are you implying that an > implementation that supports profile X must also interoperate with all > profiles that are subsets of X? If so, you should say so explicitly. > That is what I'm getting at and I will clarify. I think it would also help if I included an example from the conformance section of the W3C Compound Document Formats interoperability framework: "A conformant user agent of a superset profile specification must process subset profile content *as if it were* the superset profile content." http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance > I hope you find these comments helpful. > Indeed, I did. Thank you very much, Bob. You've definitely given me food for thought and study. Best regards, Marbux _______________________________________________ EUGLUG mailing list euglug@euglug.org http://www.euglug.org/mailman/listinfo/euglug
