decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Fine, here's a car analogy for APIs. | 438 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Fine, here's a car analogy for APIs.
Authored by: Anonymous on Thursday, April 26 2012 @ 04:05 PM EDT
"Don't you get access to the API just to do an app?"

Certainly, yes. I agree Oracle's reasoning is VERY flawed. An API is merely a
description of how something will operate. Take a car's steering wheel and gas
pedal and shifter for example. If every car used a different set of controls it
would be chaos. Instead, they all have a Common Driver Interface (they share an
API). Windows has an API, GNU/Linux has an API, iOS has an API, everything has
a "description of how you use it" -- It's the basic uncreative facts
of how software is made.

The driver doesn't need to know how an engine works, just that the accelerator
speeds up, brakes make you stop, you turn the wheel to steer. This is like a
software API. Call "print" to output text. Call max to return the
larger of two numbers, etc. Shift to R for reverse. The application coder (car
driver) need not know how the print or max or transmission or engine is
implemented or built -- They MUST know the API in order to operate the (virtual)
machine.

Additionally, The driver of an internal combustion engine car can also drive
electric cars -- They have the same interface even though the platform is
different. This is like the difference between Java and Davlik. They're both
totally different engines, but they both use the same language API -- You talk
to the Virtual machines in the same Java language, but a golf cart is not a F1
race car just because they share the same controls.

What Oracle is saying is that the FACTS of how you MUST use the language's
standard libraries (the API) is copyrightable -- Facts aren't copyright-able.
The fact that a car has a steering wheel that turns left and right can't be
copyrighted. The fact that max returns the larger of two integers shouldn't be
copyrightable -- How you achieve this could be copyrightable, if it took a
creative effort to create. However, there's really only one optimal way to
return the larger of two numbers -- You compare the bits, and return the one
with the largest value. If that's copyrightable then individual words in
English should be copyrightable too. There's only one way to spell the word
"A", eh? (that's really how basic and elementary the max and
rangecheck functions are).

Javadoc generates the API documentation -- The user manual. To me (a
programmer) it would be like watching a car driver operate a vehicle -- Oh,
press here to go, and there to stop, and turn the round thing to steer.

MACHINES generate the API specification from the interface FACTS. The JavaDoc
program reads the source code, extracts comments (descriptions) about the
functions and the facts of how the functions must be called, and create a
catalog of HTML documents that just say: "SteeringWheel( angle direction )
- Set steering wheel to 0 degrees to go straight, negative numbers indicate
degrees to turn left, and positive numbers go right); Note: You can use your
hands or knees to turn the wheel." Notice how there's NOTHING at all
creative about this -- The facts of how the function MUST be used are listed.
The creative bit about how turning the wheel translates into rack & pinion
turning wheels or power steering systems assisting the driver or anything of the
sort is not in the API. Those are the implementation details.

You must know how to use a steering wheel to drive a car -- If you only fly
jet-fighters with joysticks, you can't hop in a car and use a joystick to
control it if it has a steering wheel. This mismatch would happen if the API
names were even a single letter different. The computer would say: Look, I
don't know what a Thruster is, I have a Gas Pedal. I don't know what Yaw Pitch
Roll is, I have a "Steering Wheel", no such thing as a
"Joystick" here.

Cameras can't hold copyrights on the pictures they take... The Javadoc program
wrote the spec after it analyzed the source code, much the way a camera writes
an image to memory after it analyzes light input. If you arrange a bunch of
flowers, and a photographer snaps a shot as you carry it around at a wedding --
Guess who gets the copyright? The Photographer! Oracle (Sun) arranged the fact
of the API, but Javadoc created the API documentation -- IMO, it should NEVER be
allowed to be copyrighted. There is no creative effort required to produce it,
AND it was made by a mechanical process, BY END USERs. If any one should hold
the copyright it should be every coder who ever typed: "javadoc *" at
the command prompt... Just like the photographer who presses the shutter button
gets the picture copyright. They "arranged" the scene... Well, we
chose which arrangement of documentation to generate, we could have given all
sorts of parameters to Javadoc to generate alphabetized, less detailed docs,
etc.

You can't tell someone how to drive a car without exposing the facts of how to
control the vehicle. You can't tell someone how to program without telling them
the API (facts) about how the language and library are controlled.

Sure, a lot of time and effort goes into making cars more drivable, but just
because two cars have steering wheels on the same side of the vehicle, facing
forward, doesn't mean one car company copied anything from the other. Just
because two Virtual Machines have the same Application Programming Interface
(API), doesn't mean they copied anything but facts from the other -- Facts that
shouldn't be copyrightable.

Google has done more than just learn to drive -- They build a whole new type of
engine that has the same user (programmer) interface. Oracle (Sun) requires a
license to call such new engines "Java", and test them to make them
compatible, but Google isn't doing this -- Theirs is Davlik, and it's not
compatible.

It's essentially SCO v Unix all over again -- API == Header File (that's really
EXACTLY where the API is in other languages -- Java conflates interface info
with implementation details, that's why Javadoc API spec generator exists -- It
extracts the info that would be in a C or C++ "header file").

I don't think the API issue has been explained properly to the jury. The judge
seems to get it, with his comment about the names being the same, but the
implementation being different.

