[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Which is definitive odf?
Marbux, this is utter nonsense. I challenge you to produce a single attorney in any country to support you in this endless stream of irrelevant misrepresentation. Find one attorney who will be willing to post an email to this thread saying he supports what you have said in the email I am replying to and I will withdraw this challenge and post a public apology. If what you say is established law this should be a simple task. Andy Sent by PDA ----- Original Message ----- From: marbux [email@example.com] Sent: 06/17/2008 02:40 AM MST To: Shawn <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [oiic-formation-discuss] Which is definitive odf? On Mon, Jun 16, 2008 at 12:26 PM, Shawn <firstname.lastname@example.org> wrote: > I see a few problems with this statement. > - you are introducing legal speak into a primarily technical discussion > again. Standardization activities at OASIS are substantially constrained by the law. Even worse, you seem to be quoting a policy (not a law) for one > specific nation. No, I referenced the Agreement on Technical Barriers to Trade and the Agreement on Government Procurement, international law that constrains the discretion of governments of somewhere near 100 nations, at all levels of government. I believe that legal issues are not for us to worry about > at this stage of the game. Then I urge you to consult with legal counsel because you could not be more wrong. Competition law is very concerned globally anytime competitors exchange information and negotiate agreements, such as a TC Charter or a standard. If you are not aware of your legal responsibilities, you cannot fulfill them. This meeting does not take place in a legal vacuum. We are still trying to decide what we are > talking about. Only after that has been determined (iow: after the charter > has been drafted), THEN we would need to worry about legal issues. No. Law constrains what information can be exchanged on this list as well as what gets into the charter. Moreover, if the goal is not a legal draft Charter, then much work will be wasted. What you propose is akin to writing an app without first determining that there is a market requirement to be fulfilled by it. One must determine the requirements before engaging in activity. By analogy, checking the applicable law only after committing a homicide does nothing to avoid the consequences of committing the homicide. Your favored approach places the cart before the horse. > - As a developer I need a something I can refer to when I am asked to > "conform" to that something. One need also be concerned that what one conforms to is lawful because law is superior to technical standards, a meta-standard for standards and standards work so to speak. At the present time, ODF is not a lawful standard. It is grossly under-specified both technically and legally. The pertinent question is whether this proposed TC's work will be lawful. The question was raised as to WHICH of the > various forms of the ODF standard was to be considered definitive. In plain > speak, this is saying to me "Tell me which file to get so that I can start > working". Nothing more. ISO/IEC, legalities, etc. become meaningless to me > at that point. I only need to know what file to grab. Then consult with competent legal counsel first. To reduce legal fees, I recommend calling to your attorney's attention the case WTDS 135 EC - Asbestos (March 12, 2001) <http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm> paragraphs 66-70 (in the HTML version, which has numbered paragraphs but lacks text attributes included in the DOC version, which includes no paragraph numbers) (The same law applies to standards work at OASIS, through other sections of the Agreement on Technical Barriers to Trade. There is no version of the ODF specification that has reached the threshold requirements of legality. > > - I believe making a choice as to which ODF version and/or specific file > falls within the scope of this discussion list. You are alluding that this > is not the case, or at the very least are introducing discussion that will > delay that choice. No. I am insisting that the choices made by this formation meeting must be lawful. One of the many applicable legal requirement is that standards work must be responsive to market requirements. There is a market requirement for implementations of ODF profiles that governments may lawfully use. For that market, only profiles of the ISO/IEC:26300 international standard may be used lawfully but non-profiled implementations of the ISO/IEC:26300 standard are unlawful. Ergo, responsiveness to market requirements in the market for government use of ODF implementations forces the choice of profiling ISO/IEC:26300 to respond to market requirements in that market. Any profile and conformance test development work on any other version of ODF responds only to the market requirements of non-governmental entities. Given that the government market is the largest definable market for ODF implementations and that government choices of standards drive other markets to standardize around government standards, this TC's work is most responsive to market requirements if it chooses ISO/IEC:26300 as the defining standard for its work. This is only one example of how law often simplifies technical choices. One need not go to court to resolve all disputes. All that is required is agreement to comply with the law where the law is clear and unambiguous. > - Your proposal is forcing backwards compatibility back to the start of > time. This will be impossible. I am willing to consider a motion to amend my proposal to limit the required support for earlier profile versions to versions for which there is still a market requirement. > If there is any defining characteristic for > the technology industry, it is "change". There will come a time where doing > it the "old" way just doesn't make sense. Agreed. But responsiveness to market requirements for the older versions is the guide, not developer laziness nor desire to break interoperability .The Agreement on Technical Barriers to Trade suggests that for international standards, the appropriate time for repeal of a standard is when it is no longer needed by the market. One may arrive at the same conclusion for voluntary standards through analysis of the competition law in the U.S. and the E.U., and likely of the competition law applicable in still other nations. The defining characteristic of change that you identify is not necessarily what is legal or responsive to market requirements. The IT industry is still a very young industry as these things go and is just beginning to realize that there are legal constraints on its behavior. E.g., the Microsoft antitrust cases in the U.S./ and the E.U. Conduct lawful outside the standards context, e.g., feature wars, is illegal in the context of standards. Standards are for markets that have stabilized enough that there is a need for an agreed standard that ends feature wars. A voluntary standard is an agreement among implementors to refocus from feature wars to competition based on price and customer service, defining *all* characteristics of a product that is substitutable in the market. Standards are about stability, not about innovation. They allow market participants to realign R&D investments to the means of lower production costs and competition within a market defined by the standard. Competition law allows voluntary standards only because customers benefit from lower prices and the substitutability of products. The major reason ODF and OOXML are unlawful standards is that they do not define all characteristics of an identifable product in mandatory terms. Both standards are so outside that law that they grant conformant status to custom application-specific extensions to the specifications, the waging of feature wars within the context of a standards that are standards in name only. In the context of document format standards, the mandatory substitutability of conforming goods translates into a requirement of specifying all conformance requirements essential to achieve interoperability. Interoperability is not a mere feature of a standard; it is the threshold legal requirement for a lawful standard.. > - So this is a moving target anyways. > - we can sit around and "discuss" this point till the cows come home. It's a > minor point. Pick a version/file and move on. For the government market, it is not a moving target until there is no longer a market requirement for ISO/IEC:26300 support and a new version of ODF is adopted as an international standard. If the new international standard version of ODF does not require that conformant implementations be able to write to the existing international standard version, then we have yet another legal problem to deal with. The driving legal force is market requirements, not developer requirements. Best regards, Paul E. Merrell, J.D. (Marbux) -- Universal Interoperability Council <http:www.universal-interop-council.org> --------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.org ***************************************** Any tax information or written tax advice contained herein (including any attachments) is not intended to be and cannot be used by any taxpayer for the purpose of avoiding tax penalties that may be imposed on the taxpayer. (The foregoing legend has been affixed pursuant to U.S. Treasury Regulations governing tax practice.) Electronic mail from Gesmer Updegrove LLP, 40 Broad Street, Boston, MA 02109. Voice: (617) 350-6800, Fax: (617) 350-6878. This communication is intended only for the use of the individual or entity named as the addressee. It may contain information which is privileged and/or confidential under applicable law. If you are not the intended recipient or such recipient's employee or agent, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please immediately notify Christopher O'Sullivan at (617) 350-6800 and notify the sender by electronic mail. Please expunge this communication without making any copies. Thank you for your cooperation.