|
|
|
| Authored by: Anonymous on Sunday, April 29 2012 @ 04:28 AM EDT |
Whelan v. Jaslow in 1986 is actually very weak it did not
establish much of anything. And whats more, how do you
reconcile that with 17 usc 102(b)?
"In no case does copyright protection for an original work
of authorship extend to any idea, procedure, process,
system, method of operation, concept, principle, or
discovery, regardless of the form in which it is described,
explained, illustrated, or embodied in such work."
SSO is ok for a Novel or a Movie, because for that subject
matter it is sufficiently obvious. In the context of a
system of networked functions all you are talking about is
thin air. There is no inherent structure to it, the only
structure it might have is in the concrete expression of the
implementation, however this case is not about concrete
expression in the inplementation. Which brings you right
back to Baker v Selden which was ruled by the SC and
therefore much stronger of a ruling.
Whelan v. Jaslow in 1986 is a very controversial ruling and
certainly can be challenged in multiple ways, and it is in
direct conflict with the legislation in 17 usc 102(b). [ Reply to This | Parent | # ]
|
| |
| Authored by: tknarr on Sunday, April 29 2012 @ 04:15 PM EDT |
I'd response to Whelan v. Jaslow with "merger doctrine". In the Java APIs the
expression of the SSO is completely merged with the functional aspect: you can't
even use the API (something Oracle claims is allowed without a license)
without reference to the SSO of the API. If I want to use the sin() method, I
have to use it in java.lang.Math. If I treat it as being placed anywhere else,
treating the API as having a different SSO, my code fails to even compile let
alone run. So whether SSO is protectable or not, in the case of the Java APIs
it's completely merged with a functional aspect that isn't
protectable. [ Reply to This | Parent | # ]
|
|
|
|
|
