Is Sun Friend or Foe?

A response to GrokLaw Article, “Sun's Schwartz Pledges to Use Patents to Protect Red Hat and Ubuntu”

Authored by: gary.edwards on Tuesday, May 22 2007 @ 06:50 PM EDT

^#1Two years ago i attended an OSBC conference where Jonathan Schwartz was a keynote speaker. He spoke to the issue of how the GPL steals the most precious asset third world countries have - the wealth of intellectual property resources these countries possess by way of their growing populations. It was the most virulently condemning anti GPL speech i've ever heard. He offered up many real world use cases based on conversations Sun has had with emerging economies the world over. Brazil was frequently mentioned as a country squandering their most precious resource by mandating open source solutions based on the GPL.

Okay, after dropping SSSL and placing OpenOffice firmly under the LGPL, some might say Sun has gotten religion. And this was of course followed by the recent GPL'ing of Java. Maybe though this mysterious conversion was due to the stone cold reception Mr. Schwartz received for his OSBC assault on the GPL. The many lawyers and indemnification nazis who swarm every OSBC stood up and cheered mightily. The suits were jubilant. But tee shirt crowd in attendance (about 1/3) met Mr. Schwart's assault with stone cold glare. If looks could kill......

I remember well the long walk Mr. Schwartz took, leaving the auditorium with two body guards on each side, as he made the mistake of choosing the tee shirt gauntlet as his exit path. It was one long walk. Not once did he make eye contact with the hundreds of glaring, seething with anger, penetrating stares that never wavered. Even after he passed by. It was so chilling that even the cheering lawyers and indemnification nazis saw fit to quietly melt into a silence that hung like an explosive gas, a cloud of vengeance waiting for someone or something to jump up and ignite it all.

Later on in the afternoon, while taking a seat to listen to Geoffrey Moore's key note, i bumped into ZDNet's Dan Farber. Of course i had to have my say about the Schwartz assault on the GPL. The Schwartz claim that the GPL was a theft of an emerging countries most prized possession and source of future wealth, the natural resource of their intellectual property, was really burning me up by this time. To my surprise Dan looked at me and said that it was impossible to see it any other way. It was theft.

As Mr. Moore got into his explanation of the OSS firehose of code that had been unleashed, i was wishing he would turn the hose on me to cool things off.

It cost Sun nothing to stand up for Linux. There's no credible threat. If there was we would have seen it long before now.

The real question for Mr. Schwartz is Sun willing to put the open source crippling power of their patent portfolio on the line for OpenOffice?

He doesn't say, but the 2004 deal with Microsoft is instructive. Sun saw fit to protect the paid for version of OpenOffice, StarOffice. OpenOffice however was hung out to dry, where it remains today.

At the time, much was made of this omission by Sun. No one however made the connection between OpenOffice and the OpenDocument file format.

Last week when Microsoft launched it's son of SCO assault, most of the focus went to Linux. But who would doubt for a moment that it is the combined Windows - MSOffice desktop monopoly that is the real barrier that keeps the world under the Redmond thumb? In particular, when it comes to workgroups and workflows, MSOffice presents us with two very difficult barriers: the MSOffice bound binary file formats and, the MSOffice bound business processes, line of business integrated apps, and problematic add-ons like those represented by assistive technologies.

I would argue that it is this second barrier, the MSOffice bound workgroup - workflow business processes that have stopped the Linux Desktop stone cold.

The business processes demand near perfect "roundtrip" conversion fidelity, which only MS can achieve. Especially when converting existing documents and business processes to XML.

And then there is that problematic business process logic and application integration layer of VBA scripts, macros, and OLE dependencies so common with compound documents.

There are two traditional approaches to this impossible dilemma. One is to rebuild the MSOffice bound business processes on Linux - OpenOffice workgroups. This is often called the "rip out and replace" approach. The other approach is to try to integrate Windows-OpenOffice desktops into MSOffice bound existing workgroups, hoping for a gradual migration of business processes to open run time engines and Web 2.0 systems that would eventually open the door to Linux - OpenOffice desktops taking over these workgroups.

As OpenDocument moved into prominence as a government mandated file format solution, a third approach emerged. This is the ODF plugin for MSOffice approach, where an ODF plugin neutralizes MSOffice by turning it into a fully functional ODF pump. This approach is favored by governments because it is seen as a non disruptive, easy to implement, business as usual means of migrating existing documents and business processes to ODF XML.

