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
About Massachusetts... Updated 2 Xs
Thursday, July 12 2007 @ 05:01 PM EDT

You know how I always tell you when I make a mistake? Well, it looks like I made one when I told you that I didn't think Massachusetts would care what you said in any emails about Microsoft's OfficeOpen XML specification (now Ecma 376) being proposed as an addition to their list of usable "open standards". I'm hearing that they are reading the emails and will take them seriously.

It's a proposal, and it's not yet carved in stone. Time will tell if they mean it, but with that reassurance, I have to put my cynicism on hold, at least for now, and say that if this is an issue you care about, you need to let them know how you feel in polite and informative emails before July 20th, 2007. It never hurts to try, particularly since I've no doubt Microsoft is lobbying wherever it can. When I thought it was useless, I didn't want to pretend otherwise or have you engage in make work. But if it has a chance, it's very different.

Here's the address to write to: standards at state.ma.us. (Only use the @ symbol instead of the at.)

I suspect the most important thing right now is numbers, so even a short email is helpful. They can't know how you feel unless you tell them, and they can't understand the tech unless it's presented with proofs of statements made. And remember, it's a new crew, so some of the things we explained the first time may not have been transferred to the new brains at the helm. So please let me provide you with some resources, so that if you wish some materials at hand to compose a more thoughtful and more technical email, it will save you some time.

You can find some suggestions of topics that might be addressed in the original article. More resources here, particularly this one, Dual Standards: More Choice or Less?" and here's an article asking how open is OpenXML. You may wish to write about the formula definitions issue or explain the spreadsheet issue. Here's a letter someone else sent, Andy Updegrove, for some ideas. But I know you have your own. Oddly, they so far are not posting the emails received, but hopefully they will. If not, just cc me and I'll post them all here, if you want me to. Or just leave a comment with the gist of your message.

Also, since the issue before was access by the disabled, I believe it would be useful to explain how ODF has addressed those issues, with some comparisons between OpenXML and ODF. Peter Korn has some interesting material on that very point here and a followup here. There are more resources on accessibility on Groklaw's ODF page.

It might be useful as well as to make clear the differences between Vista and XP and what that means for applications that are currently available for XP that help the disabled. A lot of people who are not disabled are having trouble with the new GUI, after all. Others find that the two are not compatible with each other in all respects, or so I'm reading. I don't use Vista, so I can't speak with authority, but I'm hearing that you can't read your old Word documents in Office 2007 unless you install some kind of a patch. That hardly seems like an advance in interoperability.

One of the strongest arguments against having two standards was raised by Dr. G. Nagarjuna, Chairman FSF India, submitted to the Working Committee, Board of Indian Standards on Wordprocessing:

In Ecma's response document the truth of the matter comes out very vividly:
OpenXML is designed to represent the existing corpus of documents faithfully, even if that means preserving idiosyncrasies that one might not choose given the luxury of starting from a clean slate. In the ODF design, compatibility with and preservation of existing Office documents were not goals. Each set of goals is valuable; sacrificing either at the expense of the other may not be in the best interest of users. (p.6 Ecma Response)

This is the fact of the matter. This clearly shows that one of them is trying to preserve the existing data created by a single vendor, while the other is to provide a generic encoding standard for office documents. It is true therefore that their purposes are different. Since there is a difference in purpose despite the overlapping with ODF, Ecma argues, OOXML can also exist with ODF.

But the issue is: providing a way of preserving a vendor's old documents is the service that a vendor is expected to do. This must happen. This can happen by converting the documents into ODF. Ecma did not prove that this is impossible.

We therefore think, that Ecma has the burden to prove that proprietary documents made by them cannot be converted into ODF. It is very likely that there can be a few elements that cannot be translated, since ODF was not made to serve a particular vendor's requirements. Once such elements are identified, Ecma can propose a model of extending ODF so that the possible problems are sorted out. This is the desirable way.

That should get you started. But I know you have your own thoughts. You certainly have the technical knowledge to explain technical matters well, should you wish to.

Finally, here are the earlier articles (in reverse chronological order, most recent first), when Groklaw was specifically asked for input:

Don't forget, also, that there is much, much more on Groklaw's permanent ODF-MS XML page. I think you can find everything you might need to write a useful email on this topic. The overarching question is this: does Ecma 376 qualify as an open standard?

Update: TechWorld is reporting that prior to this article appearing, MA had received only 50 letters, fewer than when ODF was considered. Of course, I know there are more now, because I've received some and you've posted others here. Note that the article says they have no plans to post the letters until after they make a decision at the end of the month, but that indicates that they will publish them:

Bethann Pepoli, acting CIO of the ITD, said the commonwealth will not publish any correspondence it receives during the public comment period, which expires July 20, until after a final decision on adoption is made at the end of this month.

"We have received about 50 responses so far, but we have another week left," she said during a July 12 interview. Unlike Updegrove, none of those respondents have made their comments public.

Pepoli said the response rate is not heavier than in 2005, when the state adopted ODF as an open format and received nearly 160 responses. The 2005 campaign sparked a firestorm of debate over open formats that eventually led to the resignation of both of the ITD CIOs who preceded Pepoli.

Note this detail as well:

Microsoft also said that more than 1,150 partners from 50 countries and six continents have registered support for Ecma-376.

We knows from "Get the Facts" days how that might work, but Massachusetts might not. So if they don't hear countering information, I expect it might seem to them like ODF and OpenXML (Ecma 376) are comparable.

Update 2: Here's an article, "The converter hoax" which explains that if it were possible for converters to work, you wouldn't actually need them, and it concludes like this:

The promise of the converters is an empty one. It is a hoax.

If users of MS-OOXML make use of the Microsoft specific functions, they will find themselves locked into as much vendor and product-dependency as if no Open Standard or converter existed....

The only effective way for users of Microsoft Office to avoid that lock-in into a single-vendor dependency would be to save all their documents in the Open Document Format (ODF) by using the ODF plugin for Microsoft.

In other words: The only way to not be locked into MS-OOXML is to stay away from it. Because no matter what Microsoft and its business partners claim, the converters promote lock-in, they don't avoid it.


  


