| IANAL - but here it goes...
An API is nothing more than a formal and open
Contract, like in Copyright, between the writer/implementer of a library and
the yet unspecified users of that library to whom the API has been
documented and explicitly published to. If the API wasn't meant to be
publicly available, or usable by the public, then don't publish that API
publicly. If the contract is restricted to just a single party, then that
API/Contract should be held private between the two parties, then there will be
no implied 'public' contract available for misuse. Permission to be covered by
that contract is explicitly granted to whoever the API is published to,
including the personal use of any associated API copyright claims, by necessity,
otherwise the contract is of only one party with itself. A simply pointless
endeavour.
The implied Contract itself enjoins the needs and requirements
of the two parties and identifies the rules by which the two parties will
interoperate and 'do business'. That said, these contracts do not impose
restrictions on how the other party does their own 'internal business model'
with respect to other orthogonal and unrelated operations that do not pertain to
the API contract itself. The individual design implementations are up to the
given party, and nether party holds any contract control on how, when, or where,
the other implements their own code modules other than what is explicitly
spelled out functionally in the API specification (the contract) itself.
Philosophically, if one can not legally use the API (aka explicit
permission to use) then there is no need for such a contract to exist, and thus
no need for an API. Publication is simply the method of granting permissions to
use. Even if the API is not published there is still a legal precedent allowing
the reverse engineering of such an API to facilitate the interoperability of
software. Not publishing does not explicitly deny its use in all cases. Someone
that resorts to such methods is still bound by the functional contract of how to
interoperate, because it won't work otherwise, but they are free from any legal
constraints that may have been written into the documented API that they never
had the opportunity to read (e.g. then never read the contract thus they never
had the opportunity to agree to and sign such a contract)
The purpose of
publication of an API is to explicitly make it available. Any recipient of that
contract should have a legal right, and needs to know the explicit legal
implications of any such contract before entering oneself into such a an
agreement. Not using the API is the only form of rejection of the contract that
the second party has to exercise, and they must therefore have the ability to
read it and have an informed decision before entering such an open contract.
Deliberate attempts to publicise an API, with the explicit intent to prosecute
the recipient later, after that that publication, should be held synonymous with
a form of entrapment unless that publication itself explicitly contains the set
of legal restrictions in that very document/contract. In the case of Oracle
'changing the rules' after Sun Microsystems publicly and openly documented the
Java API's for all to see is a clear case of entrapment, if there ever was one.
---
The Investors IP Law: The future health of a Corporation is
measured as the inverse of the number of IP lawsuits they are currently
litigating. [ Reply to This | Parent | # ]
|
It's not copyrightable for the similar reasons for why a
phone book is not copyrightable - it's functional, with
limited ability for creativity. If I specify the call to an
comparison function is COMP(A, B), and it returns the larger
of the two, when someone else writes code to call my API,
they have to call it exactly like that. They can't call
MYCOMP(A, B), and expect to get the smaller back.
---
(Note IANAL, I don't play one on TV, etc, consult a practicing attorney, etc,
etc)
[ Reply to This | Parent | # ]
|
