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
Harmony Class Libraries | 394 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here please
Authored by: jbb on Wednesday, April 25 2012 @ 03:40 PM EDT
Please indicate the correction in the title.

---
Our job is to remind ourselves that there are more contexts than the one we’re
in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

News picks
Authored by: feldegast on Wednesday, April 25 2012 @ 03:42 PM EDT
please make links clickable

---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

Off topic
Authored by: feldegast on Wednesday, April 25 2012 @ 03:43 PM EDT
Please make links clickable

---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

Shocked
Authored by: Anonymous on Wednesday, April 25 2012 @ 03:45 PM EDT
Surely they would have checked the paperwork matched the
claims?...

Is this another footgun?

I'd guess that the Judge might let it run anyway (if there's
any legal way that could happen), to avoid appeals.

[ Reply to This | # ]

Comes transcribing
Authored by: feldegast on Wednesday, April 25 2012 @ 03:45 PM EDT
Thank you for your support, see http://ww w.groklaw.net/staticpages/index.php%3f page=ComesBooking for documents

---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

Oracle whoops thread
Authored by: feldegast on Wednesday, April 25 2012 @ 03:49 PM EDT
O M G

---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

  • whoops - Authored by: Anonymous on Wednesday, April 25 2012 @ 03:59 PM EDT
Oracle patents
Authored by: jvillain on Wednesday, April 25 2012 @ 04:18 PM EDT
Oracle now trying to get one patent back into case that was revived by PTO. Says willing to drop claims on other patents to use this one

Link

The time stamp is 7:40AM as I am unsure how to link to a singe tweet.

If true it doesn't mesh with what I understand of how trials work. But more importantly is speaks volumes as to the value or validity of the remaining patents.

[ Reply to This | # ]

Lay Opinion
Authored by: Anonymous on Wednesday, April 25 2012 @ 04:22 PM EDT
> Google: While you were developing Android, did you believe
> that you needed a license from Sun for the Java APIs?
>
> Oracle: Objection, foundation.
>
> Judge: He can say what he understood back then, as a lay opinion.

So why weren't the others on previous days allowed to say what they
understood then, as a "lay opinion"?

[ Reply to This | # ]

  • Lay Opinion - Authored by: PJ on Wednesday, April 25 2012 @ 05:12 PM EDT
  • Lay Opinion - Authored by: Anonymous on Wednesday, April 25 2012 @ 06:02 PM EDT
    • Lay Opinion - Authored by: DieterWasDriving on Wednesday, April 25 2012 @ 06:29 PM EDT
    • Lay Opinion - Authored by: Anonymous on Wednesday, April 25 2012 @ 06:51 PM EDT
      • Lay Opinion - Authored by: PJ on Wednesday, April 25 2012 @ 08:49 PM EDT
        • Lay Opinion - Authored by: Anonymous on Wednesday, April 25 2012 @ 10:15 PM EDT
        • Rule 50 - Authored by: eachus on Thursday, April 26 2012 @ 12:23 AM EDT
          • Clicky Rule 50 - Authored by: Anonymous on Thursday, April 26 2012 @ 12:38 AM EDT
An INCREDIBLY obvious analogy for APIs
Authored by: xtifr on Wednesday, April 25 2012 @ 04:26 PM EDT

I just posted this in the last thread, but I wanted to repost it, because it's such an obvious analogy that it barely counts as an analogy at all. It's almost an obvious technical definition.

I'm surprised that nobody has come up with this before. The most obvious analogy for an API is a computer language! Because that's basically what an API is--and extension to an existing language. The API adds new words to the language. When people say an API is "just words", that's exactly right! It adds new vocabulary to the language.

When you write a useful library, you need to make it accessible to the people who are writing programs in a given language, so you create an interface between the language and the code in your library. This makes your library essentially become part of the language--programmers can reference it just like they can reference the built-in parts of the language, to write their programs.

The more I think about it, the more this seems like a perfect analogy. You can write a library in one language (like, say, C) and provide APIs for several (say, C, Python, Perl, even Java if you want to sacrifice the portability factor). The library remains the same in all cases--all the API does is add the library to the language! And someone can come along and write a similar library using only their own code, and use your API (your vocabulary) to add their library instead, just as they can re-implement the basic underlying language(s).

I'd love to hear one of Google's lawyers ask the expert: "what is the difference between a language and an API?" We all know that languages aren't copyrightable--although implementations are. Why is it different for extensions--added vocabulary--for the language?

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

[ Reply to This | # ]

Scrivener's Error Thread
Authored by: Anonymous on Wednesday, April 25 2012 @ 04:29 PM EDT
Cannot was for the reply to Google's Rule 50 Motion, where BSF says it
was just a scrivener's error on the copyright registration form.

om1er, not logged in

[ Reply to This | # ]

Google Needed Java
Authored by: Anonymous on Wednesday, April 25 2012 @ 04:31 PM EDT
From a trial exhibit - November 2006 presentation outlining a Google phone.

Fact: Linux fragmentation threatens market acceptance. Tools and new app
frameworks are biggest hurdles. 6M Java developers worldwide. Tools and
documentation exist to support app development without the need to create a
large developer services organization. There exist many legacy Java
applications. The wireless industry has adopted Java, and the carriers require
its support.

Strategy: Leverage Java for its existing base of developers. Build a useful app
framework (not J2ME). Support J2ME apps in compatibility mode. Provide an
opTMobileized JVM (Dalvik).

http://news.cnet.com/8301-1035_3-57421233-94/googles-original-phone-surfaces-in-
court/

Google's intention was to use Java all along because they did not have a
developer base. They couldn't bring Android to market without Java.

I think we can drop the pretense that Google is any white knight. Google's a
large corporation like Oracle out to make money. Period. Google couldn't secure
a proper license from Sun so they went the backdoor route.

It will basically come down to: Did Google violate any agreement, any IP that
Oracle owns? If there is some Java IP that is not GPL'ed then Google loses. If
not, Google wins.

But let it be clear, Google used Java to further its own ends.

[ Reply to This | # ]

Oracle's Reality Distortion Field
Authored by: jbb on Wednesday, April 25 2012 @ 04:35 PM EDT
Oracle: When Mr. Schwartz [Sun CEO] did his blog, he didn't have the SDK?

Andy Rubin: No, the SDK came out a few days later.

The implication Oracle is driving at here and in later questions is that had Sun but known that Android was using Java APIs then they never would have offered praise and congratulations. Instead, they would have been launching lawsuits.

What a fine example of BS&F-speak! Obviously Schwartz knew Android used the Java language. That's why he said Android would act like booster rockets on Java. Oracle is suggesting that Schwartz was pleased only because he assumed Android had invented their own incompatible APIs which would have fractured the Java community and forced many developers to choose to either program in Sun-Java or Android-Java but not both. This is the same Oracle that is complaining about being harmed by fragmentation!

Oracle is trying to twist the plain and obvious truth into a pretzel. Schwartz was happy with Android and thought it would benefit the Java community precisely because he assumed it used the same (or at least very similar) core APIs. If they didn't use the same APIs then it would have created a huge mess that damaged both Android and Java. Yet here we have Oracle trying to spin a tale that is the exact opposite of the obvious (to programmers) truth. They are implying that Schwartz was happy because he assumed Android-Java was such a different language from Sun-Java (due to completely different core APIs) that once someone started programming with one variant they would have a very hard time switching to the other.

The bottom line is Google did the right thing by making their version of Java compatible with Sun's version. This required them to use the same or very similar core APIs. Sun was delighted that Google did the right thing. Now in order to try to make a quick buck, Oracle makes up the idea that APIs can be copyrighted and then tries to rewrite history by implying that Sun was only pleased with Android because they had assumed it had fractured the Java language to the core (core APIs that is).

It is shameful that our society richly rewards people for cooking up lies like this. These lies do nothing to benefit society as a whole. Their only purpose is to enrich a few people undeservedly at the expense of everyone else.

---
Our job is to remind ourselves that there are more contexts than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

Bouncy Castle
Authored by: Anonymous on Wednesday, April 25 2012 @ 04:37 PM EDT
Bouncy castle was an JCE provider which implements most of the javax.security
package interfaces which provide a set of cryptographic algorithms for xmlsec,
DES, AES, et alia. These were used in place of the com.sun.security
implementation which couldn't be exported and thus was separate from the
J2SE/J2EE distributions.

It's not a complete set of java APIs, just a cleanroom (aussie) implementation
of the security API's.

[ Reply to This | # ]

Why didn't Google mention APIs Oracle implements?
Authored by: Anonymous on Wednesday, April 25 2012 @ 04:46 PM EDT
Java SE contains a complete implementation of the DOM API.
That API is owned by the W3C. The class, methods, SSO etc. is
identical to the spec (it has to be, of course)
It also contains an implementation of Corba. The class and
method names are taken directly from the spec.

Why on earth has Google not brought this up?

[ Reply to This | # ]

Collection vs Individual Copyright
Authored by: MDT on Wednesday, April 25 2012 @ 05:22 PM EDT
Oracle has got themselves into a pickle, and they didn't have much of a choice about it.

They started out suing over 51 APIs. Then they had to trim it down to 37, because they didn't write or own 14 of them. That means that when they sent in the copyright registration, they knew that they didn't have the copyright over all the APIs. But, they needed the copyright for the trial, so they (BSF probably) filed the copyrights the only way they could, as a collection. Then they hoped nobody would notice.

They could not individually copyright the API specifications. There isn't enough to them to get a valid copyright from the copyright office (not to mention that other languages use substantially similar or the same specs). So, the lawyers, being well versed as they are in law, went for what they knew they could get away with without getting in hot water for falsifying applications.

Unfortunately for them, Google caught on (I kind of suspect they caught on earlier, and were waiting for Google to paint themselves into a corner and rest their case, so they couldn't wriggle out like slimy little salamanders).

---
MDT

[ Reply to This | # ]

Apache Field of Use Restriction
Authored by: hedronist on Wednesday, April 25 2012 @ 07:33 PM EDT
Oracle: Did you know that Apache had field of use restrictions on it?

Andy Rubin: No, I did not.

IANAL, but I think that Boies just came as close to lying as he could and get away with it. It struck me as odd that he would have even said that, since the only reason Apache Harmony was not verified with the JCK was because Apache wouldn't sign a license with a Field of Use restriction in it. And they said that clearly and repeatedly. Ref. Open Letter to Sun Microsystems

I was shocked that Google didn't scream Objection! 1 second after he had asked this question.

[ Reply to This | # ]

Reserving on the issue of SSO copyrightability
Authored by: darrellb on Wednesday, April 25 2012 @ 07:50 PM EDT
Judge: Reserving on the issue of whether SSO is a copyrightable issue. That way, it would be easy for the court of appeals to reverse without a new trial.

Now it makes sense why the Court moves forward with the jury under an assumption that SSO is copyrightable. There will be evidence for infringement in the event that, after appeals, SSO is copyrightable. And if SSO is ncopyrightable, the Court will have evidence that it will not need to use for anything, but won't be lacking evidence it needs.

[ Reply to This | # ]

He gets it!
Authored by: Anonymous on Wednesday, April 25 2012 @ 07:52 PM EDT
Judge: Beginning to hear a defense item, a way to escape the admission of the SSO in the case, that the API doesn't exist. That's what I heard this last witness to say. I drafted this special verdict form before I heard that. I wish you could meet and confer to come up with a definition of an API. It has become quite clear what has happened here: the names and the hierachical organization is the same. The compiled code is different.
Good, I believe he understands this now. I'm somewhat worried about the SSO thing, but maybe the funny business with the copyright registrations will scuttle that, anyhow. The law here looks pretty thorny and this seems more likely to turn on random details specific to this case than copyright law itself, but who knows?

[ Reply to This | # ]

The API analogy thread
Authored by: clemenstimpler on Wednesday, April 25 2012 @ 08:05 PM EDT
PJ has asked previously for enlightening analogies on what an API does in Java. Here is my attempt, inspired by the following quote from Rubin:
If the app needs a function from the core libraries, the program will call into the core library, and the core library will do its job.
It's in the form of a little science-fiction fairy tale.

Once upon a time, a company called Sun created a herd of little robots for menial tasks around the house. When you wanted one of them to appear in your home, you only had to consult a directory quite similar to what we know today as 'yellow pages'. If you required a plumber robot to repair your kitchen sink, you just dialed 'p-l-u-m-b-e-r.re-p-a-i-r.k-i-t-c-h-e-n-s-i-n-k' on your phone. The robot helper appeared and repaired your kitchen sink.

Another company, Google, believed that it could build such robots, too. It did not want to steal the work from Sun. So it hired people who weren't in the robot constructing business and paid them to construct robots on their own in their own 'clean room'.

But of course, people had to know which robot to call in order to get the job done. So Google published its own directory. This directory had to follow the expectations of clients using Sun robots before. So it seemed to make sense to structure the directory the same way Sun did before. After all, a plumber robot is a plumber robot. And it makes sense to call 'repair.kitchensink' by that very name.

Sun welcomed Google robots, because by then it had decided that the construction plans for its own robots should be open to the public in order to enhance the technology. Someday robots would be so ubiquitous that Sun would find a way to actually make money of them.

But these dreams did not come true. Sun was bought by Oracle for an amount of money not to be disclosed in a court of law. In due course, Oracle had a closer look at the Google robot directory. And it saw that in the Google robot directory, 37 'core robots' were listed in the same 'structure, sequence, and organisation'. They even had the same dial-up numbers. Google would have been required under the law to change the names of the robots ('pipe-and-water-technicians' rather than 'plumbers').

But this was not enough. What the robots did, was suspisciously similar to the abilities of the Oracle robots, too. They stole the idea that robots could be plumbers. But since stealing ideas is not forbidden in the future, Oracle sued Google for putting their robot under the heading 'plumber.repair.kitchensink'. Google rightfully should have added or left out some robot capabilities. So the robot command should either have been 'plumber.disconnect.kitchensink' or 'plumber.repair.kitchensink.and.toilet'.

You may have noted that the case is before the court now... ;)

[ Reply to This | # ]

Is that why you stopped beating your wife?
Authored by: BitOBear on Wednesday, April 25 2012 @ 08:30 PM EDT
Oracle's lawyer is using improperly formed questions to condition judge and jury
to assume and believe facts not in evidence.

Any fifth-grade bully knows that it is easy to construct questions that damn the
questioned no matter how they answer a question. These questions are the basis
for things like push-polling and other abuses of information purpitrated on
people like judges and juries. If, however, you have ever been subjected to this
kind of bullying you will forever be aware when the technique is in use.

Oracle is using this technique on Andy Rubin. It is frustrating him, though he
may not understand why. It is also conditioning the court to change its stance
and alter is rulings by presuming validity of certain Oracle positions.

First the sensitizing example. In deference to the forumn rules I will do a
little word substitution: We all know an F-word that references homosexuality,
and how it is used on the playground. I will substitute "(blank)"

Shouted across a playground: "Hey Rob, are you a (blank) in a cage?"

Me: "NO!"

Kids begin chanting: "(blank) on the loose! (blank) on the loose!"

So the thing is, such questions posed as yes or no (or in court "i don't
know") answer domains carry a weight of information that is unproved or
false. Asking the question is damning for all "allowed" answers.

Oracle Examples:

Did anyone tell you that Sun had put field of use restrictions on the J2SE
against mobile devices? (This is immaterial as AR's "being told" of
restrictions to a body of material they -aren't- -using- is not part of the
case. The presumed weight is that Sun is allowed to put restrictions on things
and that those things have bearing. This is a minor example to wet the pallet.)

Did you know that Apache had field of use restrictions on it? (Apache has no
such restrictions. All answers of "yes", "no", or "i
don't know" are damning. "Yes", though incorrect, says AR is a
bad actor. "No" and "i don't know" both call AR
incompetently unaware and imply the same silent question "why didn't you
know?". The correct answer is "I know that is has no such restrictions
and never has had such".)

While you were developing Android, you didn't have any authorization from Sun to
do what you were doing? (AR needed no authorization from Sun to do his job. He
needed authorization from Google, e.g. his employer. The entire case is the
question of whether Google needed authorization. The formation of the question
"affirms by silence" that said authorization was necessary.

Apache makes some or all of the Java class libraries available? (False, sort of.
Apache makes Harmony classes available. Those classes conform to the Java API.
There is an implication of ownership and trespass in the formation of the
question. The Harmony classes are classes from the java library spec, but they
are not Java class libraries.)

You knew that Apache was precluded from being used on mobile devices, right?
(There is no such preclusion, this is why Apache never went after the TCK.
Again, an answer of yes would tar with the brush of deliberate imporpriety and
both "no" and "i don't know" tar with willful ignorance.)

Thing is, this is a typical Biose (spelling?) behavior going back to SCO et al.
It's a poor-mans Perry Mason gambit. It is super common in "political
debate" as well.

Note that the damning question formation relies on the "initial
belief" mechanisim as described at the following link: (link through to the
formal study for the full citation, but the blog version is easier to take
informally.)

http://www.spring.org.uk/2009/09/why-you-cant-help-believing-everything-you-read
.php

This is not the same thing as asking a "leading" question. This is
much more sinister when done this systematically. Looking back at B.'s other
questions here and in SCO its actually very much his primary mode. I think it's
his "one trick" that we have grown so used to, but not before given
name to.

Oracle is push-polling the court, with some success it seems. Hopefully Google
can undo some of the damage in its case.

[ Reply to This | # ]

Name declaration is [merely] an implementation of the API
Authored by: lwoggardner on Wednesday, April 25 2012 @ 08:31 PM EDT
Judge: The name declaration, what do you call that?
Dan Bornstein: An implementation of the API.

Is this the crux of the "API is not copyrightable" argument? ie that The API is an abstract concept, only made concrete by the declarations which appear in source code, the bytecode and the specifications/documentation.

[ Reply to This | # ]

Who is the judge ruling for in the cleanroom issue?
Authored by: SLi on Wednesday, April 25 2012 @ 08:40 PM EDT

I'm not sure I follow this part of the notes (I'm not even sure where he's switching between different issues, so I'll quote a larger part). Whose theory is out of the window? Is "creative writing" something special in this context (i.e. apart from the Wikipedia definition) I should recognize to understand this comment? How does cleanroom relate to this?

Judge: Reserving on the issue of whether SSO is a copyrightable issue. That way, it would be easy for the court of appeals to reverse without a new trial.

Judge: I do not have in there that the implementation (compiled code)

Judge: Classic case of an attempt to copyright an idea.

Judge: Cleanroom is like creative writing. That theory is out the window. That's my judgement.

Judge: There is a trying to have it both ways character to the plaintiff's case:

1) all 37 put together

2) all 37, considered individually

On Google's side, if SSO is copyrightable, which this jury will be told is the fact, there is no way for you to argue that it's de minimis. There should be a rule 50 entry by Oracle to that fact.

[ Reply to This | # ]

Harmony Class Libraries
Authored by: BitOBear on Wednesday, April 25 2012 @ 08:54 PM EDT
I just accidentally made a point that I thought needed to be brought out for
separate discussion.

Apache Harmony -does- -not- make the Java Library Classes available.

Harmony makes the Harmony Class Libraries available. Those Harmony classes
deliberately conform to the Java classes by implementing the sections called
"java.lang" et al.

The way the questions are being asked and allowed gives undue credit and
credence to Oracle's position by making it seem like Harmony is a trespass that
it is not.

Harmony doesn't let you into Sun's house, It lets you into Apache's house. It is
true that the houses are deliberately similar, that they are hopefully congruent
in layout and functionality, but they persist in being their own properties.

The API isn't the "blueprint" for that house, as such blueprints would
contain materials used and such. The API is the "walking tour"
information. It's the "on the left you will find the master bedroom"
and "off the kitchen is a porch" information. The houses themselves
have different materials and dimensions and may differ in all sorts of detail.

Every time a witness says that Harmony "gives access to" or
"provides" the Java Library Classes it is a disservice to the truth.

[ Reply to This | # ]

Oracle can't claim 3rd patent at trial
Authored by: Anonymous on Wednesday, April 25 2012 @ 09:27 PM EDT
3rd patent claim rejected - Ars Technica

"The reversal came a few days too late, for the trial had already started and the dismissals with prejudice had already become effective," Alsup wrote. "Oracle’s argument that the patent ‘trial’ has not yet started is wrong. The was and is one trial with three phases. The trial started on April 16. This is not only the plain meaning of the term but any other interpretation would inject great prejudice given that the parties have relied on the issues to be tried and that reliance should not be turned on its head in mid-trial. Oracle will be required to stand by its word and live with the dismissal with prejudice."

[ Reply to This | # ]

Copyright on a compilation v copyright on its components
Authored by: Anonymous on Wednesday, April 25 2012 @ 09:37 PM EDT
I am not a lawyer, but I worked for nearly 15 years for a
501(c)(3) not-for-profit that depends on more than a little
of its revenue on publishing new compilations of works it
has already published. At a particularly key juncture, we
were about to publish in CD form TIFF renderings of over
seven decades of the organization's monthly membership
journal and, going forward, publish current and future
issues of that journal in interactive e-book form. It was
important to know exactly what we could and could not
copyright -- that is, exactly what did and did not happen
when we published _and copyrighted_ our compilations.

To get at the issues involved, imagine compiling and
publishing a collection _solely of works for which copyright
has expired._ Once a work falls out of copyright, it's in
the public domain and can't be pulled back in. So what are
you protecting when you release a copyrighted collection, a
compilation, of such works? Because all the components of
the collection have fallen into the public domain,
copyrighting the collection can protect only _new_
intellectual property: the organization, structure, and
sequence _of the compilation_, plus any new front and back
matter, including cover graphics. The copyright status of
the component reprinted works is unchanged because it cannot
be changed.

[ Reply to This | # ]

Hey - guess what I just found...
Authored by: Gringo_ on Wednesday, April 25 2012 @ 10:24 PM EDT

Package java.lang

Provides classes that are fundamental to the design of the Java programming language.

The page linked to details the specification for the classes, interfaces, and exceptions. To me, the above is saying the specification is part of the language, not some vague, separate thing called an "SSO". In other words, if you have a right to use the language, it follows that you have a right to use the specifications. ...and if you have a right to use the specifications, then you have a right to employ them to make your own implementations. Oracle is full of it! What does it look like to you?

[ Reply to This | # ]

Day 8 at the Oracle v. Google Trial ~ pj - Updated 5Xs - Judge Denies Oracle Motion Re '702 Patent
Authored by: Rubberman on Wednesday, April 25 2012 @ 10:55 PM EDT
PJ, this is the best reading I've had in a long time! Thanks
so much for all the work in bringing the trial to life for
those of us "in the trenches".

Rubberman
Senior Systems/Software Engineer
For A Really Big Cell Phone Manufacturer

[ Reply to This | # ]

"Oracle will be required to stand by its word," says his honor
Authored by: mexaly on Wednesday, April 25 2012 @ 11:35 PM EDT
Now that scratches an itch that I've had for a long, long time.

---
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 | # ]

When this same case was last tried...
Authored by: BitOBear on Thursday, April 26 2012 @ 03:05 AM EDT
Years before my birth there was a bunch of cases involving the S.A.E. (Society
of Automotive Engineers) and the auto makers and whomever else. [not a lawyer,
don't know the precedent.]

It was established that I have the right to replace the bits of my car with
parts made by others.

This was ruled right and just even though the manufacturers had come up with all
sorts of ways to try to make that impossible. Special tools with odd patents.
Screw drivers that nobody else was allowed to make or own without paying a
danegeld. etc.

So here we have Sun ne Oracle saying that When Apache made a drop in replacement
for some parts inside of the Java runtime they did something impermissible. If
these things were called "java.carburetor",
"java.transmission", or "java.breaks" and were being sold at
Autozone instead of given away at Google, how obvious do you think the
"correct and just" outcome would be.

Oracle's "Google has no right to put the oil filter on the engine block,
they could have put it in the turnk" argument is just plain stupid.

The interfaces, once well established, are not smart to change. Nobody is going
to expect the dipstick to be under the gas cap.

Now java as a language is about as different from C++, as My Toyota is from my
Ford.

The car makers tried to patent, obscure, and encumber the various interfaces on
their products. They rightly failed. Among other things it was pretty obvious,
when you took off a timing belt, what the "timing belt interface" was
and how to make a timing belt of your very own.

So Oracle has pointed at a windshield glass, a fan belt, a radiator cap and a
few other things that every car has and said nobody else has a right to make
these things for -OUR- car because we said so. Okay, we didn't mention it at the
time but we were thinking it real hard now that we look back on it. And we said
so because we didn't want the market in parts for our car to
"fragment".

Duh.

But see, java.lang.math or whatever is just C's "math.h" just like
Toyota's radiator cap is just a slightly resized version of every other (modern)
radiator cap on the planet.

If computer stuff is "patentable as a machine" then these are just the
interchangeable parts of that machine and we -already- have precedent that says
that no matter what games you play with the documentation and the tooling you
are -not- allowed to (successfully) sue people for making interchangeable parts
just to keep them out of your market.

[ Reply to This | # ]

The 'Thank You' Thread
Authored by: Ian Al on Thursday, April 26 2012 @ 04:11 AM EDT
I cannot say this often enough. This is a wonderful reporting job.

Try not to make the court reporter feel inadequate.

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

[ Reply to This | # ]

Bouncy Castle and yet another smoking gun against Oracle
Authored by: bugstomper on Thursday, April 26 2012 @ 05:01 AM EDT
Curious about Bouncy Castle (mentioned by both Andy Rubin and Dan Bornstein in their testimony) and browsing around, I found this documentation from Sun about JDK 1.4. To provide some context, the article is about use of the encryption algorithm AES (Advanced Encryption Standard) in the JDK 1.4. In versions before JDK 1.4 encryption was done using JCE (Java Cryptography Extension), a separate class library with its own API, which did not contain an implementation of AES. The JCE was in packages under javax.crypto, which includes three of the 37 packages in Oracle's claims.

As of JDK 1.4, the JCE packages and classes were included with the JDK. The API remained the same, but became part of the set of APIs that were shipped with the JDK. The API was unchanged, still in the javax.crypto.* packages. (Note that I am using the term "API" correctly. I am not saying that the class library did not change. I am saying that the API, which means how the packages, classes, and methods are named and used, did not change). Implementations of AES were added to go with the other JCE classes. This article is about using AES in various Java technologies, including use in JDK 1.4.

Using AES with Java Technology

That is on the java.sun.com web site which I have trouble accessing sometimes, especially from outside the US. Here is the page as archived on webcite.org unless Oracle takes action to have it removed.

Using AES with Java Technology

A quote from that page:

The AES standard has been incorporated into several Java technology offerings. Beginning with the Java 2 SDK, Standard Edition (J2SE) v 1.4.0, the Java Cryptography Extension (JCE) was integrated with the SDK and the JRE. Since then, it has no longer been necessary to install the JCE optional package, since support for strong cryptography is now available as part of J2SE. JCE has a provider architecture that enables different providers to be plugged in under a common framework.

Several providers have supported AES in their own clean-room implementations of JCE, or under the existing framework. In Java 2 Platform, Standard Edition v 1.4.2, which is currently under beta, the Sun Provider, referred to as SunJCE, supports AES. Also, the Java Secure Socket Extension (JSSE) supports AES via JCE.

Bouncy Castle is one of the "several providers" referred to in that quote. Bouncy Castle is an Open Source clean-room implementation of the JCE begun in 2000, and provides a free implementation of AES. I don't find the incorporated JCE in the JDK 1.4 sources that I can get now, but the AES in OpenJDK 6 comes from another, older, clean-room open source implementation of the JCE called Cryptix, which was released under a BSD license.

The significance of the above quote is that it is Sun in 2003 writing positively about people providing clean-room implementations of the JCE API, now one of the API components of the Java Class Libraries, copying the SSO of 3 of the 37 packages-in-suit.

I have not yet looked at the source code in Android in the javax.crypto.* packages to see which files were copied from Bouncy Castle. I would expect it to be most of them. Why should Google bother to duplicate the effort of the excellent work that Bouncy Castle already did to implement the classes in those packages? Once again, just like with Apache Harmony, there is Google accused of copying the SSO of the API when what they did was copy code that is under an Apache License, code that Sun knew about and did nothing to stop.

Google's case is even stronger with Bouncy Castle than with the packages that were copied from APache Harmony. There was no issue regarding TCK for Bouncy Castle, or field of use restrictions. Sun knew about "several providers" with "their own clean-room implementations of JCE". In fact they even used one of them, cryptix, when they needed to get an AES class to use in the JDK's version of JCE. They knew about them and they wrote about them and did not sue over their use of the SSO of JCE.

[ Reply to This | # ]

Is the need for compatibility part of fair use?
Authored by: lwoggardner on Thursday, April 26 2012 @ 05:25 AM EDT
Dan Bornstein: Method or class? Let's talk abut java.lang.math.max
Dan Bornstein: The java.lang.math would have to be there.
Dan Bornstein: it's not just a matter of comfort… lots of pre-written source code that we'd like to be able to run on Android.

ie Google's argument is that they wanted other people to be able to use their own existing Java code on Android and to do so android needed to provide implementations compatible with, and hence almost identical too, the java.* and javax.* APIs

A question that has been puzzling me is whether this is an argument for fair use, or does it go to the issue of copyrightability. ie is this argument for the jury or the judge?

[ Reply to This | # ]

It's all your fault
Authored by: Ian Al on Thursday, April 26 2012 @ 05:32 AM EDT
You let me bang on for over a year thinking that collection and compilation were synonymous in the eyes of the law.

Let me rephrase my point. The Java registrations were for a collection in the same way that the RedHat and Ubuntu registrations were for a collection. You are not permitted, under the copyright law for registered collections, to substantially copy the whole collection without a licence.

Any individual item within the collection is only protected by the copyright of the individual item. You can protect the creative expression fixated in the medium of that single item if you own the copyright of that single item.

The Java SE V5 API Specification as it is shown to us, the community and to this very court is not a single document.

Oracle showed a comparison between two web pages, one purporting to be a single html document (from a whole slew of individual html documents with their own individual copyright marking and not protected as a group by the Java SE V5 registration of a collection) from the series of documents that Oracle say is not to be considered as a compilation and is something to do with the Java API Specification. The other html document was a similar one from the Android site. We don't have to worry about that one. It is available under the Apache licence.

The only rights that Oracle have to the html document they displayed in court is for the SSO and other creative expression fixated into that single document. Any abstract ideas within that document that relate to other ideas in another document of which they own the copyright is not protected.

The 37 packages are not a single document. They are not a whole work. In fact, an analysis ( What's in a name? whats in an SSO? , towards the end) from a couple of stories back showed that the 37 packages cannot be seen as a single sub-organisation from within the 160+. They look like a pile of bits of branches copied from a tree.

The Java API Specification is not a single document like a book. Oracle say it is not a compilation. Therefore the 160+ packages are not a whole work. The Java SE5 API Specification is not registered as a collection at the USPTO. Any SSO of a library of documents is unprotectable by copyright law. Only if that library collection copyright is registered as a whole work might some modest protection be possible. Possibly.

You cannot post a copyright warning at the entrance to a library saying that access to the Science Section is permitted, with the licence restrictions that,

1) You are not permitted to make an atomic bomb using information drawn from a selection of the books in the section.

2) You are not permitted to publish a list of the tomes giving the title, the author, the ISBN, the shelf, the row and the section in which the tome is to be found.

You cannot enforce those usage and SSO licence conditions anywhere in the world, using copyright law.

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

[ Reply to This | # ]

We should be grateful...
Authored by: indyandy on Thursday, April 26 2012 @ 06:20 AM EDT
We should be grateful that when the Java Apis were being defined Unicode was not mature.

Imagine if all the methods were like this:

java™.lang.Math.max(a,b)

;-)

[ Reply to This | # ]

So Oracle has 2 Patents to go on and some very dodgy copyright claims.
Authored by: Anonymous on Thursday, April 26 2012 @ 07:00 AM EDT
Isen't this all just wonderful for Oracle?

They have 2 Patents left to go on, still having to prove
infringment. Google have lots of options to deal with that,
they may even already have a new version of their software
in the wings that works around those patents, who can know?

Oracles copyright claims are very dodgy, not sure yet what:
"Section 103b, compilation copyright only covers the
collection as a whole, only if it comes from the same
author." ... is going to mean for Oracle. But its getting
very suspenseful, watching this. Possibly Oracle will little
more than 2 patents left to argue about and/or a lot more
proving of copyright ownership to do.

At any rate the SSO issue would likely go to appeal, the
judge has indicated this. I doubt the SSO argument has much
of a chance, because it certainly applies more to a novel or
a movie then to an API specification. I think Oracle got the
subject matter definately wrong on that argument.



[ Reply to This | # ]

Judge is literally prejeducing Google by intending to tell the jury SSO is copyrightable
Authored by: Anonymous on Thursday, April 26 2012 @ 07:45 AM EDT
IMO Google will be prejeduced, maybe severly prejeduced, if
he tells the Jury that SSO is copyrightable, when in fact he
has NOT ruled on this and it is far from certain if this is
really so.

If he told the jury that SSO is NOT copyrightable Oracle
would be screaming bloody prejeduce at the top of their
lungs for sure.

To be correct, shouldn't he just tell the jury the truth?
If I were a member of that Jury I would want him to be
straight with me, if I found out later that he told me
something that was not true, I think I would be very
irritated, and rightfully so.

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