| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.