The problem with the plugin approach is that MSOffice continues to dominate the desktop, and might do so indefinitely. At some point in time, those MSOffice bound business processes have to be migrated to an open source footing. Otherwise, we're just treading water as Microsoft comes up with increasingly better productivity arguments for migrating those MSOffice bound business processes to their MOOXML - .NET - XAML centric Exchange/SharePoint Hub.

Make no mistake about it, the E/S Hub is an ODF killer. It's also a barrier to every SOA, SaaS or Web 2.0 effort not fully conversant in proprietary MOOXML-.NET-XAML.

Think of it this way. Microsoft is moving these business processes from an integrated desktop environment that they totally control, to an integrated desktop-server-device-Web integrated environment that they totally control. Judging by what has already happened int he real estate industry, moving business processes into the emerging Vista Stack of MS applications and services, these business processes will be locked in for the next fifteen years. And any application - system not having specific Microsoft permission to connect to their Vista Stack locked out.

So why is the OpenOffice - ODF connection important here?

With good reason the world is considering mandating ODf as the required file format going forward. The problem is that ODF is intimately tied to OpenOffice. If OpenOffice is no longer available, what then? Well, one can assume that we would need to pay Sun a subscription fee for StarOffice, the only other application in the world that can fully implement ODF and provide full fidelity document exchange and interoperability with existing OpenOffice ODF documents.

This is exactly what the world should have read into the recent MS patent thunder. ODF today hangs by a thread. And where does this leave our hopes for a Linux Desktop?

I for one don't think this is some accidental opportunity. A windfall that just happens to come to Sun after spending upwards of $10 Million per year on OpenOffice/StarOffice - totaling today over $175 Million spent to date.

Go back to the 2004 MS-Sun agreement. Think market allocation - market splitting. Fast forward to the recent MS-Novell agreement. Understand that the only way the world can move their existing documents and business processes to ODF is to have a version of ODF that makes every effort to accommodate the elements of high fidelity "round trip" conversion and a non disruptive transition. These elements are expressed as compatibility with existing file formats, backwards compatibility, application interoperability - including MSOffice, and expansion of ODF parameters beyond the desktop confines of OpenOffice and out across the needs of enterprise publication, content and archive management systems, SOA, SaaS, and the Web 2.0.

While no one wants to admit this, the truth is that Sun dominates and controls the OASIS ODF Technical Committee. And if you oppose them the consequences are serious, as the OpenDocument Foundation recently found out. Worse, there is a four and a half year record of Sun opposing or undermining efforts to enhance compatibility and interop.

And then there is the insane insistence by Sun that ODF be limited to only those features supported and implemented by OpenOffice.

The issues of compatibility - interoperability versus new and innovative application features came to head in the recent ODF TC vote on the ODF 1.2 List Enhancement Proposals. Once again OpenOffice features triumphed over concerns about compatibility - interoperability. Nothing new here except the lengths to which Sun was willing to go have their way with ODF. It was nothing short of a total breakdown and abandonment of the consensus process. If the governments of the world ever knew how few the number of changes to ODF are actually needed for them to bridge that problematic compatibility - interop divide; the chasm they need to cross before they can actually implement ODF with anything less than a totally costly and disruptive rip out and replace, they would hang Sun by the hide.

In fact, the interop changes are so simple i'm going to post the basics here:

Tables: * introduce allowCollapse attribute for paragraphs following nested tables to encode WW and HTML-like tables. * declare sub tables as deprecated

Numbering * introduce text:level-text attribute to encode arbitrary number formats * introduce text:num-follow-char to encode WW-like numbering * introduce text:list-override to encode WW-like numbering * declare style:list-level-properties/@text:space-before as deprecated. Effect can be achieved with paragraph indent.

Master-page styles * add header-first and footer-first to encode WW-like page-styles * modify master-page styles such that WW-like sections can be encoded; current CSS3.0 like text:sections are not applicable * declare the style:next-style-name attribute of master-page declarations as deprecated.

Styles: * allow deriving paragraph-family styles from text-family styles.

"Break chars" * introduce a command and a command similar to the command

Fields: * enhance field support by introducing a and a element to which metadata can be attached.

Change tracking: * introduce change tracking for tables * introduce change tracking on property level

