  
About ten days ago, a federal jury in L.A. returned a verdict against STAC on a trade-secret claim by Microsoft.  The jury even awarded punitive damages because it considered STAC's actions deliberate.   Since then, STAC's president, Gary Clow, and others have devoted an enormous amount of energy on these forums trying to foster the belief that Microsoft will use this verdict to pursue claims against third-party developers who legitimately use debugging tools to achieve or maintain compatibility with 
Microsoft's operating systems. These statements just aren't true.  Nor are 
STAC's claims that all they did was use a few undocumented calls.  STAC 
disassembled and analyzed a sizable chunk of MS-DOS itself to understand its 
internal design.  Then STAC used that knowledge to write code identical in 
functionality for STAC's own product.  The preloading program copied by STAC 
is one that integrates data compression seamlessly into the internal 
operations of MS-DOS to allow data compression to be performed in a safe, 
easy, and efficient manner.  This had nothing to do with undocumented system 
calls. (STAC did intercept a few internal calls but this was the least 
significant part of our design and not the reason we sued them.)    

Information obtained during the discovery phase of the case, through diaries 
and testimony of STAC developers, and confirmed during the trial, shows that 
STAC did not merely analyze the compression integration portion of MS-DOS 6 
but disassembled and copied the design, functionality,  features, and 
processes of more than 3,000 lines of MS-DOS compression integration code.  
(By comparison, the compression technology of DoubleSpace, which STAC sued 
Microsoft over, involved only about 1,500 lines of code.)  

At the trial, STAC produced a number of expert witnesses who testified that 
they regularly  "reverse-engineered" other programs, and STAC is using that 
as "proof" that other developers are on his side.  In fact, during 
cross-examination, every one of STAC's witnesses said they defined 
"reverse-engineering" to mean analysis for debugging or compatibility testing 
and not for disassembling and copying someone else's work.  STAC's final 
expert witness, Jim Sesma, a developer not affiliated with STAC, was 
specifically asked whether he had ever reverse-engineered or disassembled 
one of Microsoft's products in order to copy the internal design into another 
product.  His answer: "No, I have not.  That is not the intention of anything 
that I would do."  

Our outside expert witness testified that STAC could not have done what it did 
with a simple debugger or usual debugging techniques, and that what STAC did 
went far beyond what anyone in the industry would consider necessary for 
compatibility.  In fact, STAC's existing product was already compatible with 
MS-DOS 6, and evidence was presented at trial showing that STAC had other 
technical avenues for preloading that would not require STAC to disassemble 
and copy Microsoft's designs.   For example, IIT's XtraDrive product replaces 
the boot sector with its own code that loads their driver into memory before 
loading IO.SYS, so they get a preload effect without having to use Microsoft's 
technology.  Digital Research took still another technical approach to 
integrating disk compression in DR DOS 6. STAC did not need our trade secrets 
to solve its technical problems; taking our intellectual property was merely 
the most expedient way to do so.  

Andrew Schulman and one or two other authors have claimed in various public 
forums that Microsoft's compression integration design is not a trade secret 
because it has been documented in at least two books, including Schulman's own 
Undocumented DOS.  Schulman's book, however, documents less than 2 percent of 
the compression integration design.  This provides some understanding of the 
relative amount of weight in the integration design between the overall 
feature set of the program and the few internal operating system calls used.  
Schulman and other authors substantially understate the daunting challenge of 
uncovering and documenting the complete, detailed technical design that would 
be necessary to replicate an entire subsystem within the operating system, 
which is what STAC did.  For example, Schulman has not been able to document 
how MS-DOS 5 (released three years ago) loads itself into high memory, and 
that task is far simpler than the compression integration of DoubleSpace.  
STAC was able to copy Microsoft's work only after a heavy investment in 
developer time (documented in their own diaries) and has been found guilty of 
violating Microsoft trade secrets in doing so.    

Note: My comments here are not pointed at Andrew.  What he has done in his 
research, and what he has published in his books and articles, is radically 
different than what STAC has done.
    
Microsoft's system business is predicated on getting a large number of third 
parties,  both big and small, to develop products for our operating systems. 
Through our developer relations efforts, we continue to provide technical 
information to outside vendors and to encourage support third parties to write 
products for our systems. In addition, from time to time, we will likely seek 
to license third-party software technology to incorporate into our operating 
system and application products.  (For MS-DOS 5 and 6, we licensed technology 
from Central Point, Roundup, Helix, Vertisoft, and Quest/Norton.)    


Microsoft has no interest or intent in pursuing developers doing legitimate 
technical work to build products to run on MS-DOS or Windows.  It is one thing 
to use software tools to analyze an operating system to ensure that 
applications are compatible with it, or to fix bugs in your product that show 
up in low-level interactions in the operating system, or to work around bugs 
in the operating system itself.  It is another thing entirely to disassemble 
the operating system, copy the design of key features, and incorporate them 
into your own product.  Microsoft is not confused about the difference.  The 
developer community should not be confused.  Microsoft will work hard to 
encourage honest developers to build products for our systems, but we will 
absolutely take steps to protect our trade secrets from unscrupulous 
developers who try to rip off our work.  

Paul Maritz,  
Senior Vice President, Systems  
Microsoft Corporation  
		
 

