|
Authored by: darrellb on Friday, April 27 2012 @ 12:58 PM EDT |
I think the Court will decide that the work as a whole for the case is the work
as registered, not portions of the registered work.
Since Oracle has just backed off the collective claim, their claim must now be
that Java is a complete work. They're out of options, I think.
The complete work stance raises some other questions, too, if the work
registered is a derivative.
[ Reply to This | Parent | # ]
|
|
Authored by: OmniGeek on Friday, April 27 2012 @ 01:12 PM EDT |
On a related note, Oracle proposes a jury question about copying Oracle's
documentation into Google's code. If I understand the process by which that
documentation was created, there's an excellent argument to be made that its
SSO, and indeed the whole document, is a derivative work of the source code
(Java on Oracle's part, Android on Google's part) rather than a separately
protectable work.
I reason as follows: At least some of the Java documentation (possibly most?)is
generated automatically by a source code parser that extracts the method
signatures and associated comments, and generates a documentation file
therefrom. This does not involve any creative or original work with regard to
the output file (originality of the automated tool is a different matter not
relevant here). Since the documentation output depends utterly on the API
portions of the source code input, the docs must be a derivative work of the
input source code. Note that the *implementation* part of the source doesn't
come into this process, just the API portion (method names and signatures).
Where's the separately protectable expression here? I don't see any, hence my
contantion that the autogenerated docs are a derivative work of the input source
taken as a whole.
Anothet consequence is this: If Google runs an equivalent (or the same) source
code parser on its independent Android implementation, the fact that Google's
implementation MUST have the same file names and method signatures (SSO) as Java
in order to be compatible means that the documentation files output from this
process MUST be virtually identical to those generated using Oracle's Java
source, even though the implementations are materially different.
This seems to be fertile ground for arguments of nonprotectable nature of the
autogenerated documentation.
---
My strength is as the strength of ten men, for I am wired to the eyeballs on
espresso.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Friday, April 27 2012 @ 01:18 PM EDT |
Copyright exists merely because someone wrote something. The ability to sue over
copyright infringement comes about by virtue of registering the copyright.
Oracle has the right to go out and register other parts of java and that will
enable them to sue others later over those registered copyrights.[ Reply to This | Parent | # ]
|
|
Authored by: IMANAL_TOO on Friday, April 27 2012 @ 01:35 PM EDT |
From my perspective, if an API is hidden or not, is a question of frail
semantics between everyday usage of words and what are not.
If it is, technically, a "public" API, it may be still
"hidden" as its specifications are not normally not available to the
public, even if it is ("technically") named "public" [yet
technically "called" - publically... ;)]
What is generally made available to the general public is the API. What is
generally NOT made available to the general public is ALSO the API. Some see
this as a paradox, I guess.
In other words, it depends on which of the APIs you are talking about. The issue
is that all modern programs have an API at some level.
So, as you know, if an API was made as a single level API, then then all eternal
pun GNU would not have been invented:
GNU stands (or at least stood for) for GNU is not UNIX, where that GNU stood for
GNU is not UNIX, where that GNU stood for GNU is not UNIX, where that GNU stood
for GNU is not UNIX, where that GNU stood for GNU is not UNIX, where that GNU
stood for GNU is not UNIX, where that GNU stood for GNU is not UNIX, where that
GNU stood for GNU is not UNIX, where that GNU stood for GNU is not UNIX, where
that GNU stood for GNU is not UNIX, etc.
Still, the principle is relevant.
Java uses the GPL of GNU. Therefore, Java was aware of the GNU principle of
reciprocal algorithms; where "reciprocal algorithms", by the way, have
been used many centuries ago...
But, as the World was told, Java, as an object oriented system, of course, had
to rely on "public" and "private" methods [sic!, plural] for
their APIs, regardless if they were "top level" or not, as far as the
compiler was concerned.
Top levels in Java were, sorry, still sublevels to even higher level APIs.
---
______
IMANAL
.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Friday, April 27 2012 @ 09:33 PM EDT |
Specs are not really like a black box. They are more like a wall. On one side
of the wall, there is the implementation, on the otherside is the application.
If the ruling out of this says that Google violated some copyright because they
used the spec to write an API, then the same can be said for any application
developer that uses the spec to call the API.[ Reply to This | Parent | # ]
|
|
Authored by: matth on Saturday, April 28 2012 @ 01:27 PM EDT |
The comments of one language may contain the syntax of another. This
embedding
structure goes at least as far back as embedding assembly language
in C.
It is
inaccurate to state that comments do not or cannot contain functional parts.
In
other words, it's ALL code.[ Reply to This | Parent | # ]
|
|
|
|
|