The briefs have started to come in [see here], and the Supreme Court will soon hear oral argument (date TBD), in the Google v. Oracle** case.
**Connoisseurs of case captions will appreciate the nice “two-heavyweights-going-mano a mano,” “Ali v. Frazier” quality of this one; no et als, no d/b/as, no on behalf ofs … just the two titans facing off. It has some of the flavor of my favorite captions of all, cases (one or two of which the Court usually hears every year) involving competing State boundary claims or water rights or some-such, whose captions always sound like college football or basketball games: Nebraska v. Oklahoma, Michigan v. Wisconsin, etc.
It is, perhaps, the most important copyright case the Court has heard in over a decade, and interest in the case runs high, to put it mildly. Twenty-six amicus briefs supporting Google’s position, submitted by an exceptionally broad range of individuals, commercial entities, and non-profits—from Microsoft and IBM to Mozilla and Reddit and the Internet Society to the National Association for the Blind and the American Antitrust Association to a raft of law professors and computer scientists—were filed last week (plus two in support of neither party).*** That already puts the case at the high end of the distribution of the number of amicus briefs submitted per case (the average, in the Supreme Court, is around 10 or 11; see here), and we still have yet to hear from amici on Oracle’s side, who have until Feb. 19th to file their own briefs.
***Jonathan Band has provided a helpful summary of these briefs here. [Disclosure: Band represents one of the amici (the Computer and Communications Industry Association), and I have signed on to one of the law professors’ briefs supporting Google’s position in the case.]
The case involves a claim by Oracle that Google, in developing its Android operating system, infringed Oracle’s copyright in the Java programming platform. A little technical background is indispensable for understanding Oracle’s claim and why it is so important.
A program written in the Java language contains two different kinds of code: “declaring code” and “implementing code.” Declaring code (sometimes called a Java “declaration”) invokes (or “calls”) other programs from within a pre-existing library of Java programs, in order to accomplish some basic task—finding the larger of two integers, say, or summing a string of figures. The pre-written programs that are “called” from the library constitute the “implementation code.”
Oracle gives this example in one of its briefs:
The URLConnection program, for example, has the following declaring code:
public URLConnection openConnection()
throws java.io.IOException
An app programmer who wanted to connect her application to BankofAmerica.com without writing her own code can call on Oracle’s pre-written code by typing:
new URL(‘https://ift.tt/2NFx0gE Connection()
Then, when the program runs, the Java platform recognizes the declaring code and invokes the corresponding “implementing code” to connect to www.BankofAmerica.com.
The availability of a library of pre-written implementation code for thousands of tasks—pre-written and pre-tested subroutines, in effect—is one of the things that has made Java such a popular language in which to code applications, enabling Java programmers to accomplish a wide variety of tasks without having to re-invent the wheel and devise their own implementing code for these basic functions from scratch.
Oracle’s library of implementation code programs (sometimes also denoted as “methods”) contains over 30,000 such programs, containing many millions of lines of code, and is one of its most valuable IP assets. Oracle owns the copyright in these programs—nobody disputes that—and it actively issues licenses for their use. Anyone may obtain a royalty-free “open source” license to this entire collection of Java subroutines. Because open source licenses require users to make any alterations they make to the pre-existing code available to the public, many commercial entites are unwilling to enter into them, and Oracle accommodates them by also issuing commercial royalty-bearing licenses, at a negotiated price.
When Google began work on the Android operating system in the mid-2000s, it entered into negotiations with Oracle to obtain a commercial license for this implementing code—Oracle’s entire “Java Platform”—but those negotiations broke down. Instead of abandoning its decision to use the Java language for the Android operating system, Google chose to have its own engineers re-write those implementing programs (or, in some cases, to acquire code from third-party sources). [This new, non-Oracle implementing code, incidentally, makes up around 97% of the code for the Android operating system.]
So that’s the first important thing to understand about this case: Oracle has no copyright claim—and it has asserted no copyright claim—based on its immense and valuable collection of implementation programs, because Google did not end up copying any of that code.
What, then, is Oracle’s claim based upon? Google did indeed copy something: it copied Oracle’s hierarchical system for organizing these 30,000+ implementation programs. A little more technical background: Oracle organizes its collection of implementation programs/methods into a hierarchy consisting of about 3,000 “classes” of code performing different but related functions, which are then grouped together into around 150 different “packages” (aka “Application Program Interfaces,” or “APIs”) of related higher-level functions. It is, as Google describes it in its opening brief [here], the equivalent of an ordinary filing system: each package is a file cabinet, each class is a drawer within one of the cabinets, and each individual program containing a “method” is a folder within the drawer within the cabinet.
Google copied this hierarchical system for organizing Java methods because the corresponding declarations/calls must replicate this hierarchical system precisely if the calls are to operate correctly and find the proper “method” to run. For instance, “max” is a method/implementation program that finds the larger of two integers; a Java program seeking to invoke and run the “max” program would have a declaration that looks like this: java.lang.Math.max(5, 10). This indicates that the code for “max” is to be found within the Math “class” within the java.lang “package.”
The structure and text of the declarations, in other words, are tightly constrained by the hierarchical structure of the methods, classes, and packages; indeed, they are entirely determined by that hierarchy. As the district court put it, “the rules of Java dictate the precise form of certain necessary lines of code called declarations, whose precise and necessary form explains why Android and Java must be identical when it comes to those particular lines of [declaring] code.”
And Java programmers have already learned thousands upon thousands of declarations that are based on the Oracle organizing scheme. That is, in fact, a major component of what a Java programmer learns in order to become a Java programmer. Google’s use of Oracle’s hierarchical system for organizing the library of methods meant that Android programmers would be able to use the declarations with which they were already intimately familiar, without requiring those programmers to learn thousands of new declarations/calls to perform common tasks.
Thus, within the Android operating system, the declaration described above—java.lang.Math.max(5, 10)—does what it always does in a Java program: it finds the larger of two integers by running an implementation program (called “max”) that is located in the class Math in the java.lang package.
As Google puts it in its opening brief:
Google understood that developers would want to use their existing Java language skills to create Android applications, including their knowledge of familiar declarations and shorthand commands to trigger common operations. For those commands to work on the Android platform, Google had to replicate the syntax and structure of the Java API declarations exactly; any change to those declarations would have prevented developers from reusing the same commands, thereby forcing them to learn new commands for each routine task. Google accordingly used the same declarations for certain methods in 37 Java API libraries that were determined by Google to be “key to mobile devices.” For every one of those methods, however, Google wrote its own implementing code, tailoring the code to accommodate the unique challenges of the smartphone environment.
That’s the heart of this dispute: whether copying the hierarchical structure of the library of implementation programs—not the implementation code in those programs, but the system by which those programs are organized—and the declarations that reflect that hierarchical structure (e.g., java.lang.Math.max(5, 10)) infringe Oracle’s copyright in that structure and those declarations.
Google argues that it does not. I agree, and so did the district court, which held, correctly, that the structure of the libraries, and the corresponding text of the declarations which reflect that structure, are not protected by copyright at all. Without diving too deep into the copyright weeds, the short version of the court’s reasoning is simple and straightforward. The Copyright Act, a hopeless muddle about many things, is transparently clear on point: copyright protection is not available for systems or processes or organizing methods or the like. Section 102(b) says this explicitly, and reads in full:
“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.” (emphasis added)
This is one of the truly fundamental principles underlying our entire intellectual property regime: No matter how original or creative your system may be, or how much time and effort you put into developing it—and Oracle spends a great deal of time in its pleadings showing how original and creative and useful and valuable its hierarchical organizing system for Java methods is, and how much time and effort it expended on its development—copyright law does not allow you to prevent others from reproducing and using that system.
Incidentally, a posting [here]at the Federalist Society by David Hogberg gets this case horribly wrong. The inadvertent tip-off is right there in the headline:
“Here’s How The Supreme Court Can Stop Google From Stealing People’s Ideas.”
The Supreme Court can do no such thing, because copyright law does not prohibit “stealing” ideas; copying someone else’s idea isn’t “stealing” at all, because ideas can never receive copyright protection, no matter how brilliant or original it may be.
This vital principle establishes, among other important things, the line separating the world of copyright from the world of patent. You can get IP protection for a “system” or a “process” or a “method of operation,” but only by obtaining a patent on it, which will require you to meet very different, and far more stringent, requirements to obtain protection than does copyright, and which will last for a far, far shorter period of time.
Copyright aficionados will recognize this principle as having been derived from the seminal Baker v. Selden (101 US 99, 1879) case, a delicious case of 19th century commercial intrigue. Selden had come up with a new and innovative method of double-entry bookkeeping—one that, I’m told by those who understand bookkeeping better than I do, has been incorporated into much standard bookkeeping practice. He published a book describing the system, along with several blank data-entry forms that were to be used when implementing his new system. Baker, a stationery publisher, published books containing blank bookkeeping forms, and he included Selden’s forms; Selden sued, asserting that Baker had infringed his copyright in the book.
The Court held for Baker. It started with a “proposition so evident that it requires hardly any argument to support it”: that Selden, though he possessed a valid copyright in his book, obtained no exclusive rights therefrom in the bookkeeping system itself. Exclusive rights of that kind, the Court declared, “are the province of letters-patent, not of copyright,” and any such claim “must be subjected to the examination of the Patent Office before an exclusive right therein can be obtained.” Because Selden’s system had not been patented, it was “open and free to the use of the public.”
And because using the system required using the special forms that Selden had devised—the Court called the forms “necessary incidents” to the use of the system itself—the forms were, like the system itself, “open and free to the use of the public.” To hold otherwise—to give Selden a copyright monopoly over the forms—would effectively give him a monopoly over the use of the system. Patent-like protection, in other words, without having to satisfy the requirements of the Patent Act.
In short, Oracle’s system for organizing its library of Java “methods” has no copyright protection whatsoever, and Google was allowed—at least as far as copyright law is concerned—to copy it. Only a patent would serve to protect it from replication—and Oracle, like Mr. Selden, didn’t get a patent. As the district court put it:
That a system or method of operation has thousands of commands arranged in a creative taxonomy does not change its character as a method of operation. Yes, it is creative. Yes, it is original. But it is nevertheless a command structure, a system or method of operation — a long hierarchy of over six thousand commands to carry out pre-assigned functions. For that reason, it cannot receive copyright protection — patent protection perhaps — but not copyright protection.
[A great deal of ] code had been written in Java before Android arrived. These programs necessarily used the java.package.Class.method() command format. These programs called on all or some of the specific 37 packages at issue and necessarily used the command structure of names at issue. Such code was owned by the developers themselves, not by Oracle. In order for at least some of this code to run on Android, Google was required to provide the same java.package.Class.method() command system using the same names with the same “taxonomy” and with the same functional specifications. Google replicated what was necessary to achieve a degree of interoperability—but no more, taking care, as said before, to provide its own implementations…. Google was and remains free to group its methods in the same way as in Java, that is, to organize its Android methods under the same class and package scheme as in Java.
“Necessary to achieve a degree of interoperability.” That language helps explain why the case is so important, and why interest in it is so high. If Oracle prevails here, the ability of software developers to design interoperable programs—programs which borrow enough of the command structure and organization of other, pre-existing programs—will be deeply compromised, and that could well have rather profound and unfortunate consequences throughout the technology industries.
The Federal Circuit, in reversing the district court and holding that Oracle did possess an enforceable copyright in its system for organizing the Java methods library, has perpetrated a deep and substantial misunderstanding of U.S. copyright law.*** One hopes that the Supreme Court will take this opportunity to correct that unfortunate state of affairs and put copyright law back on course.
***That the case ended up going from the Northern District of California to the Federal Circuit—the appellate court primarily responsible for hearing patent appeals—rather than the Ninth Circuit was due to the fact that Oracle had originally asserted a patent claim in addition to its copyright claim. The patent claim, however, was subsequently dismissed, though not before it had given the Federal Circuit jurisdiction over the appeal. The judges on the Federal Circuit have little experience with the Copyright Act, and it showed.
In fact, the Federal Circuit reversed two separate decisions in Google’s favor in this case. On the first appeal, it reversed the district court by holding that Oracle’s organization of its Java libraries was a copyrightable work of authorship, and remanded the case back to the district court for trial. The district court then held a full jury trial on the question of whether Google had infringed that copyright; the jury found no infringement because Google’s use of the hierarchical structure constituted a “fair use.” Once again, on appeal, the Federal Circuit reversed. That decision, too, for reasons I won’t go into here [see here and here if you’re interested], has little to recommend it.
from Latest – Reason.com https://ift.tt/2v79aUJ
via IFTTT
