[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets
--- On Mon, 6/30/08, marbux <email@example.com> wrote: > From: marbux <firstname.lastname@example.org> > Subject: Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets > To: Andrew.Updegrove@gesmer.com > Cc: "oiic-formation-discuss" <email@example.com> > Date: Monday, June 30, 2008, 8:23 AM > On Sun, Jun 29, 2008 at 11:47 PM, > <Andrew.Updegrove@gesmer.com> wrote: > > >> I note your attempt to change the subject of this > thread with only an > >> appeal to ignorance. I decline your flame bait. Do > you have anything > >> to offer to the discussion of the technical or > legal merits of my > >> proposed use case regarding interoperability in > vertical and > >> horizontal ODF markets? > > > > Paul, it was a last attempt to try to see whether your > place in the > > community could be salvaged, intended in friendship. > This listserv has a > > purpose defined by consensus, and not by a single > participant. No one has > > an obligation to respond to everything, or even > anything, you say, if they > > don't think it is within scope, or has already > been adequately addressed, or > > is without merit. > > > > If that is flamebait, then I think that our ability to > communicate is over. > > > > Goodbye, Paul. It was nice knowing you, up to a > point. > > I note that you respond only with another excuse for not > addressing > the merits of my proposal, including an implicit > mischaracterization > of the law reqarding the consensus process that must be > observed. The > Supreme Court disagreed in some detail with your > characterization of > "consensus" in the Indian Head decision. > > The consensus to be achieved at this meeting must be: > > "based on the *merits* of objective expert judgments > and through > procedures that prevent the standard-setting process from > being biased > by members with economic interests in stifling product > competition." > > Allied Tube & Conduit v. Indian Head, Inc., 486 U.S. > 492 (1988), > <http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=486&invol=492> > (reinstating jury award of treble damages under the Sherman > Act) > (footnote omitted) (emphasis added). > > You have contributed nothing going to the merits of my > proposal in > this thread and you ignore the complete absence at this > meeting of > "procedures that prevent the standard-setting process > from being > biased by members with economic interests in stifling > product > competition." > > You skip past the merits of my proposal, all due process > components of > consensus, and the fact that the scope of the charter > remains to be > determined merely to impugn my character and reputation by > suggesting > that my "place in the [unidentified] community" > is in need of > "salvage," a consistent theme of a host of > attacks on my character and > reputation you have made without factual or legal basis, > both on this > list and on your blog. > > Please notice: [i] the title of this thread, a use case > regarding > "interoperability in vertical and horizontal > markets;" and [ii] the > Court's concern about agreements among competitors in > vertical and > horizontal markets with anti-competive effects in the > Indian Head > decision, supra: > > "Typically, private standard-setting associations, > like the > Association in this case, include members having horizontal > and > vertical business relations. See generally 7 P. Areeda, > Antitrust Law > § 1477, p. 343 (1986) (trade and standard-setting > associations > routinely treated as continuing conspiracies of their > members). There > is no doubt that the members of such associations often > have economic > incentives to restrain competition and that the product > standards set > by such associations have a serious potential for > anticompetitive > harm." > > (".My use case is carefully tailored to expose > interoperability issues > that *must* as a matter of law be addressed in the OIIC > TC's > interoperability work. My use case is based on the present > state of > the ODF standard, prior statements by IBM officials as to > the types of > interoperability they deem necessary to fulfill market > requirements in > the market for office productivity software, and the body > of U.S. > antitrust law governing mergers of and agreements among > competitors in > vertical and horizontal markets, the body of law of which > antitrust > law applicable to voluntary standards organizations is only > a art. . > > In this thread your only apparent role has been to further > the cause > of "stifling product competition" in both > horizontal and vertical ODF > markets. by those with "economic interests in stifling > product > competition" though your diversions from a discussion > of the merits of > my proposal. You have no excuse of ignorance of that law; > you head a > team of nine lawyers in your firm who specialize in the law > governing > consortiums of competitors. > > Look down, Mr. Updegrove. That thin ODF legal ice you were > skating on > broke long ago. You took your first full plunge into a > Sherman Act > section 1 conspiracy in restraint of trade the first time > you > committed a single overt act in furtherance of the unlawful > goal. You > know the law in this area, despite your continuing efforts > to > mischaracterize it in your many appeals to ignorance > sprinkled across > the record of this meeting. I privately directed your > attention to > the Indian Head decision many months ago in regard to OASIS > and the > ODF TC and well before that a summary of that decision was > posted on > your Standards <meta> Library. > > Moreover, in your first attack on my reputation and > character at this > meeting, you stated that you lacked the technical training > to > participate on this list. With an admitted lack of > technical knowledge > necessary for participation, you have scant basis at best > for > pronouncing the applicable law. In principled legal > analysis, one > necessarily determines what the relevant facts are before > deciding > what result the law commands. You, sir, admittedly > participate without > knowledge of the facts and your opinions as to the > controlling law are > without an informed factual basis. That you mischaracterize > the law > you speak of only further detracts from the weight your > opinion > deserves.. > > Please desist from further attempts to divert attention > from the merit > of this or any other proposal I have made or make. You > merely deepen > the plunge you have already taken into unlawful conspiracy > in > restraint of trade. Speaking of technical points... marbux, your indirect reply to the suggestion that round-tripping can be implemented differently than through CDRF, I think, was that CDRF is already debugged and provides a large window towards HTML and similar standards. Well, I don't think that is a good enough reason to persist with CDRF. I am one of many apparently that thinks there are better ways to move forward than with CDRF. CDRF is light, and everything it offers as concerns interop can be incorporated into a different framework. Not to mention that an ODF through CDRF will require tons of debugging. [CDRF is also not compatible with ODF 1.1] Your indirect answer to Rob's point that OASIS switched MAY meanings to adhere to ISO rules was that ISO is a private org, implying that it is not above antitrust laws, and that its members have obligations requiring them to be attentive to antitrust laws. [You should consider spending time in conversations with all the signatories of the ISO/ODF standard instead of risking your own position by holding up an engineering group that doesn't seem to agree with your overall technical position very much -- in particular, I think most here feel that the decision to go with CDRF should not be decided ahead of the TC because of substantial doubts over your proclamation that it is a wonderful solution without peers.] .. I think instead of pushing for CDRF, you should push (or have pushed) for the standard to be combed and all MAY's fortified as necessary. That work will have to be done anyway if we use CDRF because CDRF says so little about anything of real substance. I made a proposal on this list http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00746.html that Mary McRae found problematic (too detailed and off topic I think was the reason given); however, it is currently still on the list. I suggest you look over it and address why you think CDRF is clearly better than that proposal.. why CDRF should force its way ahead of that proposal.. especially without each of these being vented in full. And I do believe that proposal allows you to maintain complete backwards compat with ODF 1.1, which would be a plus over CDRF. That reason this is is that CDRF is already set in stone, whereas, that other proposal was designed with ODF 1.1. in mind. Yes, the proposal is not detailed out fully by any means. I would prefer for now that you reply to that email (if you do) directly to me as Dave has done (thanks again Dave). Details of that proposal have advanced in a positive direction thanks to Dave's help [btw, almost everything on that proposal comes from ideas and needs detailed on this very list.. part of which (not the main part by any means) was thanks to marbux]. Round-tripping, as many have stated, is not a fundamental goal of interop, in particular, it is undesirable if you want real interop. [That other proposal I just mentioned leaves round-tripping open for those that don't mind lock-in risks, but allows that door to be closed to everyone that values preventing lock-in and having surety over what is in their documents.] Your reply to round-tripping weaknesses seems to be that there are a ton of legacy docs out there that require ODF be acceptable of them. The main counter-reply to that has been that ODF is not meant to solve everyone else's problems. Your main rejection of that is that Rob said that this TC has been requested to build some interop with some other standards. Well, I hope you can find some other reason because I don't think Rob said that "interop to *every* other standard through *CDRF*" is a must for this TC. In fact, neither interop with everything else nor CDRF are requirements. In particular, you refer to the importance of fake interop (as provided by CDRF) with Monopolysoft formats, even quoting IBM stating that it's unfeasible for many customers to migrate away from those closed formats. Well, don't see how you think that implies CDRF is the only solution for the OIIC TC. I'd say a more legitimate solution is for Monopolysoft to reveal their closed specs (my preference) and/or provide a converter into a completely open format. I think ODF is close to being that format. You should argue specifically why ODF isn't the aformentioned open format (if you believe that) and work to get it there. I believe ODF can become that format to handle everything in Monopolyware (assuming it isn't, and we'd need to talk to Monopolysoft to see why), and I think the proposal mentioned above would allow that to be the case in a superior fashion to CDRF. That is my technical opinion, and I think I have "demonstrated" in this email that is the case. I await your rebuttal (preferably off list). In closing... CDRF has holes that would need to be fixed to prevent being limited to opaque interop (your solution to interop with Monopolysoft formats is to ignore forcing Monopolysoft to open up.. that is an ANTICOMPETITIVE solution and as such has no place on an ODF related TC). There is a better proposal on the table that also addresses the opaque round-tripping as a last resort (or by preference of the user) but generally would require that Monopolysoft detail all their needs in the open to augment that ODF-NG proposal. Further, ODF-NG can be profiled to match ODF 1.1 semantics precisely, in particular, while accepting all existing ODF documents (even those that have interop issues). There are many other benefits to that proposal since it is based on a flexible framework that actually is intended to be locked down to protect user's docs from being corrupted with foreign tags. It achieves all of this strength and flexibility by focusing on profiles and allowing for many elements/attributes proposed by different third parties to be stored in a standard universally accessible database (over time) so as to meet the needs of most any profile to be developed over time. The key is that it gives the end user control instead of assuming round-tripping or anything else is the most important need for any specific user. I think we agree that profiling is the way forward, but CDRF is clearly not the only way to support profiling. What do you have left to insist that CDRF should be forced upon the OIIC TC ahead of time?