|
|
|
| Authored by: Anonymous on Saturday, April 21 2012 @ 02:34 AM EDT |
I like to think about APIS as the way a programmer can make a software to do
something without knowing how to do it.
Example:
A person asks a waiter to bring him some wine, the waiter needs more information
about what the person really wants so he needs to know things like: what kind of
wine does he wants or the color and the amount of wine he wants, once with that
information the waiter goes to another room where the customer can't see and
later the waiter brings the wine in the same way the customer asked.
The API is the set of words that made a conversation between the customer and
the waiter that made the waiter to do something that the customer asked. And the
implementation is what the waiter did once the customer asked him to bring
wine.
API = Set of words used by someone to make a program to do something.
Implementation = Set of code that makes a program to do something.
I thought that the reason why Microsoft virtual machine was not accepted by SUN
was because it was marketed as "JAVA compatible" using the JAVA-logo
but they implemented things that were not portable over other machines to make
it faster plus added more functions that didn't existed in the JMV and enforced
deprecation of JAVA functions, so a program made using the MS-VM could not run
on SUN's JAVA Virtual machines.[ Reply to This | # ]
|
- Day 5 - Oracle v. Google Trial ~pj - Authored by: Anonymous on Saturday, April 21 2012 @ 02:41 AM EDT
- Day 5 - Oracle v. Google Trial ~pj - Authored by: Anonymous on Saturday, April 21 2012 @ 02:44 AM EDT
- Day 5 - Oracle v. Google Trial ~pj - Authored by: Anonymous on Saturday, April 21 2012 @ 04:44 AM EDT
- An API is a Standard - Authored by: Winter on Saturday, April 21 2012 @ 08:09 AM EDT
- Day 5 - Oracle v. Google Trial ~pj - Authored by: Anonymous on Saturday, April 21 2012 @ 08:32 AM EDT
- Day 5 - Oracle v. Google Trial ~pj - Authored by: Anonymous on Saturday, April 21 2012 @ 09:13 AM EDT
- The Startbucks CPI (Coffee Purchasers Interface - Authored by: sdm on Saturday, April 21 2012 @ 09:27 AM EDT
- API - Authored by: Tinstaafl on Saturday, April 21 2012 @ 11:29 AM EDT
- Day 5 - Oracle v. Google Trial ~pj - Authored by: Anonymous on Saturday, April 21 2012 @ 12:04 PM EDT
- Missing the point - APIs are intended to be used by others - Authored by: Anonymous on Sunday, April 22 2012 @ 01:10 PM EDT
- Airplane API - Authored by: Anonymous on Friday, April 27 2012 @ 01:19 PM EDT
| |
| Authored by: Kilz on Saturday, April 21 2012 @ 02:46 AM EDT |
| Please mention the mistake in the title of your post. [ Reply to This | # ]
|
| |
| Authored by: Kilz on Saturday, April 21 2012 @ 02:47 AM EDT |
| For all posts that are not on topic. [ Reply to This | # ]
|
| |
| Authored by: Kilz on Saturday, April 21 2012 @ 02:48 AM EDT |
Please mention the news story's name in the title of the top
post.[ Reply to This | # ]
|
| |
| Authored by: Kilz on Saturday, April 21 2012 @ 02:50 AM EDT |
Please post transcriptions of Comes exhibits here for PJ to
find. Please post them as HTML with the post mode of Plain
Text.[ Reply to This | # ]
|
| |
| Authored by: tom_markus on Saturday, April 21 2012 @ 02:50 AM EDT |
Well there is a book analogy too. A publisher creates
a series of science books (37) covering all college subject matter. Google then
scans and publishes the table of contents of each book. Say one page per book.
In the planning of a book the global organization is the most difficult and
important part of the subject. It would be easy to then take this set of
outlines and use them as the basis of a new series. Is this legal?
Indeed friends who write books tell me you submit the table of contents plus a
few pages as the initial project to a publisher. It is clearly highly skilled
and crucial in the success of the whole project.[ Reply to This | # ]
|
| |
| Authored by: jbb on Saturday, April 21 2012 @ 03:23 AM EDT |
| The reason a menu bar is a great analogy is because in Lotus v. Borland
Borland copied the menu structure from Lotus-1-2-3. They said the reason they
copied it was because the menu structure was also used to implement user
programmed macros and only by implementing the menu structure could Borland make
their spreadsheet program compatible with the user macros written for
Lotus-1-2-3.
As far as Oracle v. Google is concerned, the key thing
is that Oracle (Jacobs I believe) admitted that the Lotus v. Borland
decision said APIs were not copyrightable! The macro programming language
(which was identical to the menu structure) was considered by Oracle to
be an API. That case was decided in 1995. The Supreme court took it up but was
deadlocked in 1996 so the lower court ruling prevailed without getting a seal of
approval from the Supreme court.
Oracle told Judge Alsup that they believe
the case law has changed since 1996 and APIs are now copyrightable. I have seen
no evidence for this extraordinary claim. I know Oracle wrote at length about
Lotus v. Borland. They said the ruling was wrong and also said that it
did not apply to this case. Why would they waste valuable time and space with
those arguments if, as they claim, there is new case law that supports their
position and supersedes Lotus v. Borland?
Days (weeks?) after making
that extraordinary claim, Oracle backed off a little and admitted that they were
actually asking this judge to make the new [case] law they had said already
existed. I realize officers of the court are not held to the same standards of
logic and sensibility required of most other human beings, but it seems rather
outrageous that Oracle can base almost their entire copyright case on the
unsubstantiated claim that there was a 180 degree change in the case law since
1996 without one shred of evidence for this extraordinary event.
Even
worse, it seems Oracle had to back off from that untenable position and
(tacitly) admit to this judge that they were fibbing before about the 180 degree
about-face in case law and they were now asking Judge Alsup to make the 180
degree about-face all by his lonesome with absolutely no supporting precedents.
Why are we wasting all this time in front of the jury on the copyright
issue when Oracle already admitted APIs were not copyrightable in 1996 and then
tacitly admitted they had fibbed about there being subsequent case law that
reversed Lotus v. Borland? How can arguing the facts of this case in
front of a jury help convince Judge Alsup to make new case law to suit Oracle's
current whims and fancies?
---
Our job is to remind ourselves
that there are more contexts than the one we’re in now — the one that we think
is reality.
-- Alan Kay [ Reply to This | # ]
|
| |
| Authored by: SilverWave on Saturday, April 21 2012 @ 03:24 AM EDT |
I find it strange that on the patent side it is really clear what is
being infringed. With the copyright side, it's
strange.
Dead in the water.
Oracle
is.
:-)---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
| |
| Authored by: brong on Saturday, April 21 2012 @ 03:26 AM EDT |
Since everyone loves a good car analogy.
API is like the layout of the drivers' area in a car. The location and function
of the pedals, the direction you turn the steering wheel and the action that
causes.
You can get an electric car, or a diesel car. You can have a giant truck, or
even a little go-cart where the pedals aren't the same (Java SE anyone? - low
powered devices) but the steering wheel still works mostly the same. It's a cut
down implementation of the same API without all the features.
On some of the fancier new cars, the steering wheel might make all 4 wheels turn
rather than just the front two. That's an implementation detail too. The API
contract is "turn this wheel, the car turns in that direction"[ Reply to This | # ]
|
- Car Analogy - Authored by: Doghouse on Saturday, April 21 2012 @ 05:04 AM EDT
- Car Analogy - Authored by: Anonymous on Saturday, April 21 2012 @ 09:20 AM EDT
- Car Analogy - Authored by: Anonymous on Saturday, April 21 2012 @ 11:01 AM EDT
- Car Analogy - Authored by: eachus on Saturday, April 21 2012 @ 11:18 PM EDT
| |
| Authored by: SilverWave on Saturday, April 21 2012 @ 03:36 AM EDT |
If I want the calculator to add 42 and 42 I need to follow the rules.
I need to input the first number then hit the "+" then the next number
and then the "=" key.
There are different rules if you want to divide or multiply and in complex
calculations order matters.
I could change the "+" and rename it to "#" or even
"-" but that would cause confusion.
The implementation that processes these key strokes is going to be very similar
no matter who does it.
---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
| |
| Authored by: Ian Al on Saturday, April 21 2012 @ 03:37 AM EDT |
Mark Reinhold: [From the point of view of the computer], very little
API organization is required by the VM. We could have given them completely
random names and put them into one huge package. The design goal was that API's
should be easy to learn and easy to use. Other considerations:
1)
performance is important
2) Portability is important [wouldn't want to
define an API that is specific to Windows].
Oracle: When you launch the
API design process, what do you do?
Mark Reinhold: Collect use cases,
define the problem/solution space, general requirements. Important to get quick
to a high-level summary [ of the design ] to share with others. Sketching,
writing code snippets. Then you start writing code for the methods. It's
important to work on the implementation at the same time as the API
specification to find bugs in the specification.
Oracle: How long does
it take to design a package?
Mark Reinhold: 2 years, working half-time
on it, with additional experts and engineers working on it
simultaneously.
So putting them in packages and giving them names
which are seen as easy and logical by the users of the functionality defined in
the Specification are important. We know that Judge Alsup has declared the names
and short phrases unprotectable by copyright. If ease of use of the
functionality is that the functional ideas are well devised, then he found that
the functionality is not protectable, either. That is even if the devising of
that functionality is very creative, skilful and difficult.
A
specification does not have a performance. The implementation of the ideas
expressed in the specification will have a performance. Ideas in a document are
not protected by copyright.
The Specification works for the Windows
operating system. What in the Specification makes it portable to other
platforms? Is it copyrightable, or is it more about the functionality and the
units chosen in the definition?
Google do not provide copies of the
Java API Specification to Android developers. They have to get a copy from
Oracle. The SSO is not perceivable by the programmer in the byte code compiled
class libraries. 'Mark Reinhold: [From the point of view of the computer], very
little API organization is required by the VM. We could have given them
completely random names and put them into one huge package.' It is only
available by reading the Oracle Java API Specification.
Harmony would
have used the SSO of the Specification during their clean-room implementation.
Where is the copy of the medium they saw that had the SSO fixated in
it?
It is not the Oracle website, because the
Specification cannot be downloaded from there. Harmony would not have copied
each html document by clicking on all the hyperlinks. Anyway, that website was
only made available as part of the opening of the Java language and that
happened after Harmony created their implementation. They must have been freely
given a complete copy by Sun with the understanding that the Harmony would use
the SSO to implement the API Specification. Where is that accused copyright
document amongst the evidence? That is the one that has the protectable creative
expression, including the SSO, fixated in it. Where is the copyright notice and
special licence terms offered to Harmony from Sun, at the time?
Google
concede that by copying the Harmony compiled bytecode class libraries that they
copied the SSO used by Harmony to create them. However, Google cannot perceive
or read the SSO from the Harmony libraries. The SSO is not fixated in the
libraries. It is only the derivation of the libraries from the SSO fixated in
the original Specification document medium that is the SSO copying done by
Google.
Again, it is vital to Oracle's case that the document that had
the protected creative expression fixated in it and that was given by Sun to
Harmony and the licence conditions expressed or implied are entered into
evidence. Otherwise, it is not possible to determine whether the SSO copied by
Google was protectable SSO under the law.---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 03:50 AM EDT |
It seems clear to me that Oracle is going to spend a lot of
effort
trying to prove that Google extensively copied their documentation;
that's
about all they seem to have a chance at, at this point.
This could
get interesting, since a lot of the documentation is generated from
the
structure of the code, and the previous API comparison examples showed
the
short English language descriptions as being different to the Oracle ones.
I
wonder if some of the more detailed online docs and code examples are too
similar? could be worth looking into.
Even if Oracle could get a win on this
issue, it seems like it would be trivial for
Google to fix it, by either
removing the docs for the 37 APIs and referring
developers to the Oracle docs,
or by rewriting a few bits. I'd guess a win here
would be very much a
consolation prize.[ Reply to This | # ]
|
| |
| Authored by: SilverWave on Saturday, April 21 2012 @ 03:58 AM EDT |
Here is the key evidence that is *not* in dispute: Use of the Java
programming language; using the names of class files and methods; the source
code in the libraries, comprised of original Google works and Apache Harmony. So
what we are down to? -- the Sequence, Structure and Organization, the SSO, which
is in the public domain. Apache Harmony and GNU used them and Sun did nothing.
Then Google did what they did. Larry Ellison himself said that "Nobody owns the
Java language". The APIs have been used for years as a necessary part of the
Java language. ---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
| |
| Authored by: SilverWave on Saturday, April 21 2012 @ 04:02 AM EDT |
It seems that the demeanour at the Google table is more upbeat. There are even
some smiles. At the Oracle table, nobody is smiling, except Michael Jacobs, the
lead attorney from Morrison & Foerster
---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
| |
| Authored by: sproggit on Saturday, April 21 2012 @ 04:04 AM EDT |
In the transcript we see the following statement:-
Judge Alsup:
"It seems a little hard on the judge that the complaint could say... that we
would get all the way to the end of the trial and I have to instruct to the jury
as to what the scope of the decision is supposed to
be."
The penny has dropped.
There is a good
reason that Oracle are not being clear and forthright about this: they are
making it as hard as possible for Google to defend against the "killer blow"
that they are going to pull out of the bag in front of the jury.
With
the patents, it was impossible for Oracle to be evasive. They had to quote the
patent numbers, and once they had done this, Google were free to search the
USPTO web site for the relevant documentation. For the copyright claims, Oracle
are relying on the implied license that is automatically granted when something
is produced. Because of this, they have not been required to stipulate exactly,
to the letter, where their complaint lies.
For anyone who followed the
SCO vs. IBM complaint, this will be eerily familiar.
Sadly, in the
case of the Google complaint, Google have not done quite such a thorough job of
forcing the point until the Judge can see that BSF/Oracle are dancing.
I can only hope that when BSF/Oracle pull their little stunt that the
Court will uphold Google's inevitable complaint as to trial-by-ambush. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 04:11 AM EDT |
| The flight controls are nice as an analogy, but they have the disadvantage that
one side is human, and can adapt.
I think a better analogy is socket wiring.
Take something like the Europe Card Bus
specification. If you create a card adhering to those specifications, you can
plug it into a system and get components to interact that have been developed
independently.
I have picked this example because it shows a number of
things:
- An API does not need to make sense in every respect to be
successfully employed: this bus system has been more or less the industry
standard for a certain class of computing systems, and the layout of connections
is chaotic. I think I remember that it was related to minimizing plane
connectors on the original processor card or something like that.
- You
have some obvious components required for the task at hand (like the address
A0-A15 and data lines D0-D7 for accessing memory), there are `obvious'
extensions (like A16-A19, signals not even available on the processors for which
this has been designed), and there is stuff that is unique to the design (like
+5VBAT).
There are also specifications of how much current any card
must be able to provide on its connectors.
A card obeying this
specifications can be used in a number of different computing systems, partly
even with different processors.
Now this example was an example for a
bus system, and that means that every socket on the system is wired in
the same way. The case of computer APIs is more like the old mainframe
computers where even the processor was distributed over dozen of cards wired
with one another, with connecting sockets having more individual
layouts.
Connections running over sockets are more expensive than
connections on cards. The analogy for APIs is that passing data across function
call boundaries (functions are the basic entities processing data: they have
data for input, they have data for output, and they internally have their own
temporary variables and data needed for the processing they do) is more
expensive than working on internal data.
And even more expensive is passing
responsibility: if the other end of the socket is designed by a different
department, you need to agree on what kind of information and signals you need
to interchange, and how to best transfer them through the socket.
Analyzing
and boiling down a system into logical components with a concise and logical
number of interconnections is system design. As Oracle correctly states, this
is totally crucial to everything.
Like with a hardware bus system that needs
to match actual electric and logic characteristics of existing processors close
enough to be useful (even though it may be useful for more than one processor
family), APIs for libraries and the libraries itself need to be a reasonably
good match to the individual programming language's way of working with
data.
There are programming languages like Modula and Ada where APIs are
essentially split into `interface' and `implementation' parts of declarations,
namely declarations that are necessary for talking to a library, and
declarations that are necessary for the library to work internally.
This
clean distinction at the language level comes at a cost in overall complexity
and performance. Languages like C (and also Java) don't really have it. As a
result, the computer readable forms of APIs tend to be a mixture of requirements
for both interfaces to the library, as well as exposing internal workings or at
least the inner structure of a library.
Now the better a job the system
designers do creating APIs that reflect the function rather than the
internals of a library, the less actually copyrightable content will be
connected with it.
You can try patenting some parts of the design, but that
is also shaky.
So with API design you have the situation that the best work
is the one least likely to be `protectable', at least by copyright. This is
hardly surprising since the essence of an API is to enable interaction by
providing abstract interfaces to functionality. The better the designer does
his job, the better the abstraction will be, and the better the separation
between the (copyrightable) implementation at the other end of the API is from
the uses of the API.
The worse an API does its job of abstraction, the more
it will dictate the choice of algorithms you have to use in order to implement
the API's functionality. Part of the fault may lie with the computer language
used, part may lie with the designers' capabilities, part may be a tradeoff
between efficiency, convenience, complexity, again influenced by the
capabilities of language and designer.
The unsavory part of this case is
that Oracle tries to invent legal protection for the good parts of API design
(those that are created for interoperability _without_ needing to mix
copyrightable domains of code) by basing the protection on those aspects of an
API where the abstraction falls down, making a `cleanroom design' structurally
similar to the original implementation because too many details of the
implementation leaked into the API design.
If you call something an API and
pass it off as one, capitalizing on those aspects where it actually fails being
an API seems in bad taste and a violation of the takers' expectations.
[ Reply to This | # ]
|
| |
| Authored by: mschmitz on Saturday, April 21 2012 @ 04:13 AM EDT |
PJ,
the menu bar anology, even though not perfect from a programmer's point of view,
is probably perfect from a legal point of view - it has been used before and has
been decided in a court of law. It's too far-fetched for us programmers but the
judge may be able to relate to that.
As far as trying to understand the technology goes: don't worry. I think you're
doing fine - you ask the right questions, and come up with 'legal' analogies
that a tech person would not think are relevant. We can draw a line in the sand
from what we know makes good technical sense, you help us see where that same
line may be drawn in the legal arena. So far, it doesn't look too bad to me.
-- mschmitz
[ Reply to This | # ]
|
| |
| Authored by: bugstomper on Saturday, April 21 2012 @ 04:25 AM EDT |
| In a
comment to the previous article, BitOBear made the same analogy (although
in a more complex discussion so you might not have noticed), and in this comment I agreed with that being a
great analogy.
jbb pointed out that the analogy supports applying Lotus
v. Borland to this case. I agree. Right now I don't see any significant
difference that would make the analogy break down.
[ Reply to This | # ]
|
| |
| Authored by: AH1 on Saturday, April 21 2012 @ 04:36 AM EDT |
| Given the fact that I am an aerospace engineer and I work with flight software I
would like to correct a misconception related to the flight display analogy.
There is an industry convention that dictates the layout of cockpit gauges in
"the T arrangement" (Ref Flight Instruments )
this is not a standard, but rather a "best practice." (Other Aerospace folks
correct me if I am wrong but I can not find an FAA mandate that specifies this
configuration.) What is important here is the layout of the gauges. Aircraft
manufacturers do not deviate from this 'convention" because doing so would cause
confusion among pilots who have been trained to scan their instrument panels
according to "the accepted layout". This "best practice" was adopted by the
manufacturers of "Glass Cockpits" as well.
In other words, when we removed
the analog gauges from in front of the pilots we kept the arrangement of the
information the same. This way pilots did not have to change their scan pattern
when they moved from an analog to a glass cockpit. (Note: Glass cockpits are
software driven, analog cockpits are electrically driven.)
The important
distinction here is the assumption that you are "automatically certified" to
transition from an analog cockpit to a glass cockpit. This is not the
case.
This being said the API analogy is correct. Given a specific application
(computing language) a set of conventions/best practices are identified and
documented (API's). These API's have nothing to do with the specific system
implementation but rather, implement a "best practice" that users of a given
system are used to seeing. This DOES NOT mean that adherence to "an accepted"
convention automatically guarantees interoperability without additional work,
but rather, that the operator (coder) has an idea of where to go to go and what
to do with the information they collect.
Now from a software analogy, API's are
the convention. The actual implementation is the software. As much as I
dislike software copyrights and patents I will argue that the specific cockpit
layout & displays are unique. As an example the Boeing 757 and 767
implemented nearly identical cockpits. This way a pilot who received
certification on one was automatically certified on the other. (OK aerospace
folks don't abuse me for what happened in reality.)
So to correct the aircraft
analogy. API's are analogous to the cockpit gauge layout. Adherence to that
layout (API) does not guarantee interoperability, but it does give you the
ability to gather the data you need to interact with the system. So unless
Oracle can prove they invented the concept of the API they are going to have a
tough time proving that Android/Harmony (API's) violate their IP.... That is
until they try an argue that Java, as a language, is their sole IP. [ Reply to This | # ]
|
| |
| Authored by: xtifr on Saturday, April 21 2012 @ 04:52 AM EDT |
How about a command line analogy? If you have a linux system, you have
ready access to the command line, and it's even called an
interface.
First thing to understand is that in Java, the APIs are
grouped together in sets. This is analogous to the way that programs are
grouped together in directories. For example, java.math.sqrt() means that the
sqrt() API is inside of a math group, which is inside of the java
group.
At your command-line, you can type /bin/ls, which means that the
ls command is inside of the bin group (directory). Another command, man, can be
typed as /usr/bin/man. In this case, the bin group is not the same as the
previous bin group. It's a subgroup of the usr group. In the case of
/usr/games/nethack, the usr group is the same one referred to in /usr/bin/man,
but the games group is a new one; a sibling of /usr/bin.
If you're at
all familiar with the layout of your linux filesystem, that all should make a
certain amount of sense.
Now at this point, you may begin to suspect
that the famous "37 APIs" really refers to 37 groups of APIs. That's
exactly right! The groups contain things called functions and classes, which
are similar to programs--similar enough for this analogy, anyway.
A
function is very much like a little program. A class is--well, technically, a
class defines a group of functions, called "methods", that are automatically
associated with a particular instance of the class--an object. But for the sake
of this analogy, let's think of a class as a program that has switches, like the
"-l" switch to the /bin/ls command. The switch is--very loosely--like a method
of the /bin/ls program.
Now, even if that left you a little confused,
don't worry. Here's the important bit. On any Unix-like system, Linux, BSD,
Solaris, or even MacOS, you can use the same commands, like /bin/ls or "/bin/ls
-l", and get the same results. The names of the commands, and the switches, are
like the API. The actual programs that run are very different between, say,
Linux and MacOS, but the results you get from those commands, using the
command-line interface, are the same. You can write a script--a list of
commands--for Linux, and, as long as you stick to standard commands and
switches, that script will run exactly the same way on BSD or Solaris or
MacOS.
So, yes, an API is just a list of names! The
implementation (the part Google didn't copy) is like the programs behind the
names. The Linux /bin/ls refers to a completely different program from the
MacOS /bin/ls, just like Google's java.math.sqrt() refers to a completely
different subroutine than Oracle's java.math.sqrt(). But the interface
is the same. And that's what Oracle is complaining about. Google copied a
large set of names.
---
Do not meddle in the affairs of Wizards, for
it makes them soggy and hard to light. [ Reply to This | # ]
|
| |
| Authored by: TJ on Saturday, April 21 2012 @ 05:15 AM EDT |
Let's design a new car.
It'll be built using our new patented
ultra-light ultra-strong alloy (patentabsurbium) and have 5 road wheels, 2
steering wheels (for back-seat drivers), a fuel filler in the middle of the
roof, a gear-shift in the trunk and pedals under the rear seat.
Cool
huh!?
Or how about we design it to the car industry's Vehicle
API?
After all, every other Vehicle API implementation has 4
road wheels, just 1 steering wheel, fuel filler on the side or rear for easy
access, gear shift close to the driver's hand and pedals under the driver's
feet.
We can still build the car using our patentabsurbium
alloy.
Now when potential customers consider buying our car they are
already familiar with and know how to operate the vehicle because they know the
Vehicle API.
Our vehicle is just one of many independent
implementations of the Vehicle API. The API itself is simply the
description of how we Interface with the implementation.
If
the driver chooses they can switch to a different implementation (drive another
make of car) but they will still use the same Vehicle API to operate
it.
Each manufacturer owns copyright in their vehicle manuals which
describe how to use the Vehicle API in their vehicle but they cannot
copyright the Vehicle API itself.
If Ford or General Motors
were to claim copyright over the Vehicle API itself, rather than their
particular implementation of it, we would have to learn a different API for
every brand of vehicle we drove.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 05:42 AM EDT |
The simplest analogy I know is the lightbulb
The API is arrangemebnt of the socket
The library is the bulb itself and the controlling code has to interface to the
bulb through the socket.
The lightbulb simply has to provide the correct set og contacts etc to conform
to the api specification, then the bulb and the socket will fit together, and
when the volts are applied light comes out. It is up to the lightbulb how it
manages that .. it could be one of those new LED ones, an energy-efficient
flourescent one, an old tungsten one ... but. providing the bulb provides the
the right sort of pins and base shape, standard stuff can connect to it.
Think of any two bits of electrical gear ... say, your car and its electronic
engine gontroller ... the API is the plug between the two (including the
specification for the physical pins, and what they do, what signals they get and
what outputs they give) ... if your control unit is faulty .. if you can find
another controller that conforms to the same API, you should be able to plug it
right in. Inside the controller, it may be different code ... it may use a
different processor, or punch tape, or elves .. but, providing the API
definition is maintained and the connecotrs and signals are the same .. it will
fit right in.
APIs are the plugs and soclets between bits of code. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 05:46 AM EDT |
How about a telephone analogy.
I was looking for an interface which must not change and is
somehow abstract.
A few years (decades?) ago we were able to do additional
stuff we our phones by dialing special numbers.
The operator would recognize those numbers, and for instance
initiate a wake-up call.
You wouldn't care how the operator implemented those
operations (if they wanted they could hire people to
recognize those sequences and call you in the morning).
That would be the implementation.
Some operators had additional "special" numbers, but the
important numbers were always the same (at least here in
europe) (At least that's what I remember. I am not that
old...).
[ Reply to This | # ]
|
| |
| Authored by: BitOBear on Saturday, April 21 2012 @ 05:54 AM EDT |
Lets just look at one element of your example:
Min(list_of_numbers[]) returns number;
Things in the computer that fit into "numbers" worth of memory might
not be numbers at all. What is five devided by zero? It's an error. It may
produce the not-a-number value, e.g. a special pattern of bits inside the
"number"'s worth of memory that says "this thing here is not
really a number". This is the "this is not data" data.
So when the API is defined for Min([]) it -may- include a purely semantic rule
that NaN values are ignored. Or it may include the semantic rule that if any
values are NaN then the function will return NaN instead of the smallest legal
number found.
It will also need to tell you what "number" you will get back if the
list_of_numbers thingy contains zero numbers, e.g. no number at all.
ASIDE: exceptions exist to handle cases like this. It is easier to just have a
illegal_nan_encountered exception, and a no_values_in_list exception, than it is
to have to have every entry of every function have things that every user has to
look for on every use.
So the API for 747 cockpit as used by Pilot includes non-mechanical aspects like
"don't try to lift the landing gear while parked on the ground" and
also what will happen if you do that (You get scolded by a warning light and a
buzzer, but the weight-on-wheels sensor will prevent the hydraulics from trying
to fold up the gear, if anybody cares)
So any way, part of the problem is that API is philosophy.
To use a hopefully lawyerly analogy for the problem of understanding APIs....
Q: What is a "strict constitutional literalist" and why can you get a
room full of them together and have them all end up arguing about interpretation
of something if they are "literalists"?
A: Each literalist has something that he -wants- "constitutional
literalism" to mean. And each has what they believe to be an exact
denotation and definition for everything in the constitution that they have
studied. But none have come to grips with the fact that these strict definitions
are all personal and when they don't match an argument ensues.
So for APIs we have people here who beleive that the fact of the declarations is
the API. I will call these people API literalists.
And we have people like myself who consider that the API must include the
should(s) and shouldn't(s), and I will call my ilk the API semanticists.
It doesn't matter which of us are correct, and it doesn't matter if we change
our positions on the topic minute-by-minute or API-by-API...
The fact that the whole thing *is* subject to argument here in this forum should
be ample indication that the term is *not* well defined.
You might as well ask the court to narrowly define counter
transubstantiationalism.
The definition itself is declaratory. Its an API if someone says it is. It's
only -not- and API if everyone says it is not one.
You are not wrong or weak or unduly confused by not "getting it" on
this topic. This is the "obscenity" of the computational domain. Once
you know the topic well enough, you know an API when you see one.
API has no -strict- technical definition.
If the court gives API a strict legal definition it will, by definition, be
wrong.[ Reply to This | # ]
|
| |
| Authored by: jbb on Saturday, April 21 2012 @ 05:59 AM EDT |
Recently Oracle told the judge that you don't need a license in order write
applications that use their APIs. They seem to say the exact opposite on their web
site:
When you license the Java Platform, Standard Edition, you
can write applications to its specifications.
I admit this
is not a direct contradiction. Perhaps they told the judge the truth and are
just trying to mislead everyone who goes to their licensing page into thinking
that a license is required in order to write Java applications. They are
certainly implying that you need to buy a license in order to make use of Java's
"write once, run anywhere" feature.
Perhaps the simplest explanation,
which PJ mentioned a while back, is that despite all the promises they made to
the regulators before they bought Sun, Oracle has decided to drastically change
the licensing terms of the Java language in order to squeeze as much money out
of it as possible. Perhaps they will eventually use it as a cudgel to beat on
the heads of their competitors who were foolish enough to keep using Java after
Oracle got their greedy mitts on it.
---
Our job is to remind
ourselves that there are more contexts than the one we’re in now — the one that
we think is reality.
-- Alan Kay [ Reply to This | # ]
|
| |
| Authored by: The Cornishman on Saturday, April 21 2012 @ 06:11 AM EDT |
This works quite well, especially because since before WWII there has been a
standard for layout of the most basic aircraft instruments: the Basic T. The
three dials across the top of the T are airspeed, artificial horizon and
altimeter, with heading (compass or gyro) centrally below them.
OK, we're in the realm of human factors and interfaces, but it's really
important for a pilot in any plane to be able quickly to find and recognise
these instruments, and beginning pilots are trained to scan them in a set
pattern.
To stretch the API analogy to its limit, you don't want the main program (the
pilot!) to take action based on a return value which it thinks is altitude, when
in fact it's airspeed, nor yet to get units confused, which is why aircraft
still fly thousands of feet up, and not metres. Get this wrong, and Bad Things
Happen.
---
(c) assigned to PJ
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 07:10 AM EDT |
this is my attempt at an analogy
i have 2 numbers 2,3
i want to transform them
i type 2,3 and then a function key into my (rather old hp) calculator
i see 8
the calculator is my api and the function key is a method.
there is a place where i can enter arguments, there is a place where i choose
the function and there is a place where i see the answer
--
another one
-
webster was the api and method i used that summarised and explained
what is going on
[ Reply to This | # ]
|
| |
| Authored by: swmcd on Saturday, April 21 2012 @ 07:27 AM EDT |
Sez You (a radio show) asks
What is the difference between the
coast and the shore?
Answer:
The coast is the
boundary of the land;
the shore is the boundary of the water.
So
we will say that
- the application is the land
- the library is the
water
and
- the API lies between the coast and the shore
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 07:27 AM EDT |
I also think the aircraft cockpit is a great analogy, but there is an important
point to keep in mind:
humans are intelligent beings, the computers are not. Humans can adapt
themselves, computers - can't.
It is fundamental to understand this to be able to "get" this
analogy.
To put it into perspective, let's assume for the moment, our pilots are blind
(so they can't adapt) but have very precise hands, so they can still find all
the buttons at the defined spots.
Such cockpit should be identical to the last button or it would be useless. If
747 has push button and 767 has a flip switch located 5cm further, then our
blind pilot trained on 747 would not be able to use it at all. Where a human
would barely notice the difference.
The same goes for API's. They absolutely need to be *exactly the same* to the
last dot or they are totally useless as far as interoperability goes.
While you can describe the same thing in a million different copyrighted ways
and any human would still understand, you can't offer compatible/interoperable
API's without offering an identical "selection and structure". This is
fundamental.
This is where the human understanding of copyrights brings us to the fabulous
world of Alice in Wonderland.[ Reply to This | # ]
|
| |
| Authored by: jjs on Saturday, April 21 2012 @ 07:40 AM EDT |
In the example he gave:
average(list of numbers) return number
Note the name - average. As a result, the comment was redundent - those type of
comments SHOULD be. Programmers should choose names that reflect what the API
does. For example, java.lang - that tells me the API is related directly to
Java (it's core or very vital, can be checked by the TCK), and it's something to
do with the language itself. So it's not just that it's a header file, but
every element is essentially functional. If everything is functional, how much
creativity is there on each level of API to let it be copyrightable? Possibly
the whole, huge collection - but is each element? My answer (IANAL) would be
no.
---
(Note IANAL, I don't play one on TV, etc, consult a practicing attorney, etc,
etc)
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 08:01 AM EDT |
I don't understand why Oracle takes java.nio as an example of a creative API. It
is almost completely generated because it isn't actually creative at all. It
follows almost completely from the requirements that you want to do input/output
on various data types in a buffer. So much so that in OpenJDK the classes and
methods in the package are almost totally generated by a simple script!
Lets take a look at the java.nio package:
http://developer.classpath.org/doc/java/nio/package-summary.html
It has some classes for different Input/Output Buffers, some exceptions in case
things go wrong with the input/output (nio is short for New Input Output), etc.
And if you "zoom in" on one of the classes you see these classes have
several methods to manipulate the input/output Buffers. For example take the
IntBuffer, which Oracle used as an example in one of their slides:
http://publib.boulder.ibm.com/infocenter/ledoc/v6r2/index.jsp?topic=/com.ibm.rcp
.dee.javadoc/doc/java/nio/IntBuffer.html
(BTW. I took the liberty to reference the GNU and IBM documents for these,
because they have their own "copyright notices" which claim the
copyright holder is the FSF and IBM respectively. It is funny to think all these
people put a copyright notice on unprotected elements.)
It defines what kind of Buffer it is (an Int for Integer), and what operations
(methods) one could do on it, etc.
Oracle uses the class definition in there slides as an example of literal
copying:
public abstract class IntBuffer
extends Buffer
implements Comparable<IntBuffer>
That just says there is a class we call IntBuffer, it is a specialized version
of a Buffer which can be Compared to another IntBuffer. And Int is an
abbrevation of an Integer, a way to represent a number in the java programming
language. The package contains several such Buffer classes for different data
types (Byte, Char, Double, Float, Long, Short).
Since there is no real creativity involved at all one can just write a script to
generate all these classes. Which is what OpenJDK for example does (in fact
these templates were written by Mark Reinhold, one of Oracle's witnesses):
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/java/nio/X-B
uffer.java.template
So, the above "creative" API statement is generated from the following
template in that file:
public abstract class $Type$Buffer
extends Buffer
implements Comparable<$Type$Buffer>
Note how $Type and $Buffer are written. They are just "variables" that
will be replaced by in this case "Int" and "Buffer" (there
are also different kinds of buffers). There is just one template source file
that you run to generate lots of classes. There is no source code even for any
individual data type Buffer class mentioned in the API.
So there is literally no way Google could have copied the Oracle Java
implementation of this package. Because Oracle's source code doesn't actually
contain this API in its source code!
It also shows that this API isn't at all creative since it is almost totally
generated from some template files (there are other templates in the OpenJDK
source tree to generate the exceptions for example). So all one does is look up
the names of the basic types of the java programming language and run the script
and TADA another new API...
The resulting API names (in Oracle's java, GNU Classpath, IBM's or
Android/Harmony) just look the same. But that is not because the source code
describes the API, in this package it literally doesn't. That is because the API
is all the mundane, non-creative constants/names that fall out of having a
package that does buffered input/output.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 08:04 AM EDT |
Google knew what changes to Java were needed to make it work on a
cell phone platform. Sun / Oracle wouldn't agree to the changes. I
really wonder who is forcing a fork?
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 08:07 AM EDT |
API: Application Programmer Interface
An API is an *interface* for a *programmer* to use to implement an
*application*.
Application: is probably clear: some code which runs on some system. The system
is here represented by the Java Virtual Machine and the Java libraries.
Programmer: the Dude!
Interface: From Miriam-Webster:
1: a surface forming a common boundary of two bodies, spaces, or phases <an
oil-water interface>
2a: the place at which independent and often unrelated systems meet and act on
or communicate with each other <the man-machine interface>
2b: the means by which interaction or communication is achieved at an interface
2a is the one most suitable for the topic at hand: API is a (well defined) thing
which forms the boundary between the application code and the system code.
That is really all there is.
FWIW: an API *definition* is a description of the interface: how the programmer
can use it, what is the system functionality the interface provides access to
(exposes). The better that exposed functionality matches what the application
needs, the easier it is to code: that is why a well designed interface is
important.
HtH, Andre.
PS.: I am working on API design, standardization, implementation. Its fun :-)
PPS.: I am not a Java guy, but some of the APIs I am working on are also
rendered in Java (by others).
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 09:08 AM EDT |
| Ellison says Harmony is Java? Davlik is Java? Both? [ Reply to This | # ]
|
| |
| Authored by: HappyDude on Saturday, April 21 2012 @ 09:22 AM EDT |
I will simplify the thought and let anyone extrapolate and pick it apart.
How about a check?
The check itself tells me what data I need enter.
I have no idea why it is arranged like it is, but it seems like they're all the
same.
If I don't include some data, it probably won't work, but I don't know why.
I have no idea what happens after I write the check and the cashier scans it
through some contraption, or sends it to the bank. All I know is the outcome.
How does it work? I don't know and I don't really want to ... I just want the
transaction to occur (without bouncing).
It's a shot.
Cheers, All.
HappyDude
[ Reply to This | # ]
|
| |
| Authored by: om1er on Saturday, April 21 2012 @ 09:36 AM EDT |
| An "Application" is a task to which a computer is applied.
"Programming"
is the activity of entering sensical, executable, instructions
into a computer
as well as comments and interface specifications.
A "routine" is a part of
a program that accomplishes a programming task.
Some routines will be used
over and over again. They can be grouped
together, and the collection called a
library or a package.
The "Interface" is between two distinct routines. It
describes how those two
program routines interact, using agreed upon terms, and
names which (and
this is where the creative part comes in) describe accurately
the activity being
performed.
In order for a computer program to make use
of the routines in a package or
library, the program's source code has to use
the correct routine and variable
names and to use the correct variable types
(such as a number or a letter) to
match the routines in that library or
package.
There are at least two ways to know what those names and values
need to be:
one is with a written API specification, the other is to look at
the source code
for the routines and variables in the library or package.
If a proprietary vendor does not provide the source code for their library
or package then the vendor needs to provide the written API specification or
nobody
will know what is there or how to use it.
------------
The
analogy:
Let's say one day you feel like working a puzzle, say a puzzle that
when
properly put together is a picture of a cat.
You don't want to create
your own puzzle from scratch, so you go buy one.
As you put the pieces
together, it dawns on you that the shapes of the edges
are in computer terms an
"interface." If one piece's edges do not fit with
another piece's edges, the
puzzle will not go together. This is in hard
physical reality what an
Application Programming Interface, API, is in
computer programs. An API
describes how the pieces fit together, and is
used to make one program routine
fit together with another program routine.
You work and work, getting all
the interfaces matching, and your application
(the complete picture) is taking
shape, but you find that the manufacturer left
out a piece. What to do? Well,
the interface is well defined - it is specified
right there where the hole is.
So, you "reverse engineer" that missing piece to
complete the puzzle, and your
application. You fill in the missing space,
following the interface, and a
knowledge of what the completed picture has to
look like. (There's some
artistry involved.)
But, the puzzle manufacturer sues you because you used
their interface
specification. They claim the shape of each puzzle piece (and
there are lots of
pieces) are copyrighted, so you cannot create your own piece
without a
license from them.
Your mind boggles, much as it boggles with
software patents and Oracle v.
Google. ---
March 23, 2010 - Judgement
day. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 09:46 AM EDT |
I think it's crucially important in this trial to
understand
that 'API'
means two things, and the Oracle team are trying
hard to conflate and confuse
the meanings.
The original use Applications Programming Interface,
meaning
it's a list of things that can be called on by a program to
achieve
particular jobs, without worrying how those jobs are
done as a result.
The Applications part means that it's about handing the
opportunity of
use from one program/system to another. It's
not restricted to an operating
system, or a language.
Microsoft Word for instance has API's that let other
programs make use of Word functionality.
The Programming part should
be obvious - it's about
letting
one program use the functionality that another
has.
And Interface means that you don't need to worry about
the
implementation: all you need to know is how to call on the
functionality the
API provides.
In the original meaning, the promise of the Interface
part
means that you can replace the implementation of the API
with another.
So if you were writing a program that used
functionality provided by Microsoft
Word, you could switch
out Word, and insert LibreOffice provided the Interfaces
offered by both were the same. You'd want to do this if you
found that the
LibreOffice implementation was superior. Or
if you discovered you weren't bound
in what you could do by
the licence of LibreOffice, whereas with Word you can't
use
it in your nuclear power plant for processing safety-
critical
data.
But what tends to happen is that programmers come to
depend
upon
a particular implementation of the API, and at then
'API' is used to mean the
particular implementation.
This happens when somebody writes a really
good
implementation of the functionality in the API. Or
programmers come to
depend on implementation side-effects
which are not well documented. Or the API
spec is not clear
and one implementation does one thing while another does
something else. Or a company who provides the API builds in
hidden parts which
are necessary but unavailable for general
use. Or a particular implementation
becomes so embedded that
replacing it is fraught with danger and difficulty. Or
the
licencing requirements mean it's impossible to replace an
implementation.
Each of those have real-life examples.
In this trial it's in Oracle's
interests to conflate the
two
related ideas because the promise of an API _is_
the
replaceability of the implementation. And that
replaceability depends upon
the Interface for the
implementations being exactly the same in all ways which
would affect implementation.
Now we get to Java. What follows differs
according to the
language.
In Java, a method in an
API:
public float Divide(float a, float b)
is
replaceable if the name of the method is the same
('Divide'), and the types of
the parameters are the same,
and in the same order.
So, I could
replace the method above with another
implementation with this
definition:
public float Divide(float x, float
y)
I could not replace it with
public float
Division(float a, float b)
because the method name has
changed.
Nor could I replace it with
public float
Divide(int a, float b)
because one of the parameters has changed
type.
And neither could I replace it with
public int
Divide(float a, float b)
because one of the return type has
changed.
All of the above is to do with the ability to change
syntax.
There's also semantics. As a matter of interoperability I
can't change what a
and b mean. If a is the nominator and b
is the denominator in the Divide
function, then an
implementation intended to replace the existing
implementation cannot reverse the order of the two because
any calls to the
Divide method will have been written
expecting the original order: 4 divided by
2 is very
different from 2 divided by 4.
It goes further...
The method
Divide must be located in a class. Say it's
public class
Division
As a matter of interoperability, I can't change
the name
that the class has because programmers making calls on
Divide will
expect Divide to be part of Division.
If the Division class has two
methods - Divide and
IntegerDivide, then the order in which the two appear in
the
class is something that can change between implementations.
That
is, this:
public class Division {
public float
Divide(float a, float b) {
//Some stuff would be here, but it's
irrelevant to this
example
}
public int
IntegerDivide(int a, int b) {
//Some stuff would be here, but it's
irrelevant to this
example
}
}
is equivalent to this:
public class Division {
public int IntegerDivide(int a, int b) {
//Some stuff would be
here, but it's irrelevant to this
example
}
public float Divide(float a, float b) {
//Some stuff would be here, but
it's irrelevant to this
example
}
}
Oracle are claiming that the order is indicative of
copyrightability. In the same way that the creative order of
the words in this
sentence means that the unique snowflake
that is this sentence enjoys copyright
protection.
But it goes further.
Classes are grouped together
in packages.
For instance an API developer might group the classes
Division and
Multiplication together in a package called Maths.
As
with methods in classes, the order in packages is
immaterial to
interoperability, but the fact that Division
and Multiplication are in Maths is
important for
interoperability if I want to replace the Maths package.
And so is the name 'Maths'. I can't change that name when
replacing
the implementation, just as I can't change the
names of classes or methods.
HOWEVER.... All of the above is to do with the specific
rules of
_Java_. Other languages have other rules. APIs
provided by other systems have
other requirements on
replaceability. Order does matter sometimes. The names of
parameters matter sometimes. And so on. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 09:59 AM EDT |
Lego and programming are very similar...
You get blocks which let you make models of pretty much
anything. The blocks are the basic statements of the
programming language.
But if you want to make a model which works - say a model of
an engine, then you have a problem: to make an engine you
need gearing, axles, and ways to mount the axle. In the
basic Lego universe, these don't exist.
This is equivalent to the situation where you want to do
something that the language is not equipped to handle. I/O
in Java is an example.
You can:
- Design some new things that you'll manufacture from
scratch yourself. You'll have to cut them out of wood, or
have a plastic injection moulding kit, or something. This is
the equivalent of building some add-on to the language, from
scratch. In PHP you'd do this by writing some C code with
functionality you want to add to PHP. Similarly in Python.
This is the equivalent of building your own API. By choosing
this option, you are going down your own road: your gearing
system is unlikely to interoperate with the 'official' Lego
gearing, more on which later. To interoperate you'd need to
make a special piece which has both sets of gearing mounted
on one axle, and then you'd need to make sure your model was
designed to take account of the need for both gearing. Just
as you would in a computer program if you were using your
own.
- Or you can adapt what you have. For Lego, if you scale up
your model, you might be able to make gears. You are working
around a problem here. But it's not a great way forward.
Your model is going to have to be really big for this to
work properly. In programming you see this when you force a
language or a system to do something it wasn't designed for.
You end up with strangeness, which is caused by trying to
work around fundamental problems: like your model is going
to be bigger than the engine it models.
- Or you can depend on the manufacturers of Lego. They came
up with Lego Technic which includes gears and axles. And
they designed a new kind of brick with holes, so that you
could mount the axles. This collection of elements is
equivalent to an API. You use their parts instead of
manufacturing your own. And you get enormous benefits from
using their standardised parts: you don't have to spend time
making your own, and you don't have to try to work around
the problem of not having gears. You can make models the
size you want. And you can still make your own gears if you
want - but by making to them to the design of the Lego
gears, you are able to interoperate. Maybe you'd want to do
this if you want to use metal gears instead of plastic.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 10:03 AM EDT |
The Essence:
A Library is a tool box.
An API is a list of the tools in the box.
That's it. That's all. QED Fini. The End.
Yes, there is more in the details, and in the elaborations etc. But the essence
of what an API is, is 'A list of tools in the box'.
More complex analogies lose the central point in the details.
Keep in mind that has to be presented verbally in real time in open court. It
has to be bare-bones simple for people to grasp as they hear it. No going back
to the top of the paragraph and rereading it (5 times); or parsing phrase by
phrase. What the jurors' ears hear and they catch on the fly is what they are
gonna get.
So:
A Library is a toolbox.
An API is a list of the tools in the box.
(Lawyer pulls out a socket wrench and a screwdriver.)
Not a mechanic either
JG
[ Reply to This | # ]
|
| |
| Authored by: Magpie on Saturday, April 21 2012 @ 10:22 AM EDT |
I don't think that an API is equivalent to the control panel. Rather its a user
guide that lists all the button and gauges on the control panel, and possibly a
picture or two, along with an explanation of how it works.
What Google have done is built their own aircraft with a control panel that has
on one part of the panel the same 37 buttons and/or gauges, in the same place,
using the document as a guide. But the material used to build the control panel
is different and the plane around it is completely different.
As a pilot you can nearly fly Google's aircraft had you been trained had you
been trained on a 747 or 767, but the performance of the aircraft is different
and you have to take that into account. [ Reply to This | # ]
|
| |
| Authored by: reiisi on Saturday, April 21 2012 @ 10:23 AM EDT |
Went in to the other room to make my daughter's bed with this thought ringing in
my head: An API is an abstact language for commanding the abstract machine that
is the program. And pretty soon copyrights look like patents and physical
machines look like abstract machines, and the bases of property law disappear in
a puff of smoke as everything becomes a metaphysical tangle of maths.
Let's fix that.
An automaton is an abstract mathematical machine. Some automata are models of
real-world machines. Models of real-world machines vary in the degree to which
they match the thing being modeled.
In theory, a really good model could be substituted for the actual real-world
machine.
Programs are models of real-world machines and processes. When they work well,
they are the poster children of the above principle, that a model can be
substituted for the real thing.
An abstract mathematical machine is equivalent to a mathematical language. Well,
maybe to a language plus the semantic mappings of the elements.
A mathematical language consists of vocabulary and grammar. (Natural languages
differ from mathematical languages in that both vocabulary and grammar are
fluid. In mathematical languages, The vocabulary and the grammar are fixed.)
A computer program is (the implementation of) a mathematical language, plus the
semantics. This includes both (compilers for) programming languages and the
programs written in those languages. In the case of a program to add two
numbers, the numbers are vocbulary, as is the addition command. The sequence in
which the numbers and the command are entered is the grammar. The semantic is
the function of addition, and is somewhat independent of the language itself.
(There is a corollary to the principle of linguistics, that words have no
inherent meaning, here.)
The language doesn't care about the output other than that the output shows
(recognizes) whether the combination of vocabulary and grammar was valid or
not.
In the functional (mathematical) model, the numbers and the addition instruction
are inputs, the addition operation, or transform, is (part of) the semantics,
and the sum is the output.
An API is the set of inputs, with a specification of the expected operation or
transform. Ergo, it is an abstract description of the language and its
semantics.
In many cases, the API of real programs is not fully rendered in human readable
form, thus the expression, "The code is the documentation." (Okay, in
most cases, actually.) This is similar to the specifications of a physical
machine not usually being fully exhaustive (especially in terms of error and/or
exceptional conditions).
We'd usually rather just get on with using the machine, you see.
So, when you dig down this far, you suddenly see all the frayed edges of all
sorts of social artifacts, including the legal bases of property, itself. (Oh,
nuts. Let's just get real and quote the preacher: "Vanity, vanity, all is
vanity, and there is nothing new under the sun.")
The architects of the Constitution and the original laws about patent and
copyright understood the above, and that's why there was not supposed to be any
intellectual property under the US Constitution. We modern, excited with our
actual implementations of maths in machines, have lost sight of the forest for
the trees.
If we get rid of the boundaries between the intangible temporary liens on pieces
of the market which copyright, patent, and trademark were intended to be, we
find ourselves eroding the very principle of law, and shortly without any
protection left against either tyranny or the anarchy which tyranny hides.
(Came together better than it has in the past, guess I'm going to copy this to
my reiisi blog and then try to refine it a bit on my defining computers blog.
Not yet though, I have a deadline hanging over me on a "real" job.)[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 10:24 AM EDT |
I say forget trying to find an analogy for APIs. Libraries are black boxes.
You do not know what is inside, and nor do you care. APIs are the list of
functions that are being made available to you, and the instructions on how to
use them. The API is only used by the programmer developing an application.
The application, when it is compiled does not use the API, but accesses the
library directly.
Consider the Windows .dll file (dynamically linked library). If you are
provided the .dll file alone, there is no way to determine what is inside it.
You might be able to us a hex editor to see the names of the functions, but that
is IT. You have to be told what the functions are, and what they are expecting.
That is the API.
Thing is, APIs are not limited to libraries. Any program that is making a
function available to someone else has to provide an API, or that functionality
cannot be used. Take for instance, FTP. We know that when you connect up to an
FTP server, you can use "cd <directory>" to change to a
directory, "ls" to list the contents of a directory, "get
<filename>" to retrieve a file, and "put <filename>"
to send a file to the server. These commands are the API provided by the FTP
server. I could write another program that uses the same set of commands as
FTP, but instead, it accesses a database and adds or retrieves table records.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 10:44 AM EDT |
The API are like sockets/connectors/buses: in the same way two devices can
comunicate through a connector, the program and a library implementation
interact through an API.
I guess real world connector reproduction (like the iPod/iPhone/iPad connector,
camera lens connectors etc) is somehow protected.
So I guess API should be protected in the same way/by the same law.
Every computer programmer would like connectors were not protectable, as
every photographer would like camera lens connectors would; so don't trust us
for being unbiased on this topic.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 10:45 AM EDT |
| This
wikipedia article describes several flavors of API, skimming that might give
you an idea.
The reason "API" is so nebulous is that it describes a very
high-level concept that programmers find useful in many different situations,
ranging from correctly re-using a single function that someone else wrote, to
re-using an entire class or collection of related functions, to re-using a
complete library containing dozens or hundreds of those things. It can also
cover situations where you break a large program into smaller pieces so that
different groups of programmers can work on each piece; each piece then becomes
a "library" or "component" or "subsystem" or something like that, and each one
needs APIs so the other pieces can interact and interoperate with it.
So the
precise embodiment of the "API idea" will be different in each of those
situations, what they have in common is the high-level concept. Even in a
single scenario (say, plugging a 3rd-party image-loading library into an
image-viewing program you are writing) the overloaded term "API" can mean
several distinct things, depending on the context of the conversation. The
image-loading library probably contains a bunch of functions and/or classes, and
small groups of those (or even single ones) are "APIs" if just that small group
of things can be sensibly used together. But the collection of these smaller
"APIs" in the whole library, is also called an "API" -- its the API of the
entire library, as opposed to the API for just one piece.
Let's take Java as
an example. Java contains a "class" called java.io.File, and this class has
methods with names like exists() and length() and lastModified(). The way this
works is that you construct a java.io.File with a filename, and then you can
call methods on that object to find out things about that vacation.txt file on
your filesystem:
java.io.File myFile = new
java.io.File("C:\documents\vacation.txt");
if
(myFile.exists())
{
// ... okay, the file exists! Do stuff with it
here!
}
So here, the exists() method is part of the
public API of the java.io.File class. That means it is meant for use by
programmers who use this class (as opposed to some private implementation detail
that is only meant for the author of the java.io package to use). You can't
really use java.io.File.exists() by itself, because you first have to create a
java.io.File object to call it on. So exists() by itself should not be thought
of as an API, but all of the public methods of the java.io.File class together,
do make up an API, because a program can use those methods together in order to
get something done.
So "the public methods and fields of the java.io.File
class" constitute an API. But there are lots of other classes in the java.io
package, and most of those also constitute APIs, for similar reasons. And then
when you look at a group of classes that are meant to be used together, you
might think of them as collectively being an API. It gets murky though, so the
easiest way to think about it is to just consider the entire java.io package as
being an API. But this is a shorthand for saying "take all of the public
classes in the java.io package, and get the public API from each one, and merge
all of those together". The result can be thought of as "the public API of the
entire java.io package". If you repeat this process at a higher level, you can
merge the API's of all of the standard Java packages together and end up with
something you might call "the Java standard library API".
Going back to the
747 analogy, saying "this function/method is an API" is like saying "this single
button or knob, is an interface allowing me to control 1 very low-level detail
of the plane".
When you say "all of the public methods in the java.io.File
class together, make up an API" that is like saying "this 2x4 inch area of the
control panel, which contains 12 different buttons and knobs, is an API for
controlling the plane's flaps". Several related controls, that are used
together to accomplish a slightly higher-level task.
Then when you say "all
of the public class APIs from the java.io package combined together, make up the
API of the java.io package" that's like saying "this 8 inch by 8 inch panel of
controls, plus this giant throttle stick, plus these two visual displays, are
all related to airspeed and elevation". So its a higher-level grouping of
functionality, and it contains many smaller APIs because the pilot needs to
manage many lower-level things in order to accomplish the higher-level goal of
seeing and adjusting the plane's airspeed and elevation.
Then when you say
"the entire Java standard library API" with its hundreds of packages, you're now
talking about the entire cockpit combined; every display screen, button, stick
and knob is part of a giant interface that the pilot uses to fly the plane.
"The entire Java standard library" with all of its rich functionality (files,
strings, network connections, compression, XML, graphics, layout, UI controls,
and many many more things) is like the entire plane--it has hundreds of
thousands of implementation parts, but the "interface" to the pilot is only a
few thousand controls and displays, through which he makes the plane do what he
wants. Same thing with the Java library (and other libraries, in any
programming language). The "API" part is the "interface", that you use to tell
the library what to do. But usually most of the library's code is the
"implementation" code, which has the job of actually doing it. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 11:46 AM EDT |
The C programming language and it's standard library functions are covered in
the ISO/IEC 9899. All ISO standards are copyrighted, and the ability to use the
standard to develop a conforming implementation is not explicitly granted. In
particular, ISO has a brochure on copyright, and they don't even let one quote
the standard in the book without negotiating a royalty. Fair use is not
mentioned in the brochure, so presumably that depends on the country laws and
practices as to what fair use implies. In theory, it means that ISO (or the
respective country standards bodies) could go after people implementing
programing languages, or even the programmers as making derived works of the
header files that derive from the standard. Obviously, that would not be good
for the programming community (or people using the programs).
As the Oracle-Google case is being brought in the US, US laws govern what is
considered expressive or abstract. But, copyright laws are only uniform to the
extent that copyright conventions are uniformly transferred into national laws,
and still differ based on how laws are interpreted. A victory in US courts for
programmer freedom does not necessarily translate into a victory everywhere. Are
programing languages going to be sucked into the morass of FRAND? I certainly
hope not. And I hope Judge Alsup understands the stakes of his decision outside
the confines of just this case.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 12:41 PM EDT |
Computers are very precise about 'what' to do, but have no concept for 'why'
they are supposed to do anything.
The API has a human-readable form which states the purpose of each function in
the library. A user wanting to find the average of a group of numbers would
search for a description that matches his need. This is much like searching a
thesaurus or dictionary to find a good match for the description a writer needs.
Copyrights certainly apply to the descriptions of each word in a dictionary,
because they could be arbitrarily useful or difficult, but they don't apply to
the list of words themselves.
With normal human language, the smallest nugget of information is a single
word being listed. In API's, the smallest nuggets are individual methods for
the classes. Human words are arbitrary combinations of syllables and spellings
that are unique. API methods are arbitrary combinations of names, class paths,
inputs, and outputs that are unique. Just as there are well known rules of
language that are visible in language, there are well known rules that are
visible in API's. In english, a noun ending in 's' is referring to a plural of
that noun. In java, a class path ending in a method 'toString' is referring to
changing something into text output.
We use such conventions and rules to make it easier for humans to learn how to
use a language or API. The computer could care less if something named
'toString' returns text, erases data, or freezes the system. All it cares about
is that there is only one possible sequences of class path and method that is
being referenced so it knows what implementation to run.
Google was careful not to make a direct copy of the descriptions of methods or
the implementation of methods in their code, but did follow the same rules java
uses for resolving class path and method definitions. Trying to force a change
in the accepted rules would force the user to use a different language entirely.
It would be like saying 'box' will refer to kittens and 'boxes' will be a
lightbulb. You could do it, but no human being would want to learn such
arbitrary rule-less nonsense.
As a result, the documents produced by automatic tools to map the definitions
will make the google API look extremely similar, simply because they are using
the same rules and unique definitions. Only the text describing what it does is
likely to be different, just as a dictionary entry will vary by publisher.
Sometimes the text will be the same, just like some dictionary definitions will
be the same between books. If you follow the rules and get the same
understanding, this is a natural consequence.
We don't allow copyright on these minimal nuggets of information, because it
is like copyrighting oxygen and telling nobody else to use it. It adds a
bewildering arbitrary character that harms everyone. Only when you start
chaining these minimal nuggets to do larger works, do we allow copyright to
apply. In the end an API is a list. An arbitrary, boring, minimal list.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 01:00 PM EDT |
As discussed here so often, computer programs are, at base, mathematical
algorithms.
Discrete mathematics, the branch of math upon which computer
science is based, is a system of logic. That logic system consists of a set of
concepts and methods for their application, which anyone who employs discrete
math must use in order to obtain reliable results. If you don't follow
the rules that define the methods, you cannot be certain that your calculations
are correct. Those rules are, in effect, the API of mathematics.
What
are the rules? Let's look at a key mathematical component that is implemented
literally in computer programs: the function. (Hint to lawyers: the name
function suggests that its purpose is, well, functional). The
defining characteristic of a function is that it takes input values and maps
them to discrete output values, and in doing so it guarantees that, for each
discrete set of input values, it will always return the same output
value.
Here is a math function definition:
G(x) = x +
1
It defines a name (G), an input (the variable named x) and an
output mapping (x + 1). It is understood from the underlying definition of
functions that x is a number and x+1 also will be a number. In API terms,
everything to the left of the equals sign is the definition, to the right is the
implementation.
Mathematicians live in a world of one-letter names, but
programmers have the luxury of using descriptive names. So, a programmer who
wanted to use the function to increment a number might write it
as:
increment(x) = x + 1
In a real
programming language, C, it might look like this:
int
increment(int x) { return(x + 1); }
Here, the definition
precedes the first curly brace, the implementation is contained within the
braces. The definition is what a programmer would see in an API specification,
while the implementation likely would be compiled into binary. Here also, the
definition explicitly states that the input must be an integer and that the
returned value will be an integer.
The thing to note is that the
implementation can be changed in any way, so long as it produces the same result
guaranteed by the definition. In this case, it could be { return(X + 2 -1); },
and it would still work (though not as efficiently).
In practice, an API
specification may contain, in addition to functions, things such as constants,
signals, slots, etc. They may or may not be proper functions, but they are
related in the sense that they are a guarantee that, if used properly in a
program per the interface definition, they will obtain the specified results,
and only the specified results. [Note: I'm not a C programmer, so
please forgive me any syntax errors.]
Although Oracle tries very hard to
engender confusion about what an API is, the key is contained within the acronym
itself: the I is for Interface, not for Implementation.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 01:28 PM EDT |
Cars have batteries. Sometimes, batteries go dead, and need to be charged.
There are many different cars, and many different batteries to accomodate them.
There are also many kinds of battery chargers. How do they all work together?
There is an API. it specifies that each battery will have a positive and a
negative terminal, and that those terminals will be labelled with a
"+" or a "-" to distinguish them. Each charger likewise has
two leads, color coded red for positive and black for negative.
A user does not need to know what kind of battery they have, nor what kind of
charger. Neither do they need to know anything about the inner workings of the
battery or the charger. As long as they follow the API it will work.[ Reply to This | # ]
|
- A simple API - Authored by: Anonymous on Monday, April 23 2012 @ 04:16 AM EDT
| |
| Authored by: mosborne on Saturday, April 21 2012 @ 02:31 PM EDT |
As I started reading this article, it occurred to me that the BIOS (Basic Input
Output System) used by practically all IBM-compatible (that term itself refers
an alternate API implementation) PCs.
It was the implementation of the IBM BIOS API by another company (Columbia Data
Products) that ushered in the personal PC era that we know of and enabled the
explosion of different PC hardware. If the APIs had been copyrightable, then
there would have been no Compaq, no Dell, no Gateway, no Acer, no countless
others.
[ Reply to This | # ]
|
| |
| Authored by: mosborne on Saturday, April 21 2012 @ 03:28 PM EDT |
The US Supreme Court’s 1880 decision in Baker v. Selden said that the blank
forms used by Selden in his book were not copyrightable. An API is to a
programming library what Selden's blank forms were to his accounting method.
Each individual blank form served a particular purpose just like a particular
API. The blanks on the forms serve the same purpose as the parameters of an API,
i.e., they provide a means for the person *using* the API/form to customize the
result.
In fact, each of Selden's blank forms could be trivially represented by a
program API, one API for each form, with every blank a parameter. The result of
the calling each API with the desired parameters would an identical paper form
to that that could be filled in by hand.[ Reply to This | # ]
|
| |
| Authored by: greed on Saturday, April 21 2012 @ 03:49 PM EDT |
Or, at least, something the size and shape of a credit card.
One of my
assignments in University was exactly that: a simple database to run on a
smartcard. (JavaCard was still in the future at that point.) The idea was, you
could plug the smartcard into a point-of-sale terminal, the terminal would
deduct from your balance and ask the smartcard to record the receipt
items.
So you'd never need a paper receipt; you could then plug the
smartcard into your home computer (smartphones were still in the future at that
point...) if you wanted to check.
(Obviously, this was just to make the
assignment a little more interesting; actually implementing a system that way
would be a massive security failure.)
Apple, actually, is so sure you DO
want a database on something the size of a smartphone that iOS comes with
several "persistent data stores" built right in, including
"SQLite+".
Programmers can do amazing things when you stay out of their way;
that's part of why no-one (I know) ever cared for JavaME.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 04:16 PM EDT |
An ABI is an interface standard used to communicate between compilers and
linker/loader Operating System routines. An API/ABI bridges the compile time and
runtime environments: programmer, compiler, and runtime OS/VM.
Any analogy opens the door to catastrophic misinterpretation and the end of
FLOSS in the US. Fools tread there! APIs and ABIs are a tar pit for foolish
lawyers. Ask SCOx.
APIs/ABIs are local communication standards meant to be obeyed by modularly
written programs, drivers, and utilities. APIs are ALWAYS necessary for
programmers, to get their program to work with the larger runtime environment.
Similarly, ABIs are ALWAYS necessary for running routines for linking and
loading the proper modules correctly, with some guarantees of operational
correctness.
Finishing with APIs, programmers search perhaps multiple APIs for those
interfaces optimally supporting extensions to their custom application code.
Good programmers do not reinvent if their community already provides the
solution.[ Reply to This | # ]
|
| |
| Authored by: BitOBear on Saturday, April 21 2012 @ 05:57 PM EDT |
Woke up with a thought. This is an example of a fully conceptual API (one with
no concrete calls) that includes by implication one of several API's of your
choice. This API is entirely "rules" and contains no "API
Files" at all.
===
I hereby declare The Arbitrary Execution Web Server API:
Overview: The service supplier shall set up a web server that accepts the source
code for a program in the desired languages, and the the web server shall
respond withe the output of the program and any error messages in a mime
multi-part response.
Detail:
(1) The client shall send an HTTP GET request to the server as
/exec/language_name, where language_name is any supported language offered by
the server such as C, TCL, Java, Listp etc.
(2) The body of the get message shall be either
(2a) The unadorned program source.
(2b) A multi-part mime message, the first part of which shall be the source code
and the second part shall be the data the program needs supplied. The data shall
be provided to the program on its standard input file descriptor.
(3) The server shall respond with zero or more HTTP CONTINUE messages, at least
one every 30 seconds, for the duration of the compile and execution phase. If
the connection is lost the program shall be terminated immediately and the
results discarded.
(4) The web server will end the session with an HTTP OK message that contains
any compiler messages including errors, followed by the output of the program.
===
Okay, so here is an API I just invented. It is -purely- semantic. It doesn't
tell you, or offer you, any details about how you will create, send, or decode
the HTML messages. It doesn't provide you with any procedural calls that or
files that the code you are writing will or will be passed directly to any
compiler.
This is still an API, it is just completely language agnostic. It is also
completely semantic and, since I haven't written any code, it is completely
theoretical.
At this moment I could start writing the server while you start writing the
client. So this API is also a specification.
If everybody agreed that we were going to do this very thing, then the API would
become a Standard.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 06:46 PM EDT |
There is also the issue to consider that an API is essential
to the use of the language. In the case of the menu bar, the
company that first made it was not encouraging everyone to
use their menu bar.
Here SUN has been encouraging everyone to use JAVA (because
it benefited them.) They wanted people to use JAVA.
They had no problem with people building things in JAVA and
selling the results.
Sun would make money selling the OS that the JAVA app would
run on, or would make money licensing their version of the
JVM etc.
To now turn around and claim that the API's are proprietary
and cant be used without a license goes against all that SUN
have been pushing since JAVA was invented.[ Reply to This | # ]
|
| |
| Authored by: DMF on Saturday, April 21 2012 @ 07:08 PM EDT |
| I don't believe that anyone (even pj ;)) is having a problem understanding what
elements comprise an API: it is a list of classes and their public attributes.
What seems to be throwing everyone a curve ball is that there is no
particular *scope* implied by the term. The scope in usage is indefinite and
contextual. As a user, when I'm writing a program and I refer to "the API I
need" to write the program, it is the program that defines the scope of the API.
It may be 40 packages, or only System.out.println().
Or the scope -
from the point of view of the provider - may be the set of all possible API
elements, or a purpose-directed subset thereof.
In either case, to refer to
"the 37 APIs" is a misuse. One should refer to "the 37 packages" comprising
the API for the Java Class Libraries (or whatever the technical term is
for the grouping). If Judge Alsup understood that, I think the matter would
become clearer for him.
Hope this helps.
[ Reply to This | # ]
|
- "the 37 APIs" - Authored by: Anonymous on Saturday, April 21 2012 @ 09:29 PM EDT
| |
| Authored by: kenryan on Saturday, April 21 2012 @ 11:57 PM EDT |
I don't really have a point to this post, I just wanted to
make an observation. (note I'm a technical person, but in
hardware with some low-level software. I stay far away from
application programming).
Reading Groklaw over the last few days seems really to have
emphasized something.
The whole concept of APIs seems to be very poorly thought
out, in the sense that nobody can seem to decide on exactly
how it should be defined!
In other situations a couple people cook up a few analogies
to explain something, and those with expertise in the field
generally end up agreeing on one that illustrates whatever
point they want to make.
In following this case there has been post after post with
API analogies, all over the map. There doesn't seem to be
any convergence on just how an API should be thought about.
How on earth will a jury of laypersons ever be able to
understand what an API is well enough to make sensible
decisions about it when experts can't agree?
---
ken
(speaking only for myself, IANAL)[ Reply to This | # ]
|
| |
| Authored by: jvillain on Sunday, April 22 2012 @ 04:14 PM EDT |
| The judge is saying things like this.
Judge Alsup: "I question
what that last witness added to this case."
Ouch. Maybe it all
comes clear after the next witness but I suspect he was put on the stand purley
to muddy the water. I am still waiting for some of from Oracle to say in no
uncertain terms that Google was told they couldn't do what they did with out a
license and this (the account manager) would have been the most likely guy to do
it.
If I was in the jury what I got out of it was that Google was willing
to take a licence when they needed it and didn't take one when they thought they
didn't need it.
I am really starting to question Bois's rock star lawyer
status.Sure he won the MS trial but that case made it's self. Google hasn't even
really started to tell their side of the story yet and this is already looking
bad for Oracle. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, April 22 2012 @ 05:53 PM EDT |
The biggest High Tech case in years. Two industry heavyweights.
Highly abstract legal argument on computer programming language.
The judge announces from the bench:
> I don't have a fancy computer, all I have is this
> [ holds up a single piece of paper with columns visible and
> a yellow PostIt note sticking to it].
priceless[ Reply to This | # ]
|
| |
| Authored by: iraskygazer on Monday, April 23 2012 @ 03:43 PM EDT |
What about a very basic analogy.
A TOC is to a book like an API is to a software library, aka. Java. The main
difference is the fact that you can read/use a book without a TOC but you will
have a very difficult time using a software library without an API.
Unless of course, you are the creator of the library and have access to the
internals of the software library. Thus, the main purpose of an API is to
release information to allow software programmers to use your software library.
The programmer, who isn't the creator of the library, doesn't have to know what
goes on inside your library as long as you publish what goes in and what comes
out; aka. a black-box version of an API is made public so your software library
can be used by the public without caring how you manipulate input to get the
desired output.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 24 2012 @ 10:48 AM EDT |
Imagine there was a delivery company that would deliver whatever a business
needed. The business would fill out a paper form, fax it to the business and
then the business would deliver whatever they had asked for. The form might
contain labels, like "Name" or "Address", and maybe there'd
be a set of
instructions on the back, written as tersely as possible, describing what the
business should write in each of these fields.
The businesses, being clever, develop rubber stamps that fill in the info that's
always the same so they don't have to write it out every day. When a new
competitor delivery company starts they lay out their form in the same way as
the existing form, so that the businesses can use the same rubber stamp.
They write their own set of instructions, but there's only so many ways you
can describe how to fill in an address or an item number, so the descriptions
use many of the same words.
Assume that if you couldn't lay out the form the same way no one would use
the new delivery business, and that it is super-extra-useful to be able to swap
between the two businesses (they both deliver to areas the other one doesn't,
even if they overlap some.)
If that form would be copyrightable I suspect APIs should be copyrightable. If
not, then not. [ Reply to This | # ]
|
|
|
|
|
