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
GPL | 503 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OK... but... How About a Cola Analogy
Authored by: sproggit on Monday, April 23 2012 @ 01:36 AM EDT
A major foundation stone of Google's defense against Oracle is that
Android/Dalvik is a "Clean Room" implementation of JAVA written from
the language specification, not from any source code.

So I think Google will use the GPL angle as an incidental defense where e.g. we
see the "9 lines" and "literal copying" arguments coming
from Oracle.

For me the more relevant part is that Oracle are trying - and succeeding - to
put Google in a dilemma. You see, the SSO for the various language objects of
Android/Dalvik have to be implemented in *exactly the same* structure as JAVA or
code will not be portable. Similarly, the sequencing and types of parameters
passed to the methods within that codebase also need to be the same.

Now here's where Oracle are setting up a self-serving argument: they are saying
that "You cannot write something that is *similar to* JAVA. You can write
something which is a full implementation of JAVA - in which case you need to
prove that via a TCK which you can only get via a license from us; or you cannot
write something that is close to JAVA in any way and we will use our copyrights
of "the JAVA API" to keep you at bay..."

Google aren't claiming that Android/Dalvik is a full JAVA implementation (unless
I completely misunderstand). Instead what they are saying is that their
clean-room implementation offers developers an environment giving them
"JAVA language compatibility" without claiming it to be "full
JAVA".

How about this: suppose the source code and SSO of the Android/Dalvik was 100%
compatible with JAVA, but the run-time was not "JAVA bytecode". That
would fail the TCK and Google would not be able to call it JAVA. But, to a
developer, they would not be able to tell the difference. To a phone user, they
would not be able to tell the difference. Only Google would know. This is
essentially what I understand Google have done. [ The precise deviation from the
stand might vary slightly, but that's it].

Now, Oracle are trying to argue that because the "language
documentation" between JAVA and Android/Dalvik match, then there is literal
copying. We are speculating that if the documentation was produced using
JAVAdoc, and if Google had implemented a perfect API set, with all methods and
parameters properly implemented, then we would absolutely expect a JAVAdoc
result set to be EXACTLY THE SAME because the APIs are 100 compatible.

It seems to me [and I know nothing, of course] that the dilemma for Oracle is
that Google took the language specification - which is free to take and use -
and wrote a language implementation. Google then called this
"Android/Dalvik" and were happy. There's nothing in Oracle's license
terms that *forces* Google to go back, run the TCKs and validate that their code
is "JAVA", *UNLESS* Google want to call their code "JAVA".
Google have said, quite clearly, that they *DON'T* want to call their code JAVA,
so "that's all she wrote..."

In my thread title I mentioned a Cola analogy. Years ago the Cocoa Cola company
was founded, and one of the compelling parts of the history of their company was
that their soft drink had "Ingredient X" in it, that gave it a special
flavor. Other companies tried to find out what it was, some using lawsuits
claiming harm, to try and force the Cocoa Cola company to reveal their secret.
They were not successful. Similarly, other companies produced their own versions
of the drink. Pepsi is a well-known example.

Now, the Cocoa Cola company are/were doubtless mighty upset at Pepsi for
effectively producing a clone product. But because Pepsi did not call their
Product "Cocoa Cola", and because they did not claim it to be 100%
compatible with "Cocoa Cola" [ Pepsi merely call their drink
"Pepsi Cola" ] then there was nothing that the Cocoa Cola Company
could do about it.

In the same way, Oracle/Sun produced "the JAVA language
specification". Google used that to produce their own flavor of JAVA which
they called "Android/Dalvik". Google went as far as they were legally
permitted in order to ensure that Android/Dalvik was compatible with JAVA, so
that users of JAVA would be familiar with the new environment.

Oracle would like the jury to believe that an "either/or" exists here:
either you implement a full JAVA environment, submit to the TCK and call your
implementation JAVA (thereby agreeing to take licenses from Oracle) or you do
not get even close to the JAVA standard. It seems to me that the entire case
boils down to this argument.

I've looked at the JAVA language specification. I can't say in honesty I've read
the entire thing, because it's a lengthy and very dry document. But I can
truthfully say that I do not recall seeing any form of "all the way or not
at all" ultimatum in it anywhere.



Oracle are trying to rewrite this corner of the law in order to be able to imply
that Google have infringed something.

Google have taken Oracle's (Sun's) publicly available and free-to-use
specifications and written their own code, and now Oracle want to re-write the
usage conditions after the fact.

Proof of my theory? If Oracle's views were correct, then they would simply be
able to point to language in the language specification [which Google freely
admit to using to write Android/Dalvik] to the terms and conditions part, where
it says something like "You may only use this language specification to
produce a full implementation of the language, which you must then prove to be a
valid implementation through the use of the TCK, for which you must pay for a
license." No such language exists in the specification document.

Oracle have no merit to their argument.

Oracle are trying to get selectively creative and construe infringement where
none exists.

