|
|
|
| Authored by: Anonymous on Monday, April 23 2012 @ 06:27 PM EDT |
Even if lawmakers ponder the effects of the laws they make that they know about,
there will almost always be effects of the same laws that they will not know
about. Unless they start getting all rigid and specify exactly when those laws
apply. Then have those laws only apply in those circumstances. Of course that
will cause problems with loopholes and whatnots. Given that lawmakers are not
omniscient and omnipotent.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, April 23 2012 @ 06:32 PM EDT |
It's what they were also trying to do with SCO vs Linux,
trying to apply what should not be applied, where copyright
gained a new status, with a methods and concepts feel.
Just plain wrong.
[ Reply to This | Parent | # ]
|
| |
| Authored by: mschmitz on Monday, April 23 2012 @ 06:54 PM EDT |
| I guess that boils down to the fair use defense. To quote from the initial
exchange:
Google: Want to clarify. About the "Dudley"
packages. When I said "public domain", I'm talking about the code. It's our view
that the API is in the public domain. It's only when you get to the code, that
it can be copyrighted.
Judge: I will instruct the jury that the copyrights
extend to the SSO. I see both sides arguments on this. If you win on fair use,
then the judge doesn't have to decide those questions. [PJ: Implied, at least,
is that if they don't win, then he'll decide then. I see others so
tweeting.]
The way it's going to be presented to the jury, is that the SSO
*is* covered by copyright - not its own copyright, I'm not prepared to say to
the jury that it's a standalone entity with its own copyright, but the copyright
issued that applies to everything also applies to the SSO.
The
judge has already made up his mind that sequence, structure and organization of
an API (i.e. all that makes up the API spcecification) is covered by copyright,
but leaves open the option that Google's use of it was fair use.
Would anyone
in the IT field assume use of the API as intended, even to implement a
concurrent implementation, is fair use? Most if us would say so. Does the
definition of fair use as a defense leave room to consider whether the
alternative would have far reaching, catastrophic consequences? I don't think
so. See here for a
definition of the fair use test (p. four, second paragraph). It talks about the
effect of copying on the potential market or value of the work (still thinking
books here!). The potential damage to an entire industry is not even considered.
The only defense I see is the 'amount and substantiality of the copied
portion in relation to the work as a whole'. If the 'work as a whole' is the API
specs only, it's massive. If it's specs and implementation and docs together,
it's minimal (amount) but might still be considered substantial (it's importance
to make the whole, er, work).
The last section in the quote above does
convince me the copyright is seen to apply to the 'work as a whole', i.e.
implementation. Whether Google can successfully claim fair use on the face of
how important sequence, structure and organization are, of that I have no idea.
This would go all the way to the Supreme Court, I'd hope.
Not a lawyer -
which should be obvious from the fact that the phrase 'work as a whole' did not
trigger anything prior to looking it up in the Copyright Office circular.
--
mschmitz
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, April 23 2012 @ 07:55 PM EDT |
Ever read a Haynes manual?
No-one will ever be able to home a car from drawings/specifications again.
Took a nice Holiday snap of Niagra falls, tough, there's some dude who already
owns that picture, and the one you took on the beach.
No-one will ever be able to implement a better library.
the Tolkein estate will argue that all books with orcs are be derivatave.
JK Rowling will have wizard schools all sewn up.
The Asimov estate will sue anyone who has ever used the word robot.
Then the music industry will catch on,
Then the movie industry will catch on
The software is just there to dazzle you as it has dazzled many a patent
examiner.
This case is not about software, It's about how far thin copyright protection
goes for an SSO.
On anything.
Oracle are squeezing fair use between the mergers and scenes a faire doctrines
by mixing the applicable standards of substantial copying and exact copying and
stretching "thin" copy protection as wide and deep as possible.
e.g substantially copying (90%) of our SSO you can see in our Book, into their
source code, making their source code an exact copy of our SSO from their Book
which is a similar Book to our Book in this sub section of our SSO.
Replace "source code" with any copyrightable expression you can think
off.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 24 2012 @ 01:57 AM EDT |
If you are not alowed to reimplement an API, that would mean the end of
independantly implementing any protocol. It would be the end of Samba, Wine,
jdbc drivers for MS SQL server:
the interface description is either copyrighted or a trade secret.
Oracle is arguing you are not allowed to USE the description to implement
something compatible, even if you figure out the description yourself.
It is ridiculous and the judge should have rule on this long ago and saved the
jurors the copyright trial.[ Reply to This | Parent | # ]
|
|
|
|
|
