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
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

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


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

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

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
The MS Covenant Not to Sue: Sending a Mixed Message
Tuesday, November 29 2005 @ 01:20 PM EST

Sun's Simon Phipps has some helpful observations on the Microsoft covenent not to sue:
In the spirit of contribution, then, here are six observations about their covenant:
1. Patent protection is contingent on a conformant implementation. "Conformant" is not defined, meaning there is uncertainty needing legal advice.

2. There is no provision for partial implementation, meaning true community-based development is not covered until complete.

3. It may well mean that implementation of just a word processor is impossible -- it implies that you have to implement everything (spreadsheets & all) to reach the bar.

4. It is specific to the version currently existing, meaning I can be hooked into supporting it now, but when Office 12 or Office 13 comes out & I update to be compatible with the format in that I can get sued. The covenant Sun uses creates ongoing protection.

5. It does not grant patents to the ECMA standard as it only applies to Office 11 XML. This means a new covenant will be needed for the ECMA work.

6. If the same form of words were used for a contribution to ECMA, then those prototyping the ongoing evolution of the standard as ECMA changed it would lose protection the instant any change was made. It applies only to Microsoft's input, not to ECMA's output. Or maybe they would rather ECMA didn't change anything?

Together, these six problems seem to be show-stoppers for open source, no matter how positive Brian Jones or even Larry Rosen may feel about it all -- as David Berlind says, we only know they won't sue what they unilaterally consider to be "conforming" uses. As it stands, I don't think their covenant gives open source developers sufficient confidence to implement the spec it covers, let alone the forthcoming specs that it doesn't. Assuming Microsoft intends, as they say, to open their data formats, we expect to see some further work and clarification to address these issues.

I had similar questions, particularly the what-does-conforming-mean question? Why isn't that defined? And if it isn't, how could you ever know where the line is? Phipps writes that it's an issue needing legal advice. But if Microsoft doesn't define it, the lawyers won't know either. And may I just point out in passing that being an ECMA standard doesn't mean it is open? ECMA follows a RAND policy, the terms of which are incompatible with the GPL and most OS licenses. And in a FAQ on Office 2003 XML Reference Schemas, Microsoft tells us something interesting about RAND terms:

Q. Are Microsoft's licenses for its Office 2003 XML Reference Schemas RAND?

A. While there is no formal definition of RAND (reasonable and non-discriminatory), we believe that all of the terms in our licenses for the Office 2003 XML Reference Schemas are RAND. The patent license, including the defensive suspension clause and all other terms, are terms customarily found in standards-related patent licenses.

Catch that? "No formal definition." Or, wiggle room. This ECMA Powerpoint document states that ECMA doesn't define RAND either, and that's not all it doesn't do:

IPR Policy

Ecma does not:

Assess the essentiality of patents for implementation of a standard
Register patents used in standards or
Define the term "Reasonable And Non Discriminatory" (RAND)

Instead, members grant (not necessarily royalty-free) licences under RAND terms, by default

If, in very rare cases, contributing members do not accept RAND terms, there are several options:

Ecma stops the project
Participants collectively buy the license
Participants circumvent the patent by alternative implementations of the standard

How reassuring do you find that? Here, the patent covenant not to sue means you don't need to get a license from Microsoft on the schemas, but the point I'm making is that RAND does not equal Open. If anything, the opposite.

I believe the requirement in Massachusetts is not just that a format be a standard, but that it be an *open* standard. ECMA in no way speaks to that important requirement, in my view. So, if Microsoft wishes to qualify in a way that won't elicit derision, it still would have some work to do to qualify even if ECMA rubberstamps its application. ECMA describes itself like this:

Ecma is driven by industry to meet the needs of industry, generating a healthy competitive landscape based on differentiation of products and services, rather than technology models, generating confidence among vendors and users of new technology.

When a standards body says it is "driven by industry to meet the needs of industry", you might want to consider what that means in this context. The Commonwealth is trying to meet the needs of government, not the needs of Microsoft, presumably. ECMA has no such agenda. We won't need to guess as to the result. Novell's Miguel de Icaza writes:

Novell will be sending some folks from our Open Office team to the newly created ECMA TC45 working group. We hope to determine if the standard will be open enough and the details complete enough to allow for interoperability.

The whole Internet world is watching, so Microsoft will have to be real, or it will become obvious.

I asked Marbux to explain Microsoft's covenant to me, and hence to all of us here, and to list everything he sees. If you only have time to read one section, I'd suggest section 3.

But for the truly busy, let me quote just part of one section:

When Microsoft does update the covenant not to sue to cover Office Open XML, the company might also consider expanding the covenant's scope to expressly repudiate previously asserted inconsistent limitations of rights, such as the Office 2003 Schemas patent license and the Open Packaging Conventions draft patent license discussed in the Developer Tools Licensing Issues section of this article.

Microsoft is sending a mixed message by presenting developers with inconsistent documents like the covenant not to sue and those patent licenses. I.e., one limits rights, while the others expand some of the same rights and vice versa. Compare the covenant not to sue with the Office 2003 Schemas patent license. ...

