OpenDocumentFormat SDK

David Berlind of ZDNet started a discussion (follow up) about OpenDocumentFormat (ODF) Software Development Kit (SDK). He concentrated on the value of a SDK for ODF. His analysis and the analysis IBM Bob Sutor make sense to me. Bob Sutor argues that any ODF SDK should be open-sourced. With open source, I believe he meant an SDK that can be used both in open source and proprietory software environment. This is a very important point for a lot of closed source developer. In the context of promoting the use of ODF, I believe this is a valid and very important point.
While I agree that at present there is no SDK for ODF that can simultenously satisfy the need of both open-source and close source developer, I believe some sort of SDK is available if you are on the open source path.

There are a few big open source software with ODF support, namely, OpenOffice.org, KOffice and AbiWord, to name a few. All these software developers are not your traditional “fresh-out-of-college” people who intermingle ODF calling routine with their UI routines etc. Their source code is likely to strictly separate ODF calling routines with others. Therefore the part of these software dealing with ODF should be easily extractable and used as a SDK. Therefore, arguably, a form of SDK is already available, especially if you are working on an open source project. All you need to do is to extract it and make sure the final SDK product is in compliance with the open source license you received the original source code from. As OpenOffice.org’s LGPL license for its source code looks to be a good starting point for developing a ODF SDK, I will assume any developer’s start with a LGPLed copy of ODF code.

Thus, the first and foremost implication is that extracting the SDK this way will mean at least the part dealing with ODF must be made open source. This, does not, however, mean that all your source code is open source, as a good software architect can ensure that there is sufficient separation between the ODF SDK you developed, and your own proprietory code. One need not even go out of the way to create such an architecture, because such an architecture should/would had been created to deal with the software one is developing. Having said that, I can see and understand that some developers will like to keep any work they done with ODF private. Therefore, this approach does not work well with all proprietory software vendor, something a true ODF SDK should do.

The biggest snag with creating such an SDK is any modification must be contributed back under LGPL. This means any divergence you take from the straight-and-narrow ODF must be contributed back. Again, no problem with open source software because developers do not mind other people using their ODF derivatives. But for closed source developer this is a problem, and this negated one potential advantage of ODF, at least according to them, the rights to create proprietory derivatives. Any closed source developer who goes down this route is probably one who wants “free lunch” and is not interested in open format. Condemning them outright is a bit overzealous: There are cases to be made where proprietory derivatives makes sense. Nonetheless, this means any SDK derived from existing Open Source ODF stack is not suitable to be labelled as the official “ODF SDK”

Is there any alternatives source of ODF SDK. One obvious one is the one IBM is using to support ODF on its Workspace product. IBM’s competency means it should be easy to extract a SDK from it should IBM agrees to do so. Of course, the decision is IBM and IBM’s alone. It would not be a bad starting point.

Having discussed the subject of ODF SDK, it dawned on me that one weakness of ODF’s OASIS standardization process is that no one was thinking about an “Official SDK”. I think this is mistake.

When can one argue that a document is available? (Updated)

I was reading Microsoft’s response to the European Commission’s Statement of Objections over its Antitrust case in EU. One thing caught my eye. It is actually Footnote 2 on Page 7 of the Main Text(The 78 pages one, second on the list). It has to do with when is a document actually available.

In short, Microsoft alleges that the EC is not playing fair because it issued its statements of objections on 21st Dec 2005 without first reviewing Microsoft’s update to the documentation on 15th Dec, i.e., the last date that Microsoft has to provide the documents.

As usual, the devil is in the detail. On the above mentioned footnote, Microsoft says:

“The revised documentation was made available at Microsoft’s headquarters on 15 December 2005, and Microsoft so confirmed to the Commission, but no one from the Commission, the Trustee or any prospective licensee viewed the documentation prior to the issuance of the Statement of Objections on 21 December 2005 (“SO”). Microsoft was not able to send a copy to the Commission until December 23, because several days were needed to add digital rights management features to the documentation. All this was in accord with the requirements of the Article 24(1) Decision and the 2004 Decision, as discussed in Part V. “

Hence, the question I have to ask is, is the documentation really available on 15th December? According to Microsoft’s interpretation, the documents are available on the 15th, because if EC officials/Trustees/prospective licenses simply bother to go to Microsoft HQ in REDMOND, USA!! (I assume they meant National Headquarters, not the one in Seattle, USA), (Update: Para 109 says it is Redmond USA) they will be able to view it. This arguement implies that its delivery to the Commission on 23 December is not important, is just a courtesy and out of respect for the Commission. Furthermore, Microsoft did not modfy the document after 15th December as the delay was to add Digital Restriction Management on to the documentation.

Is this an acceptable definition of making documents available? It is the norm to assume that provider must delivered the document to the receipient’s office. I doubt Microsoft is going to accept that documents from the EC is available to them until EC delivered it to its office. Hence, it cannot claim the documents are available if receipients have to travel to its offices. In the good old days, one have to deliver the document to the doorsteps of someone’s office, get a dated receipt for it. Today, it is argueably Ok to say that if a non-critical document is available through a website, where the stakeholders (EC,trustees etc) can dowonload, or when the document is attached to an email mailed to the receipient, delivery is achieved. However, for important documents, such as this one, confirmed delivery is essential. It may be in the form of laptop computer or CD ROM but it must be physically presence in the receipients office. The point is the receipients must be able to examine the documents without much effort on his/her part. In other words, the onus is on the person providing the document, Microsoft in this case, to make reasonable effort to make the document available.

