decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
The ISO Document: India's and Venezuela's Appeals, as text - Updated with comments chart
Monday, July 14 2008 @ 01:30 PM EDT

Here are the appeals to the ISO from India's Bureau of Indian Standards and Venezuela's standards body, FONDONORMA, regarding OOXML, as text, thanks to Steve Martin, once again, and Erwan. The PDF is here, if you wish to check it. India's section begins on page 13. Venezuela is on page 15. I've grouped them together because their issues are similar. We've seen and commented on Brazil's appeal and that same link takes you to a text version of the ISO/IEC's responses. If someone has time to help do a text version of South Africa's appeal, I'd appreciate it.

India, like Brazil, is bothered by not having the final text within a month, as per the JTC 1 directives, particularly when so many changes were voted on at the BRM. How can a national body know whether or not to appeal without a final text to analyze? So it asked that the window to appeal be extended, so that it had the opportunity to examine the final text. Venezuela challenges the entire process and says it undermines ISO's reputation. It raises the issue of a bad precedent being set, whereby large companies can exercise undue political pressure on a decision about a standard, instead of letting technical people work through and solve all the technical problems, which is what ISO normally has a history of doing quite well, from all I've heard:

The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem.

That really gets to the heart of the problem, in my book. So this was a first, as far as Venezuela is concerned, and one that it worries will start a new trend. It provides a list of comments on technical problems it raised, or tried to, that it feels were not appropriately handled at the BRM.

With regard to India's issue that a JTC 1 directive was violated by not releasing the final text within a month and its request to have more time to appeal until a final text was available to work from, the ISO memo sent to the Technical Management Board with analysis and recommendations regarding the appeals said:

6. "Final" text of ISO/IEC 29500 or ISO/IEC DIS 29500, or "revised FDIS text", not released
6e. Correct but irrelevant. The decision being appealed is the JTC 1 decision to approve the draft. The text mentioned in the Directives and by the appellants is not germane to that decision, which must be taken on the basis of the original DIS text and the actions taken by the BRM on the comments. The provisions of any revised text is not for purposes of further decision by NBs.

It's a Catch 22. India says there were too many changes to be able to keep track. Most fast track submissions are already standards, already in use, so changes tend to be typos and minor things. This was a beast of a different color, so it's hard to be sure you even know what changes were made, since most of them were bulk voted. That is India's issue, and ISO/IEC's reaction is hardly responsive to the problem raised.

Venezuela

Venezuela's issues are deeper. Not only were there a lot of technical issues voted on without adequate discussion at the BRM, Venezuela believes there are too many left undiscussed, never voted on, and still not fixed. You can see an itemized list beginning on page 31. Many issues were not presented at the BRM -- if you remember, that was one of Brazil's complaints, that it tried to speak and was not allowed to -- but of the 1027 items that were allowed and were available for discussion, only 189 were discussed at the BRM. The rest, 838, were decided by group voting. Pages 32 through 35 is an itemization of issues and how they were handled at the BRM, if they were. It's an appalling list, which we are working to get for you as text. Here's one:

NB/MB Comment VE-0031 - BRM Question Number 0232 (related) - Covered in BRM? No - Appropriately Addressed? No. Ecma claims that DIS 29500 is compatible with SVG, but errors occur when the reference implementation is replicated.

Here's a comment one can't help but notice, about VE-0029, which also was never discussed at the BRM. Was it appropriately addressed? No, says Venezuela, because "Ecma does not understand the observation." Here's one a bit more somber:

NB/MB COmment VE-0002 - BRM Question Number 142 - Covered in BRM? No - Appropriately addressed? NO. The use of BLOBs (Binary Large Objects) is maintained, without specifying mechanisms for retrieving/displaying them and also leaving the implementation up to the developer without any specification.

That's geek for "No one can use OOXML at the moment but Microsoft, because only it knows how to retrieve/display the proprietary parts." Is it a standard if only one proprietary company can implement it fully, because only they have the key to all the doors, so to speak? Isn't equal access and full specification kind of the point of a standard?

The way matters were handled, Venezuela believes, undermines ISO's reputation, if it approves such a result. And deeper:

Venezuela challenges the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that by far did not provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives for not requiring any such [l]imitation as to duration.

The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem.

ISO's response, which you can see noted in the yellow boxes:

