|
|
| Oracle v. Google - Further Questions from the Bench on Interoperability ~mw |
 |
|
Monday, May 21 2012 @ 07:20 PM EDT
|
The Court has asked the parties to provide further briefing on the subject of interoperability. (1181 [PDF; Text]) It is unclear whether this line of questioning indicates some likelihood that the Court considers APIs protectable by copyright, but there is certainly that possibility.
In the meantime, the questions being asked by the jury in the patent phase give every indication that the jury is hung on the issue of patent infringement. Numerous times over the last two court days the jury has asked to have the instructions read to them again or to have certain phrases interpreted.
The problem is that, unless that information is already in the trial record, asking the question doesn't mean getting an answer. Moreover, the parties are frequently disagreeing on what the answer should be. Judge Alsup's candid remark to both parties about the dangers of patent infringement litigation never seemed more pertinent.
**************
Docket
05/21/2012 - 1181 -
REQUEST FOR MORE BRIEFING RE INTERFACES, EXCEPTIONS, AND
INTEROPERABILITY. Signed by Judge Alsup on May 21, 2012. (whalc1,
COURT STAFF) (Filed on 5/21/2012) (Entered: 05/21/2012)
**************
Documents
1181
IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF CALIFORNIA
ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.
No. C 10-03561 WHA
REQUEST FOR MORE BRIEFING
RE INTERFACES, EXCEPTIONS,
AND INTEROPERABILITY
1) By noon Wednesday, each side shall please state how many “interfaces” are
included in the joint table supplied a week ago by counsel (Dkt. No. 1124). This
can be on a total basis and need not be broken down by the 37 packages. Also
please state how many “exceptions” were “thrown” and the extent to which they
were duplicated by Google (again on a global basis). Each side should include
one example of an “interface” and one example of a “throw” to illustrate the most
salient points about these features (for a total of four examples). Please explain
the salient point. All information must be in the trial record. Please include cites.
2) With respect to interoperability (Sega / Sony), please state the trial record
evidence on:
A) To what extent, if at all, have applications and programs written for the
J2SE platform before Android arrived been able to run on Android?
B) To what extent, if at all, have applications and programs written after
Android arrived been able to run both on Android and J2SE?
C) How, if at all, have Android and the replication of virtually all of the 37
packages promoted interoperability?
D) To what extent was interoperability an actual motive of Google at the time
the decision was made to replicate the 37 packages?
To the extent practical, please quote the testimony or exhibits in evidence so that
the judge can make his own evaluation. Counsel may add argument but please
quote the evidence.
Please answer both question 1 and 2 by Wednesday at noon in 12 pages or fewer. By Thursday
at noon each side may reply in five pages or fewer.
IT IS SO ORDERED.
Dated: May 21, 2012.
/s/ William Alsup
WILLIAM ALSUP
UNITED STATES DISTRICT JUDGE
2
|
|
|
|
| Authored by: alisonken1 on Monday, May 21 2012 @ 07:32 PM EDT |
Title: Kerrections -> Corrections
Comment: Put the context of the correction here
---
- Ken -
import std_disclaimer.py
Registered Linux user^W^WJohn Doe #296561
Slackin' since 1993
http://www.slackware.com
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 21 2012 @ 07:33 PM EDT |
These are fair questions. Somehow, though, I get the feeling that the tide has
turned on Google. Last week I would've bet Google has this thing locked and
put away. Now it's looking like Oracle might get the last laugh.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 21 2012 @ 07:42 PM EDT |
In my opinion, the questions:A) To what extent, if at all, have
applications and programs written for the J2SE platform before Android arrived
been able to run on Android?
B) To what extent, if at all, have applications
and programs written after Android arrived been able to run both on Android and
J2SE?
...are the wrong questions to ask. Google has said time and again
that they had to implement the 37 packages in order that prior code written to
utilize those packages can still do so.
So I wonder why the judge is now
talking about applications and programs. I just do not understand. [ Reply to This | # ]
|
| |
| Authored by: xtifr on Monday, May 21 2012 @ 07:43 PM EDT |
It sounds like he's missing the point, sadly. This issue is not whether the
programs can interoperate--the issue is whether the programmers can
interoperate. An API is a language, just like the core Java language.
The API extends the language by adding new words and idioms. But in
the end, what you have when you throw in the API is, basically, a bigger
language. And he's already ruled that the language isn't
copyrightable.
---
Do not meddle in the affairs of Wizards, for it
makes them soggy and hard to light. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 21 2012 @ 07:44 PM EDT |
I suspect he's going to have to make a very narrow ruling and wants briefs
covering all the bases. I'm told that there are some very crazy precedents in
his circuit regarding APIs and such, so if he wants to justify ruling against
Oracle, he has a lot of tricky parts to navigate.
My suspicion is that a ruling for Oracle would be a lot easier, so he's writing
a very narrow decision saying that the APIs in this case are not copyrightable.
Getting there will be very hard, though, so it's possible that he'll give up if
he can't make the stretch.
I think he basically needs to be able to show that Google had little choice but
to copy all of this information, therefore, he needs evidence that but for this
Google decision to clone the API, there would be all these broken programs out
there.
This is, of course, nothing but a guess on my part, based on reading a whole lot
of tea leaves. I believe that he knows enough about the tech to know that
copyrightable APIs are bad, but he has to deal with all those crazy rulings in
other cases in his circuit and distinguish them. There's that really nice
Borland case, but it's from the wrong circuit. It's a very good decision, of
course, but how to invoke it while avoiding the crazy precedents and not get
overturned on appeal is very tricky business.
I'm just glad he's trying so hard. I think that's a good sign of a good judge.[ Reply to This | # ]
|
| |
| Authored by: jbb on Monday, May 21 2012 @ 07:55 PM EDT |
Please put the title of the article in your title and a link to the article in
your comment.
---
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 Monday, May 21 2012 @ 07:57 PM EDT |
I suspect the judge may pop in here from time to time. Earlier he asked for
comments on the EU ruling following a posting on that ruling here. Now he asks
for comment on interoperability following an article here which suggests that
Sun/Oracle's stance on this issue is now radically different from what it was.
Isn't this question a wonderful opportunity for Google to get that into the
record.
[ Reply to This | # ]
|
- Hi judge! - Authored by: Anonymous on Monday, May 21 2012 @ 08:43 PM EDT
| |
| Authored by: jbb on Monday, May 21 2012 @ 07:57 PM EDT |
If it's not on topic and it not already a news pick then it should go here.
---
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: jbb on Monday, May 21 2012 @ 07:58 PM EDT |
Thank you for your support.
---
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: jbb on Monday, May 21 2012 @ 08:09 PM EDT |
| The judge is now asking both parties for examples of Java "interfaces" and
exceptions. Here "interface" is a technical term that is one type of element
in an API. I believe the reason this question came up is because last week (or
so) the judge asked both parties to tell him what remained of the API SSO if all
the method declarations were removed. Oracle's (laughable) response was to say
that their brilliant billion-dollar SSO resides in the judicious use and
placement of the "interface" and "throws" keywords because these were the only
things that were left in the APIs after the method declarations were
removed!
---
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 Monday, May 21 2012 @ 08:17 PM EDT |
| The Judge is showing his amatuer programming stripes now.
Most software
development organizations from the smallest 1-man shop upto the largest
companies in the industry do not typicaly buld applications or programs in the
whole.
Most commonly a softare product is structured into various types of
modules/libraries that are built in-house. The libraries have specific
responsibilities like User Interface, Business logic, Integrating with other
parts of the hosting platform or other external systems.
Android's use of the
37 core API's significantly reduces the effort to reuse libraries that are not
tightly depedent on other API's. Many POJO style business logic libraries fall
into this class and enable organiations with existing Java Skills and Library
assets to quickly develop an Android based application based on existing
products. Is this adoption zero-cost? No! But it's a lot lower than having to
rebuild everything from scratch using alternative technologies.
The strict
answer to both A and B is none. But as pointed out in an earlier comment, the
question is too limited. Interoperability has many important dimensions that the
very narrow question does not allow. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 21 2012 @ 08:22 PM EDT |
Question 1 I can't help answer. But here are a few thoughts on 2.
2) With respect to interoperability (Sega / Sony), please state the trial record
evidence on:
A) To what extent, if at all, have applications and programs written for the
J2SE platform before Android arrived been able to run on Android?
All programs compiled for J2SE cannot run as they are on Android. Android uses
a different byte code format and this means that someone with access to the the
original source code for a J2SE application can choose to recompile against
Android/Delvik with a few minor changes. Note that any UI code will have to be
reworked to link to Androids UI libraries. This all means that for many J2SE
apps maybe only 10% of the code needs to be changed and 90% can remain
unchanged. This will vary greatly depending on an applications nature and it's
use of API's that Google choose not to re-implement (because they are less
relevant to Android's mobile market).
B) To what extent, if at all, have applications and programs written after
Android arrived been able to run both on Android and J2SE?
Programs "Compiled" for Android or J2SE cannot be run on the other
platform due to the different byte code systems used. However a program that is
written can be easily worked into two linked versions that share most of the
same code and structure but have different compiling targets. Many of the main
Java development environments now allow you to targeting either J2SE or Android
or both. Note the developer has to write different version of the UI code plus
possibly other sections as well if they want it to integrate properly with
Android.
C) How, if at all, have Android and the replication of virtually all of the
37 packages promoted interoperability?
By replicating most of the core J2SE Packages it has made developers Knowledge,
Java source code and custom libraries largely interoperable with both Platforms.
D) To what extent was interoperability an actual motive of Google at the
time the decision was made to replicate the 37 packages?
The main motive of replicating the Java Packages was to make it easier for
Programmers, many of whom already use Java, to develop for Android and re use
their past Knowledge, code and custom libraries. Google was not motivated to
make compiled J2SE apps interoperable with Android because the many limitations
this would have imposed on Android would have stopped it being inventive or
useful. However it was a core motive to make developers Java source code and
knowledge of Java interoperable with both systems.
Michael[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 21 2012 @ 08:28 PM EDT |
100% of Enterprise Java Applications, arguably one of the most important class
of real world java programs, would not run if you stripped out the XML libraries
and implementatations. Even if you let them try to use all the other JSE
libraries.[ Reply to This | # ]
|
| |
| Authored by: PolR on Monday, May 21 2012 @ 08:38 PM EDT |
> To the extent practical, please quote the testimony or
> exhibits in evidence so that the judge can make his own
> evaluation. Counsel may add argument but please quote the
> evidence.
Is the answer to these question supported by th trial record? I am sure people
here can bring lots of evidence but the judge wants to look at what is in the
record. What happens is the supporting evidence has not been entered in the
record? Do we risk getting a ruling that SSO is copyrightable because of an
incomplete record?
[ Reply to This | # ]
|
| |
| Authored by: bugstomper on Monday, May 21 2012 @ 09:52 PM EDT |
| IANAL, so I wonder without really knowing if the questions about
interoperability point toward the possibility of finding that copying the APIs
come under fair use.
I Googled for 'fair use interoperability' and found
that there are a number of places where they have been connected.
The
Library of Congress exempted jailbreaking of smartphones from the DMCA using the
reasoning described in Fair
Use Lets You Jailbreak Your Phone which says
The EFF and other
commentators suggested this modification is nonetheless permitted because the
handset purchaser owns both the handset and the copy of the software installed
on the handset, and therefore has the right to modify it under section 117 of
the Copyright Act. The Library concluded the state of the "first sale doctrine"
is too confused to conclude this is so. Instead, the Library concluded that
modifying the handset software for purposes of interoperability is a fair use of
the copyrighted software.
The definition of "interoperability"
in the DMCA, where reverse engineering for the purpose of interoperability is
explicitly allowed, says
For purposes of this subsection, the term
“interoperability” means the ability of computer programs to exchange
information, and of such programs mutually to use the information which has been
exchanged.
I can see the ability to use the same source code on
two computer platforms as being at least within the spirit of that definition.
[ Reply to This | # ]
|
| |
| Authored by: shachar on Monday, May 21 2012 @ 11:56 PM EDT |
D) To what extent was interoperability an actual motive of Google at
the time the decision was made to replicate the 37 packages?
I
think this question is so core to the dispute that I, for one, has taken its
answer for granted. I see it as a good sign that the judge thought to ask
it.
Anyone with any experience knows that it's easier to design new APIs
than to implement compatible versions of existing ones. The only reason
to go with the later is interoperability.
My only concern here is that
this is a fact question, and thus, really, not for the judge to
decide.
Shachar [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 12:30 AM EDT |
Why does the judge refer to "applications and programs"?
Do you think the judge sees a difference between an application and a
program? Could we define "program" as an algorithm rather than an
application?
The other thing I noted is he references Sega/Sony. What were the
particulars of that case?
[ Reply to This | # ]
|
| |
| Authored by: indyandy on Tuesday, May 22 2012 @ 01:23 AM EDT |
In case Google wish to emphasise how having a language that is compatible
increases interoperability of programmers they could refer to the 20
08 Sun Microsystems Inc Form 10K
BUSINESS STRATEGY
Our
business strategy is to provide superior network computing infrastructure
solutions that rely on innovation as a core differentiator. A key driver
behind this strategy is the development, integration and sharing of our
software, microprocessors, storage, services and systems in order to grow
communities of developers and users around the world, while increasing
participation on the network and building new markets for our solutions. We
intend to continue to invest in this model, with a focus on the development and
delivery of leading-edge, energy-efficient network computing products based upon
our latest innovations.
With a strong commitment to open standards, open
interfaces and the open source community, we believe sharing and collaboration
is key to our long-term success. We focus on creating communities and
sharing innovations and technologies to foster global network participation and
advance the use of the Internet as a social utility, driving increases in use
and demand for the infrastructure to support that increased use. Our open source
initiatives are intended to increase participation in software and hardware
design by making our innovative hardware and software intellectual property
freely available. A core premise to the success of our software business is
our ability to attract innovative application developers to our Java platform
and Solaris Operating System. We build relationships with these communities of
developers to stimulate demand for our commercial products and services. For
example, more Java technology-driven devices means more demand for what we build
to support those devices. Today, there are billions of Java-enabled devices in
the marketplace. As more people gain access to the network, more opportunities
surface for developers and businesses to deploy applications that create value,
from educational institutions deploying high- performance computing grids, to
banks and social networks serving millions of users. Bringing more people to the
network and encouraging development of community-based intellectual property
fuels greater demand for the innovative technologies and services that we
create.
(My emphasis)
Too late, I know, but it is
probably worth taking a look at this section for general
interest:
PATENTS, TRADEMARKS AND INTELLECTUAL PROPERTY
LICENSES
We have used, registered or applied to register certain
trademarks and service marks to distinguish our products, technologies and
services from those of our competitors in the U.S. and in foreign countries and
jurisdictions. We enforce our trademark, service mark and trade name rights
in the U.S. and abroad.
We hold a number of U.S. and foreign patents
relating to various aspects of our products and technology. While we believe
that patent protection is important, we believe that factors such as innovative
skills and technological expertise provide even greater competitive
differentiation. From time to time we receive assertions that we may be
infringing certain patents or other intellectual property rights of others.
The
action we take with respect to such assertions varies depending on our
assessment of the nature of the particular assertion. When we believe there is a
substantial likelihood that one of our products, component parts, or activities
may infringe a valid intellectual property right of another party, there are
several steps we may take to address such possible infringement, including
securing alternative non-infringing products, designing our products or
activities such that they do not infringe, or seeking a license on commercially
reasonable terms. There is no guarantee that such efforts to remediate any
infringement will be successful or that we will be able to obtain a license or
that litigation will not occur. The adverse resolution of litigation arising out
of such claims could adversely affect our business or financial condition, and
could include injunctive relief that could limit our ability to market and sell
certain of our products.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 06:23 AM EDT |
In tech related cases, the lawyers seem to do everything that they can to ensure
that the jury is clueless as to the actual tech. In most tech cases, the judges
are nearly as clueless as the jury. In this case, the judge thinks that he
understands the tech, and he does have some technical background in programming
in languages other than java.
is it possible that he has fooled himself into believing that he knows the tech
more than the parties, or at least their lawyers? I know that a judge is
supposed to know the law so that they can supposedly apply the law correctly
even when they have been exposed to outside information that a jury would not be
allowed to be exposed to, but what if the judge thinks that he knows the tech
well enough that he lets his own possibly incorrect view of the tech bias how he
interprets the law?
Would it have been better for Google to have gotten a judge that didn't
understand the tech, and knew that he/she didn't understand it?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 06:24 AM EDT |
We saw this in the SCO case also, that the judge tries so hard to be fair that
they invariably come down somewhere in the middle between the two sides.
The problem is that coming down in the middle between truth and lies doesn't
lead to truth, but gives undue weight to the lies.
This is having a knock on effect now with the Jury, who are giving undue
credence to the Oracle expert witness, who I wouldn't trust to tell me the time
at this point. I can't remember exactly when he lost all credibility in my
eyes, but his static vs dynamic definition, and his indexes are symbolic
references arguments seemed transparently obvious lies.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 06:48 AM EDT |
A) To what extent, if at all, have applications and programs
written for the J2SE platform before Android arrived been
able to run on
Android?
B) To what extent, if at all, have
applications and programs
written after Android arrived been able to run both
on
Android and J2SE?
This is interesting. I'm wondering if a
difference in answer
between A and B might be used to suggest a (bogus)
fragmentation argument - ie. Android is pulling java apps
off course by some
kind of malign influence.
Other than that, I can't see where the
distinction between
these is going. It seems like the question doesn't indicate
an understanding of the relationship between J2SE and
Android. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 07:12 AM EDT |
Read it carefully:
"B) To what extent, if at all, have applications and programs written after
Android arrived been able to run both on Android and J2SE?"
"applications and programs written after Android arrived"
Not "applications and programs written for J2SE and Android", but:
"applications and programs".
What's the judge getting at here?[ Reply to This | # ]
|
| |
| Authored by: BitOBear on Tuesday, May 22 2012 @ 11:53 AM EDT |
There is no such thing as "an interface" as a describable and
non-fuzzy concept. Any given function, constant, or exposed varialbe, may
rationally be considered and interface, and so to could any set of same.
"Interface" is what I would call a "purpose word", it is the
name of a kind of thing that is served by domain of intent.
Analogy: Ask a restaurant "how many salads do you serve", is that
unique or by type, if its unique is that on a "typical night" or
whatever. But once you have a "salad bar" the question of unique kinds
of salad becomes irrational. They could -just- have the bar, which offers a wide
variety of "kinds" of salad, and they have their prepared salads. So
is the salad bar one kind or an unbounded set or something in between based on
lists of dressings and common contents (fruit, green, etc).
But the real problem with this order is that it asks a question at the wrong
level of complexity.
It isn't about how many (whole) program interoperability, but how much -code-
interoperates. By definition, since J2SE and Android have different -entry-
-points- none of the "programs" are interchangeable by platform.
On the other hand, a given coding interest may have tens of thousands of
man-hours worth of code either directly in-use or included by library and
feature. All of that code has interoperability value before and after.
There is a reason that formal computer science uses the "subprogram"
term construction.
The record of the case likely offers -none- of this information because the
argument of -fact- made to the jury didn't involve this question.
Plus, lawyers, not being normally competent in the field of computer science
don't know to ask these questions in the first place.
Plus a lot of experts of normal skill in programming have never had to learn or
use the formal construction that the theorists had to develop in order to
properly discuss the topics implied by this question.
Further exceptions are -never- "thrown by" an API. APIs define what
exceptions "might be thrown legally" but it takes running code and
-instance- -data- to "throw an exception". Asking "how many
opossums does this car kill" is about equally valid a question by scope and
significance because, for example, my car can kill as many as I can fit under
the tires, and in front of the air-damn, and yet it has never once killed one at
all.
Further if I declare that a function "throws Exception" it could throw
any sub-class of Exception so the one specification "in the interface"
is a stand in for a potentially infinite number of actual exceptions.
Snarky Aside: API's cannot be subject to copyright protection because they are
not subject to rationally fixed legal definition. They are, in real world paper
speak, the file folder tabs that stick up, not the folders nor the files
themselves. They are necessary for good funciton but they are not a fixed
thing.
Things that are unfixed by definition, cannot be "fixed in a medium".
Sure we can write them down, but they are completely dependent on the real
thing. Going back to the classic phone directory thing, the actual list of names
and numbers is determined by who lives in the area and what they buy. Someone
moves, or adds or cancels their phone service, or changes the directory. You can
print out the directory as a book at any time, but it is obsolete the moment you
print it because the "fixed" copy is a snapshot of the reality
depicted at the moment. In fact, by the time the book form is printed it is
probably invalid due to churn.
So when you have "API files" on paper or disk, these are condensations
of aether, representative of the code that did, may, or will hopefully exist.
That -code- that did, may, or will exist is valid copyright fodder (IMHO) but
this condensation of the "interface" into a file etc is not even the
cliff-notes for the thing.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 12:00 PM EDT |
Quite often there's the speculation a Judge rules the way s/he does in order
to decrease the chances of appeal.
Judge: I don't agree with either
of you. I will give my own answer, and you can address it on
appeal.
I think that response pretty much clarifies this particular
Judge is not concerned with whether or not an appeal occurs.
As a result,
I think it's more likely any of his choices are based on fairness - as well as
the particular portions of Law - he sees in the situation.
Caveat: the
quote is extracted from the notes of Day 21. It'll be interesting to see the
actual transcript to see if that's exactly what Judge Alsup said.
RAS[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 12:11 PM EDT |
Ginny LaRoe @GinnyLaRoe
Time for our first jury note of the day in #googacle.[ Reply to This | # ]
|
| |
| Authored by: feldegast on Tuesday, May 22 2012 @ 12:14 PM EDT |
normally i'd say follow my tweets here
https://twitter.com/#!/Feldegast
https://twitter .com/#!/Feldegast/oracal-vs-google-trial
the 2nd link is ok but it looks like the only reporter there
today is and i am not going to be available today
https://twitter.com/#!/GinnyLaRoe
Ginny LaRoe ‏@GinnyLaRoe
Time for our first jury note of the day in #googacle.
---
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 Tuesday, May 22 2012 @ 01:49 PM EDT |
Compatibility per se doesn't matter if programs written before Android can't run
on Android phones if they weren't written to run on Android phones (and may
access hardware that isn't found on cell phones). If you try to run them on
Android phones, they may run but there's no guarantee that you'll get useful
results, i.e. they may need to be modified if they are useful to run on
Android.
Basically a program language is just a lot of API like specifications, the
language is the (application) programming interface between the human
programmer, the human user and the computer micro code.
So, why would I, or anyone, write a program? Because we have an objective, to
provide an 'application' useful to a user. For example, the objective may be as
simple as adding two numbers to get a resulting total, the interface
specifications are de facto, that is, I have to create a line of code that
specifies the two inputs and the single output (and an output for communicating
errors if any occur). For example x = a + b. This sounds like what you have to
do to use an API, but since it's 'built into' the language, it's not called an
API. It's built into the language because it's 'used a lot' (reusable code!).
Obviously there have to be preceding lines of code that fill the variables 'a'
and 'b' with values. Normally there also have to be lines of code to do
something with the result (display | print | Display & print) that satisfy
my objective. And probably I'd provide lines of code to examine the values to
verify that they are valid for my objective and reject and notify the user if
they are not.
If the language doesn't provide 'built-in' keywords then what we speak of as
APIs can be created, as external, reusable mini-programs (black boxes), stored
outside my source program (black box)and outside the language program (black
box). As another poster said, we do that to extend the 'reusable code' of the
language. The fact that some APIs will be used more than other APIs doesn't
matter, we create them if it makes sense because the code will be used in more
than just a single program.
These 'external' APIs follow the same rules as keywords. They expect the
programmer to specify input (if appropriate) and output (if appropriate). Why do
I condition this as being 'if appropriate'? The program code of the API (the
black box) may not need input, it may only provide output (time of day). Or it
may need input but not provide output back to the program which calls it. Etc.
Etc.
Google chose to take advantage of the large pool of Java programmers that might
be persuaded to write programs for Android phones rather than write a new
language and all that that would entail. Google wrote all the code in the black
boxes in a clean room meaning that they did not copy the black box code from
Java. But the rules for using the Android black boxes had to be the same as the
rules for using the Java black boxes to facilitate the dependency on the Java
programmer pool resource. Therefore the names of the APIs had to be the same,
the input and output specs had to be the same UNLESS Google created a new API
that didn't exist in Java, then they could do whatever made sense.
Since the 'names are the same', the packages, classes, methods and where they
all resided had to 'be the same' to the extent that everything needed for
Android was included. The sequence and grouping is simply a by product of what a
sensible person would expect to facilitate the use of the APIs.
Does Android's black box infringe '104'? I read the claim as requiring the
'translation' from a 'symbolic reference' to a 'numeric location' to be done
dynamically which means that the translation occurs when a user runs a program
via a VM and the VM does the translation, even if only once per run, but it does
it every time the program is run by the VM.
Google's dexopt does the 'translation' statically i.e. only once (or, more
precisely, every time the program is changed including newly created, but
essentially only once if never changed) before it's run by the VM. The DVM does
not need to do and therefore does not do the translation dynamically when the
program is run by the user.
The '520 claim is static initialization of arrays using 'simulation' vs. Googles
'pattern matching'.
Simulation means pretending to run the code.
Pattern matching means reading the code to determine if the code meets the
pattern for 'initializing a static array'.
Dex is looking for 'x' lines of code which say 1) an array should be created, 2)
it should be filled with static values and 3) provides a 'path' to the stored
values that will be placed into the array. In any static array, the values
could be 'anything required' to meet the objectives of the program and could be
as simple as an array with 26 constants filled with "a",
"b", "C",...."z".
If for example there are normally 4 lines of code to meet the above criteria and
dex finds exactly 4 lines of code that fit the 'pattern for initializing a
static array', then dex translates and optimizes it. If there are other than 4
lines of code or the pattern is not the one for the 'initialization of a static
array' as dex knows it, dex does not translate, dex just 'copies it'.
I'm not a lawyer or a Java programmer, I'm an avid reader of everything Groklaw
and I've tried to express my conclusions after reading (almost) everything about
this case. If what I've written is incorrect, please tell me. Otherwise it seems
that Google should prevail on all counts, including the de minimis copying.
I wish that I was on the jury.
JWC
[ Reply to This | # ]
|
| |
| Authored by: Ian Al on Wednesday, May 23 2012 @ 06:21 AM EDT |
I view the discussions about 'interfaces' and 'exceptions' being 'thrown' rather
like a New Yorker confronted with many people playing patball.
rangeCheck taught me that a throw was the return of an error message. I infer
that an 'exception' might be an error condition. I seem to remember that
'interfaces' were to break the single inheritance model in the original Javas
into a multiple inheritance model.
The consequence of the judge declaring that the functionality and the function
names and short phrases in an API are not protectable, but that the SSO of
'interfaces' and the 'throw's of 'exceptions' are protected almost makes me want
it to happen!
How are we to identify the protectable API SSO of the 'interfaces', 'exceptions'
and 'throws' in, say, Python? Python has multiple inheritances. Are these
'interfaces' which have had their SSO copied from the Java APIs? In a hall of
4,327 top computer scientists, how many would say they are and how many would
say they are not?
Do the APIs have to be in thousands of files to create the SSO or are the Python
module files and class files sufficient to prove copying? How is the copying
demonstrated?
How about C++, C# and the other related languages with APIs?
If the judge says that the SSO of these three elements are protectable by
copyright, the entire US computer science fraternity will have to down tools
until this ground-breaking issue is resolved.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | # ]
|
|
|
|
|
