|
|
|
| Authored by: Anonymous on Wednesday, May 30 2012 @ 03:05 PM EDT |
| The API of a function includes ideas about what that function is expected to
do. ABI does not.
ABI is a purely mechanical convention that covers how
to invoke the function and how it returns a value. It says nothing about the
behaviour of the function (e.g. *which* value the function is supposed to return
in various circumstances).
That is however, part of the contract of an API
-- a function's API includes not just the signature of the function (the
mechanical part) but also some conceptual info (or ideas, or contract) about how
the function is supposed to behave.
I posted about this on the previous
story, in response to xtifr's comment.
Connectix copied both ABI and API
details from Sony's BIOS. Both kinds of info must be non-protectible by
copyright, or making compatible re-implementations of existing libraries is
impossible.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Ian Al on Wednesday, May 30 2012 @ 03:12 PM EDT |
I think the point is that it does not affect the legal argument what it is
called. If it is what is necessary, functionally, to access the chosen functions
in Java or Android from Java source code then it fits all the arguments.
As matth pointed out, an API is isomorphic to its ABI. The act of compilation
converts source code to machine-executable (including VMs) code. The interfaces
are not substantially changed in this process.
If what 'goes across' the API does not also 'go across' the ABI then the two
interfaces are different and the compiled source code program will not interwork
across the interface with the respective platforms. The source code interface is
compiled into an equivalent binary interface and the same commands and
information flow happens across the interface between compiled program and
platform, but translated into binary data and machine code form.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
- matth was wrong - Authored by: Anonymous on Wednesday, May 30 2012 @ 04:48 PM EDT
| |
| Authored by: xtifr on Wednesday, May 30 2012 @ 03:35 PM EDT |
I'm pretty sure you're confused (but that's ok, because Oracle is even more
confused). An API is not a collection of ABIs. An API is a
source-level interface that typically gets coverted to an ABI by the
compiler. It's an extension to the programming language. From your WP
quote:
An ABI should not be confused with an application
programming interface (API) which defines a library of routines to call, data
structures to manipulate, and/or object classes to use in the
construction of an application using that particular (often language
specific) API.
The API is used in the
construction of the program. Once the program is built--is a binary
executable--it uses the ABI instead. (We'll gloss over interpreted languages,
with just a brief comment that they forward information from the API to the ABI
dynamically.)
If ABIs, which consist of concrete, compiled code, aren't
copyrightable, then APIs are even less so, being merely language elements. APIs
are used for expression, but are not expressions themselves, and are no more
copyrightable than a random set of words you can use in writing a
story.
Now APIs and ABIs are very similar, and closely related, and I
find it hard to imagine that there's any serious legal difference between the
two. They're like opposite sides of the same coin. But Oracle keeps
complaining about a lack of binary compatibility, which completely misses the
point of an API, which is to provide source compatibility. APIs are
frequently used for platform independence, which is exactly what Google used
them for. Oracle is getting confused between Java-the-language, which includes
the APIs, and Java-the-virtual-machine, which has ABIs, not APIs. The JVM ABIs
aren't anything like Dalvik's, so Oracle's ABI-related arguments
(binary incompatibility) are utterly irrelevant. Google didn't copy
the ABI!
Google included the APIs for compatibility, and, insofar as
they're the same as Java's APIs, they offer 100% compatibility, even
though there's zero binary compatibility.
---
Do not
meddle in the affairs of Wizards, for it makes them soggy and hard to light. [ Reply to This | Parent | # ]
|
- Connectix created their own API - Authored by: xtifr on Wednesday, May 30 2012 @ 03:53 PM EDT
- no, this is WRONG - Authored by: Anonymous on Wednesday, May 30 2012 @ 04:52 PM EDT
- no, this is WRONG - Authored by: xtifr on Wednesday, May 30 2012 @ 06:03 PM EDT
- aha - Authored by: Anonymous on Wednesday, May 30 2012 @ 06:22 PM EDT
- aha - Authored by: xtifr on Wednesday, May 30 2012 @ 08:17 PM EDT
- aha - Authored by: Anonymous on Wednesday, May 30 2012 @ 08:45 PM EDT
- You are forgetting about SSO - Authored by: bugstomper on Thursday, May 31 2012 @ 05:32 PM EDT
- Connectix was about API not ABI - Authored by: Anonymous on Wednesday, May 30 2012 @ 05:03 PM EDT
| |
| Authored by: Ian Al on Thursday, May 31 2012 @ 05:57 AM EDT |
Imagine a contract under which company A (which, for the sake of argument, I
will call Novell) contracts with company B (which I will call SCO) to manage
some of Novell's customer contracts.
It's complicated, but the contract says that 100% of the customer remittances
are forwarded to Novell and Novell returns 5% as payment for the management
service.
There is a financial interface between the two companies, but exchanges of money
between the companies could be for any number of contracts. For this particular
contract, the SCO department dealing with remittances has a range of detailed
instructions to identify the specific Novel customer contracts, send the money
and receive the payments and there are other instructions dealing with other
data interchanges to permit auditing.
As you know, contracts are what you use against your customers. The contract
gets filed until something in the detailed contractual interface goes off the
tracks and then the contract terms are checked.
The contract text is not the execution of the contract. If another company (I
will call them unXis) say to Novell that they would like to take over the same
role as SCO, but for all the new contracts, then SCO might not want to share the
text of their contract because they want to keep the role to themselves. unXis
must now reverse engineer all the various departmental instructions and provide
an equivalent service.
They need a contract document, but, even though it is functionally identical to
the SCO contract, it is an entirely new contract. The text might be similar or
identical in places, but that is irrelevant to the contractual commitments.
The 100% and 5% deal will be identical. There may be big differences in the way
unXis is organised and they may come up with completely different procedures.
However, the procedural interface between the two companies and the exchange of
data and money, must remain the same.
There is a contractual interface between the two companies. The exchanges across
the SCO - Novell interface and the unXis - Novell interface must be functionally
identical. The interface is something understood as contractual commitments in
the legal department and financial transactions in the finance department. The
aspect of the contract interface being considered determines what employees
point to as its realisation,
You cannot point to any one department, member of staff, set of procedures or
format of information that actually comprises the contractual interface. The
interface does not exist as a real thing. It is understood by all concerned as a
concept. The company performance and the employee's jobs depend on the
maintenance of the concept.
My analogy is that the contract is the API, the procedures, money and
information flow between the pairs of companies is the ABI and the procedures
and information exchange within the pairs of companies is the compilation of the
API on each side.
The way the analogy collapses is highly instructive. The contracts deal with
both sides by calling one the seller and the other the purchaser. The API is
only seen by the programmer. It is half a contract. It is an invitation to treat
or invitation to bargain. The other side of the API contract must look entirely
different.
When Connectix reverse engineered all the detailed processes and data exchanges,
they were attempting to recreate the original invitation to bargain. They were
the unXis in the exercise. Nothing they did changed any procedures or data
exchange on the Sony side of the contract nor the API on the game programmer's
side.
Connectix did not reverse engineer the games API. They already knew what that
was. Neither did they produce the ABI because this is just as conceptual as the
API. What they did was reproduce that part of the functional interface and data
exchange that they needed to interwork with the compiled games software. Who
cares what it is called? Legally, that is what Connectix needed to break the
Sony monopoly.
The concept could be understood as an API or an ABI, but there is nothing you
can point to in either the compiled games code or the functionally matching
Connectix code that comprises either interface. Both API and ABI are conceptual
just like contract commitments. All you can do is point at a piece of functional
code and say that it is part, but not all, of the contract commitments.
We know what the danger is in asserting that APIs cannot be copyright protected
by law. Judge Alsup said that he could not be sure that all APIs could not be
protected and that Oracle's API needed to be considered by comparing the
arguments in other cases. The same applies to ABIs. They are still documents
containing creative expression. If an ABI is not fixed in a media, it cannot be
copyrighted.
The legal argument must always be that it is abuse of copyright to attempt to
use it to gain a monopoly on the functional and data interchange requirements
for one program executable to interwork with another program executable. The
creative content of any document or media used solely for the purpose of
employing a functional or data interchange, no matter what the document's
conceptual status or title, must be excluded from copyright protection for that
purpose. Legal arguments based on named generic computer science concepts are
doomed to the FUD and tap-dancing we have seen in this case.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
|
|
|
|