[ Reply to This | Parent | # ]

Don't confuse the spec with its implementation
Authored by: Anonymous on Monday, April 23 2012 @ 03:46 AM EDT
Only the implementation of an API can exist as Java source code or bytecode or
whatever. The specification itself is the information people use to format
their data so that they will be understood by the actual program that implements
the API.

The API itself is the standard. It's necessary for compatibility to copy the
standard exactly. But you can make your own implementation (i.e. class
libraries) that meets the standard. I believe Google did that, though things
get fuzzy when they talk about random bits of allegedly copied source code and
things that were decompiled. BTW, decompiling is the act of turning Java
bytecode back into source code... but it's not quite the same as the source they
compiled in the first place. It's missing a lot of info, like comments.

If you compare it to making replacement parts for a car, your part has to fit in
the same place as the old part and it has to do the same job as the old part.
You might make your own design for the part, but you're constrained by how it
has to plug in everywhere the old part did. Certain features of the API, like
the exact names used, their hierarchy, the class names, class methods, function
parameters and types are things that must be copied exactly.

One can, of course, make their own part that does the same job without copying
more than these names, but honestly, I can't think of any SSO type stuff that
they would be able to avoid copying. Unless there was copying of actual Java
source code that was legally important, Oracle should lose on the issue of the
API copyright nonsense, assuming the judge can be made to understand it. And
from the look of things, he's pretty well clued in.

[ Reply to This | Parent | # ]

The root of Marks confusion and resultant mis-direct on GPL?
Authored by: Anonymous on Monday, April 23 2012 @ 07:05 AM EDT
You have a GPL'd recipe in the API spec.

Dalvik is the cake.

[ Reply to This | Parent | # ]

The root of Marks confusion and resultant mis-direct on GPL?
Authored by: Anonymous on Monday, April 23 2012 @ 08:14 AM EDT
They might be written in Java, they might be capable of producing a book that
looks like the Specification, you are arguing that anything that is *Produced*
by a GPL program, is also covered by the GPL which is, exactly the sort of
nonsense that Oracle are trying to get away with.

Recently I've drawn the distinction between an Interface types in Java and
Interface as in Application Program. It's important. Particularly as they are
basically no more than a list of declarations. That led to a comment about
"just a list" and that not being enough because of SSO, or
"only" a list. I argue that it is "only" a list, and it
matters because by definition, if you change the list, if you change the
expression in the Interface if you are 'creative' in your expression, it is Ipso
Facto not the same Interface, so you cannot separate the idea from the
expression, so merger bars copyright eligibility in each and every one of those
items that are marked as Java Language Type Interface in the Specification.

That is not necessarily so for other parts.

All Oracle are arguing (and I am not suggesting validity, I'm only saying that
this is the only way Oracles argument makes sense) is "look at our Book,
this is our work, this is our creative work, we accept that there are some parts
of this Book that are not protected, but the law says that some parts of the
Book are protected, one of those parts is the SSO"

An example is 'annotations'. Look at the Book, it is a sub section of java.lang
it was a creative choice, its small thing, its for an interesting part of the
Java Language, but it was a design choice, a creative choice to put it where it
is. Google could have put it any where they liked, they could have put it in its
own section,they have their own sections they could have put it in,
android.annotations for example, if they wanted to they could put it in in a
section called java.syntax, but they didn't, look at their Book, they copied our
design decision, we used the second number in your zip code and the third letter
in your surname, and so did Google right here in their Book, Look at their Book,
this part here, this selection, this structure this organisation, it is
identical because the selection structure and organisation was copied directly
from Our Book.

(ergo everything belongs to Oracle because)
While Google copied the SSO from Oracles Book, which they admit they did, and
you can see they did, for their own Book, they also copied it, symbol for
symbol, into their source Code. Look at their Code.


And right there the side show begins, especially when you've already got a
couple of files and 9 lines of code and some comments, and with the symbols
you've got lots of methods, now everyone is talking about code,where do the
lines get drawn, what is , what isn't, how much, how many, isn't the code this,
or isn't the code that, does it include that, what if, how many lines? what is a
class library, what is an, so on and so on, if the code is available under the
GPL then it follows.....

Even worse, you can get them arguing about how unclean their clean room was
even though "it is not disputed, that Googles source code was independently
developed and not copied from Oracles"; so who cares?

This is (IM(NS)HO) why the Judge thinks its "Strange", his technical
leaning makes him think, like everyone else, this 'Specification' is a
description 'Of' the 'Code', the 'Code' that has Google not copied.
<Doink>

So the question being asked is how much of that 'Code' is protected?, what are
the boundaries of that protection of Source and Software Code offers?, does it
include the methods, parameters, fields, names? Which bits was it you say they
copied? Is this a question of implementation? what are declarations, would this
be normal? is that looked at? is this patent eligible?. And Oracle are happy for
everyone to waste their time, they're looking in the wrong direction.

Jacobs is sitting there with a smile on his face, not just because he's a
professional, but because he's got everyone exactly where he wanted them, and
the nervousness on the rest of his team?,is that concern, or excitement? It
worked, they might even pull this off. Google of course, have yet to take stand
and are no doubt considerably smarter than me.

Oracle have warned the Judge that there is (basically) no case law to support
their position, Google ISTM have filed lots to support a position that Oracle
are not disputing.

Mark asked "When determining "substantial similarity" what is
Oracle
comparing?", I think the answer to that is the BOOK, and they try and
support that using arguments from merger/scenes a faire while pointing at
randomly between the Code and the the Book.



Oops, I appear to have a had a seizure and forgotten that we were talking about
APIs, sorry about that .


s/Book/API/


there.





[ Reply to This | Parent | # ]

GPL
Authored by: Ian Al on Monday, April 23 2012 @ 12:41 PM EDT
The GPL licence terms refer to what you can do with program source code (and
binaries, too).

Are lines of documentation legally program source code even if they are in the
same document? If Oracle prevail then the documentation text will be considered
a derivative of the protected API documentation.

Elsewhere, I point out that the API Specification is an abstract idea way of
recording what the API library implementations do. javadoc was almost certainly
part of the process of detailing the Specification. That is not, yet, clear to
the court.

Once that is clear, then the comment creative expression will be clearly fixated
in the medium of the implementation source code documents. The Specification is
a derivative of the SSO and descriptions in the library implementation and does
not contain the fixated creative expression, but merely mirrors it.

Can a document receive copyright protection on the basis of creative expression
fixed in another document? I think that copyright law says 'no'. But, what would
I know?

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

[ 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 )