|
Authored by: Anonymous on Monday, April 23 2012 @ 12:04 PM EDT |
Ars is reporting that google have
responded as follows:
UPDATE: We received a statement from Google stating that
"The USPTO ruling is on the prior art that was submitted at that time, not on
the inherent validity of the patent itself. It is important to note that
Judge [William] Alsup ordered the '702 patent dropped with prejudice from this
case." The USPTO decision does note that the Oracle patent's claims "are
confirmed over prior art presented in this reexamination." But Google can still
argue at trial that patents are invalid and should not have been issued, even if
claims made in the patents are confirmed as "patentable." (my emphasis)
does with prejudice mean Oracle cannot re assert it?
[ Reply to This | # ]
|
|
Authored by: nsomos on Monday, April 23 2012 @ 12:17 PM EDT |
Please post any corrections here.
A summary in title may be helpful.[ Reply to This | # ]
|
|
Authored by: jvillain on Monday, April 23 2012 @ 12:32 PM EDT |
In the second motion (959 [PDF; text to follow]) Oracle seeks a
clarifying instruction to the jury regarding Apache Harmony. Specifically,
Oracle asks that the jury be instructed that: (a) Apache never obtained a
license from Sun permitting the use of the Java specifications; and (b) as a
consequence, Apache had no rights to convey to Google.
Before
the judge could buy into that wouldn't there have to be testimony from some one
in the Apache group that they didn't have a licence? Maybe they think they do.
No one has called any one from Apache yet unless I missed it. I am sure some one
there would love to tell their story. [ Reply to This | # ]
|
|
Authored by: artp on Monday, April 23 2012 @ 12:38 PM EDT |
Other than this topic of Weekend Filings.
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
|
Authored by: artp on Monday, April 23 2012 @ 12:44 PM EDT |
URLs, please.
Even though new News Picks comments will tend to go on the
most recent story. Might as well finish the job. Sort of like
the Comes transcriptions, eh?
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
|
Authored by: artp on Monday, April 23 2012 @ 12:47 PM EDT |
For transcripts of those evil bitmapped court filings from
the "Comes v MS" link above.
If you are a rebel, and don't like authority, then put your
transcripts here instead of on the Comes thread on the most
recent story. Strike a blow for freedom! Okay, maybe just a
small pat for freedom.
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
|
Authored by: Ian Al on Monday, April 23 2012 @ 01:04 PM EDT |
I wonder if this is on the judge's mind. He asked how many APIs were essential
to program in the Java language. Oracle replied that there was a small handful.
Now the judge is asking if that small handful, in turn, depends on a bigger
handful. Is he wondering if he will end up with his hands full of the entire API
Specification implementation, once all of the interdependencies are considered?
Or, perhaps, just 37 packages?
Personally, I would have gone with 42.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, April 23 2012 @ 01:39 PM EDT |
I am slowly getting annoyed by the apparent constant confusion of GPL with
public domain in the arguments here.
Sun licenced Java under the GPLv2. Google publishes the Java parts of Android
under the Apache license. If they copied parts that Sun licensed under GPLv2,
that did not, repeat not, entitle them to release them under the Apache
license.
So where is the point in making such a brouhaha about the GPLv2 release and
Oracle pointing to it? That does not imply a distribution license under
incompatible terms for Google.
If literal copying and rereleasing under the Apache license has happened, the
GPLv2 did not give permission for it.[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, April 23 2012 @ 01:40 PM EDT |
Could the ex-SCOx lawyers really be copying their work products from the SCOx
case and reapplying them to the Oracle .vs. Google case? Maybe... All that legal
work down the drain. A new judge and a new case...
Really? APIs and ABIs are SCOx's backdoors to copyrighting UNIX. That turned out
to be a big flop!
For example, SCOx argued US common law permits function signatures like
"add(x, y);" in an API or ABI to be copyrighted. That way is insanity
because by reduction to absurdity US common law would be copyrighting specific
words in the context of all software. APIs and ABIs turned out to be standards
that SCOx could not claim copyright.
Programmers use APIs to communicate via files with other programmers and also
with running compilers. Plugging your software into other people's software so
they run together is a big problem, and APIs/ABIs efficiently describe the
standard public plugs.
Perhaps US common law should instead distinguish static source or binary code on
one hand from running live code on the other hand. Then it appears obvious that
APIs and ABIs are necessary to the structure, function, and processes that all
programmers control. It also appears obvious that no API or ABI could be
copyrighted or patented as isolated artifacts. Instead, protect the API/ABI
referenced library (aka framework), driver, utility, OS, or VM.
Further, I suggest that US common law define the purposes of programmer,
compiler, program, library, kernel, driver, virtual machine, operating system,
linker, loader, and OS utility. This could keep foolish lawyers out of tar pits.
Judges would be protected from specious arguments by foolish lawyers.[ Reply to This | # ]
|
|
Authored by: tknarr on Monday, April 23 2012 @ 01:52 PM EDT |
What efficiencies, if any, are obtained by grouping methods or
fields together under a single class? Put differently, what would be lost if a
method that returned the cosine of an angle was grouped under a class other than
Math? This discussion should get the pros and cons of the particular
interrelationships (e.g., inheritance) within the 37 API
packages.
When the judge asks this, the answer has two
parts.
When the original creator goes to assign classes, the answer is
"Little or none.". Whatever package the class goes into, it doesn't make a lot
of different what the package name is. At most if you place it in a package with
a lot of other stuff you pull everything else in that package in along with the
cosine function, plus everything all that other stuff needs, and that whole
combination may be more than developers want. You don't want your program to
fail because you don't have an XML parser configured just because you want the
cosine function and it's in the same package as the XML parsing. But that
basically amounts to "Group related stuff together, and don't mix it with
unrelated stuff.". The exact names don't matter, only the grouping.
But
once the original creator's laid down the grouping and assigned package names,
anybody else wanting to provide their own implementation of that API
must use exactly the same package structure and class names and
place everything exactly where the original creator did. It's like a window:
when you build the house you can make the windows any size you want, but once
the house is built if you go to replace a window you must use exactly the
same size window as originally used otherwise your replacement window won't fit
in the hole in the wall. If you don't use the same name, user code written using
that same name won't see your different name and will fail to compile. If you
don't place your stuff in the same packages, code written to import the original
packages won't import yours (or won't import all the right ones) and will fail
to compile. Where the original creator had flexibility, you're constrained to
follow his choices if you want to expose exactly the same interface to users.
And if you don't expose exactly the same interface, user code won't compile
against your implementation.
The question is, if someone else has created
an API then do you have a right to create your own implementation of that API
without needing permission from the creator? This is the question Oracle wants
to dodge, because all the case law from the seminal IBM BIOS and Lotus 123 menu
interface cases says "Yes you can. You just can't copy their code itself.". And
that's fatal to Oracle's case. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, April 23 2012 @ 01:57 PM EDT |
What efficiencies, if any, are obtained by grouping
methods or fields together under a single class? Put differently, what would be
lost if a method that returned the cosine of an angle was grouped under a class
other than Math? This discussion should get the pros and cons of the particular
interrelationships (e.g., inheritance) within the 37 API
packages.
Quite frankly, the original order is not quite clear
with regard to what he is looking for. Is he looking for relationships in the
"specifications" or in the "implementation." This distinction (specification vs.
implementation) will likely continue to plague this
trial.
Sounds as if he is trying to find out how much of the
design is predetermined when designing an API.
The problem is that
"System.math" have been used as the standard example all along for simplicity
and that class is quite special in that it is static (and all its methods and
fields are static). I guess the Judge really want to be a Java programmer before
this case ends :) Normally you make instances (i.e. object) of a class and the
normal primary reason to "[group] methods or fields together under a single
class" is not "efficiencies" but rather "information hiding", i.e. that only the
methods that need access to the private data (i.e. fields only accessible to the
methods in that class) are placed on the class.
But the discussion about if
API design is hard or not (it is), or creative or not (it is), or if the API
could have been designed another way (it could) is rather irrelevant. Google
didn't want to design a new API and they haven't claimed that they have tried,
they wanted the Java API since that is what would be familiar to Java
programmers. Therefore, they were forced (by their own desire for familiarity)
to use the (subset) of the Java API (warts and all).
AH [ Reply to This | # ]
|
|
Authored by: DannyB on Monday, April 23 2012 @ 02:41 PM EDT |
> what would be lost if a method that returned
> the cosine of an angle was grouped under a class
> other than Math?
Compatibility.
That is what would be lost. Every piece of software that had ever been written
to assume the cos() function was under Math would now be broken and non
functional. An "asteroids" game for example (which uses
rectangular/polar conversions, and therefore Math.cos).
---
The price of freedom is eternal litigation.[ Reply to This | # ]
|
|
Authored by: eachus on Monday, April 23 2012 @ 02:49 PM EDT |
Speaking as a compiler guru not as a copyright lawyer, the
intent of the
classpath exception is to allow programmers to
use the classes covered in their
programs without having to
issue their work under the GPL. It seems to me that
using the classes requires using
the APIs in their source code. In
other words, even if some
sort of copyright could stick to the APIs, the GPL
classpath
exception seems to wash all contamination from using the
APIs.
What about re-implementing the classes? It would be
perverse to
say that you can freely use the APIs, and their
implementations, but you can't
re-implement them. The law
can, of course, be perverse, but to the extent that
this
case is writing (and must write) new law* in this area, it
would be nice
to have "free to use" mean free to use when it
comes to implementing compilers
for languages.
Why? When implementing a compiler, interpreter, or virtual
machine for a programming language, it is common to write in
the language
being implemented. This limits the number of
language contexts you need to
hold in your head. My
wife used to complain, if she called me at work, I could
be
thinking in three languages--none of which was English. ;-)
* Yes,
new law. 90% or maybe 99% of this case could be
decided based on existing law.
If the court holds that APIs
are not subject to copyright, then this case
might
just determine what a Java API consists of. (Of
course, IMNSHO if
the court decides otherwise, this case
will drag out longer than the SCO saga.) [ Reply to This | # ]
|
|
Authored by: SLi on Monday, April 23 2012 @ 04:13 PM EDT |
In [955, page
2]. This is related to the definitions on
APIs.
I think if we took PJ's
friend's definition for API, what Google
says here
would be nonsense; the
signatures (including the packages, all
the SSO) are identical, therefore the
APIs are identical. I
actually agree with Google says here.
But
the selection and arrangement of APIs elements cannot,
standing alone,
support
a copyright infringement verdict. If, for the 37 APIs at
issue, Google had
substituted
APIs that had exactly the same structure, selection and
organization as the Oracle APIs, but that
did different things, the resulting
work as a whole would not be
substantially similar. For
example, if every
method always returned the same result,
regardless of what inputs were
provided
(e.g., a zero for methods with numerical results, an “a”
for those that return
strings,
“true” for those that return true or false, and so on), the
resulting
APIs would not be substantially
similar, notwithstanding having precisely the
same structure,
selection and organization as
Oracle’s APIs. The true premise
of Oracle’s claim is that the
Google APIs do the same thing
that
The point to get is that API is not merely the
signatures;
it's also the "contract" or the understanding of what the methods
actually do. Even if you keep all the signatures identical, but
change the
outward behavior, you are breaking the API.
Using the old car analogy, if
you changed the order of the
pedals, or changed the steering wheel so that when
you turn it
left, the car turns right and vice versa, you are changing the
API
even if the method signatures (the appearances of the pedals
and the steering
wheel) are identical.
For my explanation of what an API is, where I draw
from
Wikipedia and explain this too, see this
comment. Essentially,
the API is the signatures + the understanding of how
the methods
should be used (but see the above comment for elaboration). [ Reply to This | # ]
|
|
Authored by: SLi on Monday, April 23 2012 @ 04:41 PM EDT |
From Google's brief (955):
Because of the registration
requirement, only
“copyrighted works”—i.e., works in which
the owner’s
copyright claim has been registered—can be the
subject of a claim of
infringement.
The Act uses the phrase “copyrighted works” throughout section
106—which defines the
exclusive rights of the owner of a “copyrighted work”—and
in
other sections, including section
107, which provides that the fair use of a
copyrighted work is
not an infringement. 17 U.S.C.
§§ 106,
107.
I don't actually think the Copyright Act supports the
notion
that only a registered work is a "copyrighted work". [ Reply to This | # ]
|
|
Authored by: xtifr on Monday, April 23 2012 @ 04:48 PM EDT |
I'll take a stab at the good judge's questions.
1. The question is
ambiguous. An API is just a set of names, and none of the names "call
upon" other names. However, Sun's implementation of the APIs
definitely includes procedures that use the API. It's impossible to write any
useful program in Java without calling some of the API, and Sun's
implementation of the API consists of small Java programs
(subroutines).
2. Once again, if we're talking about the accused APIs
themselves, the answer is no, since the APIs don't call anything. For the
implementation behind the APIs, the answer is almost certainly yes in
most cases, since most of the APIs refer to well-known algorithms whose most
efficient implementation is a matter of general computer science. The
implementation of the same algorithms in other languages like C++ almost
certainly use the equivalent APIs in those languages in more-or-less
the same way. This is a functional requirement, not a creative one.
3.
Ok, here I'm reduced to guessing, but if the 37 APIs in question can stand alone
(as they do in Android), then there's probably no functional requirements for
any other APIs there, so the answer is probably not.
Bonus question: no
efficiencies are gained or lost by the arbitrary choice of a name. In the case
of a class or procedure, the name is purely arbitrary, and there is no
functional different between science.sqrt and math.square_root, except that
programs expecting to find math.sqrt would not locate either one.
There
is a practical limitation on the names, though. Methods of a class must be part
of that class. For example, if you have a list class called Collections.List,
which has methods called append, search, and truncate, the names of those
methods must start with Collections.List, so that when you have an
instance of a list, e.g. a list named "lawyers", you can say
"lawyers.append("Michael Jacobs")", and the compiler will know which method to
use by referring to the class of the object "lawyers".
--- Do not
meddle in the affairs of Wizards, for it makes them soggy and hard to light. [ Reply to This | # ]
|
|
|
|
|