Discourage the use of the following OD features for MOOX interop: * nested frames * current CSS3.0 like text:sections * use fo:break-before instead of fo:break-after * use fo:margin-* for tables

Not to difficult, right? And the pay off for governments looking for reasonable means of implementing ODF is extreme. if we could only get the basics into the spec. Yet take a look at the six months of public eMail discussion regarding just one aspect of compatibility - interop, the List Enhancement Proposals. Multiply by ten the abuse and personal attacks that took place in public by what went on in the back channels, and you have some idea why it is so important that the world revisit that 2004 agreement between Sun and Microsoft.

I've been a member of the OASIS ODF Technical Committee for four and half years - one of only three original members remaining. We had great hopes that even though OASIS is a big vendor consortia, and Sun controls and dominate both the ODF TC specification work and the OpenOffice reference implementation, the goal of a universal XML file format was so worthwhile and important to mankind's digital future, we could and would overcome these concerns. Especially since everyone believed that Sun shared our ambitions.

Now i wonder. Now i'm looking carefully at a series of events that include the SCO assault, Sun's funding of the SCO assault, the 2004 Sun-Microsoft agreement protecting StarOffice and cutting OpenOffice off, the 2006 Novell-Microsoft agreement, and the recent notice Microsoft has served on OpenOffice.

Let me add one last point of interest. While i'm no expert on the MS patent infringement claims, i have reason to believe that these claims are real. Recall when IBM forked OpenOffice at the OOo 1.4.1 release, when OOo was covered by a dual SSSL-LGPL license. It's a well known fact that with the OOo code base, Sun controls all key project management positions and critical rights to commit. So this was seen as rather natural rational for the fork.

In 2006, while receiving an in depth demo of IBM's WorkPlace, i couldn't believe the work that had gone into de constructing the OpenOffice interface. So much so that i wondered if users would even recognize the productivity environment potential. The off the record answer i received was right on point, and sent me reeling. It was believed that OpenOffice violated a number of MSOffice interface patents, and these violations had to be fixed. No matter what the cost.

One caution i would have for every government considering the launch of an ODF pilot study (like California). If i was Clark Kelso, i would ask Sun to fully indemnify OpenOffice, or withdraw the wonder kind and all it's many variations from consideration. As for the OASIS-Sun hammer lock on ODF? I'm fully confident that when governments realize what's really going on there, things will change fast. Very fast.

~ge~

Postscript Comment:                                                             

At any time since the founding of the OASIS ODF TC in 2002, we could have slammed the door shut on MS OOXML (OfficeOpenXML) simply by adding the interoperability eXtensions-enhancements to existing eXtensions needed to perfect compatibility with existing MS documents and interoperability with existing MS applications and processes.  There are only six very simple iX enhancements needed for ODF to establish perfect interoperability with MS documents, applications and processes. 

Sun has fought every compatibility-interoperability effort that includes MS documents, apps, and processes since that first OASIS ODF TC meeting, December 14th, 2002. 

There are only two reasons i can think of as to why Sun would intentionally seek to limit ODF interoperability.  One is that it is very costly for them to fix OpenOffice to comply with the iX compatibility-interoperability enhancements.  And nothing goes into the ODF specification unless it is fully supported and implemented by OpenOffice. 

There is one and only one exception to this; the Section 1.5 Compatibility Clause that was designed for the conversion of MS binary documents to ODF.  The Compatibility Clause was the work of Stellent, Corel, Boeing, ArborText, the Australian National Archives, and SpeedLegal.  Sun was forced into a compromise (Feb 2003). 

Sadly, OpenOffice only supports foreign elements and alien attributes with text spans and paragraphs.  Which means next to zero interoperability with ODF documents produced by MS docs and applications with ODF plug-in converters.

The other reason is that, like so many corporations, Sun treats interoperability as a corporate asset that can be traded, exchanged, bartered and otherwise leveraged in deals with other corporate systems vendors.  In 2004, Sun cut a $2 Billion deal with Microsoft that involved interoperability, patent protection for StarOffice (not OpenOffice), and sweet sweet MS Applications on Sun hardware agreements that no doubt saved the company.

Take your pick of reasons.  The result is the same - limited ODF interoperability at a time when the world is screaming for high fidelity interoperability. 

