Last week a diverse group of industry leaders, creatives, academics and a former U.S. copyright chief submitted amicus curiae briefs in support of a reversal of the district court's ruling on the Android-Java copyright infringement case. Google subsequently requested additional time to respond to Oracle's opening brief and these submissions.
In my previous post on this case I summarized and quoted from the amicus curiae briefs of former Register of Copyrights of the United States Ralph Oman and three computer science and engineering professors. I would now like to highlight the last amicus brief in support of reversal to have become publicly available. A formality had caused a delay. Here's the amicus curiae brief of Sun founder Scott McNealy and former Sun Executive Vice President Brian Sutphin (this post continues below the document):
Scott McNealy-Brian Sutphin Amicus Curiae Brief in Oracle v. Google by
This submission is unique in that it focuses on the philosophy and history of Java, addressing the legal issues in this case only indirectly. For example, the explanation of the "Write Once, Run Anywhere" principle has a bearing on why Google's "fair use" defense should be rejected as a matter of law, and many technical explanations and examples will help the United States Court of Appeals for the Federal Circuit to appreciate the creative choice involved in the authoring of the material Google copied.
The strength of this brief is its coherence, which one can only appreciate by reading the actual document. No blog post would be able to convey it appropriately. But there are two things that I would like to highlight because they are particularly relevant.
The first one is an innovation policy argument: Judge Alsup's denial of copyright protection to a huge amount of highly creative and indisputably original source code was not anticipated by Java's creators, and if they had thought that this was the law, they would have invested much less in the platform:
"In denying copyright protection to the copied elements of Java, the district court has upset the expectations of those that created the Java platform, who thought that the source code that they painstakingly developed would receive the same copyright protections afforded to any other source code (or literary work). [...] Had Sun known a priori that the result of investment of millions of dollars and years of development time would not receive copyright protection, it never would have invested as heavily in Java."
And the final sentence of this brief reinforces this point:
"The threat that a competitor like Google could simply take the naming conventions and organization of the Java Packages would have deterred Sun from maintaining its decades-long mission to revolutionize computer software development."
This is perfectly credible. Sun was a company, not a charity.
We're going to touch on innovation policy again at the end of this post. The second aspect of the McNealy-Sutphin brief that I wanted to discuss here is similar but complementary to the part of the Spafford-Ding-Hollaar brief that explains creative choices in API design based on the example of a drawCircle method. An API can provide a function for drawing a circle that is dedicated to this task, or a more flexible drawEllipse method (a circle is an ellipse with two identical axes), or an even more flexible drawPolygon method with a group of parameters including one for the number of sides ("0" would then correspond to a circle). What Scott McNealy and Brian Sutphin do in their brief (among other things) is to show how Sun, Microsoft and Apple each developed unique APIs, and the example they use for this is related to time zones and date formats:
"In Java, a developer setting the time zone in an application would first go into the 'DateFormat' class of the java.text package and declare the 'setTimeZone' method. By just looking at their labels a developer will intuitively know that the DateFormat class can be used to format a date, and then use the setTimeZone method to set the actual time zone for that developer's application. But creators of competing computer programming environments can accomplish this same function in an unlimited number of different creative ways.
Indeed, a quick examination of other programming environments shows that creators of other development platforms provide the same functions with wholly different creative choices. For example, Apple's iOS platform devotes an entire class to set the time zone in an application-- the 'NSTimeZone' class. Unlike Java's placement of that package in the java.text package, Apple put it in its 'Foundation' framework. (A framework is Apple's terminology for a structure conceptually similar to Java's 'package.'). Apple's NSTimeZone class contains numerous methods to manipulate time zones, including, retrieving time zones with abbreviations ('timeZoneWithAbbreviation'), retrieving time zones with names ('timeZoneWithName'), and setting the default time zone ('setDefaultTimeZone'). It was Apple's creative decision to organize the time zone programs in this manner, select time zone programs that it believed was desirable to programmers and label the time zone programs as they chose.
Likewise, Microsoft provides similar functionality, but with an entirely different structure, naming scheme, and selection. In its Windows Phone development platform, Microsoft stores its time zone programs in the 'TimeZoneInfo' class in its 'System' namespace (Microsoft's version of a 'package' or 'framework'). Within that organizational structure, Microsoft has programs to, among other things, convert time from different time zones ('ConvertTime') or determine whether a particular date and time in a particular time zone is ambiguous ('IsAmbiguousTime')."
The above three paragraphs are very powerful. They show that something is fundamentally problematic about the district court's holding that copyrightability had to be denied partly because the relevant code comes down to a method of operation and partly for "interoperability" reasons. Where there is so much creative choice that three major industry players choose three distinct designs, there must be copyright protection. Patents are not the answer in this context because it doesn't matter which of these APIs came first: irrespectively of novelty, these efforts to make a platform "elegant and easy to learn and memorize" deserve intellectual property protection. This is about how the code is written, not about the functions it performs.
Messrs. McNealy and Sutphin then contrast the original and creative approach of Sun, Apple and Microsoft with Google's copying:
"Apple and Microsoft made different creative choices from those found in Java. This difference in creative choices exists amongst Sun/Oracle, Apple, Microsoft, and countless other developers of programming environments--with only one notable exception: Google's undisputed and intentional copying of Java's creative choices at issue in this case. While Sun/Oracle, Apple, and Microsoft invested considerable resources and valuable time making creative decisions for their respective programming libraries, Google did not: it merely copied desirable packages from the Java platform."
And the net effect was the opposite of interoperability:
"By copying the creative elements of the Java platform familiar to Java developers, but at the same time ensuring that Java code written for Android was transformed into Android-specific code, Google's actions had two consequences: quick access to Java developers while ensuring that Java cross-platform compatibility was not maintained. Google's copying of the creative structure of Java was certainly successful in attracting developers quickly, but undermined the very principle that Java sought to promote: cross-platform compatibility."
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