About Massachusetts... Updated 2 Xs | 341 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Off Topic
Authored by: BobinAlaska on Thursday, July 12 2007 @ 05:05 PM EDT
Please see directions on clickies at the bottom.

---
Bob Helm, Juneau, Alaska

[ Reply to This | # ]

Newspicks Comments
Authored by: BobinAlaska on Thursday, July 12 2007 @ 05:06 PM EDT
Someone suggested this and I thought it was a good idea.

---
Bob Helm, Juneau, Alaska

[ Reply to This | # ]

The Corrections Thread.
Authored by: Aladdin Sane on Thursday, July 12 2007 @ 05:06 PM EDT
Please place article corrections here.

Posting a summary in the title to your post would be most helpful.

---
"While world domination is a nice fantasy, a Free computer is essential." 
  --artp, Groklaw, 2007-06

[ Reply to This | # ]

And in case anybody missed it...
Authored by: Nick_UK on Thursday, July 12 2007 @ 05:17 PM EDT
http://www.noooxml.org/petition
Nick

[ Reply to This | # ]

About Massachusetts...
Authored by: seantellis on Thursday, July 12 2007 @ 05:55 PM EDT
As sent...

---

Dear Sir/Madam,

As a user and supporter of open standards, I am writing about your proposed dual
adoption of the ECMA 376 (OOXML) standard for digital document storage,
alongside ISO/IEC 26300 (ODF).

No doubt there have been many people emailing you on this subject; I will
therefore confine myself to the one feature of the OOXML standard that I think
is most representative of the problems as a whole.

It is this section:

"2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character
Spacing)"

"This element specifies that applications shall emulate the behavior of a
previously existing word processing application (Microsoft Word 95) when
determining the spacing between full-width East Asian characters in a document's
content."

The wording of the standard is ambiguous or incomplete in many areas, but
nowhere so blatantly as this tag. The specification contains no information
about how Word95 spacing actually works, nor is this information available
anywhere else, even, apparently, to the writers of the specification:

"[Guidance: To faithfully replicate this behavior, applications must
imitate the behavior of that application, which involves many possible behaviors
and cannot be faithfully placed into narrative for this Office Open XML
Standard. If applications wish to match this behavior, they must utilize and
duplicate the output of those applications. It is recommended that applications
not intentionally replicate this behavior as it was deprecated due to issues
with its output, and is maintained only for compatibility with existing
documents from that application. end guidance]"

The required behaviour "cannot faithfully be placed into narrative" -
this is astounding language for a ratified international standard!

The specification authors admit openly that the only way to properly implement
this behaviour is to obtain a 12-year-old program, now out of production,
reverse engineer it, and translate its idiosyncracies (and possibly defects)
into new programs, without the help of the original authors. This effectively
increases the development cost of an implementation of the specification, except
preferentially for a single vendor, Microsoft.

It also raises the problem of indemnification against any patented methods
revealed by this process. Microsoft's patent undertakings during this process
are less than clear in the first place, and since any patent-encumbered methods
that may be discovered are not mentioned in the specification, they may argue
that any patent licensing agreement relating to specification itself does not
apply. Microsoft, unfortunately, has a long history of using vague threats over
patents to stifle competition and innovation, a practice which is still ongoing.


As I have said, the autoSpaceLikeWord95 tag is just one of many high-profile,
well-documented, and egregious problems with this specification. The OOXML
specification does nothing of significance over and above ISO/IEC 26300, and is
thus, in my view, redundant as well as fatally flawed.

The issue of standards adoption in Massachusetts has become a talking point,
touchstone, and cause celebre for the free software community, both in the US
and elsewhere around the globe. Please, therefore, stand firm and reject this
unacceptable "standard".

The eyes of the world are upon you again.

Yours

Sean Ellis
Surrey, UK

---
Sean Ellis (groklaw@moteprime.remove-this.org)

[ Reply to This | # ]

No, Seriously ...
Authored by: Anonymous on Thursday, July 12 2007 @ 05:59 PM EDT
Hi

I'm a welder and easily confused.

"OOXML" and "ODF" look identical to me.

To add to the confusion, both seem to have inexplicably used the word
"Open" in their titles.

Can we please call it "MSOOXML" so I can tell the difference?

IF it becomes a standard, THEN we can abbreviate it colloquially. Until that
happens it's just another obscure proprietory format.

I'd be most obliged. :-)

DACE

WAW - Welders Against Windows

[ Reply to This | # ]

OOXML is apparently fatally flawed too
Authored by: Anonymous on Thursday, July 12 2007 @ 06:34 PM EDT
Apparently OOXML has some serious flaws in its spreadsheet implementation according to this news story and the original blog article (more there) on the matter. I think that MA might want to know about that before they commit any of their data to the OOXML format.

[ Reply to This | # ]

MA seems to request comments
Authored by: Aladdin Sane on Thursday, July 12 2007 @ 09:16 PM EDT
MA seems to request comments a lot.

In fact, they seem to request comments more than ever making a decision.

They must like comments.

In fact, they seem to have requested comments for nearly 2 years now.

---
"While world domination is a nice fantasy, a Free computer is essential." 
  --artp, Groklaw, 2007-06

[ Reply to This | # ]

with the ODF plugin for mSoffice available ..
Authored by: Anonymous on Thursday, July 12 2007 @ 09:20 PM EDT
During the intial discussions the committee was keen on an ODF plugin for
MSOffice. The Sun ODF plugin for MSOffice (2003, XP and 2000) works very well
converting the old 0ffice docs into ODF. The plugin is far better then the MS
sponsored project.
This now completely negates the need for another (read OOXML) format. This
needs to be highlighted.

[ Reply to This | # ]

Gorklaw at its best
Authored by: Anonymous on Thursday, July 12 2007 @ 09:36 PM EDT
This article is Groklaw at its best.
Here's the problem (Massachusetts is being led up the garden path by the Other
Side), here's what you can do (point to the truth), and, oh yeah, here are some
resources (good factual arguments).
This is people power and community support at its best. (applause)
---
It's also happens to be a political statement. I am not saying this to throw
fuel on the fire, merely pointing out that politics is so much more that party
politics, as witnessed by this article.

[ Reply to This | # ]

use the plug-in
Authored by: Anonymous on Thursday, July 12 2007 @ 10:13 PM EDT
Microsoft went to all the trouble of developing a pluging so that they could be
compatible with open source projects. It would be rude of use to turn our back
on this effort. If the MSooxml is chosen as a standard then this will all go to
waste, Citizens should be opposed to goverment waste so in order not to waste
the effort odf must be chosen.

[ Reply to This | # ]

British Standards Institute (BSI)
Authored by: Anonymous on Friday, July 13 2007 @ 12:51 AM EDT
The British Standards Institute has created a read-only Wiki for all to see their process of a detailed examination of MS-OOXML, with some very interesting comments on the flaws they have found:- Here

[ Reply to This | # ]

OOXML and Office2007
Authored by: Anonymous on Friday, July 13 2007 @ 03:21 AM EDT
The OOXML spec currently under the ISO process has a lot of bugs. Whether it is
intentional or oversight or typos they Bugs are the Specs. I am quite sure the
Office2007, which is the only OOXML implementation, does not have these bugs.
So can we claim that Office2007 does not conform to the ECMA OOXML specs and
hence should not be purchased by MA or other states.

[ Reply to This | # ]

6 question Massachusetts officials should ask themselves before accepting MSOOXML as standard
Authored by: kosmonaut on Friday, July 13 2007 @ 06:08 AM EDT
You can forward the same 6 questions proposed by the FSFEurope to national standard bodies, just replace "national standar bodies" by "public institiutions":

The following six questions relate to the application of the ECMA/MS-OOXML format to be accepted as an IEC/ISO standard. Unless a national standardisation body has conclusive answers to all of them, it should vote no in IEC/ISO and request that Microsoft incorporate its work on MS-OOXML into ISO/IEC 26300:2006 (Open Document Format).

This is a summary document. More detailed information is available online.

* http://www.grokdoc.net/index.php/EOOXML_objections

* http://www.xmlopen.org/ooxml-wiki/index.php/DIS_29500_Comments

* http://www.noooxml.org/arguments



1. Application independence?

No standard should ever depend on a certain operating system, environment or application. Application and implementation independence is one of the most important properties of all standards.

Is the MS-OOXML specification free from any references to particular products of any vendor and their specific behaviour?



2. Supporting pre-existing Open Standards?

Whenever applicable and possible, standards should build upon previous standardisation efforts and not depend on proprietary, vendor-specific technologies.

MS-OOXML neglects various standards, such as MathML and SVG, which are recommendations by the W3C, and uses its own vendor-specific formats instead. This puts a substantial burden on all vendors to follow Microsoft in its proprietary infrastructure built over the past 20 years in order to fully implement MS-OOXML. It seems questionable how any third party could ever implement them equally well.

What is the benefit of accepting usage of such vendor-specific formats at the expense of standardisation in these areas? Where will other vendors get competitive, compatible and complete implementations for all platforms to avoid prohibitively large investments?



3. Backward compatibility for all vendors?

One of the alledged main advantages of MS-OOXML is its ability to allow for backward compatibility, as also referenced in the ECMA International press release.

For any standard it is essential that it is implementable by any third party without necessity of cooperation by another company, additional restricted information or legal agreements or indemnifications. It is also essential to not require the cooperation of any competitor to achieve full and comparable interoperability.

On the grounds of the existing MS-OOXML specification, can any third party regardless of business model, without access to additional information and without the cooperation of Microsoft implement full backward compatibility and conversion of such legacy documents into MS-OOXML comparable to what Microsoft can offer?



4. Proprietary extensions?

Proprietary, application-specific extensions are a known technique employed in particular by Microsoft to abuse and leverage its desktop monopoly into neighboring markets. It is a technique at the heart of the abusive behaviour that was at the core of the decision against Microsoft by the European Commission in 2004 and Microsoft is until today continuing its refusal to release the necessary interoperability information.

For this reason, it is common understanding that Open Standards should not allow such proprietary extensions, and that such market-distorting techniques should not be possible on the grounds of an Open Standard.

Does MS-OOXML allow proprietary extensions? Is Microsoft's implementation of MS-OOXML faithful, i.e. without undocumented extensions? Are there safeguards against such abusive behaviour?

5. Dual standards?



The goal of all standardisation is always to come to one single standard, as multiple standards always provide an impediment to competition. Seeming competition on the standard is truly a strategic measure to gain control over certain segments of a market, as various examples in the past have demonstrated.

There is an existing Open Standard for office documents, namely the Open Document Format (ODF) (ISO/IEC 26300:2006). Both MS-OOXML and ODF are built upon XML technology, so employ the same base technology and thus ultimately have the same theoretical capabilities. Microsoft itself is a member of OASIS, the organisation in which the ODF standard was developed and is being maintained. It was aware of the process and invited to participate.

Why did and does Microsoft refuse to participate in the existing standardisation effort? Why does it not submit its technological proposals to OASIS for inclusion into ODF?



6. Legally safe?

Granting all competitors freedom from legal prosecution for implementation of a standard is essential. Such a grant needs to be clear, reliable and wide enough to cover all activities necessary to achieve full interoperability and allow a level playing field for true competition on the merits.

MS-OOXML is accompanied by an unusually complex and narrow "covenant not to sue" instead of the typical patent grant. Because of its complexity, it does not seem clear how much protection from prosecution for compatibility it will truly provide.

Cursory legal study implies that the covenant does not cover all optional features and proprietary formats mandatory for complete implementation of MS-OOXML. So freedom of implementation by all competitors is not guaranteed for the entire width of the proposed MS-OOXML format, and questionable even for the core components.

Does your national standardisation body have its own, independent legal analysis about the exact nature of the grant to certify whether it truly covers the full spectrum of all possible MS-OOXML implementations?

All these questions should have answers that should be provided by the national standardisation bodies through independent counsel and experts, and in particular not by Microsoft or its business partners, which have a direct conflict of interest on this issue.

If there is no good answer to any one of them, a national body should vote no in ISO/IEC.

[ Reply to This | # ]

About Massachusetts...
Authored by: Anonymous on Friday, July 13 2007 @ 06:48 AM EDT
Here's what I sent:
To the State of Massachusetts.

RE: Microsoft OfficeOpen XML specification (now Ecma 376) beware of Greeks
bearing gifts

We have over 100,000 documents going back 25 years most of which are Microsoft
and there's nothing that can read them, not even Microsoft's products.
Archivist, historians, and others are going to hit huge black hole in human
knowledge when they get to the 1980's and find that there are no readable public
records to examine and develop historical perspective on public events.

As far as I can figure out Microsoft's OfficeOpen XML (now Ecma 376) his a huge
guise to hide documents in proprietary un understandable XML formats that no one
else 20 years from now will be able to read, much less a 100 years from now,
which probably long after Microsoft is gone.

You have a duty and responsibility to find ways to archive all public digital
records in a way they can be read way into the future.

From where I am, pdf's seem to be pretty good. They can be generated, stored,
mailed, and read on all computer platforms; i.e. Mac, Windows, Linux, Unix, etc.
There is an OpenODF XML standard which works for a lot of things.

I'd like my great grandchildren to be able to read public electronic records the
way many people doing genealogy are doing with microfilm and paper documents
today.

Kenneth King

[ Reply to This | # ]

Another Reply To The ITD
Authored by: Anonymous on Friday, July 13 2007 @ 01:23 PM EDT
I sent the following e-mail to the ITD:

Dear ITD,
I am writing to you, as an IT professional who lives and works in Massachusetts,
to oppose the inclusion of ECMA 376, the "Microsoft OfficeOpen XML"
specification, in your list of usable standards for public documents.

In order for a file format to be suitable for use with public documents, it must
be open, interoperable, and freely implementable by anyone. Alas, Microsoft's
OOXML fails on all three counts.

1. OOXML Is Not Open

Despite having an ECMA standard designation (a designation obtained through a
VERY questionable process, BTW), OOXML is NOT open. This 6000-page standard
embodies numerous REQUIRED features that refer opaquely to other, CLOSED
Microsoft formats, such as "do this the way Office 97 did it;" without
open access to these other formats, the "standard" cannot be
implemented. In addition, although it uses XML as a container, OOXML includes
proprietary binary "tags," data containers that can be essential to
rendering a document, but that -- again -- are NOT defined in open standards.
Simply put, this "standard" is incomplete and insufficient to
implement a "compliant" implementation.

Most critically, as a practical matter, the OOXML "standard"
essentially blesses WHATEVER implementation Microsoft chooses to implement in
its Office product, regardless of whether it actually matches the published
standard or not. ECMA notwithstanding, Microsoft OWNS the OOXML format and will
do whatever it pleases with it, and those who wish to work with OOXML documents
will be forced to march to MS' tune, as the company's history proves beyond
doubt.

2. OOXML Is Not Interoperable

The above-mentioned undocumented elements adopted from proprietary MS formats,
plus the use of mysterious binary containers, make it impossible to fully
implement the OOXML format without serious reverse-engineering of other --
closed -- Microsoft formats. Interoperability? "He's Dead, Jim." Add
in the fact that some of the mysterious binary objects will be Windows-specific,
and interoperability across operating systems is REALLY dead.

3. OOXML Cannot Be Freely Implemented

Microsoft provides a limited pledge not to assert patents embodied in OOXML
against persons implementing readers for OOXML documents. However, this pledge
is hedged about with more mines than the US base at Guantanamo Bay. No license
is given to implement the parts of OOXML that depend on those OTHER, closed
Microsoft standards, nor is the pledge actually valid for Microsoft's de facto
OOXML implementation; in the very likely event that the de facto Office
implementation deviates from the published standard, third parties cannot
implement it. One is left with a devil's choice: Incompatibility with what most
users will perceive as the "gold standard" implementation, or stepping
outside the narrow Microsoft nonaggression pledge. Thus, for several independent
reasons, OOXML cannot be freely implemented by third parties.

In this regard, it is also instructive to observe Microsoft's pathetically-bad
implementation of an ODF document converter for Microsoft Office. This converter
is so miserably bad (especially in comparison with OpenOffice's Word converters)
that one is forced to conclude that either 1) Microsoft does not WANT to
interoperate with open formats, or 2) Microsoft is incapable of producing
competent software implementations. In neither case is it advisable to become
dependent on MS' implementations if one wants interoperability.

4. OOXML Disadvantages Visually-Impaired Users

Much has been made of the purported difficulty of using OpenOffice and other
Open Source office suites for visually-impaired users. Many of these criticisms
appear to be based on the idea that MS Office has better support for
screen-readers than the Open Source products. While this is a questionable
proposition at present (as assistive tools take advantage of the internal API
access provided by Open Source applications), it should be pointed out that the
only significant implementation of OOXML that exists (Office 2007), like every
new version before it, is incompatible with existing assistive software. This
situation is unlikely to change with respect to Microsoft Office; MS will keep
releasing new versions that remain the only option for OOXML documents and that
break existing assistive tools, and the toolmakers will be obliged to
reverse-engineer things from the very beginning to restore functionality.

Contrast this with the case of Open Source office suites; once a visual assist
tool is interfaced to an Open Source office suite, any update to that suite that
breaks the assistive tool is immediately accessible to the toolmaker, who then
has a MUCH better range of tools and options for restoring compatibility. In the
long term, Open Source office applications are a MUCH better option for
visually-impaired users who must rely on third-party vendors for assistive
software.


For the reasons stared above, I believe that OOXML is not suitable for
consideration as a suitable document format for public documents.

[ Reply to This | # ]

Gates usually buys them off
Authored by: Anonymous on Friday, July 13 2007 @ 02:01 PM EDT
See CCIA.

http://www.groklaw.net/article.php?story=20041109031629840&query=ccia

http://www.groklaw.net/article.php?story=20041123212731262 "Eek, Pulling
Back the MS Curtain, We See ... $9.5M to CCIA's Ed Black"

THe CCIA was/is an industry group (composed of Sun, Red Hat, Nokia, IBM, etc)
that led the antitrust complaints against MS in the EU and the US. MS bought
them off for their silence in the EU case, just like they bought Novell, Real,
and Sun off.

I do question why IBM and Sun aren't lobbying more though, although of course MS
has the most lobbyists of any tech company. Many of the articles on the
"men in black" who take ODF off the table of state legislatures state
that IBM, Sun, etc. either didn't lobby them, or didn't lobby them enough and
back their positions up with facts.

Only Microsoft did.

http://www.itbusinessedge.com/item/%3fci=27282

http://www.marketwatch.com/news/story/state-state-microsoft-responds-assault/sto
ry.aspx?guid={C0D943C4-4ADC-471C-8F87-9181A4EC3E7B}

[ Reply to This | # ]

Even judges can't get it right
Authored by: tinkerghost on Friday, July 13 2007 @ 05:23 PM EDT
From the Register a judge linked a video in a ruling - that got ganked for copyright infringement.

This stuff is either terrifying or amusing - some days I can't decide which - but never boring.

---
You patented WHAT?!?!?!

[ Reply to This | # ]

About Massachusetts... Updated
Authored by: Anonymous on Friday, July 13 2007 @ 07:24 PM EDT
There's a BIG difference between partners rubber-stamping YOUR spec and partners
actually having input into the spec's design as in ODF. A standard can not be
decided by one company.

[ Reply to This | # ]

I think we should extend the 'standard' concept
Authored by: Anonymous on Friday, July 13 2007 @ 08:32 PM EDT
We should let auto manufacturers decide their own gas filler standars regarding
the size and shape of the filler tube and nozzle.
This way, Ford, Renault, and VW can each make 'filler dimension covenants' with
the oil companies, so that say, Shell and VW can ensure that their respective
customers go nowhere else for their gas and personal transportation needs.
I wonder if this brilliant concept could be applied to other industries...

[ Reply to This | # ]

Ongoing discussion on GNOME foundation list
Authored by: Anonymous on Saturday, July 14 2007 @ 08:13 AM EDT
http://mail.gnome.org/archives/foundation-list/2007-July/msg00000.html

Michael Meeks response to RMS is... well... read for yourself.

[ Reply to This | # ]

My Dear Commonwealth of Massachusetts:
Authored by: webster on Saturday, July 14 2007 @ 09:48 AM EDT
..

This letter comes in reference to your consideration of document standards for
your state word processing and other types of documents. I hear that you are
considering something called Microsoft Office Open XML (MSOOX). Let me warn you
that this is really a very big wolf in sheep’s clothing. This is a Trojan horse
that you don’t want relieving itself within your walls.

Let me tell you about these Microsoft people. Theare very powerful and used to
having their own way. They have a Monopoly on the desktop computer operating
system and they use it to force retailers to promote only their products. They
suffer Apple just to let the government rationalize leaving them alone. They
are more powerful than most countries and every state like yours. They can buy
influence like nothing you have ever seen except the KGB. Journalist sing for
their supper and politicians fawn over them lest they support their opponents.
They can pass laws and shut down companies in the blink of an eye. Even the US
Courts and the European community cannot budge them.

Schools have brought me to Massachusetts for my family and me. It is an
enlightened state with distinction as a leader. It is amazing that Microsoft,
the 8,000-pound Gorilla, let you declare ODF as a standard. Well they are
coming back at you with this MSOOX. Let me assure you, it MSOOX.

First of all, MS Office Open XML is neither open nor a standard. Microsoft
doesn’t want anything open and they do not want a standard other than their own.
If they wanted a standard, they could open up one of their own. This MSOOX is
not open because only MS can understand it fully and implement it fully. It
would be a waste of time for anyone else to bother. They will not give up their
Monopoly on the desktop. If there were a true standard that was open to others,
then one could produce that format without MS software. People could stop
upgrading their hardware and software so often. They could choose.

Calling MSOOX an open standard is a lie. MS innovates only to obscure and lock
everyone in to their products. MS is the problem. They are why you are so
desperately looking for a way to produce state documents so that you can archive
them and still read them. If you adopt the MS non-standard, you are going to
have the same problem when MS want another infusion of cash other than their
annual license with a roll-out of the next Vista Churnware. All of this
increases your hardware expense too. A true open standard will be hardware and
software blind, implementible by all. Two standards are worse than one. You
will have to maintain the capability to do both.

As a Monopoly Microsoft can generate billions with a poor product. If you
select them, you will give them billions more extra. So you have to decide.
Will you remain the Commonwealth of Massachusetts or the Kommonwealth of
Mikrosoft?

Your Humble Servant,


---
webster


© 2007 Monopoly Corporation. ALL rights reserved. Yours included.

[ Reply to This | # ]

About Massachusetts... Updated
Authored by: linuxninja39 on Saturday, July 14 2007 @ 01:34 PM EDT
This detail is an interesting one. "Microsoft also said that more than
1,150 partners from 50 countries and six continents have registered support for
Ecma-376."

My brother is a copywriter which basically means he writes things that others
put their name on. It is interesting to note that he has had several offers to
write support letters for MS "partners." These letters basically get
tweaked and mass produced then sent to MA. MS "grass roots" support
for their "standard" is nothing more than a bunch of well paid
puppets.

[ Reply to This | # ]

Scribes and ODF/OOXML
Authored by: NoCalDrummer on Sunday, July 15 2007 @ 03:14 PM EDT
It finally stuck me this morning what the ODF/OOXML difference is. So many
analogies I'd seen fall flat or just don't make sense, especially in the context
of document preservation. Don't get me wrong, I've slugged through a few pages
of the 6K of eczema... I mean ECMA376, and a few of the Open Document Format for
Office Applications.
While I have been on committees for international standards, including VESA
and the AC97 [1.0] committee, I have no personal experience on either ECMA's or
ISO's organizations. Both VESA and the AC97 committees were industry-based and
industry-lead, but the standards established were available to all. Neither one
established standards which grossly favored one vendor's product over another,
nor did these standards have language which described action in terms of a
proprietary product which other companies would have no legal ability to
replicate.
OOXML, on the other hand does. To describe a particular action in terms of a
proprietary product, for which there is no publicly available interpretation,
except for that product (which may or may not be available) not only makes the
"standard" unreproducible, but it also makes it impossible to verify
that the organization submitting the "standard" is following it
themselves. It nullifies that section of the "standard".

The analogy of OOXML vs. ODF in the sense of publicly available documents is
an ancient one. I thought of this morning would come from centuries ago, when
civilization had scribes - although court reporters would be the closest modern
equivalent. One could dictate to the scribe a document, and he, in turn would
write down your words. You could take his written words with you. If you were
not familiar with how to read his writing, you could have him read it back or
find another scribe who could read the first scribe's document back to you.
However, you were at the mercy of the scribe, since you could not interpret his
scribblings back to words. In a perfect world, your scribe would take down your
dictation accurately, and repeat back the written word accurately. He would not
be open to bribery, nor to locking away your words - only allowing you to hear
them for an exorbitant fee. And what if the scribe were to die before you
needed to hear your words again? Your words might be lost forever, because no
one might know how to interpret his writings.

But if you knew how to read the documents yourself, because there were
instructions on how to interpret his symbols freely available, you would not be
bound to that scribe. You could verify that what he wrote was exactly what
you'd said. You could go to others and have them read the document with the same
accuracy as your original statements. And if your original scribe should cease
to be, your document would still be useful.

MS Office, using OOXML is like the scribe (or court reporter) it writes down
the words (or formulas or other data) that you prescribe. It writes them down
in a format only it (and its Master, Microsoft) knows, and only it can read it
back. You depend upon it doing so with accuracy. Just like you did for Office
2003, Office 2000, Office 97.... But those scribes are now dead. Can you be
sure of whether Office 2007 will faithfully reproduce your original information?
When this one dies, are you sure the next version (the next "scribe")
will be able to read it correctly? Or will it charge you for each time you wish
to read your own words?

Products using ODF, unlike OOXML, write down the words (or other data) in a
format that had been documented. And that documentation is in a format that is
fully documented, etc. You can either manually read it yourself, or choose any
one of dozens of "scribes" to read it back to you. There are no
hidden "gotchas". Dates follow formats put into place centuries ago.
The very characters stored (especially for non-English) follow established
standards.

Rather than being the pawn of a rich land-owner, those who use ODF have their
Magna Carta Libertatum. They have the same rights as anyone else. And that's
what "Freedom" is.

[ Reply to This | # ]

Massachusetts M$OOXML battle in line with classical MSFT strategy
Authored by: kosmonaut on Monday, July 16 2007 @ 07:24 AM EDT
As official ly stated by MSFT since Halloween's documents:
introducing nonstandard extensions (or entire alternative protocols [...or document formats]) which are then saturation-marketed as standards, even though they're closed, undocumented or just specified enough to create an illusion of openness. The objective is to make the new protocols a checklist item for gullible corporate buyers, while simultaneously making the writing of third-party symbiotes for Microsoft programs next to impossible. (And anyone who succeeds gets bought out.) This game is called embrace and extend. We've seen Microsoft play this game before, and they're very good at it. When it works, Microsoft wins a monopoly lock. Customers lose.

To put it even more bluntly: "commodity" services and protocols [...and document formats, such as ODF, which didn't yet exist when the Hallowwn documents were written] are good things for customers; they promote competition and choice. Therefore, for Microsoft to win, the customer must lose.

Beating Linux

In addition to the attacking the general weaknesses of OSS projects (e.g. Integrative / Architectural costs), some specific attacks on Linux are:

o Beat UNIX

All the standard product issues for NT vs. Sun apply to Linux.

o Fold extended functionality into commodity protocols / services and create new protocols

Linux's homebase is currently commodity network and server infrastructure. By folding extended functionality (e.g. Storage+ in file systems, DAV/POD for networking) into today's commodity services, we raise the bar & change the rules of the game.

{ Here, as in the earlier comment on how Linux can win, we start to see the actual outlines of a Microsoft strategy emerge from the fog of corporatese. And it ain't pretty; in fact, it's ugly enough to make it appropriate that it's pushing midnight on Halloween as I write.

What the author is driving at is nothing less than trying to subvert the entire "commodity network and server" infrastructure (featuring TCP/IP, SMTP, HTTP, POP3, IMAP, NFS, and other open standards) into using protocols which, though they might have the same names, have actually been subverted into customer- and market-control devices for Microsoft (this is what the author really means when he exhorts Microserfs to raise the bar & change the rules of the game).

The `folding extended functionality' here is a euphemism for introducing nonstandard extensions (or entire alternative protocols) which are then saturation-marketed as standards, even though they're closed, undocumented or just specified enough to create an illusion of openness. The objective is to make the new protocols a checklist item for gullible corporate buyers, while simultaneously making the writing of third-party symbiotes for Microsoft programs next to impossible. (And anyone who succeeds gets bought out.)

This game is called embrace and extend. We've seen Microsoft play this game before, and they're very good at it. When it works, Microsoft wins a monopoly lock. Customers lose.

(This standards-pollution strategy is perfectly in line with Microsoft's efforts to corrupt Java and break the Java brand.)

Open-source advocates can counter by pointing out exactly how and why customers lose (reduced competition, higher costs, lower reliability, lost opportunities). Open-source advocates can also make this case by showing the contrapositive -- that is, how open source and open standards increase vendor competition, decrease costs, improve reliability, and create opportunities.

[ Reply to This | # ]

About Massachusetts... Updated 2 Xs
Authored by: mole on Thursday, July 19 2007 @ 04:49 PM EDT
Dear Sir or Madam,

Attached are some comments on the draft Enterprise Technical Reference
Model (ETRM) v4.0 posted at
http://www.mass.gov/?pageID=itdterminal&L=3&L0=Home&L1=Policies%2c+S
tandards+%26+Guidance&L2=Drafts+for+Review&sid=Aitd&b=terminalconten
t&f=policies_standards_etrmv4_etrmv4dot0intro&csid=Aitd

As a Massachusetts resident I would like to comment on two
general areas in the draft: The decision work flow, and the inclusion of
ECMA 376"OOXML", along with a few subsidary notes.

In previous moves towards information technology standardization in
Massachusetts, I was very glad to see Massachusetts taking an
appropriate place in global IT leadership by adopting the Open Document
format, now ISO/IEC 26300, as a document standard and am very
disheartened by the retrograde step of including Microsoft's ECMA 376 in
this draft.

1) Concerning the decision workflow:
# Introduces the decision workflow used in recommending enterprise
standards; The discussion of decisions in the text of ETRM v40. has
some differences from the diagram of the decision work flow. In
particular, the diagram enforces a much more rigid decision flow than
the text implies. Some specific comments on the criteria in the text:

* There is existing or growing support around the use of the standard.
Support is undefined. If this means multiple implementations from
multiple vendors, including open source software then I would concur.

I suggest: "Multiple implementations of the standard, including open
source software implementation exist and are in use."

* The standard interoperates with other relevant Enterprise Standards.
Nice sounding but fuzzy word: interoperates. In the context of web
services, it is fine - it doesn't matter what software is running on the
ends of a web services connection as long as both support the same
interoperable standards. In the context of software generally in the
enterprise, in particular in document formats, this is much more
problematic, here interoperates implies support in the document format
for multiple existing open standards, and for the ability of anyone to
write software to extract information from a document in a standard
format and write information into that format.

* The standard can be adopted without causing negative business impact.
Negative business impact on whom? The commonwealth? Its citizens
and taxpayers? Or the Microsoft corporation?

Timescale is important. A short term cost for conversion to an
enterprise software infrastructure that supports open standards without
ties to any single vendor may have short term costs that will be rapidly
offset by the long term savings produced by migration to an environment
of open competition and open source software.

I suggest two specific changes:
"The standard can be adopted without causing long term negative business
impact to the commonwealth and its taxpayers."

In allowing de-facto industry standards that are not capable of being
implemented by any interested party, the decision workflow looses sight
of two critical needs for the IT infrastructure in MA - long term (100
year timescale) accessibility of information, and principles of Open
Government with the ability of any citizen of MA to access and interact
with the electronic resources of their government.

Limiting negative buisness impact to very short time scales and the
commonweath, and allowing the use of de-facto industry standards that
are implementable by only a single vendor directly violates several of
the vision statements that guide ETRM v4.0:# Ease of integration of
applications, application services and data to enable inter-agency
collaboration and sharing. Can't do without fully documented open
standards. # Better responsiveness to changing business needs and
rapidly evolving information technologies. The rapidly evolving
technologies are open source. # Faster deployment of new applications.
Can't do if you are tied to vendor produced and owned code.
# Efficient sharing and re-use of current information technology assets.
Can't do if proprietary software drives
# Reduce the level of resources and costs required to develop, support
and maintain government applications. Total cost of ownership of open
source is clearly much lower than proprietary software.

2) # Updates the Information Domain to include additional standards;
I am very concerned by the inclusion in the draft of ECMA 376 "OOXML"
"Microsoft Office Open XML" as an additional standard. This is a
very
bad idea. I strongly oppose it and I strongly recommend removal of ECMA
376 from the ETRM.

I am concerned because: ECMA 376 "OOXML" is not open. ECMA 376
"OOXML"
Is not interoperable. ECMA 376 "OOXML" Cannot be freely implemented.

ECMA 376 "OOXML" Promotes vendor lock-in. I refer you to the
detailed
disscussion of these issues on:
http://www.grokdoc.net/index.php/EOOXML_Objections_Clearinghouse#Ecma_376_cannot
_be_fully_implemented_by_other_vendors
http://www.groklaw.net/article.php?story=20051129101457378#Contents
In particular: Future updates or revisions of ECMA 376 are excluded from
the OOXML covenant not to sue over patent clause, and will not be
implementable in any form by anybody other than Microsoft, any Microsoft
patented technologies refered to but not documented in ECMA 376 are not
covered by the covenant not to sue, and ECMA 376 references but does not
document proprietary Microsoft formats and behaviors in a manner that
both reqires their implementation and forbids anyone other than
Microsoft or a Microsoft licensee from implmenting those formats and
behaviors (including references to requirments for reverse engineering
Microsoft software that was released under an EULA that forbids reverse
engineering).


Examining ECMA 376 under the criteria of the draft ETRM v4.0 leaves me
baffled as to why it was included, as it fails every single decision
point in the flow chart that would lead it to "Recommend as an
Enterprise Standard", and is lead directly on the flow chart to "Do
not
recommend as an enterprise standard at this time" Reviewing the fit of
ECMA 376 to the ETRM criteria:

* The standard interoperates with other relevant Enterprise Standards.
ECMA 376 does not. It is encumbered with patent and licencing
issues. It appears to be designed to describe legacy documents rather
than interoperate. It has substantial failures in interaction with and
support for other standards. See, for some examples, the list of
failures to support ISO standards at:
http://www.grokdoc.net/index.php/EOOXML_Objections_Clearinghouse#Ecma_376_contra
dicts_numerous_international_standards
Among the failure to incorporate existing standards is ECMA 376's
vector graphics support, where ECMA 376 adopts a failed and rejected
attempt by Microsoft to develop a vector graphics standard (VML) instead
of simply incorporating the successfull and widely implemented W3C
standard SVG, see:
http://www.robweir.com/blog/2006/07/cum-mortuis-in-lingua-mortua.html
which notes "Use SVG and you get reuse on three fronts. Stick with VML
and the only thing that is reused is Microsoft's legacy code." ECMA 376
repeatedly links to proprietary elements rather than to the existing
appropriate, widely implmented, and relevant standards.

Dr G. Nagarjuna Chairman FSF India has made this point very forcefully
"The only open standard they have used ... is XML",
(http://wordprocessingml.pbwiki.com/) "OOXML [ECMA 376] does not use
many of the existing standards[.] This is the main reason why the OOXML
specification runs to over 6000 pages, and ODF which meets exactly the
same goal in about 700 pages. The only open standard they have used
(rather abused) is XML. Several published comments on OOXML already make
this point sufficiently well, therefore I do not want to repeat them
here. Not only that OOXML does not make use of ODF, it also does not
make use of MathML, SVG, Xlink, RDF etc."


* There is existing or growing support around the use of the standard.
On the contrary, there is widespread and growing critisism of ECMA
376 based upon technical details. ECMA 376 seems deeply flawed. To
quote
http://www.grokdoc.net/index.php/EOOXML_Objections_Clearinghouse#Ecma_376_contra
dicts_numerous_international_standards
"As far as we can see, all the functionality in Ecma 376 can be
represented (better) in ISO 26300, and the much greater length of Ecma
376 is due to its poor design and failure to generalize and use existing
standards."


* The standard can be adopted without causing negative business impact.
By producing vendor lock-in to the convicted monopolist Microsoft
corporation, allowing the use of ECMA 376 in ETRM will have substantial
negative business impact on the commonwealth, its taxpayers, and all
corporations other than Microsoft who wish to to buisness in or with the
commonwealth. These negative business impacts include direct costs of
licencing Microsoft software, indirect costs of forced upgrades of
hardware, and indirect costs related to managing the vastly increased
security risks produced by the use of intrinsically insecure Microsoft
software. One example of a specific issue in ECMA 376 that raises
enterprise security concerns on its own is are sections 2.15.1.28,
3.3.1.69, and 3.2.29 which define cryptographic hash functions.
Cryptography is hard to get right, easy to get wrong, and careful review
of any crypographic algorithm or protocol by the cryptographic community
is essential. The cryptographic hash algorithms described in these
sections have not had such scrutiny, and their implementation could
expose users of software which implements them to substantive security
risks. The inclusion of these non-standard hash functions in ECMA 376
was apparently pointless, as there are several national and
international standards for hash functions who's properties are well
understood by the cryptographic and security communities.

Revewing the fit of ECMA 376 to the ETRM v4.0 flow chart (which is uses
language somewhat different from the criteria in the text of the ETRM)
it would seem obvious that ECMA 376 should be rejected as an enterprise
standard for the commonwealth. At every single decision point, ECMA
376 takes a path to "Do not recommend" (even though it fails and
takes
this path at the entry point of the flow chart).

Is the standard fully documented and publically available?
Publically available: Yes and no. It is available for examination
but appears to be Patent encumbered in a manner that may prevent
implementation of software to support it and will prevent implementation
of future versions by anyone other than Microsoft.
Fully documented: No. ECMA 376 contains references to undocumented
binary blobs (e.g. section 6.2.3.17 "Embedded Object Alternate Image
Requests Types" and section 6.4.3.1). The standard reportedly contains
non-valid xml. Corporations that are attempting to develop translators
for the standard(e.g. Novell) have reportedly been required to sign
non-disclosure agreements with Microsoft in order to do so.
ECMA 376: No. Direct path to "Do not recommend".

Is the standard developed by a process that is open, transparent, and
collaborative? No. By all reports ECMA 376 was developed in a closed
process by the Microsoft corporation and fast tracked to approval with
very little community participation. This is evident in the lack of
conformity with other standards (e.g. the ISO date standard), and the
substantive errors in ECMA 376 (e.g. non-valid xml, mathematical errors
in spreadsheet functions). Reports concerning the effort to make ECMA
376 an ISO standard (such as recent reports of the exclusion of Sun and
IBM representatives from a meeting of the Portugese committee examining
the proposal) make it clear that the process is not collaborative.
Substantive issues exist in ECMA 376 that are indicative of its
development by a single vendor without an open development process or
regard for existing standards. To give a single example: The discussion
of date representation 3.17.4.1 regards all dates prior to 1900 as
invalid, and requires implementation of the incorrect treatement of 1900
as a leap year. It shows no regard for the existing standard for
numeric representation of dates ISO 8601 and its derivatives RFC 3339
and the W3C note on date and time formats. To quote from Objections to
JTC-1 Fast-Track Processing of the Ecma 376 Specification v. 0.1 "There
has been insufficient disclosure and too little time to do a
comprehensive review."
ECMA 376: No. Not an open standard.

Is the standard developed, approved, and maintained by a standards body.
Developed, No, ECMA 376 appears to have been wholly developed by
Microsoft.
Approved and maintained, Yes.
ECMA 376: No. Not an open standard.

Not an open standard -> Is it a de-facto industry standard?
No. Other undocumented Microsoft document formats, such as .doc or
.xls or .ppt form a very large base of legacy documents, but "OOXML"
is
new and has poor penetration. It is widely seen as yet another closed
format representative of the past of lock in of customer information
into formats supported by only a single vendor, not as a representative
of the open future of fully documented formats readily implemented by
any vendor.
ECMA 376: No. Direct path to "Do not recommend".

Does the standard interoperate with other relevant Enterprise standards.
No. There are numerous other relevant standards which it does not
support, as discussed above. More important than these is ISO/IEC
26300, with which ECMA 376 seeks no interoperability.
ECMA 376: No. Go to Are there compelling buisness reasons.

Are there compelling buisness reasons to recommend the standard despite
interoperability issues?
No. Quite the opposite, there are compelling direct and indirect cost
reasons to reject ECMA 376 as noted above.
ECMA 376: No. Direct path to "Do not recommend".

Can the standard be adopted without causing significant negative
buisness impact?
No. ECMA 376 appears to be implementable soley with software that
invovles licence payments to Microsoft, and has other compelling direct
and indirect cost issues with significant negative buisness impact to
the commonwealth, to taxpayers, and to corporations who wish to do
buisness with the commonwealth, such as having to purchase brand new
overpowered hardware to on an upgrade cycle driven by Microsoft with
operating system and software licence costs instead of being able to
operate on older hardware with open source software under much lower
total costs of ownership using any of multiple different vendor
implementations of ISO/IEC 26300.
ECMA 376: No. Direct path to "Do not recommend".

3) Some subsidiary notes:
The draft refers to Open Document "OASIS Open Document Format For Office
Applications (OpenDocument) v. 1.1", but leaves off mention of its
adoption as an ISO standard: ISO/IEC 26300.

A significant component of a service oriented architecture in government
is likely to be geospatial information, thus support for open geospatial
formats and protocols such as the OGC standards
http://www.opengeospatial.org/standards would seem appropriate in the
ETRM.

[ 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 ) 		Site layout based on Woodlands theme by Bryan Bell.
Groklaw logo by John Crowley.
News Picks logo by Ted Thompson.
Powered By GeekLog
Created this page in 0.06 seconds