Considering that the vote is often blocked by the originator of the standard
(Microsoft), either in isolation as in the Netherlands or in collaboration with
a number of very close partners,

I pointed my finger to Netherlands as a particularly clear case of abuse of a particularly vulnerable process where unanimity is required, but similar things have happened all over the world, including a large number of Microsoft partners literally flooding some committees to gain a unilateral control over their qualified majority vote. Also, I think your concern that I did not explicitly state that the JTC1 rules are different from the NB of the Netherlands is without merit. Of course the ISO officials know their own procedures. I did not send this to individual committee members or to any national standards bodies, it was sent to the chairs and the secretaries of ISO JTC1 and its SC34.

My apologies if you think I was not being balanced and truthful, but I really tried to be. Countering lies and misinformation with more lies and misinformation is definitely not my kind of tactics. On the contrary, I think what is needed here is truth, honesty, full and open disclosure and a good helping of common sense.

I said:

Groklaw created a document stating that patent claims in software patents
do not contains the methods and concepts described in the patent.
That is actually completly wrong as in fact patent claims in software patents
do mainly describe methods and concepts.
My opinion of Groklaw on patent law is that they "do not have a clue".

Then you write:

think you need to read that analysis again. Among other things,
they claimed that the clause "patents necessary for the implementation"
is actually an empty set, as no patents are necessary to implement
something in software

but just read this shortend version on grokdoc
http://www.grokdoc.net/index.php/EOOXML_objections#The_Microsoft_covenants_not_to_sue_grant_no_rights
shows that you did not read the analysis because the whole fundamental part is still about what I said. Your stament is only what they conclude based on patent claims not describing methods and concepts.

So if you really want to be taken serious don't tell people to read an analysis but actually read it yourself first !!!

And for naming Larry Rosen i'l actually cite him for you when he said on Office Open XML's covenant not to sue:
"This covenant is at least as generous as the patent licenses for many other document formats and industry standards"
The only thing I can remember him speak about was the cause about conformance as that wasn't clear at the time the covenant was published however Office Open XML has since then included a conformance section which makes very clear that partial implementations can be conformant.

Now I know you do not have a clue either.

So, on what grounds do you conclude that I have no clue? Because I disagree with you? If that makes you feel better, sure, go ahead. I know I have a clue, but I obviously fail miserably in getting that point across to you.

And the way you quote lines out of context is also sucky

I quoted the passages of your post I was responding to, and the full text of your post is in clear view right above mine for anyone to read. If you think that is "out of context" and "sucky", then that is your opinion, but I dare say it is a pretty unreasonable one. I actually quoted most of your short post, I certainly made an honest attempt to understand just what you were trying to say, and I showed you a great deal more respect than I thought your rather incoherent post deserved, for the sake of argument and because I had the time.

I read Andies blog and he does not state OOXML licensing is not open

No, but he and others sure conclude that the patent promise is vague enough to be potentially discriminatory and unreasonable, i.e not "RAND". If this is the case, then the standard would not be open. This is all I am saying, and that is really all that can be said without a deeper legal analysis, or taking it to court.

So, "86.84.111.211", despite honest attempts at treating you like a real person, I now have to conclude that you are a troll and only try to waste my time. You clearly do not respect me enough to give my opinion or my arguments any real consideration before responding, so I see no point in continuing this debate. You are still most welcome to contact me in person (you have my e-mail address) if you want to tell me that you are not a troll, but I see no point in continuing the conversation in this forum.

Groklaw created a document stating that patent claims in software patents do not contains the methods
and concepts described in the patent.

I think you need to read that analysis again. Among other things, they claimed that the clause "patents
necessary for the implementation" is actually an empty set, as no patents are necessary to implement
something in software. They might be useful if you know what they are about and can license them explicitly,
but no actual list of patents has been given by MS. Depending on how you implement things, it might be that
you infringe on some patents, but in no way is the patent as such absolutely necessary for implementing
the specification. The similar but less vague statement from Sun does not leave nearly as much open to
interpretation.

as long as his actions fall under the one-way agreement.

That is precisely the problem here: the actual actions falling under the agreement seem to be ambiguously
described at best, non-existent at worst.