I disagree with the opinion that a collection of function/method names would be
copyrightable -- These are named in a non creative fashion to be as utilitarian
as possible. Sun didn't say, "we're going to arrange all the names in such
a way as to make them good to use" -- most Java programmers will tell you
the verbose naming standard is one of the ugliest parts of Java, because it
arose from necessity, and following a naming algorithm, not ingenuity or
creativity.

The car and fashion industries don't have this patent and copyright problem --
They're too utilitarian. If you could describe what you were trying to do to a
computer, it would generate uninvented utilitarian names like these for your
programming elements:
AttributedCharacterIterator.Attribute

That's a name in the java.text API... What else would you name something that
was an attribute fed into the iterator of attributed characters? These are all
specific technical terms that mean a certain thing. I have an
AttributedCharacterIterator structure with an .Attribute property in my C
program's text handler. That's just what you name such things. It's as
uncreative as can be. It means an property that symbols can have when you go
down a list of symbols to display them. But, you don't use "symbol"
and "property" or "go down" because those names mean other
specific things to a programmer...

Oracle is basically saying that this machine generated list of facts, akin to
names and numbers in a phone-book, or facts of basic actions which was created
purely out of necessity, not some grand design, is somehow copyrightable and
valuable. It's not. It's only value is that we MUST use it to create
compatible Java programs -- Those names must be used to work with Java. The
actual names could be anything, and we'd still have to use them. We're stuck
with steering wheels because that's what we decided to call them. I dare you to
go to the auto-parts store and try to buy a replacement "Yaw Hoop".

If Oracle wins, no one will be able to write compatible software without
infringing someone else's API spec. Everyone will have to name everything
differently and create all interfaces from scratch -- I'll write a program to do
the random name generation for me, because we'll need such things to avoid
naming things similarly. All it will do is slow us all down. The DMCA has some
compatibility provisions, no? Well... I wonder why? Surely Google will win on
fair-use if not merely for the sheer absurdity of Oracle's claims.

IANAL, but surely some lawyer (and lay-folk) could more readily grasp this
simple concept if it were explained properly in such simple terms.

[ Reply to This | Parent | # ]

Even Microsoft lets you use APIs freely
Authored by: Anonymous on Thursday, April 26 2012 @ 04:50 PM EDT
Even Microsoft lets you use their APIs freely and they're as proprietary as it
gets. It's true that Sun was always "too nice" on some level and that
got them into trouble sometimes, but allowing people to use APIs freely wasn't
one of their mistakes.

For all its faults, Sun was a good company led by decent people. I wish that
Google had bought them instead of Oracle.

[ Reply to This | Parent | # ]

Yes, Kinda... but not really!
Authored by: sproggit on Thursday, April 26 2012 @ 06:16 PM EDT
The API in this context is the boundary layer, the point of connection between
[let's use an example] an executing program and a library function. I'm going to
use "client" and "server" terminology here. [ What's one
more analogy between friends? ] The "client" code exists in the
application program that is written in JAVA by an application developer. The
"server" code may be part of the language, the VM, or a functional
library added to the language to extend it's capabilities.

Sun defined the "API" - the interface and points of connection that
exist at the boundary of the "server" code, and in the Sun
implementation of JAVA, they wrote all the server code as well.

For Android, Google and others wrote the "server" code, but because
they adopted the same boundary layer (API set), "client" programs
written for JAVA stand a good chance of running on Android [because the API is
the same].

Oracle's argument seems to be that because they "own" all the rights
to JAVA, then they get to decide whether or not Google have their permission to
implement Google's own "server side" set of program functions, written
as Android. Oracle are arguing, essentially, that Android is an un-licensed
clone of JAVA.

The problem with this argument is that there are too many precedents against the
position. to be honest, my non-legal outlook is having terrible trouble agreeing
with Judge Alsup that the SSO of the API is copyrightable. To me, it's like
trying to assert copyright over the first few bars of a piece of music, or over
the table of contents in a book which consists of several lines of "Chapter
'n' and a page number".

Examples of cases where companies have implemented clone copies of "server
side" libraries without these legal precedents being set include :-

0. Harmony - an implementation of JAVA on which Android is based and over which
Sun had no issues. It seems a bit specious for Oracle to turn up late with a
different view. Not sure of the legal terminology, but isn't that precluded by
estoppel?

1. Computer Associates [not the original authors] who wrote the ACF/2 Security
tool for IBM Mainframes - this implements the mainframe security API.

2. WINE [as in Wine Is Not an Emulator] which implements the Microsoft Windows
API Libraries on the Linux OS.

3. Pretty much any other "software emulator" you can think of - i.e.
an abstraction layer that provides a set of APIs that actually belong to another
application/OS/platform... so examples would include things like the Atari ST
Emulator, the Commodore 64 Emulator, the SNES emulator, etc. All these
implementations offer API sets that match the original technology but which have
been ported to a completely different platform.


So Oracle are trying to argue that because they wrote the server-side code that
implements the original SSO of the JAVA API's, they own the copyright. The truth
is that there is a mountain of legal precedent [or perhaps it is more accurate
to say real-world examples] that have found the opposite.


[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )