Johnson Controls v Phoenix Control Systems,
886 F.2d 1173
(9th Cir CA, 1989) at ¶11:
Where an idea and the
expression "merge," or are "inseparable," the expression is not given copyright
protection. Herbert Rosenthal Jewelry Corp. v. Kalpakian, 446 F.2d 738, 742 (9th
Cir.1971). In addition, where an expression is, as a practical matter,
indispensable, or at least standard, in the treatment of a given idea, the
expression is protected only against verbatim, or virtually identical copying.
Rachel v. Banana Republic, Inc., 831 F.2d 1503, 1507 (9th Cir.1987); Frybarger,
812 F.2d at 530.
Note the second sentence in the cite from Johnson
above. It would seem in seeking their own implementation of the API
implementations, Google avoided verbatim or virtually identical
copying.
Now, is SSO subject to merger as inseparable? It would seem the
Java path names make it so, based on your reading of Sony v. Connectix
injunction appellate decision,
203 F.3d 596 (9th Cir. 2000) at ¶29 and ¶30.
Also supported at
¶23:
The fair use issue arises in the present context because of
certain characteristics of computer software. The object code of a program may
be copyrighted as expression, 17 U.S.C. S 102(a), but it also contains ideas and
performs functions that are not entitled to copyright protection. See 17 U.S.C.
S 102(b). Object code cannot, however, be read by humans. The unprotected
ideas and functions of the code therefore are frequently undiscoverable in the
absence of investigation and translation that may require copying the
copyrighted material. We conclude that, under the facts of this case and our
precedent, Connectix's intermediate copying and use of Sony's copyrighted BIOS
was a fair use for the purpose of gaining access to the unprotected elements of
Sony's software.
(Emphasis added)
From further reading of ¶23
of Sony we can draw a parallel between fair use decompiling or disassembly and
fair use accessing through path names dictated by SSO. The idea being that
Google's independent implementation of the Classes, etc. of the particular APIs
require the SSO to compile using javac using Java's original implementation.
Those ideas and functions not accessible without using the SSO, incidentally
also used by numerous Java SE programmers in original works.
There is no
apparent legal requirement that Google should change the SSO in providing their
API implementations, in particular when maintaining that observable structure
allows an improper subset of Java SE to be run on Dalvik after conversion, using
the JDK for exactly what it was intended. Improper subset in that Google
provides additional API implementations for use. The API SSO required to use
Oracle's API implementations, the names and functional elements not protected as
ideas and used during generation of Java code ultimately translated for Android
use.
Drive by fair use and unprotected elements. Belts and suspenders for
the eventual appeal. [ Reply to This | Parent | # ]
|