Either one can read the MS OSP document and try to judge the apparent intent behind it, or one can read it
literally (as I have learned you should always do with legal documents) and raise questions like the ones
posted at Groklaw. There is definitely some strangely fuzzy wording in the OSP, and given the large amount
of legal counsel that must have gone into the writing of the OSP text, I find reason to question the motives
of MS. I am not saying that the OSP is bogus, I am simply saying that I do not think it is safe to assume that
MS is promising quite as much as free software developers would need to freely implement, say, relevant
parts of OOXML as beta support in OpenOffice.org, with some well-documented extensions to handle OOo
application settings, or to create a partial implementation of only SpreadsheetML in Gnumeric. There are
too many loopholes in the OSP statements, and I do not see why such an important document should need
to be so vague if its intents are open and honest. MS could easily calm people by updating the OSP to be
less ambiguous if they wanted to. They choose not to, and that worries me.

My opinion of Groklaw on patent law is that they "do not have a clue".
Let say they don't 'grok' patentlaw very wel.

That is your opinion, and you are certainly entitled to it. My opinion differs from yours, though.
You are dismissing not only Groklaw and Sam Hiser, but quite a few actual patent law and standards
experts who have the same concerns. Groklaw is not just Pamela Jones, it is far bigger than that.
What do you require in terms of experts? I think you are being unreasonable here, and if you keep
insisting that any expert I point to is incompetent, I see no point in having any argument with you.
You cannot simply dismiss everyone who does not agree with you as being clueless.

But actually for an open standard it only requires that Ecma procedures are open

It requires quite a lot more than that. Please be more careful in what you say. An open standard
is (among other things) required to be completely described by the standards document itself
or by reference to other open standards. It is not yet clear whether this is the case for OOXML.
It is also required that any patents covering methods and concepts described in an open standard
are made available on reasonable terms, and this has also been questioned.

Sam Hiser document I have read. It is very suggestive

It is certainly suggestive. He is a very strong opponent to OOXML, and makes no secret of it.
However, Andy Updegrove and Larry Rosen also read it, and even though they are also
opposing OOXML in many ways, they are legal experts, and their opinions differ from yours
in that they see real causes for concern in what Sam Hiser writes. Please tell me why I should
trust your word more than theirs. You are an anonymous poster here, and if I am to put more
credit in you than in well-renowned attorneys, you need to give me a lot more quality arguments.

Of course Sam Hiser is the guy that compared Microsoft with the WWII nazi's so his claims
should probably be seen in a certain kind of refence view themselves.

I could choose to dismiss everything Microsoft says on the grounds of them calling free software
advocates "information communists" in the past, but I suggest we leave such arguments out of this.
You may still choose to dismiss Sam Hiser, but what about Andy Updegrove and Larry Rosen?
Are they being misled by Sun to spread lies and risk their reputation, or are their concerns real
and the matter needs more legal investigation before we know what to make of the OSP?
You picked the single person I named who is not a legal expert and criticized his person
instead of his opinions, and you fail to mention the two people I named who are indeed attorneys.
That is the kind of behavior that will get you a reputation for being a troll, undeserved or not.

The only thing that can be remotly seem in the spec as being a reference to Office is the
compatibility tags.

Surely you can't be serious about this. The document is chock full of descriptions of
application-specific behavior. There is the numerical 1900-base date format (an Excel quirk),
lots of pages of clip art specific to MS Word, descriptions of embedded objects which are
very specifically tailored to what is supported in MS Office on Windows, the VML format
which is only included because MS Office still uses it in some places, just to name a few.

The main problem with the spec is that it confuses MS Office 2007 as an application
with OOXML as its XML storage format. If you say that the only connection between
OOXML and MS Office is the compatibility tags you are assuming a very extreme position
in this debate, a position significantly more extreme than the standards document itself,
which explicitly states that a main reason for its existence is to provide 100% compatibility
with MS Office applications.

But why not give us an example of what exact item in the spec is not open and not just some
vague references ?

First, you specifically asked me to "provide a single example of real legal experts" saying that
there might be problems with the openness of the OSP. I did. Now you are asking me to
provide a more detailed pointer to exactly what is not open? We could dance this dance forever,
but I do not have the time to chase your rabbits, and I am not the right person to do it either.