In contrast [to Sun's covenant], Microsoft's covenant is far more convoluted and limits developer rights in a three-step process. In the first step, Microsoft makes promises only regarding its "patent claims necessary to conform" to its file format specification. I assume that somewhat bewildering phrase means that Microsoft is making no promises regarding patent claims not necessarily infringed by a "conforming part" of a software application. All other Microsoft patent claims remain in play.

However, the more typical construct I have assumed Microsoft meant to use in itself begs the question of what is "necessary." I.e., if Microsoft can later prove that a different programming solution producing the same result would not infringe, then Microsoft can argue that the covenant does not apply because the infringement was not necessary. For example, the draft Microsoft Open Packaging Conventions Patent License discussed in the next section states:

A claim is necessarily infringed only when it is not possible to avoid infringing when reading or writing packages that implement the Open Packaging Conventions, or rendering packages as allowed by the Open Packaging Conventions.
It is not absurd to suspect that Microsoft might make such arguments in regard to the covenant not to sue.

However, the covenant's putative patents are not identified, so there is no means provided for developers to determine whether there is a non-infringing work around for a Microsoft patent claim. The result is that Microsoft in effect asks developers who would work with Office Open XML to roll the dice on whether they gain any protection whatsoever from Microsoft's promise not to sue.

In the second step of its limitation of developer rights, Microsoft promises not to sue only in regard to "conforming parts" of software products. The language employed provides absolutely no guidance on what constitutes a "conforming part" of a software product. Is that any more than the file format XML code itself? Precisely what in the maze of coding interdependencies that is typical in a complex software program might be confidently demarcated as a "conforming part" and therefore exempted from a Microsoft patent infringement lawsuit? Microsoft's covenant not to sue over "conforming parts" of a software program provides scant confidence that any code in a software product will not provide grounds for a Microsoft infringement lawsuit.

Bottom line? Unless Microsoft clarifies, no one will dare to touch their XML, and that makes it not open at all. Marbux sums up:

In summary, Microsoft should consider taking prompt action to align its licensing documents with its public statements regarding developer freedom to use its forthcoming Office Open XML file format specification. Those documents presently impose unnecessary restraints on developers' implementations of the new Microsoft Office Open XML specification. . . .

If Microsoft truly desires to see Office Open XML widely used by other developers, Microsoft must allow them the freedom to add and subtract from the Office Open XML specification to accommodate the features of their own applications and to innovate. Accordingly, Microsoft should consider amending the covenant not to sue with binding definitions making it clear that developers can adapt the Office Open XML specification to their own applications as needed.

Microsoft might also consider amending the covenant not to sue to extend its promises to subsequent versions of the specification as Sun Microsystems did in its OpenDocument covenant not to sue. That omission can only create doubt that revisions to the specification may be used on the same terms. Developers need certainty that they will be allowed to update their software creations as file format specifications mature. Microsoft provides no such assurance.

Finally, Microsoft might consider moving beyond mere tweaking of its existing covenant not to sue. Because Microsoft has not yet committed to final wording on its covenant not to sue in regard to Office Open XML, the company is in a position to mirror the language of the Sun Microsystems covenant not to sue in regard to the OpenDocument XML standard.

That would cure all of the deficiencies discussed above.

Or as they might put it in Brooklyn, it ain't open 'til it's open.

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

The Microsoft Covenant Not to Sue - Sending a Mixed Message
~ by Marbux

NOTE: The Reader should understand that the author of this article is retired and no longer practices law. Accordingly, nothing in this article should be regarded as legal advice. Should you desire legal advice regarding subjects discussed below, you should consult your own attorney.


  1. Introduction
  2. The Microsoft Covenant Not to Sue
  3. Developer Tools Licensing Issues
  4. The Government Procurement Environment
  5. Conclusion
  6. Notes

1. Introduction

Facing mounting pressure to support the OpenDocument XML file format standard in its flagship Office software suite, Microsoft responded by announcing it would instead submit its own Office 12 XML file format — now under development — for consideration as a formal standard. Groklaw has already covered the initial announcement. This article addresses software patent licensing issues involved with that announcement. Copyright and trade secrecy issues are not examined.

In summary, Microsoft should consider taking prompt action to align its licensing documents with its public statements regarding developer freedom to use its forthcoming Office Open XML file format specification. Those documents presently impose unnecessary restraints on developers' implementations of the new Microsoft Office Open XML specification.

[ Contents ]

2. The Microsoft Covenant Not to Sue

Microsoft followed up its initial announcement of its intent to submit the Office Open XML specification to standardization processes with public release of a covenant not to enforce its patent portfolio ("covenant not to sue") against those who use its Office 2003 XML file format, which Groklaw has also already reported.

However, that is not the file format Microsoft intends to submit to the standardization processes. The company has not yet issued licensing information for the new Microsoft Office Open XML file format scheduled to be released with Microsoft Office 12 about a year from now. Office Open XML is the file format Microsoft said it will submit to standards bodies.

A Microsoft developer said that the company would later "update" the Office 2003 XML file format covenant not to sue1 to "cover" the Office Open XML file format once its specification was "posted." B. Jones, Microsoft Developer Network, New approach to licensing with the Office XML formats (November 22, 2005) ("[w]e'll of course update this to cover the [Office] 12 schemas as soon as we get those posted").

That statement is sufficiently vague that a court would not likely hold that it creates any enforceable Microsoft obligation. But in any event, Microsoft will likely carry through with that plan. In the remainder of this article, I will assume that the existing covenant not to sue will in fact be used without change other than to bring the Office Open XML specification within its scope, except where I make suggestions for its amendment. (However, the unavailability of the covenant that will actually be used with the proposed standard obviously prevents any analysis of the final document.)

When Microsoft does update the covenant not to sue to cover Office Open XML, the company might also consider expanding the covenant's scope to expressly repudiate previously asserted inconsistent limitations of rights, such as the Office 2003 Schemas patent license and the Open Packaging Conventions draft patent license discussed in the Developer Tools Licensing Issues section of this article.

Microsoft is sending a mixed message by presenting developers with inconsistent documents like the covenant not to sue and those patent licenses. I.e., one limits rights, while the others expand some of the same rights and vice versa. Compare the covenant not to sue with the Office 2003 Schemas patent license.

Assuming the language of the existing covenant not to sue is the model for the covenant applicable to Office Open XML, as indicated by Brian Jones, Microsoft might also consider further altering some of that language. With key words emphasized, the covenant not to sue provides in relevant part:

Microsoft irrevocably covenants that it will not seek to enforce any of its patent claims necessary to conform to the technical specifications for the Microsoft Office 2003 XML Reference Schemas posted at http://msdn.microsoft.com/office/understanding/xmloffice/default.aspx (the "Specifications") against those conforming parts of software products.

By contrast, the corresponding portion of Sun Microsystem's covenant not to sue regarding the OpenDocument XML specification reads:

Sun irrevocably covenants that … it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates[.]

Sun's covenant applies to "any implementation" of the OpenDocument standard as well as to any implementation of any subsequent version of the standard, so long as it is a version of the standard that Sun participates in developing. The rights granted are unambiguous and broad ("any implementation").

In contrast, Microsoft's covenant is far more convoluted and limits developer rights in a three-step process. In the first step, Microsoft makes promises only regarding its "patent claims necessary to conform" to its file format specification. I assume that somewhat bewildering phrase2 means that Microsoft is making no promises regarding patent claims not necessarily infringed by a "conforming part" of a software application. All other Microsoft patent claims remain in play.

However, the more typical construct I have assumed Microsoft meant to use in itself begs the question of what is "necessary." I.e., if Microsoft can later prove that a different programming solution producing the same result would not infringe, then Microsoft can argue that the covenant does not apply because the infringement was not necessary. For example, the draft Microsoft Open Packaging Conventions Patent License discussed in the next section states:

A claim is necessarily infringed only when it is not possible to avoid infringing when reading or writing packages that implement the Open Packaging Conventions, or rendering packages as allowed by the Open Packaging Conventions.

(Emphasis added.) It is not absurd to suspect that Microsoft might make such arguments in regard to the covenant not to sue.

However, the covenant's putative patents are not identified, so there is no means provided for developers to determine whether there is a non-infringing work around for a Microsoft patent claim. The result is that Microsoft in effect asks developers who would work with Office Open XML to roll the dice on whether they gain any protection whatsoever from Microsoft's promise not to sue.

In the second step of its limitation of developer rights, Microsoft promises not to sue only in regard to "conforming parts" of software products. The language employed provides absolutely no guidance on what constitutes a "conforming part" of a software product. Is that any more than the file format XML code itself? Precisely what in the maze of coding interdependencies that is typical in a complex software program might be confidently demarcated as a "conforming part" and therefore exempted from a Microsoft patent infringement lawsuit? Microsoft's covenant not to sue over "conforming parts" of a software program provides scant confidence that any code in a software product will not provide grounds for a Microsoft infringement lawsuit.

In the third limiting step, Microsoft closes its covenant with the only language it did apparently copy from Sun's covenant not to sue:

No other rights except those expressly stated in this covenant shall be deemed granted, waived or received by implication, or estoppel, or otherwise.

In Sun's covenant, the same language does not serve as a major limitation of rights because the grant of rights in its covenant is broad and contains no obvious ambiguity. In Microsoft's covenant, the same language acts as a further restriction of developer rights. That is because Microsoft's covenant contains the two-step restrictions discussed above and those terms are vague and ambiguous. Implication and estoppel are the tools traditionally used by courts to cure vagueness or ambiguity in a contract such as a covenant not to sue. In Sun's case, the language serves as protection for Sun from unanticipated arguments. In Microsoft's case, the language acts to further restrict developer rights.

When the three limitations are combined, the Microsoft promise not to sue is largely meaningless: (i) the no-waiver-or-estoppel provision acts to compel a narrow interpretation in Microsoft's favor of the "necessarily infringed" and "conforming parts" phrases; (ii) so interpreted, the "necessarily infringed" portion minimizes the number of its patent claims that are subject to Microsoft's promise not to sue; and (iii) so interpreted, the "conforming parts" phrase minimizes the amount of developers' code that is protected from suit.

Such problems are compounded by the lack of definitions for the word "conform" and its variant "conforming." If read restrictively, those terms could reasonably be interpreted as prohibiting implementation of subsets and supersets of the Office Open XML specification. See e.g., Sun Microsystems v. Microsoft, 188 F.3d 1115 (9th Cir. 1999) (Microsoft modification of the Java compiler specification).

Both subsets and supersets are critical to the ability of developers to use the Office Open XML file format. In the context of explaining why Microsoft chose to develop its own XML format rather than supporting the OpenDocument XML standard, Microsoft Office developer Brian Jones said:

Our primary goal at Microsoft was to create an open format that fully represented all of the features that our customers have used in their existing documents, documents that have been created using the existing Office products over the past couple decades. … The interoperability problems will start to come up if there are features that are present in one application but not present in the other application. You have to assume this will be the case since every application out there has a different set of customers that request different features.

Microsoft's Alan Yates compressed the same explanation:

Our customers require us to support the full feature set of Office and Office 12. They would not accept us supporting anything that didn't support some features or hid other features.

By the same logic, Microsoft should not expect other developers' customers to "accept [those developers] supporting anything that didn't support some features or hid other features."

Absent the right to create subsets and supersets, the Microsoft covenant not to sue would effectively limit competitors to writing add-on applications for Microsoft Office. They would not be granted the right to adapt the specification to stand-alone applications.

Such an interpretation, however, is at odds with statements about developer freedom issued by Microsoft officials in announcing its planned submission of Office Open XML for certification as an open standard. Therefore, there is reason to suspect that Microsoft did not intend that the "conforming" terms be interpreted as forbidding creation of subsets and supersets of its file format specification.

It may be that Microsoft actually intended a meaning more akin to the definition of "conformance" in the World Wide Web Consortium's XML 1.0 specification. That definition, far too lengthy to quote here, illustrates a minimum level of detail that Microsoft should supply in a definition of "conform" and "conforming." See also Sun Microsystems v. Microsoft, supra (Sun license required that Microsoft maintain Java compiler compatibility with a specified test suite).

If Microsoft truly desires to see Office Open XML widely used by other developers, Microsoft must allow them the freedom to add and subtract from the Office Open XML specification to accommodate the features of their own applications and to innovate. Accordingly, Microsoft should consider amending the covenant not to sue with binding definitions making it clear that developers can adapt the Office Open XML specification to their own applications as needed.

Microsoft might also consider amending the covenant not to sue to extend its promises to subsequent versions of the specification as Sun Microsystems did in its OpenDocument covenant not to sue. That omission can only create doubt that revisions to the specification may be used on the same terms. Developers need certainty that they will be allowed to update their software creations as file format specifications mature. Microsoft provides no such assurance.

Finally, Microsoft might consider moving beyond mere tweaking of its existing covenant not to sue. Because Microsoft has not yet committed to final wording on its covenant not to sue in regard to Office Open XML, the company is in a position to mirror the language of the Sun Microsystems covenant not to sue in regard to the OpenDocument XML standard.

That would cure all of the deficiencies discussed above. Such a change would also provide additional benefits. It would, for example: (i) eliminate any informed concern that the Microsoft format is more encumbered than the OpenDocument format; and (ii) eliminate the licensing incompatibilities that may otherwise frustrate feasible interoperability between the two formats.

[ Contents ]

3. Developer Tools Licensing Issues

Microsoft might also seriously consider including a binding policy statement regarding licensing terms for developer tools to work with Office Open XML. As detailed below, Microsoft's only licensing message to the industry is that it intends to keep necessary tools under lock and key. If that is not the message Microsoft wishes to convey, the company should consider clearly stating its actual relevant policy in the binding covenant not to sue discussed in the previous section. Such a message should be delivered soon, else silence itself be construed as a message.

A published draft Microsoft patent license for its Office Open XML packaging conventions is highly troubling because it: (i) casts a patent infringement cloud over any other method for packaging information in Office Open XML files; and (ii) is so restrictive that it limits developers to creating add-on tools for Microsoft Office.

I stress that the patent license is a draft; however, it conveys an ominous message to developers and government software procurement officials. Microsoft should therefore consider expressly repudiating it along with the additional restrictive license required for downloading the conventions.

Recall that the Office Open XML specification has not yet been published much less become a formal standard, and there is not yet a binding covenant not to sue if other developers use the format. Competitors' access to tools needed for use of the file format is no small issue because of Microsoft's apparent decision not to incorporate existing standards into Office Open XML as the OpenDocument standard does.

OpenDocument reuses existing standards whenever possible. It uses SVG for drawings, MathML for equations, etc. This makes the format infinitely more transparent to someone familiar with XML technologies. It also allows you to reuse existing tools that understand these standards. In contrast, Microsoft has decided to reinvent the wheel at every turn.

A. Hudson, et al, Groklaw, Format Comparison Between ODF and MS XML (November 26, 2005). Developer tools to work with the Microsoft format must therefore be reinvented as well. It matters what licensing terms Microsoft will impose on such tools.

Microsoft has made no commitment to allow others to create developer tools required for its unique file format. See B. Jones, Microsoft Developer Network, Office XML Formats: Standardizing the Microsoft Office Open XML formats (November 21, 2005) ("[i]n addition, we'll provide plenty of tutorials, best practices, and all kinds of tools to help folks work with the formats") (emphasis added).

Therefore, it is disturbing that Microsoft has made no commitment to abandon the draft patent license for its Open Packaging Conventions. Microsoft summarizes those conventions as follows:

The Open Packaging Conventions specification describes the method for packaging information in a file format, describing metadata, parts, relationships, and application of digital signatures. This specification is intended both for data format producers, who want to store data or content in a package that conforms to the Open Packaging Conventions including specific data formats such as the XPS Document format, and format consumers, who want to access and render or process the contents of a format that conforms to the Open Packaging Conventions, including the XPS Document and Microsoft Office Open XML formats.

Microsoft WHDC, Open Packaging Conventions (September 13, 2005) (emphasis added).

Internal data storage of the Office XML Formats is segmented into discreet components; for example, embedded code is stored separately from the document content inside the file. Each component within a single file is compressed using ZIP compression technology. In addition to the compression of each document segment, the entire document is also compressed using ZIP compression.

Microsoft Office Open XML Formats Frequently Asked Questions.

Microsoft's use of the ZIP file format for such purposes is hardly unique:

ZIP files generally use the file extensions ".zip" or ".ZIP" and the MIME media type application/zip. Some software uses the ZIP file format as a wrapper for a large number of small items. Generally when this is done a different file extension is used. Examples of this usage are Java Jar files, id Software .pk3/.pk4 files, package files for StepMania and Winamp, and some OpenOffice.org document formats. The OpenDocument format is usually sent as a Jar file, so it can be easily uncompressed and compressed using tools for ZIP files.

ZIP file format - Wikipedia

That Microsoft would suggest that it has patent rights to assert for a method of packaging information in ZIP files is in itself somewhat discomfiting as discussed below. However, I am here concerned with the larger licensing message conveyed to the software industry and to government software procurement officers by Microsoft's proposed assertion of severe patent license restrictions on tools needed for developers to work with Office Open XML.

Microsoft's draft Open Packaging Conventions Patent License includes much of the same language used in the Microsoft Office 2003 Reference Schemas patent license found wanting in the recent Massachusetts Executive Department's rejection of Microsoft's XML file format as a software procurement standard.

As with the latter license, the Packaging Conventions license requires inclusion of a Microsoft patent rights notice in licensed implementations and developers are prohibited from sublicensing or transferring their rights. Those provisions make the Microsoft Open Packaging Conventions incompatible with all open source software licenses certified by the Open Source Initiative ("OSI").

The no-sublicensing-or-transfer provision also blocks use of the Microsoft packaging conventions by anyone other than Microsoft who develops Office Open XML software for distribution, whether proprietary or licensed under an OSI-approved license. See my previous detailed and referenced discussion of the Office 2003 Reference Schemas patent license, including the specific reasons such provisions block use of the Schemas by other developers.

An additional issue with the draft packaging conventions patent license is a conflict between two important provisions. On the one hand, developers are told "[y]ou are not licensed to sublicense or transfer your rights." On the other hand, the license states, "[i]f you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed[.]" The license does not explain how a developer might "distribute, license or sell" software when they are prohibited from any "sublicense or transfer" of their rights. That ambiguity should be resolved if the draft patent license is not expressly repudiated.

It is also troubling that Microsoft's draft Packaging Conventions license excludes permission to use any Microsoft patented technology:

(ii) covering any Enabling Technologies that may be necessary to make or use any product incorporating a Licensed Implementation, or (iii) covering the reading or writing of packages other than packages that implement the Open Packaging Conventions, or rendering of packages in a manner that is different than the rendering allowed by the Open Packaging Conventions. "Enabling Technologies" means technologies that may be necessary to make or use any product or portion of a product that complies with the Open Packaging Conventions, but are not expressly set forth or required in the Open Packaging Conventions, such as general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like.

The implicit suggestion that Microsoft holds patent rights in this area but declines to license relevant claims unless the Microsoft packaging conventions are used implies that any developer that uses other tools for packaging information in Office Open XML files is at risk of a Microsoft patent infringement lawsuit.

Microsoft also declines to license any right to use the packaging conventions in any "general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like." Furthermore Microsoft also forbids any developer who does use the Open Packaging Conventions from sublicensing or transferring any of their rights.

To put it mildly, the patent license does not allow much wiggle room for anyone but Microsoft to do any development work involving Office Open XML. Unless developers are willing to risk a Microsoft patent infringement action over unspecified patent claims involving XML packaging conventions, Office Open XML files can only be read or written using Microsoft "general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like."

Even further issues are created by the inclusion of the following portions of the draft patent license:

Except as provided below, Microsoft hereby grants you a royalty-free license under Microsoft's Necessary Claims to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations solely for the purpose of reading or writing package that implement the Open Packaging Conventions, or rendering packages that implement the Open Packaging Conventions as allowed by the Open Packaging Conventions.

. . . . .

You are not licensed to sublicense or transfer your rights.

. . . . .

By way of clarification of the foregoing, given the unique role of government institutions, end users will not violate this license by merely reading government documents that constitute packages that implement the Open Packaging Conventions, or by using (solely for the purpose of reading such packages) any software that enables them to do so. The term "government documents" includes public records.

As I pointed out in my article dissecting the very similar Office 2003 Reference Schemas patent license, the "[e]xcept as provided below" phrase causes the prohibition against sublicensing or transfer of rights to extinguish the grant of rights to "sell, offer to sell, import, and otherwise distribute Licensed Implementations," leaving only the right to "make" and "use" a Licensed Implementation. The "[b]y way of clarification of the foregoing" phrase — which is also superior to the major grant of rights by way of the "except as provided below" phrase — necessarily implies that the license will be exceeded if the Licensed Implementation is used for anything but reading government documents (applying the expressio unius est exclusio alterius canon of contractual construction).

Because at the present time, the packaging conventions are separate from the Office Open XML specification, simply adding that specification to the existing covenant not to sue would not thereby confer Microsoft permission for others to use the packaging conventions. Therefore, Microsoft should consider explicitly bringing the packaging conventions within the scope of the covenant not to sue.

Should anyone decide after their lawyers read the draft patent license that they would prefer to download and review Microsoft's XML packaging conventions before agreeing to the patent license, they must first agree to yet another restrictive license that amongst other provisions, includes an indemnification provision: "[i]f there is litigation, the losing party must pay the other party's reasonable attorneys' fees, costs and other expenses."

Considering Microsoft's demonstrated ability to inflict and absorb legal expenses, plus the extremely narrow rights granted by the packaging conventions patent license in any event, the indemnification provision creates a considerable disincentive even to consider using both the packaging conventions and Office Open XML.

For reasons such as those discussed above, the present state of its legal pronouncements to the industry and government procurement officers leaves the message that Microsoft intends to impede their right to package data in the Office Open XML file format under implicit threat of a patent infringement action.

Indeed, by suggesting that it may assert patent rights in the area of XML package management, Microsoft casts a patent cloud over all others who package XML information in the ZIP file format. To diminish such concerns, Microsoft should consider announcing precisely what patent rights it holds in this area and explaining in detail its position regarding others' rights to use that technology. Such important matters should not be left to speculation.

Just as importantly, there is no binding Microsoft commitment to make any of the developer tools it plans to create for working with Office Open XML available under any less restrictive terms, or to allow other developers to create their own tools. But the language of the draft XML packaging management patent license suggests that Microsoft intends to keep developer tools for Office Open XML under lock and key. Unless that is its actual intent, Microsoft should consider correcting the misimpression in a legally binding document.

[ Contents ]

4. The Government Procurement Environment

On the other hand, if Microsoft management did intend to foreclose other developers from using its specification, they might consider asking its lawyers to make a more thorough study of relevant government procurement law. An anticompetitive approach to standardizing a specification may spell unanticipated trouble in the government software procurement arena.

Microsoft has indicated that its decision to submit Office Open XML as a proposed standard was driven at least in part by government procurement requirements:

Some customers, particularly in the public sector, have been telling us that they would like us to take this step. They are focused on the long-term management and archiving of digital records and want to use our document formats. They have told us that they would like to see us pursue this step as a measure of goodwill toward them and their interests and we are now following through on their request.

See also Computerworld: ("'We have a few barriers (with government contracts),' said Alan Yates, general manager for Microsoft Office").

Those barriers are significant. The OASIS OpenDocument standard is pending before the International Organization for Standardization ("ISO") for approval as an international standard. Approximately one month before Microsoft announced its decision to submit Office Open XML as a proposed standard, an OASIS Adoption Forum was held in London, U.K. devoted in part to the OpenDocument file format standard. At that conference:

Barbara Held from the eGovernment services division (IDABC) of the European Commission, said it can only recommend the open file format to member states if it is issued by a public standardization body, such as ISO. "Only specifications that are issued by public standardization bodies are considered standards by the European Commission. So, from the perspective of the European Commission, OASIS' OpenDocument format is not a standard," said Held, in a speech at the OASIS event. She said that IDABC will start recommending OpenDocument if it is approved as an ISO standard, as it already fulfills its criteria on open standards.

If the format becomes an ISO standard, this will not only impact the policy of European member states, but will also allow public sector organisations to tender for OpenDocument-compatible applications. "Only public standards can be referred to in calls for tender," said Held. "If we started tendering and asked for OpenDocument formats, someone could sue us. Instead we have to say, 'someone that is producing a document format that's open.'"

ZDNet U.K., ISO deciding whether to adopt OpenDocument (October 19, 2005). According to the same report, "the president and chief executive of OASIS[] said … that an ISO committee is due to vote 'shortly' on whether OpenDocument will be accepted as an international standard."

The European Commission's IDABC (formerly IDA) has enormous influence on government software procurement within the European Union, as it is the agency responsible for coordinating government software communications interoperability from the European Community level down to local government units. See e.g., OASIS Cover Pages, IDA Releases European Interoperability Framework for Pan-European E-Government Services (December 6, 2004). An IDABC "recommendation" bears considerable weight in European government software procurement.

Conceivably, Microsoft management inferred from such reports that adoption of Office Open XML as an ISO standard is all that is necessary, and that allowing other developers to use the standard is not a necessary condition of Microsoft products remaining eligible for government procurement contracts.

However, the very purpose of the relevant requirement of procurement tenders based on national or international standards is to end government procurement specifications that have discriminatory effect.

The overarching applicable law is the international Agreement on Government Procurement, one of the general trade agreements administered by the World Trade Organization. See my extensive previous discussion of that treaty in the context of the recent debate over Massachusetts Executive Department software procurement standards.

Regarding European law, Microsoft's attorneys may find it helpful to review a legal memorandum [PDF] prepared for the Initiative for Software Choice ("ISC"), an international government software procurement lobbying organization that includes Microsoft in its membership. I offer that memorandum because I suspect that Microsoft officials may trust its legal analysis more than mine.

The memo, after surveying the European precedents and noting their relationship to the Agreement on Government Procurement, makes plain that the purpose of the European procurement laws is to foster competition for government tenders by eliminating tender specifications that have discriminatory effect. It quotes Article 23 of the E.U. Public Procurement Directive:

Technical specifications shall afford equal access for tenderers and not have the effect of creating unjustified obstacles to the opening up of public procurement to competition.

The ISC memo concludes in part that:

[T]he conditions for performance of contracts must be compatible with Community law. As such, they may not be directly or indirectly discriminatory and must be indicated in the contract documents.

Any Microsoft plan to gain a competitive advantage in government software procurement through establishment of a discriminatory standard — if such a plan exists — should be thoroughly vetted by counsel.

[ Contents ]

5. Conclusion

Licensing issues surrounding Office Open XML remain a major concern. The over-all licensing message to the software industry and to government procurement officers conveyed by Microsoft's covenant not to sue and the draft patent license for the Office Open XML packaging conventions conflicts with Microsoft's public statements regarding the freedom that it will allow to developers working with Office Open XML. The message to developers left by the two legal documents is that they can only use Office Open XML to write add-ons for Microsoft Office, unless they are willing to risk a Microsoft patent infringement lawsuit.

It warrants consideration that licensing terms can also play a role in standardization body decisions whether to adopt a proposed standard. See e.g., Ecma Code of Conduct in Patent Matters ("[t]he General Assembly of Ecma shall not approve recommendations of Standards which are covered by patents when such patents will not be licensed by their owners on a reasonable and non-discriminatory basis").

Microsoft should promptly reconcile the disparity between its public pronouncements and its legal documents within the context of a published binding legal document so that developers and potential customers can plan whether to: (i) use the Microsoft Office Open XML file format; or (ii) pursue alternatives such as solutions based on OpenDocument XML.

[ Contents ]


6. Notes

1 Although they are not the same thing, both patent licenses and covenants not to sue have the legal effect of allowing the use of a patented invention on specified terms without liability. The author has therefore occasionally amalgamated both concepts by using the phrases licensing issues and licensing message as encompassing both patent licenses and covenants not to sue.

2 The Microsoft covenant not to sue is a grammatical horror that defies precise understanding. The phrase "patent claims necessary to conform" to the specification ignores the reality that software is written in code, not in patent claims. No patent claim is "necessary to conform to technical specifications." Once that error is recognized, the sentence dissembles into gobbledygook. I have attempted to work with the phrase nonetheless.


[ Contents ]


  


The MS Covenant Not to Sue: Sending a Mixed Message | 239 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Off topic here please
Authored by: Chris Lingard on Tuesday, November 29 2005 @ 01:25 PM EST

Please try to post in HTML, and put in those links

[ Reply to This | # ]

Put any corrections here
Authored by: Chris Lingard on Tuesday, November 29 2005 @ 01:27 PM EST

Should there be any misstakees

[ Reply to This | # ]

Non Conformant = implementing MS proprietary extensions?
Authored by: Anonymous on Tuesday, November 29 2005 @ 01:35 PM EST
My guess is that they intend to add proprietary extensions in Office, and then
sue anyone who implements those extensions as non-conformand with the
now-crippled "standard".

That way they can claim to be "open", with a Standard, yet still
prevent interoperability with anything other than MS software.

[ Reply to This | # ]

Vapor policy
Authored by: Anonymous on Tuesday, November 29 2005 @ 01:45 PM EST
The vaporware (vapourware) trick Microsoft plays is to pre-announce software and
features in a vague way months or years in advance of implementation to head off
competition. The potential buyers think "there is a Microsoft
solution/upgrade coming soon, so I don't need to switch to some other
software." This hurts competitors and wards off any potential competitors.
Over time, they may implement some of the features or none of them that were
announced, so the user is locked into the MS software and the upgrade hell.
Microsoft has been a master of this dirty trick.

Now they are applying the same tried and true vapor technique to license and
policy matters.

-srr

[ Reply to This | # ]

Next 30 days (reminders) - Meetings, Hearnings, Court dates, comment deadlines here:
Authored by: Anonymous on Tuesday, November 29 2005 @ 01:47 PM EST
Next 30 days - Reminders of Meetings, Hearings, Court dates, comment deadlines,
etc:

[ Reply to This | # ]

A Different Opinion
Authored by: Anonymous on Tuesday, November 29 2005 @ 01:53 PM EST
With all due respect to Marbux, an expert on open source law (Larry Rosen) has
weighed in on this issue, and he endorses MS's ECMA standard.
<p>
<a href="http://blogs.zdnet.com/BTL/?p=2192">ZDNET</a>
<p>
Rosen is the author of "Open Source Licensing: Software Freedom and
Intellectual Property Law". He has served as general counsel and secretary
of the non-profit Open Source Initiative (OSI), so I would think that his
opinion would carry some weight.
<p>
PJ, you've taught us a lot about expert witnesses in this forum. Would Marbux be
considered an expert on open-source law, like Rosen?

[ Reply to This | # ]

Conformance
Authored by: Minsk on Tuesday, November 29 2005 @ 02:03 PM EST
Usually the formal definition of conformance with a standard would come from the
standard itself. For example, the IETF RFCs use a set of key phrases (e.g.
"MUST", "MUST NOT", "MAY", which have an RFC of
their own) to indicate portions of the standard that are inclusive or
exclusive.

Of course Microsoft being Microsoft, the current schema reference is an
incomplete and disorganized mishmash of irrelevent Windows behaviors,
non-normative examples and low-level details. I wish any implementor luck
identifying the normative portions, because for the moment
"conformance" is a shot in the dark.

Elevation to an actual standard should improve things to the point where
normative and non-normative, inclusive and exclusive are definite. Of course
time will tell, and I am a cynic.

Chris

[ Reply to This | # ]

  • Conformance - Authored by: marbux on Tuesday, November 29 2005 @ 05:18 PM EST
    • Conformance - Authored by: Minsk on Tuesday, November 29 2005 @ 06:09 PM EST
      • Conformance - Authored by: Anonymous on Wednesday, November 30 2005 @ 02:41 PM EST
Mixed Message -- NOT
Authored by: bbaston on Tuesday, November 29 2005 @ 02:12 PM EST
How can I express my impression of this Microsoft offering?

Imagine a convicted thief, one who had previously stolen from you and mislead you, but who now wanted to do business with you and so had promised to come up with a pledge to never steal or mislead again.

Imagine that this thief finally came up with an agreement worded similarly to this Microsoft Covenant, and described it as a promise never to steal or mislead again.

Would you accept it as writen, or would you ask the thief to try again, putting a little meat in place of the fluff?

---
Ben, Groklawian in training
IMBW, IANAL2, IMHO, IAVO
imaybewrong, iamnotalawyertoo, inmyhumbleopinion, iamveryold
Have you donated to Groklaw this month?

[ Reply to This | # ]

The MS Covenant Not to Sue: Sending a Mixed Message
Authored by: Anonymous on Tuesday, November 29 2005 @ 02:39 PM EST
So "you can use our formats, and we won't sue you (unless we decide your
product is not conforming)".

In other words: if we don't like you, we will still sue you.

That doesn't sound very open to me.

[ Reply to This | # ]

The MS Covenant Not to Sue: Sending a Mixed Message
Authored by: Anonymous on Tuesday, November 29 2005 @ 03:12 PM EST
I wonder if the "olive branch" is really poison sumac?


[ Reply to This | # ]

Thanks Marbux
Authored by: RPN on Tuesday, November 29 2005 @ 03:18 PM EST
First thank you for the work and thought that went into your article. I've
always enjoyed your clear, incisive comments and this is an excellent piece that
I've found very interesting and informative.

Second it confirms my sense of what the covenant is worth as it stands.
Essentially it is meaningless because of the way it is written and above all the
ambiguities in it. A covenant as a legal document should have no ambiguities. As
a legal document perhaps a bit difficult to read as so many are but that's
different from ambiguous.

Sorry but I really cannot take this covenant seriously as it stands and it would
make my working life easier, my home life is set on Linux and Open Office now,
if MS would unabiguously either support ODF and/or make its formats now and for
all time genuine open standards (and I don't mean an MS standard but a standard
as understood by everyone else of having genuine broad industry input into its
development). Personally I don't care whether they support ODF and/or another
open standard. I do care they genuinely support a true open standard. (Which
said why bother developing another open standard when one already exists? Don't
answer this ladies and gentlemen, I think we already know the answer to that:)
)

Richard.

[ Reply to This | # ]

  • Thanks Marbux - Authored by: Anonymous on Tuesday, November 29 2005 @ 03:25 PM EST
The MS Covenant Not to Sue: Sending a Mixed Message
Authored by: Anonymous on Tuesday, November 29 2005 @ 03:33 PM EST
I would be curious to know whether MS agreement not to sue would be binding on
someone who purchased the IP rights from Microsoft. Even if Microsoft someday
comes up with a promise which sounds workable, could they simply sell the
technology and let someone else sue open source developers? Since MS is not
licensing the technology, are they providing any protection at all, or are they
simply saying "trust me, all will be well"?

[ Reply to This | # ]

ECMA is a front
Authored by: Anonymous on Tuesday, November 29 2005 @ 03:33 PM EST

The other day - in another thread - I posted this:

"Microsoft --> ECMA --> ISO

ECMA is a lobby group (think BSA). ECMA will front for MS and try to have their MS/XML accepted as a standard. ECMA does not 'approve' standards."

Tiger99 called me a troll for my efforts... I pouted :(

"Ecma International is an industry association founded in 1961, dedicated to the standardization of information and communication systems."
http://www.ecma-internation al.org/default.htm

In my book, an "industry association" is a lobby group.

"BSA is the voice of the world's commercial software industry and its hardware partners before governments and in the international marketplace."
Does the BSA sound like a lobby group?
http://www.bsa.org

Using the ECMA is just MS's way of working the 'U' in FUD.

[ Reply to This | # ]

Ethics
Authored by: monoman on Tuesday, November 29 2005 @ 04:07 PM EST
A different aspect of this situation is the ethics of doing something wrong, just because the victim promises not to sue. Personally, Microsoft's covenant could be "We'll never, absolutely never, sue you. Period." and I still wouldn't touch their schemas. Those schemas have a license, and breaking the license, even if they won't sue me for it, is still wrong. An extreme example to try to drive my point: somebody could ask me to hit him, and sign a paper claiming he's giving his full permission to be hit. I still wouldn't hit him. Besides, even with his permission it could still be illegal to hit him (or kill him, like in euthanasia). BTW, the license to the office 2003 xml is here.

[ Reply to This | # ]

MS Office XML vs ECMA Office XML
Authored by: brc on Tuesday, November 29 2005 @ 04:08 PM EST
I'm just wondering a little about how the timing of things will work...

Microsoft is putting forth their Office XML to ECMA, so it can supposedly be
reviewed and approved in some format. Presumably, a community review could
cause the format to change in some way before it's finalized.

At the same time, Microsoft is busy developing Office 12, presumably to whatever
Office XML they currently have defined.

Office 12 is due out... when?

So.. what if after review, MS Office XML changes as it is reviewed/accepted by
ECMA - I assume MS is not stopping development of MS Office 12 until this
"standard" is approved/ratified/whatever by ECMA. Or is ECMA
acceptance just a rubber stamp of what MS defines, without any community input
into the format?

If someone like Mass. accepts the ECMA "standard" version, but Office
12 is using the version prior to ECMA acceptance, and they end up being
different, what does that mean?

Am I missing something completely?

[ Reply to This | # ]

Patents (again)
Authored by: Nick_UK on Tuesday, November 29 2005 @ 04:47 PM EST
I still can't see how MS xml is 'xml' if they have
patented it - if they have, then it isn't xml. If it is
pending, then they have no right to say what they do.

Basically, as usual, MS xml isn't an open standard at all
- and never will be, as far as I am concerned; it isn't
in their nature.

Nick

[ Reply to This | # ]

The Horror
Authored by: ChefBork on Tuesday, November 29 2005 @ 05:34 PM EST

The Microsoft covenant not to sue is a grammatical horror that defies precise understanding. The phrase "patent claims necessary to conform" to the specification ignores the reality that software is written in code, not in patent claims. No patent claim is "necessary to conform to technical specifications." Once that error is recognized, the sentence dissembles into gobbledygook. I have attempted to work with the phrase nonetheless.

Marbux, I'd like to thank you for your succint analysis of this mess. I guess Footnote 2 (above) says it all.

I now feel much better about porting all my documents to OpenDocument using OpenOffice. The Commonweath needs to see this analysis to realize that they shouldn't wait on further Microsoft vaporware.

---
If two heads are better than one, then why are liars two-faced and being of two minds indecisive?

[ Reply to This | # ]

Actually, Little Miss Presumption
Authored by: Anonymous on Tuesday, November 29 2005 @ 05:36 PM EST
The company that I work for - you know, with a job that pays for my mortage and
my kids' dental work - is perfectly happy with this covenant, and we're pressing
on with an implementation for embedded devices as fast as we can, because it's
the best that we're going to get, and it's good enough.

It may not be good enough for you, but then last time I checked, you're "a
journalist with a paralegal background", not a software developer, and so I
don't really see what special insight you bring to the issue of whether
"[anyone] will dare to touch their XML", or why you feel qualified to
speak for the rest of us.

[ Reply to This | # ]

Steven J. Vaughan-Nichols: Microsoft Drops the Office Open Standard Ball
Authored by: dwheeler on Tuesday, November 29 2005 @ 06:28 PM EST
Here's a related article: "Microsoft Drops the Office Open Standard Ball" By Steven J. Vaughan-Nichols, November 29, 2005, eWeek. It argues that "Microsoft Corp.'s open-standard Office XML format announcement may have proved to be a dud." I honestly hope that it does NOT turn out to be a dud in the end, but there are clearly some very serious shortcomings in what has been done so far.

[ Reply to This | # ]

These new times our only hope...
Authored by: dateman on Tuesday, November 29 2005 @ 06:48 PM EST
I firmly believe that this is the usual stunt from Microsoft to pre-announce the
solution to head off defections (as per the vapourware note)...BUT

These are new times we are living in and while MS has done this before, they
have not tried to do it in the full light of the Internet age. Just think that
if this happened back in the days of Windows 95 or Office 97, I wouldn't have
seen anything in Australia about some technical decision regarding using ODF in
MA.

Now the world is watching MS, and analysing, and piking at every word they say
and monitor every thing they do via a million blogs liek this one. Their only
recourse now is to buy politicians, which will also become harder as the
politicians finally realise the internet is also watching them...

---
Dav1d

[ Reply to This | # ]

Schemas are vastly over-rated
Authored by: Anonymous on Tuesday, November 29 2005 @ 07:23 PM EST
Schemas tell you only about some of the coding and structure of a document.
Schemas tell very little about the real meaning of a particular combination of
data objects within a document.

A schema can allow the use of binary blobs (aka CDATA). Nothing is known about
CDATA, not coding, not structure, and not meaning.

But even when coding and structure are fully known, it is very difficult to
fully and completely define the meaning of an interacting set of data objects.

Perhaps I can convey some sense of this by telling a story.
Some years ago, I was involved with a project to reverse engineer the first
LaserJet printers. The goal was to make a compatible printer. It took years to
get to the point where we would always print the same thing as a real LaserJet
printer. After the first month, we never had any problems at the printer
equivalent of the schema level. The problems were much deeper and more subtle
and involved hidden rules which were triggered by interactions of different
combinations of objects. A typical hidden rule was something like this:

-If there is a font over 18 points on the page
-And if there is some landscape mode text on the page
-And if the right margin was ever changed from default (even if changed back to
default later)
-Then change the line space rounding rule to round down to the nearest fraction
of a pixel, instead of rounding up as usual.

This example is arguably a bug in the LaserJet printer.

But the lesson from this is that even when a schema is completely open and
perfectly followed there is ample opportunity to construct a word processor so
that it contains hidden rules which may be triggered by many possible
combinations and permutations of objects.

In this kind of situation, a schema is nearly useless. Even the existance of an
xml format as opposed to a binary format is of no practical benefit. Open
Office long ago achieved the equivalent of schema level compatibility with
Microsoft Word doc files, despite their binary format.

Lack of a schema is not the source of interoperability problems with Microsoft.

It is not the format of the data that is the problem. It is the meaning of the
data. And Microsoft has the ability to hide this and to make it as complex as
desired, even though the documents may be formally valid according to a schema.

bertd@bellsouth.net

[ Reply to This | # ]

Will Not Sue -- Very Weak
Authored by: Anonymous on Tuesday, November 29 2005 @ 08:02 PM EST
What is this "not to sue" construct? It sounds very weak to me. Why
not grant a straightforward license? Surely there are other sanctions besides
suing. For example, some MS product may be licensed "will not be run on a
PC having also installed Product X" where Product X is from Company Y which
would ordinarily be sued, but because of the "will not sue" is not
sued. Or the whole Company Y may get different prices for some products. Also,
is the "will not sue" binding -- could MS sell the rights and let the
buyer then sue?

[ Reply to This | # ]

The MS Covenant Not to Sue: My Message Wasn't Mixed
Authored by: lrosen on Tuesday, November 29 2005 @ 08:26 PM EST
Simon Phipps wrote: "Together, these six problems seem to be show-stoppers for open source, no matter how positive Brian Jones or even Larry Rosen may feel about it all..."

I'll try again to explain how I feel about it all. :-)

There are two different aspects of "open standards" that we need to distinguish:

1. The aspect of open standards I usually worry about most (probably because I'm a licensing lawyer) relates to the licenses for the patented and copyrighted technology embodied in the published standards: As long as the licenses are broad enough, they won't prevent people from freely implementing the standard in an open source or proprietary application. As long as we have the right licenses, the standard from my perspective is open and free. That's why I like the Microsoft covenant not to sue. In effect, it conveys a completely FLOSS-companible patent license to implement a particular standard that will be published eventually by Ecma.

2. The aspect of open standards that Simon's blog focuses on, and that is the main topic of PJ's article, relates to the Ecma process by which that standard evolves and is published: Is that process open enough to ensure that a consensus standard will ultimately be created, or will Microsoft dominate and dictate that standard (as it unfortunately has the reputation of doing from time to time)? That's why I suggested in my published statement about Microsoft's covenant that "It is important for open source companies to participate in this standardization effort, so that we can ensure that the specification for the standard is itself developed in an open way. If we do that, I'm confident that 'conforming' software products will evolve to meet customer needs worldwide without Microsoft having to dictate the scope of that conformance."

I completely agree that Ecma's processes and patent/copyright policies need to be updated. I'll sing from PJ's hymnal and we'll both object to Ecma's current willingness to accept RAND terms for some of their standards. We should join Ecma and vote to change those processes and policies to make them more friendly to free and open source software.

But let's be fair. This covenant from Microsoft isn't RAND. It is free and open.

We need to acknowledge that Microsoft has given us more with this covenant than it ever has before, even while we join Ecma and convince it to change its processes and policies. Simply grousing about Microsoft's reputation and fearing bad behavior from that company isn't a fair response to their recent move. Instead, let's challenge them and ourselves to cooperate in Ecma to create a standard that works for us.

One more point: Even open and free standards need to compete with other standards on the merits. So my favorable comments about Microsoft's covenant shouldn't be taken as an endorsement of their version of open documents over those of competing standards. Let the best technology and marketeer win....

/Larry Rosen

[ Reply to This | # ]

Article on register.co.uk - MA reverses decision
Authored by: om1er on Tuesday, November 29 2005 @ 09:38 PM EST
Just saw this article. It looks like what Microsoft did was "good enough."

Microsoft Opens Standards Massachusetts: ElReg

I haven't looked for verification elsewhere.

[ Reply to This | # ]

Conforming parts only...
Authored by: jacks4u on Tuesday, November 29 2005 @ 10:07 PM EST
I think I know what Microsoft(r) wants with this wording.

If Microsoft follows it's embrace and extend tendencies, then I'd expect 2
versions of the office XML - one "open", the other, an extended
version.

The wording of their covenant would cover implementations that use only the
office XML standard.

If, on the other hand, Microsoft extends the XML schema, "to accomodate
innovation" but does not make that extension part of the standard, and
perhaps pattents that proprietary portion, then misguided developers wishing to
implement the "extended" portion will run into trouble, and
potentially face pattent litigation.

Take, for a hypothetical instance: If the Office open XML covered only text
formatting, Microsoft could implement an internal system for handling embedded
immages. But if that is not covered by the standard, any developer wishing to
embed images in the same way Microsoft did, then they could face litigation.

Furthermore, it seems possible to implement the standard completely, and still
not be compatable with an "embrace and extend" schema.

Forgive me if i restate information from the article, as I did not completely
read it before opening my mouth! (insert foot, if applicable)



---
I'm not a Lawyer, this is my opinion only. I may be wrong, but I don't think so!

[ Reply to This | # ]

Everyone that has trusted Microsoft has regretted it
Authored by: kawabago on Tuesday, November 29 2005 @ 10:10 PM EST
The Gates gang routinely shafts everyone once they have stolen what they needed.
The Office XML schema is just another Microsoft scheme. Anyone who implements
this scheme will come to regret it.


---
TTFN

[ Reply to This | # ]

Wherefore art thou, SCO?
Authored by: belzecue on Wednesday, November 30 2005 @ 04:29 AM EST
How many headlines has it been since we had a juicy SCO article? :-) I had to
pinch myself just now to remind me of that fact.

They must be loving this respite from being under the microscope. Or is Darl
annoyed: The only thing worse than being talked about is not being talked about.
"But, but... I still have the big book of press clippings from SCOForum
2003! We are still relevant in 2005. Really really relevant!" :-)

That Groklaw itself would eventually outgrow SCO's petty infamy -- that must be
the ultimate insult for the Gang Who Couldn't Shoot Straight :-)

Just joking. Of course, we'll get our next SCO fix as soon as there is some
action in court. But it will now be just one tasty morsel on a wide bench full
of juicy dishes prepared by PJ.

It's nice to acknowledge that Groklaw has now steered into deeper waters,
heading for the wide horizon, with SCO's little mini-destroyer-class vessel
bobbing up and down in Groklaw's wake, trying desperately not to get swamped as
they holler, "... really, really... relevant..!" :-)

And we owe it all to you, Darl. Thank you. Thank you very much.

[ Reply to This | # ]

It's not mixed
Authored by: webster on Wednesday, November 30 2005 @ 04:34 AM EST

M$ does not want any truly open format.

If they can not prevent one, they will delay one as long as possible.

Pretending to cooperate with implementing their own open format is a tactic of
delay.

Submitting thier format to standards bodies is a tactic of delay.

They could dedicate, create or adopt a truly open format today, on their own and
have it universally accepted.

They could implement a truly open standard in two days if not hours. The legal
language, the PR statements, the code, filters are all available Now.

It would be easier for them to implement ODF than their own formats. Easier for
everybody else, too..

They are playing for time. They are jerking us around.

We understand them. Would you share the Golden Goose?

---
webster
>>>>>>> LN 3.0 >>>>>>>>>

[ Reply to This | # ]

List with MS standards Dirty Tricks
Authored by: Winter on Wednesday, November 30 2005 @ 07:45 AM EST

It seems to me that we can help those that fight MS standards traps by compiling a list of dirty tricks. Here is a first try from what I remember and have seen on GL:

(sorry, currently no time to look up the links)

  • HTML
  • Kerberos standard with proprietary expansion
  • Ecmascript, MS' own Javascript ECMA standard which MS didn't conform to
  • Java, MS lost the fight
  • ODBC API (see here)
  • ActiveX standardization (see here)
  • RIFF (WAV) is just a convoluted and subverted AIFC with byte order switched

Rob

---
"news is what someone, somewhere, wants to
suppress; everything else is advertising" Anonymous Journalist

[ Reply to This | # ]

Picking and choosing
Authored by: The Cornishman on Wednesday, November 30 2005 @ 08:16 AM EST
I found this quote from Marbux's summary a little worrying:

If Microsoft truly desires to see Office Open XML widely used by other developers, Microsoft must allow them the freedom to add and subtract from the Office Open XML specification to accommodate the features of their own applications and to innovate.

I'm guessing that for the purposes of discussion we are equating the specification with the forthcoming (but as yet over the horizon) ECMA Standard. How is adding and subtracting from the specification [standard] different to what Microsoft developers did with the HTML "extensions" to accommodate the "features" and "innovations" in Internet Explorer, and for which we execrate them all the time?

I submit that when FOSS innovations are made, they need to be incorporated into a new version of the standard. Sauce for the goose is sauce for the gander.

---
(c) assigned to PJ

[ Reply to This | # ]

In XML, conformant is a technical term....
Authored by: Anonymous on Wednesday, November 30 2005 @ 10:11 AM EST
that usually means a given implementation of XML conforms to the published
Schema for that implementation. So conformant XML is that XML which, when
parsed against the appropriate schema, is successfully parsed, that is, adheres
to the requirements defined by the schema.

If that isn't too circular an explanation - I'm not a parsing expert, but I work
beside some of them.

Jr

[ Reply to This | # ]

Are we missing the point here?
Authored by: Anonymous on Wednesday, November 30 2005 @ 04:14 PM EST
We are discussing and analyzing this issue as geeks (technical or legal), when
this is really a political problem. We would do well to focus on the question
“What does MS want?” because, as someone once advised about the USSR: “The only
thing you can be sure of is that they will act in their own best interest.”

So, what does MS hope to accomplish with all this? I think the answer is
obvious: they want things to stay just as they are. With Office earning what,
$20B/year, at 90% profits, who wouldn’t want it to continue!

There are two obstacles that threaten the status quo for Office. First,
governments and other customers are beginning to demand that their office
software adhere to formal standards, just like many other aspects of their
operation does. The need for this is crystal clear, everyone understands it
intuitively and no one can argue against it without looking like a fool. Second,
Office XML (docx) does not yet occupy the position of de facto standard, but as
soon as people upgrade to Office 12, it will. And MS knows that a de facto
standard trumps a formal standard every time. So, as long as MS can blow smoke
in the formal standard department, enough for the pols who make the rules and
the managers who set the purchasing policies to claim adherence to a standard in
choosing Office, MS is golden—quite literally. And that’s all this is.

It’s not a legal move. As Marbux has pointed out, no one knows for sure what
this covenant means. It means whatever you think it means. I can’t see that MS
intends to fight this battle in a courtroom. They won’t use this to sneak up and
sue to prevent someone from reading and writing Office XML (docx) files. They
don’t care, because compatibility will only help docx gain de facto standard
status. Hasn’t anyone noticed that OOo 2.0 already reads and writes Office 2003
XML without so much as a C&D from MS? MS is not looking to the courts to win
this.

It's also not a move toward a meaningful standard, because that's the other
piece of the status quo that they need to maintain. MS knows that a formal
standard necessarily mean anything as long as MS defines it in their code, just
as they do now. Such an impotent standard means that no ISV will implement their
Office support tools from the standard. They will instead simply license the
libraries and tools from MS, because that will give them the fastest, surest way
to market, and any OSS alternatives (based on the standard) won’t work quite
right (I wonder why?). MS is not afraid of ISVs riding their coattails, as long
as they have to buy a license to do so. MS will settle for a formal standard if
they have to; they will never willingly submit to (much less promote) an open
standard.

The best thing the OSS community can do is to push for meaningful open standards
(educate the media and the decision makers; expose back room deals) and promote
OOo and other open tools, because without viable market share, all the virtue
and truth in the universe will simply be tilting at windmills.

<Acknak

[ Reply to This | # ]

The MS Covenant Not to Sue: Sending a Mixed Message
Authored by: Anonymous on Wednesday, November 30 2005 @ 06:22 PM EST
I was interested by this phrase in particular: "Microsoft irrevocably covenants..."

"irrevocably" to me implies that there is an "indefinite" validity to the statement. However, I was trying to check up on passport requirements to the USA and found this on the USA embassy web site:

``An "indefinite" validity visa is no longer valid for travel to the United States...or apply for a new B-1/B-2 visa.''

Does this definition of "indefinite" to not mean "forever" hold for all American institutions?

[ 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 )