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
Amicus Brief - suggest Oracle v. Google | 245 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Amicus Brief - suggest Oracle v. Google
Authored by: Steve Martin on Thursday, May 16 2013 @ 01:02 PM EDT

Thus Google's reply brief must therefore appear any day now.

According to PACER, Google's brief is due May 23.

---
"When I say something, I put my name next to it." -- Isaac Jaffe, "Sports Night"

[ Reply to This | Parent | # ]

Amicus Brief - suggest Oracle v. Google
Authored by: PJ on Thursday, May 16 2013 @ 02:44 PM EDT
I'm not sure what the deadlines are. I'll check.

But if anyone feels like fleshing this out into
actual draft of the section explaining this,
feel free, in case it's not too late.

[ Reply to This | Parent | # ]

An idea for potential inclusion in an amicus brief
Authored by: macliam on Thursday, May 16 2013 @ 04:18 PM EDT

Logging an idea that occurred to me some months ago.

On page 56 of the Oracle brief, they give an example of a method signature involving a lot of words, apparently to impress the Federal Circuit judges with regard to the amount of ‘creativity’ inherent in such method signatures:

public abstract void verify(PublicKey key, String sigProvider)
   throws CertificateException, NoSuchAlgorithmException,
   InvalidKeyException, NoSuchProviderException,
   SignatureException

I wonder whether such legal briefs are written by lawyers with little or no understanding of the subject matter of their briefs.

Assuming that Google do not pick up on this in their reply brief and deal with it thoroughly, an amicus brief might explain the significance and implications of using such a method signature. I do not program in Java. Nevertheless I understand that CertificateException etc. are examples of exceptions. Any method that throws exceptions must declare the exceptions that it throws. Moreover any Java program that calls the method (in order to verify a cryptographic key) is required either to ‘catch’ these declared exceptions, or else the calling method must declare that it throws the exceptions that it doesn't catch. Thus the list of exceptions is functional and necessary for interoperability. If one wrote application code that called the Java class, and caught the exceptions declared above, and if one wished to write a replacement for the Java class for some other virtual machine, but written in the Java language, and implementing the same requirements with regard to catching and throwing exceptions, then the replacement code must also throw the exceptions that share the same names. The only genuine variability would be in the precise order in which the exceptions were declared. (One might, for example, list InvalidKeyException before CertificateException.)

The sequence of words ‘public abstract void’, in that order, is functional, not expressive. And given that the applications program is going to make use of a PublicKey class, any interoperable replacement is required to accept a first argument belonging to a class called PublicKey.

These are the requirements of the Java language that make most of the features of the method signature quoted above functional, not expressive.

Of course programmers could express and explain the above far better than I could.

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