|
|
|
| Authored by: Gringo_ on Sunday, May 06 2012 @ 12:02 PM EDT |
I respectfully disagree with your respectful
disagreement...
Exactly
how would you get around it? There was an
inspired discussion on this under the
previous article under
"Oracle shoots itself in the foot". At some point down
in
the nest of comments an anon came up with an inspired idea,
thinking
outside the box. He suggested...
you could write the
translator program in
Java (with a Java license). The data produced with the
non-
standard SSO class name paths would be the creative work of
the author
(not Oracle), would not have the Java SSO naming
convention in it at all, and
could be distributed to
billions of Android devices without Oracle being able
to
assert copyright on it.
I have to admit that might
work, however let us imagine
this translator in use. The Android developer
writes his
source code employing Java SE and the Android SDK as usual,
then
compiles his code plus resources down to a .pak file
with the .class files. Now
when the user goes to use an app,
that app is loaded into memory, and a JIT dex
compiler
translates the .class files into dex ops, with the help of
Harmony.
Now on my Android phone, this happens so fast it
seems to me the app starts
immediately, but what if we had
to insert the translator into the process? It
would consume
a huge amount of memory, and it would take time. I think it
would be impractical.
If it is impractical, then we can continue to
state "Google
could not translate the names and SSO of the API and still
have
the same functionality", but considering this does
somewhat invalidate my
arguments above, where I am saying it
is not possible at all. However, this
idea depends on the
notion that we can get around copyright issues with this
translator written in Java, and it would be an unique
solution to Android
only, and not help us with the fear of
APIs in gneral suddenly becoming
copyrightable. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 01:06 PM EDT |
Well, that dorsn't enlighten us much. Are you suggesting that simply
renaming is going to somehow change the "SSO"? Remember, everyone
has already
agreed the names themselves are not protectable. [ Reply to This | Parent | # ]
|
- fail on my part - Authored by: Anonymous on Sunday, May 06 2012 @ 02:53 PM EDT
|
|
|
|
