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
Question 4 has a hidden bombshell | 451 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here
Authored by: feldegast on Thursday, May 03 2012 @ 06:33 PM EDT
So they can be fixed

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

News picks
Authored by: feldegast on Thursday, May 03 2012 @ 06:34 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 | # ]

Thanks EU for acting in parallel
Authored by: IMANAL_TOO on Thursday, May 03 2012 @ 06:34 PM EDT
It is always good to hear the other side, isn't it? To begin with.

And this Judge has done so.

My guess is that this jury's opinion will be less important over the next few
days, whatever their next verdict may be.

The legal text from the... other side, probably have some weight here.



---
______
IMANAL


.

[ Reply to This | # ]

Off topic
Authored by: feldegast on Thursday, May 03 2012 @ 06:34 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 | # ]

Comes transcribing
Authored by: feldegast on Thursday, May 03 2012 @ 06:35 PM EDT
Thank you for your support

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

No fleas
Authored by: Anonymous on Thursday, May 03 2012 @ 06:36 PM EDT
... on this judge. He wants to know in detail (with references) why the 9th
Circuit should end up with a diametrically opposed decision to the top European
court on API copyrightability.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj
Authored by: ThrPilgrim on Thursday, May 03 2012 @ 06:36 PM EDT
The Judge may well be struggling, but that is a set of very intelligent
questions.

---
Beware of him who would deny you access to information for in his heart he
considers himself your master.

[ Reply to This | # ]

Tweets from the courtroom
Authored by: feldegast on Thursday, May 03 2012 @ 06:36 PM EDT
https://twitter.com/#!/Feldegast

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

#7
Authored by: Anonymous on Thursday, May 03 2012 @ 06:37 PM EDT
With regard to #7: If you intend to have any kind of GUI, odds are you'll be referencing java.awt or javax.swing. Applets require the aptly named java.applet. Several things that Java is regularly used for require more than lang, io, and util. Also, I find the title of this interesting: http://docs.oracle.com/javase/6/docs/api/ It's labelled in the singular - a specification for the API. How did Google's lawyers not hit Oracle over the head with this? (Surely somebody at Google has referenced this before?)

[ Reply to This | # ]

  • #7 - java.awt and java.swing - Authored by: Anonymous on Thursday, May 03 2012 @ 08:35 PM EDT
  • #7 - Authored by: Anonymous on Thursday, May 03 2012 @ 10:07 PM EDT
  • #7 - Authored by: Anonymous on Friday, May 04 2012 @ 11:00 AM EDT
    • #7 - Authored by: Anonymous on Friday, May 04 2012 @ 11:48 AM EDT
Judge won't rule on copyrightability for another 11 days?
Authored by: Anonymous on Thursday, May 03 2012 @ 06:49 PM EDT
So, if briefs are due on the 10th of May, and replies on the 14th, this
indicates no prompt decision on copyrightability, correct?

[ Reply to This | # ]

Indications of hung jury - from twitter
Authored by: Anonymous on Thursday, May 03 2012 @ 06:51 PM EDT
James Niccolai @jniccolai

Jury question: "What happens if we cant reach a unanimous decision and
people are not budging" Uh-oh

[ Reply to This | # ]

java 1.0 in 1996
Authored by: Anonymous on Thursday, May 03 2012 @ 06:58 PM EDT
http://web.mit.edu/java_v1.0.2/

[ Reply to This | # ]

My answers
Authored by: wharris on Thursday, May 03 2012 @ 06:59 PM EDT
3. If the format of the name is dictated by the Java programming rules, then is the form of “java.package.class.method” required by the syntax of the language itself?

Yes.. If a system claims to allow Java syntax, then particularly named functions must be located in particularly named packages.

4. Could Google have come up with different names and SSO yet still have provided the same functionality as in Android?

What is meant by "functionality?" If "functionality" means an open source touch-interface SmartPhone, the answer is yes. For example, the iOS (iPhone) does not use Java. On the other hand, if Google defines "functionality" to include the ability to run Java programs, then those programs must use the Java API.

6. Is it agreed that the following is true, at least as of 1996? The following were the core Java Application Programming Interface: java.lang, java.util and java.io.

I'm going to assume that the lawyers have had extensive discussion on what is meant by the "core" API. There is nothing in the documentation I have read that distinguishes those three as being different from the Abtract Window Toolkit (java.awt), java.math, java.net, java.security, ...

7. Does the Java programming language refer to or require any method, class or package outside the above three?

Yes. Even the earliest version of Java I studied (1.2 I think) had more than those three packages listed in official documentation as part of the Java API. For example, see here.

8 . To what extent do subparts of the above three Java packages refer to any other Java packages or subpart of other packages (meaning outside the three)?

I'll defer to someone with more Java guru skills than I, but I believe that parts of java.lang refer to java.math, which I think is a pretty fundamental package. I would also expect all of the following to be important packages in Java, but I don't know if anything in the three named packages refer to them: java.applet, java.awt, java.beans

[ Reply to This | # ]

Destroying an entire field
Authored by: pem on Thursday, May 03 2012 @ 07:03 PM EDT
PJ:

As for the ADA case, it seems to indicate that the judge still doesn't understand that while you can copyright and protect items in a book or a manual without destroying an entire field, if you do identical protection with computers, you can disrupt and destroy software development as it's normally practiced.

Umm, yeah.

Without creating yet another stupid API analogy, let me expound on one that's been kicking around for awhile.

If the API is like the steering wheel, brake, accelerator, clutch, etc. arrangement on the car, if you change the API, now you have two problems:

  1. You have the same problem as with cars. Namely, lots of humans running around who know how to drive one brand (which, not coincidentally, is heavily based on lots of older brands of cars) who have to relearn how to drive another brand.
  2. In addition, you have the problem that there are a lot of robots out there (e.g., in the case of Java, preexisting programs) which know how to drive one brand of car. Now, some poor human schmuck has to go and reprogram all those robots to know how to drive the new brand of car with the different API. Worse, if a programmer automates the task of updating the robots by writing a translation program, he has also violated the old API in that he has now written something smart enough to understand what it means and smart enough to translate that to the new API.

So, from a practical perspective, there are certainly two issues that argue fair use: (1) making all the programmers out there learn a new arrangement of functions for no good reason; and (2) punishing those who have written programs which use Java if they want to run those same programs on Android.

I would seriously be interested in arguments that Oracle's protection of the APIs from Google's reimplementation wouldn't adversely affect anybody who wrote any kind of translation from Java to some other language. Heck, I'd even be seriously interested in arguments that Oracle's protection of the APIs didn't mean they couldn't go after any application programmer who ever wrote anything in Java and didn't give them money.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj
Authored by: Anonymous on Thursday, May 03 2012 @ 07:04 PM EDT
java.math
java.sql
java.security
java.net

are all indispensable.

[ Reply to This | # ]

Don't you wish the Hon. (and most estimable) Judge Alsop had presided over SCO v IBM/Novell?
Authored by: Anonymous on Thursday, May 03 2012 @ 07:10 PM EDT
This is how the law should work - not like the decade-long three ring circus of
the SCO trials.

Nothing is getting past him - including locking out as many options as possible
for the inevitable appeal as he goes along.

And he's got a sense of humour.

If there were more judges like this guy then the US legal system wouldn't be
even half as broke as it is.

[ Reply to This | # ]

I'd say java.net was also core.
Authored by: Cassandra on Thursday, May 03 2012 @ 07:13 PM EDT
java.net contains the basic networking abstractions, so I'd say that it's as "core" to Java as "socket.h" is "core" to C.

However, I'm not convinced that java.net is a good API, or else why would java.nio have been added later? And that's been bothering me: Oracle has testified how difficult writing a good API is, but has anyone actually testified that all of the 37 Java's APIs are good?

[ Reply to This | # ]

Here's my stab at answering some easy ones
Authored by: xtifr on Thursday, May 03 2012 @ 07:21 PM EDT
3. Yes, the form is dictated by the language. (Although it should be noted that
the "java" in the example is just a package name.) Methods are part
of classes, and classes are parts of packages, so any API must be in the form
package{.package...}.class{.class...}.method, where the braces indicate elements
that can be repeated zero or more times. [note 1]

4. Google could have come up with new names. No idea about Spring.

5. No, that would constitute a copyright on an abstract idea.

10. None, if the arguments and return value of a method are considered to be
part of the interface (which they are). The name/declaration level tells you
only how the interface is accessed--the name, arguments, and return value--and
the arguments and return value are simply names of other classes. There is no
dependency in the interface on the implementation of the argument classes or
return value class. It all boils down to names and references to names.

13. "Compatibility" in this context refers both to the programmers and
existing programs. The TCK, VM and compiler are not factors. I have no idea
what percentage of Java programs are compatible with Android, and I doubt anyone
else does either, since many (most?) Java programs are private and proprietary.

[note 1]: I'm don't remember whether Java actually supports nested classes. I'm
more familiar with C++, which definitely does. It isn't really relevant to my
argument either way, though.

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

[ Reply to This | # ]

Jury Deadlock
Authored by: Anonymous on Thursday, May 03 2012 @ 07:22 PM EDT
So it seems that the jurors are deadlock and Judge Alsup said
he would move to the patent phase. Quick question - my
understanding is that if jury had a verdict in Oracle's favor,
Judge Alsup would decide if APIs are copyrightable. What if
the jury doesn't come with any verdict? Could Judge Alsup
decide if APIs are copyrightable? This is the most essential
question to the copyright trial phase. He has heard all the
evidence. Why does he need a verdict in Oracle's favor to
make such a determination?

[ Reply to This | # ]

Java questions and answers
Authored by: iksrazal on Thursday, May 03 2012 @ 07:33 PM EDT
6) I think it'd be universally agreed that if you were to pick the 3 most
important Java packages, java.lang, java.util and java.io would be the ones. I'd
say 99.99% of all java programs use those 3.

7) This is sort of trick question. There's the language that defines the syntax,
such as "String myString = "hello world" , but String is not only
arguably the most common class used, it also has special behavior unlike other
classes: immutability. Strings are constant; their values cannot be changed
after they are created. Therefore its so much part of the language that it'd be
impossible to learn Java without learning the String class, for example.

Anyways, even the String class uses nio (see below), such as the return of
charset here:

http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#String%28byte[],%
20int,%20int,%20java.nio.charset.Charset%29

8) Absolutely they reference other packages, a lot. For example, the following
link shows a method in the most core of all classes, System, using the nio
package as the return argument for the Channel class. nio came out in 2002 or so
under the JCP, ie, developed by committee:

http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#inheritedChannel%
28%29

[ Reply to This | # ]

  • Immutability - Authored by: Anonymous on Friday, May 04 2012 @ 09:26 AM EDT
Question 11-B
Authored by: ShineOn on Thursday, May 03 2012 @ 07:38 PM EDT
The answer seems obvious to me.

The reason the taxonomy of a butterfly and the
structure and sequence of a dental procedure coding are different from the
structure, sequence and organization of API specifications is they are arrived
at in very different ways, and have very different interdependencies.

The
taxonomy of a butterfly or the structure and sequence of dental procedure coding
are the result of an attepmt to classify something that's there already, for
one. You don't start with the taxonomy to show the butterfly how to flap its
wings. You don't start with the dental procedure insurance code to show the
dentist how to set a crown.

However, you do start with the API specification
to show a program how to interface with the system.

The structure, sequence
and organization of API specifications are inextricable from the API, part of
the whole package, part of the "work as a whole." It is not simply descriptive
of an API, but is part of the API, without which the API is incomplete.

You
don't find an API somewhere and try to classify its specifications by coming up
with a structure, sequence and organization in a taxonomic fashion.

The
butterfly works just fine without anyone knowing the taxonomy of a butterfly.
The dental procedures themselves work just fine without the coding of procedures
for insurance purposes.

You can't use an API without the specifications which
require the SSO to be what it is in order to be usable.

It's even more
different than apples and oranges - it's more like apples and trombones. Any
similarities are far outstripped by the differences. Apples and trombones are
both shiny - so what? That should be the same answer to B - they both have some
sort of structure - so what?

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj
Authored by: Anonymous on Thursday, May 03 2012 @ 07:42 PM EDT
I have a question for you Java guys. What would you answer to questions 6 through 8 particularly? I don't know about 1996, the year he asked about in question 6, but take a look at Oracle's OpenJDK page, about the Java core libraries, where I see the three APIs the judge mentioned, but are there more listed there? And does anyone have a definitive list of core Java APIs?"

List of Java5 apis which is subject to license that does not allow subset or superset in an independent implementation, see bottom of that link.

But I think the judge is asking what is required by the JLS, i.e. what is required for the language to run a program written in the language rather someone wanting to support the whole JavaSE platform. I think that is what he is trying to get at with the reference to Spring.

In that case, I think you will find lots of creep into other packages. e.g. java.lang.Class is required to run a program, it requires java.lang.ClassLoader which in turn references java.net.URL for methods like getResource()

So java.net is also required.

I know of a few similar requirements off the top of my head;
- java.lang.ClassLoader needs java.security.CodeSource so java.security is required
- java.lang.String needs java.nio.charset.Charset so java.nio is required

There are likely many others if you were to do a full analysis.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj
Authored by: Anonymous on Thursday, May 03 2012 @ 07:44 PM EDT
For question 4, perhaps it is a little too late, but someone really needs to
point out to the Judge that even Spring does use Java API or at least a subset
of it despite Ellison's claim.

[ Reply to This | # ]

4. Could Google have come up with different names and SSO yet still have provided the same funct
Authored by: Gringo_ on Thursday, May 03 2012 @ 07:45 PM EDT

4. Could Google have come up with different names and SSO yet still have provided the same functionality as in Android?

I choose to respond to this one, because on the surface it appears to be an easy question with a yes answer and therefore prejudicial to Google.

The answer is clearly yes, as I just stated above, but then you might have just as well asked if Google could have used an entirely different language, and the answer to that would be yes as well.

I contend that without the names and SSO it would be no longer Java, simple as that. Java is its libraries. Without them, it is nothing but C++. Not even that, because once stripped of its libraries, it is undefined. There would be no point in doing what the question suggests - write a different interface. Before you would consider that, you would simply go to another language, or invent your own starting from scratch.

[ Reply to This | # ]

Kapes
Authored by: Anonymous on Thursday, May 03 2012 @ 07:47 PM EDT
It seems to me that in Kapes, the judge decided that individual prices were
sufficiently original to merit copyright protection. In this case, the judge
has said that individual method signatures do not merit copyright protection.
If I were Google, I'd be highlighting that difference.

MSS2

[ Reply to This | # ]

#7 - Dependencies outside of 'core'
Authored by: gus_goose on Thursday, May 03 2012 @ 07:53 PM EDT
Java makes this sort of dependency searching relatively easy, you can check the
'import' statements to see where it gets its resources from.

Here are some of the interesting imports from classes in the java.lang.*
package:

Class
import java.security.AccessController;
import java.security.PrivilegedAction;

ClassLoader
import java.net.URL;
import java.security.*; // many different ones

String
import java.nio.charset.Charset;

System
import java.security.AccessController;
import java.security.PrivilegedAction;
import java.security.AllPermission;
import java.nio.channels.Channel;



From the java.io.* we have the following highlights:

File
import java.net.URI;
import java.net.URL;
import java.net.MalformedURLException;
import java.net.URISyntaxException;
import java.security.AccessController;
import java.security.AccessControlException;
import java.security.SecureRandom;



From the java.util.* the following stand out:

Calendar
import java.text.DateFormat;
import java.text.DateFormatSymbols;

Date
import java.text.DateFormat;

Formatter
import java.math.BigDecimal;
import java.math.BigInteger;
import java.math.MathContext;
import java.math.RoundingMode;
import java.nio.charset.Charset;
import java.text.DateFormatSymbols;
import java.text.DecimalFormat;
import java.text.DecimalFormatSymbols;
import java.text.NumberFormat;

Scanner
import java.util.regex.*;
import java.math.*;
import java.nio.*;
import java.nio.channels.*;
import java.nio.charset.*;
import java.text.*;


An interesting 'find' is the class XMLUtils.... which is a 'private' class in
java.util used to support the java.util.Properties class.....

here are the java.util.XMLUtil imports:

import java.io.*;
import org.xml.sax.*;
import org.xml.sax.helpers.*;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import javax.xml.transform.*;
import javax.xml.transform.dom.*;
import javax.xml.transform.stream.*;

There are many more java.util.*.* classes that I did not inspect.... ;-)

gus

[ Reply to This | # ]

Compatibility
Authored by: Anonymous on Thursday, May 03 2012 @ 07:53 PM EDT
What I find missing in the discussion here at Groklaw is a critical look at the
"need" for compatibility.

It is unquestionable that if I write a program for operating system A, that I
will need to use the API of operating system A. So my program needs to be
compatible in order to be functional and there is a very good case to be made
why I should be able to make reference to the API without the need for a
license.

But when I develop operating system B there is no inherent _need_ for operating
system B to be compatible with operating system A. The API provided by MacOS X
is not compatible with the API provided by Windows 7.

I can create a need, if I were to postulate that I want programs written for
operating system A to run on operating system B. Now one can make a convincing
argument under the merger doctrine that system B's re-use of the API that was
defined for system A is entirely driven by functional requirements, and that
therefor system B has only used elements of the system A's API for which idea
and expression have merged.

Google however seems to have come down in the middle.... they have reused some
APIs and not others. "We re-used the parts that we liked" doesn't look
like a very good defense to me.

[ Reply to This | # ]

  • Wrong - Authored by: pem on Thursday, May 03 2012 @ 07:58 PM EDT
  • Compatibility - Authored by: Anonymous on Thursday, May 03 2012 @ 08:16 PM EDT
  • Compatibility - Authored by: Anonymous on Thursday, May 03 2012 @ 11:25 PM EDT
  • IBM's Open32 - Authored by: Anonymous on Thursday, May 03 2012 @ 11:43 PM EDT
    • IBM's Open32 - Authored by: Anonymous on Friday, May 04 2012 @ 03:18 AM EDT
  • Compatibility - Authored by: Anonymous on Friday, May 04 2012 @ 01:43 AM EDT
  • Compatibility - Authored by: kuroshima on Friday, May 04 2012 @ 03:29 AM EDT
  • No - Authored by: Anonymous on Friday, May 04 2012 @ 04:42 AM EDT
    • No - Authored by: Anonymous on Friday, May 04 2012 @ 11:18 AM EDT
EU ruling seems to favor copyrighting "SSO"
Authored by: Anonymous on Thursday, May 03 2012 @ 07:53 PM EDT
This sounds like the EU said SSO is copyrightable:
"120. It is only through the choice, sequence and combination of such elements that the author may express his creativity in an original manner and achieve a result which is an intellectual creation."
I'm having trouble equating API with "functionality", which is what the EU ruling quoted talks about. As an example, "functionality" is something like "print a document in a given format", and an "API" is a set of methods that lets a program specify the document, format and other printer parameters. As such, the API is a means to provide and use functionality, not the functionality in itself.

I'm not seeing how the EU decision applies here, except to affirm that languages themselves are not copyrightable, which neither Oracle nor Google has claimed. I think the questions related to the packages are an effort to clarify where the Java language ends and where the API begins. For instance, if 3 of the packages in question are intrinsic to Java, the number of packages being infringed may drop from 37 to 34 (not a huge difference, but still...)

[ Reply to This | # ]

Sun's Core Java books volume 1 & 2 since 1998?
Authored by: Anonymous on Thursday, May 03 2012 @ 07:57 PM EDT
The judge is trying to hone in on what is the core of Java, and I would referrer
him to get copies of Sun Microsystems' official Core Java books (volumes 1 &
2) by Cay S. Horstmann and Gary Cornell, now in their 8th edition (about £40
each).

As any functionality explained within them is by Sun's own previous definition
“Core” to Java programmers.

What I'm really surprised that hasn't come up yet, is that the package and class
names in Java's API are actually just filesystem locations from the classpath
locations. Even though these classes are typically stored in a jar file(uses zip
file format), instead you could unzip the jar file to expand the package names
out, into folders (with the .class files). As each dot (in the package names) is
a folder separator from the classpaths root, eg /usr/java/lang/ or c:program
filessunjavalang

So given that all this talk of SSO is in fact just filenames and folder
locations, but obfuscated from view by zip files, I find it extremely hard to
believe that copyright extends to file and folder arrangements on computers.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj
Authored by: Anonymous on Thursday, May 03 2012 @ 08:10 PM EDT
The Java language specification contains direct references
to a number of classes. Without those the language could not
function. Here is a incomplete list of absolutely required
classes:

java.lang.{Object, Class, Byte, Char, Integer, Long, Float,
Double, String, Throwable, Error, Exception}

The {} notation is just shorthand to avoid repeating
"java.lang." in front of each of these.

There are more in the specification, but the above list is
of classes fundamental to the language. For example, every
class in Java inherits from java.lang.Object. Without Object
what you had could not be said to be even "Java like".

It would be possible to make an incomplete implementation of
say Object. If you want to implement the whole of it, you
will notice that Object has methods that has parameters,
return values and exceptions of other types:

java.lang.{Class, String, Cloneable,
CloneNotSupportedException, IllegalMonitorStateException,
InterruptedException, IllegalArgumentException, Throwable}

Now check each of these types for referenced types. The
first one, java.lang.Class, adds references to these types:

java.lang.{ClassLoader, Package, ClassNotFoundException,
LinkageError, ExceptionInInitializerError,
InstantiationException, IllegalAccessException,
SecurityException, NullPointerException,
TypeNotPresentException, NoSuchFieldException,
ClassCastException}
java.lang.reflect.{Constructor, Field, Method, Type,
TypeVariable}
java.lang.annotation.Annotation
java.security.ProtectionDomain
java.io.{Serializable, InputStream}
java.net.URL

Now in turn do each of those...

It would take a program to follow all the leads but it is
obvious that you will pull in a large amount of the full
API. And it won't be restricted to the three packages in the
judges question.

In fact it would probably pull in more packages than the 37
that Google used. I am not familiar with Android but
obviously Google did draw a line somewhere. They could do
this by simply marking some methods as "unimplemented" and
tell developers that this feature is not available on
Android.

[ Reply to This | # ]

Isn't it Oracle's burden to identify the SSO
Authored by: Anonymous on Thursday, May 03 2012 @ 08:17 PM EDT
I can't figure out what the SSO of an API is. We are all arguing about various
theories as to what this might be. It is very unclear what this nightmare jargon
hybrid actually means.

What is clear is that Oracle didn't explain this term properly else we wouldn't
be arguing about it. Wasn't it Oracle's burden to clearly identify what they
allege was copied? Did they do it? Having read a report of the testimony do you
think you now have a clear understanding of what the SSO of an API is?

[ Reply to This | # ]

Core Java packages
Authored by: hAckz0r on Thursday, May 03 2012 @ 08:19 PM EDT
By definition, any package that starts with "java.(anything)" should be considered part of the Java language. If it starts with "sun.(anything)" then it was a Sun reserved package. Oracle can have their packages, and Microsoft theirs, but those starting with java are exactly that. That is the package naming convention for a reason.

---
DRM - As a "solution", it solves the wrong problem; As a "technology" its only 'logically' infeasible.

[ Reply to This | # ]

Worrisome, but distingishable cases
Authored by: Anonymous on Thursday, May 03 2012 @ 08:22 PM EDT
Those cases cited are somewhat worrisome for Google, but I believe that they can
all be distinguished from precedent. I'm glad we have a smart judge who
displays some understanding of how Java works in his questions. But I see that
he might be confused on a few points, so hopefully that will get sorted out in
the briefs over this.

Yes, creating an API is a creative act, in that you have freedom in how to go
about it. But, unlike a butterfly taxonomy, it merges with the facts of how
actual programs communicate with each other. APIs describe rules for
communication between computer programs. The two programs interfacing via the
API cannot communicate with each other without speaking the same language and
using the same rules. A butterfly, like a rose, is the same no matter what name
you call it by. A Java program will return a "method not found" error
if you give the computer the wrong name for a method. In that regard, it is
more like a wall plug, where every device that wants electricity must have a
plug. While the original design of the wall outlet & plug may have been
creative, there simply isn't any way to get electricity without a compatible
plug. And the evidence shows that Google merely copied the wall plug, not the
whole device attached to it.

The coin prices are more troubling. But here, the answer to another question is
relevant. You see, the API is not the same as a whole program. Google could
and did create their own implementation of the APIs, except perhaps for that one
sorry rangecheck function and whatever other actual source code Oracle could
find, though I think all of that was put there by someone else. So the only
relevant part copied would be the purely functional elements required for
communication, not the actual parts that do all the work. That is to say that
they copied Oracle's electrical outlet so that people could plug things in, but
they did not copy the entire device attached to the plug.

I think others have commented on how the Java language treats the names, but
yes, they're organized like street addresses, in that they tell the computer
where to go looking for the implementation (which Google did not copy). So they
are dictated by the language itself. I don't know that there are actual
standards for "core" and "non core" areas, but it would be
very, very difficult to argue that the APIs listed were not core.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated
Authored by: PolR on Thursday, May 03 2012 @ 08:23 PM EDT
No 4:
> Could Google have come up with different names and SSO
> yet still have provided the same functionality as in
> Android? Android users would have had to learn a new
> vocabulary and a new outline but the methods would all
> still have been resident in such a modified Android.
> True?


Does compatibility count as functionality? Not all programs are written from
scratch. Some programs may be ported to Android from other platforms. If the
vocabulary is changed, these programs won't port without being rewritten.

Also, some programs are written to run on every platform, or at least as many
platforms as possible. This is the "write once run anywhere" feature
of Java. Does this count as functionality? Having a different vocabulary for
Android will definitely break this because Android programs won't run elsewhere
and Java programs won't run on Android. A consistent vocabulary is necessary for
compatibility.

[ Reply to This | # ]

Classes Referenced from The 3
Authored by: greed on Thursday, May 03 2012 @ 08:25 PM EDT

Based on the JDK 1.5.0 AMD64 Linux edition, using the 'rt.jar' package only, I analyzed all classes in the java.lang, java.io and java.util packages.

First, I listed all the classes in those packages with zipinfo:

zipinfo -1 rt.jar java/lang/* java/io/* java/util/* |
tr / . | sed -e 's/.class$//' |
while read CLASSNAME do stuff; done

Each class had its type signature dumped:

javap -s -classpath rt.jar $CLASSNAME

These signatures were then parsed by a quick-and-dirty Perl script I wrote--it looks for Signature: lines, pulls out the sequence Lpath; and turns path into a class name. The script also prints unique entries and omits entries in the 3 packages under examination.

A limitation of this process is, it cannot "see" what's going on inside methods. It can "see" argument and return types, but it cannot see classes that are used only inside a method.

Actually, maybe that's a feature. Only the types which make up the accessible API are found. I'm including "protected" methods, because those are accessible in sub-classes. (I didn't attempt to omit protected methods from "final" classes--those which cannot have subclasses.)

Lo, the references are:

  • java.beans.PropertyChangeListener
  • java.math.BigInteger
  • java.net.InetAddress
  • java.net.URI
  • java.net.URL
  • java.nio.ByteBuffer
  • java.nio.CharBuffer
  • java.nio.channels.ReadableByteChannel
  • java.nio.charset.Charset
  • java.nio.charset.CharsetDecoder
  • java.nio.charset.CharsetEncoder
  • java.security.AccessControlContext
  • java.security.CodeSigner
  • java.security.CodeSource
  • java.security.Permission
  • java.security.PrivilegedAction
  • java.security.PrivilegedExceptionAction
  • java.security.ProtectionDomain
  • java.security.cert.Certificate
  • javax.management.MBeanServerConnection
  • javax.management.openmbean.CompositeData
  • org.w3c.dom.Document
  • org.w3c.dom.Element
  • org.xml.sax.InputSource
  • org.xml.sax.SAXParseException
  • sun.io.ByteToCharConverter
  • sun.io.CharToByteConverter
  • sun.misc.Signal
  • sun.misc.Unsafe
  • sun.nio.ch.Interruptible
  • sun.reflect.ConstantPool
  • sun.reflect.ConstructorAccessor
  • sun.reflect.MethodAccessor
  • sun.reflect.annotation.AnnotationType
  • sun.security.util.ManifestEntryVerifier

This is direct references only. All of those classes may have further references to still more packages. In other words, this is just getting started: there--almost certainly--will be more. It's almost fractal: the closer you look, the more you see.

I will post the Perl script in a follow-up to this message so others can do the same analysis. Or hopefully something better.

[ Reply to This | # ]

Java Language Specification and API Core Libraries
Authored by: TJ on Thursday, May 03 2012 @ 08:31 PM EDT

The Java Language Specification, 2nd Edition, published in 2000 as part of the Java Community Process (JCP) Java Specification Request JSR-901 details the following (non-exhaustive) relationships between the Java Language and Core Libraries:

Introduction:

1.2 Notation
Throughout this book we refer to classes and interfaces drawn from the Java and Java 2 platforms. Whenever we refer to a class or interface which is not defined in an example in this book using a single identifier N, the intended reference is to the class or interface java.lang.N. We use the fully qualified name for classes from packages other than java.lang.
1.3 Relationship to Predefined Classes and Interfaces
As noted above, this specification often refers to classes of the Java and Java 2 platforms. In particular, some classes have a special relationship with the lan- guage. Examples include classes such as Object, Class, ClassLoader, String and Thread and the classes and interfaces in package java.lang.reflect among others. The language definition constrains the behavior of these classes and interfaces, but this document does not provide a complete specification for them. The reader is referred to other parts of the Java platform specification for such detailed API specifications.
The Java Language Specification provides very clear guidelines on how packages, classes, interfaces methods and fields should be named.
6.8.1 Package Names
Names of packages that are to be made widely available should be formed as described in §7.7. Such names are always qualified names whose first identifier consists of two or three lowercase letters that name an Internet domain, such as com, edu, gov, mil, net, org, or a two-letter ISO country code such as uk or jp. Here are examples of hypothetical unique names that might be formed under this convention:

com.JavaSoft.jag.Oak
org.npr.pledge.driver
uk. ac.city.rugby.game

Names of packages intended only for local use should have a first identifier that begins with a lowercase letter, but that first identifier specifically should not be the identifier java; package names that start with the identifier java are reserved by Sun for naming Java platform packages.
6.8.2 Class and Interface Type Names
Names of class types should be descriptive nouns or noun phrases, not overly long, in mixed case with the first letter of each word capitalized. For example:


ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

Likewise, names of interface types should be short and descriptive, not overly long, in mixed case with the first letter of each word capitalized. The name may be a descriptive noun or noun phrase, which is appropriate when an interface is used as if it were an abstract superclass, such as interfaces java.io.DataInput and java.io.DataOutput; or it may be an adjective describing a behavior, as for the interfaces java.lang.Runnable and java.lang.Cloneable.
6.8.3 Method Names
Method names should be verbs or verb phrases, in mixed case, with the first letter lowercase and the first letter of any subsequent words capitalized. Here are some additional specific conventions for method names:
• Methods to get and set an attribute that might be thought of as a variable V should be named getV and setV. An example is the methods getPriority and setPriority of class java.lang.Thread.
• A method that returns the length of something should be named length, as in class java.lang.String.
• A method that tests a boolean condition V about an object should be named isV.
An example is the method isInterrupted of class java.lang.Thread.
• A method that converts its object to a particular format F should be named toF.
Examples are the method toString of class java.lang.Object and the methods toLocaleString and toGMTString of class java.util.Date. Whenever possible and appropriate, basing the names of methods in a new class on names in an existing class that is similar, especially a class from the Java Application Programming Interface classes, will make it easier to use.
6.8.4 Field Names
Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized. Note that well-designed classes have very few public or protected fields, except for fields that are con- stants (final static fields) (§6.8.5). Fields should have names that are nouns, noun phrases, or abbreviations for nouns. Examples of this convention are the fields buf, pos, and count of the class java.io.ByteArrayInputStream and the field bytesTransferred of the class java.io.InterruptedIOException
6.8.5 Constant Names
• If a field name is hidden by a declaration of a parameter or local variable, then the name of the parameter or local variable can be changed without affecting other code.
The names of constants in interface types should be, and final variables of class types may conventionally be, a sequence of one or more words, acronyms, or abbreviations, all uppercase, with components separated by underscore “_” char- acters. Constant names should be descriptive and not unnecessarily abbreviated. Conventionally they may be any appropriate part of speech. Examples of names for constants include MIN_VALUE, MAX_VALUE, MIN_RADIX, and MAX_RADIX of the class java.lang.Character.
7.1 Package Members
The members of a package are subpackages and all the top level class (§8) and top level interface (§9) types declared in all the compilation units (§7.3) of the package.
For example, in the Java Application Programming Interface :
• The package java has subpackages awt, applet, io, lang, net, and util, but no compilation units.
• The package java.awt has a subpackage named image, as well as a number of compilation units containing declarations of class and interface types.

If the fully qualified name (§6.7) of a package is P, and Q is a subpackage of P, then P.Q is the fully qualified name of the subpackage.
7.1 goes on...
The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner,

[ Reply to This | # ]

Judge Alsup introduces Inquisitorial Justice
Authored by: Anonymous on Thursday, May 03 2012 @ 08:39 PM EDT
If the parties won't introduce sufficient evidence to settle the case,
then by golly he'll drag it out of them.

[ Reply to This | # ]

Java core APIs according to Sun: all of it!
Authored by: jbb on Thursday, May 03 2012 @ 08:42 PM EDT
Current Page: Java SE Core Technologies

Archived Page: Java SE Core Technologies (from 2007)

There is no specific list on either page but there are plenty of links. The links seem to go to a very large number of APIs. Why did Sun include such a multitude of APIs as part of the core? ISTM the core technologies must include all the APIs that are needed to pass the TCK. IOW, the core must be the minimum you need to call your implementation "Java". This is a very sensible approach and it also gives you an extremely well defined boundary.

Here is the Java Compatibility Kit 6b User's Guide. I did not immediately see list of all APIs that are tested but that information does exist when you drill down to the details of each test. From my IANAL perspective, everything that is required by the TCK must be part of the core. This will mean "all of it" is core which agrees with what is linked to by their "Core Technology" pages.

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

On languages and APIs.
Authored by: Anonymous on Thursday, May 03 2012 @ 08:57 PM EDT
I don't think anyone has hit the nail on the head here. Some things in a
language are fixed in syntax... such as how you compose a statement, an
assignment or a conditional. This varies widely in languages. Languages like
BASIC and Python have a "print" statement and builtin I/O like
"open" ... but other languages are rather barren like C or C++ ...
where the language needs a default shared library to be useful.

But that's not the end of it. Operating systems provide an API (sometimes
called an ABI (B for "Binary")). Certainly it's possible to use the
ABI directly ... but it's often quite "klunky". Often a bit of
"assembler glue" is required to even use ABI calls directly.

For a good reference on that nonesense, look for the "smallest linux
binary" among other things ... this often involves using the ABI directly
without language libraries.

It's certainly possible to use languages with different API's. Writing a GUI
program in C for windows and linux requires either the use of two different
API's or the use of an API that, in effect, uses the two different API's and
presents a common one to the user. It wasn't really until the publishing of Qt
(and the gnome equivalent) on Windows that there was a free or relatively cheap
API that allowed you to develop for both platforms.

In fact, C is a good example of a language where default libraries do not apply
universally. Writing kernel code for linux or FreeBSD has a completely
different API from that of writing regular software. stdin and stdout don't
exist (for a start) and floating point is generally discouraged.

So... back to java. It's perfectly conceivable that Google could have provided
a completely different set of libraries to use with Android. Yes... the min()
and max() functions would need to exist, but they wouldn't necessarily need to
be in the same packages. In fact, there are a wide range of APIs in Android
that exist nowhere else in java.

How practical is this? It's not too far fetched. For writing new code, many
programmers use tools that present the signatures of functions they search for
while they code. Some IDE's even manage the include statements. It probably
wouldn't have too much effect. Consider how many old java hands are actually at
the vanguard of android programming anyways ... :).

For existing java code? Consider how much code is going to run unmodified
anyways... First consider that a desktop or imbedded application isn't going to
be terribly appropriate for a phone in most cases and then consider that many
things far outside of the APIs in question are in play and would have to be
modified. Then consider that automatic code translation would easily handly 95%
of the rest.

What I'm trying to say is that Oracle has a rather offensive point, but a point
nonetheless.

Why is it offensive? It's not in their best interests, even. If Google had
done this ... created google.io and whatnot, this serves only to completely
fragment android from java ... which is bad for oracle ... and pretty much
wouldn't matter to Google. It would, however, have cancelled this silly lawsuit
before it even started.

[ Reply to This | # ]

Question 4 has a hidden bombshell
Authored by: bugstomper on Thursday, May 03 2012 @ 09:03 PM EDT
4. [...] Is this what the UK company Spring did?
As far as I can tell there is no UK or European company "Spring". Larry Ellison must have been talking about the Spring framework which is from SpringSource, a company that appeared to have been based in UK or EU before they were bought by VMware in 2006 and so is now listed as headquartered in Palo Alto.

The bombshell I refer to is not that they are not actually based in the UK, but that they are in no way the example that Ellison claimed they were. If you accept Google's objection that Ellison is not an expert, then he was demonstrating how he didn't know what he was talking about. If you accept the Judge Alsup's overrule of the objection, then Ellison was lying.

I was a bit miffed that Google's lawyers didn't have the technical expertise to catch Ellison in the error in time to get him about it during the cross. But now I can see no way that Google can miss this - To answer question 4 they have to try to find what this company "Spring" in the UK refers to and the only conclusion they will be able to come up with is that it really is SpringSource.

The reality is that Spring is a very popular Java framework used in enterprise applications. Wikipedia provides a definition of "software framework" that fits in well to this discussion

It is a collection of software libraries providing a defined application programming interface (API).
The important thing about the Spring Framework is that it does not replace any of the Java Class Libraries that one would consider "core", nor any of the classes in the 37 packages in this case. You could not use the Spring Framework without those standard Java class libraries. Like any complex Java application, Spring uses the standard classes extensively.

I don't think Judge Alsup will be very happy with Oracle when he sees the answers to this question, unless there really is some company in the UK named Spring that is not SpringSource and that has written their own core classes for Java that uses a completely different API than the standard one.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated
Authored by: Anonymous on Thursday, May 03 2012 @ 09:06 PM EDT
The ruling from the EU is almost an exact mirror of what is happening in the
Oracle/Google trial. WPL did an implementation of the SAS Language and
environment. The Google is an implementation of the Java Libraries. The SSO is
a requirement of the Java language.

Or another way, the SSO is copyrightable but only if it is NOT needed for
functionality. The courts have ruled that is ok to use an API because it is
needed to call/execute a function. (I.e. reverse engineer/clean room). This is
what Google did.

As for the SSO on the actual printed document, it is a by product of Javadoc.
Javadoc is what dictates the actual printed order, not a person typing it.

What distinguishes this from Kapes is that the SSO of the prices is not
dependent on anything. However, the SSO in of the Java implementation is
directly dependent on how Javadoc process the java classes and is completely
generate automatically without any originality because that is the way the
Javadoc is designed to work.

As for the comments, they are nothing more that describing what the
functionality of the class/methods are supposed to accomplish. Since it is
describing functionality, the only way it can violate copyright is for an exact
copy.

WPL implements the SAS language. Google implemented the 37 java classes. Case
close on copyright.

[ Reply to This | # ]

Principles of organization
Authored by: BitOBear on Thursday, May 03 2012 @ 09:16 PM EDT

What were the "principles of organization" in the Java APIs anyway?

(1) In each level of context, the methods are listed in alphabetical order.

(2) Everything starting with "java.(whatever)" should be part of the language. "javax.(whatever)" is the "java extensions" namespace for things like the windowing library. "com.sun" exists for sun-specific elements as would com.oracle for oracle (just as I am instructed to use com.whiterc as the owner of the whiterc.com domain for software emanating from there).

(3) The packages are "globs" of related stuff given a name. The clever name "java.math" was everything Sun "creatively collected" into that space by simply copying the Unix (Linux? GNU GlibC?) math.h header from C.

(4) it is -WRONG- to say the organization is "java.package.class.method", it is "organization.package_hierarchy.class.[method_or_data_item]". The use of "java." is an -EXPLICIT- indicator of the namespace reserved to the java language and implementation. Yes, sun made the point that for non-langauge-core stuff sun would use com.sun and so on.

(references for #4) -GOOGLE- -LAWYERS- -SHOULD- -READ- -THESE- before briefing this motion. Ora cle Official Breakdown of the Base Libraries which describes these "fundamental to the Java language" structures notably "Other Base Packages" includes "java.io" and "java.nio" as a matched pair of packages, and then proceeds by linkage to jump -like- -everywhere- inside the java.whatever namespace including java.security, java.net, and so forth. Then this Oracle Official Coding Conventions which describe how all the non-language packages should/would be named. The strong implication there includes com.sun as an example of the "not part of java" rules for adding packages, the contrapositive dictates that all of java.whatever was core. Third Party Tutorial on java packages which will help with clarity as to the functional nature of packaging.

(5) Each "class" is a noun. (see the code conventions [naming standard] referenced above).

Note that the use of the names is "chosen by" the implementor but the structure of that choice is "mandated" by the language spec and standards.

Saying Harmony "could have used their own names for the java core library name space" is stating outright that Harmony "could have chosen to not use java at all" for every intent and purpose.

Notice this whole document Code Conventions for the Java TM Programming Language: Revised April 20, 1999 Check out the sub-heading for section 3 "File Organization" The coding conventions even tell you what the -comments- inside the packages should contain in the classes and methods and such. If the "SSO" of the system is called out as a functional standard (e.g. put thing one before thing two) how can it be creative enough to have any copyright value? Oracle's case here is "but Harmony followed our -stated- text formulas and conventions just like we did and got the same SSO!"

[ Reply to This | # ]

13. Compatibility
Authored by: dcs on Thursday, May 03 2012 @ 09:19 PM EDT
I think this is the most important point of all, because it
is this that causes most impact if API is deemed protectable
by copyright.

It's not so much compatibility with existing programs as
with existing libraries and frameworks. I'll give two simple
examples.

First, let's talk about dates and times. It should be plain
to anyone that programs often have to handle them. Asking
questions such as "when will this happen?" or "does this
date belong to this period" is very hard (much harder that
non programmers think), given all the peculiarities of how
us human measure time. For this reason, part of the java API
is concerned with dates and times.

Now, Java API for dates and times was originally very badly
designed. It then got redone (without removing the original
API), and the redesign was incredibly bad as well.

The situation is such that if you ask any experienced Java
programmer about how to do something with dates or times, he
will most likely tell you to use JODA Time (http://joda-
time.sourceforge.net/).

So, what is JODA Time? JODA Time is a library that supplies
a well design API and corresponding implementation for
manipulating dates and times. Because users of this library
may well have to interact with software that does not use
it, JODA has to use Java API for date and time as well.

Which means that, unless Android supports Java's API for
Date and Time, someone writing a program for Android cannot
use JODA.

Let's proceed to the second example, which discusses a
testing framework.

For the past decade, a programming technique called "test
driven development" (TDD, for short) gained widespread
adoption. While not a unanimity by any means, there are many
well respected proponents of it, and lots of places where it
is considered mandatory.

One can practice TDD without help of software tools, it is
not practical. Some authors even consider software tools to
be a mandatory component of this technique.

For Java, one tool, called a "testing framework", got so
popular that not only alternative tools had to provide *APIs
compatible with it* (never thought about that until now),
but it inspired similar tools for other languages. This tool
is called JUnit.

Now, a testing framework has to do a lot of work: it has to
find out the tests, execute the tests, evaluate the results
of the tests, and display them. In order to do all these
tasks, it has to use Java APIs.

The interesting thing here is that you do not need to
execute the testing framework *on* a mobile phone. On the
contrary, you execute them on your desktop, with Java.
However, if the API used by Android was different than the
API used by Java, one could not test code written for
Android using JUnit in a reliable fashion, as the libraries
used by JUnit and the tested code would be different.

Like these two, the are many more examples. One of the
greatest advantages brought by Java over previous language
was precisely how easy it was to use libraries provided by
third parties.

This is so common that there's a joke related to the process
of downloading all required libraries when compiling a
software, a process done automatically by a tool called
"maven". It is said that "maven is downloading the
Internet".

Well, if Oracle has its way, "the Internet" would get a lot
smaller. In the short term anyway -- if Oracle wins, it will
doom Java.



---
Daniel C. Sobral

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated
Authored by: Anonymous on Thursday, May 03 2012 @ 09:22 PM EDT
2. If each API method is a program — pre-packaged but nonetheless a program — did Google copy anything more than the name and the declaration (substituting its own implementation)?

API as is used in this case could mean 2 different things; API specification or API implementation. An API specification is an explanation of inputs and the respective expected outputs. This does not constitute a program but the set of defined rules upon which a program can be built. An API implementation is the concrete realization of the rules as defined by the API Implementation.

Google, or agents of Google, appear to have copied a number of classes (I see 7 and 37, but I only see comparison on 7) from the Sun Implementation. These files were specifically in the test section of the repository and not used on the Android platform itself. Once identified these were removed from Android entirely.

Beyond this the implementation of one method is substantively the same as the Sun implementation. This may not be considered copying however in that it appears the same person created both methods. Given knowledge on an optimal solution for a specific problem every implementation of the solution will be substantively the same. (i.e. there is only one proper solution to a two Knight end game in chess)

3. If the format of the name is dictated by the Java programming rules, then is the form of “java.package.class.method” required by the syntax of the language itself?

yes. Without it you have effectively created a different language using similar rules.

4 and 5 I will skip.

6. Is it agreed that the following is true, at least as of 1996? The following were the core Java Application Programming Interface: java.lang, java.util and java.io.

In 1996 Java was still in its initial public release.

Core libraries at the time were:
java.lang
java.util
java.io
java.awt
java.net
and
java.applet

It is important to realize though that java.net and java.awt of 1996 do not really resemble the packages of today. AWT was rewritten a couple of times, really not reaching stability until 1.2 (when swing was added). The core of java.net survived more or less intact to today but it has been expanded upon greatly. java.net in 1.0 contained around 15 classes and interfaces. Current java.net has around 40 classes with the original core classes gaining a number of additional methods. Add on top of that java.nio, java.rmi, and some of java.security and the landscape for how to do network communication in Java does not resemble the Java of 1996.

I dislike making analogies but think of it like comparing English from the late 17th century (Early Modern English for the linguists out there) compared to now. The concepts are the same and a speaker from one time period could adapt to the other, but the language of the 2 periods are significantly divergent. There are many phrases and idioms used in modern English that simply had no corollary in 1700. Similarly certain phrases and words have lost their original meaning in the modern English syntax.

Java of 1996 (1.0) was still in its early fledgling days and did not have the built up supporting classes that would become available 2-3 years later with the release of Java 1.2.

7. Does the Java programming language refer to or require any method, class or package outside the above three?

This question is somewhat dependent on the version of java in question. I believe the sun.* packages existed in 1.0 but am not certain before 1.2. The sun.* packages were used for internal use and were necessary for the implementation of the core java.* packages.

In current implementations (java5 and higher) the core number of java.* packages have increased. Additionally the javax packages are necessary to completely implement the java specification. As an example javax is the home to the implementation of annotations. In the Java 4 days javax was commonly where classes that were being added to java were placed prior to becoming part of core.

8. To what extent do subparts of the above three Java packages refer to any other Java packages or subpart of other packages (meaning outside the three)? To the extent this occurs, should those outside subparts be deemed to be “core” to the programming language?

Again, this question will to a great extent depend on what generation of java under discussion. Java 1.0 (circa 1996) was largely self contained in dependencies and did not stray from this outside of sun.* packages which were not publicly listed. So from a standpoint of this lawsuit they do not refer to things outside of this core set.

java.lang - self contained.
java.util - referenced java.lang
java.io - referenced java.lang

Modern (Java 6/7) Java has a number of dependencies outside of this scope however. To implement Java 4 or higher a number of additional packages would need to be implemented in order to satisfy the definition of the core language.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj
Authored by: Anonymous on Thursday, May 03 2012 @ 09:37 PM EDT
3. If the format of the name is dictated by the Java
programming rules, then is the form of
“java.package.class.method” required by the syntax of the
language itself?

Yes, absolutely.

4. Could Google have come up with different names and
SSO yet still have provided the same functionality as in
Android? Android users would have had to learn a new
vocabulary and a new outline but the methods would all still
have been resident in such a modified Android. True? Is this
what the UK company Spring did?

To a point. While no method name is dictated by the
compiler many are dictated by industry norms, best practices
or math (There is nothing else you can name "sin". I'm
sorry, there just isn't. Many data structure operations are
similarly defined by the definitions of Computer Science.)
This could easily be determined by comparing with other non-
Java programming languages and frameworks; I'm somewhat
surprised that Google hasn't compared, say, java.lang.math
with Python's math package: they are substantially similar.
Or all of the boost libraries. Or the functions on a TI89.

5. Is the input-output (i.e., argument and return)
scheme of a method copyrightable? For example, can someone
copyright the function of inputting an angle and outputting
the cosine of that angle? If someone has a copyright on a
particular program to find cosines, does that copyright
cover all other implementations that perform the identical
function (input = angle, output = cosine)?

No. Functions are mathematical concepts (lamda calculus)
and are a reflection of truth.

6. Is it agreed that the following is true, at least as
of 1996?

The following were the core Java Application Programming
Interface: java.lang, java.util and java.io.

No. The 1996 O'Reilly book "Java in a Nutshell: 2nd
edition" defines the "core API" classes as those included in
the JDK: applet, awt, beans, io, lang, math, net, text, util
and their sub-packages.

7. Does the Java programming language refer to or
require any method, class or package outside the above
three?

Yes. The "Java programming language", as commonly employed
by programmers, refers to everything available in the JDK
downloadable from http://java.sun.com Does it require them?
It certainly requires any class they contain which is
Serializable, or it will be incompatible with the file
format the Java language produces.

8. To what extent do subparts of the above three Java
packages refer to any other Java packages or subpart of
other packages (meaning outside the three)? To the extent
this occurs, should those outside subparts be deemed to be
“core” to the programming language?

java.io.FilePermission inherits from
java.security.Permission, for example. While it is good
design to isolate functionality and reduce connections
between packages, in practice some connections will always
remain. To the extend it happens, those other packages
should also be considered part of the "core" language: which
package a class is included in is merely human convenience.

9. What cross-method, cross-class interdependencies
exist at the implementation level in Java? Were any of these
duplicated in the Android implementations? (The judge
remembers no evidence on this point.)

(Skipping; part of the reason I use a programming language
with core APIs is so I don't have to think about this
stuff.)

10. In Java, what interdependencies exist at the
name/declaration level other than the inherited
characteristics from the super class, interfaces, same
class, etc.? Please explain.

Declarations include the names of the classes of inputs.
Beyond that, names are purely for the convenience of humans.
I would argue that the primary inter-dependencies have to do
with the fact they are implementing defined domains, such as
the underlying computer system ("File",
"Socket","Permission"), Computer Science concepts
("Map",
"List", "Hashtable"), the Internet ("URL",
"URI",
"Inet6Address") or human life ("Date", "Locale",
"Color").
I have no idea what you would name "Color" other than
"Color".

13. When discussing use of the SSO in the 37 API
packages in Android to achieve “compatibility,” what exactly
are the parties referring to? Is it “compatibility” with
programmers who write in the Java programming language? Or
compatibility with pre-existing programs? If so,
approximately what percent of pre-existing programs written
for the Java platform are compatible with Android? Is it
compatibility with the TCK? Or Java virtual machine? Or java
compiler?

Compatibility is a continuum and the further along the
continuum the language is the easier my life is. If Google
didn't include these packages, each group of programmers
would re-implement them themselves (as is standard practice)
and then have to go through and change the package imports
to point to their own versions.
I can't think of any way to know what percentage of software
or, more importantly, libraries are compatible. Most are propitiatory and
inaccessible.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated
Authored by: Anonymous on Thursday, May 03 2012 @ 09:39 PM EDT
6. Is it agreed that the following is true, at least as of 1996?

The following were the core Java Application Programming Interface:
java.lang, java.util and java.io.

When they are talking core here, they mean classes whose name and structure are
mandated by the Java Language Specification. For instance, the class
java.lang.String is special because Java has a language-level operator (+,
concatenation) that works on strings. The class java.lang.Iterable is core,
because the for-each loop which was added in Java 5 operates on an Iterable.
Then there are secondary dependencies. An Iterable returns an
java.util.Iterator, so you can't have a compliant Java API without Iterator as
well, etc.

Things like java.awt have been included in Java for a long time, but they are
not required by the language spec. That's the distinction Oracle's trying to
make. That there's an implicit (or explicit, I don't know) license granted to
copy the SSO that is mandated by the JLS, but no more.

7. Does the Java programming language refer to or require any method, class or
package outside the above three?

I haven't looked through every word of the JLS, but I believe it's close to the
truth (or was in 1996). Nothing about the language in itself requires much of
anything outside of those three packages.

Hand in hand, those three packages are being argued to be completely
self-sufficient; their declaration doesn't rely on anything outside of
themselves, even though their implementation might make use of other classes.
Now, that's not true for Java 5; I'm not sure if it was true in 1996.

8. To what extent do subparts of the above three Java packages refer to any
other Java packages or subpart of other packages (meaning outside the three)? To
the extent this occurs, should those outside subparts be deemed to be “core” to
the programming language?

The implementations of these classes may well make great use of other classes
for convenience. The declarations themselves (visible field types, return
types, parameter types) do not.

I'm guessing Oracle (and probably Google to, if they're being honest about it)
will respond that only references to types that occur in declarations should be
considered part of the core API.

For example, if java.lang.ClassLoader is considered a core class whose SSO is
governed by the language (I believe that's true), then so should java.net.URL
since it's returned by the getResource() method. If you weren't allowed to copy
the java.net.URL API, you wouldn't be able to implement this method because you
couldn't return the thing you're required to return. However, the
implementation of getResource() makes use of sun.misc.Resource (at in a modern
Oracle implementation of it) and that shouldn't be considered to be part of the
core API because it's an artifact of implementation.

Anyone that responded that they found references by grepping the source, those
are often implementation things. Imports should be completely ignored, they're
irrelevant to all of this (your source can have an import and not even use it!)
and are more likely to be used for implementation than for declaration. A
better grep would be over the published Javadocs, as those do not include
implementation references.

[ Reply to This | # ]

Why European court and not another US Circuit?
Authored by: LouS on Thursday, May 03 2012 @ 09:40 PM EDT

Remember the "abstraction/filtration/whatever" process outlined by Randy Davis in the SCO trials? I wondered why it has not come up in this trial. I assumed that was because it was from another District and was not precedent setting for this trial. But we see Judge Alsop looking at European courts (although not as binding precedent) - why does he not look at another US District court the same way?

(Not complaining that he looked at EU court, just that he didn't look at Randy Davis' approach.)

[ Reply to This | # ]

Question 6
Authored by: Anonymous on Thursday, May 03 2012 @ 09:43 PM EDT
6. Is it agreed that the following is true, at least as of 1996? The following
were the core Java Application Programming Interface: java.lang, java.util and
java.io.

I don't see this mentioned elsewhere, but: from the Java Language Specification,
(C) 1996 Sun Microsystems, published in a softcover book that I bought in an
ordinary bookstore, ISBN 0-201-63451-1, first printing August 1996:

Chapters 20-22 document java.lang, java.util and java.io respectively. No other
Java APIs are given such special treatment in the _language_ specification.

[ Reply to This | # ]

Is this 1 minute concise definition of API Correct?
Authored by: Anonymous on Thursday, May 03 2012 @ 09:53 PM EDT
I just watched <a href="http://www.youtube.com/watch?
v=QSUnBPv4iQ0">this really short video on youtube</a> with
what seemed to be a very clear definition of API: an
interface of rules to simply let programs be written from a
language (for eg. java).

I have a few questions since a lot of you seem to be Java
programmers and give clear answers.
a) Is the youtube definition broadly correct?
b) In this case, what is the program? Android?
c) In this case, what is Dalvik? where does that come in?
d) Where, in this explanation, are apps for Android placed?
Are they extensions of the big program?
e) Can java be used if the original API were not there?
f) Are the 9 lines of code the case keeps dwelling on in
Java's API?


-- A non-programmer and a non-lawyer (somewhat like the
jury..)

[ Reply to This | # ]

Question #13 is the most important to me as a Java developer
Authored by: Anonymous on Thursday, May 03 2012 @ 09:53 PM EDT
I've written hundreds of thousands of lines of Java code throughout my career. Most of that code refers to Java core API package names, class names and method names. If Oracle is allowed to prevent 3rd-party implementations of this API, I am forced to use Oracle's JVM, because there's no way I can rewrite all my code against a different API. In other words, Oracle would have an indirect control over my programs. This is plainly wrong.

[ Reply to This | # ]

#6
Authored by: Anonymous on Thursday, May 03 2012 @ 10:12 PM EDT
regarding
"6. Is it agreed that the following is true, at least as of 1996?

The following were the core Java Application Programming Interface:
java.lang, java.util and java.io."

All were documented in "Exploring Java" published by O'Reilly
copyright 1996 May 1996 edition.

java.io is crucial in order to have a program that can read or write anything, a
program that can't communicate would be useless. Can't do much without
java.util or java.lang APIs. Yeah, all three are core and have been core a long
time.

[ Reply to This | # ]

API: How are the methods ordered?
Authored by: Anonymous on Thursday, May 03 2012 @ 10:14 PM EDT
I haven't looked at the Java API, but how are the methods
listed?

Alphabetically?
Grouped by common function?

Google can change the order of the methods in the API
(implementation) and it will have no effect on compatibility
(may require programs to be re-linked).

If the API methods are alphabetical, it would make the
documentation generated from the comments be in alphabetical
order too. That would be a huge bonus to programmers
reading the documents!

If the methods are not alphabetical, make the alphabetical.
The programmers reading the documents will love you. Plus
that might get around Oracle's SSO complaint.

If they are alphabetical, can't Google argue that it is the
only logical order?

If I was implementing a huge API like Java, I'd keep the
functions in the same order. It would make it easier to
compare to the API specification (i.e. find missing/skipped
methods) and it is easier to start at the top of one API,
work down to the bottom and then start working on the next
API. It would also be easier to keep your implementation in
sync when new specifications are released.

Jamie Royer

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on API
Authored by: Anonymous on Thursday, May 03 2012 @ 10:35 PM EDT

6. Is it agreed that the following is true, at least as of 1996?

The following were the core Java Application Programming Interface: java.lang, java.util and java.io.

Which words in the English Language are core words? Which can be removed?

[ Reply to This | # ]

Examples of the Core Java Libraries**
Authored by: jbb on Thursday, May 03 2012 @ 11:12 PM EDT
Let's look at the OpenJDK Core Library Group. They say the core libraries include at least the following:
java.lang
java.lang.annotation
java.lang.inst rument
java.lang.management
java.lang.ref
java.lang.reflect
java.io
java.nio
java.nio.channels
java.nio.channels.spi
jav a.nio.charset
java.nio.charset.spi
java.util
java.util.concurrent
java.util.concurrent.atomic
java.util.concurrent.locks
java.util .jar
java.util.logging
java.util.regex
java.util.prefs
java. util.spi
java.util.zip
java.math
java.rmi
java.rmi.activatio n
java.rmi.dgc
java.rmi.registry
java.rmi.server
javax.namin g
javax.naming.directory
javax.naming.event
javax.naming.ldap
javax.naming.spi
javax.script
Let's see what the folks over at GNU Classpath have to say:
GNU Classpath, Essential Libraries for Java, is a GNU project to create free core class libraries for use with virtual machines and compilers for the java programming language.

[...] GNU Classpath is a set of essential libraries for supporting the Java programming language.

Classpath serves the same role that libc has for C, but is much richer in functionality. The broadness of the standard library is an important reason why Java has been so successful. For example, the library includes frameworks to convert between character encodings, for accessing relational databases, for building Graphical User Interfaces, for encryption, for logging, and for numerous other tasks that are needed to build complex applications.

[...]1.5 Is GNU Classpath all that is needed for running Java programs?

GNU Classpath is a free implementation of Java’s standard library. To execute Java programs, it is also necessary to have a Java Virtual Machine (JVM). This component manages memory, enforces security restrictions, compiles Java bytecodes to the instruction set of your computer, and provides other runtime services.

You can browse the classes they include here but needless to say it's a massive superset of the 37 accused APIs. Of course, since GNU Classpath was intended to be able to pass the TCK, their use of "core libraries" is synonymous with the TCK definition I gave in a earlier post. Likewise, Harmony was intended to pass the TCK so they will have included (pretty much) the same APIs that are in GNU Classpath.

The Apache Software Foundation has said:

Android's core libraries are derived from Harmony.
When Tim Ellison stepped down from leading the Harmony project he said
Due to the licensing dispute over the rights for an open-source project to implement an alternative implementation of Java, the Harmony project will never be able to call itself a JavaVM or an implementation of the Java core language libraries.
Techphobia agrees:
Android applications are predominantly developed using the Java programming language. The Standard Java development environment includes a vast array classes that are contained in the core Java runtime libraries. These libraries provide support for tasks such as string handling, networking and file manipulation (to name but a few) and are both familiar and widely used by Java developers regardless of platform.

The Java Interoperability Libraries are an open source implementation (based on the Apache Harmony project) of a subset of the standard Java core libraries that have been adapted and transformed for use by applications running within a Dalvik VM.

I've found many important uses in the wild of the term "Core Java Libraries" that either say the APIs needed to pass the TCK are included as part of the core or they imply that there are many many APIs in the core. I have not found any uses of that term which contradict this. In fact, this was one of the major purposes of the TCK. If a Java implementation passed the TCK then you were assured it had all the core libraries you had come to rely on. If any one of those APIs was missing then the implementation could no longer be called "Java".

Note: **For the purposes of counting what is "core" and what isn't, the terms "Core Library" and "Core API" can be used interchangeably. There is a very simple relationship between the libraries and the APIs. In essence, a library implements an API. When talking about re-implementations, people are usually more interested in the code so they will more often say "core library" rather than "core API".

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

An API SSO is not a creative product
Authored by: Anonymous on Thursday, May 03 2012 @ 11:53 PM EDT
All APIs are generally the same in this regard.

Structure - Heirarchical
Sequence - Alphabetical
Organization - Clustered by functional domain

These are the only rational ways that one engineer can arrange data so that it
can be found intuitively by another engineer. It was ever thus.

The idea that some creative genius was involved in ensuring
java.io.fileinputstream belongs in "io" before
"fileoutputstream" and below the generic "io" level is and
always has been completely bogus.

For prior art, look in the UNIX directory structures, technical reference
manuals, biotech product catalogues, hell - even how a yellow pages phone
directory is put together.

Now, choosing what functions to have in the API is somewhat more creative.
Choosing meaningful names, the best parameters and return types etc
(signatures). But once you have the signatures, the rest is just common sense.

[ Reply to This | # ]

An example of why copyrighting APIs is very very bad for software
Authored by: celtic_hackr on Thursday, May 03 2012 @ 11:56 PM EDT
Ok, let me try to give another example of why it's very bad to give copyright
protection to APIs.

For example let's say that there exists an API called java.math.trajectory. This
API takes for input a pair of points, an acceleration, a mass, an amount of
energy it has that it can expend, and a vector (point origin, point xyz, real a,
real m, real fuel, vector v). It returns a plotted path from a point on a planet
to another point where the energy of the mass comes to rest. It could be another
place on the planet or anywhere in the galaxy.

Now let's say the stock java.math.trajectory has some bugs in it and it runs
kind of slow. Me, being a mathematical programming genius, come up with a better
algorithm and create my own implementation to use rather than Sun's broken one.
I use it in all my commercial software, and distribute my code as part of an API
with other functions I've fixed, because Oracle is ignoring my attempts to post
my fixes to their precious API. Others discover my API and start using it, and
asking me for copies. So I start distributing. My API mimics the exact same
interface as Oracle/Sun's, because remember I started out using their API, and I
was lazy in not wanting to rewrite all the calls in all the code in all my
programs, so I use the same API conventions and my change is a drop in
replacement.

So now I have this superior API and people want it, and I use the same API so
others don't need to rewrite tons of code, but if Oracle gets their way I will
have to pay them to not use their broken API code, because I happen to use the
same way of calling my superior, bug free code. How stupid is that?

Yes, I could of course rename my routine, but what if my API includes an
innocuous little thing that gets called a thousand times every time a program
runs? That means changing perhaps a thousand calls to that code, in every
program that uses it. Sure it can be automated. But it also means distributing
new copies of each of those programs to every user. Whereas, by using my API
with the same name as Oracle's, all that needs be done is drop my API over
Oracle's, and everyone's code gets fixed.

Now let's make it worse. Let's say I have 10 different versions of my API. Only
four of which still include support for bugfixes, but this API is universally
compatible with all versions of my program. So, if I can put my API on my
download server any registered user can download my API and drop it in to their
system. But if I have to change the interface, all those unsupported users are
left out in the cold. Also, any person using the java.math.trajectory could sue
my API as is, and have better bug free code without even being an owner of my
wonderful software. Because I'm a nice guy and don't require registered users to
buy anything to download. But I still make money on the API, because people are
still buying my original software which the API was written for. Just this one
API is OSSed, to show my support for FOSS and such. Now, what is the benefit to
society? I'm clearly using it in a commercial setting. Which cuts against
fair-use.

What would you rather do? Change and redistribute 10,000 programs or install 1?
Which method has more benefit to society? Which promotes progress better?

[ Reply to This | # ]

  • Changing Java - Authored by: Anonymous on Friday, May 04 2012 @ 02:26 AM EDT
Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated
Authored by: ChuckM on Friday, May 04 2012 @ 12:03 AM EDT

Ok, so PJ asked what folks thought was 'core' and I figured I would throw in my two cents.

I'm one of the original Java folks, if you look at the Meet the People page from the Alpha 1.02 release I'm back next to Frank Yellin. That particular link goes to a copy of the original Java release, the one where Sun was still thinking about flushing it down the toilet because they could not figure out how to monetize it. Everyone in that picture was thinking they needed a new job come the end of Sun's fiscal year. But in the release there was an AP I specification too which lists exactly three core APIs, java.lang, java.util, and java.io. Everything else was part of HotJava which was the browser.

During the time leading up to releasing this package there had been a lot of discussion about what was or was not part of the language. Some things were moved into java.util, others into sun.util, and still others left out entirely. I originally had a done a bunch of crypto work that didn't come out until after I had left Sun.

So I would say that those three packages really were core, and I explain to people they were like the 'libc' for Java. Further, like libc, there are things you assume are there when you write a C program like read() or write(), and there are things that you only assume if you're in an OS environment like SunOS such as socket() or even printf(). Embedded C programmers are very familiar with these sorts of trade-offs.

So any language, and Java is no exception, is hard to define in a vacuum. Things are also complicated by later versions of Java added additional stuff (like collections, the reflection API, etc). But to answer PJ's question in the post back in 1996 this was as good a definition of core as any.

--Chuck

[ Reply to This | # ]

Google legal team?
Authored by: Anonymous on Friday, May 04 2012 @ 12:19 AM EDT
Somehow, having read through all the reports on Groklaw, I get the feeling that

the Google legal team did not do a great job in presenting *why* API definitions

should not be copyrighted, why they are ideas and not expression.

Especially reading these questions - they should have been answered
convincingly to the judge before this isn't it?

[ Reply to This | # ]

Chilling effects on a UK/EU citizen
Authored by: TiddlyPom on Friday, May 04 2012 @ 01:11 AM EDT
So many times I have seen laws and legal decisions made in the USA that affect me in an adverse way (think ACTA, SOPA, Software Patents, extension of copyright etc) in which my life (as a software developer who works with open source software) has been affected.

It is somewhat gratifying that the USA legal system does take *some* notice of laws and legislation passed outside its borders even if they are (perhaps) diametrically opposed to some internals views (or perhaps the wants of USA proprietary/incumbent companies). Passing judgement in favour of Oracle would (I believe) hurt open source software development not only in the USA but all over the world.

I am involved in a project which is using the Talend Data Integration tool as well as PostgreSQL as the primary database for a data warehouse (which was decided on because Oracle was too expensive and not flexible enough in licensing terms). Talend Open Studio is written as an Eclipse plug-in (obviously written in Java) and generates Java code. At the moment, none of this affects me as on PCs this obviously is not a problem at the moment as it is covered by the OpenJDK/GPL but there has been a movement towards servers running ARM chips rather than x86 - what if they were running Android (e.g. Rowboat)? Rowboat as also an excellent possible operating system for the Raspberry PI (my Beagleboard boots both Xubuntu and Rowboat).

I just hope that the judge/jury do the right thing.

---
Support Software Freedom - use GPL licenced software like Linux and LibreOffice instead of proprietary software like Microsoft Windows/Office or Apple OS/X

[ Reply to This | # ]

API's - another analogy
Authored by: Anonymous on Friday, May 04 2012 @ 01:14 AM EDT
This is the first time I've ever read a court transcript day
by day so thanks for the coverage, it's been fascinating and
educational.

On to the analogy - I haven't seen this one so it may help,
probably a bit late but oh well.

The code for an API is a book, the api's are the index to
the book. compilers and humans need the index so they know
which bits of the book to go to (this is literally true, the
compiler looks up the api and finds the bit of code for each
method).

There are two books for any implementation, one the human
readable one ( the source code ), and one machine readable (
the compiled code ). The machine readable one is made from
the human readable one by the compiler.

The packages are how the index is arranged, it's in logical
entities or concepts. Now what google has done is taken some
of the index from the original sun/oracle book, and written
it's own book so that the index entries point to the part of
the book that means the same thing as the book that sun
wrote.

So can you copyright an index? In the world of books you'd
never do this because it's meaningless, but to a programmer
the index is the connection between the book and their code.

So what an application programmer does is write their own
book which looks up the index in Googles (or Sun's/Oracles)
book and joins the books together.

So the API is a set of indexes into a book, arranged in a
logical order. How you arrange the indexes makes packages,
and there are many ways to do this.

Is this a good analogy?

[ Reply to This | # ]

my new SSO
Authored by: Anonymous on Friday, May 04 2012 @ 01:31 AM EDT
I hereby copyright the following SSO :

#include "/usr/include/linux/kernel.h"

Now payup.

[ Reply to This | # ]

  • my new SSO - Authored by: Anonymous on Friday, May 04 2012 @ 02:22 AM EDT
OO - another point of view
Authored by: Anonymous on Friday, May 04 2012 @ 02:09 AM EDT
Up to my understanding, Java is an object oriented language. Object Oriented
(OO) does include that you can, will and have to alter an object to extend it,
to reuse it in another context. That is the purpose of OO.

In my understanding OO and a copyright on SSO for APIs and so for an object
within that SSO does conflict in its definition and purpose. Even in a closed
system. As the output can be an object (which is reusable and can be altered,
extended, inherited).

And the objects within the APIs are by definition objects that can, will and
have to be altered, extended and inherited. How can anyone expect a copyright on
SSO within OO? You can, will and have to ... but your are not allowed?

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated 2Xs
Authored by: Anonymous on Friday, May 04 2012 @ 02:24 AM EDT
7. Does the Java programming language refer to or require any method, class or
package outside the above three?


This more of a runtime dependency, but but the following program:

public class Test {
public static void main(String[] args) {
System.out.println("Hello World!!!");
}
}

Loads classes from the following Packages in OpenJdk 1.7 (I'm excluding sun.*)

java.io

java.lang
java.lang.invoke
java.lang.ref
java.lang.reflect

java.net
java.nio
java.nio.charset
java.nio.charset.spi
java.security
java.security.cert

java.util
java.util.concurrent
java.util.concurrent.atomic
java.util.concurrent.locks
java.util.jar
java.util.zip


java -versbose will list all classes as they are loaded.

[ Reply to This | # ]

Lots of Lovely Analogies, Thanks
Authored by: Anonymous on Friday, May 04 2012 @ 02:57 AM EDT
But what counts will be the answers the lawyers hand up to the bench.
The first 7 questions can be substantially answered Yes, or No,
even in their parts. Of course the parties may offer a little more
elaboration, but I still have this sinking feeling that one of the parties
is pathologically inhibited from simple Yes or No, and their answers
tend to have negative illumination values, sucking clarity and meaning
away from existing evidence. Maybe I'll have an early evening like the jury.

[ Reply to This | # ]

The Woodpecker
Authored by: BitOBear on Friday, May 04 2012 @ 03:10 AM EDT
For those who really want to understand all this:

A famous quote (closely paraphrased here) is "If buildings were built the
way software is written, the first woodpecker to come along would end
civilization."

Interfaces are not a thing, they are an idea. They are the expression of the way
unrelated things rub up against each other successfully. They are the idea of
inter-operation.

So the quote was about how software is badly made, sure, but it's got a more
sinister angle. The idea is that -one- woodpecker could bring it all down. For
that to be true the buildings would all have to be dependent on one another.
Leaning on and holding up each other in interlocking dependency.

Software is very like that. Everything is leaning on and built upon every other
thing. Sometimes to the point where some original stable piece no longer exists.
This is "the circular dependency". Look up "George Washington's
Axe" (the joke, story, zen parable of replacing all the parts of something
and then wondering if it still is that thing).

Allowing API's to be copyrighted (or patented really) strikes at the idea that
things can and should be able to use other things, this is very nearly the only
remaining tent pole of computer science. It is, and was, a foundation for all
computer science. As each stable brick and wall has been kicked out of this
discipline one at a time we have always relied on the act of composition to
survive. Interfaces are the declaration of that act. (not the act itself, just
the assertion that it is to be done with each/any so defined part).

As late as the seventies -everything- was fully disclosed source (more or less
"open source" to about 84% of the definition). When you got software
you got it as binary and source. You were expected to -need- to tweak it. You
were expected to show/tell/give those tweaks back to the providers.

These were Halcyon Days when printer manuals contained all that you needed to
operate the printer (try asking Brother for the low-level command reference for
a P-Touch USB label printer etc.) and so on for all hardware. As patents and
secrecy and closed -everything- took hold through the eighties and nineties we
got to where it was said outright; "if you want to use our video cards you
just have to blindly install our drivers" (NVidia et al).

Then the software patent bite was taken out of us all for the DVD industry et
al. This pound of flesh closest to our heart. They were denied our blood though,
when blocking interoperability was beaten down in court, so we lived owing that
flesh but still holding it in our chests.

This idea, that interoperability can be owned by copyright for a century or more
(when does the author die plus how long?) will take from us that last moment of
uneasy breath.

In the last thirty years I have watched first-person as the US software and
computer industry has ground more slowly and less usefully towards a gritty,
smoking halt. It has grown wider (everybody's got a cell phone and half of
everyone has a computer) but forward progress is almost glacial now, where there
used to be a torrent.

People sometimes talked about how amazing it was when IBM provided the IBM PC
Technical Manual because they were used to budding apple and the slew of
once-rans releasing machines to secrecy. And for a while that disclosure was the
norm and every expensive box for every component you got either matched a
published spec, came with a complete interface in the manuals, or it came
wrapped in secrecy from the preternaturally struggling Apple Inc.

As everybody else coveted secrets, and Microsoft produced more while disclosing
less (particularly to make Office work and kill WordPerfect et al), Apple always
got the next swath of breathing room as secrecy became the norm.

Now it's all bland and Apple claims Android is a ripoff of iPhone while
disclaiming how much the iPhone is a ripoff of every other product.

But still, we have these Interfaces. Ways we can eek out just a little of our
collective will and expertise to make our devices do what we want of them, what
we need of them, in our own good time instead of some marketing plan's steady
greedy schedule of cash infusion that they plan to strangle out of a public
offering.

Now the toll-taking brigands claim that even what they disclose to, or outright
copy from, the realm of common practice should be subject to toll under
copyright theories. Said theories rendered contorted and inexplicable because
they already lost that fight under reverse engineering within the patent domain
and so they must avoid here the clarity that defeated them there.

Imagine if you could find a way to take a toll on "polishing". Not a
patent on a particular way of polishing a particular material and such. Instead,
if you could own by copyright the verb "to polish". Oh you would pound
out that ownership in a general sense, and claim that you got such ownership
because "to polish" was one of the large set of verbs you registered.
And you proved you owned that verb as one of seven hands-full or so of verbs
arranged with a particular sequence and strucure and organization. And someone
decided that you deserved "a little something" for that SSO. But then,
even if everybody didn't copyright every verb in sight, you still can prevent
the construction of, or take a toll on, -anything- because almost everything
made must, at some stage, be subjected to polishing. Its not just that the
outside of everyones phones or glasses would be left a little rough, but indeed
no two pieces of precision machinery would ever again be joined in a machine
without someone paying someone for the action of polishing the parts.

So Oracle says that joining of parts using an interface isn't what they want,
but being able to define an interface should grant ownership of that interface.
And no, they don't know who owns "smooth" as a defined interface, or
"toothed", or "treaded", or "rough", but clearly
-someone- -should- since those are material interfaces, and they think they well
might.

So thus has grown up a tree of branching supposition, it grows in a soil of
fertile jargon, it wavers under the uncertain wind of mismatched definitions of
terms and practices, a rope of tangled words has been thrown through it,
everyone is arguing over who may, might, or should own that rope, and we wait to
discover if we will have been lynched on that last dangling free end.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated 2Xs
Authored by: PolR on Friday, May 04 2012 @ 05:45 AM EDT
PJ said:
After reading your comments, I think the partial answer to question 4 would be: if you don't speak French, and the waiters in a French restaurant don't speak English, will you still be able to order? You can try, but you might not get what you expected.
Perhaps judge Alsup may lack the insight that programmers don't always write programs from scratch. Programmers often port programs from one platform to another. Also they sometimes write programs with the intent of making them easily portable. Compatibility doesn't carry the same weight when one doesn't have an idea that porting is part of the picture and think only of functionality as what the program does on a single platform. Then compatibility is seen as a matter of learning a new vocabulary and this can be solved with a little training.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated 2Xs
Authored by: Anonymous on Friday, May 04 2012 @ 06:58 AM EDT
4. Could Google have come up with different names and SSO yet still have provided the same functionality as in Android?[...]

Let's say Java is a car. C++ a plane and python a bike.

Changing the APIs would be similar to changing the way you drive a car, like for instance switching the break pedal with the gear lever.

You _can_ obviously do this, you would even have the same functionality, but nobody would expect it.

By choosing another language you change the default interface everybody expects.

But if you want to provide a java language, you better provide the basic classes/APIs otherwise programming would be very confusing.

[ Reply to This | # ]

You can see what's core language stuff from the package names
Authored by: Anonymous on Friday, May 04 2012 @ 07:11 AM EDT
Everything starting java. or javax. is a core package.

Anything proprietary would of course be in sun.*

End of argument.

[ Reply to This | # ]

No. 6: What a silly question!
Authored by: Ian Al on Friday, May 04 2012 @ 08:52 AM EDT
Mind you, I had been reading this story and the comments for hours before I realised that!

6. Is it agreed that the following is true, at least as of 1996?

The following were the core Java Application Programming Interface: java.lang, java.util and java.io.
The answer to the question is no. Oracle have fragmented the Java platform into a number of parts. The core APIs defined by Oracle depend on which part one is considering.

PJ found this in an Oracle description of the various Javas.
Overview of Java ME

Unlike Java SE, Java ME is not a piece of software, nor is it a single specification. This difference can be confusing, even for developers who are already familiar with Java SE. Instead, Java ME is a platform, a collection of technologies and specifications that are designed for different parts of the small device market. Because Java ME spans such a variety of devices, it wouldn't make sense to try to create a one-size-fits-all solution.

Java ME, therefore, is divided into configurations, profiles,and optional packages. Configurations are specifications that detail a virtual machine and a base set of APIs that can be used with a certain class of device. A configuration, for example, might be designed for devices that have less than 512 KB of memory and an intermittent network connection. The virtual machine is either a full Java Virtual Machine1 (as described in the specification) or some subset of the full JVM1. The set of APIs is customarily a subset of the Java SE APIs.
The Oracle definition of the core APIs for mobile devices is that the core Java API for a particular class of mobile device is customarily a sub-set of the Java SE APIs together with optional packages to suit that mobile device class.

The core Java API for the Android class of mobile devices is a sub-set of 51 packages from SE with the additional packages required for Android device capabilities. Google follow the definition set by Oracle. Google do this so that 'developers who are already familiar with Java SE' are able to program for ME type devices like Android, just as Oracle intended.

I think that Google would find that this information that Oracle provided to the court is a pretty good answer to No. 6.

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

[ Reply to This | # ]

Java is a platform
Authored by: Anonymous on Friday, May 04 2012 @ 09:30 AM EDT

There are two issues here:

1) Java is a platform, that is comprised of the language, the APIs, and the JVM. The core APIs (java.lang, java.util, java.io) are required for the language to work. The other APIs distributed alongside Java (mainly rt.jar) are taken for granted by most developer when they write code. One of the main points of Java is to provide a set of functionality that will be available on all supported operating platforms, that's what enables the "write once run everywhere" motto. I guess the idea behind Android was that everything that was not platform specific could be reused, only the bits specific to the mobile phone platform needed to be different. So things like java.net remained, while javax.swing disappeared and android was introduced.

2) As a software engineer I design interfaces and implement interfaces designed by others all the time. For example Spring, that was used as an example works this way. They offer a framework that helps plugging interfaces and implementations together. Let me give an example : say that a specific component requires a way to access data. The authors of this component define a contract of how this access should take place, with methods such as read() or write(). The contract takes the form of an interface + the documentation. The documentation adds information that cannot be conveyed by the code alone, so the two cannot be dissociated. That contract is what is called an API. It is then my job to implement this API to give access to the data in the way required by my application, for example it could be a file, or a database.

This concept of contract is central to software design and I really wish the court understands its importance. If it was decided that an API was copyrightable, and that an implementation of an API was a derivative work, I simply could not work any more. Interfaces I wrote and I use would need relicensing with more liberal terms, and that simply would not happen for old code.

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated 2Xs
Authored by: Anonymous on Friday, May 04 2012 @ 09:30 AM EDT
In the Java 1.0 API
(http://www.aquaphoenix.com/ref/jdk1.0.2_api/packages.html),

there were the following packages:

java.lang
java.io
java.util
java.net
java.awt
java.awt.image
java.awt.peer
java.applet

java.lang.Object is the superclass of all Java classes and
java.lang.Object is dependent on java.lang.Class and
java.lang.String.

java.lang.Class is dependent on java.lang.ClassLoader and a
bunch of java.lang.reflect classes and so on.

I wrote a small app to print all the dependencies of
java.lang.Object and the dependencies of those. Here's the
list (for Java SE 6, I don't have 5 on my laptop right now):


1 java.io.Closeable
2 java.io.FilterOutputStream
3 java.io.Flushable
4 java.io.IOException
5 java.io.InputStream
6 java.io.OutputStream
7 java.io.PrintStream
8 java.io.PrintWriter
9 java.io.Serializable
10 java.io.UnsupportedEncodingException
11 java.io.Writer
12 java.lang.AbstractStringBuilder
13 java.lang.Appendable
14 java.lang.AutoCloseable
15 java.lang.CharSequence
16 java.lang.Class
17 java.lang.ClassLoader
18 java.lang.ClassNotFoundException
19 java.lang.Cloneable
20 java.lang.Comparable
21 java.lang.Enum
22 java.lang.Exception
23 java.lang.IllegalAccessException
24 java.lang.IllegalArgumentException
25 java.lang.InstantiationException
26 java.lang.InterruptedException
27 java.lang.Iterable
28 java.lang.NoSuchFieldException
29 java.lang.NoSuchMethodException
30 java.lang.NumberFormatException
31 java.lang.Object
32 java.lang.Package
33 java.lang.Readable
34 java.lang.ReflectiveOperationException
35 java.lang.RuntimeException
36 java.lang.SecurityException
37 java.lang.StackTraceElement
38 java.lang.String
39 java.lang.StringBuffer
40 java.lang.Throwable
41 java.lang.annotation.Annotation
42 java.lang.reflect.AccessibleObject
43 java.lang.reflect.AnnotatedElement
44 java.lang.reflect.Constructor
45 java.lang.reflect.Field
46 java.lang.reflect.GenericDeclaration
47 java.lang.reflect.InvocationTargetException
48 java.lang.reflect.Member
49 java.lang.reflect.Method
50 java.lang.reflect.Type
51 java.lang.reflect.TypeVariable
52 java.net.ContentHandler
53 java.net.ContentHandlerFactory
54 java.net.FileNameMap
55 java.net.MalformedURLException
56 java.net.Proxy
57 java.net.Proxy$Type
58 java.net.SocketAddress
59 java.net.URI
60 java.net.URISyntaxException
61 java.net.URL
62 java.net.URLConnection
63 java.net.URLStreamHandler
64 java.net.URLStreamHandlerFactory
65 java.nio.Buffer
66 java.nio.ByteBuffer
67 java.nio.ByteOrder
68 java.nio.CharBuffer
69 java.nio.DoubleBuffer
70 java.nio.FloatBuffer
71 java.nio.IntBuffer
72 java.nio.LongBuffer
73 java.nio.ShortBuffer
74 java.nio.charset.CharacterCodingException
75 java.nio.charset.Charset
76 java.nio.charset.CharsetDecoder
77 java.nio.charset.CharsetEncoder
78 java.nio.charset.CoderResult
79 java.nio.charset.CodingErrorAction
80 java.security.CodeSigner
81 java.security.CodeSource
82 java.security.GeneralSecurityException
83 java.security.Guard
84 java.security.InvalidKeyException
85 java.security.Key
86 java.security.KeyException
87 java.security.NoSuchAlgorithmException
88 java.security.NoSuchProviderException
89 java.security.Permission
90 java.security.PermissionCollection
91 java.security.Principal
92 java.security.ProtectionDomain
93 java.security.PublicKey
94 java.security.SignatureException
95 java.security.Timestamp
96 java.security.cert.CertPath
97 java.security.cert.Certificate
98 java.security.cert.CertificateEncodingException
99 java.security.cert.CertificateException
100 java.util.Collection
101 java.util.Comparator
102 java.util.Date
103 java.util.Enumeration
104 java.util.Iterator
105 java.util.List
106 java.util.ListIterator
107 java.util.Locale
108 java.util.Locale$Builder
109 java.util.Locale$Category
110 java.util.Map
111 java.util.Map$Entry
112 java.util.MissingResourceException
113 java.util.Set
114 java.util.SortedMap

Also, here's a list of some of the classes mentioned in the
Java Language Spec 7 and dependent classes (I don't have
v3):

115 java.io.Console
116 java.io.File
117 java.io.FileDescriptor
118 java.io.FileFilter
119 java.io.FilenameFilter
120 java.io.Reader
121 java.io.SyncFailedException
122 java.lang.AbstractMethodError
123 java.lang.AssertionError
124 java.lang.Byte
125 java.lang.Character
126 java.lang.Character$Subset
127 java.lang.Character$UnicodeBlock
128 java.lang.Character$UnicodeScript
129 java.lang.ClassCircularityError
130 java.lang.ClassFormatError
131 java.lang.CloneNotSupportedException
132 java.lang.Deprecated
133 java.lang.Double
134 java.lang.Error
135 java.lang.ExceptionInInitializerError
136 java.lang.Float
137 java.lang.IllegalAccessError
138 java.lang.IllegalMonitorStateException
139 java.lang.IncompatibleClassChangeError
140 java.lang.InstantiationError
141 java.lang.Integer
142 java.lang.InternalError
143 java.lang.LinkageError
144 java.lang.Long
145 java.lang.NoClassDefFoundError
146 java.lang.NoSuchFieldError
147 java.lang.NoSuchMethodError
148 java.lang.NullPointerException
149 java.lang.Number
150 java.lang.OutOfMemoryError
151 java.lang.Override
152 java.lang.Process
153 java.lang.Runnable
154 java.lang.Runtime
155 java.lang.SecurityManager
156 java.lang.Short
157 java.lang.StackOverflowError
158 java.lang.SuppressWarnings
159 java.lang.System
160 java.lang.Thread
161 java.lang.Thread$State
162 java.lang.Thread$UncaughtExceptionHandler
163 java.lang.ThreadGroup
164 java.lang.UnsatisfiedLinkError
165 java.lang.VerifyError
166 java.lang.VirtualMachineError
167 java.lang.annotation.Documented
168 java.lang.annotation.ElementType
169 java.lang.annotation.Inherited
170 java.lang.annotation.Retention
171 java.lang.annotation.RetentionPolicy
172 java.lang.annotation.Target
173 java.net.InetAddress
174 java.net.NetworkInterface
175 java.net.SocketException
176 java.net.UnknownHostException
177 java.nio.MappedByteBuffer
178 java.nio.channels.AsynchronousChannel
179 java.nio.channels.AsynchronousFileChannel
180 java.nio.channels.ByteChannel
181 java.nio.channels.Channel
182 java.nio.channels.CompletionHandler
183 java.nio.channels.FileChannel
184 java.nio.channels.FileChannel$MapMode
185 java.nio.channels.FileLock
186 java.nio.channels.GatheringByteChannel
187 java.nio.channels.InterruptibleChannel
188 java.nio.channels.ReadableByteChannel
189 java.nio.channels.ScatteringByteChannel
190 java.nio.channels.SeekableByteChannel
191 java.nio.channels.WritableByteChannel
192 java.nio.channels.spi.AbstractInterruptibleChannel
193 java.nio.file.AccessMode
194 java.nio.file.CopyOption
195 java.nio.file.DirectoryStream
196 java.nio.file.DirectoryStream$Filter
197 java.nio.file.FileStore
198 java.nio.file.FileSystem
199 java.nio.file.LinkOption
200 java.nio.file.OpenOption
201 java.nio.file.Path
202 java.nio.file.PathMatcher
203 java.nio.file.WatchEvent$Kind
204 java.nio.file.WatchEvent$Modifier
205 java.nio.file.WatchKey
206 java.nio.file.WatchService
207 java.nio.file.Watchable
208 java.nio.file.attribute.AttributeView
209 java.nio.file.attribute.BasicFileAttributes
210 java.nio.file.attribute.FileAttribute
211 java.nio.file.attribute.FileAttributeView
212 java.nio.file.attribute.FileStoreAttributeView
213 java.nio.file.attribute.FileTime
214 java.nio.file.attribute.GroupPrincipal
215 java.nio.file.attribute.UserPrincipal
216 java.nio.file.attribute.UserPrincipalLookupService
217 java.nio.file.spi.FileSystemProvider
218 java.util.AbstractCollection
219 java.util.AbstractList
220 java.util.ArrayList
221 java.util.Collections
222 java.util.Deque
223 java.util.Dictionary
224 java.util.Hashtable
225 java.util.InvalidPropertiesFormatException
226 java.util.Properties
227 java.util.Queue
228 java.util.Random
229 java.util.RandomAccess
230 java.util.SortedSet
231 java.util.concurrent.Callable
232 java.util.concurrent.ExecutionException
233 java.util.concurrent.Executor
234 java.util.concurrent.ExecutorService
235 java.util.concurrent.Future
236 java.util.concurrent.TimeUnit
237 java.util.concurrent.TimeoutException

[ Reply to This | # ]

Example
Authored by: Anonymous on Friday, May 04 2012 @ 10:08 AM EDT
There is a well known physics simulation library for games
written for the Java platform. Making a good physics
simulation is not trivial and so it is a significant
advantage for a game developer to have access to an existing
library.

Now it happens that Google did implement enough of the Java
API that this library can be used for Android development.

If Google had made their own API the physics simulation
library would need to be rewritten from scratch. Same if
Google had only used the "core"-packages as defined by the
Judge.

Fact is that Google did NOT use the Java API because it was
very "good". They could have made a much better API and
spend less effort doing so too. Take a look at more modern
APIs such as the Scala API, it is so much better than the
Java API that is no contest at all.

So why reuse a date API that is not that good to begin with?
Because it brings compatibility. It brings access to the
Java ecosystem. There are literally millions of Java
libraries out there that can be reused for Android.

In addition to libraries, the decision to go with Java and
its APIs made it possible to reuse whole applications
written for the Java ME platform. There are thousands of
handset models out there that supports Java ME and a large
number of applications. Android is not fully Java ME
compatible so the applications would need to be modified but
most of the code could be reused. All handsets from Nokia,
Motorola, Sony Ericsson and many others have supported Java
ME for at least 10 years.

While SUN created the language and platform, they do not own
the ecosystem. We all do. The Java ecosystem was created by
a huge number of companies and individuals that made
applications and libraries available as opensource. Aside
from Java itself, SUN/Oracle are not even that big a
contributor to this. SUN/Orace are not a major contributor
to the Apache libraries that everyone are using (even
SUN/Oracle are using the Apache stuff!).

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated 2Xs
Authored by: IMANAL_TOO on Friday, May 04 2012 @ 11:06 AM EDT
Some are concerned that an Oracle loss would lead to more overseas outsourcing. That is really not the case, I am afraid. From www.computerworld.com/s/article/82909/Oracle_ to_more_than_double_software_development_staff_in_India :

"Oracle to more than double software development staff in India

Ellison: 'It is not just us. A lot of other companies ... are doing this as well'"
That was in 2003...

Oracle is in fact one of the major US outsourcers. Here is a snippet from an article called, " April 19, 2011 Big U.S. Firms Shift Hiring Abroad Work Forces Shrink at Home, Sharpening Debate on Economic Impact of Globalization", in Wall Street Journal:
The Commerce Department's summary of its latest annual survey shows that in 2009, a recession year in which multinationals' sales and capital spending fell, the companies cut 1.2 million, or 5.3%, of their workers in the U.S. and 100,000, or 1.5%, of those abroad. The growth of their overseas work forces is a sensitive point for U.S. companies. Many of them don't disclose how many of their workers are abroad. And some who do won't talk about it. "We will decline to comment on future hiring or head-count numbers," says Kimberly Pineda, director of corporate public relations for Oracle Corp.[...]

Oracle, which makes business hardware and software, added twice as many workers overseas over the past five years as in the U.S. At the beginning of the 2000s, it had more workers at home than abroad; at the end of 2010, 63% of its employees were overseas. The company says it still does 80% of its R&D in the U.S.

Here are some more reflections on that study.
The Wall Street Journal reports today that Corporate America certainly isn’t doing its part to help bring America out of its economic malaise. The paper surveyed employment data by some of the nation’s largest corporations — General Electric, Caterpillar, Microsoft, Wal-Mart, Chevron, Cisco, Intel, Stanley Works, Merck, United Technologies, and Oracle — and found that they cut their workforces by 2.9 million people over the last decade while hiring 2.4 million people overseas

No-one is taking this message light-heartedly, except perhaps Oracle which took the lead in outsourcing with brute force.


---
______
IMANAL


.

[ Reply to This | # ]

Q5: copyright on "double cos(double)"
Authored by: Anonymous on Friday, May 04 2012 @ 12:01 PM EDT

He asks specifically about cos(), which is even simpler to define the interface for than max(), although the implementation might be more complex at some level or another. This might be deliberate, in which case he's definitely thinking in the right direction for Google.

There really isn't much leeway for declaring cos() any other way than it is. You put an angle in (one floating-point parameter) and get one floating-point result out.

Look at ANSI C89, it uses the same abbreviation for "cosine" and has the same pattern of input and output. Programmers naturally expect essentially the same thing from a new language.

Look at the Am9511 FPU, produced in 1979. While incredibly slow and primitive by modern standards, it still accepts a single argument to it's cosine function and produces a single result, both in what is recognisably a floating- point format. It is essentially the same interface at the machine level as the x87 family FPU provides, and sufficiently similar to the 68881 FPU.

Relevantly, some clever people have produced a pin- and interface- compatible replacement for the Am9511, based on a modern microcontroller. The replacement is faster and consumes less power, but conforms to the same programming and electrical interfaces and is therefore a drop-in upgrade.

More recent FPUs don't provide hardware trigonometric functions, but compilers simply call a library function as expected, instead of issuing a single FPU instruction as an optimisation. This library function is almost invariably as defined by C89 in math.h. Other languages therefore deviate from C89 interface or behaviour in their specification at their peril - and Java is no exception.

[ Reply to This | # ]

Judge Alsup Asks, the US, and the EU
Authored by: Anonymous on Friday, May 04 2012 @ 12:03 PM EDT
Not that I disagree with what is going on in the EU, but I don't understand why
a EU case is being used as a basis for questions to participants in a US Federal
case from a US Federal judge.
Scares me.

[ Reply to This | # ]

I think Lexmark may apply here
Authored by: Anonymous on Friday, May 04 2012 @ 12:25 PM EDT
The Lexmark case showed that an expression which would normally be subject to
copyright protection may be unprotected due to the way in which it was used.

The Java APIs are used in a similar way and should therefore be unprotectable
for essentially the same reason. (Of course, they may not be normally
protectable in the first place, so this is assuming they are; I would argue
strongly that they are not.)

As you may recall, Lexmark put some code (in the form of a ROM) in their printer
ink cartridges and essentially used this in an attempt to prevent third parties
from selling compatible cartridges. A company came along and outright copied
Lexmark's code/ROM and successfully created compatible ink cartridges. Lexmark
sued for copyright infringement with the hope of blocking the third party
cartridges (and thus keeping a monopoly on ink cartridges for their printers).

The court found that Lexmark's code/ROM, used in this manner, was unprotectable
because it was required for correct functionality and compatibility, despite the
fact that the code would normally be protectable.

The Java APIs are required for correct functionality and compatibility with the
Java language and thus are not protectable (even if they would normally be so).

~ray

[ Reply to This | # ]

Friend of the court brief?
Authored by: Anonymous on Friday, May 04 2012 @ 02:51 PM EDT
If this goes to the Supreme Court (as currently seems very plausible) I can't
wait to see who lines up to file amicus curae briefs for and against the
copyrightability of SSO of APIs, and APIs in general.

It's not an overstatement to say that if Oracle wins and the decision stands, it
will turn the entire software industry upside down. The potential repercussions
are absolutely enormous, and I don't think anyone can predict yet the true
extent of the ripples it would cause.

If Google doesn't win, we're all going to suffer. :P

-- A programmer who designed and implemented several original APIs just in the
past week

[ Reply to This | # ]

Judge Alsup Asks Oracle&Google To Brief API/SSO Issue in Light of EU Ct of Justice Ruling on APIs ~pj Updated 2Xs
Authored by: Anonymous on Friday, May 04 2012 @ 02:56 PM EDT

I really like the analogy of APIs to paper forms. I think that it works really well to understand the issues here.

Let us say that you are starting a banking and insurance business. You are old school and will only use paper and deal with cash. You will offer four types of service: a checking account, a loan account, insurance against loan defaults and insurance on loss/damage on items. You prepare a number of forms, like a 'new checking account' form, a 'deposit' form, a 'withdrawal' form, a 'close account' form, etc. The forms have fields, like an 'account number' and 'amount' for the 'deposit' form, and 'response field' where you can record the response to the form (like "account does not exist" or "deposited successfully").

In Java terms, the methods are the forms. The fields on the form are the input parameters on the method and the response is the returned value(s). The services are the classes and the packages are main groups (banking and insurance).

In this case Sun started such a business, and Google decided to start their own very similar one. Google copied all of the forms, but not with a photocopier - they changed the fonts, etc. They kept all of the fields and names the same. Their way of doing business is entirely different though - they have no idea how you store money, etc., but they use all the same business rules, so that if you change to banking with them then you can expect exactly the same interaction.

There is significant creative work in coming up with the forms, because you need to make sure that you always have the right information available. For example, if the form to open a loan requires loan insurance (and asks for your policy number) then the loan insurance form cannot ask for the loan account number, because otherwise you cannot open either... Similarly you have spent a lot of time thinking about exactly which forms are needed, and in what order the client must fill them in. However, you have spent a lot more time building the bank, a vault, computing risk, etc.

So now lets look at some of the Judge's questions:

4. Could Google have come up with different names and SSO yet still have provided the same functionality as in Android? Android users would have had to learn a new vocabulary and a new outline but the methods would all still have been resident in such a modified Android. True? Is this what the UK company Spring did?

They could have used different names. In the UK it would be a chequing account. They could ask for your surname rather than your last name, or your gender rather than sex, or ask for 'last name, first name' instead of 'first last'. But if one can just search and replace the names then there is no creative expression - this is why math cannot be copyrighted, because the names only express an underlying set of facts.

Common sense says the answer is 'yes, they could have', but it would not have been a creative transformation, and would have just confused people. Things have names, and when you use other names, you confuse people, you don't make other things.

5. Is the input-output (i.e., argument and return) scheme of a method copyrightable? For example, can someone copyright the function of inputting an angle and outputting the cosine of that angle? If someone has a copyright on a particular program to find cosines, does that copyright cover all other implementations that perform the identical function (input = angle, output = cosine)?

Can you copyright a form? Not just the physical look and feel, but the actual fields? Is the first person who thought of that clever little plan of the car on a car rental form where you can mark damage (which is also used by body shops, insurance agents, cops, etc.) entitled to limit all other uses of a similar type?

Common sense says 'no'. While the paper copy of a form is copyrightable, the form expresses an idea (open a bank account) which is not copyrightable. Common sense also says that while you might spend considerable time thinking about the form when no-one has done this before, once you start doing it and gain some real world experience, you will quickly find the shortcomings in your design. In practice, people copy forms all the time, and are cursed when they don't copy the good ideas from other forms.

9. What cross-method, cross-class interdependencies exist at the implementation level in Java? Were any of these duplicated in the Android implementations? (The judge remembers no evidence on this point.)

The judge is asking the wrong question here. Interdependency in the implementation is not relevant. This is like asking, "Sun's bank would go under because of a big insurance claim. Would Google's also?". This is not at issue. The judge should be asking about inter-dependencies in the interfaces, like some interfaces requiring objects of certain types. There are considerable inter-dependencies in any API.

But, back to forms. What inter-dependencies exist in the banking model? Lots. Your account opening form has to have a response box for an account number, and the same box has to appear on the other forms. The insurance form also needs this box so you can know where to draw funds. But once again, while you might spend a lot of time thinking about these at the start, you will soon find the right blend. Again, in practice, people copy these things, because they learn quickly.

Regards,
-Jeremy

[ Reply to This | # ]

Spring
Authored by: Anonymous on Friday, May 04 2012 @ 03:19 PM EDT
Loads of UK companies with Spring in their name


SL002419 THE SPRING PARTNERSHIP
02597522 SPRING AND COMPANY LIMITED
07727466 SPRINGA LTD
05949456 SPRINGACE LTD
06999823 SPRINGA CONSULTING LTD.
02660864 SPRINGACRE PROPERTIES
LIMITED
06709225 SPRING ADVERTISING & DESIGN
LIMITED
05783002 SPRING ADVISORY LIMITED
07492200 SPRINGAGAIN CLINIC LTD
03732988 SPRING AGENCY LIMITED
07653243 SPRING AHEAD LTD
07676613 SPRING AHEAD COACHING AND
CONSULTANCY LTD
04467978 SPRINGAIR LIMITED
06634478 SPRINGALEX LTD.
05963287 D SPRINGALL LIMITED
Dissolved
07680324 SPRINGALL LIMITED
07627428 SPRINGALL ALLEN PARTNERSHIP
LIMITED
01352324 L SPRINGALL ASHFIELD LIMITED
in Liquidation
06878058 D THE SPRING ALLIANCE
COMMUNITY INTEREST COMPANY Dissolved
06997570 D SPRING ALLIES UK LIMITED
Dissolved
06554642 SPRINGALLS WHARF RTM COMPANY
LIMITED
06354783 SPRING A. M. LTD
NI056708 SPRING & AIRBRAKE IRELAND
LIMITED
07865293 SPRING & AUTUMN LTD
05100092 L SPRING AND CO. ACCOUNTANTS
LTD. in Liquidation
06405097 SPRING AND COMPANY
(HOLDINGS) LIMITED
05972809 SPRING AND CO. TAX LIMITED
04879963 SPRING & DIALS LIMITED
04301739 L SPRING & GREENE LIMITED in
Liquidation
OC350256 SPRING AND MERCER LLP
01530029 D SPRING AND PRESS
DEVELOPMENTS LIMITED Dissolved
05288266 D SPRING & SUMMER LIMITED
Dissolved
07439880 SPRING & SUMMER LIMITED
04865193 SPRINGANSWER LIMITED
06420693 SPRING ARCHITECTS LIMITED
02088483 THE SPRING ARTS & HERITAGE
CENTRE CO LTD
04205489 D SPRING ASP LIMITED
Dissolved
04282232 SPRING ASSET MANAGEMENT
LIMITED
02491578 SPRING ASSOCIATES LIMITED
05909649 SPRINGATE LIMITED
07878289 D SPRINGBEAT LIMITED
Dissolved
02599614 SPRINGBECK LIMITED
05714393 SPRING BECK LIVERY LTD
07963987 SPRINGBEECH SERVICES LTD
04627754 D SPRINGBEES LTD Dissolved
SC203341 D SPRINGBERRY LIMITED
Dissolved
SC203340 D SPRINGBERRY MINERAL WATERS
LIMITED Dissolved
04092453 SPRINGBEST LIMITED
07194447 D SPRING BIDCO LIMITED
Dissolved
04170337 SPRINGBIG LTD
03464177 SPRINGBIRD LIMITED
06182343 D SPRINGBLAST LTD Dissolved
07530091 SPRINGBLEND LIMITED
06795092 SPRING BLOODSTOCK LTD
06168885 SPRINGBLOSOM LIMITED
05729427 D SPRING BLOSSOM CREATIVE
LIMITED Dissolved
05922702 SPRING BLOSSOM DEVELOPMENTS
LIMITED
07049828 D SPRING BLUE LIMITED
Dissolved
07438181 SPRINGBLUE (UK) LIMITED
03533956 L SPRINGBOARD LIMITED in
Liquidation
07576975 SPRINGBOARD ACCOUNTANCY
LIMITED
06674811 SPRINGBOARD ADULT SERVICES
LIMITED
05213328 SPRINGBOARD ADVISORY
SERVICES LIMITED
07780617 SPRINGBOARD ARTS LIMITED
04367562 SPRINGBOARD ASA LIMITED
03102132 D SPRINGBOARD ASSOCIATES LTD
Dissolved
07992597 SPRINGBOARD ASSOCIATES LTD
03861794 D SPRINGBOARD (BOURNEMOUTH)
LIMITED Dissolved
03747966 SPRINGBOARD-BRIGHTON & HOVE
PERFORMING ARTS LIMITED
01809705 SPRINGBOARD BROMLEY TRUST
04553776 D SPRINGBOARD (BUSINESS
ANALYSIS) LTD Dissolved
04739247 SPRINGBOARD BUSINESS
SERVICES LIMITED
04751316 SPRINGBOARD BUSINESS SUPPORT
LIMITED
07434266 SPRINGBOARD CAMBRIDGE
LIMITED
07400579 SPRINGBOARD CAPITAL LIMITED
07920464 SPRINGBOARD CAREER SERVICES
LTD
07188595 SPRINGBOARD CATERING LIMITED
01904167 THE SPRINGBOARD CENTRE
(COALVILLE) LIMITED
03031621 THE SPRINGBOARD CHARITY
IP24634R C SPRINGBOARD-CHELMER HOUSING
ASSOCIATION LIMITED Converted / Closed
04570841 SPRING BOARD CIRCUITS
LIMITED
04046903 SPRINGBOARD COACHING LIMITED
03031405 D SPRING BOARD COBHAM
Dissolved
07122316 SPRINGBOARD COMMERCIAL
CONSULTING SERVICES [SCS] LIMITED
03171602 D SPRINGBOARD COMMERCIAL LOANS
LIMITED Dissolved
04508776 D SPRINGBOARD COMMERCIAL
SOLUTIONS LIMITED Dissolved
04176825 D SPRINGBOARD COMMUNITY
ENTERPRISES Dissolved
06648502 SPRINGBOARD CONSORTIUM LTD
04729410 THE SPRINGBOARD CONSULTANCY
LIMITED
03821060 SPRINGBOARD CONSULTANTS
LIMITED
05551085 SPRINGBOARD CONSULTING LTD
07557358 SPRINGBOARD CONTRACTORS LTD
05401027 SPRINGBOARD CORPORATE
FINANCE LIMITED
06770207 D SPRINGBOARD COURIER LTD
Dissolved
06208499 SPRINGBOARD CREATIONS
LIMITED
07546050 SPRINGBOARD CREATIVE
EDUCATION LTD
03532540 D SPRINGBOARD CREATIVE
SOLUTIONS LIMITED Dissolved
07444690 SPRINGBOARD CREDIT
MANAGEMENT SERVICES LTD
06717086 SPRINGBOARD DESIGN LIMITED
03715469 SPRINGBOARD DEVELOPMENTS
LIMITED
07619870 SPRINGBOARD DIGITAL LTD
07044271 SPRINGBOARD DRAMA LIMITED
07429932 SPRING BOARD EAST LIMITED
04170149 SPRINGBOARD EDUCATION
LIMITED
04826062 D SPRINGBOARD EDUCATION
DEVELOPMENT LIMITED Dissolved
03340592 SPRINGBOARD EMPLOYMENT &
TRAINING GROUP
07927871 SPRINGBOARD ENTERPRISE
ASSOCIATES LTD
06636001 SPRINGBOARD ENTERPRISES
LIMITED
SC374760 SPRINGBOARD EUROPE LIMITED
02289662 D SPRINGBOARD EUROPE LIMITED
Dissolved
SC331905 SPRINGBOARD EVENTS LIMITED
06525108 SPRINGBOARD EVENTS
MANAGEMENT LTD
06911290 SPRINGBOARD EXECUTIVE LTD
06107074 SPRINGBOARD FITNESS LIMITED
06251103 SPRINGBOARD FOR CHILDREN
07053909 D SPRINGBOARD4 LIMITED
Dissolved
04149312 D SPRINGBOARD 4 BUSINESS
LIMITED Dissolved
06005797 D SPRINGBOARD4IDEAS LIMITED
Dissolved
06251586 SPRINGBOARD FULHAM LTD
04769345 SPRINGBOARD GRAPHICS LIMITED

And so on

Information on all UK companies freely available at
http://www.companieshouse.gov.uk/index.shtml select "company
information"

[ Reply to This | # ]

A question.
Authored by: Anonymous on Friday, May 04 2012 @ 05:20 PM EDT
If Oracle can copyright the use of the class path
structure, then can I copyright the name structure
Fred Bloggs, and charge the government for use of the
copyrighted nameing structure "Fred Blogs" every time
they enter it into any government database
Silly? So is Oracle's claim for copyright protection for
class name paths which people are forced to use in
order to reference names in a compatible way.

[ 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 ) 		Site layout based on Woodlands theme by Bryan Bell.
Groklaw logo by John Crowley.
News Picks logo by Ted Thompson.
Powered By GeekLog
Created this page in 0.06 seconds