There are plenty of detailed claims in the documents you claim to have read. I suggest you read
them again. I could claim that I fear that according to Swedish law, the OSP gives me absolutely
no rights whatsoever, because it is not a binding contract and not a formal patent license,
and that I suspect that the promise is not a legal document according to Swedish law, but that
would just be my personal opinion. I am not a legal expert, I am just a person who is worried
that there is so much controversy over this issue, and that all criticism is simply dismissed
without any further comments by Microsoft.

Your posts are not helping much here, you are mostly just restating Microsoft's opinion that
anyone who raises any doubt that the OSP makes OOXML open should just shut up, because
everything is fine, we should trust them on it. Well, many people seem to think everything is
not necessarily fine, for what I think are perfectly good reasons.

In a formal promise or covenant like this the second party does not have to agree as long as his actions fall under the one-way agreement.

Regarding patent law that should be enough to use patents.
In patent law the owner of the patent has an exclusive right on a certain technology. It is acceptable for a patent owner to grant that right to many others and a promise/covenant seems a very acceptable way of doing that.
To infringe on a patent you have to use the patent without autority to do so. By releases the promise or covenant you can claim to have the autority to do use the patent. This infringment part is fairly similar in every country using patent law.

I hope this clarifies the covenant and open specification promise a bit.

Sam Hiser document I have read. It is very suggestive but he mostly states that OOXML is not open because Ecma is not open and because MS Office 2007 is not open.
But actually for an open standard it only requires that Ecma procedures are open and that membership of Ecma is non-discrimatory (not the same as free).
And as for his references to MS Office, I can't do anything with that as he relates lot's of stuff in the spec to hidden MS Office features where that is not evident from the spec. The only thing that can be remotly seem in the spec as being a reference to Office is the compatibility tags.

However they are either fully documented in OOXML and therefore fall under the patent release by the OSP or they are describing former bugs on rendering the spec and as rendering is implementation defined allover the OOXML spec this is not a worry in openness. Or to put that more clearly: if you have an Office document you can render it however you want including any compatibility tags.

Of course Sam Hiser is the guy that compared Microsoft with the WWII nazi's so his claims should probably be seen in a certain kind of refence view themselves.

But why not give us an example of what exact item in the spec is not open and not just some vague references ?

what matters is market security. I expected Microsoft to put forward national legal analysis.

It is very difficult to asses how this strange model will be applied in court. I was told it was an estoppel under American law but continental civil law is different.

I assume that a "promise" has absolutely no value and gets interpreted as an informal commitment. That may be different in the US.

I invite you find find a single comment from a lawfirm and/or a real legal expert on patent licensing
on OSP not being a valid open method for patent licensing.

Well, six serious issues found by Sam Hiser (at Sun) were analyzed by Andy Updegrove
(who is a standards attorney) and Larry Rosen (also an attorney, with significant experience
with software and patent licenses), and both of them found real causes for concern.
A nice summary is on Groklaw. Did you even look properly before posting your challenge?
I found this by a simple Google search, in much less than a minute.

Actually the comments are now being taken to the project editor

The project editor is suggested by Ecma (as is normal procedure in accordence with ISO directives).
It is a logical choice to have an editor that is related to the submitting organisation.

So in this case the project editor for is Ecma Liaison, Rex Jaeschke who is employed by Microsoft.
A logical choice as it would be virtually impossible for an outside 3rd party to suggest edits for the standard.

So actually the comments will be dealt with by an Ecma appointed project editor that works for Microsoft.

The original post said "ECMA has said it will handle the comments". This is very different from what is
being said above. It is still ISO who handles the comments, only the ISO project editor is suggested
by ECMA. The ball is still with ISO, not ECMA. I restate my point: ECMA as an organisation is currently
not in a position to make promises regarding what will and what will not be handled in the process.
Until ISO or someone speaking with formal authority from ISO (like the project editor) says that
comments sent in with "approve" votes will indeed be handled, no promise has been made.

Good news, though, that all comments are at least being sent over to the editor, that indicates
that they will probably be considered in some way. I wish Rex Jaeschke all the best in handling the
comment resolution, and I hope he will receive proper support from ISO, and not be left with the
same people who failed so miserably in drafting ECMA-376.

Actually Ecma TC45 is already planning several meetings to discuss the comments

