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
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

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
Ooooooh! | 52 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
re: 702 patent - google statement?
Authored by: Anonymous on Monday, April 23 2012 @ 12:04 PM EDT
Ars is reporting that google have responded as follows: UPDATE: We received a statement from Google stating that "The USPTO ruling is on the prior art that was submitted at that time, not on the inherent validity of the patent itself. It is important to note that Judge [William] Alsup ordered the '702 patent dropped with prejudice from this case." The USPTO decision does note that the Oracle patent's claims "are confirmed over prior art presented in this reexamination." But Google can still argue at trial that patents are invalid and should not have been issued, even if claims made in the patents are confirmed as "patentable." (my emphasis)

does with prejudice mean Oracle cannot re assert it?

[ Reply to This | # ]

Corrections thread
Authored by: nsomos on Monday, April 23 2012 @ 12:17 PM EDT
Please post any corrections here.
A summary in title may be helpful.

[ Reply to This | # ]

Re: Harmony
Authored by: jvillain on Monday, April 23 2012 @ 12:32 PM EDT
In the second motion (959 [PDF; text to follow]) Oracle seeks a clarifying instruction to the jury regarding Apache Harmony. Specifically, Oracle asks that the jury be instructed that: (a) Apache never obtained a license from Sun permitting the use of the Java specifications; and (b) as a consequence, Apache had no rights to convey to Google.

Before the judge could buy into that wouldn't there have to be testimony from some one in the Apache group that they didn't have a licence? Maybe they think they do. No one has called any one from Apache yet unless I missed it. I am sure some one there would love to tell their story.

[ Reply to This | # ]

Off Topic Thread
Authored by: artp on Monday, April 23 2012 @ 12:38 PM EDT
Other than this topic of Weekend Filings.

---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?

[ Reply to This | # ]

News Picks Thread
Authored by: artp on Monday, April 23 2012 @ 12:44 PM EDT
URLs, please.

Even though new News Picks comments will tend to go on the
most recent story. Might as well finish the job. Sort of like
the Comes transcriptions, eh?

---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?

[ Reply to This | # ]

Comes Goes Here
Authored by: artp on Monday, April 23 2012 @ 12:47 PM EDT
For transcripts of those evil bitmapped court filings from
the "Comes v MS" link above.

If you are a rebel, and don't like authority, then put your
transcripts here instead of on the Comes thread on the most
recent story. Strike a blow for freedom! Okay, maybe just a
small pat for freedom.

---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?

[ Reply to This | # ]

Ooooooh!
Authored by: Ian Al on Monday, April 23 2012 @ 01:04 PM EDT
I wonder if this is on the judge's mind. He asked how many APIs were essential
to program in the Java language. Oracle replied that there was a small handful.

Now the judge is asking if that small handful, in turn, depends on a bigger
handful. Is he wondering if he will end up with his hands full of the entire API
Specification implementation, once all of the interdependencies are considered?

Or, perhaps, just 37 packages?

Personally, I would have gone with 42.

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

[ Reply to This | # ]

Oracle v. Google - More Weekend Filings - The Most Recent Briefs on Copyright Liability
Authored by: Anonymous on Monday, April 23 2012 @ 01:39 PM EDT
I am slowly getting annoyed by the apparent constant confusion of GPL with
public domain in the arguments here.

Sun licenced Java under the GPLv2. Google publishes the Java parts of Android
under the Apache license. If they copied parts that Sun licensed under GPLv2,
that did not, repeat not, entitle them to release them under the Apache
license.

So where is the point in making such a brouhaha about the GPLv2 release and
Oracle pointing to it? That does not imply a distribution license under
incompatible terms for Google.

If literal copying and rereleasing under the Apache license has happened, the
GPLv2 did not give permission for it.

[ Reply to This | # ]

This echoes SCOx's claims of a backdoor to UNIX
Authored by: Anonymous on Monday, April 23 2012 @ 01:40 PM EDT
Could the ex-SCOx lawyers really be copying their work products from the SCOx
case and reapplying them to the Oracle .vs. Google case? Maybe... All that legal
work down the drain. A new judge and a new case...

Really? APIs and ABIs are SCOx's backdoors to copyrighting UNIX. That turned out
to be a big flop!

For example, SCOx argued US common law permits function signatures like
"add(x, y);" in an API or ABI to be copyrighted. That way is insanity
because by reduction to absurdity US common law would be copyrighting specific
words in the context of all software. APIs and ABIs turned out to be standards
that SCOx could not claim copyright.

Programmers use APIs to communicate via files with other programmers and also
with running compilers. Plugging your software into other people's software so
they run together is a big problem, and APIs/ABIs efficiently describe the
standard public plugs.

Perhaps US common law should instead distinguish static source or binary code on
one hand from running live code on the other hand. Then it appears obvious that
APIs and ABIs are necessary to the structure, function, and processes that all
programmers control. It also appears obvious that no API or ABI could be
copyrighted or patented as isolated artifacts. Instead, protect the API/ABI
referenced library (aka framework), driver, utility, OS, or VM.

Further, I suggest that US common law define the purposes of programmer,
compiler, program, library, kernel, driver, virtual machine, operating system,
linker, loader, and OS utility. This could keep foolish lawyers out of tar pits.
Judges would be protected from specious arguments by foolish lawyers.

[ Reply to This | # ]

Oracle v. Google - More Weekend Filings - The Most Recent Briefs on Copyright Liability
Authored by: tknarr on Monday, April 23 2012 @ 01:52 PM EDT
What efficiencies, if any, are obtained by grouping methods or fields together under a single class? Put differently, what would be lost if a method that returned the cosine of an angle was grouped under a class other than Math? This discussion should get the pros and cons of the particular interrelationships (e.g., inheritance) within the 37 API packages.

When the judge asks this, the answer has two parts.

When the original creator goes to assign classes, the answer is "Little or none.". Whatever package the class goes into, it doesn't make a lot of different what the package name is. At most if you place it in a package with a lot of other stuff you pull everything else in that package in along with the cosine function, plus everything all that other stuff needs, and that whole combination may be more than developers want. You don't want your program to fail because you don't have an XML parser configured just because you want the cosine function and it's in the same package as the XML parsing. But that basically amounts to "Group related stuff together, and don't mix it with unrelated stuff.". The exact names don't matter, only the grouping.

But once the original creator's laid down the grouping and assigned package names, anybody else wanting to provide their own implementation of that API must use exactly the same package structure and class names and place everything exactly where the original creator did. It's like a window: when you build the house you can make the windows any size you want, but once the house is built if you go to replace a window you must use exactly the same size window as originally used otherwise your replacement window won't fit in the hole in the wall. If you don't use the same name, user code written using that same name won't see your different name and will fail to compile. If you don't place your stuff in the same packages, code written to import the original packages won't import yours (or won't import all the right ones) and will fail to compile. Where the original creator had flexibility, you're constrained to follow his choices if you want to expose exactly the same interface to users. And if you don't expose exactly the same interface, user code won't compile against your implementation.

The question is, if someone else has created an API then do you have a right to create your own implementation of that API without needing permission from the creator? This is the question Oracle wants to dodge, because all the case law from the seminal IBM BIOS and Lotus 123 menu interface cases says "Yes you can. You just can't copy their code itself.". And that's fatal to Oracle's case.

[ Reply to This | # ]

Grouping methods or fields
Authored by: Anonymous on Monday, April 23 2012 @ 01:57 PM EDT
What efficiencies, if any, are obtained by grouping methods or fields together under a single class? Put differently, what would be lost if a method that returned the cosine of an angle was grouped under a class other than Math? This discussion should get the pros and cons of the particular interrelationships (e.g., inheritance) within the 37 API packages.
Quite frankly, the original order is not quite clear with regard to what he is looking for. Is he looking for relationships in the "specifications" or in the "implementation." This distinction (specification vs. implementation) will likely continue to plague this trial.

Sounds as if he is trying to find out how much of the design is predetermined when designing an API.

The problem is that "System.math" have been used as the standard example all along for simplicity and that class is quite special in that it is static (and all its methods and fields are static). I guess the Judge really want to be a Java programmer before this case ends :) Normally you make instances (i.e. object) of a class and the normal primary reason to "[group] methods or fields together under a single class" is not "efficiencies" but rather "information hiding", i.e. that only the methods that need access to the private data (i.e. fields only accessible to the methods in that class) are placed on the class.

But the discussion about if API design is hard or not (it is), or creative or not (it is), or if the API could have been designed another way (it could) is rather irrelevant. Google didn't want to design a new API and they haven't claimed that they have tried, they wanted the Java API since that is what would be familiar to Java programmers. Therefore, they were forced (by their own desire for familiarity) to use the (subset) of the Java API (warts and all).

AH

[ Reply to This | # ]

What would be lost?
Authored by: DannyB on Monday, April 23 2012 @ 02:41 PM EDT
> what would be lost if a method that returned
> the cosine of an angle was grouped under a class
> other than Math?


Compatibility.

That is what would be lost. Every piece of software that had ever been written
to assume the cos() function was under Math would now be broken and non
functional. An "asteroids" game for example (which uses
rectangular/polar conversions, and therefore Math.cos).





---
The price of freedom is eternal litigation.

[ Reply to This | # ]

How does the Classpath exception to GPL v.2 figure into this case?
Authored by: eachus on Monday, April 23 2012 @ 02:49 PM EDT
Speaking as a compiler guru not as a copyright lawyer, the intent of the classpath exception is to allow programmers to use the classes covered in their programs without having to issue their work under the GPL. It seems to me that using the classes requires using the APIs in their source code. In other words, even if some sort of copyright could stick to the APIs, the GPL classpath exception seems to wash all contamination from using the APIs.

What about re-implementing the classes? It would be perverse to say that you can freely use the APIs, and their implementations, but you can't re-implement them. The law can, of course, be perverse, but to the extent that this case is writing (and must write) new law* in this area, it would be nice to have "free to use" mean free to use when it comes to implementing compilers for languages.

Why? When implementing a compiler, interpreter, or virtual machine for a programming language, it is common to write in the language being implemented. This limits the number of language contexts you need to hold in your head. My wife used to complain, if she called me at work, I could be thinking in three languages--none of which was English. ;-)

* Yes, new law. 90% or maybe 99% of this case could be decided based on existing law. If the court holds that APIs are not subject to copyright, then this case might just determine what a Java API consists of. (Of course, IMNSHO if the court decides otherwise, this case will drag out longer than the SCO saga.)

[ Reply to This | # ]

Google on substantial similarity of APIs
Authored by: SLi on Monday, April 23 2012 @ 04:13 PM EDT

In [955, page 2]. This is related to the definitions on APIs. I think if we took PJ's friend's definition for API, what Google says here would be nonsense; the signatures (including the packages, all the SSO) are identical, therefore the APIs are identical. I actually agree with Google says here.

But the selection and arrangement of APIs elements cannot, standing alone, support a copyright infringement verdict. If, for the 37 APIs at issue, Google had substituted APIs that had exactly the same structure, selection and organization as the Oracle APIs, but that did different things, the resulting work as a whole would not be substantially similar. For example, if every method always returned the same result, regardless of what inputs were provided (e.g., a zero for methods with numerical results, an “a” for those that return strings, “true” for those that return true or false, and so on), the resulting APIs would not be substantially similar, notwithstanding having precisely the same structure, selection and organization as Oracle’s APIs. The true premise of Oracle’s claim is that the Google APIs do the same thing that

The point to get is that API is not merely the signatures; it's also the "contract" or the understanding of what the methods actually do. Even if you keep all the signatures identical, but change the outward behavior, you are breaking the API.

Using the old car analogy, if you changed the order of the pedals, or changed the steering wheel so that when you turn it left, the car turns right and vice versa, you are changing the API even if the method signatures (the appearances of the pedals and the steering wheel) are identical.

For my explanation of what an API is, where I draw from Wikipedia and explain this too, see this comment. Essentially, the API is the signatures + the understanding of how the methods should be used (but see the above comment for elaboration).

[ Reply to This | # ]

Funny definition of "copyrighted work" from Google
Authored by: SLi on Monday, April 23 2012 @ 04:41 PM EDT

From Google's brief (955):

Because of the registration requirement, only “copyrighted works”—i.e., works in which the owner’s copyright claim has been registered—can be the subject of a claim of infringement. The Act uses the phrase “copyrighted works” throughout section 106—which defines the exclusive rights of the owner of a “copyrighted work”—and in other sections, including section 107, which provides that the fair use of a copyrighted work is not an infringement. 17 U.S.C. §§ 106, 107.

I don't actually think the Copyright Act supports the notion that only a registered work is a "copyrighted work".

[ Reply to This | # ]

Oracle v. Google - More Weekend Filings - The Most Recent Briefs on Copyright Liability
Authored by: xtifr on Monday, April 23 2012 @ 04:48 PM EDT

I'll take a stab at the good judge's questions.

1. The question is ambiguous. An API is just a set of names, and none of the names "call upon" other names. However, Sun's implementation of the APIs definitely includes procedures that use the API. It's impossible to write any useful program in Java without calling some of the API, and Sun's implementation of the API consists of small Java programs (subroutines).

2. Once again, if we're talking about the accused APIs themselves, the answer is no, since the APIs don't call anything. For the implementation behind the APIs, the answer is almost certainly yes in most cases, since most of the APIs refer to well-known algorithms whose most efficient implementation is a matter of general computer science. The implementation of the same algorithms in other languages like C++ almost certainly use the equivalent APIs in those languages in more-or-less the same way. This is a functional requirement, not a creative one.

3. Ok, here I'm reduced to guessing, but if the 37 APIs in question can stand alone (as they do in Android), then there's probably no functional requirements for any other APIs there, so the answer is probably not.

Bonus question: no efficiencies are gained or lost by the arbitrary choice of a name. In the case of a class or procedure, the name is purely arbitrary, and there is no functional different between science.sqrt and math.square_root, except that programs expecting to find math.sqrt would not locate either one.

There is a practical limitation on the names, though. Methods of a class must be part of that class. For example, if you have a list class called Collections.List, which has methods called append, search, and truncate, the names of those methods must start with Collections.List, so that when you have an instance of a list, e.g. a list named "lawyers", you can say "lawyers.append("Michael Jacobs")", and the compiler will know which method to use by referring to the class of the object "lawyers".

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

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