|
|
|
| Authored by: Anonymous on Saturday, April 28 2012 @ 04:21 AM EDT |
Willy Wonka has a marvellous automated factory that makes nuts and bolts. To
control his factory, he creates hundreds of robots to each perform a specific
task that the factory must perform. The robots are arranged in rooms so they can
easily be found.
To activate one, a munchkin has to give it the right signal. For instance, to
get the temperature robot to go and turn the thermostat down a little, it might
just mean pressing a button. Or, to get a robot to make a knut, the munchkin
might need to give the robot a small bar of iron, and recieve the knut back
after it has trudged off to make it.
[ Reply to This | Parent | # ]
|
| |
| Authored by: argee on Saturday, April 28 2012 @ 04:23 AM EDT |
In the days when I used to do 8080 assembler programming,
we used the API's to interface to CP/M, the operating
system.
It went something like this, to send a character to the
i/o (I forget the exact details):
You put the character in one of the 8080 registers.
You the put 01 hex in another register.
You then CALL the entry point of the CP/M o/s.
The character prints.
The o/s returns with a code in one of the registers
to tell you if it succeeded or not.
We also had libraries, like to do math. You want
to multiply two numbers, it went something like this:
Put first number in stack
put second number in stack
call the library.
The result will be in a register or on the stack.
How the library worked was the implementation; the
putting the numbers and requested operations in
registers or stack was the API. The documentation was
some text that explained it, like I did above.
Some CPU's have minimal registers and do everything via
the stack, like the Apple's 6502. Some, like Intel
architecture 8080, 8088, Pentium, etc. are register
oriented.
In higher level languages, the situation was/is the same.
You write the program, put the parameters in the right
place and call the language and get the results.
What goes where and with what names is the API.
No API, can't use the language. Be Java, Harmony, C,
or assembler. No API docs, you are stabbing the blind.
The actual implementation; ie, what the language or
library does with the CALL is the implementation.
Here, Google is saying the API is not protectable, the
documentation parameters are not protectable, but the
actual wording of the documentation is like a novel and
may well be, but can be rewritten. The language or
library is very definetely protectable but can also be
rewritten.
It will be interesting to see what the Judge and the Jury
decide. To tell the truth, I am lost at sea with the
explanations as given, and the instructions to the Jury.
Upon reading the instructions, my feeling was that ORACLE
should prevail, although common sense tells me otherwise.
---
--
argee[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, April 28 2012 @ 10:35 PM EDT |
The "NEMA 14-20 electric outlet" specification says that there are
three holes, in particular places, the round one is ground, the long blade is
"hot", the short blade is "neutral", and the circuit is
supplied with 110-120V current at no more than 20 amps.
The "Edison screw socket" light socket specification has similar but
subtly different specifications.
When making an electrically powered device you can choose which API to use --
Edison screw socket, or three-prong plug? But if there are already existing
electrical devices, the choice is absolutely forced: all light bulbs require a
screw socket, practically everything else needs to have a three-prong outlet.
Behind the three-prong plug (or screw socket) you can implement the electrical
supply in any number of different ways: copper wiring, aluminum wiring, many
different sorts of insulation, many different ways of generating the power.
Different implementations.
You can't copyright the shape of the of the electrical socket. It's absolutely
necessary for compatibility; there is no creativity in it once it's in use. You
shouldn't even patent it, because if you do nobody's gonna use it.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, April 29 2012 @ 03:17 AM EDT |
I think you're close and maybe close enough, but here's what I'd
say.
First, there's too much variability in your example. Let's make it
simpler.
There are four slots and four keys.
Each key represents a note. Each
slot represents when in the sequence the tone
sounds, left to right. The
keys are the api, that which the external
user can use in order to make the
device change its behavior and outputs. The
documentation tells the user what
frequency sounds when the key is inserted,
so the programmer understands the
parameters of the api. The interface is
made up of the
slots the keys go into
and the speaker that broadcasts the note. A combination
of
keys in slots is a
program.
Let's add
that the box whistles at 5 pm, so everyone knows when
it's time to open a beer.
This is not part of the api, because it happens
regardless of the
user/programmer's key
selections. It is probably part of the
specification, because the specification
should detail behaviors and outputs,
whether the user controls them or not.
So, to
recap: - Specification: description of behavior and
outputs.
- Interface: the specific mechanisms of inputs and
ouputs.
- API:
Inputs the user may provide
which change the box's
behavior or outputs
- Documentation: Details
about the Specification,
Interface, and API.
- User Program: a sequence
of steps from the API so
the user alters the box's behavior or outputs.
I hope this helps.
For this case, and applying the modified analogy,
Google built a tone box that
used many of the same keys to the exact same
result as
Oracle's box:
substantially the same API. If Google
had copied the box's innards, Oracle
would have a stronger case. Or if Google
had made the Red key C and all the
other keys different notes, Oracle has no
case. But we are talking about an api
in which there are thousands of exactly
matching keys which when put in
Google's box do the same thing as when put
into Oracle's box. (Google didn't
copy all of Oracle's keys and Google added
some keys of its own which won't
work in the Oracle box.) Hope it
helps, and to be honest there is some
permeability between the concepts, which
adds to the confusion. Plus, we are
really talking the java libraries, though not
the implementation (what's inside
our tone box). Subtract implementations
from a library and that leaves the
names and
groupings so, Oracle is offering API as the word that describes what
they claim
was infringed. Partly, this is because a specific name of a function
or method
is not
protected under copyright so Oracle prefers to call them
something else. Using
API is unfortunate, because when
programmers like me
hear Oracle claim the API is protected, some think that
Oracle intends to
go
after us programmers for infringement, because we refer to the
documentation in
order to refresh our memory when writing our programs. We
copy parts of the API
when we leave
notes to non-IT users detailing the keys and slots for the melody
we'd like them
to play. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, April 29 2012 @ 05:48 PM EDT |
As I read that I couldn't help but think of the Church or
Cathedral or Concert organs or any other instrument.
So the copyrighted work would be the piece of music as
written down by the composer. The 'API' would be the
interface to the machine - the little black and white keys
and all the stops that you could pull out to change the
sound that was produced. And that was the purpose of the
original composition - to produce a pleasing melody. Whether
it was played on an organ or piano or violin it would be
instantly recognisable as a composition by J.S.Bach or
whoever.
The analogy breaks down in so many ways because there is not
a one to one relationship between the input (the
composition) and the output (the sound produced).
But the composer still retains the copyright to the original
work no matter what way was used to actually produce the
output. And the manufacturer of the instrument used to
interpret the composition could equally well have patents
and trade secrets embodied in the instrument and maybe even
copyrights on the artistic appearance of the instrument.
So much hand waving about 'our valuable IP' is done by
lawyers that sometimes it is difficult to work out exactly
what they are talking about.
SSO. What the hell is that and what protects it? Is it
copyrightable? Then where is the document that defines it
and when was it submitted to the USPO? Is it patentable? If
so it is no more than an idea - do you need a physical
machine to represent? No? Is it a trade secret? Hardly,
after all the books that have been dedicated to explaining
exactly how the Java language works and is supposed to work.
What else is there? Oh yes trademark. To be able to use the
coffee cup you have to have a licence. But you don't have to
if you don't want to have the coffee cup.
So what's left to protect Oracle's VIP? Answer - nothing.
There is nothing in the old Sun IP cupboard left. It is
empty. There is nothing there. Nada. Jumping up and down and
wailing about all the money you spent and somehow Google
stole it all from you doesn't wash frankly. Sun hardware
division - I guess you ought to do something with that -
after all that's about the only bit that Sun hadn't tried to
open source before you bought them isn't it.
Sorry about the rant but this seemed like the best place to
let off steam![ Reply to This | Parent | # ]
|
|
|
|
|