I would strongly suggest enlisting some outside help. ECMA TC45 did not get it right the
first time, so they are either not skilled enough, or simply too few and too busy for the
huge task at hand. I do not mean to be disrespectful, but TC45 are probably not enough
hands, eyes and brains for the job.

You seem to have some insider insight into this. If you are uncomfortable with posting here
without anonymity, would you consider dropping me an email so we can be formally introduced?
I do not bite, and I do not have a hidden agenda, just a very keen private and professional
interest in this issue, and anything you send me in private will stay private.
My mail address is "moc.liamg|nosvatsug.nafets#moc.liamg|nosvatsug.nafets".

Office Open XML already contains the mechnism you suggest. It is called custom tags.

So why not use it? Why clutter up the namespace with custom element names? It's simply bad XML, a beginner's mistake.

adding the compatibility settings for it's previous format is only really curtesy as using undocumented propriety custom settings

Are you deliberately using confusing words here? Surely you realize that custom setting need neither be "undocumented" nor "proprietary", they can simply be "custom settings". Any custom settings implemented in the form of specific XML attributes and values can certainly be documented, and they can be shared between applications and be made cross-compatible between multiple implementations if that is considered appropriate. Reserving a closed set of element names for Microsoft's own use is certainly not my idea of what is appropriate in an open, vendor-neutral file format. OOXML should get rid of such baggage and play nice, by specifying application-specific behavior and settings for MS Office in a general, application-neutral way. Of course they should be documented, that goes without saying.

If Ecma/Microsoft remove these item from the spec and start using the custom tags there is no interoperable
way to built converters that can make interpretable compatibility settings

This is pure nonsense. How a setting is stored obviously has no bearing on whether it can be supported or not.
I am suggesting that the closed set of specific compatibility tag names be scrapped, and that the very same
information is instead encoded in a more general, extensible and vendor-neutral way which is well documented
and openly published by Microsoft. Vendor-specific settings can and should be moved out of the standard.
The standard tries to document every single quirk and obscure feature of MS Office, and that is why it fails.
All over the document, there is considerable confusion between specific application behavior and the document
format. This is where most of the revision work is needed, in my opinion. Decouple the standard from the
MS Office 2007 implementation. Not doing so would imply that no other implementation is ever expected.

But now that is actually a strategy supported by FFII !!!

I don't get this last comment. Are you assuming I have a connection to FFII or to this website?
I most definitely have not. Please read my profile. I am a university researcher from Sweden.

Also, please do not try to taunt me. I am a very calm person, and I care far too much for this
issue to be engaged in any heated conversations. Keep it civil, and I'm happy to talk. Trying
to pick a quote, read it wrong and turn it on me is not going to work, trust me.

BTW, please create an account and log in, it's always nice to know who I am talking to, and
you seem like a very good person to have a real, constructive conversation with on these
issues. If you like, drop me an email. I will not post any of my private email in public without
asking for permission first, and I'd be happy to talk to you in private if you feel this is a too
hostile environment. My gmail account works best, as this is not part of my daytime job:
"moc.liamg|nosvatsug.nafets#moc.liamg|nosvatsug.nafets"

All compatibility tags should be redefined to use a common parent as in ODF, something like:
<compatibilitySetting vendor="Microsoft" name="placeFootnotesLikeWW95" value="true">

Allthough that suggestion is even better than ODF because it has an actual vendor property you should understand that Office Open XML already contains the mechnism you suggest. It is called custom tags. So adding the compatibility settings for it's previous format is only really curtesy as using undocumented propriety custom settings like in ODF would have led to an uproar of Microsoft not being open about their compatibility settings.

Also the current addition of the compatibility settings allow for multiple converters to be built that can convert the compatibility settings 1:1 from binary files to standardised Office Open XML files. If Ecma/Microsoft remove these item from the spec and start using the custom tags there is no interoperable way to built converters that can make interpretable compatibility settings It will limit legacy conversion to MS products and interpreting the then undocumented compatiblity settings to MS products as well, creating a vendor lockin on converted documents.

But now that is actually a strategy supported by FFII !!!

ECMA has no standing in this at present.
It has already approved ECMA-376 with all its bugs and sent it to ISO for approval.

Actually the comments are now being taken to the project editor

The project editor is suggested by Ecma (as is normal procedure in accordence with ISO directives).
It is a logical choice to have an editor that is related to the submitting organisation.