Requiring the receipient to travel to Microsoft headquarters and review the document seriously inconvenient the receipients. This is true even if Microsoft is willing to foot the cost of travel. Moreover, the document is not viewed in a neutral place but in a hostile setting (MS headquarter). That is much more objectionable then the travelling requirement.

It is true that some government offices require receipients to travel to its office to collect communications/documents. This is usually done when the government cannot know beforehand who will want the documents. Furthermore, it is the government or authorities that can claim this practice when dealing with you or me or private entities like Microsoft. To ask the government or authorities to come to collect from private persons or entities is laughable.

All in all, I do not consider the documents delivered until 23 December when a copy arrived at the commission. Thus, in my view, the European Commission is within its rights to ignore Microsoft’s 15th December revision. It was not delivered in time.

In fact, should the Commission have any problems reading the documents for any reasons (I am thinking of the Digital Restriction Management), one can argued that the document is not delivered until the problems are resolved.

Do Microsoft’s counsels know that their reasoning is flawed? I would think so, coz they prefered the word “available” rather than “delivered”.

(Update) On footnote 73 (p35), Microsoft indeed argued that they complied with the 15th Dec deadline because the Instruction to Microsoft only requires Microsoft “to make Interoperatbility Information available to undertakings wishing to develop competitive operating systems and to established a mechanism for such undertakings to evaluate the Interoperability Information” and by making the Interoperatbility Information available at its USA headquarter it satisfied the requirement. That is stretching the term “availability” beyond its elasticity limit and they know it. Things are not available if one is made to jump-through-the-loops to get it. If this type of “availability” definition is acceptable, next time someone will say they did make things available by writing the documents in braille.

Storm about a not-so-new potentially Microsoft-penned report

[Updated March 07 2006: Karipuf has pointed out an serious flaw in my assertion that microsoft actually ghost written the report. On further investigation there is no evidence to support it. I apologize for the misunderstanding and withdrawn the blog entry. I am still leaving it online for the record]

There is a storm brewing over an old report that might as well be “ghost-written” by Microsoft for New Zealand government. I say it might has well been ghost-written by Microsoft because the person who penned the report is a law firm that works with Microsoft, and the content is virtually parroting all Microsoft’s argument against open source.

According to this Groklaw article, if you download the .doc version of the report, Microsoft is the copyright owner of the document. (Update March 07 2006: There is where I misread PJ’s article, thus misassociating two possibly independent piece of work, the .doc file and the report) How strange. A report written by State Services Commission (SSC) to assist NZ government agencies is not copyrighted by them but by someone else. I am not a lawyer, but I would think that any policy document/important guide authored for SSC is Crown-copyrighted. Unless, of course, the document is not as important is it looks.

It is an old report, written in 1998 to be precise. If my memory serves me correctly, it is about the time Microsoft started the anti-FOSS (Free and Open Source Software) FUD campaign. Of course, at the stage, the conflict-of-interest and self-serving purpose of Microsoft penned report on software development were not yet known or not impressed onto the government. As far as government agencies are concerned, Microsoft is a big software house, and they have long experience in software licensing and their views was (and still is) valuable in formulating policy. There is also a blind trust on Microsoft, which is now severely eroded.

Hence it is not surprising that SSC bought Microsoft’s view outright back in 1998. The re-acceptance of the report back in 2003 raise slight concern because it does not seems to be revised. In particular, it fails to consider the evolving open source landscape. Either the reacceptance process is simply a standard process, was done blindly, or its re-acceptance simply means it was taken into account when a policy was made, i.e., this is not a policy statement. The evidence support the last scenario when viewed in the context that SSC briefing on Open Source Software in NZ government was a good piece of work worthy of a neutral party in the Proprietory vs Open Source debate.

As for its release in 2006, it is probably because someone in NZ government managed to dig it out from the archive and put it out for pulic access. Someone was tasked to write a brief introduction and he/she got the context wrong. This is possible, I did it sometime. Hence, I do not read it as something sinister or a Microsoft plot behind this 2006 release.

Is the report all bad? No. A quick glance of the report shows that if you take out the biases against open source, it is a good recommendation on how to manage software, any software, in government and in business. To do so, you replace “Open Source Software” with “Any Software, proprietory or open source” in the document and consider all license-specific comments as evaluation criteria when choosing whether to license software. It outlines the due-dilligent process one have to follow before adopting any software, contracting software development to third party and how to maintain changes to source code etc.

IPod Hi-Fi, a step too far for Apple?

Apple just launched the IPod Hi-Fi. One word summarize it: UGLY!

I don’t care what advance technology Apple has used in the product coz most people do not buy IPod for the underlying technology, but for the “Cool” factor.

As far as I can see, IPod Hi-Fi simply add two large speakers (and a remote). So what make it different from other IPod enabled speakers in the market already? NONE.

Except two things: size and cost. IPod Hi-Fi looks huge. It looks like a cheap rip off of my grandfather’s old monophone speaker. How am I going to show it off to my friend?

Worse, one’s IPod looks like a sore thumb when connected to this rip-off speaker. Connecting the IPod to the speaker looks like an afterthought and unplanned. At least Apple should have the decency of designing a proper slot for the IPod.

As for cost, $350? Nuts. Too expensive. Buy it and people do not think you are rich, but a gullible man who do not know how to spend his money.

All in all, I do not like the product a bit. I hope this is a one-off for Apple. Otherwise, we will see a repeat of what the PCs did to the company in the 90s. And Steve Job will also gain the dubious honour to be the only person in this world who lost the market after building it with innovative products twice in the same company. Apple’s shareholders should also be reminded about the saying “Fool me once, shame on you. Fool me twice, shame on me”.