When Judge J. Frederick Motz recently threw Novell's WordPerfect antitrust case under a bus, ruling for Microsoft on its motion for judgment as a matter of law, his excuses seemed flimsy to me, at best. One of his reasons was that, in his view, when Microsoft withdrew support from certain APIs back in the '90s, Novell could have just used what they already had to at least come up with a makeshift solution to tide them over so as to be ready for the Windows 95 launch. He also found it important that Novell bigwigs didn't complain about the APIs to Microsoft at the time.
Was he right?
I want to show you some
emails from 1994 and 1998 our volunteers have just transcribed as text, from the collection of PDF exhibits in Comes v. Microsoft. The 1994 internal Microsoft thread includes Jim Allchin saying, in effect, that the company should deliberately make sure competitors' applications don't work as well on Windows as their competing applications do. That is precisely what Novell claims happened with WordPerfect, and in that exact time frame. The Allchin email
seems to match Bill Gates' notorious email about deciding to pull back on the API support ("We should wait until we have a way to do a high level of integration that will be harder for the likes of Notes, Wordperfect to achieve, and which will give Office a real advantage."). And then there are a couple of internal Novell emails from 1998 on problems with Microsoft, and finally a Gateway thread from the same general time frame, showing how Microsoft could really mess your business up, if Microsoft Help didn't want to help, which Novell says is what happened right after Microsoft pulled the API support.
Here's some background on how we got to this point in the Novell v. Microsoft litigation, in case you are new, or even if you are not. The case meanders along, back and forth to the appeals court and has been going on for years, but no matter how many times Microsoft seems to have sloughed Novell off its back, Novell hangs on like a barnacle. Now
Novell has decided to appeal Judge Motz's ruling, to the same appeals court that overruled his last decision [PDF] that tried to hand Microsoft a victory on a technicality without a jury trial, so stay tuned. Anything can happen.
Let's review a bit of what
Judge Motz wrote in his decision, before I show you the emails, so you'll see their significance. I've already written about Judge Motz's flawed middleware theory. Here's what he wrote about Novell being able to forge onward without the APIs, using just what they already had as a stop-gap solution:
Fourth, if, as Novell now argues, the 90-day period after the release of Windows 95 was critical to the success of WordPerfect, Quattro Pro, and PerfectOffice, Novell could have released those products using Microsoft's common file open dialog. In fact, Ford and LeFevre testified that they urged Gibb to pursue that option. (Ford, Trial Tr. at 3710-11, Nov. 30, 2011; LeFevre, Trial Tr. at 4041-43, Dec. 2, 2011). Actually,
Novell provided evidence by Gary Noll that they in fact did try that at first, but the help desk at Microsoft was no longer willing to help the way they had before. Some of the emails I'll show you confirm his testimony as being sufficiently plausible that a jury really should be the decider, in my view, not the judge as a matter of law.
In short, no reasonable jury could find, on the basis of the evidence presented at trial, that Microsoft's withdrawal of support for the namespace extension APIs caused Novell's failure to develop its applications within 90 days of the release of Windows 95.
And Judge Motz
also wrote that nobody at the top in Novell complained about it to Microsoft at the time:
First, as stated in section I ... there is no evidence that anyone at Novell made any complaint to anyone at Microsoft who could have reversed the decision to withdraw support for the namespace extension APIs.
But in the hearing [PDF] held on November 18, 2011 regarding Microsoft's original motion for judgment as a matter of law, when Microsoft's lawyer said that nobody at Novell complained to Microsoft at the time, the judge disagreed:
THE COURT: Well, again, this is a Rule 50 motion. I hear you, but I believe that Mr. Frankenberg testified that he did complain to Mr. Gates. One can question the credibility of that because there are no memos, but in terms of a Rule 50 motion don't I have to credit that?
So he knows that there was such testimony. Frankenberg did complain, and to Bill Gates himself, who presumably could reverse any decision he wanted to. Microsoft's lawyer said it was a generic complaint about undocumented APIs, not about these specific APIs in this litigation. And, he continued, "Microsoft continued to help Novell." But the emails I'm going to show you now show what Microsoft's help was like.
Novell sold off WordPerfect in March of 1996, but Novell still had to deal with Microsoft in connection with its other products. Let me show you what dealing with Microsoft help was like.
Here they are, first Exhibit 2921 [PDF]:
Does that sound like Microsoft was trying to be helpful? Here's a second email, Comes Exhibit 2922 [PDF], about the struggles Microsoft had created for Novell's GroupWise users:
From: Dennis Foster
To: Dave Wilkes; John Gailey; John Robertson
Date: Tue, Jun 9, 1998 3:46 PM
Subject: GroupWise vs. Outlook 98
On 05-21-98, I called our Microsoft Premiere Support
number to request help with the conflict between GW and
Outlook 98. I spoke to Barbara Thomas who generated case
My initial request was that MS consider it a bug that
Outlook 98 by default installs using the "Internet
Only" option for e-mail services. I told her that it
was our opinion that the Outlook 98’s setup program
should inspect the system it’s being installed on and
choose the "Corporate or Workgroup E-mail" option
by default if the Windows Messaging System (WMS i.e., MAPI)
was installed and profiles have been defined and choose the
"Internet Only" option by default otherwise. This
would probably eliminate 90% of the complaints we get as
I’m sure most people when reading the screen
containing these options don’t realize what’s
being said and simply go with the default as being
On 05-28-98 I received a call and e-mail from Barbara
telling me that my request had been investigated and Adam (I
don’t recall having heard his last name) from
Microsoft would be contacting me. On either the 28th or
29th, I got a call from Adam. He told me that MS views the
way Outlook 98 was operating as a "Feature", not a
bug. They would take my request and submit it as an
"Enhancement" for future development. I
discussed/argued the issue with Adam for several minutes,
explaining how by defaulting to "Internet Only",
Outlook 98 ends up breaking a GroupWise installation that
had up to the point Outlook 98 was installed, worked fine. I
explained to him that the setup screen made no mention of
MAPI services being changed and/or broken for applications
that need them. His response was that the user is given an
ample description of what was going to happen and that we
should "educate" our users to make the correct
selection during Outlook 98’s setup. All in all,
I’d describe my conversation with Adam as equivalent
to talking to a rock.
I believe that the changes I made to the address
book’s initialization flow last week is probably the
best that we can hope for without Outlook 98 changing. We
may want to add something to our README about this. The
check/change I put into Surge for Outlook 98 could easily be
retrofitted into a Jolt CPR build as well, assuming we
don’t mind the resource the changes.
FYI: Before I made the changes mentioned above, when
installing Outlook 98 using the "Internet Only"
default option, the following problems were encountered:
- No Novell address book service providers are
- There is no way to add them to your profile (the old
MAPI profile dialog has been replaced by something Outlook
- Sometimes (usually?), our call to login to MAPI fails (I
don’t fully understand why this happens).
- When we can login, Outlook 98’s LDAP service
provider causes us grief because of its problems
implementing the MAPI APIs we use. The problems here
- Calls to IMAPITable..Restrict GPF when passed
NULL for the restriction. This is the only documented way in
MAPI to delete a restriction.
- The way we use MAPI for LDAP services for Boldon
James and Nexor doesn’t work with the Outlook 98
provider. I’ve found two areas that we could/should
change that should be compatible with the Boldon James
and/or Nexor providers.
As you see, people believed it was purposefully anticompetitive. Was it? Before you answer, here's more that Microsoft was doing to Novell, from Comes Exhibit 2914 [PDF]:
From: John Gailey
To: Michael Buck; Rex Olpin
Date: Wed, Jun 10, 1998 2:20 PM
Subject: Win98 and Microsoft MAPI Service
In a clean install of Win98 (not over an existing Win95
installation), the Microsoft Windows Messaging System (MAPI)
is not installed. GroupWise 5.2 will auto-detect this fact
during install and will attempt to install the MAPI system
by accessing the Win95 CD. However, the MAPI system has been
moved to a different location on the Win98 CD, causing the
GroupWise 5.2 install to fail in its attempt to install
End-users can manually install the MAPI system from the
Win98 CD. To do so, they must run:
This self-extracting executable with install the MAPI
subsystem (and unfortunately, will also install MS Exchange
Inbox and MS Exchange Post Office.)
Rex, we need a TID written up for this for our current
GroupWise 5.2 customers.
Michael, we need a fix for this for the next GroupWise
5.2 service pack.
this is anti-competitive!
- John Gailey
CC: Bill Street; Craig Miller
Spreading FUD about "security" issues that didn't exist. Nice. Anticompetitive much? Of course, these emails are from 1998, too late for Novell to use. But wait. Here's the internal email thread that included Jim Allchin, 1994, that discussed how to pretend to get along with Novell and then take over networking eventually, and as it happens, it includes a smoking gun. Here's Mr. Allchin's suggestion for copying the technique they used with competitors' applications and Office to win in networking too:
To: Ryan Richards
Date: Sun, May 31, 1998 7:03 PM
Subject: Re: NDS for NT / LDS Church
This document that Gary provided is a common document
that is being delivered in many of our major market
Microsoft Consulting is coming into our accounts and
repeating this message over and over. (I think it is based
on a template.)
Actually, I am good friends with a guy at the Church
Office Building (Larry Adams) that could provide us with
more information if we need this from them.
(He is on the NT Domain project. Last time I was in town,
I had lunch with him and told him they should be doing
NDS4NT. He requested that the Church Headquarters give us a
fair shake in the evaluation process.)
I think that Kenneth Gaul should add this doc to his list
of issues around NDS4NT.
As a FYI, the jury is not out on Service Pack 4. There
seems to be several versions of the beta patch kit that is
floating out there to customers under NDA’s.
SP4 is supposed to be officially released sometime in the
month of June.
>>> Gary Hein 05/30/98 05:34PM
Don’t know if you guys have seen this document yet,
but it’s just another example of lies propagated by
MS. There are some very disturbing remarks, including:
Although it is possible to establish bi-directional
trust, the trust connection can not be used for
administering remote, unmigrated domains. This means that
centralizing management with NDS for NT requires a wholesale
conversion of the entire enterprise
Note that NT servers would need to run IPX/SPX to support
NDS for NT as well as TCP/IP to access other network
reqources and to comply with current standards.
GH: False - NDS for NT works over IP - no need to add
IPX. This is a scare tactic.
Service Pack updates are questionable at best. MCS has
not yet released Service Pack 4.0, however we suspect it
will replace the existing samsvr.dll. To protect against NT
Service Packs replacing samsrv.dll, NDS for NT checks at
shutdown time and replaces samsrv.dll with the Novell
version. MCS believes potential for failure is very high, as
soon as any dll starts depending on new exports from
samsrv.dll. Replacing this one critical dll could case the
system to fail to boot and recovery could be very difficult.
GH: Perhaps advance knowledge of SP4?
Microsoft has repeatedly stated that it will support
their NT customers and NT’s basic functionality, but
in areas that NDS touches, namely security and
authentication, Microsoft will refer customers to Novell.
This has the potential of creating some confusion in the
resolution of issues revolving around security and
GH: Scare tactic
Also, comments from PeopleSoft should be solicited to see
if PeopleSoft and Tuxedo are supported in environments where
NDS for NT is in use as well as the IntranetWare client.
GH: Is it possible that MS is telling NT developer that
they should not support their products with NDS for NT?
Windows NT has a feature where anonymous logon users can
list domain user names and enumerate share names. Customers
who wanted enhanced security requested the ability to
optionally restrict this functionality. Windows NT 4.0
Service Pack 3 and a hotfix for Windows NT 3.51 provide a
mechanism for administrators to restric the ability for
anonymous logon users from obtaining system information.
These anonymous connections are also known as NULL session
connections. During the installation of Novell’s NDS
for NT, the samsrv.dll is replaced. Novell NDS for NT
currently does not include support for restricting anonymous
connections. MCS see this deficiency as a security weakness.
GH: This is the Red Button attack, which MS
‘claims’ is fixed with SP3, but really
isn’t. Again, this is completely incorrect - using NDS
for NT will not impact the security flaw mentioned in this
Anyhow - I don’t know if this is of any use to you
but I thought I’d forward it over anyway.
CC: David Bradford
It is a fine line (compatibility vs. enhance), however we should focus on making Chicago and Daytona&Cairo work better than Chicago and Novell. I'm not saying that the UI shouldn't be improved, but I'm saying that much more focus should be put into making our systems seamless together. If we don't do this, then we are not using the strength of being in the same company. In short, it was a plan to make Microsoft's products work better with other Microsoft products than they did with Novell's. Microsoft, the email crows, could do with networking what it had already done with apps in Office.
One of (the?) largest new business area within MS is the server business. It is clear that tight integration with the client is required to win. It's no different than our apps in Office. Sure our apps will work with other apps, but they sure work better if they are our apps. (Maybe Lotus is a better example here, I don't know.)
And in 1994, the competition to Office was WordPerfect.
Here's the Allchin thread in full, Comes Exhibit 1951 [PDF]:
It wasn't just Novell, by the way. Here's a 1997 internal Gateway email to then-CEO Ted Waitt about all the things going wrong in the Gateway-Microsoft partnership, Comes Exhibit 2734 [PDF], where Gateway employees look for direction as to whether it would be worth it to complain to Steve Ballmer and if so, how much to say:
Comes v. Microsoft
To: bradsi; jimall;paulma
Subject: RE: Network strategy and NCP
Date: Wednesday, January 05, 1994 7:18AM
we too want to have a substantial position in the network business. but
co-existence seems to be a better route to that position than the creation of
alternative non-coexisting technologies. novell does have 70% of the market, i
haven't seen a business plan from anyone where that changes substantially over
the next 5 years.
so given this, i want our client to be a natural thing to buy for this 70% of
the market, so i want to do a great job co-existing with netware and enhancing
the client side of netware so that these customers have a strong reason to buy.
if we can establish the ms client as the natural network client on install on
all nets, then we have made a big step up. we have strong competition in this
area – novell is serious about PNW, they have added quality people to the team
(Kyle Powell), they want to kill our network client and establish their own as
the standard Windows Network desktop. we are in a position of strength here, WFW
is outselling PNW, we need to grow this lead. this implies being a better NW
client than PNW.
from this base we can then provide extended functionality and expand the
protocols as needed. I don't understand why we wouldn't use extended ncps for
our extensions – it makes it that much easier for 70% of the market to use our
extensions. i don't think file system protocols are a strategic technology –
they are just a technology that we should use or discard as it makes engineering
sense. what is strategic is the quality of our client and server implementations
– ease of use for users and admins, robustness, scalability, performance. file
system protocol has no measurable impact on these metrics – we have yet to
identify a distinctive advantage of NCPs that we cannot achieve in SMBs or vice
i think we should pursue similar tactics on the server side – build a great
server that is compatible with the largest part of the market, and then provide
extended functionality on top of that.
i don't think we have done a very good job of analyzing the competition in this
debate. at this point, novell is quite aware of all our plans for cairo and
chicago. we have to assume that they are going to provide a system that they
will represent as having the same capabilities as cairo. i wonder how easy that
system will be to trial and deploy in real customer nets – i suspect that on our
current path, it will be easier to deploy the novell solution in an existing
netware net than it will be to deploy the cairo system. And i suspect the
immediate tangible benefits of the novell solution to a netware user will be
greater than the immediate tangible benefits of the cairo solution. for these
reasons, i think we need to be more netware compatible than we are
finally, i worry a great deal about novell's continued growth in the ncp file
server business. their continued unopposed dominance of this business gives them
an incredible amount of cash with which they are funding their entry into every
other part of our business. i think a more direct attack on this cash flow would
be welcomed by customers, lucrative for us, and would lessen novell's ability to
fund other investments.
it is pretty clear we are not coming to closure on this. i'm no
convinced it is appropriate to come to closure. Perhaps we need two distinct
efforts – one effort to provide very netware-compatible systems, and one to
provide and alternative. lowering our risk by placing 2 bets against our largest
threat doesn't seem like a terrible thing, in fact it seems like a time-honored
|From: Jim Allchin
|To: bradsi; johnlu; paulma
|Subject: FW: Network strategy and NCP
|Date: Tuesday, January 04, 1994 7:18PM
|I know bob didn't expect me to forward this private piece of mail,
|I agree with the major points he included and I thought others
|see this. (Bob, forgive me.) Above and beyond the NCP issue,
|wanted to point out the critical importance of synergy of the
|products. They have to be “made for each other”.
|NBU made two major mistakes (1) trying to ignore the compatibility
|aspect that is required with a competitor that owns 50-60% of the
|market and (2) simply copying Novell and not offering any real
|add. We won't make those mistakes again. However, we could make
|another very bad mistake by enhancing Netware networks with our
|clients. We should not do this. It is a fine line (compatibility
|vs. enhance), however we should focus on making Chicago and
|Daytona&Cairo work better than Chicago and Novell. I'm not
|that the UI shouldn't be improved, but I'm saying that much more
|should be put into making our systems seamless together. If we
|do this, then we are not using the strength of being in the same
|One of (the?) largest new business area within MS is the server
|business. It is clear that tight integration with the client is
|required to win. It's no different than our apps in Office. Sure
|our apps will work with other apps, but they sure work better if
|are our apps. (Maybe Lotus is a better example here, I don't know.)
|From: Bob Muglia
|To: Jim Allchin
|Subject: Network strategy and NCP
|Date: Saturday, January 01, 1994 1:06PM
|Jim, I haven't been involved in the detailed discussions on this
|so maybe this is totally obvious. But then again.... I marked this
|high-priority because I think it's worth reading and I know what
|email queue is like.
|It's very clear that personal and corporate systems are out-of-sync
|whether we develop future enhancements based on NCP or SMB. It is
|totally clear that we MUST get in-sync. What is not clear is WHY
|we're pursing different paths. This issue is not about manpower or
|client memory size, it is about strategy.
|Fundamentally, there are two possible networking business strategies
|can pursue – co-existence or ownership. Everybody agrees that
|networking today equals Novell. The question is, do we accept this
|assune it will remain true for the foreseeable future, or is it our
|STRATEGY to change that? If we are pursuing an ownership strategy,
|then we need to take appropriate steps NOW. We need to use every
|weapon at our disposal to take them out.
|Clearly, I view it as my job to increase our network market share
|replace Novell wherever possible. Eventually, I want MS to have
|market share. However, I don't think there is universal agreement
|this is a practical plan.
|If we believed that Novell will continue to dominate the networking
|world in the foreseeable future, then we would need to focus on
|maintaining our client franchise while building a profitable
|selling server solutions into Novell environments.
|In this model (co-existence), our client-side networking effort
|be primarily focused on making sure that we have great connectivity
|into Novell servers. We would need to expend this energy because
|Windows franchise depends on Novell connectivity and we cannot rely
|Novell. Since we assume it will be a Novell world, we must clone
|of their features to ensue we remain competitive. In many ways, we
|really don't care whether customers use our software or Novell's to
|connect to their Netware servers – we just want to make sure the
|connectivity is there. We would also focus on cloning their API,
|just to make sure clients work great in a Novell environment.
|Since all customers use Novell, when we add networking features we
|to make sure they work great with Novell servers. Chicago point and
|print support on Novell print servers is a good example of this
|Clearly, SMBs are irrelevant and we should just adopt NCP.
|On the server side in a co-existence world, our focus would be to
|value into Novell networks. NT SQL Server with Novell clients is a
|great example of this. Further, if we really believed that
|co-existence was our destiny, then Cairo is not properly focused.
|Cairo would be thought of as additional services for Novell
|For example, it would be important to content-index Novell
|Also, our whole directory plans would be in question – why bother
|NW4 will be installed in almost every customer site? Instead, we
|would focus on adding value to NW4 installations.
|On the other hand, if our focus is to own the networking business,
|we would do things very differently. We need to do everything we
|to encourage customers to buy MS networking software instead of
|The key points:
|1. Own the API and get ISVs to write to it. This is the first rule
|systems software. If Novell loses control of the application API,
|our ability to displace them in installations is vastly improved.
|Interestingly, Novell is weak on this point. Although they are
|pursuing a similar strategy with Appware, we are in a stronger
|with our Windows run-rate and our strong relationship with ISVs. We
|can use our NW clients to get MS software installed in a large
|percentage of customers systems. When our software is running, we
|add APIs. If these APIs are attractive to ISVs – say they are
|cross-NOS instead of Novell specific, we can get ISVs to write to
|Specifically, I suggest we add Win32 WOSA APIs in areas which we
|currently don't cover. Administration is one good example.
|Even on the server side, Novell has weaknesses we can exploit. NLMs
|are hard to write and they have a confused strategy wrt Unixware.
|we really need to do here is continue our evangelism effort to get
|server apps written for NT.
|2. Leverage Windows to differentiate MS Networking software. When
|add new networking features for which Novell has no native services,
|should focus on making them work on MS networks. If Novell catches
|and adds support, then we can add support for Novell. A perfect
|example of this is point and print support in Chicago. NT already
|supports this, there is no equivalent concept in Novell print
|When Chicago ships, this should only work on NT and Chicago systems.
|Other examples are only supporting content indexing of OFS drives
|only supporting catalog storage on OFS volumes.
|To be clear, I am not suggesting crippling Novell installations. If
|Novell supports a feature – for example, long filenames or
|authentication, then we should support it. My point is lets not go
|of our way ti make things work on Novell. Instead, lets use these
|new features to give customers REASONS to buy MS software on the
|3. Interoperate, make migration easy. Our network clients need to
|support all of the Novell features our customers demand. They need
|be as good or better than the ones Novell provides so that
|have no motivation to install Novell's client. We need to make it
|for customers to migrate from Novell servers to NT AS. We need to
|terminology which is familiar to Netware administrators. We have
|done a great job on this in the past but we are now focused on
|We should also take advantage of tactical opportunities to install
|server solutions into Netware networks. This can provide a foot in
|door for further sales.
|4. Equal Novell in performance, add features they cannot easily
|No surprise here. This is our plan with Daytona and Cairo.
|5. Establish a strong channel. We can't win without doing this,
|however it is a separate topic.
|If we are on an ownership strategy, should our file protocol be NCP
|SMB? I contend that if we are to gain control of the networking
|business, each major component must be either owned by MS or an
|standard. Transport stacks are critical components but we have
|to focus on industry standard protocols which are widely used (IPX
|TCP). If NCP was an open standard , then we could consider using it
|our file-level protocol. However, it most definitely is not. It is
|clearly proprietary to Novell and is thus controlled by Novell.
|Since Novell controls NCP outright today, we cannot hope to own it
|the future. The best we could hope for is that it becomes an open
|standard. Yet, this too is a long-shot. I think this is analogous
|Sun's attempt to make the Windows API an open standard. Any attempt
|make to change NCP into an open standard will fail for the same
|Sun will fail with Windows – Novell can (will) choose to pay no
|attention to the standard and will implement new features which
|continually leave us behind.
|Because I believe that we are on an ownership strategy and because
|need to control our own destiny, we should consider SMB our
|protocol and should base new features on SMB. We still need to
|implement NCP for compatibility purposes but we should not consider
What do you think? People back then were afraid to complain, because if Microsoft, monopoly that it was, wanted to hurt you, it surely could. And there was no one standing in their way.
To: Ted Waitt, Bill Elliott
From: Penny L. Nash
Date: July 11, 1997
Re: MS Relationship Issues for Steve Ballmer
CC: Jim Collas, Jim Von Holle, Kathy Skidmore & Jim
Per your request here are a list of Relationship issues
concerning Microsoft. Please review and provide your
comments as to how much of this should be sent to Steve
In the past six to twelve months we have seen a steady
decline in the over all business relationship between our
two companies. The below examples show this decline.
- Obvious negative treatment due to our differences
- Competitors continued Sales of Office 95 beyond
contractual cut off dates.
- Adding new application titles/bundles to support our
Software Strategies has become burdensome and time
consuming. This has created unwillingness to use MS content
in our bundles or our software strategies.
- MS causing delays in software PO shipments (due to
licensing issues in MS’ Troika System), which have
ccaused Stop Ship situations (UK & APAC) and risks
little or no inventory levels globally. This had rarely
happened in past years but became very noticeable in the
last 3-6 months on a "global basis". This has
created negative feelings toward MS and unwillingness to use
- Lack of support/responsiveness from our Account Mgr on
- When issues are communicated they are immediately
delegated. Very little communication (takes days or with no
return call or mail) or ownership of issue resolution.
- When issues are delegated, the person(s) to which the
delegation is given do not have decision making authority,
thus creating delay in resolution. Often requires escalation
to get immediate attention to issues.
- Often are referred to others within MS to get movement on
things and are frequently told "this is not my
responsibility you need to talk to..." (e.g. Agreements
with other divisions of MS). When issue reach a higher level
(either at GW or MS), we then see moment (CYA mode begins).
- RFQ for Mouse - MS was one of three Mouse Suppliers that
was sent this RFQ. MS did not reply, BF stated the he felt
that they did n ot need to reply because of our current
contract and committments.
- Very Little Trust in our Account Mgr or OEM Team
- Net PC Specification. GW involved in discussions but not
part of the OEM Team in drafting this specification (Dell,
Compaq, HP & Intel) with MS.
- Country Store Proposal provided to incorrect contact after
being specifically informed of correct contact and
- No copy to Supply Management (for tracking) or correct
contact for timely reply. Appears that MS is trying to
divide us. Causes frustration on both sides and creates a
negative opinion of MS on our side.
- Very Little Trust in our Account Mgr or OEM Team
- Often get mixed/numerous mixed messages/communication.
Causes delays in action, no accountability on either side
and frustration on both sides (but yet this continues even
after communication of GW’s Supplier Policy from GPO
& Supply Mgmgt).
- Sets up meetings with GW representatives with no
communication to Supply Management or GPO, both internal at
GW and off-site at MS. This creates mixed messages, no
accountability on either side and inconsistent messaging
from GW. (but yet this continues even after communication of
GW’s Supplieer Policy from GPO & Supply Mgmgt).
- Limitations on GW Flexibility
- Changes in policy with no communication.
- Changes to Windows 95 CD
- Funding for Premier Support Services Contract.
- MS dictates how GW should deliver product to our customer
even when supplied with compelling proof of our customer
needs/frustrations on their product(s).
* * Note
- 2/97 - Dell/Micron Continued Promotion/Sales of Office
Pro 97 Upgrade Program at N/C
GW cut off per contract 2/1/97. GW complied with contract
cut off date. In prior discussions MS stated that
"All" OEM’s license to offer this Upgrade
ended on 2/1 as well as sales of Office-95 & 4 3
~ GW $30 Upgrade option at point of sale 2/3 - 2/23.
- GW ended Program on 2/23 per our agreement.
~ 2/26 MS BF notified of Dell continued sales of Coupon
Program with purchase of Office 95
- MS response that Dell was to Stop on 2/1, but was also
given the same point of sale upgrade option as GW ending
2/23. The Dell rep was notified that this to stop
~ 2/27 Dell still offering Office 95 & Upgrade Offer.
~ 2/27 GW turned $30 Upgrade Offer back on pending Dell
discontinuation of program.
- MS BF very unhappy of our decision to turn program back
- Provided his authorization with restriction; should only
be used if we could loose a sale.
~ 2/28 Call placed to MS BF. No resolution
~ 3/3 Discovery of Micron’s promotion of Office 95
with "free" Upgrade Coupon.
~ 3/3 MS BF Notified.
~ 3/4 Dell discontinues Office Pro 97 "free"
Upgrade and begins offering at $215.
~ 3/4 Micron continues Office 95 as standard with
"free" Upgrade Coupon to Office 97 SBE or $29
upgrade to office Pro 97.
~ 3/6 Dell offering Office 97 SBE as standard with $215
upgrade to Office Pro 97.
~ 3/6 Micron offering Office 97 SBE as standard with $199
upgrade to Office Pro 97. Still offering Office 95 on some
~ 3/7 Micron now in compliance.
** Calls placed daily to MS BF.
** Numerous discussions of GW’s business with MS Dell
- Quote: "What ever MS gives GW impacts the Dell
** Threats of making sure that Dell and GW do not have an
advantage over the other to end the political war.
- 3/97 Request for GW Australia to provide fulfillment of
Office Pro 97 Media from GW Sydney
GW reasoning, low volumne numbers and cost effectiveness.
This request was provided to previous OEM Acct. Mgr. which
was never addressed prior to New Acct. Mgr.
~ MS BF reply - NO!
- Determining factor for this answer was that MS has traced
Grey Market distribution of Office Products to GW2K.
- Cost issue addressed again with BF and he states;
"then why are you doing business there?"
** Any notices or questions regarding Grey Market
Distribution of MS Products have been addressed with proper
resolution. Only one on record at GW.
- 3/97 Allegations of Grey Market Distribution in
~ 3/20 MS BF requests information on GW System Sales into
Egypt (GW OEM Product found in Grey Market).
~ 3/21 Total of 3 systems sold into Egypt from Jan. - March
- 1 to US Embassy
- 1 to US Citizen
- 1 Destination to Distributor (no application SW)
~ Issue Dropped.
- Modifications to Win 95 Backup CD
In the past MS has provided authorization to make additions
to the Win 95 CD (from late Q3 94 until recently Q1 97).
These changes provided our customers the availability of one
location for all files needed for re-installation of the OS.
Since the arrival of the New Acct. Mgr. MS has stated that
GW can not continue to make "any" additions to the
Win 95 Backup CD due to policy change.
~ Policy Change was never communicated to GW until first
discussion with BF.
~ OSR (Operating System Release) releases. We receive
OSR’s from MS with fixes, added files, drivers, etc...
MS will not allow GW to incorporate these releases into the
Win 95 backup CD deliverable, MS is requiring that GW
deliver the OSR on a separate media (diskette: adding
COG’s). Numerous discussions with MS with a reply of;
"We have NO resources available to do this, they are
working on Memphis and we can not afford to pull anyone off
at this time."
~ Pix 4 (Intel & Microsoft) - Requested that MS address
issue. Main issue for GW 1) customer satisfaction/OOBE (out
of box experience) issues regarding Windows ‘95 which
would provide one location for the customer & 2)
providing the necessary files for the New Technology.
- GW’s request stalled by Acct. Mgr. BF
- Files needed are MS files, but MS would still not provide
GW the approval to add to Win 95, only provided approval to
add to separate CD or ship on diskette.
~ Enabling USB. GW needs USB integrated into the setup of
- Numerous discussions with numerous individuals at MS. No
movement from MS. USB is a top priority for GW.
- Win NT 4.0 Service Packs (SP’s)
~ MS does not provide OPK (OEM Preinstallation Kit) for
Service Packs. Thus it creates increased download time
(manual download), decreased manufacturing productivity,
increased support calls and increased customer dis-
- GW has requested that SP’s be provided in OPK form.
MS has not provided OPK to date.
~ MS does not permit us to incorporate Service Pack into our
Win NT 4.0 CD Deliverable, MS requires that GW provide on
separate media (1 additional CD adding additional
~ MS has been provided backup data outlining our issues,
added costs, time, etc... with no reply other than;
"there is NO OPK available and NO resources to create
- Premier Support Agreement
~ In past years (4+) MS OEM Sales has funded 100% of this
~ MS has stated that OEM Sales will no longer fund this
agreement moving forward.
- The 97-98 Agreement MS OEM Sales will only fund 80% of
this agreement and GW is responsible for the balance. Total
cost of this Service Agreement is $60,000. MS OEM Sales is
funding $40,000 and GW is responsible for the balance of
- Future Licensing of Past versions of MS Operating
~ Questioned MS on concerns from MA Customers.
- MA Customer(s) are hearing (from MS Field Sales Reps) that
GW will be loosing their ability to offer past versions of
~ MS BF stated that he has not seen the new version of OS
Agreement therefore he can not address the issue. Concerning
the rumors, at this time there are no plans to change your
choice of OS’
- Licensing of MS Application Titles
~ Contract amendments for simple product additions take
weeks and numerous calls to follow-up before action is
~ This has created delays in time-line execution for product
launch, unwillingness to use MS content in our bundles or
our software strategies.
~ MS’ pricing for their products is way out line
compared to other SW Suppliers with just as or better
- Missing Licensing Information from MS’ Troika
~ All Regions including US have had numerous instances in
the last 6 months where our Replicator’s can not
produce or ship product to GW to fulfill our PO’s due
to the fact that MS’ system shows GW as not being
licensed for a particular product(s).
- MS has made it perfectly clear to some specific AR’s
that if they ship said product(s) they risk their AR License
- In some instances this has resulted in a STOP SHIP
situation for several days.
- In others, it risks little or no inventory levels globally
which could/would have caused a STOP SHIP situation.
~ Each instance has resulted in days of calls both with MS,
the AR and our Subsidiaries before resolution was reached.
This had rarely happened in past years but has became very
noticeable in the last 6 months on a "global
basis". This has created negative feelings toward MS
and unwillingness to use MS content.
Example: MS Mouse Drivers - GW has been licensed for the MS
Mouse for many years. The contract is 3+ years in the
making. GW has been reproducing the Mouse drivers for years
per the terms of our agreement. Recent PO’s have been
put hold by MS; 1) questioning our quantities, 2) stating
that we do not have the right to reproduce & 3) stating
we do not have the rights to distribute separate from the
Mouse. All of these issues are outlined in the contract
and/or amendments providing us the license grant to do so.
~ We had to provide the proof to MS.
~ We supplied the language locations in the agreement(s).
- BF has not been involved in this issue. He delegated it to
his admin to handle. Neither BF or his admin took the time
to review or have knowledge of this agreement prior to
placing our PO’s on hold.
~ To date our PO’s are still on hold pending our
answers to questions on our large PO quantities.
This situation alone has created a willingness to bring in
"new" Mouse Supplier.
- No Reply to RFQ for Mice
MS was one of three Mouse Suppliers that was sent this RFQ.
MS did not reply, BF stated the he felt that they did not
need to reply because of our current contract and
- Our minimum committment with MS has been met.
- Our contract with MS expires at the end of 1997
Other Mouse suppliers can provide the same type of Mice as
MS but a significantly lower price point than MS. Thus the
RFQ to bring MS to the negotiation table for our business.
- MS Mtgs held with GW representatives On-site & Off-
site with no notification of Supply Management or GPO
~ Numerous Mtgs with GW representatives
- No Accountability on either side
~ Marketing invitation to OEM Acct. Mgr. to Golf with GW
Mens Golf League
- Threat that he may have come in contact with information
that he should have had access to.
Gateway 2000 Inc.
If all the world were like Judge Motz, there still would be no one. And that would be a crying shame. Happily, he is not the only judge in the world, and the US legal system provides for review. That is the next step.
And if everyone here could do just one Comes exhibit PDF as text, we'll be done. We decided to make the exhibits searchable, because the parties in the litigation were complaining that neither of them could find a way to search the collection's PDFs, which were named only by number. So for historians, we began the project. And we are almost done. So please lend a hand. Pick one that no one has done yet, leave a comment that you are working on it here, and then post it in plain text mode with the plain HTML showing, so I can copy and paste. Thank you if you can.