So in this case the project editor for is Ecma Liaison, Rex Jaeschke who is employed by Microsoft.
A logical choice as it would be virtually impossible for an outside 3rd party to suggest edits for the standard.

So actually the comments will be dealt with by an Ecma appointed project editor that works for Microsoft.
And you think Ecma has no standing ? You should understand ISO procudures better. It is of course the intention of ISO to have maintenance done by Ecma and therefore logical that Ecma is the lead on making edits based on the comments that accompany the ballots.

Actually Ecma TC45 is already planning several meetings to discuss the comments (I asume with the project editor in attendance) and how and which to add those to the specification.
So that part of the fasttrack is actually working as it should and will certainly lead to a much improved version having a lot less faults in it.

Therefore indeed the ballot resulotion meeting will be about a lot of the above listed more relavant issues.

I can fully agree on the list of fundamental issues above. Those are not the only issues I have,
but they are certainly all among the top ten. Many of them have fairly simple resolutions if
ECMA and Microsoft are willing to make changes to the standard which affect the shipping
implementation in Office 2007.

Asking to remove VML has been shot down as a political issue by some MS rebuttal of comments,
as the format is claimed to be included for legacy reasons only, but the fact is there is a small
amount of mandatory VML markup left in the format for a few important elements, and if that
goes we get a much cleaner standard. VML should go, not even to an annex, it should just go.
That resolution is simple, but it might not be met with enthusiasm by Microsoft.

All compatibility tags should be redefined to use a common parent as in ODF, something like:
<compatibilitySetting vendor="Microsoft" name="placeFootnotesLikeWW95" value="true">
That would make it vendor neutral, easy to skip by any application not supporting it,
and keep the schema free from clutter and lots of unnecessary tag names. XML basics, really.
This resolution is also simple, but once again, it has never been suggested by Microsoft that
they are willing to do any such changes to the existing implementation in Office 2007.

I could go on, but I certainly don't have all the answers. However, you see my point. If the
standard is allowed to change at all, there are often very simple resolutions. The problem is
that the standard is held hostage to the behavior of a single implementation (Office 2007),
and that is unfortunate.

ISO has good people who cannot be as easily bought, fooled or coerced into favoring any
specific interests to either side, and the SC34 committee is a long-standing list of international
and renowned experts. I trust ISO to find the answers here. They have done a very good
job so far, and they simply can't afford to have their expertise or neutrality questioned.

My point, which you are still dodging, is this: only by blocking a "no" vote to "abstain" is it possible
to have all comments from other parties discarded. Blocking a "yes" vote is actually correct behavior
if you have any concerns with the standard, and I think we can all agree that many concerns over
OOXML are based on actual perceived issues from real people, not only some global conspiracy from
IBM or FFII. Some comments might be unreasonable, some are probably based on misunderstandings,
many comments have quite obviously been based on findings made by IBM and FFII initiatives, and
some comments are undoubtedly sent in for political reasons by people who just don't like Microsoft,
but at least some of the people who submitted all those comments must be credited with real concern
over them, regardless of whether they found them by their own reading of the huge standard or if they got
some pointers. You can't just dismiss all comments by saying that there are commercial interests on
both sides, and conclude that anyone having problems with this standard should therefore just shut up.
Surely SOME of the hundreds of objections at least from others than IBM, Sun and FFII must be of
some significance and require a resolution, even in your opinion? If so, an "approve" vote is inappropriate.

I fail to see how your argumentation holds together. If the standard really is OK as it is and all the
objections are from a bunch of zealots, whiners and ugly competitors, then that will be made clear in
the ballot resolution process. Unreasonable comments will not stand the scrutiny of ISO JTC1 SC34.
They are not a bunch of idiots, they are qualified experts on document markup and standards professionals,
and contrary to ECMA they have significant expertise and an excellent track record with document standards.
I fully expect them to shoot any unreasonable comments down, but I also count on them to address the
real issues and find a resolution.

The ISO ballot rules are clear: technical comments are to be submitted only as a "disapprove with
comments" vote. Anyone with any substantial objections to having the standard passed in exactly
its current form is explicitly asked by ISO to submit comments and vote "disapprove".

