A week after Oracle filed the opening brief in its appeal of a district court's ruling on the Android-Java copyright infringement case, amicus curiae briefs were submitted by technology industry leaders (three different briefs), organizations representing creatives, academics, and a former U.S. copyright chief. In a request for more time to respond to Oracle's brief, Google noted the aggregate length of the amicus briefs supporting reversal.
By now I've been able to access and analyze all amicus curiae briefs except for the one filed by Sun founder Scott McNealy and former Sun executive Brian Sutphin, and wanted to do a follow-up on the content of some of the briefs. There are really two categories of amici:
major stakeholders (industry players writing directly and through BSA | The Software Alliance, and creatives) stressing the chilling effects that the district court's ruling would have if upheld, and
experts who don't represent billion-dollar groups or organizations but bring a wealth of legal and technical expertise to the table.
The briefs from major stakeholders drew almost all of the media attention in this context. They are undoubtedly powerful and persuasive, and backed by an impressive and diverse group of companies. Except for one remark on corporate interests this post will focus on the submissions made by the aforementioned individuals, which I believe deserve more publicity and are going to be extraordinarily helpful to the appeals court because they provide first-rate information from practitioners that calls into question the district court's legal analysis and technical findings.
Amicus curiae briefs are usually unrelated to conspiracies and rivalries
The one thing I wanted to say and further explain in this post about the submissions from industry players is that I disagree with commentators who speculated, at least between the lines, about competitive motives, when it's actually about the issues.
Even if someone might have a reason to hurt a particular rival through an amicus brief, he ultimately won't want to cut his nose to spite his face by taking positions on overarching issues that may come back to haunt him elsewhere. The plausibility test for whether there might be such an agenda in play in a particular case must extend beyond the simple and superficial questions of whether companies compete in certain markets and/or have litigation pending against each other on completely unrelated issues. The hurdle for the plausibility test must be reasonably high because large corporations have interests, not friends, and there have been other intellectual property issues on which companies taking different positions on the Android-Java case were on the same side. The hurdle for the plausibility test should be particularly high if an amicus actually competes with both parties to a dispute, and in my view it's insurmountably high if a given stakeholder actually owns valuable intellectual property that depends on the type of protection he advocates.
A conspiracy theory is likely also baseless if there's a consensus among industry heavyweights. With the BSA membership including Apple, IBM and Microsoft (the latter also submitted a brief together with EMC and NetApp), and with Oracle being the appellant, four of the five largest players in this industry agree that reversal is needed (though they do support interoperability, which is not what Google's selective copying of Java material is about) -- and the only one of the top five companies in IT to promote weak copyright is Google itself, which also happens to be the only large IT company to bash the patent system instead of focusing only on constructive reform proposals.
Former U.S. copyright chief says Judge Alsup's ruling "largely eviscerates copyright protection for some of the most creative aspects of computer software"
In a recent post I discussed the background of Ralph Oman, a former Register of Copyrights of the United States, and mentioned that the headline of his brief stressed the urgent need to reverse Judge Alsup's decision. His brief is in many ways antithetical to the section of the district court ruling entitled "The Development of Law on the Copyrightability of Computer Programs and Their Structure, Sequence and Organization" (which Judge Alsup had concluded with an "apology for its length"). Mr. Oman, who helped shape copyright legislation and is a professorial lecturer, explains how statutory and applicable case law on copyrightability should be interpreted and applied in this context.
Here's Mr. Oman's brief (this post continues below the document):
Ralph Oman's Amicus Curiae Brief in Oracle v. Google by
Mr. Oman's brief warns that the copyrightability-denying "aspect of the [district] court's decision, if not reversed, will chill investment and innovation in the software industry, and retard development of future generations of software, because it largely eviscerates copyright protection for some of the most creative aspects of computer software". The filing also says that "the rejection of copyright protection for the organization of Oracle's software packages threatens to do violence to the very concept of copyright protection of software".
It's difficult to select particular passages from Mr. Oman's highly coherent submission. Still I would like to quote four passages that I believe are exceptionally helpful in understanding some of the problems concerning the district court's ruling.
I think the following example explains quite well the idea of protecting structure, sequence and organization regardless of the protectability of the individual elements of a larger structure:
"Likewise, choreography -- the arrangement and sequences of movements, steps and patterns of dancers -- is subject to copyright protection (17 U.S.C. § 102(4)), even though the underlying movements and steps are not protectable; the options for each movement or step are limited, and each command serves the function of directing the movement of the dancer."
Mr. Oman explains that whether something is copyrightable must not depend on a circumstance that can change over time:
"[U]nder the court's reasoning, even if the Oracle command structure was copyrightable at the time it was created, the later development of a market based around the Java platform could somehow vitiate protection before the end of the copyright term. The fact is that even if the specific market considerations that the court posited somehow existed at the time the software was first authored, it would still have been inappropriate to consider them, as they could not have affected the programmers' creative choices."
In the above context it's key to consider that "[s]oftware concerned with interoperability is no more or less 'functional' than code that enables a program to display images on a monitor or send email; it is a string of commands resulting in a series of actions".
Footnote 9 of Mr. Oman's brief basically says that the district court's ruling was counterproductive with respect to the policy goal of interoperability:
"[...] Oracle points to admissions by Google that Android was not designed to be 'interoperable' with Java applications at all. [...] Assuming this is correct, the [district] court's decision has a decidedly anti-competitive effect: While denying copyright protection to the creator of an original work, it secures a plagiarist's use of non-interoperable software."
In the next and final section of this post you'll see that a group of computer science and engineering professors also believes that the denial of copyrightability for what isn't truly interoperability is against the public interest.
The fourth passage I'd like to quote from Mr. Oman's brief relates to the question of whether the denial of copyrightability in the API context is justified, as Judge Alsup suggested, by the availability of patent protection for software. I discussed this issue in a separate post and said that the two intellectual property regimes at issue -- software patents and copyright -- are complementary. Mr. Oman puts it like this:
"The [district] court's reluctance to grant a '95 year monopoly' seems to stem not just from believing it had to choose between copyright and patent protection, but also from mistakenly equating the copyright and patent monopolies. The copyright monopoly is longer, but much more limited than the short, 'powerful' patent monopoly. An inventor can bar a subsequent inventor from practicing an invention, even if the second inventor had no knowledge of the first and independently created the same invention, and there is no 'fair use' defense to patent infringement. Not so on the copyright side. [...]"
Computer science and engineering professors explain choice in API design and warn against security and stability issues resulting from lack of protection of APIs
In a previous post on the fact that various amici curiae made subsmissions I also talked about the background of computer science and engineering professors Gene Spafford, Zhi Ding and Lee Hollaar. I mentioned Professor Spafford's impressive contributions to key open source projects in the area of computer security, and Professor Hollaar's influential amicus briefs in other IP cases.
After the California trial I saw that some commentators were extremely impressed with Judge Alsup's mentioning of his own efforts to learn Java. While I agree that it's great if judges acquire technical knowledge relevant to IP cases, I think it's important to separate this story from the analysis of how well-reasoned a given ruling is. I don't doubt that Judge Alsup acquired the knowledge he talked about in court, but with the greatest respect, his copyrightability ruling could have been written, even without any knowledge of Java, by anyone who simply decided to adopt Google's arguments. But if some people prefer to talk about background rather than substance, certain amicus curiae briefs should give them pause. I don't think anyone can argue that Mr. Oman knows less about copyright law than Judge Alsup, and with respect to the issues of technical fact that are key to the copyrightability analysis, the three professors have likely forgotten more about programming than any judge will ever know.
The Spafford-Ding-Hollaar brief has the following focus:
"We submit this brief to draw the Court's attention to, and correct what appears to be, the district court’s fundamentally erroneous understanding of the creativity underlying APIs. We do not address the district court's legal reasoning, but we do observe that its holding appears predicated on assumptions that there is only one or a few limited ways to express an API and that expression is dictated by a set of pre-determined functions. Those, assumptions however, are mistaken: for any given problem or use case, an API can be structured and expressed in a vast variety of ways, and that variety reflects the creative choices and subjective judgments of its author. In other words, contrary to the district court's opinion, a huge number and variety of APIs may be written to accomplish the same purpose, and the differences among those APIs are determined by each designer's creativity, experience, and personal preference, and only somewhat, if at all, by any requirements of functionality."
Here's the academics' brief (this post continues below the document):
Spafford-Ding-Hollaar Amicus Curiae Brief in Oracle v. Google by
In my opinion the brief does a great job explaining the creative choices involved in API design. The existence of those choices runs counter to the district court's finding that the asserted code is just functional and not creative. One example is that even for a function that draws a circle, there are alternative solutions. An API can have a function that does nothing but draw circles. It needs few parameters, but it's also a one-trick pony. A drawEllipse function is more flexible, and a circle is just a special kind of ellipse, so you can use that function to draw a circle just by setting the parameters accordingly. And even a drawPolygon function could be capable of drawing circles. The brief explains that there could be a complex variable called ShapeType, which would be an object (so we're talking about a parameter that actually groups multiple parameters), and if one of the parameters it contains specifies that the object has zero sides, the drawPolygon function could also be used to draw a circle.
Those three options for drawing circles are, obviously, not exhaustive, and this is is just one of countless functions in the Java APIs ("the district court incorrectly focused on a single method and failed to address the many other creative choices that go into software API design beyond simply the parameters in a method declaration, including: the class in which the method is defined; the method's exposure to other classes; and the containing class’s relationship to other classes, interfaces, and packages").
The final part of the Spafford-Ding-Hollaar brief explains why APIs protected by copyright will be more reliable and secure (thereby warning against the negative effects of a denial of copyrightability on security and stability):
"D. Copyright Protection Incentivizes Reliable and Secure APIs.
APIs embody the creative expression, competence, and understanding of their original authors. To the extent that copyright protection over the design and structure of APIs prohibits unauthorized changes to APIs, they may help prevent the introduction of anomalous problems, including security, compatibility, stability, and fragmentation that may result from such changes.
If an API is written by an author trained in proper software engineering, safety, and security, the resulting API and code may support critical features and dependencies not explicitly described in the documentation. If someone else with less knowledge of the features and dependencies modifies the API (and the underlying implementation), it may introduce unanticipated vulnerabilities and instability. The versions (and stability) of the software may become fragmented and of uncertain reliability.
Using the blueprint analogy given above, anyone not following the blueprint (e.g., putting in larger or extra windows) may cause unexpected failures (e.g., wall collapse because of loss of load-bearing structure) because not all of the design requirements and responses are explicitly shown in the blueprint. By the same token, we believe that a software API should receive copyright protection to help prevent such failures in information systems."
As you can see above, these three computer science and engineering professors believe that the district judge not only misunderstood some key technical issues but also issued a ruling that, if affirmed, would be undesirable from a public policy point of view. Other amici also raise public policy arguments and generally argue that investment in innovation must be protected by intellectual property rights. The interesting thing about the section quoted above from the academics' brief is that they talk about an additional reason for which end users would be better off if there's a reasonable degree of protection for APIs.
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:
