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

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.

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?

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 SRX9805216011611.

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 "safe".

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 available
• There is no way to add them to your profile (the old MAPI profile dialog has been replaced by something Outlook 98 specific).
• 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 include:
  • 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.

Dennis.

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 MAPI.

End-users can manually install the MAPI system from the Win98 CD. To do so, they must run: toolsoldwin95messageuswms.exe

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!

Aaarghh!!!

- John Gailey

CC: Bill Street; Craig Miller

From: BHENDRICK
To: Ryan Richards
Date: Sun, May 31, 1998 7:03 PM
Subject: Re: NDS for NT / LDS Church

Ryan,

This document that Gary provided is a common document that is being delivered in many of our major market accounts.

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.

Stay Tune!!

Ben Hendrick
Novell Consulting-Atlanta

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

GH: False

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 authentication.

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 document.

Anyhow - I don’t know if this is of any use to you but I thought I’d forward it over anyway.

Thanks,

Gary

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.

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]:

PLAINTIFF'S
EXHIBIT
1951
Comes v. Microsoft

Erik Stevenson
------------------

From: johnlu
To: bradsi; jimall;paulma
Cc: bobmu
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 versa.

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 today.

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 longer 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 microsoft strategy.

----------
|From: Jim Allchin
|To: bradsi; johnlu; paulma
|Cc: bobmu
|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, but
|I agree with the major points he included and I thought others should
|see this. (Bob, forgive me.) Above and beyond the NCP issue, I
|wanted to point out the critical importance of synergy of the systems
|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 value
|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 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.
|
|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.)
|
|jim
|
|
|----------
|From: Bob Muglia
|To: Jim Allchin
|Subject: Network strategy and NCP
|Date: Saturday, January 01, 1994 1:06PM
|Priority: High
|
|Jim, I haven't been involved in the detailed discussions on this issue
|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 your
|email queue is like.
|----------
|
|It's very clear that personal and corporate systems are out-of-sync on
|whether we develop future enhancements based on NCP or SMB. It is also
|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 we
|can pursue – co-existence or ownership. Everybody agrees that

|networking today equals Novell. The question is, do we accept this and
|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 and
|replace Novell wherever possible. Eventually, I want MS to have 70%+
|market share. However, I don't think there is universal agreement that
|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 business
|selling server solutions into Novell environments.
|
|In this model (co-existence), our client-side networking effort would
|be primarily focused on making sure that we have great connectivity
|into Novell servers. We would need to expend this energy because our
|Windows franchise depends on Novell connectivity and we cannot rely on
|Novell. Since we assume it will be a Novell world, we must clone all
|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, again
|just to make sure clients work great in a Novell environment.
|
|Since all customers use Novell, when we add networking features we need
|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 add
|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 networks.
|For example, it would be important to content-index Novell networks.
|Also, our whole directory plans would be in question – why bother when
|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, then
|we would do things very differently. We need to do everything we can
|to encourage customers to buy MS networking software instead of Novell.
|The key points:
|
|1. Own the API and get ISVs to write to it. This is the first rule in
|systems software. If Novell loses control of the application API, then
|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 position
|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 can
|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 them.
|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. All
|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 we
|add new networking features for which Novell has no native services, we
|should focus on making them work on MS networks. If Novell catches up
|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 servers.
|When Chicago ships, this should only work on NT and Chicago systems.
|Other examples are only supporting content indexing of OFS drives and
|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 out
|of our way ti make things work on Novell. Instead, lets use these cool
|new features to give customers REASONS to buy MS software on the network.
|
|3. Interoperate, make migration easy. Our network clients need to
|support all of the Novell features our customers demand. They need to
|be as good or better than the ones Novell provides so that customers
|have no motivation to install Novell's client. We need to make it easy
|for customers to migrate from Novell servers to NT AS. We need to use
|terminology which is familiar to Netware administrators. We have not
|done a great job on this in the past but we are now focused on these
|issues.
|
|We should also take advantage of tactical opportunities to install our
|server solutions into Netware networks. This can provide a foot in the
|door for further sales.
|
|4. Equal Novell in performance, add features they cannot easily match.
|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 or
|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 open
|standard. Transport stacks are critical components but we have decided
|to focus on industry standard protocols which are widely used (IPX and
|TCP). If NCP was an open standard , then we could consider using it as
|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 in
|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 to
|Sun's attempt to make the Windows API an open standard. Any attempt we
|make to change NCP into an open standard will fail for the same reason
|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 we
|need to control our own destiny, we should consider SMB our strategic
|protocol and should base new features on SMB. We still need to
|implement NCP for compatibility purposes but we should not consider it
|strategic.
|
|bob

HIGHLY CONFIDENTIAL
PURSUANT TO
PROTECTIVE ORDER

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 Wharton

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 Ballmer.

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 regarding Office.
  - 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 MS content.
• Lack of support/responsiveness from our Account Mgr on addressing/resolving issues.
  - 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 cc’s.
  - 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 Cont’d
  - 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 immediately.
  ~ 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 on.
  - 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 lines.
  ~ 3/7 Micron now in compliance.
  ** Calls placed daily to MS BF.
  ** Numerous discussions of GW’s business with MS Dell Rep.
  - Quote: "What ever MS gives GW impacts the Dell Account."
  ** 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 Egypt
  ~ 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 ‘97.
  - 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 Win 95.
  - 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- satisfaction.
  - 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 COG’s).
  ~ 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 one."
• Premier Support Agreement
  ~ In past years (4+) MS OEM Sales has funded 100% of this Support Agreement.
  ~ 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 $20,000.
• Future Licensing of Past versions of MS Operating Systems
  ~ 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 Windows products.
  ~ 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 taken.
  ~ 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 compelling titles.
• Missing Licensing Information from MS’ Troika System
  ~ 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 with MS.
  - 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 committments.
  - 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.
Confidential Information

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.