To suggest it will leave a format with hubndreds of bugs in it is therefore not correct. Also in quantity a lot of the bugs are found in either examples or in not validating XML's that although anoying are unlikely to cause much problems anyways. Ecma won't have problems fixing issues that are either minor bugs or editorial explantion issues.

There are only a few fundamental issues with the specifcation that will surface at the ballot resolution meeting.

• Should VML still be included or be in an annex.
• Should compatibility tags be in the spec or not (or should they just be undefined propriety items)
• Is the spec open (allthough not a single expert ever said it isn't that it is still raised a lot)
• Should the XML'led bitmask items be replaced with more true XML items
• Should the spec drop the alternative country countries and only keep IS 639 country codes
• Should spreadsheetML support ISO dates (or a subset thereof like ODF)
• Should the decimal 1900 date format in Spreadsheet ML be either removed or depraceted

If the several hundred editorial and minor bugs are all dealt with and for most of the above list Ecma can satisfy the national bodies concerns I have little doubt the spec will be approved.

The debugging process of proposed standards that ISO/IEC JTC1 has today in practice has been demonstrated during the CP and DIS 29500 procedures that can be nullified in any moment by any entity having presence in all the NSBs (as Microsoft has).

Which are the mechanisms that JTC1 has to avoid the hijacking of national committees and subcommittees. It has been demonstrated in USA, Italy, Holland, Portugal and much other countries, that any company with a wide partner network can hijack a lot of the (sub)committees and avoid the study and debugging of the proposed specification.

A big problem has raised for ISO/IEC. Their quality process has been seriously compromised with DIS 29500…

Perhaps Microsoft will win its ISO 29500 not having to solve any of its hundreds of technical problems, but surely never ISO will be perceived the same after that granting.

Microsoft could win, but ISO will lose the most.

Your concern would be appropriate if there had indeed been a focused minority group or a single

party blocking "yes" votes in committees worldwide.

In every country that they are present IBM, Sun and FFII have voted against OOXML ?

Your concern would be appropriate if there had indeed been a focused minority group or a single
party blocking "yes" votes in committees worldwide. This is clearly not the case. Rather, it is
mostly the other way around, and it is only by deliberately blocking a "no with comments" and
force an "abstain" vote that comments can be discarded, comments which would otherwise have
been included with the ballot to ISO.

The context is very important here. We are not talking "yes" or "no" votes in the usual sense of
the words. Please read up on the ISO ballot procedures. "Approve" and "Disapprove" votes both
have a specific focus on eventually getting the standard approved. The process assumes that
there is a valid reason for having the standard in the first place, and the ballot reflects this.

An "approve" vote may include comments, but they are not given any formal status and are
included for informational purposes only. Comments sent in with an approval are not in any
way guaranteed to be addressed, much less resolved by ISO. "Approve" means "yes",
without reservations.

A vote of "disapprove with comments" in the ISO ballot sense means "yes, if these particular
issues are resolved". There is no way for a vote to be cast that says "no, drop this standard".
It is up to ISO to decide if a standards proposal should be discarded and not be allowed to
progress any further in its current incarnation. Even then, it is still not being scrapped, it is
simply sent back to the submitter for a possible revision and later resubmission to ISO.

The "abstain" vote literally means "we don't care, do as you like". An "abstain" vote formally
cannot include comments, and any comments sent with an "abstain" vote are most likely
discarded, at best noted by ISO but certainly not acted upon.

My point, which you seem to be missing, is that there is a very different reason why many
countries ended up with an "abstain" vote than what is caught by the single word "abstain".
I pointed out that in this particular case, there is a reason which motivates looking at the
comments which were discarded, to see who raised those comments and who agreed on
them. Controversy is not a common ingredient in a standards proposal. The process was
clearly not designed to handle it properly. We need ISO to look behind the "abstain" votes,
or they will simply not get the whole picture.

An explicit count of votes would have been the ideal here. Wouldn't it be nice for ISO to
see clear statements to the effect of "4 out of 10 members of the TC approved without
comments, 1 had no opinion, but 5 had these issues, so a majority approval requires
them to be resolved", or "9 out of 10 voted for approval, only 1 named member was
in disagreement and wishes these comments to be noted". Requiring an entire country
to submit one representative vote is clearly overly restrictive in this case, seeing how
many have had to bail out and abstain.

What you are saying is that the covenant not to sue by Sun and the OSP by micrsoft are actually not valid in your country making the licensing for Opendocument and Office open XML worthless ????

Let me take you bait and bounce it back:
I invite you find find a single comment from a lawfirm and/or a real legal expert on patent licensing on OSP not being a valid open method for patent licensing.

Surely you mean party, as it evident that only Microsoft CAN use this format practically and legaly.

http://blogs.infosupport.com/wouterv/archive/2007/08/18/How-I-voted-for-the-Open-XML-ISO-.aspx

To quote from that : "the fact that during our last meeting it was repeatedly made clear that a vote that would result in Open XML becoming an ISO standard was highly unfavorable for some, and would have no chance of succeeding"

This open letter is therefore very suggestive and selective in information on the standardization proces in the Netherlands. It was evident that even Microsoft would have been be willing to send in the accompany the abstain ballot with the comments that was consensus on so that the effort to reach consensus on these comments would have not gone to waste.

Concluding:
Considering that the voted for approval for Office Open XML is often blocked by competitors or parties with an interest in the competive format Opendocument it seems clear that the system is open to exploit by a small minority of committee members who wish for an "abstain" vote to block comments if a "NO" vote cannot be reached.

It seems very strange that a small group of parties with an interest in a different competing format and that have no special interest in using the proposed format because of their use in another format can influence ISO procedures and block the interest of parties that are actually able and willing to use the proposed format.

Dear ISO JTC1 officials,

I am writing to you to point out a fundamental problem with the procedure for
ISO standards ballots from ISO member countries, a problem which has been
made apparent with the recent unusual development in the ballot for ISO/IEC
DIS 29500, Office Open XML. The regular ISO comment resolution procedures
state, if I am not misinformed, that:

"The only comments that the Project Editor is allowed to consider are those
submitted via the ballot."

This is most unfortunate, since there are two distinct and very different reasons
for a member country to arrive at the response "abstain".

In one case, it is "abstain for lack of interest and/or expertise", in which
case it is of course perfectly OK to ignore that member country.

The other case, however, is "abstain for lack of consensus regarding numerous
comments". Because this is exactly what has happened recently in a number
of member countries when voting on DIS 29500, I strongly urge you to look at
the procedure behind each "abstain" votes and take into consideration the fact
that "abstain" in fact often means "this issue is so full of controversy that
we cannot agree on a unanimous vote". To restrict the set of comments being
processed further to include only those submitted via a "no with comments"
vote would be to throw away a very large portion of all the criticism which has
emerged regarding DIS 29500, disregarding hard and honest work by expert
reviewers who pointed out what they perceived as problems with the standard.
Such problems were often agreed upon by a substantial part of the respective
technical committees, but consensus or a required qualified majority was not
reached.

These ballot procedures are clearly unsatisfactory for issues where there is
controversy and a strong commercial interest in having a standard approved.
Considering that the vote is often blocked by the originator of the standard
(Microsoft), either in isolation as in the Netherlands or in collaboration with
a number of very close partners, it is clear that the system is open to
exploit by a small minority of committee members who wish for an "abstain"
vote to block comments if a "yes" vote cannot be reached.

This state of affairs is most unfortunate, and the credibility of ISO as a high
quality standards body is at stake if such unilateral attempts at sabotage of
the ballot process are allowed to pass formally unnoticed by ISO in the
upcoming ballot resolution process.

As an example, the Netherlands TC recently voted almost unanimously for
a "no with comments". Only Microsoft, not even its partners, voted against,
so a consensus was not reached. Therefore, the vote was "abstain" and
hundreds of comments were unduly discarded. One account of the process
behind Netherland's "abstain" vote is here:

http://www.noooxml.org/forum/t-16678/

The purpose of that web site is to strongly oppose DIS 29500, but I have
no reason to doubt the credibility of their report of the events, as it
originates from one of the members of the TC.

Please take the unusual nature of this ballot into consideration when
considering the upcoming action from ISO. As I said, the very credibility
of ISO as a high quality standards body is at stake.

Sincerely,

Stefan Gustavson, Linkoping University, Sweden (es.uil.nti|ugets#es.uil.nti|ugets)
Volunteer technical reviewer of ISO/IEC DIS 29500 for SIS