|
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 | # ]
|
|
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 | # ]
|
- Jury may be deadlocked in Oracle-Google trial - Authored by: Anonymous on Thursday, May 03 2012 @ 07:58 PM EDT
- Jury may be struggling in Oracle-Google trial - Authored by: Anonymous on Thursday, May 03 2012 @ 08:06 PM EDT
- More jury questions, hair-splitting in Google v. Oracle - Authored by: Anonymous on Thursday, May 03 2012 @ 08:26 PM EDT
- Software industry reclaims open standards debate - Authored by: Anonymous on Friday, May 04 2012 @ 02:41 AM EDT
- Yahoo's so-called CEO and lying on a resume - Authored by: Anonymous on Friday, May 04 2012 @ 10:10 AM EDT
- News picks - Authored by: Anonymous on Friday, May 04 2012 @ 11:31 AM EDT
- News picks - Authored by: Anonymous on Friday, May 04 2012 @ 11:35 AM EDT
- Nokia - Authored by: Anonymous on Friday, May 04 2012 @ 06:04 PM EDT
- Judge Alsup on what to do if jury is deadlocked - Authored by: Anonymous on Friday, May 04 2012 @ 12:03 PM EDT
|
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 | # ]
|
- To describe Judge Alsup's request in a word: - Authored by: Anonymous on Thursday, May 03 2012 @ 06:46 PM EDT
- we win? - Authored by: Anonymous on Thursday, May 03 2012 @ 08:34 PM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 08:39 AM EDT
- Not so certain - Authored by: Winter on Friday, May 04 2012 @ 08:50 AM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 09:07 AM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 09:37 AM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 10:22 AM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 10:19 AM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 10:00 AM EDT
- Not so fast - Authored by: BJ on Friday, May 04 2012 @ 01:30 PM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 10:36 AM EDT
- Not so certain - Authored by: Anonymous on Friday, May 04 2012 @ 11:03 AM EDT
|
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 | # ]
|
- politics explained - Authored by: Anonymous on Thursday, May 03 2012 @ 06:47 PM EDT
- A very good example of newspeak - Authored by: mbouckaert on Thursday, May 03 2012 @ 07:49 PM EDT
- GIMP 2.8 released - Authored by: Anonymous on Thursday, May 03 2012 @ 09:28 PM EDT
- Flashback could be as bad as Blaster - Authored by: Anonymous on Thursday, May 03 2012 @ 11:11 PM EDT
- Judge Rules IP Addresses Are Insufficient Evidence To Identify Pirates - Authored by: SpaceLifeForm on Friday, May 04 2012 @ 06:04 AM EDT
- Bad Posting Form? - Authored by: Anonymous on Friday, May 04 2012 @ 10:26 AM EDT
- no - Authored by: Anonymous on Friday, May 04 2012 @ 10:28 AM EDT
- no..?!? - Authored by: Anonymous on Friday, May 04 2012 @ 11:59 AM EDT
- Yes - Authored by: Anonymous on Friday, May 04 2012 @ 10:52 AM EDT
- First to post - Authored by: artp on Friday, May 04 2012 @ 12:23 PM EDT
- First to post - Authored by: Anonymous on Friday, May 04 2012 @ 02:30 PM EDT
- Feds Seized Hip-Hop Site for a Year, Waiting for Proof of Infringement - Authored by: Anonymous on Friday, May 04 2012 @ 10:33 AM EDT
- Nokia Sued for 'Fraud' Over Windows Phone Sales - Authored by: Gringo_ on Friday, May 04 2012 @ 01:01 PM EDT
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
- Tweets from the courtroom - Authored by: feldegast on Thursday, May 03 2012 @ 06:47 PM EDT
- Tweets from the courtroom - Authored by: feldegast on Thursday, May 03 2012 @ 06:48 PM EDT
- Hmmm. - Authored by: OmniGeek on Thursday, May 03 2012 @ 06:59 PM EDT
- Hmmm. - Authored by: jvillain on Thursday, May 03 2012 @ 07:04 PM EDT
- Hmmm. - Authored by: Anonymous on Friday, May 04 2012 @ 01:04 AM EDT
- Hmmm. - Authored by: Anonymous on Friday, May 04 2012 @ 01:05 AM EDT
- Tweets from the courtroom - Authored by: feldegast on Thursday, May 03 2012 @ 07:08 PM EDT
- Tweets from the courtroom - Authored by: feldegast on Thursday, May 03 2012 @ 07:09 PM EDT
- Jury released for the day - Authored by: Anonymous on Thursday, May 03 2012 @ 07:17 PM EDT
- Tweets from the courtroom (Friday) - Authored by: feldegast on Friday, May 04 2012 @ 11:00 AM EDT
- Tweets from the courtroom (8am hearing) - Authored by: feldegast on Friday, May 04 2012 @ 11:03 AM EDT
- Tweets from the courtroom - Authored by: feldegast on Friday, May 04 2012 @ 11:18 AM EDT
- Tweets from the courtroom - both sides only care about the first jury Q - Authored by: feldegast on Friday, May 04 2012 @ 11:20 AM EDT
- Tweets from the courtroom - going to receive a partial verdict - Authored by: feldegast on Friday, May 04 2012 @ 11:30 AM EDT
|
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
|
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 | # ]
|
|
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 | # ]
|
|
Authored by: Anonymous on Thursday, May 03 2012 @ 06:58 PM EDT |
http://web.mit.edu/java_v1.0.2/ [ Reply to This | # ]
|
|
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 | # ]
|
|
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:
- 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.
-
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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
|
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 | # ]
|
- Question 11-B - Authored by: Anonymous on Thursday, May 03 2012 @ 11:59 PM EDT
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 @ 08:31 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
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
- No! - Authored by: jbb on Thursday, May 03 2012 @ 11:16 PM EDT
- No! - Authored by: BJ on Friday, May 04 2012 @ 02:54 PM EDT
- #6 - Authored by: PJ on Thursday, May 03 2012 @ 11:24 PM EDT
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
|
|
|