
Oracle v. Google judge to decide whether APIs are Copyrightable, not the jury - vgnet
http://www.groklaw.net/article.php?story=20120421131810380
======
ajross
I'm not sure it's actually supposed to be surprising that the Judge came down
on this side. The whole point of the Judge/Jury separation is that one gets to
decide matters of law and the other matters of fact. Clearly whether or not
the doctrine of copyright extends to the expression of an API is not a fact
being contested here.

The more amusing bit is that the incriminating code snipped in Oracle's slides
goes the other way: the code is in Java because Josh Bloch (the Google
employee who checked it into Android) _wrote it in the first place and gave it
to Sun_. So the same TimSort implementation got carried with him into Android.
There may still be a copyright question if he actually assigned ownership to
Sun, I guess. But suing the author over the use of open source code he gave
you in another open source project is... yeah.

~~~
jdq
_"...Josh Bloch (the Google employee who checked it into Android) wrote it in
the first place and gave it to Sun."_

What does that mean exactly--'gave it to Sun'? He was a Sun employee at the
time. It's silly to say the Java code he wrote while working at Sun was given
to Sun by him. Likewise, it's silly to say that then by extension when he went
to work for Google he just took his code with him and gave it to Android.

~~~
simoncion
From the fine article, it seems that the code in question is timsort, which
Bloch wrote _after_ he left Sun. He gave the code to Sun by pushing it into
the OpenJDK.

~~~
jdq
The code in question is most certainly not TimSort, but the rangecheck()
method within it, which is copied verbatim from arrays.java, which Bloch wrote
_while_ at Sun. It's what Oracle is using to show that Bloch did reference Sun
code and Android is not a clean-room implementation. It's there in the Groklaw
piece, but glanced over very quickly because, well it's groklaw.

 _"Q. Why did you use the same rangecheck() function in Timsort as was in
arrays.java?

A. It's good software engineering to reuse an existing function.

Q. But why use the exact same code?

A. I copied rangecheck() as a temporary measure, assuming this would be merged
into arrays.java and my version of rangecheck() would go away.

[Discussion of Timsort dates and Android work dates.]"_

~~~
nknight

        private void RangeCheck(int index) {
        if (index >= size)
            throw new IndexOutOfBoundsException(
            "Index: "+index+", Size: "+size);
        }
    

If this were the basis of Oracle's copyright claim, any judge in the country
would have tossed the case on summary judgement.

~~~
tryke
It doesn't even check for underflow!

~~~
SeanLuke
To do so would be meaningless, since arrays already do that.

Fun fact: Java's ArrayList RangeCheck function has had a brutally stupid
misfeature for over a decade (yes, I had posted it as a bug -- ignored) which
prevented its add(), set(), and get() methods from being inlined. I kid you
not.

