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
Long lists of uncorrelated information (you misunderstand the witness) | 270 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread
Authored by: bugstomper on Thursday, April 19 2012 @ 11:02 PM EDT
Please summarize error->correction or s/error/correction/ in the Title box

[ Reply to This | # ]

Off Topic threads
Authored by: bugstomper on Thursday, April 19 2012 @ 11:03 PM EDT
Please stay off topic here

[ Reply to This | # ]

News Picks Thread
Authored by: bugstomper on Thursday, April 19 2012 @ 11:04 PM EDT
Pick your News here. Please put the title of the News Pick in the Title box and
include a clicky link to the article for when it scrolls off the sidebar.

[ Reply to This | # ]

Comes transcripts here
Authored by: bugstomper on Thursday, April 19 2012 @ 11:08 PM EDT
Please post your transcriptions of Comes exhibits here with full HTML markup but
posted as Plain Old Text to make it easy for PJ to copy and paste.

[ Reply to This | # ]

Day 4, Thursday, Oracle v. Google ~ pj
Authored by: Anonymous on Thursday, April 19 2012 @ 11:13 PM EDT
I don't understand how copyrights can be part of this case. As I understand it,
much of the java specification and core library was released under the GPL2...
which--as microsoft is so fond of saying--is viral. That is, if any one part of
the "system" is put under GPL then the entire quantity has to be under
GPL. That would imply java.lang and any java.* and any API whatever. (The
link/library safe version is the LGPL, which is not what this is licensed
under.)

What "line" am I missing that the GPL cannot cross?

[ Reply to This | # ]

A. Packages and methods are fundamental tools of the language.
Authored by: Gringo_ on Thursday, April 19 2012 @ 11:41 PM EDT

Isn't that the smoking gun, right there? "Packages and methods" are part of the API specification. He is saying they are fundamental to the language - ie: the foundation. So if you have a right to use the language without a licence, then you have a right to the API specification, and therefore you could use that to write your own libraries that perform the same function's as Java's libraries.

This was on redirect of Mark Reinhold, by Oracle's Lawyer Michael Jacobs. This is Oracle's witness - telling the world that the API specification is fundamental to the language.

It's late, and I am very tired. Do I have that right?

[ Reply to This | # ]

APIs are not source code
Authored by: Anonymous on Thursday, April 19 2012 @ 11:42 PM EDT
And what I learned is that APIs are not source code. They are ones and zeroes for the computer to use. Correct me if I'm wrong, but how can you copyright ones and zeroes?
PJ, it is all about context when referring to the APIs. (Oracle are doing their best to muddy the waters here by using the term on its own without qualifying whether they mean the documentation, specification, source code, or binaries).

An API has to be developed in a computer language as source code. After that (in the case of Java) it is compiled into byte code and shipped to customers in a library (binary form). The average person coding in Java only needs access to the libraries to produce their programs. Whilst the source code to the APIs might be made available too, it is only there for reference purposes. That is my understanding. It is certainly not essential for developing Java software - only the Java byte code interpreter (JVM) and the libraries containing the APIs in byte code form are needed.

As far as I know, only the API source code can be subject to copyright. I can't imagine that the API libraries output from the Java compiler can also be subject.

[ Reply to This | # ]

APIs are not source code?
Authored by: mschmitz on Thursday, April 19 2012 @ 11:56 PM EDT
PJ:

"And what I learned is that APIs are not source code. They are ones and
zeroes for the computer to use. Correct me if I'm wrong, but how can you
copyright ones and zeroes?"

I hate to correct you - but the quote was about 'API libaries'. These are, in
fact, binary code. The particular arrangement of these ones and zeroes may be
copyrighted as far as I've understood (as specific machine-readable expression
of the idea 'API'), is that not so?

Jacobs' question (which is what Reinhold answered with above quote about API
libraries) was: "Google asked about accessing source code via APIs" -
this does not seem to be mentioned earlier in the report, and the question does
not make much sense on the face of it. Why would you need to use the Java API to
access some source code? You might need a way to access what version of Java
(ME, SE, EE) the application is running on, but source code??

It again boils down to the question: what is an API? At its most basic, as best
as I can make out, the API is a set of method definitions, describing exactly
how an application can go about invoking methods supplied by the supporting
framework (runtime system, operating system, other software libraries aka
'classes' or 'packages').

The method definitions can be given in plain (?) English, as set of method name,
return type, parameter type(s) and parameter ordering , and a textual
description of the effects and side effects of the method (at least that's how
it works in functional languages; some of this may be different in object
oriented languages).

Example:

Method 'print', returns integer (0 for success, -1 for error).
Parameters: format of 'stuff to print' (string), actual stuff to print (number
of parameters and types as described by format).

Effect: stuff to print is sent to the big bit bucket in the sky, formatted
exactly as requested.

Side effects: all variables passed (as 'stuff to print') are destroyed.

Not very useful, maybe, but it is a valid definition of a method 'print' in my
API.

To implement the API, someone at some stage will have to write actual source
code, and compile that into the API library. Sun's source code and library will
differ from Apache's source code and library. Any of this can be copyrighted and
licensed. The question around which this case revolves (as it seems to me) is -
can the API (the set of method definitions) be copyrighted, or is its structure
and arrangement fully dictated by the requirement of compatibility?

To me, at least, that last point is clear: method names, the return types,
parameter types and parameter order for any compliant implementation have to be
the same in order for the implementations to be compatible. Deviating from the
API definition means you're not implementing the same thing. In order to make
use of the API as defined, you have to stick to the definition, to the very
letter. Copyrighting this and still claiming 'everyone is free to use it' seems
pretty dishonest to me. It should not even be possible to copyright the plain
API.

What have I missed? (I'm not actually certain whether the parameter ordering
needs to be matching in Java, or whether parameter naming in addition to typing
is used there. Correct me if I'm wrong.)

So in a way, you are right - APIs are not source code. But they are not ones and
zeroes to be used by the computer either (that would be the API libraries).
Except in the very narrow sense that, in order to store or transmit the API, I
will have to turn them into the ones and zeroes of an e-mail, or HTTP post, or
something. APIs are recipes for writing source code (both that of the API
libraries, and that part of your application making use of the APIs).

Which meaning of API are Oracle and Google talking about?

-- mschmitz


[ Reply to This | # ]

Day 4, Thursday, Oracle v. Google ~ pj
Authored by: Anonymous on Thursday, April 19 2012 @ 11:57 PM EDT
"And what I learned is that APIs are not source code. They
are ones and zeroes for the computer to use. Correct me if
I'm wrong, but how can you copyright ones and zeroes?"

The way that the witness had phrased the answer was really
misleading (per the transcript that is done live and not
tape).

Any program can have an API. If you were to write a web
forum in Java, you could have an API that others can use to
interact with your forum.

An API is a function (or functions) with the main purpose of
allowing other programmers or programs to interact with
whatever the API was written for. So in the we forum
analogy, lets say you wanted to allow people to post from
another website to your forum. Instead of making them go to
your forum, the other websites developer would collect the
post from the end user and post it to your forum
automatically using the API.

Most programs in Java are written in source, which means
that they are not compiled into byte code (what the computer
actually deals with) but in human readable code. The java
language interprets the human readable and compiles into
into byte code at run time.

What the witness is saying is that the API's are pre-
compiled into byte code and shipped with Java in a non human
readable format.

The reason for this is byte code does not have to be
compiled on the fly and thus it is quicker to execute.

So saying that API's (in general) are not source code is
incorrect. They are source code at some point in time,
however once they are shipped they are already compiled and
in non human readable format.

[ Reply to This | # ]

Is the jury up to the task and what is a 'matter of law'?
Authored by: Anonymous on Friday, April 20 2012 @ 12:56 AM EDT
Yes. Humans are bad at managing long lists of uncorrelated information.

The problem, as i see it, is that it's the subtleties of this case can easily be lost on the jury as Oracle continues to uses terms inconsistently to describe what was stolen from them. Unless the jury is up to the task and makes appropriate connections, for example to the statement above, then the many many statements by Oracle that their designs (API specifications) are copyrighted by Oracle could win ground.

It's unfortunate that the court considers Oracles view that API's are copyrighted a 'fact' to be resolved by a jury. At what point is someones view of 'a fact' considered by the court to be so skewed from reality that it then becomes 'a matter of law' to be resolve by a judge?

[ Reply to This | # ]

Reinhold is wrong, Bloch is correct
Authored by: bugstomper on Friday, April 20 2012 @ 01:41 AM EDT
PJ, that thing you were led to understand by Reinhold's statement about
"API libraries" being binary is wrong, because there is no such thing
as an "API library". Either Reinhold was wrong or it was
mis-transcribed by the reporter.

The binary files that are installed on any platform that runs Java programs are
called the Java Class libraries, not API libraries.

Joshua Bloch had the more accurate description of what APIs are. Reinhold was
either lying (I assume he does know about APIs and is not just ignorant) or more
likely was saying things that are precisely truthful but phrased in a way to
mislead the non-expert into thinking that he was saying something else, mostly
by conflating the API with the class libraries themselves.

I really like how Bloch is not simply accepting much of the obfuscating
terminology that has been thrown around such as calling the 37 packages 37
APIs.

I do wish he had had the presence of mind to give a clearer answer to Judge
Alsup's direct question about that. Something like

A library is a collection of software that performs some useful functions and
can be installed on a computer where it is available to be called by application
programs on that computer. Java has several libraries, such as the Java Standard
Library which contains the most generally useful functions that are required by
most applications, the Cryptographic library which contains functions used for
encryption and so on, and others. Each library is organized into packages,
classes, and methods. The API for a library describes how to use it, including
which packages, classes, and methods it contains. If you are talking about
different libraries you might want to talk about different APIs describing how
to use them. The 37 packages are not in 37 different libraries. Many of the 37
packages are sub-packages of another package in the list, clearly belonging to
the same library. And if they are all lumped together in the same runtime
environment you might even call them one library, and therefore one API. There
is no hard and fast way to enumerate them as a certain number of APIs.

[I just though of a monkeywrench to throw into the discussion of "what is
an API?" How would one explain a phrase like "the Collections
API" which does not refer to a single library or even package, but is an
API to use to make use of any class that implements the Collections interface?]


[ Reply to This | # ]

grrrr...
Authored by: Anonymous on Friday, April 20 2012 @ 02:03 AM EDT
If these guys would learn a little bit about the law they could explain these
things better!

API:packages,classes,methods::LAW:laws,common law,precedence

[ Reply to This | # ]

My take on 'What is an API'
Authored by: calris74 on Friday, April 20 2012 @ 02:26 AM EDT
To talk about an 'API' as a tangible thing is completely nonsensical - You need to either talk about the:
  • The Specification - i.e. The documentation
  • The Implementation - i.e. The code
  • The Library - i.e. The compiled implementation stored in a file on disk
  • The Instance - i.e. A copy of the library (in part or in full) in memory
  • The Interface - i.e. The interaction between the programmers compiled code and the instance of the implementation of the API definition

Remember, the I is 'Interface' - A program 'calls' or 'invokes' the API. But there are many ways an interface can be invoked....

Lets so I have an API definition of:
int sum(int a, int b);

That in itself is not enough to actually use the API. Behind the API is what is usually called the ABI (Application Binary Interface). This is usually hidden by the compiler and specifies whether the parameters are passed on the stack (and if the caller or callee removes them from the stack when the function return) or in registers, what registers must be preserved etc.

Digging deeper, how does the users application interact with a library - You start to enter the world of dynamic loading and linking which gets into the Operating System and System Libraries.
That leads you to how the library file which stores the implementation of the functions listed in the API Definition. What is there file-format, where are they located on disk, how are they indexed, accessed etc.

So Google's implementation of java.lang.math.sum is an exact match for the API Definition but under the hood they are probably completely different. And not just in terms of lines of Java code, but also in the way the application interacts with the library files itself (and this is all controlled by Dalvik)

So even if you independently implement 'The Specification' and somehow 'The Specification' is copyrightable (which I doubt) then it could be argued that such copying in itself is de-minimis

Microsoft has already fought and lost the 'Independent implementation of a specification' battle one copyright grounds, but won it on patent grounds (the FAT patent is one case in point)

I cannot see how the 'API' question can be anything but a point of law...

[ Reply to This | # ]

The big download...
Authored by: mtew on Friday, April 20 2012 @ 02:33 AM EDT
This could be a problem.

Consider what would happen if Oracle downloaded the entire source archive, or an
archive copy of one of the older versions of Android that contains the now
removed files.

They could argue that the disputed files have not been removed at all. Since
this is legal issue, they might have a legal point.

Of course one of the HUGE points about Open Source is that you can examine the
history of the code.

I think they are likely to argue that the disputed code has not been removed and
that Google has to pay for keeping copies of it.

Of course this will reek havoc on keeping accurate and transparent records of
the codes development, BUT THAT IS PRECISELY WHAT THEY WANT TO DO!

---
MTEW

[ Reply to This | # ]

An API is...
Authored by: Anonymous on Friday, April 20 2012 @ 03:23 AM EDT
This is my understanding ( for the last 20 years ) of an
API.

A library is a collection of classes/functions that serve a
common purpose to reduce a programmers work, by not
requiring him to implement from scratch features not central
to his program.

For example, a cryptography library allows a programmer to
use cryptography in his code without implementing
cryptographic functions from scratch. A person whose
application needs to communicate with the internet, uses a
networking library instead of hand coding network
communications.

An API is exactly what it says it is. It is an interface to
a library that application programmers use. It is a
description of the protocol one needs to follow when
utilizing a library.

[ Reply to This | # ]

  • An API is... - Authored by: Anonymous on Friday, April 20 2012 @ 08:21 PM EDT
  • An API is... - Authored by: Anonymous on Friday, April 20 2012 @ 10:56 PM EDT
API not a concrete thing, it doesn't have a level
Authored by: BitOBear on Friday, April 20 2012 @ 04:05 AM EDT
Where the judge asks if the API is at class level or the package level he is
making an ontological mistake. He is addressing it as if it is a concrete and
distinct thing (like a chair) when it is a metaphysical thing (like "the
proper use of a chair").

So go back and read my stuff about forgetting the first two words Application
and Program, and then ponder the word Interface.

ohm....

Okay, so say I sell a device like a carburetor for a car, and there are a bunch
of screws on it to tune the mixture and limit the accelerator. There is also a
surface where the carburetor bolts down onto the intake manifold. There is also
a place where the air cleaner housing bolts down on the carburetor. There is the
place where the gas line hooks on and the place where the accelerator cable is
attached. All this constitutes the "physical features" of the
interface.

But a skilled mechanic knows that when the carburetor is mounted it will need
gaskets and will likely want to apply at least so much torque and no more than
so much more torque. He'll also know that if the thing is brand new he almost
certainly doesn't want to mess with the mixture screws since they were factory
set. He'll know that the accelerator line needs to pivot freely at the point of
attachment to the arm so he wont over tighten that or he'll use a special dingus
of some sort.

Now the driver may not know from the carburetor even though they use it every
time they move their foot more or less on or off the accelerator.

Now a "gear head" owner may want to go in and tweak the mixture.

So what is the interface?

It's the physical thing's points of interaction with other things but it is
-also- the information about how that interaction will effect the thing, and how
the thing will effect other stuff (like engine intake pressure and engine speed
if you "punch it").

So there are things and there are rules.

Any single API is "one set" of thing and rules that "make
sense" when you lump them together.

If I have two ponds, and I drain one, do I still have two ponds or do I have one
pond and a ditch? Does it matter if the water from was drained into the pond
that still has water.

It's hard to define an API as a thing because it is typically a set of things
that are themselves examples of the thing you are trying to define.

Example: The java.net package is (hopefully) a rational set of things that make
sense together and represents a large API. It encompases a number of smaller API
such as those dealing with "sockets" and those dealing with
"addresses". And of the socket API it has the API for
"server" sockets in a connection, "client" sockets in a
connection, and "peer" sockets in a connectionless transmission (UDP
etc) communication setup. These socket APIs often use or relate to the address
API, which is why its part of a larger API.

Part of the reason the expert was agog is that the lawyers are asking questions
that are kind of metaphysical. The lawyers drew distinctions with a fine line
where the expert knows there is an expanse of shadow and gray.

Now, the API files are discrete for being files, not for the interface part.
Each file is discrete but there is no telling how much of which files constitute
the interface.

In C on linux, for example, if I look up the "connect" verb ("man
connect") from the network API, I am told that I will need to include the
files "sys/types.h" and "sys/socket.h" to be able to use
"connect". If I want to read data from that socket using
"read" I will need the file "unistd.h". This documentation
of these two simple corner of this API don't tell me what all the compiler will
need to do, just what I need to do to get the compiler to do what it needs to
do.

hua?

Well those files tell the computer how to find and understand the tidbits, but I
am the one who knows that after I "connect" the socket I will want to
"read" it. The compiler is the one who has been told what makes sense
at one level.

Thin is, I could take the value returned by connect and misuse it (say take its
cosine, or use it as a denominator in some math).

Classes are a feature of an advanced language (like C++ or Java) to help keep
things in useful piles and to help discourage misuse. The C network interface
returns an integer, the java.net interface likely returns an instance object of
a ServerSocket class type or something. When the java machine talks to the
operating system it has to pluck that integer out of the bigger class instance
and call read with it (or whatever) but now the Java Programmer can't make the
cosine misuse.

Additionally a formal API may define that there "shall be" a class
called "ServerSocket" and said class "shall contain" some
particular members. If you go look at that class you may discover that it
contains far more than the formal API defined. You probably don't want to touch
those other things. They are there, you can use them, but they are not part of
the "formal API". There presence makes them part of the "defacto
API".

Lots of people use the defacto API to things to make magic happen. But you
better be a wizard to do it or you may end up with a dead assistant.

Some famous judge said "I cannot define obscenity, but I know it when I see
it." If I were a lawyer I could tell you which one it was.

Well as a professional in the art, I cannot define "an API" or tell
you whether "an API" is at the class or function call level (its at
bother and neither) to a degree that would have a legal meaning, but I can tell
you if the files you give me constitute "at least one" and whether it
"sucks." 8-)

Only the compiler for the language can tell you if the API files are sufficient
to let the compiler make sense of the code. This is why compilers have error
messages about missing files and undefined terms and symbols.

Only the library knows what will happen if you call a given function in that
library with a given piece of data. This is why we have runtime errors.

From the other angle, an API is whatever the API writer says one is. The entire
Lisp language API (e.g. talking to the language not the operating system running
it) consists of a single function call named "eval" that takes a
string. This has been true for decades and whole volumes and bookshelves of
documentation and guides have been created to tell you what to put in that
string argument to get different things to happen.

No I am not joking, and this is not hyperbole.

Look up the game "go" and then ask the question "what is a go
strategy".

Really. No concrete, universal, legally testable definition of API is possible.

[ Reply to This | # ]

Are APIs really "nothing but long lists of uncorrelated information"?
Authored by: Anonymous on Friday, April 20 2012 @ 05:08 AM EDT
The lead article makes this claim, but I don't understand it, maybe
someone could explain. It also seems to take Reinhold's remarks out of
context. At the time, he is describing the efforts taken to make the API
understandable for its users. The organisation of classes and methods is
anything but uncorrelated or random. I think he was just trying to say, yes
an API can get so big and unwieldy that its useless.

Also, the article goes on to imply that a list of uncorrelated information is
not copyrightable? Surely a list is copyrightable?

I hope there is some other argument against the Oracle position. For
example, wasn't there some argument against the claim that definitions in
C header files couldn't be subject to copyright?



[ Reply to This | # ]

Oh! I'm such a twit. How could I be so stupid!
Authored by: Ian Al on Friday, April 20 2012 @ 05:40 AM EDT
You guys tell me stuff and give me stuff to read and I might as well line my parrot's cage with it (lovely plumage, the Norwegian Blue).

I'm not going to show you the spectacular creative expression in the nine lines of rangeCheck again after your previous hysterical laughter. I will, however, repeat bugstomper's comment,
Note that the three if tests and their throw statements follow the order they are described in the specifications.
In other words (if I have this right) there are three 'if' statements which check for range errors and, if one is found, the relevant call is made to the 'throw' API to return the type of error to the program.

Let me show you the implementation code from the Google slide for the max() API function to decide which is the biggest number. Please forgive the indentation which I could not quite master:
public static float max(float a, float b)
{
    // this check for NaN, from JLS 15.21.1, saves a method call
      if(a != a)
        return a;

    // no need to check if b is NaN; > will work correctly
    // recall that -0.0 == 0.0, but [+-]0.0 - [+-] 0.0 behaves special
    if (a == 0 && b == 0)
    return a -- b;
    return (a > b) ? a:b;
    }
This is the max() implementation code from GNU Classpath 0.9.8 and not the one from OpenJDK which is shown on the following slide. I suppose GNU were another member of the JCP just like Harmony.

As you read it, you might just miss the point that you are reading it. You can see math going on and the appropriate result being returned to the program calling the max() function API.

The rangeCheck code calls the function 'throw' in another API. We can read it and understand what it is doing because it is written in Java source code and uses the Java API Specification. Now, its no use to man nor beast in source code form. It needs to be compiled in order to be executable. If you are a Harmony or an Android user you are told to download the Oracle JDK complete with the Sun API implementation code and use the compiler that comes with it. That, of course, comes with a full licence to any patents or copyrights necessary to program in the Java language for the Java Runtime Environment.

If the API implementation code is written in Java source code and compiled with the Sun compiler, then the resulting code is Java byte code that only runs on the JRE. Supposing you want more API libraries for use in your programs. Are you permitted to devise additional classes and write the implementation code for the class libraries? Of course you are! In fact, someone reported that the javac series of APIs were not originally in the Java API Specification but were adopted by programmers so quickly that they were hastily cobbled in. Don't forget, you can write any APIs you like using all the Sun Java patents and copyrights. You are fully licensed.

So, Google were just fine in using just the 37 Sun API packages they needed for Dalvik and adding more APIs for their own programs. The problem is that Java is not free speech. Sun made it impossible with the API implementation to bar the APIs that would break a programmer's program. Google had to use the Harmony implementation code and add the remaining Dalvik APIs or else give programmers a list of thousands of classes from the downloaded JDK that they must not use if they are programming for Dalvik.

The additional Dalvik APIs are just fine because the JDK is written to support additional APIs written in Java. Google had to separate the authorised Harmony APIs needed for Dalvik away from the Sun API set, because Java is the language in the iron mask.

Pulling out just the Harmony APIs that were compatible with Android was the only sensible way of stopping Java programmers programming for Android apps using the Sun APIs which were incompatible with Dalvik.

It's not a problem, though, because Google ask Android programmers to download and use the Sun JDK and with that comes a full licence to use all the Java copyrights and all the Java patents. Sun said how happy they were that the Harmony project (part of the JCP) had implemented the APIs and they proposed to Google that they partnered with Sun and used the Harmony code free of charge to write and compile app programs to run on their Android devices. They would also be able to use all the other stuff created by the community and donated to Sun. It's a shame about the possible fragmentation, Sun said in their proposal, but we're cool with that.

So, what are we here for, again?

---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

Why Java?
Authored by: arnotsmith on Friday, April 20 2012 @ 05:51 AM EDT
Given all these problems, why is Java used?

There are other languages around; Python was mentioned, for example. Are there
similar licensing difficulties, or are they simply less comprehensive?

I ask as a Fortran IV expert - I know very little about current languages.

[ Reply to This | # ]

  • Why Java? - Authored by: mcinsand on Friday, April 20 2012 @ 08:50 AM EDT
  • Why Java? - Authored by: Anonymous on Friday, April 20 2012 @ 10:00 AM EDT
  • Why Java? - Authored by: TheOldBear on Friday, April 20 2012 @ 10:24 AM EDT
Someone please tell the judge what API stands for
Authored by: Anonymous on Friday, April 20 2012 @ 06:07 AM EDT
API - Application Programming Interface

It is a dictionary of terms that allows pieces of code to have a common syntax
in order to communicate.

Place it in the context of latin in how a well written API will follow rules of
structure and the judge will be able to understand it.





[ Reply to This | # ]

What exactly is an API?
Authored by: Anonymous on Friday, April 20 2012 @ 07:04 AM EDT
What exactly IS an API? And what about it are Oracle trying to claim as copyrightable?

A. ...Sun had 500 programmers at one point working on Java, many were working on APIs.
[Emphasis added] What exactly were these programmers doing with the APIs? Were they writing the function stubs, eg using open(2) from *nix
int open(const char *pathname, int flags, mode_t mode)
{
}
and then someone else, NOT working on the API filled in the code of the function between the braces based on what the function has to do; or were they actually employed in filling in the code, ie they were employed in implementing the API and their creative work in this aspect is subject to copyright?

With OO, it is slightly different. The object has defined methods (aka functions) which do stuff to the data held in the object - the point being that the data is abstracted away from the programmer to keep it "safe". The object is a wrapper for the data that tells you what you can do with the data contained within.

So to believe that many hours of work go into designing the wrapper of an object is quite believeable, and each object will have a set of methods which provide the interface for the program to use the object - which would, I presume be the API for the object; and I would guess that some of the programmers were working on what methods the object would need (as in "How do we wrap up this data"?).

So the question of copyrightability of APIs comes down to what exactly of this is copyrightable?

  • Clearly the code implementing the object and its methods ought to be.
  • What about the object itself?
Without the specification of what methods are available and how to use them the object is useless.

Are oracle trying to assert that copyright extends to the wrapper containing the data? But is that wrapper merely an "idea"?

Amazon's one-click idea (sic) was patented, but not copyrighted even though copyright has a much, much, much longer period of protection! The One-click is a wrapper for everything that happens when you use that method of its object (the button). Perhaps Amazon are watching to see if they can also claim copyright on it...I won't hold my breath.

[ Reply to This | # ]

Explanation of Language vs API..
Authored by: ghost on Friday, April 20 2012 @ 07:39 AM EDT
A language, is a set of rules, intended to provide a specific way of writing,
expressing and understanding things, to provide a uniform common platform, that
can interpret and translate the word into a specific meaning, that can be
actioned, and the language itself, defines a certain set of
"primitives", or "core keywords" on top of which everything
else is written and built. No exception.

However complex the code is, it always boils down to these core keywords.

For ANSI C, there are 32 keywords, or fixed words, which is used to build and
define everything else. This list of words is:

auto
break
case
char
const
continue
default
do
double
else
enum
extern
float
for
goto
if
int
long
register
return
short
signed
sizeof
static
struct
switch
typedef
union
unsigned
void
volatile
while


Take this example (c):

int a[100] ;
for ( i = 0 ; i < 100 ; i++)
a[i] = argument ;

What this does, is to define an array of 100 memory locations where we can stick
data (numbers), and then goes though each and one of them, sticking the value
of "argument" into that memory location.

In order to make this more practical, we encapsulate this in a "functional
name", making it a function, that performs a specific something, and that
can be called easily and repeatedly.

void AssignValue(int argument)
{
int a[100] ;
for ( i = 0 ; i < 100 ; i++)
a[i] = argument ;
return ;
}

What we have done here, is to extend the language of "c", with another
word "AssignValue", which is constructed out of the keywords defined
in C itself, and it takes one argument, which is a numerical value, that will be
written into each memory cell.

If we want to assign 10 to each memory cell, we could now simply say:
AssignValue(10) ;

A class, is made up of a group of functions that performs action on something
that is related, for example mathematical calculations, database operations,
graphical operations etc, and you would give this a name, say
"database", "math", "graphics" and so on.

Assume that we created a class around the common mathematical operations named
"math".
In this class, you would stick the functions for each of the
"primitive" mathematical functions, such as plus, minus, multiply,
divide, sine, cosine, pi and so on, and instead of having individual names for
each of these, we group them by the name "math", and refer to them as
"math.add(1,2)", "pi = math.pi()" and so on.

The language is the ground and foundation of everything, the classes, is built
upon the language, and all the classes that supports the language can be grouped
into API's, or a set of functional groups.

Going back to the code example above, this can, once the language is defined,
and we have strict and precice rules for how to interpret it, be converted from
the text form, by breaking down the specific meaning of the into numerical
machine instructions (machine code)

Lets take a stab at it, converting it to mnmonics (which is the individual
machine code instruction numbers (binary numbers) expressed as words, with one
line being equivalent of a single machine instruction - i am using
pseudo-mnemonics to easily follow things)


void AssignValue(int argument)
{
int a[100] ;
for ( i = 0 ; i < 100 ; i++)
a[i] = argument ;
return ;
}

AssignValue: # This is the starting address of this function.
ld acc,r4 # Load the argument (register 4) into accumulator.
ld r1,&array # Load register 1 with the location of the array.
ld r2,0 # Load 0 into register 2 (our loop counter)
repeat: # Jump label - we go back here for each iteration.
ld [r1],r4 # Load memory address r1 with contents of r4.
inc r1 # Add 1 to r1 (array index location)
inc r2 # Add 1 to the loop counter.
cmp r2,100 # Compare R2 against 100.
jrz repeat # If the comparison is not true (r2 not equal to 100)
return # Ok, r2 is 100, return.


We have now converted this into machine code, that can be either java bytecode,
or i86 machine code, or any other, depending on what we wanted.

Thinking of the whole concept of languages, api's and functions in another way:

Imagine the earth under a city, with all its roads, town districts, buildings
and everything else in it, being the language.
Earth is earth, regardless of what you decide to call the town or city, and thus
we have the language "earth".

The API (the town or the city), is what is within the defined city or town
border, so, we could have one API called "London", and another one
called "New York". They are both built on the same earth, but both,
while similar in function size, are vastly different in design and layout, yet,
both are called cities (API's).

One API may contain similar or identical names as another one, doing the same
thing, but they are still not the same API (city).

The classes within each api (city), could be compared to city districts that
shares common traits, but may still be very different from another district.

Consider this:

FoodOnPlate = London.CanaryWharf.Subway( "sandwich" ) ;
FoodOnPlate = NewYork.WallStreet.Subway( "sandwich" ) ;

Both describes similar api's, albeit the naming is different, apart from the
last thing, which orders a "sandwich" from the "subway"
outlet.

London and NewYork being the API's name, CanaryWharf and Wallstreet being the
class names, and "Subway" being the functional name - the one piece of
code that does the work - delivering a sandwich (as requested)

A language defines how you write things.
A function, is a single tool, like a wrench.
It does one specific thing.
A class, is a group of tools, similar in function or use.
A fixed spanner, adjustable spanner, monkey wrench ...
They are stuck in the same group, as they do similar things,
while still having different individual properties.

An API, is the collection of everything above, aka "the toolbox", and
each API, just like a toolbox, may not be the same as another.
A mechanic's toolbox (API) is not made up the same way as a plumbers or a
carpenters, even though some of the tools in each toolbox is exactly the same
for each trade.

You design the API around what it is to be used for, but in the end, it all
boils down to the very same thing - what the tools are made of - the language.
The "iron" and "wood" that the tools are made of.

After all, there's no wonder there are overlaps, or that code can be similar or
even identical in their implementation, as there are cases where there is only
one way of doing certain things.

For a fixed spanner, there's only limited ways of making it, if it is to be
functional (turn the nut), and it would be silly to be able to claim copyright
on the tool's functional design itself, or even part of it (the head of the
spanner, for example, or the arm of the same), as there is only one functional
way you can get something around the nut, if it's an open spanner.


[ Reply to This | # ]

Q. Does that specification have copyright notices?
Authored by: Ian Al on Friday, April 20 2012 @ 09:19 AM EDT
...

A. No, it's in the Java platform API specification.

Q. Does that specification have copyright notices?

A. Yes.

Q. Was it Sun's practice to register copyrights?

A. Yes.

It was Sun's practice to register the entire Java distribution as a compilation
copyright registration. It was never their practice in all the years of Java
development to register the copyrights on the Java API Specification.

Also, ask yourself where the copyright notices in the Java API Specification
are. Each chunk of implementation code will have a copyright marking, but it is
not possible to mark the alphabetical list of the compilation of the
compilations of individual APIs that is the Java API Specification.

I think my question on cross would have been 'show me'.

---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

Easy solution to speed this up
Authored by: Anonymous on Friday, April 20 2012 @ 09:32 AM EDT

I have an easy suggestion to speed this up. Oracle likes to keep pushing the $7.4 Billion dollar figure. And they seem to really want to pound on the 9 lines. So, let's do some basic math:

    $7.4 Billion * (9 lines of allegedly infringed / 15 million lines in Android) = $4,440
So how about Google pay Oracle $4,440 and we call it a day?

Nah... I didn't think Oracle would go for that. Of course, they don't want to have to prove how 9 lines out of 15 Million doesn't fall into de minimus concept of Copyright Law either. Sure must be tough to want to claim billions and not have to actually prove your case.

RAS

[ Reply to This | # ]

Some comment on the 9 lines
Authored by: celtic_hackr on Friday, April 20 2012 @ 10:09 AM EDT
Even hearing 9 lines of copying again and again, it doesn't properly put this in
perspective. So here's my attempt to do that.

1) Most computer software lines contain three words,two "nouns" and a
"verb" (eg "x = y" [and sometimes an end of
"sentence" marker like ";"]) . Some lines only contain
"one" of each (eg "writeln([noun])"). Some lines contain
more maybe 4 or 5 or even up to 12. Poorly written code, or highly complex
logic, may fill up more than one 80 character line.

2) Let's assume Java is well written code, because they are awful proud of it.
So on average a line is say 4 words long.

3) This is 36 words of code from over 60,000,000 words, or less than 1 word per
1,500,000 words 1:1,500,000 or less than 0.000067% of Android code. Yes, less
than zero point zero zero zero zero six seven percent.

4) An advanced college level computer science class program might contain 5000
words. So, Oracle's claim is in effect saying if you include just 1 word used in
Java in a 5000 word college class program you are infringing Java.

5) My mind can't help but replay in my head that dumb PS-commercial from the 80s
or 90s. "This is your brain on drugs."

If I were Google, probably my first defense would be to pop up a chart showing
this is all it's ridiculousness, with two stacks of unprinted paper and a copy
of "War and Peace". Then I'd take a printed source code page, tear of
9 lines and lay it on top of the "Android" stack.

That would be my opening defense. I would then continue to eviscerate them on
the rest of their silly copyright suit.
If I were Google's lawyers, but they have better lawyers than my dream of being
one. So, I can't wait to see what entertaining demonstration they bring.

P.S. - PLEASE don't post those 9 lines of code, I don't want to know if any of
my non-Java code infringes. I've easily written 15,000,000 lines of code, and
frequently write code in the ten to hundreds of thousands of lines of code. I'm
sure I've got at least a few lines of the form "x = y;", "x =
f(y);", "if x" + "{ f(y) };", and "f(x);".
So, I've probably got at least five infringing lines of code in almost every
program I've ever written over the past 30 odd years of programming. Hmmm...
maybe some of their code is infringing MY copyrights.

[ Reply to This | # ]

API's and copyrights
Authored by: Anonymous on Friday, April 20 2012 @ 10:16 AM EDT
I agree that the design of an API, taken as a whole, is creative enough that it
should be subject to copyright. On the other hand, I also believe that
Oracle/Sun have publicly said "Java is Open" enough times, and
solicited community involvement in the use and development of "Open"
Java, that they cannot claim proprietary rights to Java and the Java API's.

[ Reply to This | # ]

Reinhold: APIs can change like wildfire.
Authored by: mexaly on Friday, April 20 2012 @ 10:38 AM EDT
This caught my eye; if the API is not fixed, then it's not fixed in a medium.

I felt this got at the concept of an "interface," perhaps in a way
that relates to copyright law, but it went on by without hooking on anything.

---
IANAL, but I watch actors play lawyers on high-definition television.
Thanks to our hosts and the legal experts that make Groklaw great.

[ Reply to This | # ]

What is an API?
Authored by: swmcd on Friday, April 20 2012 @ 01:55 PM EDT
Judge: So what is an API? Is it a package, or a class, or what?
Ohhh...man. 18 months into this thing and there is not a common understanding of the matter before the court. I don't even want to think about the jury's understanding of this...

[ Reply to This | # ]

  • What is an API? - Authored by: Anonymous on Friday, April 20 2012 @ 04:13 PM EDT
  • What is an API? - Authored by: Anonymous on Monday, April 23 2012 @ 06:33 AM EDT
Info week article
Authored by: jvillain on Friday, April 20 2012 @ 02:31 PM EDT
Information Week has a recap up.

Lin k

On page two we get the following.

At the conclusion of the testimony, the judge said he wanted the two sides to clarify their positions on whether APIs can be patented. He also asked whether the copyright office investigated the structure, sequence, and organization of software submitted for copyright. He said he didn't think the Copyright Office did that and Baber confirmed his assumption. Finally, he asked for arguments about the standards for derivative works.
Why is the judge asking if an API can be patented? To my knowledge that question hadn't been raised by any one. Then again maybe it is a typo and he meant copyright.

The question around the copy right office is interesting. Maybe he is hoping they did some heavy lifting which would save him some work. Then again maybe he is suspicious of Oracles claims that the API can be copyrighted. He has probably seen enough of the good work that the USPTO does that he is also suspicious of the copyright office as well. To the best of my knowledge the copyright office isn't much more than an automated rubber stamp. Some one else may know more of how they work.

[ Reply to This | # ]

  • Because Oracle said ... - Authored by: Anonymous on Friday, April 20 2012 @ 03:34 PM EDT
  • typo? - Authored by: Anonymous on Friday, April 20 2012 @ 04:22 PM EDT
A simplistic answer for "What is an API?"
Authored by: Anonymous on Friday, April 20 2012 @ 02:44 PM EDT
I would use something like this for an analogy about API's
and the language.

Look at the language as a house, with a door. In order to
use the language (get into the house) you have to go through
the door. The API is like the specific lock and key that
opens the door. You have to use a key that is matched
exactly to the tumblers in the lock, or the door won't open.

So, in terms of Java (or any language), if you don't use the
exact syntax that the API requires, then it won't execute
the method, class, or package that you're trying (or won't
execute it in the way that you want).

In the end, it's all about interfacing and implementation.
The API is just the way that you get into the internal
workings of the package, class, method, or object--without
having to know the internal workings or re-write them in
your program.

The only problem that I see with this analogy is that you
can patent locks. At least the internal workings of the
lock. Which might make the jury think that you can/should be
able to patent an API (or copyright it). It needs to be
pointed out that while you can patent the internal workings
of a lock, you can't patent the idea of using a key to
unlock it, or the idea that the key matches the tumblers and
causes them to open.

Have a great day:)
Patrick.

[ Reply to This | # ]

Ten of the 37 APIs ... free of Oracle/Sun's rule (ie. unpaid).
Authored by: Anonymous on Friday, April 20 2012 @ 04:48 PM EDT
This seems strange to me. How could Oracle's lawyers not know better? Did they
not say to the OpenOffice developers who were developing code in this same
manner "Give us your copyrights!" In turn, did not the OpenOffice
developers say, "Not a chance" and put their code to another project
called LibreOffice?

Was this a lame (but failed) attempt by Oracle to try to sue the open source
communities for using code that the open source communities developed in the
first place?

Is this the reason that Oracle sued Google without demanding the copyrights from
the people who actually wrote the APIs? Like maybe their intention was to
obfuscate (while trying to play ignorant at the same time).

I find it very difficult to believe that Oracle (or it's lawyers) did these
things without knowledge of what they were doing... Reminds me a lot of SCO
demanding the copyrights for UNIX from Novel whilst shooting the double-barrel
foot-gun by trying to sue IBM over those same copyrights ("how whack is
that?!?!").

If this total lack of common sense is a side effect to some disease, I sure hope
it isn't contagious! People are dumb enough as it is (just sayin')... And
thank the gods for sites like GrokLaw and folk like PJ! :)

[ Reply to This | # ]

Day 4, Thursday, Oracle v. Google ~ pj - Updated 3Xs
Authored by: Anonymous on Friday, April 20 2012 @ 04:54 PM EDT
So, I am gathering that Google desired a license for Sun Java
CODE, so they went to discussions, and when they fell through,
Google went on it's own path, as they required no license for
anything else.

[ Reply to This | # ]

Long lists of uncorrelated information (you misunderstand the witness)
Authored by: SLi on Friday, April 20 2012 @ 08:26 PM EDT

You are misinterpreting the witness. He is very obviously not saying APIs are long lists of uncorrelated information. And I'm sorry to say that APIs most certainly are not long lists of uncorrelated information.

What he is saying is that if you misdesign an API, it can be very hard to use because then it can be essentially a very long list of uncorrelated information. One of the main points of API design is to bring structure to the chaos, to make it not a very long list of uncorrelated information. For example, to put APIs related to network in one package and APIs related to mathematics in another.

The same witness explains further:

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.

That's what he's referring to when he says "a very long list of uncorrelated information" - having everything in the same package. It's like having a single box in your carage where you store "all kinds of" (i.e. uncorrelated) stuff, from tools to car parts to food to books.

[ Reply to This | # ]

Trying to explain APIs (and the Wikipedia API page)
Authored by: SLi on Friday, April 20 2012 @ 09:22 PM EDT

I think Wikipedia has a fairly good page on APIs.

Understanding the meaning of API is hard enough for beginning programmers (and hard enough to explain for experienced ones), so I can see why it baffles non-programmers. A key thing to notice that API is a somewhat abstract creature, like "the way you drive a car". The car API would specify that a car has a steering wheel and pedals, and the abstract notion of what these do when you operate them. The fact that a car has a steering wheel is part of the API; in a sense, the steering wheel itself, the physical object, is not part of the API, but an implementation of the steering wheel is required for any car that wishes to follow this API. The particular implementation of the steering wheel would be the method signature; it's closely tied to the API, and that's why steering wheels are so similar in different cars. Turning the steering wheel mediates an action; the API is the convention that specifies that you can turn a steering wheel, and that it should effect an action that causes the car to turn.

One thing I'm not entirely comfortable with is using the plural form of "APIs" when we're talking about a single system. In a sense, it's not readily countable; you could just as well talk about "the API of the class libraries", referring to all packages, classes and methods as a single API.

Here are some snippets from the Wikipedia article that I consider helpful, interspersed with my comments:

An application programming interface (API) is a source code-based specification intended to be used as an interface by software components to communicate with each other. An API may include specifications for routines, data structures, object classes, and variables. An API specification can take many forms, including an International Standard such as POSIX or vendor documentation such as the Microsoft Windows API, or the libraries of a programming language, e.g. Standard Template Library in C++ or Java API.

This, the first paragraph of the article, is a fairly good summary in my opinion.

The term API may be used to refer to a complete interface, a single function, or even a set of APIs provided by an organization. Thus, the scope of meaning is usually determined by the context of usage.

Under the section title "Detailed explanation":

An API may describe the ways in which a particular task is performed. In procedural languages like C language the action is usually mediated by a function call. Hence the API usually includes a description of all the functions/routines it provides.

Function is more or less the same thing as a method. By convention, they are called methods on object oriented languages and functions on procedural languages. They are snippets of code that do something when invoked or called (they typically either effect a change or fetch some information for the caller). The simplest functions do some very simple calculations, or change the value of a variable. More complex functions can build on top of simpler functions by calling them.

If a car was a class, one method could be "float get_current_speed()" (that is the signature, not the implementation of the method). Calling it would not affect the car in any way, but it would return to the caller the current speed as a number ("floating point number", essentially a decimal number).

Another method could be "void apply_parking_brake()". It would affect the state of the car, namely apply the parking brake. It does not return any information (signified by the "void").

A taxi driver could build on top of these; the API of a taxi driver could have a method named "void drive_to()", which in turn would use the lower level car APIs to accomplish this task.

These method signatures are really not "the API"; they can be said to be part of the API, which is the idea, or specification, of what you can do to get your car to do things, but the API also encompasses the general idea or expectation of what happens if you turn the steering wheel. You can talk about the "car API", but you could subdivide it to "the brake API" and "the steering API" if you wished. See also the example about the manual page of sqrt() in the Wikipedia page. The API is not only the function signatures in that example, but also "the fact" that it computes a square root (but not how it does it).

Hence the API in this case can be interpreted as the collection of the include files used by the C language and its human readable description provided by the man pages.
But:
Many program development environments provide the documentation associated with an API in some digital format, e.g. perl comes with the tool perldoc:

Note "documentation associated with an API". The documentation is not the API; the method signatures are not the API; the API is something intangible, an idea, but with some very concrete details (the method signatures, for example) that cannot really be modified without breaking the API.

As for object oriented languages:

In object-oriented languages, an API usually includes a description of a set of class definitions, with a set of behaviors associated with those classes. A behavior is the set of rules for how an object, derived from that class, will act in a given circumstance. This abstract concept is associated with the real functionalities exposed, or made available, by the classes that are implemented in terms of class methods (or more generally by all its public components hence all public methods, but also possibly including any internal entity made public, like fields, constants, nested objects, enums...).

The API in this case can be conceived as the totality of all the methods publicly exposed by the classes (usually called the class interface). This means that the API prescribes the methods by which one interacts with/handles the objects derived from the class definitions.

More generally, one can see the API as the collection of all the kinds of objects one can derive from the class definitions, and their associated possible behaviors. Again: the use is mediated by the public methods, but in this interpretation, the methods are seen as a technical detail of how the behavior is implemented.

For instance: a class representing a Stack can simply expose publicly two methods push() (to add a new item to the stack), and pop() (to extract the last item, ideally placed on top of the stack).

In this case the API can be interpreted as the two methods pop() and push(), or, more generally, as the idea that one can use an item of type Stack that implements the behavior of a stack: a pile exposing its top to add/remove elements. The second interpretation appears more appropriate in the spirit of object orientation.

The API of a class that implements the stack data structure is the method signatures along with the understanding that invoking those methods causes the effects you would expect from a stack implementation.

In this sense, in object-oriented languages, the API defines a set of object behaviors, possibly mediated by a set of class methods.

This is a concise piece of wisdom; if you understand this, you understand a lot.

An API is usually related to a software library: the API describes and prescribes the expected behavior while the library is an actual implementation of this set of rules. A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.

[ Reply to This | # ]

Why the API concept is confusing: what an interface is depends on what it is interfacing with
Authored by: clemenstimpler on Friday, April 20 2012 @ 09:59 PM EDT
Oracle can muddle the waters, because an API is an interface. The concept of an
interface is 'relational'. Some interfaces are only for humans, e. g. a GUI
(after all, it's in the name). It should be feasible to put a camera in front of
a monitor, so that it can capture output of the GUI, and to pipe that input into
another computer, so it may execute instructions depending on what is being
displayed on the monitor. This is idiotic, because computers have more efficient
ways to communicate. But it shows, how interfaces are made for particular sorts
of input or output.

The same seems to be true for an API. In fact, or so I guess, there is never
only one of them. The specification is the human readable aspect of the API: It
allows a programmer to grasp what a particular library will do without looking
at code or testing different strategies. It's written, more ore lss, in plain
English or another natural language.

The source code of the library is a different mode of expression of the same
facts. A knowledgeable programmer may get the same information from the code
that is expressed in easily accessible form in the specification, because, after
all, the specification is implemented in code. So the code displays a different
kind of interface, but it is an interface nevertheless - a particular way of
'displaying' expected inputs and outputs.

The binary is an interface for code. It takes quite an amount of work to reverse
engineer it in order to retrieve the information contained in the source code or
the specification. But it is feasible in principle nevertheless.

So there are three ways to 'express' an API: specification, source code, binary
code. The specification is for the unenlightened programmer, the source code is
for the expert, the binary code is for the machine.

So you can either argue that there are three APIs, depending on what the API is
interfacing with (amateur, expert, machine). Or you can say that one and the
same API is 'expressed' in three different ways. If you choose the first
strategy, there are two or three things that can be copyrighted: the
specification, the code, the binary (opinions on the last point differ). Google
does not dispute that. But it copied neither the specifiation nor the code or
the binary.

If you choose the second strategy, there is one thing that can be expressed in
three different ways. When I see a thing that walks like an idea and swims like
an idea and quacks like an ide, I call that thing an idea.

IIRC, Google focused in questioning the witnesses on the 'tangible medium'
aspect of copyright. If you choose the first strategy, there are three 'tangible
media' (a book or a webpage, a source code listing that can be printed out, a
binary that can be burned to a medium). It is more or less uncontested that none
of these were copied by Google. If you choose the second strategy, one and the
same 'thing' could be made available in three different media. Again, if it
walks like and quacks like etc. ....

Oracle's copyright case is a dead duck.

[ Reply to This | # ]

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 )