4. BRM "inconclusive", too short, arbitrarily short, or otherwise incorrectly conducted.
4e. Not correct. Decisions on the comments not discussed during the BRM and proposed dispositions were taken by a process agreed by the BRM itself (29 votes in favour, none against and 2 abstentions.

5. Final report of the BRM not issued.

5e. Not correct. The final report of the BRM was issued on 2008-03-06.

6. "Final" text of ISO/IEC 29500 or ISO/IEC DIS 29500, or "revised FDIS text", not released

6e. Correct but irrelevant. The decision being appealed is the JTC 1 decision to approve the draft. The text mentioned in the Directives and by the appellants is not germane to that decision, which must be taken on the basis of the original DIS text and the actions taken by the BRM on the comments. The provisions of any revised text is not for purposes of further decision by NBs.
8. Document does not follow ISO guidelines for presentation of standards.
8e. Correct but irrelevant. Fast-track submissions need not follow ISO or IEC guidelines for presentation of standards. The corresponding standard must be made to follow the guidelines from its next revision onwards (see JTC 1 Directives, 13).
9. NBs were required to analyze far too much information in far too little time.
9e. A matter for NBs' judgement, which they expressed through their positive or negative vote on the draft.
10. Process followed was incompatible with the principles of consensus, technically-oriented discussions and "redundancy of standards", was dominated by large multinational organization(s), and has harmed the reputations of both ISO and the IEC
10e. Insofar as observation of Statutes, Rules of Procedure, Directives and other rules is concerned, this is not correct. Otherwise it is a matter for NBs' judgement, which they expressed through their positive or negative vote on the draft.

I commented on the ISO/IEC response before, so no need to repeat it. They didn't highlight their answer number 4, but it's clearly a Venezuelan issue, in that they mentioned arbitrary cutoff of discussion time. Why was it all so rushed? It gives me the feel of when someone calls you on the phone to sell you something, and if you ask to read some materials about the offer before making a decision, tells you an immediate yes or no is required. I always say no to offers like that, no matter how good they sound, because if I can't study an offer in detail and get my questions answered, how can I make a good decision? That is likely why the appeals suggest that OOXML be taken off the Fast Track and resubmitted in the regular way, so all the many questions can be discussed and answered.

Update: Erwan has finished the table of comments and their disposition, as submitted by Venezuela, which I have now included as the final item. The pagination is as per the PDF.

*****************************

Rakesh Kacker, IAS
Director General
BUREAU OF INDIAN STANDARDS
[address]

Our Ref: LITD/ADGT/Misc

Mr Alan Bryden
ISO Secretary General
ISO Central Secretariat
[address]

Subject: Appeal from Indian National Body regarding ISO 29500 OOXML

Dear Sir

The Indian National Body (BIS) hereby submits the following appeal under provision of Clause 11 of JTC 1 directives in reference to ISO 29500 OOXML:

During the Ballot Resolution Meeting (BRM) on 25-29Feb 2008, a large number of modifications were decided to be made in the document. The whole document was restructured and scopes of different parts were modified.

As per 13.12 of JTC 1 directives it is stated that "In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and final DIS text in case of acceptance." However, the final text incorporating the modifications, as envisaged in the BRM is not available even as on date, thus violating JTC 1 directive.

(13)

All national bodies have the right to appeal in accordance with Clause 11 of JTC 1 Directives. In the present case, as P-member national body, it is not possible to exercise our right to appeal in reference to the content of the final text of the ISO 29500, as the same has not been made available to national bodies till date. Thus in terms of the provisions of 11.1.2 of JTC 1 Directives, there is a clear case for appeal.

We therefore request ISO to extend the permissible time period for the appeal providing sufficient time for examining the final text of the standard after the same has been made available to the national bodies.

Best Regards

(signature)

(Rakesh Kacker)
Director General, Bureau of Indian Standards

cc ISO/IEC JTC 1 Chairperson
ISO/IEC JTC 1 Secretariat

(14)

*******************************
*******************************

FONDONORMA
Fondo para la Normalización
y Certificación de la Calidad

RIF:J000932670

Caracas, 30th May, 2008
Ref N° GN0080-08

Mr Alan Bryden
Secretary-General
Internacional Organization for Standardization ISO
CH-1211 Geneva 20
Switzerland
+ 41 22 733 34 30/ central(AT)iso.org

Appeal from the Venezuelan national body regarding the outcome of the fast-track processing of DIS 29500 Office Open XML.

The national body of Venezuela (FONDONORMA), as a P member of JTC 1, hereby submits an appeal against the outcome of the fast track processing of DIS 29500 Office open XML.

This appeal is made in accordance with Clause 11.1.2; "A P member of JCT 1 or an SC may appeal against any action, or inaction, on the part of JTC 1 or an SC when the P member considers that in such action or inaction:

* questions of principle are involved;

* the contents of a draft may be detrimental to the reputation of IEC or ISO; or

* the point giving rise to objection was not known to JTC 1 or SC during earlier discussions."

Reasons for appeal
1- In our opinion, the procedures used during the discussions of DIS 29500, including the Ballot Resolution Meeting held from 25 to 29 February 2008 are incompatibles with basic principles to the standardization, such as consensus, technically oriented discussions and redundancy of standards, among others.Attachment 1, Item 10

2- It is also our opinion that the proposed standard produced trough this procedures may be detrimental to the reputation of IEC or ISO as an standardization body, because of the clear absence of guidelines for the presentation of ISO standards. Attachment 1, Item 8

3- We believe that the use of the fast track procedures was inadequate to the length and technical complexity of the DIS 29500 proposal, which added to the lack of technical, objective discussion, and the fact that procedures used during the Ballot Resolution Meeting held from 25 to 29 February 2008 leaved unattended too many standing technical issues in the proposal, resulted in a standard proposal that lacks the quality that usually describes the body of work of ISO. Attachment 1, Item 9

4- We also raise to your consideration the fact that up to date of writing, neither the final report of the BRM meeting or the revised FDIS text has been circulated by the SC Secretariat, in clear contradiction with clause 13.12, last bullet point: "In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and fnal DIS text in case of acceptance." Attachment 1, Items 5, 6
Conclusion

Venezuela challenges the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that by far did not provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives for not requiring any such [l]imitation as to duration.

The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem.

Best regards

Maria Teresa Saccucci
Standardization Manager
FONDONORMA
Venezuela

cc ISO TMB Secretary (Mr Mike Smith)
IEC SMB Secretary (Mr Jack Sheldon)
ISO/IEC JTC 1 Chairman (Mr Scott Jameson scott.jameson (AT) hp.com)
ISO/IEC JTC 1 Secretariat (Ms Lisa Rajchel lrajchel (AT) ansi.org)

[Fax]


Annex 1 – BRM Vote Breakdown Table

Total of responses available for
discussion
Total of responses addressed at
the BRM
Total of responses decided by
group-voting
1027 - 100% 189 – 18,4% 838 – 81,6 %

(31)

Annex 2 – Standing Issues as presented by VE

NB/MB
Comment
BRM
Question
Number
Covered in
BRM?
Appropiately Addressed?
VE-0001 102 YES NO. The mechanisms persist in an annex when they
should be entirely removed. Also, the use of MD2 and
MD4 (weak cryptographic algorithms) is suggested.
VE-0002 142 NO NO. The use of BLOBs (Binary Large Objects) is
mantained, without specifying mechanisms for
retrieving/displaying them and also leaving the
implementation up to the developer without any
specifications.
VE-0007 0073 NO NO. Pseudo-code is not specified in the standard. This
was not addressed at the BRM
VE-0008 0035 NO NO. Complex configurations are moved and rewritten in
an annex and the necessary documentation has not been
delivered.
VE-0009 0035 NO NO. Complex configurations are moved and rewritten in
an annex and the necessary documentation has not been
delivered.
VE-0010
YES YES
VE-0011 0018 NO NO. The changes made at the BRM keep the old style
date format as the default. 1900 should not be handled as
a leap year.
VE-0012 0035 NO NO. Complex configurations are moved and rewritten in
an annex and the necessary documentation has not been
delivered.

VE-0013 0092 YES NO. New XML types are defined as to eliminate VML,
however, there's no text that explains the new XML
types or their meaning. VML is moved to an annex when
it should be entirely removed.
VE-0014 0092 YES NO. New XML types are defined as to eliminate VML,
however, there's no text that explains the new XML
types or their meaning. VML is moved to an annex when
it should be entirely removed.
VE-0015
YES YES
VE-0016 0101
(related)
NO NO. All the render parameters are left to the application
side implementation.
VE-0017 102 YES NO. The mechanisms persist in an annex when they

(32)





should be entirely removed. Also, the use of MD2 and
MD4 (weak cryptographic algorithms) is suggested.
VE-0018
YES YES
VE-0019
YES YES
VE-0020
YES YES
VE-0021 0099 YES NO. Partially addressed. Proposes a dual mode solution,
when it should propose a universal solution.
VE-0022
YES YES
VE-0023 0099 YES NO. Partially addressed. Proposes a dual mode solution,
when it should propose a universal solution.
VE-0024
YES YES
VE-0025
YES YES
VE-0026
NO NO. Ecma claims that this is against the proposal
objectives.
VE-0027
YES YES
VE-0028
NO NO. Ecma claims that this is against the proposal
objectives.
VE-0029
NO NO. Ecma does not understand the observation.
VE-0030
YES YES
VE-0031 0232
(related)
NO NO. Ecma claims that DIS 29500 is compatible with
SVG, but errors occur when the reference
implementation is replicated.
VE-0032
YES YES
VE-0033
YES YES
VE-0034
YES YES
VE-0035 0016 YES NO. The proposed solution partially changes the text that
defines ST_LangCode and keeps the same underlying
failure of having two ways of identifiying languages
instead of using ISO 639
VE-0036 0016 YES NO. The proposed solution partially changes the text that
defines ST_LangCode and keeps the same underlying
failure of having two ways of identifiying languages
instead of using ISO 639
VE-0037
YES YES
VE-0038 0016 YES NO. The proposed solution partially changes the text that
defines ST_LangCode and keeps the same underlying
failure of having two ways of identifiying languages
instead of using ISO 639
VE-0039
YES YES

(33)


VE-0040
YES YES
VE-0041
YES YES
VE-0042
NO NO. The XSLT standart is allowed as a customization
and it's not default.
VE-0043
YES YES
VE-0044
YES YES
VE-0045
YES YES
VE-0046
YES YES
VE-0047
YES YES
VE-0048
YES YES
VE-0049
YES YES
VE-0050
YES YES. Comment: OOXML uses a custom type to store
content that goes against the XML standard.
VE-0051
YES YES
VE-0052
YES YES
VE-0053
YES YES. Comment: OOXML uses a custom type to store
content that goes against the XML standard.
VE-0054 102 YES NO. The mechanisms persist in an annex when they
should be entirely removed. Also, the use of MD2 and
MD4 (weak cryptographic algorithms) is suggested.
VE-0055 102 YES NO. The mechanisms persist in an annex when they
should be entirely removed. Also, the use of MD2 and
MD4 (weak cryptographic algorithms) is suggested.
VE-0056 102 YES NO. The mechanisms persist in an annex when they
should be entirely removed. Also, the use of MD2 and
MD4 (weak cryptographic algorithms) is suggested.
VE-0057 0341 NO NO. The paper size is stored as a code instead of using
an standard format
VE-0058 0341 NO NO. The paper size is stored as a code instead of using
an standard format
VE-0059
YES YES
VE-0060 0018 NO NO. The changes made at the BRM keep the old style
date format as the default. 1900 should not be handled as
a leap year.
VE-0061
YES YES
VE-0062
YES YES
VE-0063
YES YES
VE-0064
YES YES

(34)


VE-0065
YES YES
VE-0066
YES YES
VE-0067
YES YES
VE-0068
NO NO. These foreign XML entities are kept, despite the
compatibility issues.
VE-0069
YES YES
VE-0070
YES YES. Comment: The technical issues specified by the
National Body do not represent all the interoperativity
problems between operating systems of this proposal. A
big vendor dependency issue persists and the lack of
practical implementations for multiple environments.
VE-0071
YES YES. Comment: The technical issues specified by the
National Body do not represent all the interoperativity
problems between operating systems of this proposal. A
big vendor dependency issue persists and the lack of
practical implementations for multiple environments.
VE-0072
YES YES. Comment: The technical issues specified by the
National Body do not represent all the interoperativity
problems between operating systems of this proposal. A
big vendor dependency issue persists and the lack of
practical implementations for multiple environments.
VE-0073 0092 YES NO. New XML types are defined as to eliminate VML,
however, there's no text that explains the new XML
types or their meaning. VML is moved to an annex when
it should be entirely removed.

(35)


  


The ISO Document: India's and Venezuela's Appeals, as text - Updated with comments chart | 68 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Africa
Authored by: Steve Martin on Monday, July 14 2008 @ 01:38 PM EDT

[PJ:] If someone has time to help do a text version of South Africa's appeal, I'd appreciate it.

PJ, You should already have the South African appeal in your inbox, I did it before tackling the Brazil one.

If you don't see it, let me know, I have it on my computer at home.

---
"When I say something, I put my name next to it." -- Isaac Jaffe, "Sports Night"

[ Reply to This | # ]

Hat-trick thread ;-) n/t
Authored by: Alan(UK) on Monday, July 14 2008 @ 01:39 PM EDT
.

---
Microsoft is nailing up its own coffin from the inside.

[ Reply to This | # ]

Corrections
Authored by: bbaston on Monday, July 14 2008 @ 01:47 PM EDT
So PJ can find them.

---
IMBW, IANAL2, IMHO, IAVO
imaybewrong, iamnotalawyertoo, inmyhumbleopinion, iamveryold

[ Reply to This | # ]

Off Topic
Authored by: bbaston on Monday, July 14 2008 @ 01:49 PM EDT
Keep it off topic please, and include links.

---
IMBW, IANAL2, IMHO, IAVO
imaybewrong, iamnotalawyertoo, inmyhumbleopinion, iamveryold

[ Reply to This | # ]

News Picks
Authored by: bbaston on Monday, July 14 2008 @ 01:50 PM EDT
Please give the article's title as seen in the right-hand column.

---
IMBW, IANAL2, IMHO, IAVO
imaybewrong, iamnotalawyertoo, inmyhumbleopinion, iamveryold

[ Reply to This | # ]

The only purpose to requiring an immediate answer without time to examine...
Authored by: Anonymous on Monday, July 14 2008 @ 02:32 PM EDT

Is because the individual knows you're more likely to not accept if you're aware of what's actually occurring. After all, if you're more likely to accept once you have a full understanding, it's a marketing fau pas to refuse to let you examine the situation.

I do the same with regards reading the materials and refusing outright in the event they require an immediate answer.

RAS

[ Reply to This | # ]

Haiku here
Authored by: DannyB on Monday, July 14 2008 @ 03:00 PM EDT
Insecurity
and Vulnerability
built in to Vista!


---
The price of freedom is eternal litigation.

[ Reply to This | # ]

The question that really needs to be answered
Authored by: kawabago on Monday, July 14 2008 @ 03:23 PM EDT
How did the executives of ISO and IEC benefit from acceptance of ooxml? Clearly
the standard was approved by a procedure designed to produce that result no
matter what happened. I don't believe the top brass at ISO or IEC would so
obviously and blatantly corrupt the system as they have done without some
personal vested interest in the outcome they forced on the world. ISO and IEC
have been corrupted and they no longer have the moral or ethical authority to do
their jobs. We now need a new system to produce standards because ISO and IEC
can no longer be trusted.

[ Reply to This | # ]

Inversion - It Would Never Work
Authored by: sproggit on Monday, July 14 2008 @ 06:29 PM EDT
Sorry in advance, this is a bit of a nonsense comment. Or maybe not.

One of the ways that we could consider DIS29500 is to imagine what would happen
if there were a standard that were the exact inverse of it. Obviously we'd have
to compare that with what we believe to be a truly open standard.

So let's try.

What would the inverse of TCP/IP look like? That's an open standard, right?
Let's think about that for a moment... A stateful network protocol in which none
of the states, standards, addressing schemes, frame or packet details or other
components were published, and in which anyone who implemented it would be free
to make up all of those parts entirely for themselves... OK, hands up all those
that think that they stand a chance of building "Internet II" using
invTCP/IP? No Steve, put your hand down...

What would the inverse of DIS29500 look like? Well, it would look like an
ordinary office standard, except that there would be some chunks in it that were
secret sauce. This secret sauce would be available to IBM, Sun, the KOffice and
OpenOffice Developer Communities, plus pretty well anyone else, except employees
of Microsoft, their resellers, agents, potential employees and the like. Anyone
accessing the standard would have to agree to never reveal the details to
Microsoft. So there.


Now, belatedly, to the point.

Can you or anyone else imagine that Microsoft, with all their beellions of
dollars, would sit quietly by an allow a non-Microsoft standard to be developed?
Exactly. They would are the Redmond Campus a Nation State, demand membership of
the UN [and the Security Council, of course] and veto everything in sight until
they got the non-MS standard ratified. But the point is, *only* Microsoft would
have been harmed by it. Not one other industry player - all of whom would have
had access to the standard for free - would have been remotely bothered.

So this "what's good for the goose is good for the gander" test sort
of works, doesn't it? If something is truly open and you invert it, it becomes
truly closed to the point where it blatantly wouldn't work for anyone. If,
however, it's been twisted, distorted and manipulated into being, the
manipulations would invert to harm only the original manipulator.

It doesn't take much to realise just how absurd this nonsense is, does it? So
why are all the "officials" at ISO still blindly pretending that
nothing is wrong? Before long the answer to that question will boil down to one
of two things: ignorance or corruption. If it's the former, then the present ISO
organisation should be purged and rebuilt. If it's the latter, then we need an
entirely different kind of purge...

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )