|
|
|
| Authored by: sd_ip_tech on Monday, May 21 2012 @ 08:33 PM EDT |
I wonder if he is trying to determine the damages to JAVA by the Android fork. I
can't remember is Oracle made this claim or not. But IF there is no damage then
it favors Google and we are left with rangeCheck(). OTOH, maybe he is close to
API decision as well and IF the fork does not alter APIs it is a win for Google
also.
---
sd_ip_tech[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, May 21 2012 @ 09:19 PM EDT |
But, if one wants to create a language and libraries which have some
affinity to programs written in a prior language or with the knowledge and
experiences of programmers well-versed in the prior language, with the
emphasis on the programs, this is not doable except reference is made to the
documentation surrounding the older language and its libraries. Looking at
something and writing it down again in another place is copying. Did
Google copy something that cannot be protected? Or was the copying related to
interoperability, and arguably fair use? I think you're going to find
some difficulty in explaining what "interoperable with programmers" means.
Programmers read documentation, write source and provide it to an interpreter
or compiler. Beyond that, interoperable for programmers feels a little
bit like saying translating a Russian novel into English is fair use and the
original author cannot seek infringement damages. After all, didn't we just
make that novel interoperable with the US reader? Interoperable
should
mean something like the following. You have a black box and I have a gray box.
You
provided an api to your black box and I would like my gray box to work
with it.
So I look at your APIs and extend the functionality in my gray to
include a
bridging mechanism. Under this situation, I may use and copy your
apis for
interoperability. Or
put another way, my gray box code is not
elevated into an unlicensed derivate
work because it makes reference to some of
your apis. You left them there
because you wanted programmers like me to have
programmic access..
Now, let's pretend I'm Google and the Android phone
is my gray
box. What's the black box it needs to operate with? The java
language. No, it's
not a black box. It's an api to an application called the
jvm. The jvm then? No,
because Android does not interface to the
jvm. Let's invert it. Let's say
that the point was to have java programs
written without reference to Android
to run in Android and let's say that is
Google's claim to fair use. The question as
to how many unmodified java
programs could run in Android is on point to that
claim. Unfortunately,
that question is unanswerable. Just now I
counted all the instance of "public
static void main" on my computer. ( I piped
find '*.java' to grep -ni 'public
static void.*main", write it to a file and ran wc -l.)
It's not an unreasonable
methodology as a java program has to have one class
with that method
implemented. Now this overlooks all the java code I've
archived over my 12
years of using the language. It also counts all those times I
wrote a main
method to test intermediate code. My answer: 3,275. And I'm a
semi-professional. So here's the point. Ironically Google would have
had
to copy more of the documented packages, classes, methods, and
signatures in
order to have 100% interoperability. They copied a core, the
axioms, if you
will, so that they could build a library tailored to the constrained
hardware
of a mobile phone. As a result, the interoperability percentage is not
very
high. (And I imagine it takes 95% of the work to implement the last 5% of a
fully interoperable library.) If Google answers honestly, and I do not
see any reason to think they would not, they would say that interoperability
was
not a significant factor behind the replication of the 37 packages and
their
included classes, methods, and signatures. This is okay. Google's best
chance is
that the documentation serves as a reference and using the reference
is not
infringement, whether it was done over days or years or was to write a
program,
a textbook on the language, a book showing examples of using the
language,
or a new language with some affinity to the old one.. [ Reply to This | Parent | # ]
|
| |
| Authored by: PolR on Monday, May 21 2012 @ 09:44 PM EDT |
> This issue is not whether the programs can
> interoperate--the issue is whether the programmers can
> interoperate.
I disagree.
Programmers can always learn a new vocabulary. They can always run scripts to
rename methods in old programs. This is annoying but if the argument is to
remove annoyance Oracle wins. Annoyance does not make software elements
uncopyrightable.
But if the programs don't interoperate then it means the APIs are functional and
this is what matters legally. Functional items are not copyrightable by law.
IANAL, If someone knows better please correct me.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 12:33 AM EDT |
They don't add new words or idioms to the language. And API's are not about
"programmer interoperability". API's specify how a program should
behave so that it can operate in any environment that "understands"
the API.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 07:28 AM EDT |
all questions are answered against Google. yet i think this will not affect the
outcome of the case.
the questions all relate to fair use. but the the most important question is
about ability of apis to be copyrightable in themselves(also their structure
& arrangement ...sic).
these questions are to effectively answer all points raised by oracle in
judgement. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 22 2012 @ 12:28 PM EDT |
In this comment, jbb
mentions in passing something that I
think makes a good
analogy:
Releasing incompatible core APIs would
have
truly fractured the Java community. It would have been very
difficult for
developers to switch between using Sun-Java
and using Android-Java. There would
be almost no code reuse
between the two systems. Anyone who tried to switch from
one
to the other would generate tons of bugs as they tried to
get their fingers
accustomed to the new system. It would be
like changing around the keys on the
keyboard. You could
eventually get used to the new layout but the
transition
would be difficult and your productivity would plummet every
time you
switched from one to the other.
The keys on a keyboard are an
API that nearly everyone
reading this site will be familiar with.
Different
computer languages may have similar syntax, like
Java shares much of its
appearance with C++. It's like
using a German keyboard with the Y and Z
switched; it may
cause some minor errors but the layout is basically the
same.
Some layouts may be completely different, such as
Dvorak which moves nearly all
the letters to different
locations. This still has a lot of similarity, though.
To
look at something quite different, consider the stenotype
used by court
reporters to basically type in shorthand.
This is so far removed from an
ordinary computer keyboard
that it has little similarity beyond the fundamental
idea of
putting down letters on paper to represent words.
What Google wanted
to do was to take advantage of the
existing community of touch typists that know
the Java
keyboard. Sun stated that the language was free for anyone
to use.
What Oracle tried to say with the SSO theory was
that the Java
language(keyboard) was free, but the
API organization(choosing where
to put the keys) was
protected.
The keyboard as we know it has to have the
same keys in the
same place for touch typing to work. In fact, the
keyboard
itself is backward compatible with the typewriter, although
there are
many minor differences. (Have you seen a 1/2 key
on your keyboard anytime
recently?) There are many
variations on the standard keyboard itself especially
if you
look at older computers - the function keys have moved and
the backslash,
arrow keys may be in different places - but
the basic letters, numbers, space
bar, and shift keys stay
in the same place.
The reason Sun was concerned
about fragmentation was because
of what Microsoft tried to do to add additional
pieces to
Java, and still call it Java; then anyone using Sun's Java
would find
these Microsoft-specific pieces missing, and it
would not work the same. (Think
of the Microsoft keyboard,
with a key to open Calculator and Outlook. Or the
Windows
key that seems to have become ubiquitous on the modern
PC
keyboard.)
But there is a big difference between a keyboard whose
basic
function is to make marks on paper, and an API for a
programming language.
The first case is fundamentally about
human interaction. Much of the process
of making a program
run is automated. If documents were reproduced by
a
mechanism that sat over the keyboard, read a player-piano
type roll and
physically pushed the corresponding keys, that
would be closer to the situation
that exists with a computer
language. The machine pushing the keys does not
care that
the key it is striking has an "E" printed on it - even the
touch
typist doesn't actually need it, but it serves as a
helpful reminder; this is
akin to the documentation and
human-only comments, that do not actually affect
the
compiled code. It definitely does matter whether striking
the key produces
an E on the page - this is the functional
aspect.
Google decided to build
their own keyboard, after failing to
reach an agreement to use the Sun
Java-branded keyboard.
They may not have duplicated every key identically;
maybe
they left off the Print Screen and Scroll Lock keys. This
is not
fragmentation any more than the various Java editions
with more limited features
(J2ME is more like a laptop
keyboard that removed the number pad and function
keys,
which is part of why developers did not like it compared to
J2SE). This
prevents them from being able to brand it as an
official version of Java, but
Google was not really
interested in that as a primary goal.
-k (anonymous as
account creation is disabled) [ Reply to This | Parent | # ]
|
|
|
|
|