The failure of ODF in Massachusetts is exactly due to the intentional limiting of ODF interoperability.  The da Vinci plug-in for MSOffice is able to match exactly the high fidelity "round trip" conversion of the OOXML plug-in for MSOffice.  The problem is that, without the ODF iX "interoperability enhancements", it is impossible to pipe da Vinci's conversion into ODF with the high degree of interoperability the world expects between ODF ready applications.

The failure of ODF in Massachusetts has a date; October 4th, 2006, when CIO Louis Gutierrez resigned.  CIO's in California, Denmark and Belgium quickly moved to a joined OOXML-ODF implementation model.  The recognition being that if Massachusetts couldn't implement ODF without having to rip out and replace MSOffice, then no one could.

Every government CIO in the USA realizes the importance of the ODF failure in Massachusetts.  The "rip out and replace" solutions offered by the ODF community are simply too costly and disruptive.  This attitude is so ingrained that it no longer matters what ISO does with OOXML.  The real world issue is that of being able to migrate existing documents, applications and processes to XML.  And do so without loss of information.  Microsoft provides a high fidelity OOXML plug-in for MSOffice.  There is no similar ODF plug-in available.  And without OASIS ODF TC acceptance of the iX proposals, that's not likely to ever change.

The funny thing is that Novell and Sun are working together on a native OOXML implementation for OpenOffice.  Sun recognizes that the only way they can do this is with some forms of the ODF iX interoperability enhancements.  Yet, it will still take up to three years for them to re write the OpenOffice layout engine to effectively implement iX.  Meaning, the rest of the ODF community will have to wait before the critically important iX proposals make their way into the ODF specification.

In the past year there were no less than five iX proposals submitted to the OASIS ODF TC for discussion.  Three of these were submitted by the Foundation with the signed off approval of Massachusetts ITD.  Two others were submitted by Novell as part of their agreement with Microsoft to create an OOXML plug-in for OpenOffice.  Of the five, two of the iX proposals qualified as "interoperability frameworks".  Meaning, independent converters, translators, developers and document processors would be able to innovate new features and deal with "unknown" application features without having to submit eXtensions to the OASIS ODF TC for approval before implementing.

All iX proposals were met with disregard and objection.  Sometimes vicious objection.  Sun in particular opposed the interoperability enhancements, characterizing them to various governments as "proprietary eXtensions" designed to intentionally break ODF interoperability!

IMHO, Sun's actions have served to hold the door open for OOXML.  At any time we could have slammed that door shut.  Yet, here we are.  OOXML will be the target file format for the conversion of billions of existing documents to XML.

Hope this helps,

~ge~

References
Bookends
Background on iX "Interoperability Enhancement" Proposals

References: 

• Florian Reuter: Suggested iX "interoperability enhancements" for OpenDocument V1.2:
• Florian Reuter: Status Update for iX "interoperability enhancements", ODF v1.2
• Break Point::OASIS ODf “List Enhancement Proposal” :: Vote Details with comments
• What Does Interoperability Mean?
• A History of the OASIS ODF iX Proposals
• The Foundation's ACME 376 - da Vinci Plug-ins for MSOffice
• ODF Alliance Rift :: A Change of position in response to the failure of ODF in Massachusetts

• ACME 376 :: The ODF iX Proposals and the quest for a Universal File Format

• What is the truth about Sun and SCO?

Bookends:                                                                           

While it's hard for governments in particular to understand why the OASIS ODf TC would ever oppose the needed “interoperability enhancements” necessary for high fidelity conversion, there is the fact of the Sun “bookends”.

The bookends are actions taken by Sun at the beginning and the end of the ODf life cycle. In the middle are years of Sun acting to limit the universal interoperability of ODf to not include Microsoft documents, applications and processes.

At the very first OASIS ODF TC meeting on December 14th, 2002, an effort was made to change the proposed charter Sun had written to include as a primary objective, "compatibility with existing file formats and interoperability with existing applications". This would of course include Microsoft file formats and applications. After much discussion, the proposal was cut to just "compatibility with existing file formats", with Sun opposed to having a vote that day. Like so many other interoperability - conformance issues, the charter universal interop issue was punted far into the future.

Fast forward to July of 2007 and consider the Sun-Bosak official position statement in support of ISO approval of OOXML (DIS 29500) as an international standard:

“We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.”

There you go. If you want to know who held the door open for OOXML, look no further than these bookends. And what's in between isn't pretty.

Background on the iX "Interoperability Proposals: