|
|
| The AMD Subpoena to Microsoft |
 |
|
Monday, April 17 2006 @ 02:07 AM EDT
|
Let's take a little side trip. Groklaw's feldegast couldn't resist doing a text version of the heart of the AMD subpoena to Microsoft [PDF]. So, for those who'd like to track this one, here it is. He didn't do the forms, but if anyone feels inclined, you can find templates in the Groklaw Archives, in the subpoenas SCO sent Intel and The Open Group. I don't think it's necessary, but if you want to do the work, I'm happy to put it here on Groklaw. It's a document subpoena. On page 3 of the PDF, one of the pages we haven't transcribed, you'll see that there is no one scheduled to be deposed at this time. At this point, it's about documents. Later, I'm sure after they study the documents they get, AMD will have in mind to depose some folks. Frankly the standards questions Microsoft is being asked to provide information about fascinate me, because of the ODF story and the whole Ecma/Oasis thing. You'll see that part begin in the section on documents to be produced, paragraphs 4-6. For example, here's 4: 4. DOCUMENTS reflecting or discussing: ( I ) the design, development or
implementation of STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR
SECURE INPUT OR OUTPUT INTERFACES; (2) intellectual property rights of
MICROSOFT, INTEL, or AMD relating to STANDARDS, SPECIFICATIONS, PROTOCOLS
OR SOFTWARE FOR SECURE INPUT OR OUTPUT INTERFACES; (3) licensing of
STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT
OR OUTPUT INTERFACES, or any intellectual property rights related thereto, by
MICROSOFT, INTEL or AMD and the terms of such licenses; or (4) INTEL'S or AMD's
participation in or exclusion from efforts to design, develop or implement STANDARDS,
SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT
INTERFACES. AMD seems to have something quite specific in mind. That part of this story I'll definitely be following. To think, I used to feel standards were boring.
Say, paragraph 6 is pretty interesting too: 6. For purposes of this document request, ''STANDARDS, SPECIFICATIONS,
PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT INTERFACES" refers to
(a) standards, specifications, protocols or software relating to Microsoft's Palladium,
Trustworthy Computing initiatives, Trusted Network Connect (TNC), Network Access
Protection (NAP) or Next-Generation Secure Computing Base (NGSCB); (b) standards,
specifications, protocols or software relating to Intel's LaGrande technology or AMD's Presidio
technology; (c) standards, specifications, protocols or software relating to the Trusted Platform
Module or Secure Startup; or (d) standards, specifications, protocols or sohare considered,
discussed or developed by or through the Trusted Computing Platform Alliance (TCPA), Trusted
Computing Group (TCG), Peripheral Component Interface Special Interest Group (PC1 SIG),
Universal Serial Bus (USB) lrnplementers Forum or IEEE. What does AMD see going on in the Trusted Computing space?************************************
IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF DELAWARE |
ADVANCED MICRO DEVICES, INC., a
Delaware corporation, and AMD
INTERNATIONAL SALES & SERVICE, LTD.,
a Delaware corporation,
Plaintiff,
vs.
INTEL, CORPORATION, a Delaware
corporation and INTEL KABUSHIKI KAISHA,
a Japanese corporation,
Defendants. |
Civil Action No. 05-441-JJF
|
NOTICE OF SUBPOENA
TO:
Richard L,. Horwitz, Esquire
Potter Anderson & Corroon LLP
[Address]
Darrell B. Bernhard, Esquire
Howrey LLP
[Address]
Robert E. Cooper, Esquire
Daniel S. Floyd, Esquire
Gibson, Dunn & Crutches, L.L.P
[Address]
PLEASE TAKE NOTICE that on April 1.3, 2006, the attached subpoena was served on Microsoft Corporation, c/o Corporation Service Company, [Address].
1
Of Counsel:
Charles P. Diamond
Linda J. Smith
Mark A. Samuels
O'Melveny & Myers, LLP
[Address]
[Phone]
Dated: April 13,2006
[Signature]
Jesse A. Finkelstein (#1090)
Frederick L. Cottrell, III (#2555)
Chad M. Shandler (#3796)
Steven J. Fineman (#4025)
Richards, Layton & Finger, P.A.
[address, phone, email addresses]
Attorneys for Plaintiffs Advanced Micro
Devices, Inc and AMD International Sales &
Service, Ltd.
2
[Subpoena Form Document]
3
[Proof of Service Form Document]
4
EXHIBIT A
5
SCHEDULE A
DEFINITIONS
1. For purposes of this document request, "DOCUMENT" includes, without limitation,
any hard copy writings and documents as well as electronically stored data-files including email,
instant messaging, shared network files, and databases created, accessed, modified or dated on or
after January 1, 2000
2. With respect to electronically stored data, "DOCUMENT" also includes, without
limitation, any data on magnetic or optical storage media (e.g., servers, storage area networks,
hard drives, backup tapes, CDs, DVDs, thumblflash drives, floppy disks, or any other type of
portable storage device, etc.) stored as an "active" or backup file, in its native format.
3. For purposes of this document request, "MICROPROCESSOR" means general
purpose microprocessors using the x86 instruction set (e.g., Sempron, Athlon, Turion, Opteron,
Celeron, Pentium, and Xeon).
4. For purposes of this document request, "64-BIT MICROPROCESSOR" means any
MICROPROCESSOR that uses x86 instructions for the 64-bit architecture, including, but not
limited to, any 64-BIT MICROPROCESSORS (e g., Opteron, Athlon 64, Turion 64), any
INTEL MICROPROCESSORS using the EM64T extended instruction set and any INTEL
MICROPROCESSORS using x86 instructions fiom any other 64-bit instruction set.
5. For purposes of this document request, the terms "COMPANY" and "MICROSOFT"
refer to Microsoft Corporation and any of its controlled present or former subsidiaries, joint ventures,
affiliates, parents, assigns, predecessor or successor companies and divisions thereof.
"INTEL" refers to Intel Corporation, Intel Kabushiki Kaisha, and any of their present or former
subsidiaries, affiliates, parents, assigns, predecessor or successor companies and divisions
thereof. "AMD" refers to Advanced Micro Devices, Inc., AMD International Sales and Service
Ltd., and any of their present or former subsidiaries, affiliates, parents, assigns, predecessor or
successor companies and divisions thereof.
6. For purposes of this document request, ''STANDARDS, SPECIFICATIONS,
PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT INTERFACES" refers to
(a) standards, specifications, protocols or software relating to Microsoft's Palladium,
Trustworthy Computing initiatives, Trusted Network Connect (TNC), Network Access
Protection (NAP) or Next-Generation Secure Computing Base (NGSCB); (b) standards,
specifications, protocols or software relating to Intel's LaGrande technology or AMD's Presidio
technology; (c) standards, specifications, protocols or software relating to the Trusted Platform
Module or Secure Startup; or (d) standards, specifications, protocols or sohare considered,
discussed or developed by or through the Trusted Computing Platform Alliance (TCPA), Trusted
Computing Group (TCG), Peripheral Component Interface Special Interest Group (PC1 SIG),
Universal Serial Bus (USB) lrnplementers Forum or IEEE.
6
INSTRUCTIONS
1. The time period, unless otherwise specified, covered by each request set forth below is
from January 1,2000 up to and including the present.
2. In responding to each request set forth below, please set forth each request in full
before each response.
3 If any DOCUMENT covered by these requests is withheld by reason of a claim of
privilege, please furnish a list at the time the DOCUMENTS are produced identifying any such
DOCUMENT for which the privilege is claimed, together with the following information with
respect to any such DOCUMENT withheld: author; recipient; sender; indicated or blind copies;
date; general subject matter; basis upon which privilege is claimed and the paragraph of these
requests to which such DOCUMENT relates. For each DOCUMENT withheld under a claim
that it constitutes or contains attorney work product, also state whether COMPANY asserts that
the DOCUMENT was prepared in anticipation of litigation or for trial.
4. If COMPANY objects to a request in part, please state specifically which part of the
request COMPANY objects to and produce all DOCUMENTS responsive to all other parts ofthe
request.
5. With respect to any DOCUMENT maintained or stored electronically, please harvest
it in a manner that maintains the integrity and readability of all data, including all metadata.
6. Please produce all DOCUMENTS maintained or stored electronically in native,
electronic format with all relevant metadata intact and in an appropriate and useable manneI
(e.g., by copying such data onto a USB 2.0 external hard drive). Encrypted or passwordprotected
DOCUMENTS should be produced in a form permitting them to be reviewed.
7. Please organize electronic DOCUMENTS produced for inspection in the same manner
that the COMPANY stores them (e.g., if maintained by a custodian, such as email residing on an
email server, please organize DOCUMENTS for production by custodian; if maintained in a
subfolder of "My Documents" on a custodian's hard drive, please organize DOCUMENTS for
production by custodian with path information preserved, etc.).
8. To the extent responsive DOCUMENTS reside on databases and other such systen~s
and files, COMPANY shall either produce the relevant database in useable form andlor shall
permit access for inspection, review, and extraction of responsive information.
9. At COMPANY'S election, DOCUMENTS maintained or stored in paper; hard-copy
form can be produced as searchable .PDF (i.e., portable document format files with embedded
text) and in an appropriate and useable manner (e,g., by copying such data onto a USB 2.0
external hard drive).
7
DOCUMENTS TO BE PRODUCED
1. DOCUMENTS reflecting or discussing: (a) MICROSOFT'S decision to develop
software for AMD's or INTEL'S 64-BIT MICROPROCESSORS; (b) MICROSOFT'S
development of software for those MICROPROCESSORS; and (c) the timing and schedule for
development and release of such software.
2. DOCUMENTS constituting or reflecting communications with AMD or INTEL
concerning: (a) MICROSOFT'S decision to develop software for AMD's or INTEL'S 64-BIT
MICROPROCESSORS; (b) MICROSOFT'S development of software for those
MICROPROCESSORS; and (c) the timing and schedule for development and release of such
software
3. DOCUMENTS constituting or reflecting internal discussions or other communications
within MICROSOFT concerning: (a) MICROSOFT'S decision to develop software for AMD's
or INTEL'S 64-BIT MICROPROCESSORS; @) MICROSOFT'S development of software for
those MICROPROCESSORS; and (c) the timing and schedule for development and release of
such software.
4. DOCUMENTS reflecting or discussing: ( I ) the design, development or
implementation of STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR
SECURE INPUT OR OUTPUT INTERFACES; (2) intellectual property rights of
MICROSOFT, INTEL, or AMD relating to STANDARDS, SPECIFICATIONS, PROTOCOLS
OR SOFTWARE FOR SECURE INPUT OR OUTPUT INTERFACES; (3) licensing of
STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT
OR OUTPUT INTERFACES, or any intellectual property rights related thereto, by
MICROSOFT, INTEL or AMD and the terms of such licenses; or (4) INTEL'S or AMD's
participation in or exclusion from efforts to design, develop or implement STANDARDS,
SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT
INTERFACES.
5. DOCUMENTS constituting or reflecting communications with AMD or INTEL
concerning: (1) the design, development or implementation of STANDARDS,
SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT
INTERFACES; (2) intellectual property rights of MICROSOFT, INTEL or AMD relating to
STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT
OR OUTPUT INTERFACES; (3) licensing of STANDARDS, SPECIFICATIONS,
PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT INTERFACES, or any
intellectual property rights related thereto, by MICROSOFT, INTEL or AMD and the terms of
such licenses; or (4) INTEL'S or AMD's participation in or exclusion from efforts to design,
develop or implement STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE
FOR SECURE INPUT OR OUTPUT INTERFACES.
6. DOCUMENTS constituting or reflecting internal discussions or other communications
within MICROSOFT concerning: (1) the design, development or implementation of
STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE INPUT
OR OUTPUT INTERFACES; (2) intellectual property rights of MICROSOFT, INTEL, or AMD
8
relating to STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE FOR SECURE
INPUT OR OUTPUT INTERFACES; (3) licensing of STANDARDS, SPECIFICATIONS,
PROTOCOLS OR SOFTWARE FOR SECURE INPUT OR OUTPUT INTERFACES, or any
intellectual property rights related thereto, by MICROSOFT, INTEL, or AMD and the terms of
such licenses; or (4) INTEL'S or AMD's participation in or exclusion from efforts to design,
develop or implement STANDARDS, SPECIFICATIONS, PROTOCOLS OR SOFTWARE
FOR SECURE INPUT OR OUTPUT INTERFACES.
7. DOCUMENTS reflecting or discussing: (a) MICROSOFT'S actual or perceived
collaboration with or support of AMD relating to advertisement or promotion of AMD, AMD
MICROPROCESSORS and/or computer systems containing AMD MICROPROCESSORS; (b)
MICROSOFT'S actual or planned participation in and support of any AMD product launch or
promotion; or (c) INTEL'S reaction or response to MICROSOFT'S actual or perceived
collaboration with or support of AMD relating to advertisement or promotion of AMD, AMD
MICROPROCESSORS and/or computer systems containing AMD MICROPROCESSORS or
MICROSOFT'S actual or planned participation in and support of any AMD product launch or
promotion.
8. DOCUMENTS constituting or reflecting communications with AMD or INTEL
concerning: (a) MICROSOFT'S actual or perceived collaboration with or support of AMD
relating to advertisement or promotion of AMD, AMD MICROPROCESSORS and/or computer
systems containing AMD MICROPROCESSORS; (b) MICROSOFT'S actual or planned
participation in and support of any AMD product launch or promotion; or (c) INTEL'S reaction
or response to MICROSOFT'S actual or perceived collaboration with or support of AMD
relating to advertisement or promotion of AMD, AMD MICROPROCESSORS and/or computer
systems containing AMD MICROPROCESSORS or MICROSOFT'S actual or planned
participation in and support of any AMD product launch or promotion.
9. DOCUMENTS constituting or reflecting internal discussions or other communications
within MICROSOFT concerning: (a) MICROSOFT'S actual or perceived collaboration with or
support of AMD relating to advertisement or promotion of AMD, AMD MICROPROCESSORS
and/or computer systems containing AMD MICROPROCESSORS; (b) MICROSOFT'S actual
or planned participation in and support of any AMD product launch or promotion; or (c)
INTEL'S reaction or response to MICROSOFT'S actual or perceived collaboration with or
support of AMD relating to advertisement or promotion of AMD, AMD MICROPROCESSORS
and/or computer systems containing AMD MICROPROCESSORS or MICROSOFT'S actual or
planned participation in and support of any AMD product launch or promotion.
10. DOCUMENTS constituting or reflecting internal discussions or other
communications within MICROSOFT or communications with any third party concerning the
capitalization, financing, valuation or financial viability of AMD.
11. DOCUMENTS authored by or on behalf of MICROSOFT constituting or reflecting
assessments, evaluations, analyses, summaries, reports, studies or other writings (a) concerning
the capitalization, financing, valuation or financial viability of AMD, or (b) comparing INTEL
and AMD MICROPROCESSORS from a price, quality, performance or other standpoint.
9
CERTIFICATE OF SERVICE
I hereby certify that on April 13, 2006, I electronically filed the foregoing document with
the Clerk of Court using CMIECF and have sent by Hand Delivery to the following:
Richard L. Horwitz, Esquire
Potter Anderson & Corroon LLP
[Address]
and on April 13, 2006 have sent by Federal Express to the followi~lgn on-registered participants:
Darrell B. Bernhard, Esquire
Howrey LLP
[Address]
Robert E. Cooper, Esquire
Daniel S. Floyd, Esquire
Gibson, Dunn & Crutches, L.L.P
[Address]
________[Signature]________
Steven J. Fineman (#4025)
Richards, Layton & Finger, P.A.
[Address]
[Phone]
[Email]
|
|
|
|
| Authored by: wood gnome on Monday, April 17 2006 @ 03:42 AM EDT |
| Many thanks, Feldegast! (this is on topic, actually, I think) [ Reply to This | # ]
|
| |
| Authored by: MathFox on Monday, April 17 2006 @ 03:59 AM EDT |
For typos not found by Feldegast's spellchecker and PJ's eyes.
---
If an axiomatic system can be proven to be consistent and complete from within
itself, then it is inconsistent.[ Reply to This | # ]
|
| |
| Authored by: Groo on Monday, April 17 2006 @ 04:14 AM EDT |
For those wondering what this is about, the technology in question is LeGrande
or LT on the Intel side, Presidio on the AMD side. It basically is the 'trusted
computing' hardware, and more or less removes the last vestiges of rights
consumers had in dealing with computers.
Ostensibly, it is about security, but it does not secure the PC from outsiders,
it keeps the owner from looking at things that outsiders don't want them to,
outsiders being MS, Sony and the other DRM merchants.
Either way, 'security' in this sense should be read in the same way that the
'clean skies act' loosens air quality restrictions, and the DMCA 'protects' us.
-Charlie
P.S. If you plan to read up on the tech, don't plan on sleeping well for a long
time.[ Reply to This | # ]
|
| |
| Authored by: Quila on Monday, April 17 2006 @ 08:35 AM EDT |
For their antitrust suit against Intel, AMD is looking for evidence that Intel
tried to get Microsoft to support only its DRM enabling technology and not
AMD's.[ Reply to This | # ]
|
| |
| Authored by: rsteinmetz70112 on Monday, April 17 2006 @ 08:45 AM EDT |
I'm not sure what this is all about, anyone able to expand on it?
---
Rsteinmetz - IANAL therefore my opinions are illegal.
"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk
[ Reply to This | # ]
|
| |
| Authored by: dwheeler on Monday, April 17 2006 @ 09:39 AM EDT |
| I never thought standards were boring. Yes, many of the details of a standard
can be boring, but the selection of standards is anything but
boring.
Fundamentally, standards are about control and power. Who
controls your computer? Whoever controls your computer will control all the
information in your computer. If you let a supplier control your interfaces,
then fundamentally that supplier controls you. Open standards (where users can
switch suppliers) make it possible for users to control their own
destinies, freeing them from control of any particular supplier.
Moving to
open standards isn't always easy, but not all worthwhile things in life are
easy.
[ Reply to This | # ]
|
| |
| Authored by: davcefai on Monday, April 17 2006 @ 03:46 PM EDT |
I forget who said this but:
Standards are wonderful. That's why there are so many of them!
[ Reply to This | # ]
|
| |
| Authored by: jsusanka on Monday, April 17 2006 @ 05:54 PM EDT |
you go amd
I for one don't buy anything else except your amd 64 chips
I am sick of the microsoft/intel cartel.
I have one pentium 4 pc left and when that dies I will be
nothing but amd 64 chips.
this will be a very interesting case and we will actually
get to see the microsoft intel cartel in action.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 18 2006 @ 03:45 AM EDT |
Two steps forward, one step back. Time to clean up the mess that was WinTel,
once and for all.
The AMD story is one for the ages. They took a wild, beyond risky shot at
taking on the Tel part of the WinTel empire. And somehow they won. The risk
they took was based on a government mandate that Intel license the X86
architecture to would be competitors. This mandate reminds me of the DOJ
settlement with Microsoft mandating that Microsoft license the middleware API's
to would be server, device and desktop competitors. Intel however agreed to
offer comparatively reasonable licensing terms that, although reasonable, would
no doubt preserve the serious advantage they had. While Microsoft was allowed
to charge whatever they wanted – as in whatever was reasonable in light of their
efforts to extend their monopolist domain. The only requirement being that some
MS cartel members would actually pay the price asked for access to the
monopolist jewels. Intel had to provide equal access. Microsoft continues to
operate as if this inside information was a special permission that comes with
strings and obligations.
Against all odds, AMD took a long shot and prevailed, catching and tripping
Intel exactly where Intel tried to replace the 32 bit X86 architecture with a
newly proprietary IA-64 instruction set. From Wikipedia, “the IA-64 (Intel
Architecture-64) is a 64-bit processor architecture developed in cooperation by
Intel and Hewlett-Packard, implemented by processors such as Itanium and Itanium
2. The goal of Itanium was to produce a "post-RISC era" architecture
using EPIC.” Translated, the new IA-64 instruction set was not compatible with
the old X86 set.
AMD developed an AMD64 bit extension to the X86 set, and achieved far better
performance, able to run with the vast investment in X86 legacy applications
written to the Win32 API. The IA-X86 escape instructions Intel came up with to
run the wealth of legacy Win32 API applications totally bombed. Intel
eventually choose licensing the AMD64 set over being driven out of business.
Talk about turning the tables! And now AMD has enough power and influence to
exact revenge and demand enforcement of the Rule of Law. Finally.
I don't doubt for a second that Microsoft isn't in a similar position today.
The critical point is again the legacy of Win32 bound applications, services and
business processes. Almost the entire monopoly base of 450 million desktops is
bound to the Win32 API. Yet, here's Microsoft pushing forward with a .NET –
WinFX – XAML – C# - MSECMAXML bound XP-Vista stack. The Win32 API and all those
legacy Windows desktops are being EOL'd, support, maintenance and security fixes
having long ago ceased. Even on XP Professional there are serious problems for
legacy Win32 applications and drivers, rendering whole application libraries and
business processes next to useless. It will be far worse when Vista is
released.
Here's the thing; there is no AMD type corporate competitor in place to step
into the Win32 API breach, and carry those 450 million desktops into the age
collaborative computing. And do so with consumer legacy code investments intact
and performing as expected.
What we have instead is a gaggle of cross platform open source efforts able to
deliver collaborative computing within the Win32 API boundaries. Lead by core
productivity components, OpenOffice.org and Mozilla.org, a cross platform open
stack of applications able to provision an XML ready desktop productivity
environment is just a download away. If KOffice ever makes it to the Win32 API,
all hell is going to break loose, and Microsoft will have to fight like crazy to
hang on to their monopoly. The empiric half of the WinTel empire will be facing
the ultimate challenge; being undercut by outsiders who are seizing a rare
moment in time. The moment when Microsoft abandons the Win32 API, and tries to
force march at great cost and disruption, an angry user base. Marching them
into a collaborative computing future. Ever under the iron fisted control of
Redmond, this time across the entire integrated stack of XP-Vista OS, desktop
applications, middleware, API's, devices and server suites.
AMD got into position via their own tenacity and a long overdue government
mandate. Microsoft is exposed because of a hubris so elevated, so nauseating,
that they have lost all respect for developer network, their vast cartel of
trading partners, and the legendary user base long the envy of furtive
monopolist and empiric dreamers the world over. They were found guilty of some
of the most illegal and reprehensible business practices ever brought before a
court of law. Activities so lacking in any ethical or moral grounding as to
make Enron execs look like a bunch of boyscout's gone bad with some wayward
copies of National Geographic. And they got away with it. Hence a hubris and
disdainful disrespect unlike anything we've ever seen.
Thinking about it, i now wonder if the current DOJ Settlement was crafted in a
fashion similar to the Intel mandate that gave AMD a second life. Obviously the
European Union disagrees. They want those XP-Vista middleware API's released
without encumbrances or access barriers.
IMHO, the heart of the deliciously named Microsoft Anti Trust trial was the
issue of an essential carrier. In the case of the X86 instruction set, Intel
was alleged to be an essential carrier of computation. In the case of
Microsoft, Windows was found to be an essential carrier of computational
applications and services. There is something about connectivity, transport and
messaging“carriers” that the laws of efficient use of shared resources and
public access are warped into non competitive arrangements. Things like
bridges, railroads, turnpikes, cable, copper wires, electrical transmission,
radio frequencies, and computational platforms have led to either public
ownership or public regulation. The one thing we don't find is competition.
Building a second Golden Gate Bridge to compete right along side the original
just doesn't make any sense.
With Open Standards and open architectures, it's entirely possible to build
computational systems out of highly competitive components. Possible as long as
everyone agrees to the open standards for interfaces, protocols and methods that
make such interoperability between competing components possible. But who has
the foresight to predict which technologies will become essential carriers? Is
it possible that we are now entering an age when the challenge of winning
critical mindshare and marketshare is terminally clouded by concerns over open
standards, open Architectures, and open licensing models? I think so. I think
the days of the X86, Windows OS, and the controlling dominance of the Win32 API
are gone forever. Lesson learned. Now the challenge is to break loose from our
sordid past, and never make the same mistake again.
The answer to the essential computational carrier question is now bound up with
concerns for open standards and the methodologies of open interoperability. The
balance now sways with open source communities who excel in both these areas.
Things are changing. Perhaps much faster than vendors suspect. The old game
had these rules; if a vendor, or royalty sharing consortia of vendors can set
the “standards” for how things connect, interface, interact and exchange, they
can control markets. Control the terms of interoperability, and you get to
drive price and eliminate competition for years to come. Through control of
standards and the standards process, ruthless supply side opportunist could
dictate the terms of demand.
Brian Behlendorf comments that there are only two industries that refer to their
customers as “users”. Both industries share the characteristics of extremely
high profits for those who are in control; and, collusion between would be
competitors to carve up markets, eliminate competition, control of supply,
distribution, and the terms of demand so that high profits are perpetually
maintained.
In one industry these activities are illegal, even declared to be a threat to
national security and the well being of civilization. In the other, these same
activities are for the most part legal unless and until a monopoly has been
officially declared. Governments declaring at that point that such collusion
has gone to far, open and competitive markets need be restored, and the Rule of
Law (especially contract law) enforced.
Information technology consumers who get hooked on a suppliers proprietary
standards are continually pushed to purchase more from that providers cartel in
a never ending cycle of higher prices for less functionality. There are two
ways for consumers and outside the cartel technology providers to get back in
the game; Open Standards and Open Source implementations of those standards.
Personally i don't believe one is possible without the other. Least ways not in
a meaningful, lasting manner that truly guarantees that markets will remain open
and competitive, and, that consumers will finally be able to take ownership of
both their information and their information processes.
The emerging relationship between the open standards process, FLOSS influence,
and participation in that process is exactly how the rules of the game are
changing. It's still early in the day though. That FLOSS was central to the
build out of the Internet is beyond doubt. A few open protocols, methods, and
interfaces quietly brought the Internet to the point of notice as an alternative
platform of communications and collaborative computing. The Netscape IPO
brought the Internet into full public awareness, and the race to commercialize
what had been a public commons took off. And with that blast off came the
effort to assert control through the proprietary twisting of what were soon
dubbed “open standards”.
Corporate consortia proposals for vendor controlled standards followed the
incessant twisting of open standards. Both efforts designed to wrest control of
the Internet away from FLOSS and common public use.
These efforts were followed by much consortia posturing aimed at fooling the
public into thinking that patent encumbered and license restricted standards
proposals were actually big letter Open Standards.
The days of the Open Internet looked to be numbered.
Put me in the camp of those who would argue that Microsoft's war against
Netscape and Java were part of a larger effort to seize control of the Internet.
Or at least to take command of Internet based opportunities.
This first war was followed by an assault against the GPL and Linux, the
powerful one two punch at the heart of the exponentially exploding FLOSS
community development riding the wave of a global and open Internet.
The assault on the GPL and Linux has masked another, perhaps far more serious
assault launched on the next generation Internet API, “Open XML”. This
shouldn't come as a surprise in that XML is the future of the Open Internet. If
you seek to control the Internet, you have to somehow seize control and assert
ownership of XML. Since XML is owned, developed and openly licensed by the W3C,
it's very difficult to assert patent claims or ownership rights over the basic
XML methods and technologies. But given what is at stake, control of the
Internet, hungry vendors quickly go to the next best thing: seeking patents over
XML methods and implementations – over “how” XML is used - and, asserting
consortia control over the standards processes governing these implementations.
FLOSS communities have such power of participation and marketshare, that i think
they can bring daylight to the corrupt patent assertions , and, balance to the
open standards process.
FLOSS alternatives to proprietary software and services are proliferating, and
with that proliferation comes a greater awareness of the factors of great
interoperability: open interfaces, open messaging and communications protocols,
open run time engines and libraries, and Open XML technologies – including file
formats.
What the Open Internet and FLOSS share is that they are each a living, thriving
embodiment of how things can connect and work together. They also scream loudly
to the world what it is that is lacking in proprietary integrated technologies
and consortia controlled standards processes. Their very existence shouts out
that indeed, the emperor has no clothes.
As the Internet and XML increase in importance, invading every systems stack of
software and services known, there is a parallel rise in public awareness of how
important Open Standards and Open XML technologies are. Governments are now
routinely writing into their requirements binding definitions and demands for
Open Standards and Open XML technologies - leaving vendors increasingly less
room to wriggle, wrangle and obfuscate. A box that seems to get tighter with
each new requirements release.
One of the most important movements to watch is that, as the demand side of the
information technology marketplace becomes more involved in the open standards
process, so too must FLOSS communities. This is happening, but slowly. On
the OASIS OpenDocument XML TC, the process was very much multi vendor – multi
market driven except for one important factor. The two reference
implementations that everyone worked from, and every aspect of the OD XML spec
was routinely tested against, were the FLOSS implementations; OpenOffice.org and
KOffice.
The influence of ever present FLOSS communities worked to insure that there is
nothing theoretical about OD XML. Proposals to enhance or change the
specification were scrubbed by community developers and project managers before
making it into the formal specification. The proposals were public, and so was
the participation in how implementation issues were resolved. This benefited
the vendors involved in that they didn't have to disclose trade secrets or
compromise their corporate works by participating in the collaborative process
demanded to prove out a particular proposal. The OD XML spec benefited in that
it was road tested at the proposal level by a widely divergent but highly
collaborative group of developers. The participants were familiar with an
impossibly wide range of issues, spanning from possible interfaces, across
platforms and systems infrastructures, and into the many layers of
interoperability demanded by legacy connectivity and compatibility with emerging
collaborative computing needs. No matter what the problem, someone somewhere on
the Open Internet had been working on that same problem, and were more than
willing to contribute their expertise.
The OASIS ODF TC work now extends through four primary information domains: the
desktop productivity environment; publication, content and archive management
systems; SOA efforts; and the Open Internet. With Plone CMS ODF round trip
capability becoming the most recent announcement.
I would argue that the ODF implementations are far more important at this point
than the continuing open standards work at OASIS. The ODF 2.0 work will contain
some extraordinary advances concerning Accessibility, Open Formula, and a
Semantic Web Metadata model. But those enhancements would not make sense, nor
would they be proceeding so fast, if not for the expanding ecosystem of often
hybrid vendor and FLOSS efforts pushing ODF into parts unknown and uses never
dreamed of.
In many ways the involvement of FLOSS in the ODF standards process has set the
high bar for open standards in general. It may even be a peep into the future,
where FLOSS communities work everywhere with vendors and technology consumers to
craft open standards certain to accelerate the advance of this digital
civilization.
If anything, i believe the increasing involvement of FLOSS in Open Standards
will help insure that the Open Internet remains owned by none, open and useful
to all. The terms of an enduring interoperability are baked into the FLOSS DNA.
And that's a good thing.
~ge~
gary.edwards@OpenDocument.us[ Reply to This | # ]
|
|
|
|
|