To wit: these methods all call RangeCheck, which potentially throws an
exception, along these lines (here's get(i) in pseudocode):

    
    
        RangeCheck(i)
            if (i >= maxLength) throw exception about i
    
        get(i)
           RangeCheck(i)
           return array[i]
    

Until recently methods which threw exceptions could not be inlined. Thus even
if get(i) was inlined, you'd still have to call an uninlinable RangeCheck(i)
call every time.

This was trivially fixable:

    
    
        ThrowException(i)
            throw exception about i
    
        get(i)
           if (i >= maxLength) ThrowException(i)
           return array[i]
    

This has never been fixed. Recent improvements in HotSpot have rendered it
moot though, as HotSpot can now inline the RangeCheck call. But for almost a
decade ArrayList has been approximately 1/4 the speed it should have been for
most common calls.

------
haberman
As someone who obsesses over API design, it is interesting for me to reflect
on why I don't consider APIs copyrightable, even though I have spent so much
effort and creativity designing them.

The issue makes the most sense to me when I think of APIs as communications
protocols. Indeed APIs for remote services literally _are_ communications
protocols. But even for the in-process case an API is the means by which two
decoupled pieces of code communicate.

In this sense, APIs aren't that different from languages themselves. If you
get really abstract, you could think of LISP as nothing but S-expression
syntax and everything else (including define, lambda, etc) as an API.

Languages themselves aren't copyrightable, even thought things you can say
_in_ a language are. Languages like Lojban certainly had a lot of creative
design go into them, but that alone doesn't make them copyrightable.

So even though I think you can make a pretty convincing philosophical argument
for why APIs shouldn't be copyrightable, the critical deciding factor to me in
is a practical one. Allowing APIs to be copyrightable would be a huge and
unwarranted advantage to incumbents at the expense of innovation and
disruptive technology. Users of any API would be locked in to one particular
provider of that API.

The ability to swap out one component for another is a fundamental tool for
software engineers, and it's a fantastically pro-competitive check that keeps
people honest. If your API provider BigCo raises their prices and no one else
is allowed to compete with them because their API is copyrighted, how is that
good for anyone except BigCo? In particular, someone else may have developed a
superior way of implementing the API; allowing them to do so could help move
the entire industry forward. Protecting BigCo from this disruption gives them
no incentive to move their own tech forward; they can continue to coast on the
vendor lock-in of their customers. We're not talking about letting others copy
their product, but rather allowing others to speak the same _language_ that
everyone is currently speaking to BigCo.

I agree with Joshua Bloch's sentiment that API design is "tough" and "a noble
and rewarding craft," but I don't think either of these imply legally-
protected status. I think it would be terrible for the industry if the judge
ruled that APIs are copyrightable.

------
IsaacL
One thing that suprises me is how _well_ the judge seems to grasp this rather
technical issue.

~~~
rayiner
Judge Alsup has a B.S. degree and apparently planned to be an engineer before
he got interested in civil rights:
[http://www.fedbar.org/Resources_1/Judicial-
Profiles/Judicial...](http://www.fedbar.org/Resources_1/Judicial-
Profiles/Judicial-PDFs/Alsup-profile.aspx?FT=.pdf)

------
_delirium
That seems correct: whether copyright law in principle covers copyright of
APIs is a question of law rather than fact.

~~~
jimmyvanhalen
<http://www.pcmag.com/article2/0,2817,2403292,00.asp>

Under questioning from Oracle lawyer Michael Jacobs, Reinhold contended that
"each page of the [Java] language specification includes a copyright notice,"

"Page, 39, testified over the course of two days, claiming that Google only
used elements of the Java programming language that are freely available in
the public domain. But after being admonished from the bench for evasive
responses to Oracle questioning, the Google CEO finally admitted that his
company never obtained a license to use Java code in its own software."

~~~
icebraining
Having a copyright notice does not mean it's copyrighted, though. Rural
Telephone Service Co. probably had a copyright notice in their listings too,
but the court still found it uncopyrightable.

------
Nogwater
I'm surprised that copyrightability of APIs is still an open question in (US)
law. Is that because people haven't copied each other's APIs before, or
because when they did nobody cared about the legality?

~~~
ajross
It might be a bit of a stretch to say it's an open question. This is the first
time (AFAIK) anyone has sued over it, so there's no case law. The closest
equivalent in "big" cases is probably Lotus v. Borland
([http://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_Int...](http://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_Intl,_Inc.)).

Basically, Lotus sued Borland because the menu layout of Quatro was identical
to 1-2-3. They won initially, but ultimately lost in the Supreme Court. The
judgement was that the mechanism for using a program was not a copyrightable
form. Prior to this case, I guess everyone sane had assumed that an API was a
basically equivalent mechanism (just one for a programmer instead of a user).
But Oracle has the constitutional right to sue for what they believe they own,
so there's no "short circuit" that would prevent the suit.

~~~
nitrogen
I thought that the copyrightability of APIs was a question in USL vs. BSDi
(<http://en.wikipedia.org/wiki/USL_v._BSDi>). Am I mistaken?

~~~
tonyjwang
If settlement occurs before a judgment is passed down, then the court case
doesn't bind future decisions.

------
zmanji
I feel the judge will rule that APIs are not subject to copyright. There is no
expression of creativity and it is fairly mechanical. I also think that if
they are subject to copyright lots of people are going to get sued.

~~~
Silhouette
_There is no expression of creativity and it is fairly mechanical._

I disagree. Designing a good API is one of the most difficult skills to
acquire in all of software development. If creating a good API were "fairly
mechanical" then the world wouldn't be full of crappy ones, and we'd all
rejoice permanently in the comforting glow that comes from writing code
against an API written by someone who gets it.

Despite this, I strongly believe that APIs _should_ be excluded from
copyright, for the same reason that I support the US exclusion of fonts. Some
things are too important to general communication and creativity to allow any
individual to have exclusive control over them, and they demonstrably can and
will be created without needing that incentive to make them economically
viable.

~~~
amalag
I can agree with parts of it, but I still think Google should pay Oracle for
licensing Java. They copied the entire API so they could leverage the entire
Java ecosystem, I think that's quite unfair to Oracle. Oracle is not suing
microsoft for implementing their own .NET VM.

~~~
nitrogen
What does it mean to "leverage the entire Java ecosystem?"

~~~
amalag
Developer tools (eclipse), libraries, developers trained in Java, Java
training. Just some of reasons they did not create their own VM like
Microsoft.

~~~
jrockway
They did create their own VM -- Dalvik.

~~~
davesims
Sort of -- but not in the same sense that the .NET CLR is MS's _own_ VM, with
its own unique bytecode (MSIL code).

Dalvik compiles ("dexes") Java bytecode (most of which, except for Android-
specific libraries, would run on any JVM) down to Dalvik 'bytecode'.

It's honestly not that different from what the MSVM tried to do. The main
difference, it seems to me, between the MS/Sun lawsuit over the MSVM, and the
Google/Oracle suit, is that 1) Google _did_ implement the entire JDK -- they
simply added more proprietary libraries that can't run on a conventional JVM
and 2) MS had a binding agreement with Sun.

If Google wins (and for the record I'm on their side of this completely), my
question is -- does that mean Microsoft _didn't_ need that license agreement
with Sun to begin with -- the one signed in 1996 that eventually caused the
downfall of J++/MSVM, and the birth of .NET?

That would be an interesting turn.

~~~
amalag
So asking for forgiveness and not permission would work out for Google? I
don't see how that can work, the only way is if API's are not copyrightable,
which will be up to the judge and not the jury.

------
zissou
Google will have to display Android's relevance via the difference between
implementing an API into a piece of software vs. the open and free use of an
API's concept, which in this case is mostly a set of [37] "best practices" for
a programming language. I suspect the latter is where Google will try and grab
some ground in the copyright debate in the days to come.

