Re: [oiic-formation-discuss] Which is definitive odf?

[Andrew.Updegrove@gesmer.com]

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 [marbux@gmail.com]
Sent: 06/17/2008 02:40 AM MST
To: Shawn <sgrover@open2space.com>
Cc: oiic-formation-discuss@lists.oasis-open.org
Subject: Re: [oiic-formation-discuss] Which is definitive odf?



On Mon, Jun 16, 2008 at 12:26 PM, Shawn <sgrover@open2space.com> 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: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.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.