TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: Kevin Ring
from: Mike Bilow
date: 1995-05-30 04:52:06
subject: WARP API and EXE format

Kevin Ring wrote in a message to Mike Bilow:

> This sort of thing has been done, most notably by Sun's "Windows 
> Application Binary Interface (WABI)" and Linux's recursively named 
> "WINE Is Not an Emulator (WINE)."  The obstacles are probably legal 
> rather than technical, since the API may be considered a proprietary 
> piece of intellectual property. The law on this is complicated, and the
> standard counterclaim would be that reverse engineering has always been
> legal under U.S. law and is considered essential in the promotion of 
> competition.
 KR> (A lot deleted)

 KR> I can understand how there might be some legal issues with
 KR> such a program, but I assumed it would have legal
 KR> implications similar to those of Cyrix essentially
 KR> "emulating" the Intel instruction set.  Although I'm sure I
 KR> don't know the whole story, Intel took Cyrix to court over
 KR> its use of the name 386, 486, etc, but could do nothing
 KR> about their use of the Intel instruction set.   

I don't want to get into an extended discussion of this issue, at least not
in an echo that should be about OS/2 programming rather than software law. 
The short answer, however, is that infringement is a matter of degree and
uniqueness.  A processor, no matter what kind, has instructions that
ultimately operate similarly and which have similar names based on public
domain concepts such as "AND," "ADD," "MOVE,"
and so forth.  An API is much more distinct when compared to another API,
as would be immediately apparent from comparing, say, PM and Windows.

(By the way, the lawsuit over the use of "386" was against AMD,
not Cyrix, and was won by AMD on the classic legal point that no one can
own a simple number.)

 KR> There are also programs like OSTSR, that, although on a much
 KR> smaller scale, emulate the API of other programs.  (OSTSR
 KR> emulates part of the Desqview API in order to convert the
 KR> released time slices into OS/2 time slice releases) 

Any intellectual property protection enjoyed by an API would apply to the
totality of the API, not to a single call, especially not one common to all
multitasking operating systems such as "release timeslice." 
There is also no intellectual property content in arbitrary design
components, such as the decision to end a string sent to the console with a
"$" character, which was originally a feature of CP/M and was
then carried over to MS-DOS and OS/2.

 KR> There's also the fact that doing this wouldn't require any
 KR> kind of reverse engineering, only the documents provided
 KR> publicly from Microsoft and IBM.  I would imagine that
 KR> unless they say specifically you can't use them for
 KR> something like this, there would be nothing they could do
 KR> about it...

Read the legal notices at the beginning of WINDOWS.H or OS2.H.

 KR> Or maybe not.. :)

This is by no means a clear-cut issue, and will probably go through the
courts someday as the "look and feel" claims did.  I am trying to
keep my opinions out of this in order to avoid a flame war here, especially
since the whole issue is only marginally on-topic.  However, I think there
is some legitimacy in the argument that an API is a complex structure that
requires extensive effort to develop, and still more effort to achieve
market acceptance.  In addition, one nice thing about Windows and OS/2 is
that they were not implemented in proprietary and incompatible ways by
different software companies, as was X/Windows for a while.  Owning a
standard API is something of an industry trust, which Microsoft does not
understand and which IBM was only made to understand in the course of its
1956 antitrust consent decree.
 
-- Mike


---
* Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107)
SEEN-BY: 105/42 620/243 711/401 409 410 413 430 807 808 809 934 955 712/407
SEEN-BY: 712/515 628 704 713/888 800/1 7877/2809
@PATH: 323/107 150 3615/50 396/1 270/101 105/103 42 712/515 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.