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
OT here | 393 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections thead
Authored by: nsomos on Friday, May 25 2012 @ 08:51 AM EDT
Please post any needed corrections here.
Summerize if possible in posts title.
(Summer is getting closer)

Summerize -> Summarize

[ Reply to This | # ]

OT here
Authored by: SpaceLifeForm on Friday, May 25 2012 @ 09:07 AM EDT


---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

News Picks commentary here
Authored by: SpaceLifeForm on Friday, May 25 2012 @ 09:08 AM EDT
Please note the article you are
referencing and include a link
for future readers.

---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Comes notes here
Authored by: SpaceLifeForm on Friday, May 25 2012 @ 09:10 AM EDT


---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Grasping at a thin straw: Oracle v. Google - Copyright Reply Briefs
Authored by: Anonymous on Friday, May 25 2012 @ 09:18 AM EDT
My read of the Oracle brief is that they're trying to tie together two or three independent threads and hoping that the result is a finished quilt. I don't see it working. The pieces don't add up. Oracle's definition of compatibility appears to be with Java as a whole , but has been said dozens of times, this isn't a case about the whole of Java, it is about Android and a couple of functions or procedures. I am not a lawyer, but this line of argument seems weak to me.

[ Reply to This | # ]

Can't have it both ways.
Authored by: Anonymous on Friday, May 25 2012 @ 09:24 AM EDT
Oracle is arguing that Selection, Structure, and
Organization is hard work and copyrightable.

But they're also arguing Android represents the spectre of
fragmentation - it's not completely compatible with Java!

If that's so, then the API for Android, while it might be
inspired by Java, is not the same.

This implies that Google expended "time and effort" to
Select, Structure, and Organize it's API to something that
Oracle itself is arguing is DIFFERENT from Java. That seems
to be a creative act by Oracle's very argument, doesn't it?

Otherwise, Oracle's API itself is derivative of many
languages that came before...

[ Reply to This | # ]

Directional compatibility
Authored by: Anonymous on Friday, May 25 2012 @ 10:27 AM EDT
Oracle's making the argument "Not everything that runs in
Java runs on Android. Therefore, Android isn't compatible
with Java."

That's clever slight-of-hand that misses the point.

Android was never intended as a piece-wise replacement for
Java. It's deliberately a subset of Java. Claiming it's
not "compatible" because it can't run every Java program
isn't the proper definition of "compatible."

The operative question is whether ANDROID programs can run
in JAVA, not the other way round.

[ Reply to This | # ]

It would be nice to have specific examples...
Authored by: Anonymous on Friday, May 25 2012 @ 11:26 AM EDT
of Java programs, with clear descriptions of their purpose and the hardware on
which they'd have to be or are intended to be run, that couldn't be processed
through dexopt and run in the Dalvik VM (Android). It would likely be quite
clear then that Oracle's argument is inappropriate re: interoperability.

It isn't up to Google to go looking for Java programs that could be processed to
run in Android.

JWC

[ Reply to This | # ]

I don't get the compatibility argument
Authored by: Anonymous on Friday, May 25 2012 @ 12:32 PM EDT
Does Oracle mean it would be ok if Google had "copied" even *more*?

[ Reply to This | # ]

What is the next show?
Authored by: argee on Friday, May 25 2012 @ 03:37 PM EDT
The SCO cases have dwindled to just the footnotes
on the screen at the end of the show.

Oragaggle is winding down. Season finale is next
week.

News at 11.

What is next? When?

---
--
argee

[ Reply to This | # ]

Oracle Didn't Do Homework?
Authored by: Anonymous on Friday, May 25 2012 @ 08:18 PM EDT
Is anyone else surprised by Oracle's statement about how they didn't do their
homework and couldn't find a copy of this case even after several days?

What do they think that will buy them, exactly? Do they intend to use it as an
excuse for misrepresenting the holdings of that case?

[ Reply to This | # ]

Could Google's team throw straws
Authored by: kawabago on Friday, May 25 2012 @ 11:28 PM EDT
Could Google's team throw straws for Oracles team to grasp
at?

[ Reply to This | # ]

Newspicks??Microsoft Requests Takedowns From Google, But Content Remains on Bing
Authored by: Anonymous on Saturday, May 26 2012 @ 12:50 AM EDT
From wired . ... we would expect Bing to remove all of the same links that Microsoft requests Google Search to remove. Unfortunately, this isn’t the case all the time. One reason could be that Microsoft, which recently released a new version of Bing, wants to give itself a slight edge over its largest competitor. Mickey$oft strikes again lol.

[ Reply to This | # ]

Seems like the Connectix case was about ABIs
Authored by: xtifr on Saturday, May 26 2012 @ 03:17 AM EDT

It looks to me like the Connectix case was about ABIs--Application Binary interfaces, not about APIs (Application Program Interface. ABIs are about the kind of binary compatibility that Oracle is discussing, but APIs are for the programmer. They are in the source, and may not even exist anymore once the code passes through a compiler. I'm not sure which should be afforded more protection (assuming the value is non-zero in either case), but my instincts tell me that APIs are less protectable than ABIs!

An API only appears in the source code--though it may match an underlying ABI. It's basically (as I've argued before) an extension to the language, expressive in the same way that words in a language are: it's not the words that are protected (not the API), but the use (a program using that API--as well, of course, as the implementation behind the API). Oracle keeps talking about binary compatibility, which is irrelevant when we're discussing APIs. The point of using an existing API is to provide a familiar language for the programmer. And, like any other computer language, is inherently not protectable.

ABIs, on the other hand, actually involve links between compiled code, and I could see arguing that linking to existing compiled code on either side of an ABI could be creating a derivative work. Any point in a compiled program could be declared as an ABI, but only some are necessary for compatibility, which is why compatibility is an important issue when discussing ABIs in the context of infringement. Which is why I suggest that ABIs are more protectable than APIs. (Though I admit it's a stretch to call an arbitrary point in an existing program an ABI.)

There's a reason why ISO standards for languages like C and C++ (which actually have standards, unlike Java, which really still only has Oracle's whim)--the APIs are part of the language. Even third-party APIs merely extend the language. It's still a language, and the Java language (and like any computer language) is not copyrightable, because it's a means of expression, not an expression itself.

So not only is Oracle's argument unavailing, but they're not even on-point in half of what they talk about.

---
Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | # ]

What's reasonable?
Authored by: Anonymous on Sunday, May 27 2012 @ 09:34 AM EDT
I'm pro Google...

That said, what do you think would be a reasonable
judgement, given the evidence we've heard about APIs and
copyright?

It's not disputed that Google copied the API's. I personally
don't think that the _reason_ for compatibility
- whether for programming compatibility or to help
programmers learn the environment -is of any relevancy. I do
think that it was reasonable for Google to
use the work; Java is free and open - Sun made it that way.
But even if it wasn't open, reusing an API should be fair
use. It's not reasonable to Google to call their work
call Java; that's something that Sun protected. And Google
made no representations that it was Java, so I don't
think that Java fragmentation discussion is at all relevant.
I do think that there is work and choice in designing an
API, but that APIs are functional.

Overall API use. I think it's in the name; they could
reimplement them to their heart's content whether they were
required for the language or not, provided they meet a very
low bar of needing to for interoperability. And personally,
I think even without interoperabililty, these are functional
things, and shouldn't be copyrightable.

SSO. I don't think that Oracle was clear about what they
meant. Not in any evidence I heard, anyway. Google had to
use the same package names to make for
transferability of skills and code between the
platforms. They had to use the same class names for the same
reason. Ditto interface names. Ditto exceptions. In
particular to Java (and not all other programming languages)
they did not have to use the same parameter names to
methods. Some of those parameter names are purely
functional, and there's very little choice - e.g. color.
Others could be different. It's great to be able to reuse
the Java documentation, but this is not a requirement
enforced by the programming language. I think Google should
pay something in respect of the re-use of parameter names
that are non-functional. I'd like to see the tariff set at
$60 in total.

With respect of the order of the methods in classes, and the
classes in the packages, I think Google had some choice. I
haven't checked whether the ordering in Java was
alphabetical, but if it doesn't follow alphabetical
ordering, or some other predicable ordering, and if the
Google ordering is the same, then I'd say this was
copyrightable, and again, the tariff should be $60 in total.

With respect to the 9 lines. I disagree with the judge, and
side with the jury - I'd say they were de-minimus. However,
the judge disagrees. I'd say $60 total tariff for the 9
lines, and I think this is high, considering the way that
those lines entered Android and Java. (I wonder if Oracle
should _pay_ $60 for the use of these lines as part of the
Timsort routines. Oracle having to pay something would be
justice for this unbelievably stupid court case. I'd like to
see them spin that into some sort of win!)

With regard to the test files. They should not have been
present, and whether a subcontractor included them or not is
irrelevant; Google bears responsibility. However, they were
never shipped, and there's no evidence that I know of that
they were of use. I would say $60 total for the
infringement.

I think the judgement as a whole should be written to
protect the use of APIs where they are being used. It should
distinguish between the API and the implementation. I'm
referring specifically to the API, not the implementation. I
would like to see it being made clear that anything that's
functional is covered by protected use. I'd like to see
specific criticism of the arguments that Oracle has deployed
in this case, and their game playing. I'd like to see
elements of the judgement that make them think twice about
whether it would be a good idea to appeal.

Overall, I think Google was in the right, were using Java
fairly, and that any infringement was inadvertent. I think
$240 is a fair price for their mistakes. I don't think that
costs should be awarded. Actually, I'd like to see Oracle
having to pay Google's costs, but that's unfortunately
unrealistic.

[ Reply to This | # ]

Oracle v. Google - Next Steps?
Authored by: Anonymous on Tuesday, May 29 2012 @ 08:40 AM EDT
So, what happens next on this, and is there any expected
timeline?

Here's what I think still needs to happen (please advise if
I'm missing anything). In no particular order:

I expect at some point the judge will rule on the
outstanding motions, and notably API copyrightability.

We need the bench trial/determination on copyright liability
for the 9 lines of timsort and the decompiled help files.
Not sure if that depends on the API ruling or not.

We need final judgement entered on patents. This may
require waiting for some JMOL motions from Oracle claiming
"no reasonable jury could have found for Google on these
facts" and asking the judge to set aside the verdict.

And then, of course, we wait for the inevitable appeal by
Oracle on patents, by whoever loses the API ruling on
copyrights, and possibly by both on the timsort/helpfiles
copyright (I expect Google to appeal on de minimis for both
and that the judge used an improper definition of the
"complete work," I expect Oracle to lose on infringers
profits and appeal on that).

Is the list above complete and accurate? And do any of the
first 3 steps have an expected timeline?

[ Reply to This | # ]

"de minimis" defined
Authored by: Anonymous on Tuesday, May 29 2012 @ 10:50 AM EDT
There is an old and well-known* saying "De minimis non curat lex",
which means "The law does not concern itself with trifles".

Clearly this is no longer the case, and our Judges are in danger of getting
jelly and cream all over their wigs.

*OK, well-known among lawyers who speak Latin. But well-known enough that it's
usually abbreviated to "de minimis".

[ Reply to This | # ]

About that fragmentation...
Authored by: webmink on Wednesday, May 30 2012 @ 11:00 AM EDT
Going back through my materials to write an article for CWUK this week, I suddenly realised the significance of a video interview I did with the director of Java ME at JavaOne in 2009 which I also blogged. It clearly demonstrates that Java ME was already fragmented in 2004 (when Java Verified launched), that Sun had made multiple attempts to address it, and that it was nothing to do with Android.

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