As you know, there is an April 1 deadline to register comments regarding the Massachusetts Open Formats proposal. We thought it would be helpful if Marbux explained some issues that he believes come into play. It's quite a long article, because we included information for the public and for lawyers, so pick and choose the parts you are most interested in, according to your circumstances. Section 4 is for those mostly wishing to understand Microsoft's "Patent License" and how it impacts on the Open Format proposal. Remember that Marbux is now retired, and he is not providing legal advice. For that, you need to hire your own attorney. For those of you who want the quick version, I believe it can be summed up in this paragraph from the article: "Having learned from its bad press, Microsoft no longer bluntly prohibits licensing to open source software developers, but instead includes license terms that are incompatible with software developed under an open source software license. It is troubling that government officials would fall for such tactics and proclaim that such licenses are 'nondiscriminatory' and 'open,' as Massachusetts has done.
The Great Massachusetts Legal Donnybrook
~by Marbux
Contents
- The Great Massachusetts Legal Donnybrook
- Background
- Of BillGates and the Information Highway
- Dissecting Microsoft's 'Patent License'
- International Treaty Obligations
- Endnotes
[T]he only
principle recognized—if it can be called a principle—was akin to that
recommended to the traditionary Irishman on his visit to Donnybrook
Fair, "Wherever you see a head hit it".
—Walter Bagehot, The English Constitution (1867).
World Trade Organization proceedings could flare from a tinderbox
legal situation involving eGovernment computer file formats, Microsoft
Corp., and the Commonwealth1 of Massachusetts, one of the 50 state government subunits of the United States.
The situation suggests a legal fire storm may erupt. What is
potentially at stake has thus far escaped notice in the major media:
whether the U.S. portion of the software infrastructure of the
world-wide digital Information Society will be constructed: (i) based on open standards
that stimulate competition among software developers; or (ii) based on
proprietary software standards that exclude competition through software patents and other types of intellectual property subject to licensing restrictions and royalty payments.
Microsoft has persuaded Massachusetts officials to approve
specifications for its Microsoft Office software file formats as
acceptable for eGovernment use, even though they are encumbered by
restrictive patent licensing requirements that exclude competitors from
using the Microsoft file formats. See Dissecting Microsoft's 'Patent License'
section below. Competitors are thus effectively precluded from bidding
against Microsoft or its suppliers for any Commonwealth contract
specifying use of Microsoft's software file formats.
One might question whether taxpayers' interests are well represented
by adopting a government software procurement standard that has the
practical effect of foreclosing competition in bidding on government
contracts, particularly when quality software is available for less
money. As explained by Microsoft's Chief Software Architect more than a
decade ago:
O[n]ly immense loyalty to a product at the end user
level prevents corporations from using their buying power to force a
cheap site license. When the US Government DOD moves software
procurement to a separate contract, the price per user of software will
end up around 0. Why shouldn't some small organization price their
product at say $1M for the entire US Government for all time? We would
if we were small and hungry. Fortunately most organizations don't force
cheap software on their end users.
Bill Gates, Microsoft Corp., Challenges and Strategy memorandum (May 16, 1991).
Mr. Gates obviously recognized that standards established through
government purchasing decisions tend to drive software acquisition
decisions in the private sector as well. While that was true in the
pre-World Wide Web days of 1991, the more recent expanded
internetworking of eGovernment and eCommerce absolutely requires file
format compatibility. Open file format standards are therefore crucial
to software competition in the networked environment, including the
eGovernment software procurement environment.
However, Massachusetts officials' discretion to approve the
specifications for the Microsoft file formats is at least arguably
foreclosed by the Agreement on Government Procurement,
an international treaty to which the U.S. is signatory. Likewise, it
appears that the Commonwealth's discretion will later be curtailed when
involved goods and services become subject to near-identical provisions
of the North American Free Trade Agreement. Those topics are discussed at length in the section below titled International Treaty Obligations.
While the Agreement on Government Procurement was not decisive in
the issues involved, Massachusetts was the losing defendant in the only
Supreme Court case discussing the Agreement on Government Procurement.
The court made clear that it was the relevant complaints filed with the
World Trade Organization that were driving the court's decision that
states' rights had to give way to the federal statute adopting the
treaty.2
The Massachusetts initiative is apparently a trial balloon sent
aloft by a large group of federal and state government agencies working
together to implement the Electronic Signatures in Global and National Commerce Act of 2000 ("E-Sign"), 15 USC §§ 7001 et seq. Federal, state, and local coordination is largely accomplished through the auspices of the National Electronic Commerce Coordinating Council.3
[ Contents ]
Massachusetts announced approval of the Microsoft Office 2003 XML
Reference Schemas as an approved specification for file formats used in
Commonwealth eGovernment as part of its draft Enterprise Information Technology Architecture. See MA Posts New Version of Open Formats - Requests Comments, by Pamela Jones (Groklaw report). Public comments are required by April 1, 2005, and may be eMailed.4
According to the Massachusetts Information Technology Division ("ITD"),
"[t]he reference schemas are licensed by Microsoft for use in office
applications under terms that meet the Commonwealth's definition of
Open Format."
For an earlier draft of the Commonwealth's architecture, that definition was provided by the January 13, 2004 ITD Enterprise Open Standards Policy:
Open Standards: Specifications for systems
that are publicly available and are developed by an open community and
affirmed by a standards body. Hypertext Markup Language (HTML) is an
example of an open standard. Open standards imply that multiple vendors
can compete directly based on the features and performance of their
products. It also implies that the existing information technology
solution is portable and that it can be removed and replaced with that
of another vendor with minimal effort and without major interruption. …
However, those criteria had changed a year later, when Massachusetts Secretary of Administration & Finance Eric Kriss informally announced new criteria during a speech (transcript and audio) delivered during a meeting of the Massachusetts Software Council, an industry trade association.
Secretary Kriss summarized the new criteria used for inclusion of computer file formats on the "approved" list:
"Open Formats" are specifications for data file
formats that are based on an underlying open standard, developed by an
open community and affirmed by a standards body; or, de facto
format standards controlled by other entities that are fully documented
and available for public use under perpetual, royalty-free, and
nondiscriminatory terms.
(Italics added.) Whereas previously only open standards were
permissible, proprietary standards would be permissible under the new
criteria, so long they were available under "perpetual, royalty-free,
and nondiscriminatory terms."
By contrast, the European Interoperability Framework for Pan-European eGovernment Services v. 1.0 (PDF, November, 2004)5 defines "open standard" as follows:
Use of Open Standards
To attain interoperability in the context of pan-European
eGovernment services, guidance needs to focus on open standards. The
following are the minimal characteristics that a specification and its
attendant documents must have in order to be considered an open
standard:
- The standard is adopted and will be maintained by a
not-for-profit organization, and its ongoing development occurs on the
basis of an open decision-making procedure available to all interested
parties (consensus or majority decision etc.).
- The standard has been published and the standard
specification document is available either freely or at a nominal
charge. It must be permissible to all to copy, distribute and use it
for no fee or at a nominal fee.
- The intellectual property – i.e. patents possibly
present – of (parts of) the standard is made irrevocably available on a
royalty-free basis.
- There are no constraints on the re-use of the standard.
One might therefore question why Massachusetts finds it necessary to
allow Microsoft to control one of the Commonwealth's "open formats,"
given that the European Community did not.
Secretary Kriss also announced that Microsoft had agreed to modify the patent license
for Microsoft Office 2003 XML Reference Schemas, the specifications for
the Microsoft Office file formats, to make that license compliant with
the revised Massachusetts criteria, which was adopted specifically to
allow Microsoft's proprietary file formats to be required in bid
specifications. See Microsoft Bends for the GPL to Qualify as Open Format in MA, by Pamela Jones (Groklaw report).
During the same speech, Secretary Kriss announced that the
Commonwealth had approved the OpenDocument XML file format schema,
which is publicly available in its entirety without license
requirements or fees. See previous Groklaw article, The future is open: What OpenDocument is and why you should care,
by Daniel Carrera. Microsoft was invited but declined to participate in
developing the OpenDocument standard, despite the fact that several of
its competitors have contributed to the effort.
Pouring fuel on the fire, Secretary Kriss further stated that the
Microsoft Office XML formats, "like DOC files, will be deemed to be
Open Formats because they will no longer have restrictions on their
use." Informal Comments on Open Formats (Massachusetts state website).
However, it appears that the Microsoft .DOC file format remains a
trade secret, except to the extent it can be inferred from the Office
XML Schemas. Moreover, Massachusetts has given no indication that other
software companies will be given equivalent bidding advantages. For
example, Canadian software development company Corel Corp. produces
WordPerfect Office, which has produced files in XML file formats for
many years. However, there is no indication that Massachusetts
considered allowing Corel to compete for Commonwealth software
contracts.
The standard adopted by Massachusetts allows Commonwealth agencies
to choose between specifying software using the OpenDocument or
Microsoft XML schemas. Because Massachusetts is setting standards not
only for itself but also for those who wish to exchange documents with
Massachusetts government agencies, the effect is to establish
Microsoft's XML and DOC file formats as the de facto standard for bidding on Commonwealth software contracts.
It is, after all, a software market that Microsoft already
dominates. The Massachusetts initiative thus grants Microsoft a unique
bidding advantage, unless Commonwealth and local government bodies in
Massachusetts are willing to insist that citizens, businesses, and
government agencies acquire and use new software to communicate with
the Commonwealth and its subdivisions, which seems a doubtful
proposition given the Commonwealth's present stance.
Massachusetts officials may believe that by approving the Microsoft
Office XML file formats they are saving citizens and businesses who
wish to interact with Commonwealth computer networks the expense of
switching to new software. However, it should be recognized that
Microsoft's XML formats are only available in Microsoft Office 2003. It
thus appears that citizens and businesses will be forced to acquire new
software in any event, except for those who have already acquired the
2003 version of the Microsoft Office.
A cynic might therefore view Microsoft's eagerness to have
government approve of its XML file formats as Microsoft recognition
that such approval would force Microsoft's customers—and government
offices—to purchase expensive upgrades for Microsoft's software, the
very sort of "vendor lock-in" the Commonwealth is striving to overcome. See Massaschusetts Enterprise Open Standards Policy ("[o]pen systems and specifications are often less costly to acquire, develop and maintain and do not result in vendor lock-in").
At least so far as can be determined from the Commonwealth documents
posted to the Massachusetts.gov web site, there has also been no
recognition that approval of the Microsoft file formats can have the
effect of locking the Commonwealth into supporting Microsoft Office and
Microsoft Windows in the future. That is because, as Sun Microsystems
has noted:
Documents saved in Microsoft’s XML document format
can still contain XML encoded binary data (e.g. OLE objects, VBA
macros) which are dependent upon Office 2003 and Windows[.]
Sun Microsystems, Sun Microsystems Comments on the document ENTR/02/21-IDA/MIDDLEWARE-XML: “Comparative assessment of Open Documents Formats Market Overview” (PDF, pg. 4).
For that reason, to the extent that the Commonwealth accepts and
processes electronic XML documents generated by businesses and citizens
using Microsoft Office 2003, the Commonwealth will thereby be locked in
to use of Microsoft Windows and Microsoft Office 2003 in order to
retain the integrity of such documents, which is a major requirement of
the Uniform Electronic Transactions Act being implemented by the
Commonwealth.6
Reportedly, Massachusetts initially declined to approve Microsoft's
Office file format specifications because of restrictive patent
licensing terms. The effect of that decision was that Microsoft Office
would not be able to compete in bidding for the Commonwealth's future
software procurement business, unless Microsoft agreed to support the OpenDocument XML file formats.
It also meant that Microsoft Office electronic document files generated
outside Massachusetts government would not be accepted by the
Commonwealth or its subunits.
But the change in Massachusetts criteria for what constitutes "open
formats" means that the Commonwealth will necessarily continue to buy
into Microsoft's strategy of maintaining proprietary file formats in
order to exclude competition.
[ Contents ]
It should be recognized that greater standardization in computer
file formats is, as a general matter, long overdue. As computers have
increasingly been networked, more and more end users have experienced
the frustration of receiving a computer file only to discover that they
lack the particular software needed to open the file.
That problem is compounded many times for major Information Highway interchanges such as government agencies. As Government evolves to eGovernment,
the need to standardize the types of files that are used and accepted
by government has become acute. The problem is serious enough just
considering the number of different computer programs that would be
required over the short term. But particularly for electronic public
records that must be maintained for very long periods of time, it is
simply unrealistic to expect government to cope with a multitude of
incompatible file formats and to permanently maintain all programs
necessary to retrieve and use a multitude of incompatible formats.
At the same time, uniformity in computer file formats is of crucial
importance. For example, one state government's computer networks do
not operate in isolation. Those networks must interoperate with those
of different government agencies, with those of the private sector,
with those on other continents. Therefore, all who are concerned with
construction of the Information Society's technological infrastructure—virtually everyone who will operate a networked computer within
their lifetimes—must be wary of attempts by companies to "own" that
infrastructure.
To illustrate, let's pretend that you live in the small city of Data
Gap, which is located in the wilds of Alaska. All that connects Data
Gap with civilization is a long public highway to Anchorage winding
through hundreds of miles of scenic mountains and canyons owned by the
government. There are only three automobile dealerships in Data Gap, so
most Data Gap residents drive BillMobiles, CorelMobiles, or
FOSSMobiles.
Bill is the founder and owner of the BillMobile Auto Company. Bill
has a near monopoly in automobile manufacturing and distribution, but
one day he notices that while the CorelMobile market share is still
dwindling, FOSSMobiles are beginning to gain market share in Data Gap.
But Bill is equal to the challenge.
Bill is not only the founder and owner of BillMobile Auto Co., he is
also its Chief Software Architect. He supervises creation of and
patents the software to operate an automated tollgate. Bill then
obtains from the Alaska Highway Department formal approval of his
patented software specifications as a standard for tollgate operation,
as well as permission to install the first of his brand new BillGates on
the Data Gap Scenic Highway.
Bill's new BillGate uses technology to determine what brand of
automobile is approaching and take corresponding actions. If the
motorist is driving a BillMobile, a BillGate allows unimpeded passage.
But if a BillGate detects a CorelMobile or a FOSSMobile, the gate slams
down and a team of automated lawyers jump out of the tollbooth spouting
reasons why the motorist can not legally pass through, blocking passage
with their bodies. Unless the motorist buys a BillMobile, the motorist
will not be allowed to pass. If motorists attempt to bypass the
BillGate, Bill will sue them for infringing his patent rights.
The residents of Data Gap who do not drive BillMobiles radio for
helicopters to carry them to Anchorage and—joined by a company that
distributes FOSSMobiles and by the Corel Auto Manufacturing Co.—sue
the Alaska Highway Department and Bill, seeking an injunction
overruling Bill's authorization to operate his BillGate on the
Data Gap Scenic Highway.
Bill's fleet of lawyers respond, bringing into court with them a
patent license that was publicly posted on the Internet allowing any
auto manufacturer or distributor to use the BillGate patented
technology to design and market their own tollgates if they comply with
the licensing restrictions.
Bill's lawyers argue that he has a valid patent and has made the
specifications for his patented software available to any auto
manufacturer on reasonable and non-discriminatory ("RAND") terms.
Therefore, it is simply a matter of his competitors' choice—the
lawyers argue—whether there will also be CorelGates and FOSSGates on
the highway, and the Alaska Highway Dept. was entitled to adopt his
software specifications as a standard and to approve his placement of
the BillGate on the public highways.
Bill's lawyers point to previous antitrust court rulings upholding
Bill's right to impose RAND terms on competitors who wish to license
one of his similar software creations, WinGate. They also cite court
decisions approving of RAND licensing terms when patented technology is
adopted by private standard-setting bodies composed of representatives
from competing companies.
If you were the judge, how would you decide this case?
By now, you have probably realized that BillMobiles are an analogy
for Microsoft's Office XML file format specifications, and FOSSMobiles
and CorelMobiles are respectively analogies for the OpenDocument and
WordPerfect XML file format specifications. Of course, the Data Gap
Scenic Highway stands for eGovernment, a publicly owned and maintained
section of the Information Highway.
Also by now, you have probably sensed a few problems with Bill's legal arguments, such as:
- It matters whether BillGates are located on a public highway or a private toll road;
- It matters whether the public benefits from adoption of privately-owned "inventions" as government standards; and
- The facts indicate that Bill may not be using his
patent right to profit from his BillGate invention; instead, he is
asserting his patent unlawfully7 to maintain and expand his monopoly in the automobile market.
With such principles in mind, we are now poised to review the patent license for Microsoft's Office 2003 XML Reference Schemas.
[ Contents ]
Note: The reader should understand that the author is
retired and no longer practices law. If you are evaluating whether to
agree to Microsoft's patent license, you should not rely on this
discussion and should instead consult a practicing attorney.
The patent license for the Microsoft Office 2003 XML Schemas
can be viewed on Microsoft's web site. What arguments does that license
create for Microsoft to use later? This review will be confined to
issues that might not leap off the page in a cursory review.
Major Structure
The license is structured to be read restrictively, in Microsoft's favor. At the end of the license, it states that:
"All rights not expressly granted in this license are reserved by Microsoft. No additional rights are granted by implication or estoppel or otherwise."
(Emphasis added.) This is not the customary "all rights reserved"
phrase more commonly encountered. A short translation of the language
quoted is in order: Those two sentences mean exactly what their plain
words say. If you can not find words in the license explicitly stating
that you have the right to do something, you don't get that right.
Microsoft keeps that right; it is not yours. Forget everything but what
the words of the license actually say. Do not assume that because a
related right is granted, that a further right is necessarily implied.
In pseudocode, the default is:
IF NOT EXIST {explicit grant of right} DO SET Var{rights}=0
Do not be influenced by what you believe is fair, just, or necessary.
Specific Issues Raised by Microsoft's Patent License
- No integration clause. There is no language
stating that the patent license comprises the entire agreement between
Microsoft and the licensee. Microsoft's lawyers know how to write an
integration clause. See e.g., this closely-related license
("[t]his agreement and any amendments to it, and the terms for
supplements, updates, Internet-based services and support services, are
the entire agreement for the software"). That omission raises a warning
flag that there may be other documents relevant to the patent license's
requirements and interpretation.
The failure to include an integration clause leaves ambiguity
whether other documents can be used to interpret the agreement.
Typically, lawyers will advise a client who is a potential licensee
that an integration clause should be included, all relevant language
should be included in a single document, and to the extent that other
documents may be part of the agreement, they should at the very least
be attached as annexes and be expressly described in the main agreement
so that their role is clear and the number of pages accounted for.
Pages should be numbered consecutively throughout the entire assembled
document. For an internet-based contract, the entire document should be
contained in a single unalterable file, such as a file in Portable
Document Format.
Even when an integration clause is included, it is wise to acquire
hard copies not only of the entire agreement but also any relevant
advertising, earlier drafts, public statements, personal notes, and the
like. Lawyers typically advise their clients to do so, and deliver the
entire collection for your lawyer's review (and safekeeping) before you
agree to the license. Generally speaking, courts will not honor
integration clauses if it decides that language in the agreement is
vague or ambiguous. It is not possible to anticipate every context in
which a contract dispute might arise, and therefore what seems clear
and unambiguous in one context may be easily challengeable in another
context. If the courts decide to look beyond the four corners of the
license itself because of vagueness or ambiguity, the normal focus is
on determining the original intent of the parties. Accordingly, the
associated materials should be preserved as potential evidence.
In this particular situation, we know from Secretary Kriss's speech
that there was an earlier version of the agreement that was different.
We also know from the Wayback Machine that there were other documents
associated with the earlier version of the patent license including a
Frequently Asked Questions ("FAQ") document that apparently has no
current counterpart. There is also at least one separate copyright
license, discussed below, as well as a click-through copyright license
for an associated software development kit.
With the lack of an integration clause and a mushrooming number of
associated documents, with no visible end to related documents in
sight, and with the key legal documents existing only in editable HTML
form, were I still practicing law and the conditions of relying on the
licenses important to my client I would advise at this point, without
proceeding further, that it would be unwise to agree to the license.
Only an integration clause would provide Microsoft's lawyers with the
necessary incentive to get all relevant documents into a single file.
At this point of the review it matters not whether the mess is due to
deliberate obfuscation or simple sloppiness. It is an unacceptable
situation.
- No license for schemas themselves. The patent
license governs only software necessary to implement the schemas
("Licensed Implementation") and does not license use of the schemas
themselves. License language disclaiming any right to imply terms in
the license means Microsoft might later argue that a separate license
is also necessary to use the schemas.
- No grant of copyright included in patent license.
While expressly claiming that it may hold relevant copyrights, no
license for copyrighted material is granted in the patent license. Only
patent rights, not copyrights, are granted in this document. See point b. The patent license states:
As described in this document, the technical specifications for the schemas include rights under copyright to make reproductions and to display and distribute those reproductions, subject to certain terms and conditions.
So now we know there are not only schemas but technical
specifications for them as well. We have also been given legal notice
that there is a copyright claim to the technical specifications.
Moreover, the patent license does not state that there are no
copyrights involved with the schemas themselves. Therefore, to the
extent that the schemas are subject to a claim of copyright, the
language reserving to Microsoft all rights not specifically granted
potentially blocks any implied copyright license for the schemas. There
is mere silence, and under the major structure of the patent license,
silence means rights that Microsoft has reserved.
Microsoft's failure to identify in the patent license precisely what
copyrights are involved with the Schemas themselves is therefore
troubling. See e.g., Gates Rubber Co. v. Bando Chemical Industries Ltd.,
9 F.3d 823, 28 USPQ2d 1503 (10th Cir. 1993) ("[a]lthough processes
themselves are not copyrightable, an author’s description of that
process, so long as it incorporates some originality, may be
protectable"). Note also, as discussed below, that the schemas
patent license requires precise implementation of the schemas
specification and therefore literal copying of at least portions of the
schemas themselves. Copyright infringement for unlicensed copying is a
plausible legal theory to be employed later by Microsoft against
licensees and end users.
Agreeing to the patent license and relying upon it to develop
software thus raises a concern that Microsoft may later employ a claim
of copyright infringement as a weapon against those developers who rely
on the schemas, particularly should it be proved that the developers
made any copies of the schemas or excerpted portions not falling within a valid fair use defense.
The patent license also states:
Copies of the technical specifications for the
Office Schemas, which include an associated copyright notice and
license, can be found here.
However, there are no such documents at the linked web page. Update:
As of March 23, 2005, some additional documents have been posted to that
web page. However, there is still no "specification" link and if there were, there is no way of knowing whether it would be the
original document that had been linked. Again, this is a
show-stopper. The patent license incorporates another document by
reference giving a specific hyperlink to that document. The document is
not there. That raises a likelihood that the reason it is not there is
that it was removed, and may have been edited in the meantime. Therefore, there is
potential for later disagreement over precisely what version of a
defectively referenced document is intended.
There is, however, a link at that location to Download the Word 2003 XML SDK. That took me to yet another web page.
From the language on that page, it appears the relevant copyright
license might be in the Software Development Kit, a downloadable
executable file in Microsoft Installer (MSI) format.
I downloaded that file to my Windows XP system and launched the
installer. That presented me with a click-through license for the SDK.
It is long and a diversion from the patent license itself, which has
sufficient problems that there really is scant need to extensively
critique the Word XML SDK license.
Any free and open source software ("FOSS") developer will have to
forget about using the SDK in any event. Here is only one reason:
3. Distribution Restrictions. You may not:
- modify or distribute the source code of any
Distributable Code so that any part of it becomes subject to an
Excluded License. An Excluded License is one that requires, as a
condition of use, modification or distribution, that:
- the code be disclosed or distributed in source code form, or
- others have the right to modify it.
Both provisions seem squarely intended to block distribution of any
Distributable Code under an open source license. But at least we
finally have another link to what may be the copyright license we are
actually looking for, at another location:
The software consists of Microsoft development
tools, software programs and documentation. Notwithstanding anything in
this agreement to the contrary, the software does not include, nor does
this agreement cover, the WordprocessingML Schema, which consists of
schemas and technical documentation, installed by default in the
schemas subdirectory of c:program filesmicrosoft office 2003 developer
resourcesmicrosoftoffice2003wordxmlsdk. You may use the
WordprocessingML Schema solely in accordance with the terms and
conditions set forth for the Microsoft Office 2003 XML Reference
Schemas at: [Link].
There, we finally learn that—assuming we actually have the right copyright license—
Permission to copy, display and distribute the
contents of this document (the “Specification”), in any medium for any
purpose without fee or royalty is hereby granted, provided that you
include the following notice on ALL copies of the Specification, or
portions thereof, that you make:
Copyright © Microsoft Corporation. All rights reserved. Permission
to copy, display and distribute this document is available at:
[Link].
No right to create modifications or derivatives of this Specification is granted herein.
So is there yet another copyright license arguably in play? But as
it turns out, the linked web page is simply another copy of the license
just quoted. Is there yet another copyright license involved and merely
a defective hyperlink to it? The question can not be answered absent
clarification by Microsoft.
However, we can now definitively say that Microsoft is not granting
any right "to create modifications or derivatives of this
Specification." That would seem to be a deal breaker for any developer
attempting to adapt the specification to its own software, which almost
certainly will have features in addition to those in Microsoft's
software and therefore will require "modifications or derivatives."
- No commitment to delivering any future changes to
the schemas or right to develop software implementing them under the
same or more liberal license. Microsoft therefore reserves the
right to employ vendor lock-in tactics, for example by significantly
altering the schemas and future licenses for the altered schemas, and
to charge royalties for licensing a future altered version of the
schemas. There is no Microsoft commitment to allow the schemas to
evolve as free and open standards. In that regard, it is noteworthy
that the U.S. antitrust injunction requiring Microsoft to share its
APIs and file format specifications will soon expire unless renewed,
and that Microsoft has a long history of embracing, extending, and
thereby extinguishing standards. That it reserves the right to do the
same to its own "standard" is not reassuring.
- No identification of Microsoft patents involved.
While explicitly claiming to hold relevant but unidentified copyrights,
Microsoft makes no claim that it presently holds any relevant patents.
The license states only that "Microsoft may have patents and/or
patent applications that are necessary for you to license in order to
make, sell, or distribute software programs that read or write files
that comply with the Microsoft specifications for the Office Schemas."
Note: There may be others, but since this article was written, Microsoft's application for one relevant U.S. patent was reported, Application 20040210818,
filed in June, 2002, claiming a patent for invention of
"[w]ord-processing document stored in a single XML file that may be
manipulated by applications that understand XML." (Previously reported on Groklaw.)
The claimed invention appears to have been anticipated no later than 2000. E.g., Rys (David) McCuster weblog.
("Similarly, XML is an way to encode anything in a standard way, but
*what* gets encoded might be proprietary. In this case, the XML can
effectively clearly delineate something mysterious like this:
proprietary content … I could also put binary hex values in text
portions of an XML element").
It is also noteworthy that Corel WordPerfect Office, at least
since version 9 (released on January 27, 2000), used its "Publish to
HTML" feature to convert its native Rich Text Format ("RTF")-based file
formats to a single HTML file by embedding an auto-generated Cascading
Style Sheet in a style element of an HTML file, including embedding of
images in at least three image formats. HTML, like XML, is a subset of
SGML. On April 23, 2001, Corel released WordPerfect Office 2002
(version 10), which included its new "Publish to XML" feature, which
likewise could encapsulate both images and formatted text in a single
XML document based on the DocBook XML DTD.
Thus, the heart of the Microsoft patent application—filed
more than a year later in June, 2002 for embedding "rich" text
formatting and images in a single XML file—is highly questionable on
grounds of prior art and obviousness.8
In any event, it is only an application, not an issued patent, so does not impact the analysis given here. See also Oasis Cover Page, "Microsoft Files for Patents Related to XML Parsing and Word Processing."
Considering the severity of the restrictions imposed by the license
terms as well as the Microsoft rights reserved from the grant of rights
to licensees, this absence of specificity in identifying relevant
copyrights and patents prevents the developer, end user, and the
Commonwealth of Massachusetts from realistically evaluating whether or
not to accept the license as a reasonable restriction of rights for a
file format standard.
Microsoft is capable of disclosing such information. For example, in
drafting its patent license provisions for the Common Internet File
System communication protocol ("CIFS"), Microsoft was able to identify
specific patents involved in the license and identify them by patent
number.9 Such specificity
allows evaluation of the validity and applicability of Microsoft patent
claims when deciding whether to accept or approve the license.
This is not a trivial issue. If Microsoft in fact has no valid relevant issued
patents for the Office Schemas, the license is mere surplusage and
serves no function other than to create arguments for later use by
Microsoft. On the other hand, if Microsoft does have relevant patents
and copyrights, they should be disclosed to enable assessment of their
validity and the extent of their actual applicability. Such patents, if
they exist, may demonstrably be invalid because of obviousness or prior
art.
The fact that Microsoft has disclosed its patents in other licenses
but not in the present license process raises a concern that they may
not exist or are invalid. Microsoft may or may not be legally justified
in imposing all, some, or none of the restrictions the license requires
and it almost certainly lacks the patent rights on the entirety of the
code necessary to implement the schemas. Absent applicable and valid
patents and copyrights, Microsoft's legal right to limit alteration of
the schemas may not exist.
The Microsoft prohibition against writing to files employing the
Office Schemas (discussed below) raises related issues, of course, for
software developers who have already invested considerable effort to
maximizing interoperability of their software with Microsoft Office
through extensive engineering of file formats that Microsoft held
secret up until its belated release of the Microsoft Office 2003
Schemas. Such developers include Corel (WordPerfect), Sun Microsystems
(StarOffice), IBM (Lotus Smartsuite), OpenOffice.org (OpenOffice), and
KDE (KOffice). There are others.
Despite following such issues closely over the years, to my
knowledge Microsoft has never before objected to developers reverse
engineering the Microsoft Office file formats for software
interoperability purposes. Apparently, that situation has changed.
Microsoft suddenly suggests that it "may" have patent rights involving
technology necessary to interoperate with its new file formats.
Troublingly, Microsoft has also publicly stated that its schemas
incorporate code to maintain compatibility with its older file formats
for previous versions of Microsoft Office. Has Microsoft suddenly
acquired patent rights to implementing software that it never asserted
before during the many years in which its competitors reverse
engineered its file formats? Is a patent license from Microsoft now
necessary to continue marketing software compatible with older
Microsoft Office file formats? Or is Microsoft attempting to sweep a
mountain of prior art under a hazy assertion that it "may" have patent
rights to license that encompass the entirety of the schemas?
Microsoft's failure to disclose whether it actually holds relevant,
current, and valid patent rights to license as well as the extent of
such rights also raises the question of whether Microsoft is unlawfully
attempting to enforce—by assertion before a government procurement
standards-setting body—invalid patents or patent rights it does not
own.10
If Microsoft has no current patents or has patents that do not
encompass the entirety of the schemas, either a covenant not to sue or
a waiver of rights would have been far more appropriate than a botched
attempt at a blanket patent license.
- No identification of third-party patents. The
patent license mentions that third parties may hold patents involving
software implementations of the schemas and grants no rights in any
such third party patents. Is this not an admission that the entirety of
the specifications and schemas are not subject to Microsoft patent
claims? Again, the extent to which the schemas or the software
necessary to implement them are encumbered by patents is crucial
information in making an informed decision whether to adopt the
schemas. Such patents are even more crucial in regard to third party
claims, as the license conveys no rights regarding such patents
whatsoever. To the extent that Microsoft is aware of potential blocking
third party claims—for example, through its numerous recent "patent
peace" cross-licensing agreements with other major software developers—it should be required to disclose them as a condition of its schemas
even being considered as a government standard.
Note that Microsoft makes no commitment to indemnify those who rely
on its patent license should the schemas or implementing software later
be found to infringe third parties' patents. Indeed, Microsoft
explicitly disclaims such responsibility. Microsoft is, in effect,
providing only a promise not to pursue claims against its own licensees
who comply with the license. Absent indemnification, it is crucial that
Microsoft disclose what it knows about relevant third-party patent
claims the Licensed Implementations potentially infringe. Without such
disclosure, Microsoft explicitly shifts to its licensees all resulting
liability for its own failure to disclose what it knows about potential
"submarine" patents that might destroy the utility of its proposed
"standard."
It is common practice among industry standard setting bodies to
require disclosure of all relevant patents participating companies may
hold or license so participants may decide whether to adopt or work
around patented technology. Is Microsoft setting a trap for those who
rely on its patent license? Absent disclosure, there is no way of
knowing.
- No right to sell or sublicense implementing software. In its major grant of rights, the license provides:
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 and writing
files that comply with the Microsoft specifications for the Office
Schemas.
That sounds like a very broad grant of rights, doesn't it? But slow
down a moment. Take another look at that "except as provided below"
introductory phrase. It might trigger later language invalidating all
or any of the major rights granted. The "except as provided below"
phrase means that any language below the major grant of rights that
conflicts with it overrules the major license grant of rights.
There is at least one such conflict. Later in the license, it states:
"You are not licensed to sublicense or transfer your rights."
That means we have to go back to the major grant of rights and
subtract each right that requires sublicensing or transfer of "your
rights." (We'll come back to "your rights" later.)
- Make: Can you still "make" the software? Yes, no need to sublicense or transfer rights in order to "make" the software.
- Use: Can you still "use" the software? Yes, no need to
sublicense or transfer rights to use the software. (But there is a
"clarification included later in the license that severely restricts
"use," which is discussed under another numbered point below.)
- Sell: Can you still "sell" the software? No. You are
prohibited from sublicensing or transferring your rights. Selling
requires transfer of rights and therefore is prohibited.
- Offer to sell: Can you still "offer to sell" the
software? No. You can't "offer to sell" unless you have the right to
"sell." Otherwise, an offer to sell would be made in bad faith and
subject you to civil and criminal liability.
- Import: Can you still "import" the software? Probably
not. Technically, you might get away with importing the software, but
whoever sold you the software will most likely be regarded as violating
the license since it involves transfer of its licensed rights to you.
Should that person be sued or charged criminally as an intellectual
property "pirate," you may be liable as a co-conspirator.
- Otherwise distribute: Can you still "otherwise
distribute" the software? Probably not, since distributing it to others
would amount to a transfer of your rights to the software.
So let's take another look at the major grant of rights, to get a
picture of what rights are left after the "except as provided below"
phrase has worked its first magical effect:
Except as provided below, Microsoft hereby grants you a royalty-free license under Microsoft's Necessary Claims to make [or] use, sell, offer to sell, import, and otherwise distribute
Licensed Implementations solely for the purpose of reading and writing
files that comply with the Microsoft specifications for the Office
Schemas.
Boiled down to essentials, every method of sharing or making money
on your software just went up in smoke. You can make your software, and
you can use it. But you can't do anything else with it. Acquiring the
software except by writing your own requires that someone else violate
the same license.
So commercial developers are prohibited from profiting by supporting
Microsoft's new file format "standard." (We'll get to FOSS developers
later.) Commercial developers' only realistic option is to make a
separate deal with Microsoft for a different license. Any guesses on
whether Microsoft will make such a deal without extracting some
advantage such as royalty payments or cross-licensing of intellectual
property rights?
- Prohibition against sale and licensing of implementing software
Now let's deal with that blood-sucking, rights-squishing "your
rights" phrase we noted before, at the end of the sentence that
swallowed most of the rights in the major grant of rights and spit them
out into the trash can:
"You are not licensed to sublicense or transfer your rights."
The question that needs answering is: In context, does "your rights"
mean: (i) your original rights in your own code you create that
implements the file formats; (ii) the rights you acquire from Microsoft
via the license; or (iii) both? That is a serious question with serious
repercussions. If your original rights in your own code are within the
scope of "your rights," then you have no right to sell your
implementing software to another development company, and you have no
right to license your software to end users, since under both scenarios
you would be transferring "your rights" to another.
The strongest argument I could conjure why "your rights" should be
interpreted as encompassing only the rights you acquire from Microsoft
via the patent license must be inferred from the meaning of
"sublicense" as opposed to "license." Had Microsoft meant "your rights"
to mean your original rights—more than the rights it grants in the
license—then Microsoft would have used the word
"license" rather than "sublicense." That is because you would license
your own code to customers, not sublicense it. Therefore, use of the
verb "sublicense" limits the meaning of "your rights" to those rights
you acquired from Microsoft.
But that argument has vulnerabilities. The first problem with it is
that grammatically, the sentence actually contains two prepositional
phrases, not one. The Microsoft lawyers, if using more strict grammar,
would have drafted the license to say it bestows no right "to
sublicense your rights or to transfer your rights." So properly parsed,
"sublicense" limits only the meaning of the first occurrence of "your
rights," not the implicit second.
The second problem with the argument is that with the prepositional
phrase fully restated properly as two phrases, to maintain the argument
in favor of the licensee the "to sublicense your rights" phrase becomes
entirely superfluous, because a "sublicense" is encompassed within the
universe of a "transfer" of rights.
There is a hoary canon of contract interpretation that counsels
against interpretations that render words superfluous; each word is to
be interpreted as having separate meaning if it is plausible to do so.
So in this situation, there seems to be no justification for including
the first, "sublicense" prepositional phrase unless "your rights" was
intended to have a different meaning in each of the two contexts,
sublicensing and transferral of "your rights." What is different about
those meanings? Logically, "licensing" would be included in the meaning
of the prohibited "transfer of rights" but not within the meaning of
"sublicensing." Therefore, both "sublicensing" and "licensing" are
prohibited. And the prohibition against licensing implies that your
original, personal right to license your own code is blocked.
That's not the end of it, of course. The third problem with the
argument is that, having written some four pages of detailed syntactic
analysis, I decided to discard most of it and not inflict upon the
reader still more of an intractable issue that absolutely refused to be
definitively resolved by the rules of grammar and canons of contractual
interpretation. There is ambiguity.
Where I think the tipping point lies, without much more thorough
legal research, is in the reservation of rights language: "All rights
not expressly granted in this license are reserved by Microsoft. No
additional rights are granted by implication or estoppel or otherwise."
The very essence of a patent license is the exercise of the patent
holder's right to condition use of the invention. One of the patent
holder's rights is to insist on receiving value for the license to use
the invention. And certainly, a patent holder has the right to
condition use of the invention on the licensee's promise not to
sublicense use of the invention. But by the same token, the patent
holder has the right to insist that an implementation of the invention
not be transferred to those who hold no license. It's a "my deal is
only with you" kind of right.
Given that it certainly can not be said that Microsoft "explicitly"
granted the right to sublicense its rights in a licensed implementation
to any third party, the reservation of rights clause should trump any
relevant ambiguity. (Of course all of this assumes that Microsoft
actually has any relevant and valid patents to license.)
So by my reasoning, the treatment Microsoft's patent license gives
"your rights" creates blocking rights in other developers' licensed
implementations themselves by prohibiting a developer from transferring
to a willing purchaser any license, sublicense, or ownership interest
in a software product dependent on the licensed rights. For example,
should Corel implement the Microsoft schemas in WordPerfect Office in
reliance on the Microsoft patent license, Corel might later find itself
blocked from selling or encumbering (e.g., using as collateral
for a business loan) its relevant interests in WordPerfect Office,
unless it first removed all relevant code.
Even if regarded as mere ambiguity, the language creates an
unacceptable risk that a court might rule that the Microsoft patent
license blocks sale of an implementing developer's software to another
development company.11
- Prohibition against software having functions other than to read and write files using the specification without modification. The major grant of licensed rights discussed earlier is further limited to "Licensed Implementations solely for the purpose of reading and writing files that comply with the Microsoft specifications for the Office Schemas."
In other words, licensed implementing software by that language
arguably must be "solely" limited to the functions of reading and
writing compliant files.
Yet a further limitation on rights is contained in the portion of
that language that requires literal compliance with the schemas. But it
is not obvious in the four corners of the license just how limited the
right to read and write files really is. The license requires:
If you distribute, license or sell a Licensed
Implementation, this license is conditioned upon you requiring that the
following notice be prominently displayed in all copies and derivative
works of your source code and in copies of the documentation and
licenses associated with your Licensed Implementation:
"This product may incorporate intellectual property
owned by Microsoft Corporation. The terms and conditions upon which
Microsoft is licensing such intellectual property may be found at [Link]."
The web page linked from the Microsoft quotation is a "legal notice" stating in relevant part: "[n]o right to create modifications or derivatives of this Specification is granted herein."
Licensed Implementations are prohibited from departing from the
specification in any way, either by extension or reduction of
implemented features. A further restriction is that the Licensed
Implementation must be "solely for the purpose" of reading and writing
files in the Microsoft format.
For example, should Corel implement the Microsoft schemas in
WordPerfect, it arguably runs afoul of the "solely for the purpose"
phrase. The Licensed Implementation must be a stand-alone application.
Arguably, no implementing code could be shared with WordPerfect itself,
since that would violate the "sole purpose" language. Moreover, Corel
would be required to implement the Microsoft specifications fully, but
without modifications for any features present or absent in
WordPerfect.
Considering the inherent software architecture and feature
differences in the two companies' products, however, such a license
restriction would likely limit Corel's ability to implement all
Microsoft Office features, since different coding solutions might
require schema alterations to implement. Developers will undoubtedly
comment on Groklaw regarding the difficulty thereby imposed, but the
practical difficulties of writing a file conversion filter from one
complex application's file format to another's appears to be
significantly constrained by the inability to alter the schema
specifications.
- No license to convert files to and from other formats.
The schemas license nowhere bestows any right for licensees to write
code enabling software interoperability by converting files to or from
the Microsoft formats. The meaning of the word "read" in the license
is, viewed most charitably, ambiguous.
We are not yet done with the limitations of rights imposed by the language, "[l]icensed Implementations solely for the purpose of reading and writing files that comply with the Microsoft specifications for the Office Schemas."
Notice that the Licensed Implementation must be "solely" devoted to
reading and writing files in the Microsoft file formats. Both input and
output files must be in the Microsoft file formats. Any implementation
that also reads or writes to any non-licensed file format is at least
arguably forbidden by the plain language meaning of "solely." So even a
stand-alone program to convert files from the Microsoft formats to
other formats, or vice versa, would violate the license restrictions.
- No right to write files using the schemas.
We've already looked at one short phrase that unleashed havoc on what
appeared at first to be a broad grant of rights, the "except as
provided below" phrase. Now let's take a look at a phrase that does its mayhem on the major grant of rights by aiming upward in the document:
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 files that comply with the Microsoft specifications for the Office Schemas, or by using (solely for the purpose of reading such files) any software that enables them to do so. The term 'government documents' includes public records.
(Emphasis added.) See also Clarification of License Terms for Office XML Schema, by Microsoft XML Architecture Senior Director Jean Paoli.
A relevant canon of contract interpretation is expressio unius est exclusio alterius,
which loosely translated from the Latin means that the express
identification of one thing excludes any other thing of like kind.
Applying that canon to this license, the "clarification" expressly
declaring a grant only to "read" documents without violating the
license would extinguish the earlier grant to "write" documents. The
need to apply the rule is bolstered by labeling the language as a
"clarification" rather than as an "example." Under that interpretation,
end users acquire no right to write files complying with the Office Schemas or to use "any software that enables them to do so."
Moreover, the fact that the language confines itself to the rights
of end users suggests that the persons or companies who distribute the
software acquire no such immunity.
Now to get a better picture of how the license is structured,
picture one big, ugly gangster sitting near the top of the patent
license blazing away with his machine gun down toward the middle of the
text. That's Mr. Except AsProvided Below. Now look closer to the end of
the license, and picture the gangster's buddy, shooting up at the
middle. That is Mr. Clarification OfThe Foregoing. In the valley
between them sits their target, poor Major Grant Of Rights.
Did the valiant Major Grant survive? What is left after the bullets
stop flying? Just before the last flurry of bullets all he had left was
a stand-alone application to read and write files only in the Microsoft
format. He was not permitted even to convert files to or from
Microsoft's formats, having the right to read and write files only in
Microsoft formats without modification. But now Major Grant has lost
his right to write files as well. All he can do is create his file
viewer and "read" Microsoft documents in Microsoft file formats, and
even that only for "government documents."
Major Grant can not lawfully sell or offer to sell his file viewer.
He can not license or sublicense it. He can not even give it away. He
can't transfer any rights in his file viewer, either his own or the
"rights" he licensed from Microsoft, to anyone. But there is still a
small blessing; if someone steals his file viewer, Microsoft might not
sue Major Grant because he never transferred any of his rights to the
thief.12
Query, Without a right to write files, is there even a right
to print files? To pass files off to a speech synthesizer for use by
the disabled? Remember the reservation of rights language.
- Vagueness and ambiguities will deter implementation by developers and adoption by end users.
Whatever advantages the Microsoft Office Schemas might have, the
multiple show-stopping provisions of the license are most charitably
regarded as vague and ambiguous on crucial terms. Developers other than
Microsoft are thereby deterred from implementing the Schemas. The
license is, in effect, little more a veiled threat to sue any
implementing developer for patent and copyright infringement.
Developers unable to reach separate and different agreements with
Microsoft will likely treat Microsoft's patent license with the respect
owed to bubonic plague.
End users will also likely be affected, and implementation of
Microsoft's schemas further hindered as word spreads that Microsoft's
relevant "patent license" is the software equivalent to a "poison pill"
defense to a hostile corporate takeover. The license serves to drive
developers away, not to entice them.
- Discriminatory incompatibility with F/OSS licensing.
Needless to say, each of the limitations of the Microsoft Office
Schemas Patent License discussed above make that license unquestionably
incompatible with free and open source licenses for software such as
the Gnu General Public License or the Gnu Lesser General Public
License. For example, open source licenses require distribution of
source code and allow modification of it. See generally, the Open Source Definition.
Furthermore, many F/OSS development projects are irrevocably
committed to their licenses through the licensing provisions. The KDE
KOffice word processor and spreadsheet program developers, for example,
can not legally alter their LGPL license to accommodate Microsoft's
license terms without violating the rights of numerous developers who
have contributed code under LGPL terms. The Microsoft license terms are
therefore discriminatory.
Many of the restrictions in the Microsoft license appear to serve no
purpose other than to discriminate against developers who license their
software under such licenses. Consider, for example, the denial of
right to sublicense a licensed implementation. The Microsoft "patent
license" supposedly is available to anyone in the world. What purpose
then might a refusal to allow sublicensing serve, if not to create an
incompatibility with open source software's licensing requirement that
the software's source code and any modifications to it be sublicensable?
Indeed, Microsoft has been so hostile to F/OSS developers that it
has gone so far in some of its other licenses as to explicitly prohibit
use of its intellectual property in software licensed under the GPL or
LGPL.13
Having learned from its bad press, Microsoft no longer bluntly
prohibits licensing to open source software developers, but instead
includes license terms that are incompatible with software developed
under an open source software license. It is troubling that government
officials would fall for such tactics and proclaim that such licenses
are "nondiscriminatory" and "open," as Massachusetts has done.
There is no question that Microsoft knows how to use a truly open
license when it benefits financially, including one that waives patent
rights. For example, Microsoft has released its WiX XML source code under the open source Common Public License.
- Discriminatory incompatibility with proprietary software competitors.
As discussed above, Canada's Corel Corp. has for many years offered
WordPerfect Office, which includes SGML and XML document generation and
editing capabilities. Likewise, the FOSS-licensed OpenOffice.org uses
the OpenDocument XML Schemas. There are many other XML editors and
generators on the market.
Because of the many obstacles created by the Microsoft patent
license to software competitors' ability to use the Microsoft Schemas,
adoption of the Microsoft Office XML Schemas as an approved government
standard discriminates against competitors.
[ Contents ]
The Massachusetts "open format" definition purports to allow adoption of:
"de facto format standards controlled by other
entities that are fully documented and available for public use under
perpetual, royalty-free, and nondiscriminatory terms."
In light of the discussion in the preceding section, the Microsoft
Office 2003 XML Reference Schemas are neither "available for public
use" nor is their licensing "non-discriminatory."
Existing U.S. law governing industry standard-setting and antitrust
cases allows use of "reasonable and non-discriminatory" ("RAND") terms
in licensing. Such law might arguably approve of the Massachusetts
decision to approve Microsoft's Schemas as a public standard. Under
that body of law:
One interpretation of nondiscrimination might be
that a patent owner is merely required to license to everyone in the
industry, with no exceptions. This sort of compulsory license is in
itself a major concession by the patent owner, for it requires the
patentee to relinquish the basic property right embodied in a patent:
the right to exclude others from making, using, and selling the
patented invention. Under this interpretation, as long as all industry
participants are offered a license on terms that are not so prohibitive
as to constitute no offer at all, the nondiscrimination requirement is
met.
A second interpretation of nondiscriminatory would require the
patentee to license not only to everyone without exception, but to
offer each licensee identical rates. Under such a policy,for example,
one might argue that a patent holder can do no more than license at a
single, specific rate (e.g., $1.00/unit or 5 percent of net sales). In
this case, there would be no room for individualized negotiations with
each licensee. Another drawback of this interpretation is that it would
effectively foreclose patent owners from entering into cross-licenses.
No two companies have identical patent portfolios, so it would be
impossible for a patent owner to enter into cross licenses with two
different companies that have identical terms. Cross-licenses are very
common and efficient mechanisms for resolving patent issues in industry
standard-setting processes, and a policy that discourages
cross-licenses would most likely be problematic.
A third possible interpretation of nondiscrimination would be that
similarly situated parties should be treated similarly. Under this
interpretation, although licensing to everyone on identical terms might
be sufficient to meet a goal of nondiscrimination (at least to the
extent all potential licensees are similarly situated), it would not be
the only form of nondiscriminatory licensing. Rather, a patent owner
whose patents are incorporated into a standard could license everyone
at rates that are fair and reasonable vis à vis other similarly
situated licensees. A requirement that similarly situated licensees be
offered similar terms provides more flexibility to the negotiating
parties to reach optimal agreements concerning the preferred form of
payment for the license (whether it be cash, cross-licenses, or other
forms of consideration). This interpretation is consistent with the
more general sense of nondiscrimination as a term of art in the law
(e.g., nondiscrimination in employment or housing): it is not necessary
to treat everyone identically, as long as people in similar situations
are treated similarly.
One example of two potential licensees who are not similarly
situated occurs where one licensee has a large patent portfolio it can
offer for cross-licensing, and another licensee has no patents to
license back. The patent holder might wish to enter into a
cross-license with the first licensee, and a per-unit royalty-bearing
license with the second licensee. In such a case, under the similarly
situated interpretation of nondiscrimination, the differing terms of
the licenses in and of themselves would be of no consequence.
The Effect of Industry Standard Setting on Patent Licensing and Enforcement, by R. Feldman, M. Rees, and B. Townshend, Communications (July, 2000); see also Oasis Cover Page, "Patents and Open Standards" (discussing pros and cons of RAND licensing).
However, Massachusetts is neither an antitrust defendant nor is it a participant in an industry
standards-setting body. It is a government body establishing a standard
for government procurement of software and acceptance of computer files
from the private sector. Massachusetts is a customer, not a
competitor. Legal definitions of RAND in other settings must therefore
give way to more specific requirements controlling government
procurement of goods and services.
The international Agreement on Government Procurement is intended to
open up government competitive bidding processes throughout signatory
nations and to end government discrimination against foreign businesses
in government procurement contracts. As one consequence, governments
around the world have been developing standards for information
technology used in government bidding specifications. Particularly in developing nations, public officials are increasingly opting to adopt open source software solutions in order to comply with the Agreement. See e.g., Global Policies on Open Source
by the U.S.-based Center for Strategic and International Studies,
surveying the status of open source software adoption by governments in
some 80 nations. (Report last updated December 14, 2004.)
In the European Union, implementation of the Agreement is under the direction of the IDABC,
the Interoperable Delivery of European eGovernment Services to Public
Administrations, Businesses and Citizens, and of the European
Commission's Information Society and Media Directorate-General. The IDABC has a strong focus on implementing open source software solutions in Europe. See e.g., the IDABC's Open Source Observatory. According to Microsoft,
the IDABC also raised questions about Microsoft's Office 2003 XML
Reference Schemas patent license. However, IDABC rejected the Microsoft
Schemas, in part because of licensing restrictions. See Carrera, supra.
The Agreement on Government Procurement's Article VI provides:
1. Technical specifications laying down the
characteristics of the products or services to be procured, such as
quality, performance, safety and dimensions, symbols, terminology,
packaging, marking and labelling, or the processes and methods for
their production and requirements relating to conformity assessment
procedures prescribed by procuring entities, shall not be prepared, adopted or applied with a view to, or with the effect of, creating unnecessary obstacles to international trade.
2. Technical specifications prescribed by procuring entities shall, where appropriate:
(a) be in terms of performance rather than design or descriptive characteristics; and
(b) be based on international standards, where such exist;
otherwise, on national technical regulations, recognized national
standards, or building codes.
3. There shall be no requirement or reference to a particular
trademark or trade name, patent, design or type, specific origin,
producer or supplier, unless there is no sufficiently precise or
intelligible way of describing the procurement requirements and
provided that words such as “or equivalent” are included in the tender
documentation.
4. Entities shall not seek or accept, in a manner which would have
the effect of precluding competition, advice which may be used in the
preparation of specifications for a specific procurement from a firm
that may have a commercial interest in the procurement.
The Agreement unquestionably was intended to apply to information technology. See e.g., Article XXIV, section 8. Moreover, the Agreement on Government Procurement to the extent applicable takes precedence over the related Agreement on Technical Barriers to Trade. See id., section 1.4.
Thus, strong arguments could be raised by any signatory nation
before the World Trade Organization that Massachusetts' adoption of
Microsoft's Office XML Schemas as a procurement standard violates the
Agreement on Government Procurement in that it:
- Has the "effect of" creating unnecessary
obstacles to international trade as prohibited by Article VI § 1 by
giving more favorable treatment to a U.S. software vendor;
- Is not based on international or national regulations or standards as required by Section 2(b);
- Improperly requires and makes reference to a
particular "patent, design or type, specific origin, producer or
supplier" as prohibited by Section 3;
- Is improperly based on "design or descriptive
characteristics" rather than being described in "terms of performance,"
as prohibited by Section 2(a); and
- Was improperly adopted as a result of a negotiation
with "a firm that may have a commercial interest in the procurement"
that is prohibited by Section 4.
See also Agreement on Government Procurement Article XIV § 4 (negotiations) and Article XV § 1(b) (tenders limited for technical reasons).
The U.S. government acceded to the Agreement on Government Procurement by passage of the Uruguay Round Agreements Act, 19 U.S.C. § 3511.
The Agreement is made applicable to state governments by Section 3512.
Under Section 3512(c), Congress purported to extinguish any private
right to enforce the Agreement. However, it is not clear that such a
limitation or the related limitations under Section 3512(a) would
survive challenge before the World Trade Organization, as they are
blatantly inconsistent with requirements of the Agreement itself in Article XX,
which requires that a private right to challenge violations be made
available. Moreover, in the context of computer software, the
limitations exceed the only exceptions allowed, which are listed in Article XXIII.
While the corresponding sections of the North American Free Trade Agreement
have yet to take effect as applied to government procurement of
computer software, when they do NAFTA will impose virtually identical
duties and prohibitions on the U.S. and its subunits.14
Because of the issues discussed above, the Massachusetts decision to
adopt Microsoft's Office 2003 XML Reference Schemas as a procurement
standard may result in initiation of legal proceedings in the World
Trade Organization against the U.S. pursuant to Section XXII
of the Agreement on Government Procurement. Indeed, considering the
critical nature of computer file compatibility in networks and the
precedential nature of the Massachusetts action in the U.S. as well as
its networking effects throughout eGovernment and eCommerce worldwide,
such a clash seems nearly inevitable, unless Massachusetts officials
back down.
Ultimately, it is Microsoft's decision whether it wishes to compete
for government software procurement contracts. The company is entitled
to patent that which is patentable, but it does not have the right to
impose its patented products on government agencies. In the U.S., the
constitutional guarantee of equal protection of the laws and the
constitutional prohibition against the unequal grant of privileges and
immunities both require a level playing field in competition for
government contracts.
Moreover, Massachusetts officials' Open Formats standard must comply
with the international Agreement on Government Procurement, which
prohibits standards that have "the effect of" discriminating against
foreign bidders.
The situation appears to be ripe for resolution through adoption of
government procurement standards by international standard-setting
bodies. Failing that, the Massachusetts standard may have to await
adoption of a national standard as required by the Agreement on
Government Procurement.
While the U.S. specifically disclaimed the portion of the Agreement on Government Procurement that grants companies the right to challenge discriminatory government procurement specifications, the right of other nations to challenge such actions before the World Trade Organization is in play.
The Commonwealth might avoid such litigation dangers by dropping its
proposal to approve the Microsoft Office XML Reference Schemas as an
approved state procurement standard. Should Microsoft not back down
from its refusal to license without unreasonable restrictions,
Massachusetts has the option of waiting until more states are ready to
issue their own standards, then present Microsoft with a united front.
Massachusetts taxpayers would benefit. Microsoft should not be
allowed to destroy the basis for competitive bidding on software, open
standard file formats. Should the Commonwealth heed the guidance of the
Agreement on Government Procurement, competition will be preserved. As
Bill Gates recognized in his Challenges and Strategy memo, "the price per user of software will end up around 0."
[ Contents ]
1 Massachusetts government identifies itself as a commonwealth rather than a state; however, it is for all purposes relevant to this article one of the co-equal states of the United States of America.
2 Crosby v. National Foreign Trade Council, 530 U.S. 363 (2000). C.f., Golan v. Ashcroft,
a pending U.S. district court case seeking to have the U.S. enactment
acceding to the Agreement on Government Procurement declared
unconstitutional (copyright case).
3 See also What Governors Need to Know About E-SIGN: The Federal Law Authorizing Electronic Signatures and Records, National Governors' Ass'n. (Sept. 22, 2000).
4 See How to Contact Massachusetts about Open Format Proposal (Groklaw) for addressing information.
5 For a much more detailed
and fully referenced discussion of the European Interoperability
Framework for Pan-European eGovernment Services v. 1.0, see IDA Releases European Interoperability Framework for Pan-European E-Government Services.
6 The Commonwealth would thus
be forced into a problematic hybrid migration-encapsulation strategy
for preserving digital records. See e.g., The State of the Art and Practice in Digital Preservation (PDF, 14 pp.), L. Kyong-Ho, et al, J. Res. Natl. Inst. Stand. Technol. 107, 93–106 (2002).
7 See e.g., Eastman Kodak Co. v. Image Tech. Svcs., 504 U.S. 451 (1992):
The Court has held many times that power gained
through some natural and legal advantage such as a patent, copyright,
or business acumen can give rise to [antitrust] liability if "a seller
exploits his dominant position in one market to expand his empire into
the next." Times-Picayune Publishing Co. v. United States, 345 U.S. 594, 611 (1953), see, e.g., Northern Pacific R. Co. v. United States, 356 U.S. 1 (1958); United States v. Paramount Pictures, Inc., 334 U.S. 131 (1948); Leitch Mfg. Co. v. Barber Co., 302 U.S. 458, 463 (1938).
The doctrine finds its origin in case decisions such as Morton Salt Co. v. G. S. Suppiger Co., 314 U.S. 488 (1942):
The grant to the inventor of the special privilege
of a patent monopoly carries out a public policy adopted by the
Constitution and laws of the United States, 'to promote the Progress of
Science and useful Arts, by securing for limited Times to *** Inventors
the exclusive Right ***' to their 'new and useful' inventions. United
States Constitution, Art. I, 8, cl. 8; 35 U.S.C. 31, 35 U.S.C.A. 31.
But the public policy which includes inventions within the granted
monopoly excludes from it all that is not embraced in the invention. It
equally forbids the use of the patent to secure an exclusive right or
limited monopoly not granted by the Patent Office and which it is
contrary to public policy to grant.
8 See Graham v. John Deere Co., 383 U.S. 1 (1966), quoting Thomas Jefferson:
"(A) machine of which we are possessed, might be
applied by every man to any use of which it is susceptible." Letter to
Isaac McPherson, supra, at 181. "(A) change of material should not give
title to a patent. As the making a ploughshare of cast rather than of
wrought iron; a comb of iron instead of horn or of ivory ****" Ibid.
"(A) mere change of form should give no right to a patent, as a
high-quartered shoe instead of a low one; a round hat instead of a
three-square; or a square bucket instead of a round one." Id., at
181-182. "(A combined use of old implements.) A man has a right to use
a saw, an axe, a plane separately; may he not combine their uses on the
same piece of wood?" Letter to Oliver Evans (Jan. 1814), VI Writings of
Thomas Jefferson, at 298 (Washington ed.).
9 Microsoft Royalty-Free CIFS Technical Reference License Agreement section 1.6.
10 Antitrust
Guidelines for the Licensing of Intellectual Property, U.S. Justice Dept. and Federal Trade Commission.
11 For example, The SCO
Group is presently suing IBM for some $5 billion in damages under claim
that IBM violated contractual rights by contributing AIX code developed
by IBM to the open source Linux operating system, on the theory that
TSCOG acquired rights in AIX by TSCOG's predecessor in interest
licensing UNIX to IBM for use in AIX development. See case summary at Groklaw.
Microsoft has publicly stated, of course, that it believes that TSCOG
has a valid claim, and there are indications that Microsoft has funded
TSCOG's lawsuit.
12 See also Microsoft releases their updated patent license,
by Massachusetts Software Council president Dan Bricklin, who also
concludes—apparently based on legal advice—that the Microsoft
patent license allows only use of a file viewer, and not a right to
develop and distribute even that. ("What it doesn't do is allow a
developer to develop such software if patent law could stop them.")
13 Microsoft initially
garnered bad press in 2001 with a license for Microsoft Mobile Internet
Toolkit Beta 2 that branded open source software as "Potentially Viral
Software," specifically identifying Linux as such and defining the term
to include software licensed under a number of specific open source
software licenses. News.com, "Microsoft license spurns open source," by Stephen Shankland; see also full text at use.perl.org.
That public relations debacle was followed by an initial public
draft of Microsoft's CIFS license in 2002 that gained notoriety because—while dropping the "Potentially Viral Software" terminology—it
expressly prohibited CIFS from being employed in software licensed
under the GPL, LGPL, or similar licenses. See sections 1.4 and 3.3 of the full text of the Royalty-Free CIFS Technical Reference License Agreement at Foundation for a Free Information Infrastructure; and discussion of it.
14 See sections 906
(standards compatibility and equivalence); 1001 (procurement); 1003
(national treatment and non-discrimination); 1007 (technical
specifications); 1014 (negotiation disciplines); 1017 (bidding
challenges in procurement).
This article is licensed under the Creative Commons Attribution-Noncommercial License 2.0.
[ Contents ]
|